Kubernetes 已经成为事实上的编排平台的领导者，下一代分布式架构的王者，其在自动化部署、扩展性、以及管理容器化的应用中已经体现出独特的优势，在企业中应用落地已经成为一种共识。感谢本次技术内容提供者青云QingCloud 软件工程师张仁宇。

Bookinfo 程序，这个是 Istio 官方提供的示例，类似微服务的 HelloWord ，非常简单，主要由四个微服务组成，

入口服务负责调用后端的服务，把信息聚合呈现给前端。Reviews 服务是用来展示书籍的 Reviews。这个 Reviews 服务分为三个版本，不同的版本是不一样的。V1 版本是最原始的版本，V2 版本对它进行了改造，它的 Reviews 不再是单独写一句话，它会有一些打星的显示。V3 版本的服务是打红色心，代表版本的升级。这是不一样的地方，Details 服务是书籍详情。V2 版本的 Reviews 服务和 V3 版本的 Reviews 服务，它的打星不是自己产生的，而是读取，调用服务打星评价分数读出来，然后显示。这就是一个符合微服务架构的非常简单的程序。

现在看到的页面是 ProductPage 的返回，左侧是 Details 服务返回的信息，右侧 Reviews 是 Reviews 的服务，这句话就是 Reviews 服务返回的评价。

Istio 介绍

现在非常火的概念是 ServiceMesh，ServiceMesh 讲究的是把请求、服务间的调用下沉，而不是在你的代码服务器上做，把它做成分离的组件，作为平台的基础设施。在生态圈里，它是作为 Lib 引用到你的代码中，Java 代码中需要这个包去写。

在 Istio 中，ServiceMesh 讲究的是我跟代码无关，代码无侵入。对于 Istio 来说，它是跟语言无关的，不管是什么语言，你做了一个架构，只要在 Istio 平台都可以使用。

以一个非常简单的场景来说，我在非常原始的情况下直接写 API 调用，当你的服务规模上去了，服务节点多了、副本多了，你再去调用的话是调用副本吗？我想做负载均衡怎么办？你可能用非常黑科技的方法自己写，但这会非常麻烦，每次服务一下线、节点一挂你就要改配置，在你的代码中很难做到非常一致，不能说换一个开发，还接着用这个代码。又要改配置，这很麻烦。

在 Istio 中，它的架构是怎么做的？

K8S 中 Pod 作为最小的单元，Pod 可以有很多 Container 。Istio 的实现是什么？在一个 Pod 里，我给它硬塞进去一个容器，这个容器做的是什么？让你所有的请求不再直接从 Service A 调到 Service B，所有的请求通过 Pod 拦截住，由 Pod 发起调用，根据你请求的情况来做。

比如我现在做一个负载均衡，Pod 把你拦截后，我给你做熔断、灰度发布、流量切分等。它不是直接调用那个服务，它是调用那个服务的 Sidecar，就像以前老式三轮车，只有两个人能坐。他调到 Sidecar，调到 Sidecar 后，它可以用你的请求代码。

平台上有很多这样的 Sidecar，所有的 Sidecar 是可以连通的。所有的 Car 连成一个网，这就是 ServiceMesh 的概念。这在 Service 里叫数据平面，它是真正从你的请求来做。

你的配置不会直接发往这里，它怎么知道这个请求应该发往哪里？它的控制平面主要是接触用户的配置关系，把配置标准化，分发到所有的 Sidecar 里。

这个配置包括几个组件，Mixer 主要做规则的校验，如果你需要做一个认证，请求调用时我要根据你的身份确定让不让你过这个请求。这时候 Pod 需要 Mixer 请求一下，看请求能不能给你过，作为 Pod Check。如果不行，就把你的请求灭了，你的请求就失败了。

Mixer 还有一个重点，接受遥测。这是每次请求调用产生的数据，顺序地发给 Mixer，Mixer 把数据收集起来，最后存储下来，最后再可视化的展示出来。

Proxy，Proxy 可以做定制化，灵活性很强。

Pilot，这是里面分发线的，它去获取 Service 的信息。每次创建新的 Service，比如你服务的节点增加或减少，Pilot 可以感知到信息，它自动感受到，并且配置分发。

Citadel，这是负责安全的，它的调用不仅仅是 HTTP 请求，也有别的请求。在请求之间为了安全想加密怎么办？正常想做一个加密要做双向认证，对应你的服务来说，每次这样做是非常繁琐的。Istio 可以下沉，不需要你做。

通过这个的架构完成了代码无侵入，现在的请求该怎么调用还是怎么调用，代码该怎写就怎么写。

今天我们说一下在 KubeSphere® 平台怎么用 Istio 做微服务治理，主要分四部分讲一下我们的工作。

1

Sidecar 注入

首先说一下 Sidecar 注入，在刚刚 Istio 的架构图上对每一个应用来说都要注入一个 Sidecar。对于我的应用来说，这是应用程序的一部分。Sidecar 主要就是两种创建方式，手动的方式不会采纳，因为太繁琐，用户操作的出问题的可能性也比较高。对于用户来说每次创建 Sidecar 都很麻烦，不可能每创建一次就手动导一下。

自动注入依赖于 K8S 提到的 AdmissionWebhook，在 K8S 里面你创建一个资源、创建一个对象，你先提交一个 Depolyment，不是你 Yaml 提交完，立刻就出来了。要先提交到 K8S 的 Server 去，把数据持久化。然后你 Controller 获取，如果发现才能真的创建。Sidecar 过程发生在你把文件提交到 API Server 把配置文件 Yaml 变成持久化。

请求认证通过后，根据你的配置会调用一个 AdmissionWebhook。Webhook 是一个 API 的一部分，你需要有 API 和 Service 供他调用。

如果你现在想对 Pod 或者 Depolyment 做修改，它会把资源创建到 YAML 文件里，发送 Webhook Server。你根据创建的内容做相应的修改，修改完后会返回给 K8S，K8S 再对你的修改结构做校验。校验成功可以做 Validating 的工作。

Validating 的工作是干什么的？K8S 想做 CID，仅仅依赖于 CID 定义的文件的描述是不够的，CID 里第一本指南是自定义资源，把指南对象做简单的校验，范围、类型等。你不能对它进行复杂的校验，比如这个类型和另一个值有关系，这个值可以设定，那个值不能设定。它提供了 Validating Webhook，它可以调用你的 Webhook 做校验，让你的校验功能做得更强大、更自定义。

前面说到 Sidecar 的过程，就发生在 Validating Webhook。我们在 KubeSphere® 平台中，这些都是自动的，把 Istio 对应下面串联的所有 Pod 都可以做，这是没问题的，只要标一下就行。在我们平台上这个行为是显式的，因为同一个项目下可能有些需要，有些不需要。只有在你创建的模板里显示，加上这样的配置后，我们才给你注入一个 Sidecar。

就像右边这个串联一个配置，对那些 Pod，哪些符合条件的 NameSpace 去做，它是做 NameSpace 项目级别的筛选过程。只有符合这样条件的项目，才调用下面的 Webhook。因为我们使用了这样的配置，每次 K8S 创建 Pod 都会走这样的流程。假如我这个 Webhook 的 Service 挂了，流程走不通，它就卡在这个地方，Pod 永远创建不了。在实际使用中，一定要用各种措施保证 Webhook 是高可用的，不能一下就挂了。

假设 DNS 的服务也挂了，K8S 重建肯定不成功，DNS 永远创建不了。这会造成很严重的问题，所以在使用过程中要加入 Webhook，不能让它容易挂掉，一定要保证高可用。

2

Istio 对应用的要求

还有一个问题，在 Istio 上部署一些 Depolyment 时都可以给你注入 Sidecar，但不是所有的 Pod 都可以使用这个配置。它对于你的配置也严格要求，对你定义 Service Yaml，你需要严格保证服务端口要命名。

K8S 里的服务端口命名没有要求，但 Istio 命名有要求，要符合命名格式。前面是服务协议、TCP 等，后面加你的名字，后面是随意的。你的 Container Pod 一定要显示出来，不能不标注。你在 K8S 里可以不标注 Pod，直接访问 Pod 的端口是可以的。只要你的服务能监听这个端口是可以的，但对 Istio 来说，它需要做一些配置的分发，它需要预先知道这些信息，所以你一定要有这个东西。

还有一个限制，你的 Pod 的同一个端口不能关联两个服务。对于 Istio 来说，以同一个 Pod 来说，假如两个服务都选了这个 Pod 会导致很多问题。

还有一个要求，你的 Depolyment，也就是 Pod 的 Depolyment 组件必须有版本和端口，必须有这两个。在第一页 Istio 程序里可以看到 Reviews 有很多版本，区分同一个服务下面不同的版本，你必须有两个端口，这是需要的。

在我们 KubeSphere® 平台中，我们把这些要求弱化了，我们把用户的要求、内容、特征，我们自动给他生成，用户不用管这些事情，只需要添加镜像、启用参数、端口就行了，剩下我们会根据你提供的自动生成。

按照前面说的配置，你仅仅保证服务起来了，如何应用 Istio 提供的策略？如何切分？访问同一个服务，发不同的版本，你还要创建几个配置文件才行。仅仅让它联网，比如你要创建一个服务，说我这个服务有几个版本。你还要创建 Service，这个请求过来了，这个请求发往你的 Service，你要两个版本可以写 V1 版本和 V2 版本。

Gateway(入口)，对 Istio 来说他只管他管理的服务，你可以把 Istio 看成封闭的网，流量进不来也出不去，除非你定义。你告诉它，它才能打开。

现在我们要定义 Gateway，让流量进入服务中。Gateway 是什么意思？指的是网格内其他的服务、其他的 Pod 可以通过这个网关走这个入口。用户使用 Istio 学习成本很高，他对底层的理念不是特别关心，除非你真的是研究这个。这是 Istio 微服务治理，我们尽量做好，让你接触到的都是你已经知道的。你不需要知道网关、Service 等，跟你没有关系。

3

发布策略

在我们工作过程中，自定义了一个对象叫 Strategy ServicePolicy CRD，对应服务发布的策略，金丝雀发布、镜像、蓝绿部署，对应这些东西。你创造这些策略，我们把这些策略通过我们定义的 Controller 自动创建应用 Pod，自动提交给 Istio，Istio 自动把配置文件分发下去。让用户写是很繁琐的，用户一写错，比如 Service 直接面向 Istio，一提交就会分发下去，如果写错会导致整个服务挂了，无法访问。我们采用 CID 的方式，刚刚 Istio 里提到配置文件，我现在想把容量从 60% 改称 50%，只需要改配置文件就行了。

以刚刚的例子来说，一个灰度发布流量是 10% 和 90%，我的版本上线一段时间发现没有问题，慢慢把流量提高。之前的做法是改配置文件，改好数据就行了。现在用这种方式，我们可以定义一种策略，Controller 会定期获取灰度版本的指标，如请求的正确率、请求时间。如果发现没有问题，我们每隔一个小时可以提高一点，逐渐到 100%。不需要人工干预就完成了这次灰度发布，图中显示是自己拖的。你可以通过这种方式慢慢淘汰这种方式，它自己把灰度发布维护好。

还有一种拓展能力，刚才灰度版本中，如果你的配置文件先发布，虽然 Pod 是创建了，但是 Pod 启动也需要一定时间发布。少五秒的启动也好，有时候慢的话，资源配置不对，肯定一两分钟也启动不了。这时候你的配置文件生效了，仍然还是会导过去。你导过去这个 Pod 不在，启动会失败。我们用这种方式，我们等你的 Pod 全部起来后才把应用下发下去，不会让你的请求有错误的真空期。通过配置文件，自定义的方式来做。如金丝雀发布、A/B 测试，直接通过这种方式做，点一下模板就可以了。

应用在 K8S 里有不一样的概念，这是一个大的应用，不同的部署之间的应用。我们现在的做法是把微服务以应用的视角，这是整个应用，不是我是 details 一个服务。就像两个服务调用，你要涉及两个 Pod，你至少会涉及两个副本，而不是单个副本。

刚才说到的都是在 Sidecar 生效的。如果你只有一个 Pod，只有一个 Sidecar，我们发起时那个 Pod 没有 Sidecar，它不知道这个策略，无法生效。所以你至少得有两个副本，多的话这种情况更复杂，我们做的是把逻辑相关的强制，在创建时必须以应用的视角、应用的概念来做。这样的做法好处是服务关系是静态定义的，不像之前可以通过调用关系分析数据分析出来的，我们可以根据你的配置文件预定义，这样可以非常方便管理。我把应用删除时，我可以把应用下面的所有资源全删除，不用像以前一个个删除。

4

可观察性

最后一部分是微服务的可观察性，为什么要做微服务？因为我们的应用规模越来越大，不可拆分。如果微服务拆分的话，对服务间的状态是不知道的，你看不到一个状态，没有有效的看状态，你还是抓瞎，除了问题也不知道在哪儿，假如它的链路很长，服务出问题了，你会怎么解决？所以我们在做微服务治理时，可观察性是看重的。

一次调用层面的响应情况，都可以通过分布式追踪工具把它展示出来。这张图展示了很丰富的监控指标，正确率、IOPS 等，收集到的数据挖出来再看。出问题时，这张图是不一样的，你可以从另一个角度看到服务出问题了。之后我们会加上应用的监控告警，整体的响应时间到达 200 毫秒，我就报警，快速响应。

系列分享回顾：

「K8S 技术落地实践」系列：高效运维 K8S 集群

「K8S 技术落地实践」Prometheus 在 K8S 上的监控实践

「K8S 技术落地实践」Operator：以 K8S 原生的方式去管理 K8S 原生应用

「K8S 技术落地实践」企业级核心存储平台为 Kubernetes 赋能

「K8S 技术落地实践」NetDevOps in Kubernetes

-FIN-

长安十二时辰用望楼、暗语、大案牍术展现了唐代的数字世界，那么现代的数字世界是什么样呢？7 月 25 日，请来和我们一起，洞见未来数字世界?