istio部署-sidecar注入

參考

• fleeto/sleep
• fleeto/flaskapp

1. Sidecar注入

1.1 對工做負載的一些要求

• 支持的工做負載類型：Job，DaemonSet，ReplicaSet，Pod，Deployment 等， 對這些工做負載的要求以下：
  • 要正確命名服務端口：
    • Service 對象中的 Port 部分必須以 "協議名" 爲前綴，目前支持的協議名包括 http，http2，mongo，redis 與 grpc；
    • istio 會命名來肯定爲端口提供什麼樣的服務，不符合命名規範的端口會被當作 TCP 服務器，其功能支持範圍會大幅縮小。
  • 工做負載的 Pod 必須有關聯的 Service：
    • 爲知足服務發現的須要，全部 Pod 都必須有關聯的服務；
    • 官方建議爲 Pod 模板加入兩個標籤：app 與 version，分別標註應用名稱與版本，雖僅是個建議，但 istio 不少默認策略會引用這兩個標籤，若是沒有會引起不少沒必要要的麻煩。

1.2 手工注入

# 準備測試用 yaml 文件
cd ~
git clone https://github.com/fleeto/flaskapp.git
cd ~/flaskapp

# istioctl kube-inject 會將 istio 相關容器注入應用，"-o" 參數將注入結果生成 yaml 文件 ，方便觀察使用此命令與 "kubectl apply -f" 的區別；
# 新的 yaml 文件中多出了 "Sidecar" 容器， 而且出現了1個初始化容器 (initContainers) "istio-init" ，初始化容器即用來劫持應用通訊到 "Sidecar" 容器的工具；
# 可直接 "kubectl apply -f" 生成的 yaml 文件
istioctl kube-inject -f flask.istio.yaml -o flask.istio.injected.yaml

1.3 自動注入

1.3.1 配置自動注入

• istio 的自動注入屬性可經過 values.yaml 文件調整。

# istio-1.1.7/install/kubernetes/helm/istio/values.yaml

sidecarInjectorWebhook:
  # 開啓 "Sidecar" 自動注入特性
  enabled: true
  replicaCount: 1
  image: sidecar_injector
  # "true"：爲全部命名空間開啓自動注入功能
  # "false"：只有標籤爲 "istio-injection: enabled" 的命名空間開啓自動注入功能
  # 默認值："false"
  enableNamespacesBydefault: false
...
global:
  proxy:
    # 啓動自動注入功能後，對於指定命名空間內新建 Pod 是否進行自動注入；
    # "enabled"：命名空間內的 Pod 只要沒有被註解爲 'sidecar.istio.io/inject: "false"'，就會自動完成注入；
    # "disabled"：須要爲 Pod 註解 'sidecar.istio.io/inject: "true"'，纔會進行注入；
    # "sidecar.istio.io/inject" 沒有所謂的默認值，未註解時，取決於 "autoInject" 的設置，"enabled" 則注入，"disabled" 則不注入
    autoInject: enabled

1.3.2 測試

kubectl create ns auto
kubectl create ns manually

# 爲命名空間 auto 注入標籤
kubectl label namespaces auto istio-injection=enabled

# 在兩個命名空間建立工做負載
cd ~
git clone https://github.com/fleeto/sleep.git
cd ~/sleep
kubectl apply -f sleep.yaml -n auto
kubectl apply -f sleep.yaml -n manually

# 查看命名空間 auto 是否有自動注入
kubectl get pod -n auto
kubectl get pod -n manually

1.3.3 ConfigMap istio-sidecar-injector

1.3.3.1 ConfigMap istio-sidecar-injector

• 無論是手工注入或自動注入，均可以經過編輯 istio-system 命名空間中名爲 istio-sidecar-injector 的 ConfigMap資源，來影響注入效果；涉及兩個標籤（與 policy 同級）：

• neverInjectSelector：無論命名空間及策略如何，對符合標籤選擇器要求的 Pod 都不進行注入；

  # 如下兩個元素之間是 "或" 關係
  neverInjectSelector:
    - matchExpressions:
      - {key: openshift.io/build.name, operator: Exists}
    - matchExpressions:
      - {key: openshift.io/deployer-pod--for.name, operator: Exists}

• alwaysInjectSelector：對符合標籤選擇器要求的 Pod ，無論全局策略如何，都會被注入 Sidecar。

1.3.3.2 修改 istio-sidecar-injector

• istioctl 根據 ConfigMap 獲取注入內容，即執行 istioctl 的用戶必須可以訪問安裝了 istio 的 Kubernetes 集羣中的這個 ConfigMap ；

  # 若是因某些緣由不能訪問，能夠在 "istioctl" 中使用本地的配置文件；
  # 採用具有 "ConfigMap" 獲取權限的用戶身份執行如下命令
  kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}' > inject-config.yaml
  
  # 可對文件進行修改，並在 "istioctl" 中使用
  istioctl kube-inject --injectConfigFile inject-config.yaml

1.3.4 自動注入的優先級

• 自動注入的評估順序：
  Pod 註解（優先級最高，如 Pod 中含註解 sidecar.istio.io/inject: "true/false"，則會被優先處理） --> neverInjectSelector --> alwaysInjectSelector --> 命名空間策略。
• autoInject，命名空間，Pod 註解的關聯關係以下表：

命名空間，istio-injection=enabled	autoInject	Pod，sidecar.istio.io/inject	是否注入
是	enabled	true	是
是	enabled	false	否
是	enabled	未註解	是
是	disabled	true	是
是	disabled	false	否
是	disabled	未註解	否
否	enabled	true	否
否	enabled	false	否
否	enabled	未註解	否
否	disabled	true	否
否	disabled	false	否
否	disabled	未註解	否

1.3.5 Sidecar 注入故障排查

• 查看 sidecar-injector Pod 資源日誌；

  kubectl logs -f $(kubectl get pods -n istio-system -l istio=sidecar-injector -o jsonpath='{.items[0].metadata.name}') -n istio-system

• 建立業務 Pod ，查看日誌輸出；
• 更詳細的日誌，能夠編輯 sidecar-injector Deployment對象，爲其添加 args 參數 --log_output_level=default:debug；

• 若是在 sidecar-injector Pod 資源日誌仍是未找到發生問題的緣由，則表明 sidecar-injector 沒有收到 Pod 建立的通知，也就不會觸發自動注入操做，這多是由於命名空間沒有正確設置標籤致使的，須要檢查命名空間的標籤及 MutatingWebhookConfiguration 中的配置：

  # 命名空間默認設置 "istio-injection=anabled" 標籤；
  # 能夠檢查其中的 "namespaceSelector" 字段與內容
  kubectl edit MutatingWebhookConfiguration istio-sidecar-injector -n istio-system