服务网格仍然很难 - cncf

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

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

而服务所有者却遇到陡峭的学习曲线。 

 

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

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

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

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

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

 

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

上一个感恩节，我试图使用最新的Zookeeper舵图帮助用户在网格中运行Zookeeper服务。Zookeeper作为Kubernetes StatefulSet运行。一旦我尝试将特使边车代理注入每个Zookeeper pod，Zookeeperpod将无法运行并继续重新启动，因为它们无法建立领导者并在成员之间进行交流。

默认情况下，Zookeeper监听Pod IP地址以进行服务器之间的通信。但是，Istio和其他服务网格要求将本地主机（127.0.0.1）作为侦听的地址，这使Zookeeper服务器无法相互通信。

与上游社区合作，我们为Zookeeper，Casssandra，Elasticsearch，Redis和Apache NiFi添加了配置解决方法。我确信还有其他与边车不兼容的应用程序。

 

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

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

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

 

4.可以为您的服务进行零配置，但不能零代码更改

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

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

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

 

5.服务所有者需要了解客户端和服务端配置的细微差别

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

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

在非服务网格世界中，源容器和目标容器之间只有1个连接池，但是在服务网格世界中，有3个连接池：

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

这些连接池中的每一个都有其自己的单独配置。卡尔·斯通尼（Karl Stoney）的博客很好地描述这些问题，解释了复杂性，三者中的任何一个可能出问题以及如何修复这些问题。

 

#服务网格      #Istio      #Kubernetes