在 istio 中为了对流量进行有效的管理，一般通过注入的方式将代理 istio-proxy 与应用程序一起位于同一个Pod，然后通过 istio-init initContainer修改 iptables 实现 ingress 或 egress，那么在 istio 中这个注入是如何实现的呢，本节对其实现原理进行一些分析。 实现原理 在上一节《apiserver 中的webhook开发教程》 我们介绍过admission controller 基本实现原理，由此得知当创建一个资源对象的时候，可以通过定义 ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration 实现在创建的进程中对这些 webhook 进行调用。而 MutatingWebhookConfiguration 则可以对请求的资源进行修改。在istio中的 injection 正是基于此原理实现的。 webhook配置 当我们在k8s集群中安装 istio 后，会创建一些资源，如 deployment、service、crd 等 $ istioctl install --set profile=demo -y ✔ Istio core installed ✔ Istiod installed ✔ Egress gateways installed ✔ Ingress gateways installed ✔ Installation complete $ kubectl get deployment -n istio-system NAME READY UP-TO-DATE AVAILABLE AGE istio-egressgateway 1/1 1 1 126m istio-ingressgateway 1/1 1 1 126m istiod 1/1 1 1 131m $ kubectl get pod -n istio-system -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES istio-egressgateway-7b8b76f497-w2xvj 1/1 Running 0 139m 10.

源码版本：istio-v1.11.3 为了方便理解，本文会介绍到 vm 和 容器 两种部署形式的情况，一般会在讲解时提到，因此需要注意当前的部署方式，不过他们的架构是完全一样的。 架构 pilot 共分两个主要模块，一个是 pilot-agent 用来提供 pod 中的服务发现 客户端，另一个是 polot-discovery 提供服务发现 服务端。 其中 envoy 和 Istio Agent 就是我们上面所讲的 pilot-agent 模块,其为 数据面 组件，而 Istiod 则为 控制面，模块对应源码见 pilot-agent 对于 polot-agent 它运行在每个pod中 ，并以 sidecar 方式与应用容器运行在同一个pod。如果你使用的是 vm 的话，则可以在当前主机通过 pstree 命令看到进程视图 # pstree -pu 24530 su(24530)───pilot-agent(24611,istio-proxy)─┬─envoy(24619)─┬─{envoy}(24620) │ ├─{envoy}(24621) │ ├─{envoy}(24622) │ ├─{envoy}(24623) │ ├─{envoy}(24624) │ ├─{envoy}(24625) │ ├─{envoy}(24627) │ ├─{envoy}(24628) │ ├─{envoy}(24629) │ ├─{envoy}(24630) │ └─{envoy}(24635) ├─{pilot-agent}(24612) ├─{pilot-agent}(24613) ├─{pilot-agent}(24614) ├─{pilot-agent}(24615) ├─{pilot-agent}(24616) ├─{pilot-agent}(24617) ├─{pilot-agent}(24618) ├─{pilot-agent}(24626) └─{pilot-agent}(24698) ​ 从进程关系可以看到，envoy 属于 pilot-agent 的一个子进程，当前进程以 istio-proxy 用户身份运行。

建议参考官方文档 https://istio.io/latest/zh/docs/setup/install/virtual-machine/ ，这里提醒大家对于命令中文版部分命令与英文版不一致，请以 英文版 为准。 对于istio在vm上的安装教程主要分为三部分。首先是在k8s的master节点生成vm连接主节点的一些配置信息，其实是在vm上应用这些配置信息，最后也就是验证连接是否成功。 本篇主要介绍“单网络”的情况， 对于”多网络“请自行参考官方文档。 vm环境准备 生成vm通讯配置信息 这里主要介绍一些新手迷惑的部分。如环境变量设置及vm注册的方式 设置环境变量 在设置变量时，对于”单网络“来讲 CLUSTER_NETWORK 和 VM_NETWORK 保留空值即可。如我这里设置如下 $ VM_APP="myapp" $ VM_NAMESPACE="vm" $ WORK_DIR="/root/myapp" $ SERVICE_ACCOUNT="vm-sa" $ CLUSTER_NETWORK="" $ VM_NETWORK="" $ CLUSTER="Kubernetes" 每个环境变量的解释： VM_APP 表示vm上应用的名称 VM_NAMESPACE 表示应用所在的namespace WORK_DIR 生成vm配置信息保留的目录，任何位置即可 SERVICE_ACCOUNT 服务运行的账号 ，即yaml文件中的 ServiceAccount 字段 CLUSTER 集群名称，默认为 Kubernetes 即可。 安装 Istio 控制平面 1 为安装创建 IstioOperator 空间 cat <<EOF > ./vm-cluster.yaml apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: name: istio spec: meshConfig: accessLogFile: /dev/stdout enableTracing: true enableEnvoyAccessLogService: true defaultConfig.

使用服务入口（Service Entry） 来添加一个服务入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样，可参考 https://istio.io/latest/zh/docs/concepts/traffic-management/#service-entries。 简单的理解就是允许内网向外网服务发送流量请求，但你可能会说正常情况下在pod里也是可以访问外网的，这两者有什么区别呢? 确实默认情况下，Istio 配置 Envoy 代理可以将请求传递给外部服务。但是无法使用 Istio 的特性来控制没有在网格中注册的目标流量。这也正是 ServiceEntry 真正发挥的作用，通过配置服务入口允许您管理运行在网格外的服务的流量。 此外，可以配置虚拟服务和目标规则，以更精细的方式控制到服务条目的流量，就像为网格中的其他任何服务配置流量一样。 为了更好的理解这一块的内容，我们先看一下普通POD发送请求的流程图普通 Pod 请求 创建 ServiceEntry 资源 举例来说： svc-entry.yaml apiVersion: networking.istio.io/v1beta1 kind: ServiceEntry metadata: name: svc-entry spec: hosts: - "www.baidu.com" ports: - number: 80 name: http protocol: HTTP - number: 443 name: https protocol: HTTPS location: MESH_EXTERNAL resolution: DNS 该 ServiceEntry 资源定义了一个外部网站 www.baidu.com 服务，并将它纳入到 Istio 内部维护的服务注册表（服务网格）中。 创建资源 $ kubectl apply -f svc-entry.yaml serviceentry.networking.istio.io/svc-entry created 现在我们已经创建了一个 ServiceEntry, 默认在 default 命名空间。