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