Istio如何实现自动注入？

当命名空间激活istio注入功能时，比如部署一个deployment，会发现业务容器旁多了一个sidecar容器。

istio是如何实现这一点的呢？使用的是Admission Controllers中的两个特殊的控制器：MutatingAdmissionWebhook 和ValidatingAdmissionWebhook

AdmissionController 会在客户端请求经过认证授权验证后，在对象持久化到etcd之前拦截请求。

参考：https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers

kubectl 注册一个ValidatingWebhookConfiguration/MutatingWebhookConfiguration对象， 对象包含触发webhook调用的条件，webhook server地址 etc。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "pod-policy.example.com"
webhooks:
- name: "pod-policy.example.com"
  # 触发webhook的条件
  rules:
  - apiGroups:   [""]
    apiVersions: ["v1"]
    operations:  ["CREATE"]
    resources:   ["pods"]
    scope:       "Namespaced"
  clientConfig:
    # webhook server的服务地址
    service:
      namespace: "example-namespace"
      name: "example-service"
    caBundle: "Ci0tLS0tQk...<`caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate.>...tLS0K"
  admissionReviewVersions: ["v1", "v1beta1"]
  sideEffects: None
  timeoutSeconds: 5

当用户使用kubectl apply 注册了感兴趣的资源，此处为新的Deployment。API Server就会触发webhook调用。

API Server首先会调用所有的mutating admission webhook， 用于设置资源对象的默认值。
然后调用所有的validating admission webhook，用于验证资源对象的合法性。

经过webhook验证的资源对象，最后持久化到etcd中。

第三步的具体流程是：

APIServer发起一个POST HTTP请求，请求体中包含AdmissionReview对象。AdmissionReview包含了更改Resource的信息，
Webhook Server返回一个AdmissionReview对象，作为Response。

触发mutating admission webhook 调用时，可以实现sidecar注入逻辑。只需要webhook server实现处理AdmissionReview的信息，添加sidecar容器信息即可。