Sidecar Injector自动注入的原理 –《云原生服务网格Istio》书摘04

本节书摘来自华为云原生技术丛书《云原生服务网格Istio:原理,实践,架构与源码解析》一书原理篇的第6章透明的Sidecar机制,6.1.1小节Sidecar Injector自动注入的原理。更多内容参照原书,或者关注容器魔方公众号。

Sidecar注入

我们都知道,Istio的流量管理、策略、遥测等功能无须应用程序做任何改动,这种无侵入式的方式全部依赖于Sidecar。应用程序发送或者接收的流量都被Sidecar拦截,并由Sidecar进行认证、鉴权、策略执行及遥测数据上报等众多治理功能。

如图6-1所示,在Kubernetes中,Sidecar容器与应用容器共存于同一个Pod中,并且共享同一个Network Namespaces,因此Sidecar容器与应用容器共享同一个网络协议栈,这也是Sidecar能够通过iptables拦截应用进出口流量的根本原因。

 istio-sidecar-injection-of-cloudnativeistio-04-01

图6-1  Istio的Sidecar模式

在Istio中进行Sidecar注入有两种方式:一种是通过istioctl命令行工具手动注入;另一种是通Istio Sidecar Injector自动注入。

这两种方式的最终目的都是在应用Pod中注入init容器及istio-proxy容器这两个Sidecar容器。如下所示,通过部署Istio的sleep应用,Sidecar是通过sidecar-injector自动注入的,查看注入的Sidecar容器:

(1)istio-proxy 容器:

(2)istio-init容器:

Sidecar Injector自动注入的原理

Sidecar Injector是Istio中实现自动注入Sidecar的组件,它是以Kubernetes准入控制器Admission Controller的形式运行的。Admission Controller的基本工作原理是拦截Kube-apiserver的请求,在对象持久化之前、认证鉴权之后进行拦截。Admission Controller有两种:一种是内置的,另一种是用户自定义的。Kubernetes允许用户以Webhook的方式自定义准入控制器,Sidecar Injector就是这样一种特殊的MutatingAdmissionWebhook。

如图6-2所示,Sidecar Injector只在创建Pod时进行Sidecar容器注入,在Pod的创建请求到达Kube-apiserver后,首先进行认证鉴权,然后在准入控制阶段,Kube-apiserver以REST的方式同步调用Sidecar Injector Webhook服务进行init与istio-proxy容器的注入,最后将Pod对象持久化存储到etcd中。

 istio-sidecar-injection-of-cloudnativeistio-04-02

图6-2  Sidecar Injector的工作原理

Sidecar Injector可以通过MutatingWebhookConfiguration API动态配置生效,Istio中的MutatingWebhook配置如下:

从以上配置可知,Sidecar Injector只对标签匹配“istio-injection: enabled”的命名空间下的Pod资源对象的创建生效。Webhook服务的访问路径为“/inject”,地址及访问凭证等都在clientConfig字段下进行配置。

Istio Sidecar Injector组件是由sidecar-injector进程实现的,本书在之后将二者视为同一概念。Sidecar Injector的实现主要由两部分组成:

  • 维护MutatingWebhookConfiguration;
  • 启动Webhook Server,为应用工作负载自动注入Sidecar容器。

MutatingWebhookConfiguration对象的维护主要指监听本地证书的变化及Kubernetes MutatingWebhookConfiguration资源的变化,以检查CA证书或者CA数据是否有更新,并且在本地CA证书与MutatingWebhookConfiguration中的CA证书不一致时,自动更新MutatingWebhookConfiguration对象。

原创文章。为了维护文章的版本一致、最新、可追溯,转载请注明: 转载自idouba

本文链接地址: Sidecar Injector自动注入的原理 –《云原生服务网格Istio》书摘04


,

No comments yet.

发表评论