在此配置中，每个集群都具备本人的Istio管制立体部署，而不是应用共享的Istio管制立体来治理网格，每个集群治理本人的端点。为了执行策略和确保安全，所有集群都处于共享的管理控制之下。

在共享管制立体部署模型下，多个Kubernetes近程集群连贯到在主集群中运行的共享Istio管制立体。近程群集能够与主群集位于同一网络中，也能够位于不同网络中。连贯一个或多个近程集群后，主集群的管制立体将治理所有服务端点上的服务网格。

如果在 Kubernetes 上应用微服务，那么像 Istio 这样的服务网格将施展出巨大作用。这里咱们先讨论一下 Istio 的体系结构。

微服务有很多长处，包含独立的拓展、隔离的业务逻辑、独立的生命周期治理以及繁难的分布式开发。这些长处同时也带来了一些弊病，例如微服务可能会减少安全漏洞，因为每个微服务都能够是攻打指标，这有形间减少了攻击面。如果入侵者进入网络，它们能够肆意地攻打单个微服务，因而仅爱护网络边界（network border）是不够…

微服务会将应用程序合成为多个较小的服务组件。与传统的一体化（Monolithic）架构相比，微服务架构将每个微服务视为独立的实体与模块，从根本上有助于简化代码和相干基础架构的保护。应用程序的每个微服务都能够编写在不同的技术堆栈中，并且能够进一步独立地部署、优化和治理。

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。Istio 1.6.7 公布Istio 1.6.7 是为了解决在 1.6.6 中引入的一个 bug。该 bug 可能会导致 在应用 Istio 1.6.6 时，某些 Pod 进入 CrashLoopBackOff 状态，无奈失常提供服务。修复后的外围代码如下，这里主…

本文节选自 ServiceMesher 社区出品的开源电子书《Istio Handbook——Istio 服务网格进阶实战》，作者罗广明，来自百度。