Istio 在不触碰代码的情况下,为一组微服务添加流量管理、安全和可观测性。之所以能做到这一点,是因为它的两半在如何分工上的设计:一个实际处理流量的数据平面,以及一个告诉数据平面该做什么的控制平面。本指南涵盖这两者,以及将它们与你的工作负载连接起来的 sidecar 模型。

Sidecar:与你的容器并肩而行的代理

在 Istio 的默认模式下,每个工作负载 Pod 都会在你应用自己的容器旁边被注入第二个容器:一个 Envoy 代理,被配置为拦截该 Pod 所有的入站和出站流量。你的应用仍然绑定自己的端口,并像什么都没变一样发出出站调用;sidecar 透明地位于路径之中,这正是关键所在。应用永远不需要知道代理的存在。

这带来的好处是:TLS、重试、超时、负载均衡和授权从应用代码中移出,变成应用于代理的配置。开发团队编写业务逻辑;网格在每个服务上统一处理网络方面的关注点,而不是每个团队各自重新实现(或忘记实现)同样这些关注点的各自版本。

数据平面:Envoy,做实际的工作

数据平面是所有这些 sidecar 代理的集合,实际承载服务之间的每一个请求。流量在这里被加密,请求在超时后在这里被重试,某个服务的某个版本在这里可能为金丝雀发布接收 10% 的流量。数据平面自己不决定策略;它强制执行控制平面推送给它的任何配置。

控制平面:istiod

istiod 是 Istio 的控制平面,作为自己的一组 Pod 运行在 istio-system 命名空间中。它做三项不同的工作:

• 配置分发。 你用 Istio 自己的 Kubernetes 资源表达意图,比如”在这两个版本之间以 90/10 拆分流量”。istiod 把它翻译成 Envoy 的原生配置格式并推送给每个相关的 sidecar,所以你永远不需要手写 Envoy 配置(本资料库中关于 Envoy 的”学习”系列介绍了那套底层配置实际是什么样子,供好奇 istiod 在生成什么的人参考)。
• 证书颁发机构。 istiod 颁发并轮换每个 sidecar 用于双向 TLS 的证书,所以服务到服务的流量被加密,并且双方可以验证对方的身份,而无需任何应用代码自己管理证书。
• 服务发现与策略。 istiod 跟踪存在哪些服务以及它们在哪里,并将认证和授权策略分发给需要强制执行它们的代理。

Sidecar 注入:Pod 究竟如何得到代理

仅仅安装 Istio 不会改变你运行中的工作负载的任何东西。Sidecar 注入是一个独立的、显式的步骤:给命名空间打标签(istio-injection=enabled),此后在该命名空间中创建的任何 Pod 都会在创建时自动被添加一个 Envoy sidecar 到它的 spec 中。已有的 Pod 不会被追溯修改;它们需要在标签就位之后被重新创建(删除后重新应用,或通过 Deployment 滚动),才能获得 sidecar。

这种按命名空间选择加入的设计是有意的。自动让集群中的每个命名空间入网,包括那些从未打算运行 sidecar 的系统命名空间,会增加没有人要求的资源开销和复杂性。打标签让你可以精确控制哪些工作负载进入网格。

带有 sidecar 的 Pod 显示两个容器,而未入网的等价 Pod 只显示一个:

kubectl get pods
# NAME                READY   STATUS
# reviews-v1-abc123   2/2     Running   ← sidecar present
# ratings-v1-def456   1/1     Running   ← no sidecar (unlabeled namespace)

对于需要 sidecar 但又不想给整个命名空间打标签的工作负载,手动注入(istioctl kube-inject)会在应用单个清单之前,把 sidecar 添加到该清单,下一篇指南连同安装的其余部分一起介绍。

关于 ambient 模式的说明

上面所述的一切,描述的都是 Istio 最初的、基于 sidecar 的架构,这也是本系列其余部分所涵盖的内容。Istio 还提供另一种无 sidecar 的 ambient 模式,它把数据平面拆分为每个节点一个的组件(ztunnel)和每个命名空间一个的 waypoint 代理,而不是向每个 Pod 注入代理,旨在降低每个工作负载运行一个 Envoy 的资源开销。这在架构上的差异足够大,因此超出了本系列的范围;你在这里学到的关于流量管理和安全的概念,在 ambient 模式下概念上仍然适用,但流量如何被拦截的机制则不同。如果你评估的恰好就是 ambient 模式,请查阅 Istio 自己的文档。