那么，每个人都在谈论的这个Istio是什么？
TL; DR /什么是Istio？
Istio是一个服务网格，可以在群集中的Pod和服务之间进行更详细，复杂和可观察的通信。
它通过使用CRD扩展Kubernetes API来进行管理。 它将代理容器注入所有容器，然后控制群集中的流量。
Kubernetes服务
从这里开始，您应该已经了解Kubernetes服务，您可以阅读本系列的第1部分。 现在，我们将很快探讨如何实施Kubernetes服务。 我认为这有助于了解Istio如何做相同和不同的事情。
> Image 1: Kubernetes native service request
图1显示了一个Kubernetes集群，该集群具有两个节点和4个Pod，每个Pod具有一个容器。 服务service-nginx指向nginx容器，服务service-python指向python容器。 红线显示了从pod1-nginx中的nginx容器向service-python服务发出的请求，该服务将请求重定向到pod2-python。
默认情况下，ClusterIP服务进行简单的随机或循环分发。 Kubernetes中的服务不存在于特定的节点上，而仅存在于整个集群中。 我们在图2中更详细地看到了这一点：
> Image 2: Kubernetes native service request with kube-proxy
图2显示了与图1相同的示例，只是更加详细。 Kubernetes中的服务由在每个节点上运行的kube-proxy组件实现。 该组件创建iptables规则，将请求重定向到Pod。 因此，服务就是iptables规则。 （还有其他一些不使用iptables的代理模式，但是过程相同。）
在图2中，我们看到Kubernetes API对每个kube-proxy进行编程。 每当服务配置或服务吊舱发生更改时，就会发生这种情况。 这样，Kubernetes API（以及整个主节点或控制平面）可能会崩溃，但服务仍然可以工作。
Kubernetes Istio
现在，我们来看配置了Istio的相同示例：
> Image 3: Istio Control Plane programs istio-proxy
图3显示了Istio控制平面附带的已安装的Istio。 还普遍看到的是，每个吊舱都有一个名为istio-proxy的第二个容器，该容器会在创建过程中自动注入到吊舱中。
Istio最流行的代理是Envoy，它具有惊人的功能。 尽管可以使用其他代理（例如Nginx），这就是为什么从现在开始我们仅将代理称为istio-proxy。
我们可以看到不再显示kube-proxy组件，这样做是为了保持图像清洁。 这些仍然存在，但是具有istio-proxy的Pod将不再使用kube-proxy组件。
每当配置发生更改或服务的Pod发生时，Istio Control Plane都会对所有istio-proxy边车进行编程。 类似于Kubernetes API编程图像2中所有kube-proxy组件的方式。Istio控制平面使用现有的Kubernetes服务只是为了接收每个服务指向的所有pod。 通过使用Pod IP地址，Istio实现了自己的路由。
在Istio Control Plane对所有istio-proxy边车进行编程之后，它看起来可能像这样：
> Image 4: Istio Control Plane programmed all istio-proxys
在图4中，我们看到Istio Control Plane如何将当前配置应用于群集中的所有istio-proxy容器。 为简单起见，这些还包括" ClusterIP"声明。 虽然ClusterIP是Kubernetes内部服务类型。 Istio将把Kubernetes服务声明转换成它自己的路由声明。 但这有助于想象图像中显示的情况。
让我们看看如何使用Istio发出请求：
> Image 5: Request made with Istio
在图5中，所有istio-proxy容器均已由Istio控制平面进行了编程，并包含所有必需的路由信息，如在图3/4中所示。 pod1-nginx的Nginx容器向服务service-python发出请求。
该请求被pod1-nginx的istio-proxy容器拦截，然后重定向到一个python pod的istio-proxy容器，然后将其重定向到python容器。
这里发生了什么？
图像1-5显示了具有nginx和python pod的相同示例Kubernetes应用程序。 我们已经看到了使用默认的Kubernetes服务然后使用Istio如何发生请求。
重要的是：无论使用哪种方法，结果都是相同的，不需要更改应用程序本身，而只需更改基础结构代码。
为什么要所有这些，为什么要使用Istio？
如果在使用Istio时没有任何改变（nginx pod仍然可以像以前一样连接到python pod），那么为什么首先使用Istio？
惊人的优势在于，现在所有流量都通过每个Pod中的istio-proxy容器进行路由。 每当istio-proxy接收并重定向请求时，它还会将有关该请求的信息提交给Istio控制平面。
因此，Istio控制平面确切地知道该请求来自哪个pod，存在哪些HTTP标头，从一个istio-proxy到另一个istio-proxy的请求花了多长时间等等。 在具有许多彼此通信的服务的群集中，这可以提高可观察性并更好地控制所有流量。
高级路由
Kubernetes内部服务只能对Pod进行轮询或随机分配服务请求。 使用Istio，可以使用更复杂的方法。 就像根据请求标头进行重定向一样，如果发生错误或到最少使用的服务。
部署
它允许将一定百分比的流量路由到某些服务版本，因此允许进行Green / Blue和Canary部署。
加密
可以对从istio-proxy到istio-proxy的Pod之间的群集内部流量进行加密。
监控/图形生成
Istio连接到Prometheus等监视工具。 它也可以与Kiali一起很好地显示所有服务及其流量。
> https://istio.io/docs/tasks/observability/kiali
追踪
由于Istio控制平面包含有关请求的数据负载，因此可以使用Jaeger进行跟踪和检查。
> https://istio.io/docs/tasks/observability/distributed-tracing/jaeger
多簇网格
Istio有一个内部服务注册表，可以使用现有的Kubernetes服务。 尽管也可以从群集外部添加资源，甚至可以将不同的群集连接到一个网格中。
> https://istio.io/docs/ops/deployment/deployment-models/#multiple-clusters
边车注入
为了使Istio正常工作，应将其作为网格的一部分的每个吊舱都需要注入istio-proxy边车。 可以在pod创建过程中针对整个名称空间自动完成此操作（通过Admission Controller挂钩），也可以手动完成。
Istio是否取代Kubernetes服务？
否。当我开始使用Istio时，我问自己一个问题，即它是否可以取代现有的Kubernetes服务。 答案是不。 Istio使用现有的Kubernetes服务获取其所有端点/吊舱IP地址。
Istio是否会取代Kubernetes Ingress？
（也许读入本系列第2部分的Ingress）
是。 Istio提供了新资源，例如Gateway和VirtualService，甚至还带有入口转换器istioctl convert-ingress。 一个很好的来源是https://istio.io/docs/concepts/traffic-management
图6显示了Istio网关如何处理入口流量。 网关本身也是一个组织代理组件。
> Image 6: Istio Gateway
控制平面组件
Istio控制平面由一些较小的组件组成，如Pilot，Mixer，Citadel和Galley。 如果您想更深入地学习，建议前往https://istio.io/docs/ops/deployment/architecture
如果Istio控制平面关闭，会发生什么？
由于所有istio-proxy边车均已编程，因此Istio控制平面可能会下降，交通如常。 但是不会应用配置更新或创建的新Pod。
尽管对于高级路由，例如将流量发送到使用最少的Pod或策略（https://istio.io/docs/tasks/policy-enforcement），所有Istio代理之间都需要通过Istio控制平面进行通信。 然后，每个istio-proxy都必须在允许请求之前先检查回到Istio控制平面。
为了使这些配置正常工作，我认为控制平面必须始终可用。 如果您有与此相关的链接，请随时添加评论。
接下来您能做什么？
我写了一个示例文章和有关Istio Canray部署的Github回购。
Istio提供了一个很好的示例应用程序，其中包含一些微服务。 如果您想深入了解Istio，这是一个不错的开始：https://istio.io/docs/setup/getting-started
如果您想更深入地学习，该视频也很棒。
概括
这是一个简单的介绍和广泛的概述，希望对人们有所帮助。 Istio无疑在Kubernetes之上增加了另一层次的复杂性。 尽管对于现代微服务架构，它实际上提供了比必须在应用程序代码本身中实现跟踪或可观察性更简单的方法。
(本文翻译自Kim Wuestkamp的文章《Kubernetes Istio simply visually explained》，参考：https://itnext.io/kubernetes-istio-simply-visually-explained-58a7d158b83f)
