Istio 尾行記
Istio 一直沒有什麼像樣的更新，Conduit 也遲遲不出來懟，眼看 2017 就要過去，安裝試用也不新鮮了，補一篇 Istio 的筆記，算做個收尾了。
Istio 最大的亮點之一，就是使用 Pilot 將集群控制語言翻譯成為 Envoy 配置，利用 Sidecar 的方式對服務通信進行控制，下面就是對這一過程的跟蹤嘗試。
會看到，這裡生成了相當多的內容，除去 Deployment、Service 和 ConfigMap 老幾樣之外，還有當前集群必須的 RBAC 幾要素：Service Account、ClusterRole 以及 ClusterRoleBinding。然後就是 Kubernetes 世界裡強力擴展的標誌：各種 CRD(CustomResourceDefinition) 了。
這裡會生成一系列的監控用具，包括了 Prometheus、Grafana、ZipKin 以及 ServiceGraph，原則上這些並非必須組件。不過為了監控方便，一般還是會加上。
另外這裡的 Prometheus 以及 Grafana 的監控、儀錶盤配置都可以保存下來，方便同現有設施進行融合。
運行這個命令之前，務必注意幾個對 Workload 的要求：
目前，Pod 對應單一服務的情況才能得到支持。
在安裝好 Istio 之後，一般會使用這一命令對服務進行注入（同樣也有自動注入的能力），使之稱為被 istio 加持的 Service Mesh 成員服務。注入之後的 YAML 會變得比較豐腴：
下面分別講解一下多出來的這些部分：
Annotation
為 Deployment 和 Pod 加入了同樣的註解：
，目前理解是，標註了這一部署和 Pod 是否已經被注入，被什麼版本注入。
Init 1
使用 Alpine 鏡像，設置內核 Dump 模板，以及 ulimit。
Init 2
使用 進行初始化，參數為
Sidecar
鏡像為： docker.io/istio/proxy_debug:0.4.0
其中定義了大量的服務關係，包括：
運行
利用 ，將注入後的 yaml 文件運行起來，接下來就可以使用各個 Pod 來查看剛才注入的內容的行跡了。
列出 Pod：
通過前面的 yaml 定義，我們知道這個 Pod 的兩個容器分別是 和 ，Istio 強調的是 Sidecar 模式的無侵入管理，因此我們可以認為是沒有變化的，Service Mesh 的 Sidecar 功能會體現在這一容器中。
初始化
上一節中提到了，使用進行的初始化（Alpine 部分修改內核參數，就不用多說了），我們可以進入源碼，查查他的初始化做了什麼。
Dockerfile 中我們看到，這一容器的入口命令為，找出這個文件，會看到其中使用這兩個參數對 iptables 的 nat 部分做了配置，另外還可以看到，其中加入了 iptables 命令，這裡我們可以進行驗證：，輸出內容可以這樣解讀：
和腳本初始化內容一致。
istio-proxy
啟動之後，我們可以使用進入 Proxy 容器，執行命令，會發現有兩個正在運行的進程：
並且 Envoy 的父進程就是這個 pilot-agent。其運行參數和我們前面注入到 YAML 中的參數一致。
另外還可以查看 下面的配置文件，可以看出：
驗證路由規則
執行
可以看到 httpbin 的路由如下：
新建預設路由：
再次查詢路由，可以看到其中發生了變化：
cluster
可以看到所有對應的服務信息，以及可能存在的斷路器信息。
TAG:偽架構師 |