出于撰写本文的需要，我将介绍Kuma。Kuma是一种建立在Envoy之上的开源解决方案，为微服务和服务网格充当控制平面。它与Kubernetes和虚拟机兼容，可以支持一个集群中的多个网格。
还有其他开源和托管服务网格可供选择，比如Istio、Linkerd和Kong Mesh。
为什么使用服务网格?
我们使用服务网格的主要目的之一是，在内部pod服务之间获得相互传输层安全(mTLS) 以确保安全。另外，使用服务网格具有诸多好处，因为它允许工作负载在多个Kubernetes集群之间联系，或者运行连接到Kubernetes的标准裸机应用程序。它提供跟踪、记录pod之间的连接，可以将连接端点健康指标输出到Prometheus。
该图显示了在实施服务网格之前工作负载的样子。在左边的示例中，团队花费时间构建管道而不是构建产品或服务，通用功能在服务之间加以复制，存在不一致的安全性和可观察性实践，还存在毫无可见性的黑盒实现。
在右边，在实现服务网格之后，同一个团队可以致力于构建产品和服务。他们能够构建可扩展的高效分布式架构，可观察性在多个平台上保持一致，更容易实施安全和合规最佳实践。
Kuma服务网格架构的工作原理
将应用程序pod的套接字通信从明文转移到mTLS的神奇之处在于Kuma控制平面、边车(sidecar)和Kuma 容器网络接口(CNI)。当开发人员合并一些更改、为应用程序添加新服务时，Kuma透明地检测和注入所需的位，跨自己的网络数据平面自动代理流量。
Kuma服务网格包括三大组件：
- Kuma CNI：这个CNI插件可以根据注释来识别带有边车的用户应用程序pod，以设置流量重定向。它在pod生命周期的网络设置阶段完成这项设置，此时每个pod通过名为mutating webhook的进程在Kubernetes中进行调度。
- Kuma-sidecar：它在每个暴露服务的实例上运行。这些服务将所有连接性和可观察性问题委托给进程外的运行时环境，该运行时环境将位于每个请求的执行路径上。它代理所有出站连接，并接受所有入站连接。当然，它还会在运行时执行流量策略，比如路由或日志。如果使用这种方法，开发人员不必操心加密连接，可以完全专注于服务和应用程序上。它被称为边车代理，因为它是在同一个pod上的服务进程旁边运行的另一个容器。每个运行的服务实例都会有一个边车代理实例;又由于所有出入请求及其数据始终通过边车代理来传输，这又叫Kuma数据平面(DP)，因为它位于网络数据路径上。
- Kuma控制平面(kuma-cp)：这是一个用GoLang编写的分布式可执行文件，可以在Kubernetes上运行，颁发数据平面证书，并在Kubernetes API内协调数据平面(DP)状态。您可以使用Kuma自定义资源定义(CRD)来配置Kuma设置和策略，边车自动从控制平面获取更改。
结语
现在的服务网格拓扑结构酷似1990年代和2000年代的企业服务总线(ESB)架构。无需像ESB架构那样根据业务策略沿路由引导代理流量，有了网格，您可以自由地连接应用程序，网格自上而下管理路由和策略。
在我看来，ESB架构在业界没有更流行的最大原因是它必须满足整体式代码库需求以及经常遇到的最终的依赖项管理问题。您会有数十个项目共享依赖项以管理ESB上的对象，这成了软件管理的一大难题。
服务网格技术通过与代码保持分离来减轻复杂度。它让开发人员可以将安全性、可靠性和可观察性的复杂性从应用程序堆栈转移出来，将其作为基础设施环境的一部分。
原文标题：Implementing a Secure Service Mesh，作者：Jonathan Kelley
