【翻译计划2】Service Mesh in Kubernetes — Pictorially

Created: Mar 10, 2021 10:42 PM
Year: 2020
link: https://medium.com/tarkalabs/service-mesh-in-kubernetes-pictorially-1a254670b965
writer: Sudhakar Rayavaram
标签: kubernetes, 技术

以下是本文的正文内容

图解kubernetes服务网格

这篇文章假设在你已经知道Kubernetes是怎么工作的基础上。如果你不清楚，可以尝试阅读下之前的这一篇文章

为什么是Service Mesh？

至此，我们的Kubernetes世界里已经有了Pods，deployments，services和ingress控制器，我们可以轻松的使用它们去部署我们服务，也能够按照我们的需求去拓展服务。

那么，为什么我们还要提到一个新的概念，所谓的“service mesh”（服务网格），它又会给我们带来什么？为了回答这个问题，让我们假设一个场景，在这个这个场景中，当我们的集群增长到了拥有了更多的服务，它们相互调用以满足一个服务请求，它们的内在依赖关系错乱，堪比意大利面条。

Pod，Deployment，Service，Secret等等这些Kubernetes组件，它们帮助我们创建和部署业务和应用程序，但是却很少可以观察、管理和控制它们之间的流量。这真是Service Mesh起作用的地方。

关键组件

在我们深入了解Service Mesh的技术细节之前，我们先快速的浏览下，它所需要依赖的Kubernetes中的重要理念。

Sidecar proxy

顾名思义，代理服务器运行在主容器的侧边，拦截网络流量，有时候对它进行修改（如mTLS $^1$，mutual TLS，双向认证）。这把应用程序容器（开发者关注的）从其他的如保护通信、通知监视服务器有关流量（操作关注的）等职责分离开来。应用程序可以独立部署，而不用担心代理。

Istio，是一个使用Envoy Proxy的服务网格，而linkerd是使用rust编写代理的服务网格。

Custom Resource Definition (CRD)

Kubernetes提供了定义自己资源的能力（类似于Service、Pod、Deployment、ReplicaSet等），还可以使用kubectl命令行与这些资源进行交互，就像任何Kubernetes资源一样。几乎所有的服务网格实现都创建了自定义资源，以管理和控制它们创建的组件。

Kubernetes Operator

Kubernetes中的Operator更像是自动化的机器人。运营团队（Ops Team）不断重复的事情可以被转化为Operators。从这个角度，甚至部署资源（depolyment resource）也是一个内建的Operator，因为它知道怎样通过配置文件去增加/缩小资源。

服务网格能做什么？

让我们看看运营团队所面临的一些场景，以及他们如何在Kubernetes集群中处理这些场景。

问题

Q：我的哪个微服务处于高负载下？为什么？

A：不知道。默认的Kubernetes的设置无法帮助回答这些。我们可以向Pods中部署Sidecar Proxy，这样他就可以向Prometheus这样的监控服务器中发送服务级别的指标。或者，部署一个自动执行此操作的服务网格。

Q：当一个依赖服务变得缓慢时，如何保证我的客户至少能够使用系统中的某些功能。

A：在Sidecar Proxy中设置断路器，以便于被请求的服务在其依赖变得迟钝/失败时也可以快速响应。或者，安装并配置Service Mesh去执行此操作。

Q：我的服务从东到西，跨越地区/数据中心，怎样去保证安全通信？

A：将本地CA切换成mTLS，以便于服务知道它们正在与真实的服务通信。或者你猜对了，也可以使用Service Mesh。

Q：我如何得到我所管理的服务的流量图？

A：像是Weave Scope和KubeView这样的解决方案只提供资源依赖关系图，而不实时提供流量状态。配置Sidecar去捕获它，或者，这里也可以使用Service Mesh。

等同

Service Mesh是这种解决方案的抽象，因此他可以很容易的应用到任何集群中去。服务网格在管理应用流量方面的作用就如同Kubernetes创建和部署应用程序方面的作用一样。

它是怎么做到的？

Service Mesh在Pods中注入了一个Sidecar Proxy，因此所有的网络流量都需要经过它。这个独立于实际应用程序的组件，可以有许多有趣的应用方式，如下所述：

安全通信

手动设置Mutual TLS不是一个简单的任务，因为它涉及到配置证书颁发机构和处理集群中每一个参与服务发送的证书签名请求。但是，有了Sidecar Proxy，这个问题可以在一个地方解决了。当Sidecar Proxy打开代理/关闭TLS层时，应用程序将可以继续在http中发送/接受流量。

网络监控

Sidecar Proxy也能向Prometheus这样的监控服务器发送有关目标服务器的信息，以了解流量模式，因为这也是Sidecar级别所完成的，所有的实际运行的应用程序完全可以忽略这一点。

你可能已经注意到了，这样的流量监控可能会淹没网络，因为我们需要发送大量额外的数据包，因此很多的Service Mesh提供了我们控制是否开启和按需进行监控。

流量管理

我们可以Sidecar Proxy级别配置的规则将流量路由到服务的不同版本。在上面的图中，所有的“/svc-b/user”的请求都将到达服务b的V1，而对同一服务但是不同端点”/svc-b/order“的所有请求都将到达服务b的V2.这可以用户A/B测试或者服务级别的canary deployment $^2$。

Next steps

如果你已经走到了这一步，并且认为服务网格可以是您的团队获益，那么你可以探索服务网络的实现，如Istio/Linkerd/concorder。每一个都有自己的特性，并以不同的方式管理着服务网格。值得花费一些时间在Service Mesh Interface $ ^3 $上，它提供了不同实现方式的标准化。

参考

[1] What is mTLS and How Does it Work? -https://freedomben.medium.com/what-is-mtls-and-how-does-it-work-9dcdbf6c1e41

[2]canary deployment，金丝雀发布。将小部分用户路由到新的代码版本中，如果没有错误发生，就像新版本逐步推广到整个基础设置中。

[3]Service Mesh Interface:实现了服务网络的标准化接口。它定义了通用的标准。

版权属于：秋

本文链接：https://blog.lyneee.com/tp-2.html

本站文章采用 知识共享署名4.0 国际许可协议 进行许可，请在转载时注明出处及本声明！