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 注解的關聯關系如下表：

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
  

標籤：其他

上一篇：kubeadm配置高可用etcd集群

下一篇：分享資源-地震資料挖掘分析系統（云計算處理、智能挖掘技術）