服务网格仍然很困难

前言

今年8月ServiceMeshCon分别讨论了Linkerd和Istio的改进，目标是使用户使用起来更简单。

当前服务网格比前几年前更加成熟，但是，对于用户来说仍然很难。服务网格有两种技术角色，平台所有者和服务所有者。平台所有者（也称为网格管理员）拥有服务平台，并定义了服务所采用服务网格的总体策略和实现。服务所有者在服务网格中拥有一项或多项服务。

对于平台所有者而言，使用服务网格变得更加容易，因为项目正在实施简化网络配置，安全策略配置以及整个网格可视化的方法。例如，在Istio中，平台所有者可以在他们喜欢的任何范围内设置Istio身份验证策略或授权策略。平台所有者可以在主机/端口/TLS相关设置上配置入口网关，同时将目标服务的实际路由行为和流量策略委托给服务所有者。实施经过良好测试和常见方案的服务所有者可以从Istio的可用性改进中受益，从而轻松地将其微服务加载到网格中。但是服务所有者在实施不太常见的方案时将继续遇到陡峭的学习曲线。

我认为服务网格仍然很困难，原因如下：

缺乏关于是否需要引入服务网格的明确指导

在用户开始评估多个服务网格或深入研究特定的服务网格之前，他们需要有关服务网格是否可以提供帮助的指导。不幸的是，这不是一个简单的是/否问题。有多个因素需要考虑：

• 您的工程组织中有多少人？
• 您有多少个微服务？
• 这些微服务使用什么语言？
• 您是否有采用开源项目的经验？
• 您在什么平台上运行服务？
• 服务网格需要什么功能？
• 对于给定的服务网格项目，功能是否稳定？

对于各种服务网格项目，答案可能会有所不同，因为服务网格增加了复杂性。即使在Istio内部，我们也采用微服务来充分利用Istio 1.5之前的早期版本中的服务网格，但是决定将多个Istio控制平面组件转变为单体应用程序以降低操作复杂性。例如，运行一个整体服务而不是四个或五个微服务更为有意义。

注入边车模式后，您的服务可能会立即中断

在上一个感恩节，我试图使用最新的Zookeeper helm chart帮助用户在网格中运行Zookeeper服务。Zookeeper作为Kubernetes StatefulSet运行。一旦我尝试将特定边车代理注入每个Zookeeper Pod，Zookeeper Pod将无法运行并继续重新启动，因为它们无法建立领导者并在成员之间进行通信。默认情况下，Zookeeper监听Pod IP地址以进行服务器之间的通信。Istio和其他服务网格要求将本地主机（127.0.0.1）作为侦听的地址，但是这使Zookeeper服务器无法相互通信。

通过与社区合作，我们为Zookeeper，Casssandra，Elasticsearch，Redis和Apache NiFi添加了配置解决方法。我确信还有其他与边车模式不兼容的应用程序。如果有的话，请通知社区。

服务在启动或停止时可能会有异常行为

该应用程序容器可能会在sidecar之前启动，并导致应用程序启动失败。当然sidecar可能会在应用容器之前停止。这些都是使用sidcar带来的挑战。

Kubernetes缺乏声明容器依赖项的标准方法。不过有一个Sidecar Kubernetes增强建议（KEP），但是Kubernetes版本中尚未实现，并且要花一些时间才能使用该功能。同时，服务所有者可能会在启动或停止时观察到意外行为。

为了帮助解决此问题，Istio为平台所有者添加了全局配置选项，以将应用程序启动延迟到Sidecar准备就绪为止。后期Istio将允许服务所有者在pod级别进行配置。

您的服务可以零配置，但代码会有改动

服务网格项目的主要目标之一是为服务所有者提供零配置。像Istio这样的一些项目已经添加了智能协议检测功能，以帮助检测协议并简化网格的入门体验，但是，我们仍然建议用户在生产中显式声明协议。通过在Kubernetes中添加appProtocol设置，服务所有者可以使用标准方法为在较新的Kubernetes版本（例如1.19）中运行的Kubernetes应用程序服务配置协议。

为了充分利用服务网格的功能，不幸的是不可能零代码更改。

• 为了使服务所有者和平台所有者正确观察服务跟踪，在服务之间传播跟踪标头至关重要。
• 为避免混淆和意外行为，至关重要的重试和超时可能需要重新修改，以查看是否应进行调整并了解其行为与与sidecar代理配置的重试和超时的关系。
• 为了让Sidecar代理检查从应用程序容器发送的流量并智能地利用内容来做出决策，例如基于请求的路由或基于请求头的授权，对于服务所有者而言，确保从源服务发送至目标服务，从而安全地升级连接并信任Sidecar代理。

服务所有者需要了解客户端和服务端配置的细节问题

在使用服务网格之前，我不知道有太多与超时和从Envoy代理重试有关的配置。大多数用户都熟悉请求超时，空闲超时和重试次数，但是存在许多细微差别和复杂性：

• 当涉及到空闲连接超时时，HTTP协议下有一个idle_timeout，它适用于HTTP连接管理器和上游集群HTTP连接。有一个stream_idle_timeout一个流与存在没有上游或下游路线活性检测，甚至可重写stream_idle_timeout。
• 自动重试也很复杂。重试不仅是重试次数，而且是允许的最大重试次数，这可能不是实际的重试次数。重试的实际数量取决于重试条件，路由请求超时和重试之间的间隔，这些间隔必须落在总体请求超时和重试预算之内。

在非服务网格环境中，源容器和目标容器之间可能只有1个连接池，但是在服务网格环境中会出现3个连接池：

• 源容器到源Sidecar代理
• 源Sidecar代理到目标Sidecar代理
• 目标Sidecar代理到目标容器

这些连接池中的每一个都有其自己的单独配置。三者中的任何一个配置不当都会出现问题。

结论

我希望上述挑战能引起您的重视，无论您利用服务网格到何种场景。我期待看到所有项目的创新，因为我们正在努力使服务网格变得枯燥无聊但尽可能有用。

推荐

深入探究 K8S ConfigMap 和 Secret

Kubernetes入门培训（内含PPT）