微服务网格（三）：Istio高级特性

最新推荐文章于 2024-07-08 22:26:04 发布

Docker_

最新推荐文章于 2024-07-08 22:26:04 发布

阅读量252

点赞数

本文链接：https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/101128587

版权

640?wx_fmt=jpeg

这是一系列博客中的第四篇--Kubernetes和Microservices Mesh。在我们的上一篇文章中，我们了解了Istio的基础知识，并了解了它对于设置和管理更复杂的云架构有多大用处。在分布式微服务设置中，Istio允许你使用服务网格来获得集中化带来的一些好处。今天，我们将研究更深层次的Istio功能，以展示服务网络的真正功能。

Istio很强大，但它也可能非常复杂。构建一个能够处理重负载的可扩展服务网络可能会非常充实。理想情况下，在本文结束时，你将更好地了解构建网格时可以使用的工具，并了解其复杂性。虽然大多数情况下你不需要手动配置sidecar或配置网络，但有助于了解底层发生的情况。使用与服务网格一样深的主题，你可以从工具中获得更多帮助，你将获得更好的帮助。

本着这种精神，今天我们将深入探讨Istio及其服务网格实施的4个关键组成部分：流量管理（Envoy），控制平面（Pilot），遥测组件（混合器）和安全组件（Citadel）。我们将依次查看这些组件，并解释它们如何适应更大的服务网格图。

Envoy

640?wx_fmt=png

你可能已经熟悉我们最后一篇关于Istio的sidecar代理了。在那里，我们展示了如何将代理添加到每个服务定义中，并将其部署在与服务本身相同的Pod中。即使有可能为sidecar插入不同的东西，我们也将Envoy和sidecar视为同义词。

sidecar充当来自你定义的单个服务的流量的主要网络网关：它接收指向服务的传入流量，并根据你在整体配置中设置的规则和策略对其进行路由。

sidecar需要处理来自两个来源的控制信息。第一个来自你，以及你在网格中部署的配置。当你传递配置（例如更改负载均衡参数，添加新节点和服务或新的网络路由信息）时，会将其放入Pilot，这是Istio关于应用状态的所有相关信息的真实来源。sidecar会定期检查Pilot，以确保他们拥有最新的配置信息，并根据本地规则进行任何调整。

控制信息的第二个来源是sidecar附加的应用程序。在作为负载均衡器的角色中，Envoy sidecar不断检查它附着的实例的健康状况并进行ping操作以确保它们仍处于活动状态。它还监控关键指标，如响应时间，以确保提出请求。Envoy将从池中删除不良实例，以确保不良部署或服务器错误不会导致整个服务崩溃。

添加sidecar有什么好处呢？除了内置的负载均衡和运行状况检查之外，你还可以通过有趣的方式配置流量，以帮助你深入了解应用的运行方式。例如，在部署具有重大代码更改的新版本时，你可以从开发环境的测试中学到很多东西。通常，你希望将少量生产流量引导到运行新代码的实例，以便你可以了解它在实际场景下的运行情况。

Envoy允许你定义一个配置，对不同版本之间的负载进行加权。这意味着你可以从仅将5％的流量引导到新版本的服务开始。将配置更改推送到Pilot时，它会更改sidecar上的负载均衡行为。最初，少量流量会转到新服务，你可以收集实验数据。当你获得信心时，你可以逐步从5％扩展到100％，然后再次迭代。

配置sidecar

640?wx_fmt=png

这种配置在实践中是什么样的？好吧，要将流量移动到不同的目的地，你只需在服务配置上设置权重参数，如下所示：

apiVersion: networking.istio.io/v1alpha3	
kind: VirtualService	
metadata:	
   name: helloworld	
spec:	
   hosts:	
      - hello1	
   http:	
      - route:	
         - destination:	
            host: hello1	
            subset: v1	
            weight: 75	
         - destination:	
            host: hello1	
            subset: v2	
            weight: 25	
---	
apiVersion: networking.istio.io/v1alpha3	
kind: DestinationRule	
metadata:	
   name: helloworld	
spec:	
   host: hello1	
   subsets:	
      - name: v1	
      labels:	
         version: v1	
      - name: v2	
      labels:	
         version: v2

这里我们有一个主机hello1，它有两个版本的目标，v1和v2。我们在开始时为v1分配75％的流量。按下配置后，你可以按预定义的时间间隔检查流量并再次更改参数。

Envoy让你可以很好地控制流量发送到各个目的地的方式。如果你的流量是突发性的并且压倒了你的硬件，则可以通过更改fault参数来引入延迟或故障：

apiVersion: networking.istio.io/v1alpha3	
kind: VirtualService	
metadata:	
   name: helloworld	
spec:	
   hosts:	
      - hello1	
   http:	
      - fault:	
         delay:	
            percent: 10	
            fixedDelay: 3s	
   route:	
      - destination:	
         host: hello1

Pilot

640?wx_fmt=png

Envoy sidecar的主要配对物是Pilot，它是网格中所有Envoy实例的集中管理器。Pilot是事实的核心来源，你可以在本地存储针对不同服务的所有规则以及它们的通信方式，以及存储运行内容的信息。Pilot通常是Istio控制平面的同义词，因为它管理和配置所有Envoy Proxies（尽管Citadel等其他组件在技术上也是控制平面的一部分）。

当然，当你试图理解网格时，Pilot是一个非常重要的难题，但实际上与Pilot相关的大部分工作都是由Envoy代理自己完成的。他们会定期检查网格的Pilot以确保它们具有最新的配置，并定期更新。当你更改网格的配置时，控制平面也是你正在与之交互的对象。这种职责划分是Istio的一个关键想法：Envoy代理人与Pilot协同行动，以生成你正在构建应用程序的服务。了解它们如何相互作用是理解网格概念的关键部分。

在我们的

测试Pilot

640?wx_fmt=png

熟悉网格的Pilot实例的最佳方法是查看已注入的sidecar并了解其状态。你可以通过运行命令获取网格中的服务列表以及控制它们的Pilot id：

istioctl proxy-status

然后弹出一系列服务及其ID，即Pilot id，和当前同步状态。列为“Synced”或“Synced（100％）”的sidecar是最新的，表明Pilot的最新配置已更改。状态“Not Sent”表示没有最近的配置更改，因此没有任何内容可以同步。状态“Stale”意味着sidecar没有响应变化。

如果确实存在同步问题，则proxy status命令还允许你提供服务ID并查看Pilot和Sidecar之间出错的同步详细信息。例如，如果上面的服务列表包含“hello-world-v2-5aa3f7abd-ppz2n.default”之类的ID，则可以运行以下命令：

istioctl proxy-status hello-world-v2-686a3b641-4r52s.default

你应该看到以下输出：

Clusters Match	
Listeners Match	
Routes Match (RDS last loaded at Fri, 24 May 2019 20:22:14 UTC)

请注意，proxy-status命令的输出随着Istio的不同版本（1.0.5,1.1.2和最新的1.1.7）而不同。在以前版本的Istio中，命令的输出包含完整的JSON，但从1.1.7开始，输出如上所示。你可能会看到不同的输出格式。

Pilot将格式化得显示差异，包括尚未对服务发送的配置更改，以及服务尚未确认修改的配置。

Mixer

640?wx_fmt=png

与Pilot类似，Mixer是一个Istio组件，可以对流量进行操作并应用你配置的规则。关键的区别在于，Mixer作为一个整体在网格层上运行，并允许你应用全局规则。这意味着你可以使用Mixer收集有关应用程序整体性能的遥测，或者对某些服务的使用方式设置全局限制。

了解Envoy和Mixer运行的不同方式非常重要。正如你对名称sidecar代理所期望的那样，Envoy被添加到你的应用程序中部署的每个服务中，并对来往该单个服务的流量进行操作。相比之下，Mixer作为一个整体在应用程序级别上运行，并应用你为整个应用程序设置的规则。

那可能是什么样的？这些规则的范围很广，从记录带有时间戳和IP地址的每个请求，到应用复杂的配额和白名单规则来保护安全性。Mixer是为你提供整体应用程序结构所期望的集中化的组件。想根据用户发送的请求数量为你的SaaS应用程序设置结算？你可以通过Mixer来做到这一点。想在任意时刻用户访问你的敏感信息时，就添加日志到外部服务？使用Mixer。

Mixer的另一个好处是它与第三方插件的集成。当然，有关应用程序的集中信息的主要来源非常适用于可视化活动或查询日志的工具。Mixer允许你将这些添加到Kubernetes并经常实时显示它收集的信息。日志记录平台Prometheus已预安装。

通常，这些工具可以让你的生活更轻松。通过Mixer，你可以深入了解曾经无法用于微服务部署的服务网格。此外，深入了解微服务部署正在做什么并不容易。你应该从那里的任何工具中获得所有帮助。

使用Mixer

640?wx_fmt=png

Istio准备好了可以部署的几个Mixer策略。要开始收集遥测数据，就像使用配置应用YAML文件一样简单。

kubectl apply -f samples/bookinfo/telemetry/metrics.yaml

输入流量将被记录并发送到中心Mixer实例。如果你的服务是实时的，你会立即看到结果。否则，你可以人为地向服务发送一些流量，然后查看结果。

查看流量的最简单方法是通过Prometheus，它是内置的Istio日志查询工具。设置Prometheus端口转发。

kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 9090:9090 &

然后，Prometheus将在本地计算机上的端口9090上运行。你可以从那里查询日志。

Citadel

640?wx_fmt=png

除了Envoy提供的可扩展性和Mixer提供的可视化外，云网状结构的主要优点之一是安全性。在Istio中，由主要安全组件Citadel处理。Citadel帮助管理现代微服务部署所需的密钥和证书。

管理微服务部署的安全组件通常是上升到服务架构层面的令人沮丧的部分之一。如果你想做双向TLS认证，你将被迫选择管理大量独立的，不断更改的自签名证书，否则你只能使用未加密的内容，并希望一切都往最好的方向发展。

Citadel为你做了很多工作。它会根据你的服务定义自动处理密钥的创建和存储，并使用Kubernetes的内置秘密管理基础架构对其进行管理。通过与Kubernetes交互，Citadel可以确保每个新服务都分配了证书，并且每个新的Envoy代理都配置为信任使用该新服务部署的证书。

这意味着不再有任何理由不使用双向TLS，这也是当前服务架构的最佳实践。每个服务在与其他服务共享数据时都会进行TLS握手，因此即使攻击者正在监视你的网络流量，你的数据也会被加密，没有暴露风险。

当然，自签名证书甚至双向TLS只是Citadel提供的能力。如果你已有适当的安全措施，它可以与第三方证书颁发机构进行交互并使用备用证书，并且可以根据需要为你设置更严格的策略，例如通过HTTPS的双向TLS。对于安全服务，它具有惊人的灵活性。

使用Citadel

640?wx_fmt=png

虽然它提供的安全功能可能非常复杂，但实际上使用Citadel非常容易。与Mixer一样，大部分魔法都会自动发生。你只需要激活正确的配置即可。

例如，要激活全局双向TLS，你需要更改网格的身份验证策略。这可以通过kubectl完成，只需使用以下内容：

kubectl apply -f - <<EOF	
apiVersion: "authentication.istio.io/v1alpha1"	
kind: "MeshPolicy"	
metadata:	
   name: "default"	
spec:	
   peers:	
      - mtls: {}	
EOF

然而，这只是故事的一半。虽然你已告知网状网服务仅接受使用TLS的传入流量，但它们未配置为使用TLS发送传出请求，因此它们目前无法进行通信。要解决此问题，请配置网络规则以对传出请求使用双向TLS：

kubectl apply -f - <<EOF	
apiVersion: "networking.istio.io/v1alpha3"	
kind: "DestinationRule"	
metadata:	
   name: "default"	
   namespace: "istio-system"	
spec:	
   host: "*.local"	
   trafficPolicy:	
      tls:	
         mode: ISTIO_MUTUAL	
EOF

然后测试你的服务。他们仍然应该能够相互通信，但现在他们是流量加密的。通过两个命令，你可以使网络更安全，流量更安全。

总结

640?wx_fmt=png

到目前为止，你应该更深入更广泛得熟悉了Istio提供的能力，以及它相对于通用服务网格模式的优势。关于Istio的一个优势是他很好地分离了问题关注点。每个组件，如Envoy sideca或Citadel密钥管理系统，都是独立且自包涵的。

这意味着Istio值得你继续花一些时间来了解各个组件的工作原理。在你理解了服务网格提供的能力时，它会带来回报并带来红利。

当然，单个开发人员几乎不可能真正掌握Istio所提供的所有内容。随着技术的发展，跟上变化和新的复杂性将成为一项全职工作。虽然这里的示例可以帮助你了解幕后发生的事情，但通常最好使用可用的工具来确保你采用正确的“Istio”方式。

原文链接：https://medium.com/faun/microservices-mesh-part-iii-istio-advanced-b969eef758bd

基于Kubernetes的DevOps实战培训

640?wx_fmt=png

基于Kubernetes的DevOps战培训将于2019年10月11日在上海开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：容器特性、镜像、网络；Kubernetes架构、核心组件、基本功能；Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则；Kubernetes的数据库、运行时、网络、插件已经落地经验；微服务架构、组件、监控方案等，点击下方图片或者阅读原文链接查看详情。