设置 Sidecar

分手后的思念是犯贱 2023-01-17 03:17 129阅读 0赞

### 注入 Sidecar ###

为了充分利用 Istio 的所有特性，网格中的 pod 必须运行一个 Istio sidecar 代理。

向 Pod 中注入 Istio sidecar 的两种方法：使用 istioctl 手动注入或启用 Pod 所属命名空间的 Istio sidecar 注入器自动注入。

手动注入直接修改配置，如 Deployment，并将代理配置注入其中。

当 Pod 所属的命名空间启用自动注入后，自动注入器会使用准入控制器在创建 Pod 时自动注入代理配置。通过应用 `istio-sidecar-injector` ConfigMap 中定义的模版进行注入。

*  下载 istio：

curl -L https://istio.io/downloadIstio | sh -
    
    cd istio-1.9.0
    
    export PATH=$PWD/bin:$PATH              #将 istioctl 加入环境变量

然后需要通过 helm 部署好 istio，此处省略。

*  手动注入 sidecar：

要手动注入 deployment，请使用 `istioctl kube-inject`：

istioctl kube-inject -f samples/sleep/sleep.yaml | kubectl apply -f -

默认情况下将使用集群内的配置，或者使用该配置的本地副本来完成注入。

kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}' > inject-config.yaml
    
    kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.values}' > inject-values.yaml
    
    kubectl -n istio-system get configmap istio -o=jsonpath='{.data.mesh}' > mesh-config.yaml

指定输入文件，运行 `kube-inject` 并部署。

istioctl kube-inject \
      --injectConfigFile inject-config.yaml \
      --meshConfigFile mesh-config.yaml \
      --valuesFile inject-values.yaml \
      --filename samples/sleep/sleep.yaml \
      | kubectl apply -f -

验证 sidecar 已经被注入到 READY 列下 2/2 的 sleep pod 中。

kubectl get pod -l app=sleep
    
    NAME                     READY   STATUS    RESTARTS   AGE
    sleep-64c6f57bc8-f5n4x   2/2     Running   0          24s

*  自动注入 sidecar：

使用 Istio 提供的准入控制器变更 webhook，可以将 sidecar 自动添加到可用的 Kubernetes Pod 中。

当在一个命名空间中设置了 `istio-injection=enabled` 标签，且 injection webhook 被启用后，任何新的 Pod 都有将在创建时自动添加 sidecar。

请注意，区别于手动注入，自动注入发生在 Pod 层面，Deployment 本身将看不到有任何更改。取而代之，需要检查单独的 Pod（使用 `kubectl describe`）来查询被注入的代理。

*  禁用或更新注入 webhook：

Sidecar 注入 webhook 是默认启用的。如果希望禁用 webhook，可以使用 Helm 将 `sidecarInjectorWebhook.enabled` 设置为 `false`。

--------------------

### 部署应用 ###

*  部署 sleep 应用：

验证 Deployment 和 Pod 只有一个容器。

kubectl apply -f samples/sleep/sleep.yaml
    
    kubectl get deploy -o wide
    
    NAME    READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES            SELECTOR
    sleep   1/1     1            1           67s   sleep        curlimages/curl   app=sleep
    
    kubectl get pod
    
    NAME                     READY   STATUS    RESTARTS   AGE
    sleep-64d7d56698-lwsjh   1/1     Running   0          2m29s

*  给 namespace 打上标签：

将 default namespace 标记为 `istio-injection=enabled`。

kubectl label namespace default istio-injection=enabled
    
    kubectl get namespaces -L istio-injection
    
    NAME              STATUS   AGE    ISTIO-INJECTION
    default           Active   194d   enabled
    ingress-nginx     Active   194d   
    istio-system      Active   20h    
    kube-node-lease   Active   194d   
    kube-public       Active   194d   
    kube-system       Active   194d

注入发生在 Pod 创建时。杀死正在运行的 Pod 并验证新创建的 Pod 是否注入 sidecar。原来的 Pod 具有 READY 为 1/1 的容器，注入 sidecar 后的 Pod 则具有 READY 为 2/2 的容器。

kubectl get pod -l app=sleep
    
    NAME                     READY   STATUS    RESTARTS   AGE
    sleep-64d7d56698-27mbt   2/2     Running   0          2m14s

查看已注入 Pod 的详细状态。可以看到被注入的 istio-proxy 容器和对应的卷。

kubectl describe pod -l app=sleep

禁用 default namespace 注入，并确认新的 pod 在创建时没有 sidecar。

kubectl label namespace default istio-injection-
    
    kubectl delete pod -l app=sleep
    
    kubectl get pod
    
    NAME                     READY   STATUS    RESTARTS   AGE
    sleep-64d7d56698-xcr8l   1/1     Running   0          7s

--------------------

### 理解原理 ###

当 Kubernetes 调用 webhook 时，`admissionregistration` 配置被应用。默认配置将 sidecar 注入到所有拥有 `istio-injection=enabled` 标签的 namespace 下的 Pod 中。`istio-sidecar-injector` 配置字典指定了注入 sidecar 的配置。如需更改指定哪些 namespace 被注入，可以使用以下命令编辑 `MutatingWebhookConfiguration`：

kubectl edit mutatingwebhookconfiguration istio-sidecar-injector

> 修改 `MutatingWebhookConfiguration` 之后，应该重启 sidecar 注入器的 Pod。

*  策略：

`disabled` \- 默认情况下不会将 sidecar 注入到 Pod 中。在 Pod 模板规范中添加 `sidecar.istio.io/inject` 的值为 `true` 来覆盖默认值并启用注入。

`enabled` \- sidecar 将默认注入到 Pod 中。在 Pod 模板规范中添加 `sidecar.istio.io/inject` 的值为 `false` 来覆盖默认值并禁用注入。

下面的示例使用 `sidecar.istio.io/inject` 注解来禁用 sidecar 注入。

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ignored
    spec:
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
        spec:
          containers:
          - name: ignored
            image: tutum/curl
            command: ["/bin/sleep","infinity"]

*  模板：

Sidecar 注入模板使用 `https://golang.org/pkg/text/template`，当解析和执行时，将解码成下面的结构体，包含需要注入到 Pod 中的容器和卷。

type SidecarInjectionSpec struct { 
          RewriteAppHTTPProbe bool                          `yaml:"rewriteAppHTTPProbe"`
          InitContainers      []corev1.Container            `yaml:"initContainers"`
          Containers          []corev1.Container            `yaml:"containers"`
          Volumes             []corev1.Volume               `yaml:"volumes"`
          DNSConfig           *corev1.PodDNSConfig          `yaml:"dnsConfig"`
          ImagePullSecrets    []corev1.LocalObjectReference `yaml:"imagePullSecrets"`
    }

该模板在运行时应用于以下数据结构。

type SidecarTemplateData struct { 
        DeploymentMeta *metav1.ObjectMeta
        ObjectMeta     *metav1.ObjectMeta
        Spec           *corev1.PodSpec
        ProxyConfig    *meshconfig.ProxyConfig  // Defined by https://istio.io/docs/reference/config/service-mesh.html#proxyconfig
        MeshConfig     *meshconfig.MeshConfig   // Defined by https://istio.io/docs/reference/config/service-mesh.html#meshconfig
    }

`ObjectMeta` 和 `Spec` 来源于 Pod。`ProxyConfig` 和 `MeshConfig` 来源于 `istio-system` namespace 下 istio 的 ConfigMap。模版可以使用这些数据有条件地定义被注入的卷和容器。

例如下面的模版。

containers:
    - name: istio-proxy
      image: istio.io/proxy:0.5.0
      args:
      - proxy
      - sidecar
      - --configPath
      - { {  .ProxyConfig.ConfigPath }}
      - --binaryPath
      - { {  .ProxyConfig.BinaryPath }}
      - --serviceCluster
      { {  if ne "" (index .ObjectMeta.Labels "app") -}}
      - { {  index .ObjectMeta.Labels "app" }}
      { {  else -}}
      - "istio-proxy"
      { {  end -}}

将在使用模版 `samples/sleep/sleep.yaml` 定义的 Pod 被应用时变为

containers:
    - name: istio-proxy
      image: istio.io/proxy:0.5.0
      args:
      - proxy
      - sidecar
      - --configPath
      - /etc/istio/proxy
      - --binaryPath
      - /usr/local/bin/envoy
      - --serviceCluster
      - sleep

--------------------

### 对于例外 ###

有些情况下用户无法控制 Pod 的创建，例如，这些用户是被其他人创建的。因此他们无法在 Pod 中添加 `sidecar.istio.io/inject` 注解，来明确是否安装 sidecar。

考虑在部署应用程序时创建辅助 Pod 作为中间步骤。例如 OpenShift Source to Image Builds，创建这样的 Pod 用于构建应用程序的源代码。构建二进制工件后，应用程序 Pod 就可以运行了，而用于辅助的 Pod 则被丢弃。这些中间 Pod 不应该有 Istio sidecar，即使策略被设置为 `enabled`，并且名称空间被正确标记为自动注入。

对于这种情况，可以根据 Pod 上的标签，指示 Istio 不要在那些 Pod 中注入 sidecar。可以通过编辑 `istio-sidecar-injector` 的 ConfigMap 并添加 `neverInjectSelector` 条目来实现。它是一个 Kubernetes 标签选择器数组，使用 `OR'd`，在第一次匹配成功后则停止。看一个例子：

apiVersion: v1
    kind: ConfigMap
    metadata:
      name: istio-sidecar-injector
    data:
      config: |-
        policy: enabled
        neverInjectSelector:
          - matchExpressions:
            - { key: openshift.io/build.name, operator: Exists}
          - matchExpressions:
            - { key: openshift.io/deployer-pod-for.name, operator: Exists}
        template: |-
          initContainers:
    ...

上面声明的意思是：永远不要注入带有 `openshift.io/build.name` 或者 `openshift.io/deployer-pod-for.name` 标签的 Pod —— 标签的值无关紧要，只检查键是否存在。添加了这个规则之后，就涵盖了上面所说的 OpenShift 的构建用例，也就是说辅助 Pod 不会被注入 sidecar（因为 source-to-image 工具产生的辅助 Pod 明确包含这些标签）。

完整起见，还可以使用一个名为 `alwaysInjectSelector` 的字段，它具有类似的语法，总是将 sidecar 注入匹配标签选择器的 Pod 中，而忽略全局策略。

值得注意的是，Pod 中的注解具有比标签选择器更高的优先级。如果一个 Pod 有 `sidecar.istio.io/inject: "true/false"` 的标记那么它将先被履行。因此，优先级的顺序为:

> Pod Annotations → NeverInjectSelector → AlwaysInjectSelector → Default Policy

--------------------

### 卸载 sidecar 自动注入器 ###

kubectl delete mutatingwebhookconfiguration istio-sidecar-injector
    
    kubectl delete svc -n istio-system istio-sidecar-injector
    
    kubectl delete deploy -n istio-system istio-sidecar-injector
    
    kubectl delete sa -n istio-system istio-sidecar-injector-service-account
    
    kubectl delete clusterrole istio-sidecar-injector-istio-system
    
    kubectl delete clusterrolebinding istio-sidecar-injector-admin-role-binding-istio-system

上面的命令不会从 Pod 中移除注入的 sidecar。需要进行滚动更新或者直接删除 Pod，并强制 Deployment 创建它们。

同时给 namespace 去掉自动注入的标签：

kubectl label namespace default istio-injection-

--------------------