📚 课程目录第3章 Istio 架构与部署实战

3. Istio 架构与部署实战

Istio 的架构可以概括为“一个控制平面 + 一组数据平面代理 + 一套配置分发通道”。理解这三者的职责边界与通信路径，是后续做流量治理、可观测性和安全策略的前提。本节先拆解组件，再说明控制平面如何把配置下发到数据平面，最后给出一套可复现的生产级安装与验证流程。

一、组件解析：谁在做什么

控制平面由 istiod 统一承载，它把原先分散的 Pilot、Citadel、Galley 能力合并为一个进程。其中 Pilot 负责将 VirtualService、DestinationRule 等高层配置翻译为 Envoy 可识别的 xDS 配置；Citadel 负责证书签发与轮换，为工作负载提供 SPIFFE 身份；Galley 负责配置的校验与分发。数据平面则是以 Sidecar 形式注入的 istio-proxy（Envoy），它拦截 Pod 的入站与出站流量，执行路由、熔断、mTLS 和遥测上报。

需要特别区分两个辅助组件：istio-ingressgateway 是部署在网格边缘的 Envoy，负责南北向流量入口；istio-cni 是可选的 CNI 插件，用于在受限权限环境下完成流量重定向，避免依赖 init 容器的 iptables 提权。它们不是控制平面的一部分，但属于安装清单中的关键对象。

二、控制平面与数据平面的通信机制

istiod 与 Envoy 之间不是“推送命令”，而是基于 gRPC 的 xDS 增量订阅。每个 Sidecar 启动后，会通过 istio-agent 向 istiod 建立长连接，声明自己关注的资源类型。当配置发生变化时，istiod 只把差异部分推送给受影响的代理，而不是全量重发。这套机制包含五类核心资源：

LDS（Listener Discovery Service）：定义 Envoy 监听哪些端口、使用什么过滤器链；
RDS（Route Discovery Service）：定义 HTTP 路由规则，对应 VirtualService 的匹配与转发；
CDS（Cluster Discovery Service）：定义上游服务集群及其负载均衡策略；
EDS（Endpoint Discovery Service）：定义集群内具体 Pod IP 与健康状态；
SDS（Secret Discovery Service）：下发证书与私钥，支撑 mTLS 身份。

通信链路可以这样理解：Kubernetes API Server 中的 CRD 是“期望状态”，istiod 监听并翻译为 xDS 资源，Envoy 通过长连接接收并热更新本地配置，最终在数据面生效。整个过程中，Envoy 不直接访问 API Server，这既降低了 API Server 压力，也保证了配置一致性由 istiod 统一收敛。

排查配置不生效时，优先确认三件事：istiod 是否正常 watch 到 CRD 变更、目标 Pod 是否已注入 Sidecar、Envoy 是否成功收到对应 xDS 资源。可用 istioctl proxy-config 系列命令逐层核对。

三、生产级安装与验证

生产环境不建议直接使用 istioctl install --set profile=demo。推荐用 IstioOperator 声明式安装，把配置纳入 Git 管理。以下示例假设集群为 Kubernetes 1.28，使用默认 revision 安装，并开启访问日志与 Prometheus 指标：

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-prod
  namespace: istio-system
spec:
  profile: default
  meshConfig:
    accessLogFile: /dev/stdout
    enablePrometheusMerge: true
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
  values:
    global:
      proxy:
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi

执行安装并确认组件状态：

istioctl install -f istio-prod.yaml -y
kubectl get pods -n istio-system
# 期望输出：istiod、istio-ingressgateway 均为 Running
istioctl verify-install

接下来为业务命名空间开启自动注入，并部署一个测试应用验证链路：

kubectl label namespace default istio-injection=enabled
kubectl apply -f samples/httpbin/httpbin.yaml
kubectl apply -f samples/sleep/sleep.yaml
kubectl get pods
# 确认每个 Pod 的 READY 为 2/2，说明 Sidecar 已注入

验证分三层进行。第一层看注入是否成功，Pod 容器数应为 2；第二层看代理配置是否下发，执行 istioctl proxy-config cluster deploy/sleep -n default，应能看到指向 httpbin 的 cluster；第三层做实际调用，从 sleep 容器内访问 httpbin：

kubectl exec deploy/sleep -c sleep -- curl -s http://httpbin.default:8000/ip
# 返回 {"origin":"10.244.x.x"} 说明东西向流量已走通

最后确认 mTLS 是否生效。默认情况下 Istio 使用 PERMISSIVE 模式，可先查看认证策略，再通过 istioctl x describe pod 观察实际使用的证书与对端身份。若返回结果中显示 mTLS: STRICT，说明双向认证已启用。

生产安装常见坑：节点资源不足导致 istiod 处于 Pending；集群已有旧版本 Istio 残留 CRD 导致升级失败；命名空间未打注入标签却期望 Sidecar 生效。安装前建议先执行 istioctl x precheck 做环境预检。

完成以上步骤后，控制平面、数据平面与通信链路均已就绪，后续的流量治理、可观测性与安全策略都可以在此基础上展开。