Hellofresh每周向数百万客户供餐，表面上看起来很简单，实际上要复杂得多。在幕后，要在我们范围内运营，需要大量的基础设施，然后才能最终将餐交付给客户。
在HelloFresh，我们运行着数百种微服务，这些微服务可以完成从供应链管理和付款到保存客户偏好的所有工作。大规模运行微服务并非没有挑战，许多公司开始经历复杂性的痛苦。像许多其他微服务采用者一样，我们发现随着服务数量的增加，越来越难以理解所有这些服务之间的交互。当微服务领域出现问题时，很难确定问题可能在堆栈中的哪个位置。在2019年初，我们开始研究解决此问题的方法，并得出结论认为服务网格，尤其是Istio是最佳选择。
Istio
Istio是围绕Envoy代理构建的服务网格，用于管理和控制流量，保护服务并查看它们之间发生了什么。此外，Istio还可以与Jaeger，Grafana，Kiali和Prometheus等其他常见基础结构和监视组件配合使用。由于我们已经将所有工作负载转移到Kubernetes/EKS，并且已经使用了上述工具，因此Istio非常适合我们。我们花了几个月的时间在测试和生产工作负载上部署和配置Istio，到2019年12月，我们在生产环境全部通过Istio治理。这一系列博客文章将解释我们在这段时间中学到的所有内容，并将涵盖一些未必在文档中突出显示的经验教训。
专注于您的需求，做减法
Istio可以做很多事情。其提供了非常多的功能，但Istio的核心确实做四件事：连接性，可观察性，安全性和流量控制。早些时候，我们决定将精力集中在提供可观察性和可用性上。我们的策略是首先利用好可观察性和可用性，然后再逐步使用其他功能。
在Istio中，意味着选择能够实现可观察性和可靠性的核心功能集。为了提高可用性，我们启用了“断路”，“异常检测”，“重试”（必要时）和“超时”等功能。我们以一种使开发人员可以选择他们想要实现的功能的方式启用它们，但是具有公司标准接口（更多内容请参见下文）。实际上，我们为大多数服务添加了sidecar代理（Envoy），网关，虚拟服务和目标规则。
这里的建议是，对于大多数公司而言，Istio可能过于复杂而无法一次全部使用所有功能。因此，首先关注一个或两个方面，然后再添加其余方面。
集中管理Istio模板
我们使用Helm chart部署所有服务。通常，要在全公司范围内创建虚拟服务和目标规则，我们将必须使用适当的Istio相关Helm模板来更新每个git repo。但是，我们编写了一个Helm插件，该插件可加载包含Istio虚拟服务，目标规则，网关资源的集中式Helm模板。该插件将这些模板与项目特定的值结合使用，以生成完整的Charts。然后，应用程序团队可以在维护模板的同时配置 helm value文件以满足他们的需求。为了为所有人启用Istio，我们要做的就是创建模板，而团队只需更新其helm values即可。我们创建了一个简单的界面，通过以下helm value来控制Istio的所有方面：
注入Sidecar？不注入Sidecar？
最终，在考虑并确定要推出的功能以及开发人员如何与之交互之后，我们开始进行测试。在Istio中，这意味着将代理Sidecar添加到应用程序Pod。 Istio通过在应用程序旁边注入基于Envoy的Sidecar代理进行工作，该应用程序拦截去到和来自Pod的所有入站和出站调用。然后，可以将Sidecar代理配置为控制或保护通过它的流量，同时也可以收集遥测指标和跟踪信息，以供Prometheus和Jaeger使用。
首先，我们选择不向每个新Pod中注入Sidecar，因此我们全局禁用了自动注入：
global:
proxy:
autoinject: disabled同样，并不是我们需要为每个Kubernetes名称空间注入sidecar，因此我们通过向启用istio的名称空间添加以下标签来限制可能具有sidecar的名称空间：
istio-injection: "enabled"
有了这两部分之后，我们就可以通过在Pod中添加以下注释，逐个应用地使用Istio：
sidecar.istio.io/inject: "true"
Istio可以在应用程序级别上彻底改变预期的行为。在盲目地将其部署到任何地方之前，您需要做出明智的选择，以使其运行在哪些应用程序上。另外，并非每个应用程序都与Istio兼容，因此请务必先检查。
逐步落地
在HelloFresh，我们将团队分为小组。每个小组都有自己的Kubernetes命名空间。如上所述，我们按名称空间启用sidecar注入名称空间，然后按应用程序启用。在为Istio启用应用程序之前，我们举办了研讨会，以使各个小组了解其应用程序发生的变化。由于我们采用“ownner”的制度，因此，团队可以在进行故障排除时了解流量。不仅如此，它还提高了公司内部的知识水平。我们还创建了与Istio相关的OKR，以跟踪我们的进度并实现我们的Istio落地目标。
配置控制层弹性伸缩
每个新的Sidcar都会给Istio控制平面增加更多的负载。Pilot连接到每个istio-proxy，每个istio-proxy都针对每个请求（减去一些缓存）使用Mixer进行检查并报告，因此这些控制平面组件变得非常关键。在将每个名称空间迁移到Istio之前，我们都已监控并调整了控制平面。在继续增加负载之前，这为我们提供了一个很好的检查点。我们必须定期调整每个控制平面组件的副本数，CPU和内存请求/限制。另外，我们还要关注每个istio-proxy消耗的内存量。请记住，尽管Envoy代理是相对轻量级的，但是要运行数千个并不是免费的，它可能会占用大量内存。我们已经在使用Kubernetes集群自动缩放器，因此我们的集群可以自动缩放，但是在计算运行服务网格的成本和性能开销时，请务必包括这些数据。
同样，所有生成的日志，指标和跟踪都会给我们的Graylog，Jaeger和Prometheus基础架构带来额外的负担。通常，我们必须为日志记录基础架构Jaeger，Cassandra数据库增加更多的容量，并在将更多名称空间加入Istio之前扩展Prometheus Pod。
结论
这些只是我们为确保Istio在整个公司中顺利落地而采取的一些高级步骤。请继续关注第2部分，我们将在其中深入了解实现细节。