最近在學習k8s與serviceMesh技術時，由於發現網上內容概念太多，太亂，太細，很多文章就是COPY很多基本知識，與我期望的認知過程不符合，所以寫這樣一個學習筆記。不講安裝，不講demo，只是整合一些知識點，並理清相關的概念與關聯，形成一個知識框架方便記憶與使用。
正好看到這麼一篇文章–“關於整體性學習”https://www.jianshu.com/p/1019549f256b，與我想法不謀而合，我的目的就是建立這麼一個基礎的知識框架。
因爲水平有限，有些知識點還是自己猜測的，有不對的請各位看官指正。
一、從docker到k8s
開始用docker還是比較方便的，但如何從docker的組合角度進一步理解，如何實現部署可伸縮應用，應用編組提供服務，進一步提供對外的服務？K8s會怎麼做出選擇呢？
先上圖，左邊是我理解的k8s中的東西，右邊是一般使用Docker。
1. docker容器與pod
先不講伸縮（假設有腳本可以幫你完成），你在裝有Linux的物理機或者虛擬機上，如何用docker組織出一個微服務呢？首先是相同的應用應分散在不同的機器上，另外不同的應用之間如何調用？至於分散在哪，哪些相同，假設有靜態配置供查找。
如果不同的應用在同一個機器上，而在不同的容器內，可以通過4種方式調用。如果在不同的機器上，只能通過機器ip與內外映射進入容器內。如果要無差別對待兩種情況，都映射機器端口來調用可以。
如果容器內被調用應用的容器要自由漂移，從同機移動到其它機器，調用方需要知道這個變化造成的ip變化，這個可以辦到。但同主機的多容器使用的宿主機volumn，共享一些主機東西，密切相關可能就破壞了。
另外，如果想調度容器，容器有可能Docker容器，但它也可能是一個rkt的容器，所以不如讓宿主機（當然物理機不行）漂移起來。這可以理解爲k8s的基本操作單元pod。
2. 多個層次的通訊
既然類似虛擬機的pod飄移起來，從一個主機到另一個主機。應用也要分組來組成同一種service。service應該是一個比較固定的概念，它包含的同類應用pod是變化的，需要一個映射關係。主機是固定的，service是數量不定比較穩定的，pod是變化的，所以每個主機上有相關的關係表。我從一個pod發起調用，從當前所在的主機上找到這個服務service的pod都在哪，按策略找到一個，連接過去。
主機、服務、pod是分屬三個層次的內容，兩層映射關係表。主機的Ip當然在主機物理網絡內了。可飄移pod之間類似虛擬機之間，自己有完善的ip來組網，畢竟真正的調用就在這層ip上，就是plannel虛擬網絡。服務ip處理兩者之間，只做數據包轉發功能，是一層特殊性質的ip。前面docker提到容器通訊，也可能有一層橋接網絡，這個如果有的話，層次最低，這裏提一下。
這三個層次關係，由kuber-proxy處理。當service給外部提供服務，要有主機與端口與service的映射關係，否則內部不用配置。
3. k8s的結構
k8s由mater與node組成，這種結構與很多軟件產品的結構相似，比如hadoop，yarn，rocketmq。一個負責總的管理，一個負責具體事物。比如總控處理Pod漂移與增減，得到新service上線，通知node，更新映射關係表。
二、從k8s到istio（一絲踢藕）（serverMesh）
istio主要功能是爲每個服務，分離出公共的調用，發現，流量控制等通用功能，服務專注於業務功能，其它交給istio。istio肯定有一個附着在應用一起的sideCar（貼身待者）。
istio的sideCar就叫Envoy，在上圖中紅色背景標識出來了。它注入到每個pod創建過程中，拉起一個容器運行Envoy，與應用在同一個pod中。一開始我受springCloud的sideCar影響，以爲Envoy與你的服務之間有調用關係。springCloud中是爲了包裝異構服務的發現，其實就是一個網關應用代理了異構服務， 7層協議調用。
後來發現了一個圖，看到了Linxu/netFilter，一查此概念，恍然大悟。
Netfilter/IPTables是Linux2.4.x之後新一代的Linux防火牆機制，是linux內核的一個子系統。Netfilter採用模塊化設計，具有良好的可擴充性。其重要工具模塊IPTables從用戶態的iptables連接到內核態的Netfilter的架構中，Netfilter與IP協議棧是無縫契合的，並允許使用者對數據報進行過濾、地址轉換、處理等操作。
這正好是4層通訊攔截，路由的地方，Envoy並不與你的應用有半毛錢的直接關係，它是給Netfilter用的。
Envoy具體特點：
- 對業務透明的請求攔截。
- 對攔截請求基於一定規則做校驗、認證、統計、流量調度、路由等。
- 將請求轉發出去，在ServiceMesh中所有的流量出入都要經過Sidecar，即由Sidecar承擔起所有的網絡通訊職責，由此可知請求轉出後的下一個接收方也必然是Sidecar。
猜測一下，比如之前K8s中一個pod調用另一個服務，要走上一層找到服務，返回對應的隨機pod，沒辦法控制流量。現在sideCar可能從k8s拿到了映射關係，並附加了自己的策略，就按配置的比例，在pannle虛擬網絡上路由數據包。
當然sideCar要接受一些控制管理監控，這些就是建一羣專門的pod服務了，沒啥特別要講的。
三、SpringCloud與k8s關係
1. 基本關係
這篇文章寫的比較清楚：https://www.cnblogs.com/assion/p/11249519.html
更詳細的可以看這個：https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/78919669
準確點說SpringCloud是適合實現微服務的一套基礎開發框架，SpringCloud有助於訊速的落地微服務架構。SpringCloud是以Java庫的形式工作所以它的工作層面是在應用層（研發層）。
k8s並不是因爲微服務而生，而是因爲docker而生，只是天時地利人和正好趕上了微服務流行的時代，docker的特性正好特別適用於微服務，而k8s進一步對docker方便的編排。它的工作層面是在容器層（運維層）
Istio開始就是與k8s結合設計的，加入了特色功能，Istio結合k8s可以牛逼的落地微服務架構。
2. 不能理解的用法
話說還看到一個把springcloud部署到k8s的例子，感覺怪怪的，一種發現套另一種發現上，一種路由套另一種路由。不知道把springcloud套在istio會怎麼樣？一種限流，熔斷套另一種限流熔斷嗎？
https://blog.csdn.net/weixin_44388301/article/details/99575907
四、istio在螞蟻的發展
網上只看到些螞蟻金服在搞istio的進一步擴展，他們的 SOFAMesh 項目，是螞蟻金服推出的 Service Mesh 開源產品，簡單的理解爲是 Istio 的落地增強版本。
http://www.uml.org.cn/wfw/201910213.asp?artid=22547
1. 重點是拓展Envoy的功能
在這個架構中，和 Istio 原版最大的不同在於沒有選擇 Istio 默認集成的 Envoy，而是用 Golang 開發了一個名爲 SOFAMosn 的 Sidecar 來替代 Envoy。爲什麼我們選擇了用 Golang 語言來實現？
我們需要考慮在 SOFAMesh 和 SOFAMosn 中增加這些通訊協議的支持，需要支持 REST 和 gRPC 之外的衆多協議，尤其是要可以讓客戶非常方便的擴展支持各種私有TCP協議。
2. 落地中遇到的典型問題和解決方案
快速的擴展支持一個新的通訊協議。
解決問題：註冊模型不匹配，原有用接口調用的代碼調不通。一般情況下 Dubbo 程序是按照 Interface 來註冊和發現，調用時也是通過 Interface 來調用。
設計了一個名爲 DNS通用選址方案 的解決方案，用來支持 Dubbo 等SOA框架，容許通過接口名來調用服務。不做 SOA 程序的微服務改造，就直接搬遷到 SOFAMesh，提前受益。
我猜測接口名是相對service的，要靠攏istio就要是ip定位，具體的實現不知道在哪，就要有一個接口與DNS對應關係。
3. 探索一下服務間通訊的範圍
然後我們將探索一下服務間通訊的範圍，看看 Service Mesh 可以在哪些領域得到應用
Service Mesh 起初關注的是東西向通訊，即系統內部各個服務之間的通訊，而這通常都是同步的，走REST或者RPC協議。
通過將 Sidecar 用於南北向通訊，重用 Sidecar 的請求轉發和服務治理功能。如服務發現，負載均衡，路由，灰度，安全，認證，加密，限流，熔斷……