Istio Pilot 组件介绍 在Istio架构中,Pilot组件属于最核心的组件,负责了服务网格中的流量管理以及控制面和数据面之间的配置下发。Pilot内部的代码结构比较复杂,本文中我们将通过对Pilot的代码的深入分析来了解Pilot实现原理。 首先我们来看一下Pilot在Istio中的功能定
引子 早在 2019 年底的 KubeConNA 中,Google API 基础设施的架构师 Louis Ryan 就透露了 Istio 控制平面架构将要进行调整的消息。从即将发布的 1.5 版本开始,原本多个独立的组件将会整合在一起,成为一个单体结构。相信每个开发者都能意识到架构调整会带来什么样的
背景 这是使用 istio 最常见的困境:在微服务中引入 envoy 作为代理后,当流量访问和预期行为不符时,用户很难快速确定问题是出在哪个环节。客户端收到的异常响应,诸如 403、404、503 或者连接中断等,可能是链路中任一 sidecar 执行流量管控的结果, 但也有可能是来自某个服务的合理
引子 Istio 1.5 是一个具有重大变革的版本。长久以来,面对社区对 Istio 的性能和易用性的诟病,Istio 团队终于正视自身的问题,在当前版本中彻底推翻了原有控制平面的架构,完成了重建。正如 Simplified Istio 文中所说: 复杂是万恶之源,让我们停止焦虑,爱上单体。 I
本文为翻译文章,点击查看原文。 译者注:Istio的架构在1.5版本中发生了翻天覆地的变化,控制平面从微服务回归单体,pilot、citadel、galley等控制平面组件整合成了单一的istiod二进制文件,同时饱受诟病的mixer同志终于在1.5中deprecated了,社区呼声很高的Wasm以
本文基于 Istio 1.5.1 版本,将为大家介绍以下内容: 什么是 sidecar 模式和它的优势在哪里。 Istio 中是如何做 sidecar 注入的? Sidecar proxy 是如何做透明流量劫持的? 流量是如何路由到 upstream 的? 在此之前我曾写过基于 Istio 1.
作为云原生服务网格领域的热门开源项目,Istio 可以为微服务提供无侵入的流量管理、安全通信、服务可见性等服务治理能力。目前越来越多的微服务项目开始考虑将自己的微服务基础设施向 Istio 进行迁移。 Istio 对 Kubernetes 具有较强的依赖性,其服务发现就是基于 Kubernetes
在上一篇文章一文带你彻底厘清 Kubernetes 中的证书工作机制中,我们介绍了 Kubernetes 中证书的工作机制。在这篇文章中,我们继续探讨 Istio 是如何使用证书来实现网格中服务的身份认证和安全通信的。 本文是对 Istio 认证工作机制的深度分析,假设读者已经了解 Service
内容摘要:从 1.2 版本开始,Istio 进入季度发布的节奏。5 月 21 日发布的 1.6 版本可以说是最准时的一次。我们是否可以理解 Istio 架构简化后的开发工作已经步入了正轨?这次的更新是否会带给我们惊喜?亦或是还有遗憾?让我们一一道来。 (感谢罗广明同学的审校和修改建议) 加法和减法
背景 Istio 从发布开始就使用 Envoy 作为自己的数据平面,充分利用了 Envoy 提供的服务发现、路由、熔断、负载均衡等功能。与此同时,Istio 项目也一直致力于提供一个便于灵活扩展的平台,以满足用户多样化的需求。在过去的一年半中, Google 的团队一直在努力用 WebAssembl
引言 2020 年 8 月 21 日,Istio 发布了 1.7 版本。除了介绍新版本的主要更新内容外,本文会重点分析 Istio 团队在产品更新策略上的激进态度和举措。是稳扎稳打做好向后兼容,带给用户所承诺的易用性;还是快刀斩乱麻,做进击的追风少年,且听笔者慢慢道来。 如约而至——Istio 1.
彭磊,陈凌鹏,腾讯云高级软件工程师,目前负责 TCM 服务网格产品,致力于打造云原生服务网格。本文首发于腾讯云+社区。 在腾讯,已经有很多产品已使用或者正在尝试使用 istio 来作为其微服务治理的基础平台。不过在使用 istio 时,也有一些对通信性能要求较高的业务会对 istio 的性能有一些担
Istio 作为目前 Service Mesh 方案中的翘楚,吸引着越来越多的企业及开发者。越来越多的团队想将其应用于微服务的治理,但在实际落地时却因为不了解 Istio 黑盒中的运行机制而左右为难,本文将基于 1.7 的源码讲解 Istio 的核心组件 Pilot 的结构及运行流程,希望对读者应用
了解了 Pilot 源码的基本结构和启动流程之后,我们可以深入探索 Pilot 究竟是怎么下发 xDS 协议的,以及协议的生成逻辑。相信大家都会有这些疑问:控制面与数据面详细的交互过程是什么?到底什么时候才会增量推送?增量推送判断的逻辑是什么? 非 Kubernetes 原生的服务(如存在于虚拟机的
本文译自 Request affinity with istio。 背景介绍 很多 Cash App 的应用都会有一系列运行在 AWS 的 Kubernetes 集群上的分布式服务。们的工程团队也在几年前开始把应用迁移到 Kubernetes 上面, 最近我们才开始使用 Istio 作为一种服务网格
本文译自 Istio 官方博客 Expanding into New Frontiers - Smart DNS Proxying in Istio。 DNS 解析是 Kubernetes 上任何应用基础架构的重要组成部分。当你的应用代码试图访问 Kubernetes 集群中的另一个服务,甚至是互联
1.8 是 Istio 在 2020 年发布的最后一个版本,按照 Istio 社区在今年初设定的目标继续推进,该版本主要有以下更新: 支持使用 Helm 3 进行安装和升级 正式移除了 Mixer 新增了 Istio DNS proxy,透明地拦截应用程序的 DNS 查询,实现智能应答 新增了 W
本文译自 Service Mesh Comparison: Istio vs Linkerd。 根据 CNCF 的最新年度调查,很明显,很多人对在他们的项目中使用服务网格表现出了极大的兴趣,并且许多人已经在他们的生产中使用它们。将近 69% 的人正在评估 Istio,64% 的人正在研究 Linke
注:本文是本人在云原生社区直播分享的内容整理,视频见 B 站,PPT 可以在 GitHub 下载。 Slime是网易数帆微服务团队开源的服务网格组件,它可以作为Istio的CRD管理器,旨在通过更为简单的配置实现Istio/Envoy的高阶功能。目前slime包含三个非常实用的子模块: 配置懒加载
本文为翻译文章,点击查看原文。 Istio 1.9 版本的重点是改善用户在生产中运行 Istio 的 Day2 操作。在用户体验工作组收集到的反馈意见的基础上,我们希望改善用户的稳定性和整体升级体验。稳定性的一个关键是明确 Istio 核心 API 和功能发布的功能状态,并增强它们的稳定性,使用户能