Istio Pilot 组件介绍 在Istio架构中，Pilot组件属于最核心的组件，负责了服务网格中的流量管理以及控制面和数据面之间的配置下发。Pilot内部的代码结构比较复杂，本文中我们将通过对Pilot的代码的深入分析来了解Pilot实现原理。 首先我们来看一下Pilot在Istio中的功能定位，Pilot将服务信息和配置数据转换为xDS接口的标准数据结构，通过gRPC下发到数据面的Envo

引子 早在 2019 年底的 KubeConNA 中，Google API 基础设施的架构师 Louis Ryan 就透露了 Istio 控制平面架构将要进行调整的消息。从即将发布的 1.5 版本开始，原本多个独立的组件将会整合在一起，成为一个单体结构。相信每个开发者都能意识到架构调整会带来什么样的后果。这一重磅消息也促使笔者决定著成此文，以告天下拥趸：变化有风险，落地需谨慎！ 原罪 解耦是罪？

背景 这是使用 istio 最常见的困境：在微服务中引入 envoy 作为代理后，当流量访问和预期行为不符时，用户很难快速确定问题是出在哪个环节。客户端收到的异常响应，诸如 403、404、503 或者连接中断等，可能是链路中任一 sidecar 执行流量管控的结果， 但也有可能是来自某个服务的合理逻辑响应。 特别的，当 service mesh 系统的维护者和应用程序的开发者来自不同的团队时，问

引子 Istio 1.5 是一个具有重大变革的版本。长久以来，面对社区对 Istio 的性能和易用性的诟病，Istio 团队终于正视自身的问题，在当前版本中彻底推翻了原有控制平面的架构，完成了重建。正如 Simplified Istio 文中所说： 复杂是万恶之源，让我们停止焦虑，爱上单体。 Istio 1.5 回归单体，无论架构和使用方式都发生了巨大变化。因此笔者决定对 1.5 的变化内容做深入

本文为翻译文章，点击查看原文。 译者注：Istio的架构在1.5版本中发生了翻天覆地的变化，控制平面从微服务回归单体，pilot、citadel、galley等控制平面组件整合成了单一的istiod二进制文件，同时饱受诟病的mixer同志终于在1.5中deprecated了，社区呼声很高的Wasm以Proxy-Wasm plugins的方式登上历史舞台，官方承诺在1.6版本中提供标准的wasm插件

本文基于 Istio 1.5.1 版本，将为大家介绍以下内容： 什么是 sidecar 模式和它的优势在哪里。 Istio 中是如何做 sidecar 注入的？ Sidecar proxy 是如何做透明流量劫持的？ 流量是如何路由到 upstream 的？ 在此之前我曾写过基于 Istio 1.1 版本的理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫

作为云原生服务网格领域的热门开源项目，Istio 可以为微服务提供无侵入的流量管理、安全通信、服务可见性等服务治理能力。目前越来越多的微服务项目开始考虑将自己的微服务基础设施向 Istio 进行迁移。 Istio 对 Kubernetes 具有较强的依赖性，其服务发现就是基于 Kubernetes 实现的。如果要使用 Istio，首先需要迁移到 Kubernetes 上，并使用 Kubernete

在上一篇文章一文带你彻底厘清 Kubernetes 中的证书工作机制中，我们介绍了 Kubernetes 中证书的工作机制。在这篇文章中，我们继续探讨 Istio 是如何使用证书来实现网格中服务的身份认证和安全通信的。 本文是对 Istio 认证工作机制的深度分析，假设读者已经了解 Service Mesh 以及 Istio 的相关基础概念，因此在本文对此类基础概念不再解释。对于 Istio 不熟

内容摘要：从 1.2 版本开始，Istio 进入季度发布的节奏。5 月 21 日发布的 1.6 版本可以说是最准时的一次。我们是否可以理解 Istio 架构简化后的开发工作已经步入了正轨？这次的更新是否会带给我们惊喜？亦或是还有遗憾？让我们一一道来。 （感谢罗广明同学的审校和修改建议） 加法和减法 Istio 1.6 的 Release note 开篇的标题用三个巨大的 Simplify 来表明态

背景 Istio 从发布开始就使用 Envoy 作为自己的数据平面，充分利用了 Envoy 提供的服务发现、路由、熔断、负载均衡等功能。与此同时，Istio 项目也一直致力于提供一个便于灵活扩展的平台，以满足用户多样化的需求。在过去的一年半中， Google 的团队一直在努力用 WebAssembly 技术为 Envoy 代理添加动态扩展，并推出了针对 Envoy 代理的 WebAssembly

引言 2020 年 8 月 21 日，Istio 发布了 1.7 版本。除了介绍新版本的主要更新内容外，本文会重点分析 Istio 团队在产品更新策略上的激进态度和举措。是稳扎稳打做好向后兼容，带给用户所承诺的易用性；还是快刀斩乱麻，做进击的追风少年，且听笔者慢慢道来。 如约而至——Istio 1.7.0 发布 就在几天前，Istio 发布了 1.7 版本，和 1.6 版本的发布时间正好间隔三个月

彭磊，陈凌鹏，腾讯云高级软件工程师，目前负责 TCM 服务网格产品，致力于打造云原生服务网格。本文首发于腾讯云+社区。 在腾讯，已经有很多产品已使用或者正在尝试使用 istio 来作为其微服务治理的基础平台。不过在使用 istio 时，也有一些对通信性能要求较高的业务会对 istio 的性能有一些担忧。由于 envoy sidecar 的引入，使两个微服务之间的通信路径变长，导致服务延时受到了一些

Istio 作为目前 Service Mesh 方案中的翘楚，吸引着越来越多的企业及开发者。越来越多的团队想将其应用于微服务的治理，但在实际落地时却因为不了解 Istio 黑盒中的运行机制而左右为难，本文将基于 1.7 的源码讲解 Istio 的核心组件 Pilot 的结构及运行流程，希望对读者应用 Istio 有所助益。 注：本文基于 istio release-1.7 分支分析，其他版本的代码

了解了 Pilot 源码的基本结构和启动流程之后，我们可以深入探索 Pilot 究竟是怎么下发 xDS 协议的，以及协议的生成逻辑。相信大家都会有这些疑问：控制面与数据面详细的交互过程是什么？到底什么时候才会增量推送？增量推送判断的逻辑是什么？ 非 Kubernetes 原生的服务（如存在于虚拟机的服务、 Dubbo 服务等）到底是怎么注册并且经过一系列转化下发至数据面的？ 带着这些问题，开始我们

本文译自 Request affinity with istio。 背景介绍 很多 Cash App 的应用都会有一系列运行在 AWS 的 Kubernetes 集群上的分布式服务。们的工程团队也在几年前开始把应用迁移到 Kubernetes 上面， 最近我们才开始使用 Istio 作为一种服务网格的解决方案来解决我们服务之间的通信。在这篇文章里，我会专注在 Istio 接管流量负载均衡这一功能是

本文译自 Istio 官方博客 Expanding into New Frontiers - Smart DNS Proxying in Istio。 DNS 解析是 Kubernetes 上任何应用基础架构的重要组成部分。当你的应用代码试图访问 Kubernetes 集群中的另一个服务，甚至是互联网上的服务时，在发起与服务的连接之前，它必须首先查找服务主机名对应的 IP 地址。这个名称查找过程通

1.8 是 Istio 在 2020 年发布的最后一个版本，按照 Istio 社区在今年初设定的目标继续推进，该版本主要有以下更新： 支持使用 Helm 3 进行安装和升级 正式移除了 Mixer 新增了 Istio DNS proxy，透明地拦截应用程序的 DNS 查询，实现智能应答 新增了 WorkloadGroup 以简化对虚拟机的引入 WorkloadGroup 是一个新的 API 对象，

本文译自 Service Mesh Comparison: Istio vs Linkerd。 根据 CNCF 的最新年度调查，很明显，很多人对在他们的项目中使用服务网格表现出了极大的兴趣，并且许多人已经在他们的生产中使用它们。将近 69％ 的人正在评估 Istio，64％ 的人正在研究 Linkerd。Linkerd 是市场上第一个服务网格，但是 Istio 的服务网格更受欢迎。这两个项目都是最

注：本文是本人在云原生社区直播分享的内容整理，视频见 B 站，PPT 可以在 GitHub 下载。 Slime是网易数帆微服务团队开源的服务网格组件，它可以作为Istio的CRD管理器，旨在通过更为简单的配置实现Istio/Envoy的高阶功能。目前slime包含三个非常实用的子模块： 配置懒加载: 无须手动配置SidecarScope，按需加载配置和服务发现信息 Http插件管理: 使用新的的C

本文为翻译文章，点击查看原文。 Istio 1.9 版本的重点是改善用户在生产中运行 Istio 的 Day2 操作。在用户体验工作组收集到的反馈意见的基础上，我们希望改善用户的稳定性和整体升级体验。稳定性的一个关键是明确 Istio 核心 API 和功能发布的功能状态，并增强它们的稳定性，使用户能够放心使用 Istio 的这些功能，这是 1.9 版本的另一个重点。 请关注我们的博客，了解我们的