揭开 Istio Sidecar 注入模型的神秘面纱

揭秘 Istio 是如何将其数据平面组件添加到现有 deployment。

Jan 31, 2019 | By Manish Chugtu

Istio 服务网格体系结构的简单概述总是从控制平面和数据平面开始。

从 Istio 的文档 :

基于 Istio 的应用程序的总体架构。
Istio Architecture

重要的是要理解向应用程序 pod 中注入边车是自动进行的，尽管也可以手动注入。流量从应用服务流向 sidecar，而开发人员无需关心它。一旦将应用程序连接到 Istio 服务网格，开发者便可以开始使用并获得服务网格中的所有效益。但是，数据平面管道是如何发生的，以及无缝迁移工作的真正要求是什么？在本文中，我们将深入研究 Sidecar 注入模型的细节，以非常清楚地理解 Sidecar 注入的工作原理。

Sidecar 注入

简单来说，Sidecar 注入会将额外容器的配置添加到 Pod 模板中。Istio 服务网格目前所需的容器有：

istio-init init 容器用于设置 iptables 规则，以便将入站/出站流量通过 sidecar 代理。初始化容器与应用程序容器在以下方面有所不同：

因此，您可以看到，对于不需要成为实际应用容器一部分的设置或初始化作业来说，这种容器是多么的完美。在这种情况下，istio-init 就是这样做并设置了 iptables 规则。

istio-proxy 这个容器是真正的 sidecar 代理（基于 Envoy）。

手动注入

在手动注入方法中，可以使用 istioctl 修改容器模板并添加前面提到的两个容器的配置。不论是手动注入还是自动注入，Istio 都从 istio-sidecar-injector 和的 istio 两个 Configmap 对象中获取配置。

我们先来看看 istio-sidecar-injector Configmap 的配置，了解一下其中的内容。

$ kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}'

以下代码片段来自 output：

policy: enabled
template: |-
  initContainers:
  - name: istio-init
    image: docker.io/istio/proxy_init:1.0.2
    args:
    - "-p"
    - [[ .MeshConfig.ProxyListenPort ]]
    - "-u"
    - 1337
    .....
    imagePullPolicy: IfNotPresent
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
    restartPolicy: Always

  containers:
  - name: istio-proxy
    image: [[ if (isset .ObjectMeta.Annotations "sidecar.istio.io/proxyImage") -]]
    "[[ index .ObjectMeta.Annotations "sidecar.istio.io/proxyImage" ]]"
    [[ else -]]
    docker.io/istio/proxyv2:1.0.2
    [[ end -]]
    args:
    - proxy
    - sidecar
    .....
    env:
    .....
    - name: ISTIO_META_INTERCEPTION_MODE
      value: [[ or (index .ObjectMeta.Annotations "sidecar.istio.io/interceptionMode") .ProxyConfig.InterceptionMode.String ]]
    imagePullPolicy: IfNotPresent
    securityContext:
      readOnlyRootFilesystem: true
      [[ if eq (or (index .ObjectMeta.Annotations "sidecar.istio.io/interceptionMode") .ProxyConfig.InterceptionMode.String) "TPROXY" -]]
      capabilities:
        add:
        - NET_ADMIN
    restartPolicy: Always
    .....

如您所见，configmap 包含了 istio-init 初始化容器和 istio-proxy 代理容器的配置。该配置包括容器镜像的名称以及拦截模式，权限要求等参数。

从安全的角度来看，重要的是要注意 istio-init 需要 NET_ADMIN 权限来修改 pod 命名空间中的 iptables，如果 istio-proxy 是 TPROXY 模式，也需要这一权限。由于该仅限于 pod 的命名空间，因此应该没有问题。但是，我们注意到最近的 open-shift 版本可能会出现一些问题，因此需要一种解决方法。本文结尾处提到了一个这样的选择。

要修改当前的 Pod 模板以进行 sidecar 注入，您可以：

$ istioctl kube-inject -f demo-red.yaml | kubectl apply -f -

或者

要使用修改后的 Configmap 或本地 Configmap：

如上所示，我们使用 sidecar-injector 和网格配置创建了一个新模板，然后使用 kubectl 应用该新模板。如果我们查看注入后的 YAML 文件，它具有 Istio 特定容器的配置，如上所述。一旦我们应用注入后的 YAML 文件，我们将看到两个容器正在运行。其中一个是实际的应用程序容器，另一个是 istio-proxy sidecar。

$ kubectl get pods | grep demo-red

demo-red-pod-8b5df99cc-pgnl7   2/2       Running   0          3d

这里没有 3 个 Pod，因为 istio-init 容器是一个 init 类型的容器，它在完成应做的操作后退出，其用于在 pod 中设置 iptable 规则。为了确认 init 容器已退出，让我们看一下 kubectl describe 的输出：

$ kubectl describe pod demo-red-pod-8b5df99cc-pgnl7

以下代码片段来自 output：

Name:               demo-red-pod-8b5df99cc-pgnl7
Namespace:          default
.....
Labels:             app=demo-red
                    pod-template-hash=8b5df99cc
                    version=version-red
Annotations:        sidecar.istio.io/status={"version":"3c0b8d11844e85232bc77ad85365487638ee3134c91edda28def191c086dc23e","initContainers":["istio-init"],"containers":["istio-proxy"],"volumes":["istio-envoy","istio-certs...
Status:             Running
IP:                 10.32.0.6
Controlled By:      ReplicaSet/demo-red-pod-8b5df99cc
Init Containers:
  istio-init:
    Container ID:  docker://bef731eae1eb3b6c9d926cacb497bb39a7d9796db49cd14a63014fc1a177d95b
    Image:         docker.io/istio/proxy_init:1.0.2
    Image ID:      docker-pullable://docker.io/istio/proxy_init@sha256:e16a0746f46cd45a9f63c27b9e09daff5432e33a2d80c8cc0956d7d63e2f9185
    .....
    State:          Terminated
      Reason:       Completed
    .....
    Ready:          True
Containers:
  demo-red:
    Container ID:   docker://8cd9957955ff7e534376eb6f28b56462099af6dfb8b9bc37aaf06e516175495e
    Image:          chugtum/blue-green-image:v3
    Image ID:       docker-pullable://docker.io/chugtum/blue-green-image@sha256:274756dbc215a6b2bd089c10de24fcece296f4c940067ac1a9b4aea67cf815db
    State:          Running
      Started:      Sun, 09 Dec 2018 18:12:31 -0800
    Ready:          True
  istio-proxy:
    Container ID:  docker://ca5d690be8cd6557419cc19ec4e76163c14aed2336eaad7ebf17dd46ca188b4a
    Image:         docker.io/istio/proxyv2:1.0.2
    Image ID:      docker-pullable://docker.io/istio/proxyv2@sha256:54e206530ba6ca9b3820254454e01b7592e9f986d27a5640b6c03704b3b68332
    Args:
      proxy
      sidecar
      .....
    State:          Running
      Started:      Sun, 09 Dec 2018 18:12:31 -0800
    Ready:          True
    .....

从输出中可以看出，istio-init 容器的 State 为 Terminated，而 Reason 是 Completed。只有两个容器是运行的，主应用程序 demo-red 容器和 istio-proxy 容器。

自动注入

在大多数情况下，您不想在每次部署应用程序时都使用 istioctl 命令手动注入边车，而是希望 Istio 自动将 sidecar 注入到您的 pod 中。这是推荐的方法，要使自动注入生效，您只需要用 istio-injection=enabled 标记想部署应用程序的命名空间。

贴上标签后，Istio 会自动为您在该命名空间中部署的所有 pod 注入 sidecar。下面的例子里，istio-dev 命名空间中部署的 pod 被自动注入了 sidecar：

$ kubectl get namespaces --show-labels

NAME           STATUS    AGE       LABELS
default        Active    40d       <none>
istio-dev      Active    19d       istio-injection=enabled
istio-system   Active    24d       <none>
kube-public    Active    40d       <none>
kube-system    Active    40d       <none>

但它是如何工作的呢？要深入了解这一点，我们需要理解 Kubernetes 准入控制器。

来自 Kubernetes 文档：

对于 sidecar 自动注入，Istio 依赖于 Mutating Admission Webhook。让我们来看看 istio-sidecar-injector 中的配置详情。

$ kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml

以下代码片段来自 output：

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"admissionregistration.k8s.io/v1beta1","kind":"MutatingWebhookConfiguration","metadata":{"annotations":{},"labels":{"app":"istio-sidecar-injector","chart":"sidecarInjectorWebhook-1.0.1","heritage":"Tiller","release":"istio-remote"},"name":"istio-sidecar-injector","namespace":""},"webhooks":[{"clientConfig":{"caBundle":"","service":{"name":"istio-sidecar-injector","namespace":"istio-system","path":"/inject"}},"failurePolicy":"Fail","name":"sidecar-injector.istio.io","namespaceSelector":{"matchLabels":{"istio-injection":"enabled"}},"rules":[{"apiGroups":[""],"apiVersions":["v1"],"operations":["CREATE"],"resources":["pods"]}]}]}
  creationTimestamp: 2018-12-10T08:40:15Z
  generation: 2
  labels:
    app: istio-sidecar-injector
    chart: sidecarInjectorWebhook-1.0.1
    heritage: Tiller
    release: istio-remote
  name: istio-sidecar-injector
  .....
webhooks:
- clientConfig:
    service:
      name: istio-sidecar-injector
      namespace: istio-system
      path: /inject
  name: sidecar-injector.istio.io
  namespaceSelector:
    matchLabels:
      istio-injection: enabled
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods

在这里，您可以看到与标签 istio-injection:enabled 相匹配的 webhook namespaceSelector 标签。在这种情况下，您还会看到在创建容器时要完成的操作和资源。当 apiserver 接收到与其中一个规则匹配的请求时，apiserver 会根据 clientconfig 配置中指定的 name: istio-sidecar-injector 键值对，向 webhook 服务发送准入审查请求。我们应该能够看到该服务正在 istio-system 命名空间中运行。

$ kubectl get svc --namespace=istio-system | grep sidecar-injector

istio-sidecar-injector   ClusterIP   10.102.70.184   <none>        443/TCP             24d

最终，该配置与手动注入中的配置几乎相同。只是它是在 pod 创建过程中自动完成的，因此您不会看到部署中的更改。您需要使用 kubectl describe 来查看 sidecar 代理和 init 代理。

sidecar 自动注入不仅取决于 webhook 的 namespaceSelector 机制，还取决于默认注入策略和每个 pod 自身注解。

如果你再次查看 istio-sidecar-injector ConfigMap，它将定义默认的注入策略。在这个示例中，它是默认启用的。

$ kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}'

以下代码片段来自 output：

policy: enabled
template: |-
  initContainers:
  - name: istio-init
    image: "gcr.io/istio-release/proxy_init:1.0.2"
    args:
    - "-p"
    - [[ .MeshConfig.ProxyListenPort ]]

您还可以在 pod 模板中使用注解 sidecar.istio.io/inject 覆盖默认策略。以下示例展示如何为 Deployment 中的 pod 禁用 sidecar 自动注入。

apiVersion: extensions/v1beta1
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"]

此示例显示了许多变量，这取决于是否在命名空间、ConfigMap 和 pod 中控制 sidecar 自动注入，它们是：

注入状态表根据上述变量的值清晰显示了最终注入状态。

从应用容器到 Sidecar 代理的流量

既然我们已经清楚了如何将 sidecar 容器和 init 容器注入到应用清单中，那么 sidecar 代理如何捕获容器之间的入站和出站流量？我们曾简要提到过，这是通过在 pod 命名空间中设置 iptable 规则来完成的，而规则又是由 istio-init 容器完成的。现在，是时候验证命名空间中实际更新的内容了。

让我们进入上一节中部署的应用程序 pod 命名空间，并查看已配置的 iptables。我们将展示一个使用 nsenter 的例子。或者，您也可以通过特权模式进入容器并查看相同的信息。对于无法访问节点的人来说，使用 exec 进入 sidecar 并运行 iptables 更实用。

$ docker inspect b8de099d3510 --format '{{ .State.Pid }}'

4125

$ nsenter -t 4215 -n iptables -t nat -S

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N ISTIO_INBOUND
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_INBOUND -p tcp -m tcp --dport 80 -j ISTIO_IN_REDIRECT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001

上面的输出清楚地表明，端口 80 的所有入站流量（即我们的 red-demo 应用正在监听的端口）现在已被 REDIRECTED 到端口 15001，即 istio-proxy 的端口，一个 Envoy 代理正在监听的端口。对于出站流量也是如此。

本文已经快结束了。我们希望本文有助于您弄清 Istio 是如何将 Sidecar 代理注入到现有部署中以及 Istio 是如何将流量路由到代理。