Istio中sidecar的注入規范及示例 · kubernetes完整攻略

# Istio 中 sidecar 的注入及示例 **注意：本文檔已失效，請瀏覽 [Istio 官方文檔](https://istio.io/zh)。本書中的 Service Mesh 章節已不再維護，請轉到 [istio-handbook](https://jimmysong.io/istio-handbook) 中瀏覽。** 我們知道 Istio 通過向 Pod 中注入一個 sidecar 容器來將 Pod 納入到 Istio service mesh 中的，那么這些 sidecar 容器的注入遵循什么樣的規范，需要給每個 Pod 增加哪些配置信息才能納入 Istio service mesh 中呢？這篇文章將給您答案。 ## Pod Spec 中需滿足的條件為了成為 Service Mesh 中的一部分，kubernetes 集群中的每個 Pod 都必須滿足如下條件，這些規范不是由 Istio 自動注入的，而需要生成 kubernetes 應用部署的 YAML 文件時需要遵守的： 1. **Service 關聯**：每個 pod 都必須只屬于某**一個** [Kubernetes Service](https://kubernetes.io/docs/concepts/services-networking/service/) （當前不支持一個 pod 同時屬于多個 service）。 2. **命名的端口**：Service 的端口必須命名。端口的名字必須遵循如下格式 `<protocol>[-<suffix>]`，可以是 `http`、`http2`、 `grpc`、 `mongo`、或者 `redis` 作為 `<protocol>` ，這樣才能使用 Istio 的路由功能。例如 `name: http2-foo` 和 `name: http` 都是有效的端口名稱，而 `name: http2foo` 不是。如果端口的名稱是不可識別的前綴或者未命名，那么該端口上的流量就會作為普通的 TCP 流量來處理（除非使用 `Protocol: UDP` 明確聲明使用 UDP 端口）。 3. **帶有 app label 的 Deployment**：我們建議 kubernetes 的`Deploymenet` 資源的配置文件中為 Pod 明確指定 `app`label。每個 Deployment 的配置中都需要有個與其他 Deployment 不同的含有意義的 `app` label。`app` label 用于在分布式追蹤中添加上下文信息。 4. **Mesh 中的每個 pod 里都有一個 Sidecar**：最后，Mesh 中的每個 pod 都必須運行與 Istio 兼容的 sidecar。以下部分介紹了將 sidecar 注入到 pod 中的兩種方法：使用`istioctl` 命令行工具手動注入，或者使用 Istio Initializer 自動注入。注意 sidecar 不涉及到流量，因為它們與容器位于同一個 pod 中。 ## 將普通應用添加到 Istio service mesh 中 Istio官方的示例[Bookinfo](https://istio.io/docs/guides/bookinfo.html)中并沒有講解如何將服務集成 Istio，只給出了 YAML 配置文件，而其中需要注意哪些地方都沒有說明，假如我們自己部署的服務如何使用 Istio 呢？現在我們有如下兩個普通應用（代碼在 GitHub 上），它們都不具備微服務的高級特性，比如限流和熔斷等，通過將它們部署到 kubernetes 并使用 Istio 來管理： - [k8s-app-monitor-test](https://github.com/rootsongjc/k8s-app-monitor-test)：用來暴露 json 格式的 metrics - [k8s-app-monitor-agent](https://github.com/rootsongjc/k8s-app-monitor-agent)：訪問上面那個應用暴露的 metrics 并生成監控圖這兩個應用的 YAML 配置如下，其中包含了 Istio ingress 配置，并且符合 Istio 對 Pod 的 spec 配置所指定的規范。 **k8s-app-monitor-istio-all-in-one.yaml文件** ```yaml apiVersion: extensions/v1beta1 kind: Deployment metadata: annotations: kompose.cmd: kompose convert -f docker-compose.yaml kompose.version: 1.10.0 () creationTimestamp: null labels: app: k8s-app-monitor-agent name: k8s-app-monitor-agent spec: replicas: 1 template: metadata: creationTimestamp: null labels: app: k8s-app-monitor-agent spec: containers: - env: - name: SERVICE_NAME value: k8s-app-monitor-test image: jimmysong/k8s-app-monitor-agent:749f547 name: monitor-agent ports: - containerPort: 8888 restartPolicy: Always --- apiVersion: v1 kind: Service metadata: annotations: kompose.cmd: kompose convert -f docker-compose.yaml kompose.version: 1.10.0 () creationTimestamp: null labels: app: k8s-app-monitor-agent name: k8s-app-monitor-agent spec: ports: - name: "http" port: 8888 targetPort: 8888 selector: app: k8s-app-monitor-agent --- apiVersion: extensions/v1beta1 kind: Deployment metadata: annotations: kompose.cmd: kompose convert -f docker-compose.yaml kompose.version: 1.10.0 () creationTimestamp: null labels: app: k8s-app-monitor-test name: k8s-app-monitor-test spec: replicas: 1 template: metadata: creationTimestamp: null labels: app: k8s-app-monitor-test spec: containers: - image: jimmysong/k8s-app-monitor-test:9c935dd name: monitor-test ports: - containerPort: 3000 restartPolicy: Always --- apiVersion: v1 kind: Service metadata: annotations: kompose.cmd: kompose convert -f docker-compose.yaml kompose.version: 1.10.0 () creationTimestamp: null labels: app: k8s-app-monitor-test name: k8s-app-monitor-test spec: ports: - name: "http" port: 3000 targetPort: 3000 selector: app: k8s-app-monitor-test --- ## Istio ingress apiVersion: extensions/v1beta1 kind: Ingress metadata: name: k8s-app-monitor-agent-ingress annotations: kubernetes.io/ingress.class: "istio" spec: rules: - http: paths: - path: /k8s-app-monitor-agent backend: serviceName: k8s-app-monitor-agent servicePort: 8888 ``` 其中有兩點配置需要注意。 - `Deployment` 和 `Service` 中的 label 名字必須包含 `app`，zipkin 中的 tracing 需要使用到這個標簽才能追蹤 - `Service` 中的 `ports` 配置和必須包含一個名為 `http` 的 port，這樣在 Istio ingress 中才能暴露該服務 **注意**：該 YAML 文件中 `annotations` 是因為我們一開始使用 `docker-compose` 部署在本地開發測試，后來再使用 [kompose](https://github.com/kubernetes/kompose) 將其轉換為 kubernetes 可識別的 YAML 文件。然后執行下面的命令就可以基于以上的 YAML 文件注入 sidecar 配置并部署到 kubernetes 集群中。 ```bash kubectl apply -n default -f <(istioctl kube-inject -f manifests/istio/k8s-app-monitor-istio-all-in-one.yaml) ``` 如何在本地啟動 kubernetes 集群進行測試可以參考 [kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster) 中的說明。 ## Sidecar 注入說明手動注入需要修改控制器的配置文件，如 deployment。通過修改 deployment 文件中的 pod 模板規范可實現該deployment 下創建的所有 pod 都注入 sidecar。添加/更新/刪除 sidecar 需要修改整個 deployment。自動注入會在 pod 創建的時候注入 sidecar，無需更改控制器資源。Sidecar 可通過以下方式更新： - 選擇性地手動刪除 pod - 系統得進行 deployment 滾動更新手動或者自動注入都使用同樣的模板配置。自動注入會從 `istio-system` 命名空間下獲取 `istio-inject` 的 ConfigMap。手動注入可以通過本地文件或者 Configmap 。 ## 參考 - [Installing Istio Sidecar](https://istio.io/docs/setup/kubernetes/sidecar-injection.html)