服务网格仍然很难 – cncf

微信扫一扫,分享到朋友圈

服务网格仍然很难 – 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)的 博客
很好地描述这些问题,解释了复杂性,三者中的任何一个可能出问题以及如何修复这些问题。

微信扫一扫,分享到朋友圈

服务网格仍然很难 – cncf

《漫威蜘蛛侠:迈尔斯·莫拉莱斯》IGN 9分:有史以来最棒的超英游戏之一

上一篇

1亿补贴,中国医美的狂欢盛宴就在新氧11.11

下一篇

你也可能喜欢

服务网格仍然很难 – cncf

长按储存图像,分享给朋友