关于 Jimmy Song | 宋净超

2024-09-06 19:14:52

上个月，因为参加 KubeCon China，我第一次前往香港，这让我有机会近距离审视这颗“东方明珠”。

我不记得之前在哪里看到一个说法，说是“香港是中国内地的一面镜子”。香港因其特殊的历史背景、经济发展轨迹以及在回归后的一系列表现等，许多人都在分析研究过程中会将香港的发展情况、社会治理经验教训等与内地进行关联和比较，认为其在某些方面可以为内地提供参考借鉴，就如同镜子一样反映出一些现象和问题的不同侧面及解决路径的可能性等。比如一些研究区域发展和社会治理的专家学者在相关论述中可能就会涉及到类似的观点表达。

香港与内地的不同

香港与内地存在着诸多不同，这些不同不光是表面上的：

香港拥挤的交通

香港岛是香港最繁华的地方，面积约 78.10 平方公里，这里集中了大量的商业、办公和住宅区域，吸引了众多人口和车辆，交通压力较大。在香港岛上，有一种极具特色的交通工具——叮当车，它也被称为有轨电车。叮当车全部分布在港岛北部狭长的地带，共有 6 条线路，全都经过港岛繁华热闹的地区，如铜锣湾、跑马地、中环等。它的车身通常为双层，造型古朴，当司机踩到踏脚时，车子会发出“叮当、叮当”的声响，故而得名。

在香港旺角的街头，人群如潮水般涌动。这里是繁华都市的缩影，喧嚣与热闹交织成一幅独特的画卷。摩肩接踵的人们，怀揣着各自的梦想与故事，在这个充满活力的地方穿梭。时尚的店铺、美味的小吃、璀璨的灯光，共同构成了旺角的魅力。每一个匆忙的脚步，每一张洋溢着笑容的脸庞，都在诉说着这座城市的无限可能。旺角，一个让人感受香港脉搏跳动的地方，永远充满着生机与活力。

香港岛地形以山地为主，地势较高，自北向南地势渐缓，环岛沿岸曲折，多美景港湾。岛上的主要山峰包括太平山、柏架山、奇力山等，其中太平山是香港岛的最高峰，海拔 554 米。

兰桂坊位于香港岛中西区中环，是一个聚集大小酒吧与餐馆的中高档消费区。它由德己立街、威灵顿街、云咸街、和安里、仁寿里及荣华里构成，宽约 20 米，长约 300 米。20 世纪中期，香港经济腾飞，商业高速发展，夜总会文化开始在香港流行，很多在香港工作或暂居的外国人渴求适合他们品味和要求的娱乐场所，兰桂坊便应运而生。每当夜幕降临，这里便会灯红酒绿，觥筹交错，置身这里让我仿佛置身东南亚，感觉跟泰国很像。

本地特色

我在香港 City walk 的时候发现的一些本地特色。

我发现很多建筑使用竹子搭建的脚手架，现在竹子脚手架在大城市中很少见到了。

我还在庙街看到算命一条街，还有一家店代客烧香。

最后本地的粤菜真的很好吃，我吃了一道炸猪排，外焦里嫩，口水直流。

总结

在香港的这次旅行中，我不仅领略了这座城市的繁华与多样性，还感受到了它作为一面“镜子”所带来的思考。香港的独特之处在于它东西方文化的交融、现代与传统的结合，以及其与内地在政治、经济、文化等方面的显著差异。无论是乘坐叮当车穿行在港岛繁华的街道，还是漫步在兰桂坊体验夜生活的丰富多彩，亦或是在街头巷尾发现本地的特色文化，这一切都让我更加理解为什么有人说香港是中国内地的一面镜子。通过这面镜子，我们可以看到一个不同的视角，这不仅让我们更好地理解香港，也能反思内地的许多方面，为未来的社会和经济发展提供更多的借鉴和启示。

2024-08-27 10:23:48

今年的KubeCon China是首次在香港举办的盛会，持续了三天。作为会议的参与者及一个论坛的主持人，我在这篇文章中将分享会议的精彩内容和对服务网格及网关技术的深入讨论。

主题焦点

本次 KubeCon 新增了 AI 与开发者主题，以下是部分重点内容：

1. 云原生技术在行业中的实际应用：特别是电动汽车和网络安全领域，如 Huawei 和 NIO 的共同探讨云原生技术如何加速电动汽车创新。

2. Kubernetes 社区的力量：详细讨论了中国 Kubernetes 社区的影响力及其在推动区域云原生活动中的角色。

3. 开源技术与人工智能的融合：探讨了中国及香港在开源与 AI 技术领域的先进地位及对区域技术创新的推动。

4. 服务网格与 API 网关的最新进展：包括服务网格的最新技术更新及其与 Kubernetes 调度器的协同工作提高系统吞吐量的策略。

5. 供应链安全的新策略：关注保障供应链安全的最新动态，特别是 SLSA 合规性的实践指南。

6. 多集群管理与边缘计算：探讨了在不同架构下进行有效管理与创新的策略。

7. AI 大模型的推理性能优化：讨论了无服务器架构下的 AI 大模型推理性能优化及相关技术进展。

Istio 与现代 API 网关：探索服务网格的未来

我与来自 Tetrate、阿里云和 Kong Inc.的行业领袖共同参与的圆桌讨论，深入探讨了 Istio 和 API 网关的最新进展及其融合带来的革新。

1. Istio 的革新：介绍了 Istio 1.123 版本中的 Ambient 模式优化，此模式作为新的架构选择，减少资源消耗同时提升性能。

2. Ambient 模式与 Sidecar 模式的实用对比：

   • 何时选择 Sidecar：需要高度隔离与详尽流量管理时。
   • 何时选择 Ambient：追求极致性能与资源效率时。

3. Ambient 模式的发展挑战：尽管有诸多优势，Ambient 模式在复杂流量管理与多租户环境中仍面临挑战。

4. 服务网格优化策略：讨论了服务网格的优化方法，如何提升云应用的性能与效率。

5. 服务网格与 API 网关的整合：展示了这两大技术如何共同作用，支持更复杂的部署与运维模式。

Istio 的未来展望

在徐中虎和何建鹏的分享中，我们了解到了 Istio 未来的可能发展方向：

• 双模驱动：Istio 将同时支持 Ambient 模式和传统的 Sidecar 模式。Ambient 模式适合追求性能和资源成本优化的用户，而 Sidecar 模式将为需要更全面功能的用户长期支持。

• Gateway API 的支持：Istio 对 Gateway API 的支持，为用户提供了更灵活的路由与策略配置选项。

• Waypoints 的策略应用：Waypoints 不必局限于 Istio 或 Envoy。通过使用 Gateway API 和 GAMMA，任何符合标准的实现都可以作为 Waypoint，这为服务网格提供了更大的灵活性和扩展性。

Sandwich Waypoint

他们着重介绍了 Sandwich Waypoint，这是一种在 Istio 内管理和引导流量的复杂方法，特别是在环境模式下。这种 Waypoint 代理模式旨在通过充当处理、转换和转发客户端和服务器之间流量的中介层来简化和提高流量路由的效率。它利用了双 zTunnel 设置，其中位于通信通道两端的每个 zTunnel 协作封装和解码流量。Waypoint 本身负责执行额外的功能，如流量整形、安全检查和协议转换，从而在没有传统边车开销的情况下丰富服务网格功能。这种方法允许 Istio 保持强大的流量管理和安全功能，同时优化资源利用率并减少延迟。

Sandwich Waypoint 支持：

• 流量重定向：可通过设置 istio.io/use-waypoint: {namespace}/{gateway-name} 注解，将目标服务、Pod 或命名空间内的流量重定向到同一个 Waypoint。
• Waypoint 部署：用户可以通过创建一个 Gateway 对象来部署 Waypoint。与原始的 Waypoint 实现不同，新的部署方式将包括相关联的服务和服务账户，不仅仅是 Waypoint 实例。
• 路由与政策配置：使用 Gateway API 进行路由和政策配置，这为用户和供应商提供了更多的自定义选项。

这是一种 Istio Ambient 模式中捕获七层流量模式，如下图所示。

Istio Sandwich Waypoint 捕获七层流量的步骤如下：

1. 通过 zTunnel 终止 HBONE 连接，到达 Waypoint，zTunnel 负责解码 HBONE 协议。
2. Waypoint 提取目的地地址、源地址等信息用于处理流量及确定转发位置。
3. Waypoint 扩展或解析传输层封装（TLV）数据，代理支持处理 TLV 以提供更多上下文。
4. Waypoint 与同位 zTunnel 通信，与服务端 zTunnel 协调确保流量正确转移。
5. 封装 HBONE，由服务端 zTunnel 发送到最终服务器目的地。实现 Istio 环境中服务的细粒度流量管理和路由并保持与现有网络协议兼容性。

Envoy Gateway 的前沿扩展

赵化冰在 KubeCon 上介绍了 Envoy Gateway 如何通过扩展 Kubernetes Gateway API 来增强功能与灵活性的演讲，涵盖了多种匹配与路由能力的扩展、新的资源和策略模型以及安全策略的细节。

• 网关 API 兼容性：Envoy 网关完全兼容网关 API，并提供了广泛的匹配和路由选项。这些包括 HTTP 主机和路径匹配、基于 HTTP 头的操作、权重负载均衡，以及对 gRPC、UDP 和 TCP 路由的支持。
• 高级流量管理策略：引入的 ClientTrafficPolicy 和 BackendTrafficPolicy 为用户提供了更细粒度的流量管理控制，适用于上游和下游连接，包括如限速、重试、负载均衡、断路器等功能。
• 安全与认证增强：新引入的 SecurityPolicy 支持 CORS、HTTP 基础认证、OIDC、JWT 认证，并能与各种身份提供商集成。它还提供了详细的访问控制，允许根据请求者的原始 IP、JWT 声明等进行授权。
• 自定义扩展功能：Envoy 网关支持通过 WASM（WebAssembly）和外部进程扩展来支持自定义扩展。这允许用户通过集成他们自己为特定用例和操作需求量身定制的扩展来增强网关的功能。
• 未来探索：未来版本预计将支持非 Kubernetes 环境部署，优化控制平面的内存使用，并扩展授权能力。

总结

通过本次会议我们了解了 Istio 的 Ambient 模式和 Envoy Gateway 的进展。这些技术的讨论不仅展望了未来趋势，也提供了实用的洞察，助力技术实施与创新。

2024-08-23 14:47:39

随着 8 月 20 日《黑神话：悟空》的正式发售，瞬间点燃了玩家们对 3A 游戏无尽的热情与讨论。在这篇随笔中，我将漫步于记忆的长廊，从孩提时代的掌中世界到今日的次世代主机，细数那些陪伴我的游戏时光，并深入探讨我心目中 3A 大作的独特魅力。

我的游戏养成史

在中国，游戏曾一度被视为教育的绊脚石，是家长眼中的洪水猛兽。然而，正是这些看似微不足道的游戏机，悄然开启了我探索未知世界的奇妙之旅。

掌上游戏机

在我十岁左右，我获得了一个第一台游戏机，一台类似 Gameboy 的掌上游戏机。

这是我最早接触的游戏机，还有我最早接触的游戏《俄罗斯方块》。

游戏机厅

也进过游戏机厅，小学时每年寒暑假前都要写保证书，名叫《暑/寒假公约》，其中一定会有一条——“不去游戏机厅”。我只去过一两次，这些游戏机需要投币。

这类游戏机上常玩的游戏是《街头霸王（Street Fighters）》。

小霸王学习机

小霸王学习机，可以更换卡带，接上电视就能玩，那时候经常用它玩高桥名人的《冒险岛》。

虽然号称是学习机，但是我没有见过有谁用它来学习的。

网吧

世纪之交的时候，网吧开始兴起，2000 年的时候我才第一次接触电脑，暑期的时候还参加电脑培训，练习过五笔打字，那时候也没学会，光顾着玩游戏了，我记得那时候还使用的是 3.5 英寸软盘，操作系统还是 Windows 98，使用的是笨重的 CRT 显示器。

2000 年左右，电脑上的游戏有《红色警戒》、《暴力摩托》、《三角洲部队》、《拳皇》，但是我最喜欢的还是《红色警戒 2》，从 2000 年一直到 2008 年。

最开始玩红警的时候年纪还小，是我自己一个人探索着玩，一开始做任务，甚至不知道怎样展开基地车，因为游戏是繁体字，很多我还看不懂。

单机游戏：2000 - 2008

除了红色警戒之外，我玩过的游戏还有《反恐精英》、《半条命》、《暗黑破坏神》、《仙剑奇侠传》、《魔兽争霸》，但这些游戏都不是我的菜，大多也玩不好，我还是钟情于红警，还有它的各种 mod。

网络游戏：2005 - 2008

在开始玩网络游戏之前，从来没有为玩游戏花过钱，因为中国的各种盗版游戏泛滥，网上到处都可以下载到。

在此之后就是网游的时代了，什么《传奇》、《大话西游》，腾讯的各种游戏比如《泡泡堂》、《劲舞团》、《地下城与勇士》、《QQ 飞车》这些我都玩过。

休闲游戏：2009 - 2013

曾经有一段时间，大概 2008 到 2013 年，校友网、QQ 空间上诞生的网页游戏，比如《抢车位》、《开心农场》等火爆一时，很多人定闹钟偷菜，也诞生了一些做网页游戏的网站。

还有一些流行的休闲游戏，比如《植物大战僵尸》也是我特别喜欢的一款游戏。跟它同时期的一些游戏也不错。

手机游戏：2014 - 2023

《开心消消乐》、《原神》、《辐射：避难所》。不过很多流行的手机游戏比如《绝地求生》、《穿越火线》我都没有玩过。

主机游戏：2023 至今

从 2009 年到 2023 年可以说我就没有再接触主机游戏和网游了，平时也很少玩游戏，直到 2023 年 12 月，我获得了我的第一台游戏主机 PS5，情况才发生了改变。

在此之前我曾玩过朋友的任天堂主机，但是并不是很喜欢任天堂主机的游戏，画面质量，游戏类型都不是我喜爱的。

但是从我接触的第一个 PS5 主机游戏《双人成行》开始，我对主机游戏甚至说对电子游戏的看法大大改观了。一起我对大部分游戏都提不起兴趣，感觉那些游戏就是打发打发时间，玩久了就很无聊，但是接下来的几款游戏让我体验到了什么是 3A 大作。

3A 大作

在拥有了 PS5 之后，玩什么游戏就是一个问题了。我订阅了二挡会员，所以起初我下载和玩了一些游戏库里的游戏。

双人成行

《双人成行》这是一个必须两个人配合才能完成的游戏，通过 PS5 的手柄来操控，终于让我体会到玩游戏的快感。这也是我第一次购买的实体游戏，我购买了游戏光盘。

地平线：西之绝境

《地平线：西之绝境》在 PlayStation 的二挡会员库里，所以我也下载和游玩了这款游戏。这款游戏以废土世界的旧金山为背景，里面有很多奇思妙想的未来机械生物。但是我对它的剧情和部落完全不感兴趣，只是享受其中打斗的乐趣，因为主角可以使用的武器和技能有很多。

对马岛之魂

《对马岛之魂》，故事发生在古代日本的对马岛，虽然景色很美，但是打斗风格及剧情让我提不起兴趣，一个日本人反抗蒙古侵略者的故事，我只玩了几个小时就卸载了游戏。

蜘蛛侠：Miles Morales

《蜘蛛侠：Miles Morales》，以纽约为背景，化身蜘蛛侠在纽约的城市上空飞来飞去，还有爽快的打斗，确实是一款很刺激的游戏，但是我对漫画人物为主角的游戏也不是特别喜欢，这款游戏的故事也比较简单，很快就通关了。

极地战嚎 6

《极地战嚎 6》，是一个虚构的现代国家 Yara 为背景（实际上是映射古巴）的游击队反抗政府军的故事，这是育碧旗下的游戏，已经出到第六代，有点像罐头游戏，完成主线任务也很快，我喜欢里面的各种枪械和野路子武器，剧情能够发人深省。

荒野大镖客 2

《荒野大镖客 2》是以 19 世纪末的美国西部为背景，玩了不到 1 个小时，实在无法带入剧情，对这个的故事和背景也不感兴趣，索性不玩了。

艾尔登法环

我玩过的最后一个 3A 大作是《艾尔登法环》，这是我第一次玩魂系游戏，其中的世界观，复杂的技能点加成，庞大的地图，开放世界都给我造成很大的困惑，尤其是强大的怪物，我一开始玩了几个小时，就死过无数次，被大树守卫很轻易就秒杀，甚至一个普通怪物三两下就把我干掉，我感觉玩这个游戏很痛苦，完全无法体会其中的乐趣，直到我了解可以购买卢恩，将角色升级到满级，然后玩这个游戏就可以轻松很多。

不过这个游戏偶尔还是会让人感觉很不适，尤其是各种迷宫一样的墓地，阴暗的环境，下水道，恶心的怪物。但是面对那些强大的怪物，当时死亡无数次后将其打败，可以体会到其中的快感，以及游戏庞大的地图，琳琅满目的武器，是我坚持玩下去的动力。

什么是我想要的 3A 游戏

在《黑神话：悟空》诞生之前，并没有一个让我眼前一亮的 3A 大作，它的出现就像一颗闪耀的新星。下面我将谈谈什么是我心目中的 3A 大作。

深入灵魂的叙事篇章

我心目中的 3A 大作，首先必须拥有一段深入人心的故事。它应当如同一部宏大的史诗，让玩家在跌宕起伏的剧情中与角色同悲共喜，体验一段段难忘的旅程。《黑神话：悟空》以其独特的中国神话背景，正是我所期待的那一抹亮色。

视觉与听觉的双重盛宴

高质量的美术与音乐是 3A 大作的另一大亮点。精美的画面、逼真的场景、细腻的角色设计，以及动人心弦的背景音乐和音效，共同构建了一个令人向往的虚拟世界。《黑神话：悟空》的预告片已经展现出了其在这方面的非凡实力。

流畅操作与无限玩法

流畅的操作手感与丰富的游戏玩法是 3A 大作的基石。无论是战斗系统的爽快感、解谜机制的巧妙设计，还是探索元素的无限可能，都应让玩家在享受游戏的过程中感受到无尽的乐趣与挑战。《黑神话：悟空》作为动作冒险游戏，其在这方面的表现无疑值得期待。

文化内涵的深度挖掘

对于国内玩家而言，游戏中融入的文化内涵往往能引发更深的共鸣与认同。《黑神话：悟空》以中国神话为背景，不仅展现了丰富的传统文化元素，更通过游戏这一载体将中华文化的魅力传播至世界各地。

持续的创新与支持

一款优秀的 3A 大作不仅需要在发布时惊艳四座，更需要在后续的开发与运营中保持活力与创新。持续的更新与支持不仅能够为玩家带来新鲜感与惊喜，更是游戏生命力的体现。《黑神话：悟空》作为国产 3A 的佼佼者，其后续的更新与支持同样值得我们期待。

结语

《黑神话：悟空》的发布不仅是对国产游戏的一次重大突破，更是对全球游戏界的一次震撼宣言。它让我看到了国产 3A 大作的无限可能。

今天我就购入了《黑神话：悟空》，在游玩一段时间后我会发布新的博客谈谈我的游玩体验。

2024-08-13 13:43:16

Istio 提供了对入口网关的强大而灵活的支持，利用 Envoy 代理在其 sidecar 模式下运行。尽管 Istio 专注于管理集群内服务之间的通信，Envoy Gateway 旨在将应用程序暴露给外部世界，处理用户请求，并支持高级功能，如 OIDC 单点登录。通过结合 Istio 服务网格的功能和 Envoy Gateway 的高级网关功能，可以增强整体应用程序的可访问性和安全性。

下图显示了 Istio 网格中入口网关的流量路径。

下一个图表显示了在引入 Envoy Gateway 后，流量如何从 Istio 网格的边缘流入内部网络。

准备 Envoy Gateway 与 Istio 之间的互操作性

要将 Envoy Gateway 用作 Istio 的入口网关，请考虑以下关键点：

• 在 Istio 安装期间避免启用入口网关。我们将手动安装并配置 Envoy Gateway 作为入口网关。
• 由于 Istio 和 Envoy Gateway 都使用 Envoy 作为代理，确保 Istio 将 Envoy sidecar 注入到 Envoy Gateway 的网关 Pod 中，以允许与 Istio 的数据平面安全通信。
• 配置由 Envoy Gateway 创建的 Envoy 代理的路由类型为 Service 而不是 Endpoint，以确保正确路由。

按照 快速启动文档 安装 Envoy Gateway。标记 Envoy Gateway 的命名空间以确保数据平面获得 Istio sidecar 注入：

kubectl label namespace envoy-gateway-system --overwrite=true istio-injection=enabled

配置 Envoy Gateway 的 sidecar 以不拦截进入网关的流量。注入的 sidecar 确保 Envoy Gateway 的组件及其创建的代理被包含在 Istio 网格中，并安装正确的证书以进行安全通信。

spec:
  ports:
  - port: 18000
    appProtocol: tls

应用补丁：

kubectl patch service -n envoy-gateway-system envoy-gateway --type strategic --patch-file control-plane-tls.yaml

配置 Envoy Gateway 不拦截入站流量：

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: data-plane-sidecars
  namespace: envoy-gateway-system
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyDeployment:
        pod:
          annotations:
            traffic.sidecar.istio.io/includeInboundPorts: ""
  routingType: Service

应用配置：

kubectl apply -f teg-sidecars-no-inbound.yaml

修改 GatewayClass 配置以将 sidecar 配置应用于 Envoy Gateway 数据平面中的所有 EnvoyProxy：

spec:
  parametersRef:
    group: gateway.envoyproxy.io
    kind: EnvoyProxy
    namespace: envoy-gateway-system
    name: data-plane-sidecars

应用补丁：

kubectl patch gatewayclass teg --patch-file gtwcls-use-envoyproxy.yaml --type merge

安装 Istio

使用 minimal 配置文件部署 Istio 以避免部署入口网关：

istioctl install --set profile=minimal -y

重启 Envoy Gateway 控制平面

在 Istio 的 sidecar 注入准备好后，重启所有 Envoy Gateway 控制平面的 pod：

for d in envoy-gateway envoy-ratelimit teg-envoy-gateway teg-redis;
	do kubectl rollout restart deployment -n envoy-gateway-system $d;
done

部署测试应用程序

在安装 Istio 后部署测试应用程序，以确保它们也接收到 sidecar 注入：

kubectl create namespace httpbin
kubectl label namespace httpbin --overwrite=true istio-injection=enabled
kubectl apply -n httpbin -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml

配置 Envoy Gateway

现在配置 Envoy Gateway 以处理边缘流量：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: apps
  namespace: httpbin
spec:
  gatewayClassName: teg
  listeners:
  - name: http
    protocol: HTTP
    port: 80

应用配置：

kubectl apply -f apps-gateway.yaml

部署应用网关，包括以下容器：

• istio-init：由 Istio 注入以修改 pod iptables。
• envoy：由 Envoy Gateway 控制，充当入口网关。
• istio-proxy：由 Istio 注入，负责与内部集群 pod 的通信。
• shutdown-manager：由 Envoy Gateway 控制，负责 pod 生命周期管理。

创建一个 HTTP 路由：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin
  namespace: httpbin
spec:
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: apps
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /httpbin/
    filters:
    - type: URLRewrite
      urlRewrite:
        hostname: httpbin.httpbin.svc.cluster.local
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - kind: Service
      name: httpbin
      port: 8000

应用路由配置：

kubectl apply -f httpbin-route.yaml

发送测试请求

获取网关的负载平衡器 IP 地址并发送测试请求：

export GATEWAY_URL=$(kubectl get svc -n envoy-gateway-system -l gateway.envoyproxy.io/owning-gateway-name=apps -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')
curl -v -H Host:www.example.com http://$GATEWAY_URL/httpbin/get

你应该能看到来自 httpbin 服务的正确响应：

*   Trying 34.41.0.90:80...
* Connected to 34.41.0.90 (34.41.0.90) port 80
> GET /httpbin/get HTTP/1.1
> Host:www.example.com
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< server: envoy
< date: Wed, 31 Jul 2024 08:21:58 GMT
< content-type: application/json
< content-length: 282
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 11
<
{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Host": "www.example.com",
    "User-Agent": "curl/8.7.1",
    "X-Envoy-Attempt-Count": "1",
    "X-Envoy-External-Address": "123.120.227.173"
  },
  "origin": "123.120.227.173",
  "url": "http://www.example.com/get"
}
* Connection #0 to host 34.41.0.90 left intact

启用严格 mTLS

通过应用以下配置启用严格 mTLS：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

应用配置：

kubectl apply -f strict-mtls.yaml

为网关启用 TLS

创建服务签名的根证书和私钥：

mkdir example_certs
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example_certs/example.com.key -out example_certs/example.com.crt

为 www.example.com 创建证书和私钥：

openssl req -out example_certs/www.example.com.csr -newkey rsa:2048 -nodes -keyout example_certs/www.example.com.key -subj "/CN=www.example.com/O=www organization"
openssl x509 -req -sha256 -days 365 -CA example_certs/example.com.crt -CAkey example_certs/example.com.key -set_serial 0 -in example_certs/www.example.com.csr -out example_certs/www.example.com.crt

为入口网关创建一个密钥：

kubectl create -n httpbin secret tls httpbin-credential --key=example_certs/www.example.com.key --cert=example_certs/www.example.com.crt

配置入口网关：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: apps
  namespace: httpbin
spec:
  gatewayClassName: teg
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: httpbin-credential

应用配置：

kubectl apply -f tls-apps-gateway.yaml

发送测试请求：

curl -v -H Host:www.example.com --resolve "www.example.com:443:$GATEWAY_URL" --cacert example_certs/example.com.crt "https://www.example.com:443/httpbin/get"

你应该可以通过 HTTPS 在网格内访问 httpbin 服务。

结论

通过将 Envoy Gateway 集成为 Istio 服务网格中的入口网关，你可以利用两者的优势：Istio 的强大服务网格能力和 Envoy Gateway 的高级网关功能。这种设置增强了你的应用程序的安全性、可扩展性和灵活性，提供了无缝且安全的用户体验。通过仔细的配置和正确的工具，管理服务网格内外的流量变得更加高效和有效，确保你的应用程序始终可访问并且安全。

2024-08-06 11:03:02

Istio 是一个功能强大的服务网格解决方案，提供零信任安全性、可观测性和高级流量管理等功能，且无需修改代码即可实现。然而，由于配置错误，我们经常会遇到意料之外的行为。本文将介绍几种常见的 Istio 配置错误，解析其背后的原理，并通过示意图展示如何识别和解决这些问题。我们还将介绍 Tetrate 提供的工具——TIS Config Analyzer，这是一种优化 Istio 操作效率和安全性的工具。

配置错误导致的事故案例

以下是两个由于配置错误导致的典型事故案例：

1. Amazon Web Services 2017 年停机事件：一次简单的输入错误导致了广泛的服务中断，影响了数千个在线服务和应用，突显了即使在成熟的云基础设施中，一个小小的配置错误也会引发严重后果。

2. GitLab 2017 年数据丢失事故：由于配置错误，GitLab 在进行数据库维护时误删除了大量生产数据。尽管备份机制被配置好，但错误的配置阻止了数据的及时恢复。

这些案例表明，正确的配置管理对于防止服务中断和数据丢失至关重要。

常见的 Istio 配置错误类型

Istio 配置错误主要分为以下几大类：

1. AuthorizationPolicy（授权策略）：命名空间不存在、仅允许 HTTP 方法和完全限定的 gRPC 名称、主机没有匹配的服务注册表条目、字段需要启用 mTLS、未找到服务帐户等。
2. DestinationRule（目标规则）：同一主机子集组合的多个目标规则、主机在服务注册表中没有匹配条目、子集标签在任何匹配主机中未找到等。
3. Gateway（网关）：同一主机端口组合的多个网关、网关选择器在命名空间中未找到匹配的工作负载等。
4. Port（端口）：端口名称必须遵循特定格式、端口的应用协议必须遵循特定格式等。
5. Service（服务）：未找到暴露与服务相同端口的部署等。
6. VirtualService（虚拟服务）：目标权重的路由没有有效的服务、指向不存在网关的虚拟服务等。

常见的 Istio 配置错误示例

在 Istio 的日常使用中，以下是一些最常见的配置错误：

1. 虚拟服务指向不存在的网关：

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: details
     namespace: bookinfo
   spec:
     hosts:
       - details
     gateways:
       - non-existent-gateway
   

   在这种情况下，details 虚拟服务试图通过一个不存在的 non-existent-gateway 进行路由，导致流量管理失败。

2. 虚拟服务引用不存在的服务子集：

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: details
     namespace: bookinfo
   spec:
     hosts:
       - details
   

   如果 details 服务没有定义相应的子集，请求将因无法找到正确的服务实例而被拒绝。

3. 网关找不到指定的服务器凭证：

   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: cert-not-found-gateway
     namespace: bookinfo
   spec:
     selector:
       istio: ingressgateway
     servers:
       - port:
           number: 443
           name: https
           protocol: HTTPS
         tls:
           mode: SIMPLE
           credentialName: "not-exist"
   

   这会导致 TLS 握手失败，因为指定的凭证 not-exist 不存在。

配置验证

为了减少由于配置错误而导致的服务中断风险，配置验证成为了一个不可或缺的步骤。配置验证可以分为以下两种：

• 静态配置验证：在配置应用到系统之前进行验证。这包括检查语法错误、完整性以及配置项的有效性。
• 按需配置验证：在配置已经应用但可能需要根据实时数据进行调整时进行验证。这种类型的验证有助于适应动态环境中的变化，确保配置的持续正确性。

推荐的配置验证工具

istioctl validate

istioctl validate 用于验证 Istio 配置文件（如 YAML 文件）的语法和基本结构，确保配置文件符合 Istio API 的规范。它可以在配置应用到集群之前检测出语法错误和格式问题，是一个静态分析工具，通常结合 CI 流程使用，防止无效配置文件应用到集群中。

istioctl analyze

istioctl analyze 是一个强大的诊断工具，用于分析 Istio 集群的运行状态和配置一致性。它不仅检查配置文件的语法，还可以检查集群中实际应用的配置，找出潜在的问题和冲突。istioctl analyze 提供动态分析功能，能够识别集群运行时的配置错误和潜在问题。

istioctl analyze 的配置流程如下：

1. 收集配置数据：首先，istioctl analyze 收集来自指定源的 Istio 配置数据。这些源可以是活动的 Kubernetes 集群，也可以是本地的配置文件。
2. 解析和构建模型：工具解析收集的配置数据，构建一个内部表示 Istio 配置的模型。
3. 应用分析规则：随后，它应用一系列预定义的规则来分析这个模型，检测潜在的配置问题。这些规则涵盖从安全漏洞到性能问题的各种潜在问题。
4. 生成报告：分析完成后，istioctl analyze 输出一个包含所有发现问题的详细报告。如果没有发现问题，它会通知用户配置看起来没有问题。

下面是 istioctl analyze 的工作流程图：

Kiali

Kiali 是管理和可视化 Istio 服务网格的重要工具，提供对网格健康状况、性能和配置状态的实时洞察。通过将 Kiali 集成到 Istio 环境中，可以通过以下方式增强配置安全性：

• 可视化：Kiali 提供服务网格的图形表示，更容易发现配置错误，如路由错误或缺失的策略。
• 验证：有助于验证 Istio 配置，突出显示如配置错误的网关或目标规则等问题，以防这些问题引起麻烦。
• 安全洞察：Kiali 提供对安全策略的可见性，确保 mTLS 和授权设置正确实施。

将 Kiali 与 istioctl validate 和 istioctl analyze 等工具结合使用，能确保更为稳健的方法来预防和解决 Istio 配置错误，进而提升服务网格的安全性和效率。

Tetrate 的 TIS 中的 Config Analyzer 工具介绍

为了帮助开发者和运维人员避免常见的配置失误，Tetrate 开发了 TIS Dashboard 中的 Config Analyzer 工具。该工具能够自动验证 Istio 的配置，根据最佳实践分析服务网格的配置问题，并提供优化建议。Config Analyzer 可以自动检测 Istio 服务网格中的配置问题，提供解释及解决方案，支持按需检测配置中的错误。

总结

正确配置 Istio 是确保服务网格健康运行的关键。通过了解和避免常见配置错误，以及利用如 Tetrate 的 TIS Config Analyzer 这样的高级工具，您可以确保 Istio 环境的稳定性和安全性。记住，一个小小的配置错误可能导致整个服务网格的故障，因此持续监控和审核配置是非常必要的。

参考

• Validation - kiali.io

2024-07-25 14:09:37

引言

近期，Wiz 研究团队发布了博客，揭示了 AI 服务中的租户隔离漏洞，引起了广泛关注。该研究详细阐述了多个 AI 服务供应商存在的安全缺陷，特别是 SAP AI Core 平台。通过合法的 AI 训练过程，研究人员能够绕过 Istio 服务网格中的流量劫持，进而横向移动并接管服务，获取客户的私人文件和云环境凭证。这些发现凸显了当今云服务和管理平台在确保隔离和沙盒环境方面面临的挑战。

在这个背景下，Istio 作为一个重要的服务网格解决方案，同样面临着类似的安全问题，尤其是在 sidecar 注入和流量管理等关键功能上。这篇博客旨在探讨如何保护 Istio 服务网格的安全，并提供一套全面的缓解措施。我们还将讨论多层安全策略如何有效增强 Istio 的安全性，以应对类似 Wiz 报告中提到的挑战。

概述

Istio 主要用于管理 Kubernetes 中的东西向流量，提供详细的流量管理功能，如请求路由、负载均衡和故障恢复策略。虽然 Istio 提供了流量加密、认证和授权等安全功能，但它本身不应被视为防火墙。为了确保 Istio 网格中的服务安全，除了使用 Istio 自身的安全功能，还需要结合底层网络和基础设施的安全措施，比如 CNI 和安全容器。此外，微分段技术可以用来实现更细粒度的隔离，提高安全性。

不论是 Sidecar 模式还是 Ambient 模式，都是通过劫持应用程序 Pod 的流量到数据平面代理中进行处理和转发的。如果没有成功拦截到应用程序流量或者被仿冒程序冒充了 Istio 而执行操作，就会有安全漏洞出现。

下图展示了通过绕过或仿冒 Istio 系统用户而造成的安全漏洞存在的位置。

接下来，我们将探讨“安全漏洞”产生的具体情况及应对策略。

绕过 Istio Sidecar 注入

在命名空间级别禁用注入

• 场景：应用团队滥用命名空间标签，在命名空间级别禁用 Istio Sidecar 注入。
• 缓解策略：平台团队抽象化应用部署，限制对原始 Kubernetes 命名空间资源的访问。
• 监控：使用策略引擎（如 OPA Gatekeeper）来确保命名空间标签的合规性，定期审查命名空间的配置。

在 Pod 级别禁用注入

• 场景：应用团队滥用 Pod 标签，在 Pod 级别禁用 Istio Sidecar 注入。
• 缓解策略：平台团队抽象化应用部署，限制对原始 Kubernetes Pod 资源的访问。
• 监控：使用 Admission Webhook 强制启用 Sidecar 注入，禁止使用排除标签，定期扫描和审计所有 Pod，确保所有需要的 Pod 都注入了 Sidecar。

绕过流量重定向到 Istio Sidecar

滥用流量重定向注解

• 场景：应用团队滥用 Pod 注解，排除特定的入站或出站端口或 IP 地址，从而绕过流量重定向。
• 缓解策略：平台团队抽象化应用部署，限制对原始 Kubernetes Pod 资源的访问。
• 监控：使用策略引擎来检测和警告不合规的注解使用，定期审查 Pod 注解。

滥用 Pod 的 UID

• 场景：应用团队滥用 UID 1337（sidecar 代理的 ID），绕过 Istio Iptables 重定向规则。
• 缓解策略：
  • 强制所有 Pod 指定非 1337 的 UID。
  • 检查所有容器镜像以检查 UID 1337 并拒绝这些镜像。此检查可以使用准入 Webhook 或由管理镜像注册表的中央团队来执行。
• 监控：禁用或限制 UID 1337 的使用，定期审计 Pod 的 UID 配置，确保没有绕过行为。

滥用 Pod 能力（NET_ADMIN、NET_RAW）

• 场景：应用团队滥用 NET_ADMIN 和 NET_RAW 能力，移除 Istio Iptables 规则。
• 缓解策略：平台团队启用 Istio CNI（以避免授予应用团队提升的权限），并限制对原始 Kubernetes Pod 资源的访问。
• 监控：定期审查和监控 Pod 的权限配置，确保没有越权行为。

绕过入站流量约束

滥用 PeerAuthentication

• 场景：应用团队创建一个针对每个命名空间/每个工作负载的 PeerAuthentication 资源，启用 PERMISSIVE 认证模式。
• 缓解策略：平台团队限制对原始 Istio PeerAuthentication 资源的访问。
• 监控：定期审查 PeerAuthentication 配置，确保所有入站流量都按照要求加密。

绕过出站流量约束

滥用 ServiceEntry

• 场景：应用团队创建一个 ServiceEntry，直接访问外部服务，而无需经过 Egress 网关。
• 缓解策略：平台团队限制对原始 Istio ServiceEntry 资源的访问。
• 监控：定期审查 ServiceEntry 配置，确保没有绕过行为。

滥用 ExternalName 服务

• 场景：应用团队创建一个类型为 ExternalName 的 Kubernetes Service，直接访问外部服务，而无需经过 Egress 网关。
• 缓解策略：平台团队限制对原始 Kubernetes Service 资源的访问。
• 监控：定期审查 Kubernetes Service 的类型配置，确保没有绕过行为。

无法控制地更改 Istio Sidecar 配置

滥用 Sidecar 资源

• 场景：应用团队创建一个针对每个工作负载的 Istio Sidecar 资源，并将 outboundTrafficPolicy 字段设置为 ALLOW_ANY（覆盖可能的全局值 REGISTRY_ONLY）。
• 缓解策略：平台团队限制对原始 Istio Sidecar 资源的访问。
• 监控：定期审查 Sidecar 资源配置，确保没有覆盖全局设置的行为。

滥用 EnvoyFilter

• 场景：应用团队创建 EnvoyFilter，导致与现有 Istio 对象冲突，从而引发 DoS 攻击或违反安全策略。
• 缓解策略：平台团队限制对原始 Istio EnvoyFilter 资源的访问。
• 监控：定期审查 EnvoyFilter 配置，确保没有不当使用行为。

服务网格应作为分层防御的一部分

服务网格被描述为现有安全模型的一个补充层，通过在传统安全控制之上添加更细粒度的安全策略来增强微服务的安全性。然而，文章强调了服务网格无法独立保障微服务的全面安全，而是应当作为整体安全策略的一部分。

服务网格主要通过在每个服务实例旁部署一个轻量级的代理（sidecar），来管理和控制网络流量。这使得它能够在网络层面上实现精细的流量控制和策略执行，如流量加密、身份认证和授权。尽管服务网格能够提供诸如流量控制、服务发现和断路器等功能，这些功能本质上是对网络流量的管理，无法解决所有安全问题。例如，它不能替代应用层防火墙、入侵检测系统和数据安全等更传统的安全措施。

此外，服务网格依赖于正确的配置和管理，配置不当可能导致安全漏洞。因此，尽管服务网格是现代微服务架构中不可或缺的一部分，它应该与传统的安全措施相结合，共同构成一个全面的、多层次的安全策略框架。参考如何通过服务网格增强微服务的安全性以进一步了解如何加强服务网格的安全。

长期解决方案和社区合作

Istio 社区每年都会进行一次安全审计，见 2021 年、2022 年 的安全审计结果。从结果中我们可以看到，Istio 的安全态势有了很大的提升。确保你的 Istio 服务网格符合安全最佳实践。另外，你还需要关注 Istio CVE 公告栏，或者使用如 Tetrate Istio Subscription 这类工具来扫描 Istio 服务网格的各种 CVE，部署符合 FIPS 并经过 FIPS 验证的 Istio 发行版。

结论

服务网格通过在应用程序外部管理控制流，为微服务架构提供了额外的安全层。这允许在不影响应用程序性能的前提下，加强服务之间的通信安全。在部署服务网格时，推荐使用 Istio 的 Egress Gateway 来管理出口流量，结合 Kubernetes 的 NetworkPolicy，确保所有出口流量都必须经过网关，从而防止潜在的数据泄露和其他安全威胁。

参考

• How to enforce egress traffic using Istio’s authorization policies - tetrate.io
• Istio Security Best Practice - istio.io
• Optimize Traffic Management and Security with These Service Mesh Best Practices - tetrate.io
• Istio publishes results of 2022 security audit - istio.io
• Announcing the results of Istio’s first security assessment - istio.io

2024-07-23 15:24:08

上个周末，我从北京自驾前往乌兰察布，经历了一段全程 995 公里的旅程。周五晚上，我从北京东四环出发，驶过 295 公里，抵达乌兰察布兴和县，暂住一晚。清晨，我们满怀期待地出发，迎接乌兰哈达火山的壮丽景观。

乌兰哈达火山地质公园是一个免费开放的景区，景区公路和一些配套设施还在建设中。我从北面进入公园，首先到达的是 3 号火山。

当天虽然温度只有 31°C，但紫外线格外强烈。11 点钟，我们开始攀登 3 号火山。烈日当空，紫外线炙热，我穿着防晒服，T 恤已经被汗水浸湿，汗珠如豆粒般大小不断滴落，仿佛在与这片广袤的天地进行一场激烈的对抗。当地的海拔达到了 1600 米，空气清新而稀薄。

乌兰哈达火山地质公园

乌兰哈达火山地质公园位于内蒙古乌兰察布市，这里保存着一片完好的火山群，展现着大自然的鬼斧神工和地质变迁的壮丽画卷。火山群由多座火山组成，其中最著名的 3 号和 6 号火山，被分别称为“北炼丹炉”和“南炼丹炉”。

我们首先攀登了 3 号火山，从山顶俯瞰，火山口清晰可见，周围的火山岩石展现出奇特的地质构造，仿佛在诉说着那段遥远而神秘的历史。随后，我们自驾途径 6 号火山，由于交通堵塞，不得不掉头返回。3 号火山的南面已经被挖得面目全非，只有从北面看才能看出完整的火山形状。

夜晚，我们住在现代化的“蒙古包”里。蒙古包的构造独特，圆形设计不仅抵御风沙，还能保持内部温暖。现代蒙古包则在传统基础上融合了现代元素，提供了更为舒适的居住体验。

火山岩石具有独特的地质特征，这些岩石形成于数百万年前火山喷发的熔岩冷却后。它们质地坚硬，颜色多样，从黑色到红色不等。这些岩石不仅是大自然的杰作，也是地质学研究的宝贵材料。

生态保护红线

生态保护红线是为了保护生态系统、维护生态安全而划定的严格保护区域。乌兰察布地区的生态保护红线确保了火山地质公园和周边生态环境的原始风貌得以保存。这片大地上的生态保护红线，像是一道无形的屏障，守护着这片古老而神秘的土地。

卓资县，位于乌兰察布的偏远角落。由于经济发展滞后，人口逐年减少，许多村庄因此被废弃。这些废弃的村庄见证了人口迁移和城镇化的历史变迁，仿佛在无声地诉说着一个个时代的故事。

上图中上方左二为战国赵长城遗址，公元前 300 年，赵武灵王修建的长城，今复何在？

赵长城，为赵武灵王时所筑，故也称赵武灵王长城。据《史记·匈奴列传》记载：“赵武灵王变俗，胡服，习骑射，北破林胡、楼烦，筑长城，自代并阴山下，至高阙为塞。”

拍摄于乌兰察布市察哈尔右翼后旗四胜路马房沟附近的树林里，成百上千只鸟时而隐藏在树林里，时而飞到远处的山坡上，蔚为壮观。

我们在生态保护红线的地图上采用投飞镖的方式随机造访一个村子，投中了胜利村。几经辗转，我们发现胜利村在手机地图上甚至没有路线指引。最终到达的村子已经不复存在，只留下一些荒废的房子，静静地伫立在这片广袤的土地上。

总结

这次乌兰察布之旅让我深刻感受到了内蒙古独特的自然景观和人文历史。从壮丽的火山地质公园到失落的乡村，每一处景点都给我留下了深刻的印象。这次旅程不仅让我放松了身心，也让我对生态保护和人口流动有了更多的思考。在这片辽阔的土地上，我看到了自然的壮丽与人类历史的沉浮，内心也随之变得更加丰盈和宁静。

2024-07-22 16:43:16

TEG 简介

Tetrate Enterprise Gateway（TEG）是基于 Envoy Gateway (EG) 的企业级解决方案，专门针对 Envoy Proxy 设计，通过 Kubernetes Gateway API 提供更易于消费的 Envoy 代理配置和管理包。TEG 结合了 Kubernetes Gateway API 的特性，支持在 Kubernetes 中轻松暴露服务和应用程序。

TEG 相对于 Envoy Gateway 的主要新增特性包括：

1. 全局速率限制（Rate Limiting）：TEG 支持基于 IP 5-tuple、请求头等进行流量控制，需要通过 Redis 实例管理。
2. WAF 功能（Web Application Firewall）：TEG 提供了与 mod_security 兼容的 WAF 功能，增强了安全防护能力。
3. OIDC/OAuth2认证：支持在网关级别进行 OIDC/OAuth2 认证，应用程序可以按路由配置认证方式。
4. 使用 Kubernetes Gateway API：相较于其他 API，Kubernetes Gateway API 的设计更加现代，结合了众多 Ingress 实现的经验，将网关的配置与流量的路由分离，使平台所有者可以管理网关，而应用团队可以掌控流量路由。

TEG 将 Envoy 的高级网络流量处理能力带入 Kubernetes 环境，提供了一种简化的方法来部署和管理负载平衡、API 网关功能、安全控制等，同时支持现代的、开放的应用程序暴露 API，如 Kubernetes Gateway API。这些特性使 TEG 成为一个功能丰富、易于管理的企业级网关解决方案。

TEG 的能力

Tetrate Enterprise Gateway for Envoy (TEG) 构建于 Envoy Gateway 项目之上，提供了一种易于使用和操作的入口，具有先进的按请求流量控制功能、与现有环境的轻松集成，以及一流的可观测性，以理解应用流量和入口健康状况。

易于安装、操作和升级

TEG 从头到尾注重易用性：从首次安装到启用应用团队，从故障排查到执行升级。TEG 的初始安装只需几分钟，你就可以开始使用高级功能，如速率限制、单点登录和金丝雀流量路由。TEG 还简化了运维流程，与你现有的指标、跟踪和日志记录管道相适应，我们还提供了一个完整的、预配置的可观测性堆栈，以评估 EG 产生的数据，并帮助你计划如何将 TEG 集成到你的现有指标堆栈中。

操作性：一流的功能

TEG 由在生产环境中运行大型、关键系统的经验丰富团队构建。TEG 简化了漏洞检查和持续升级过程，与你现有的指标和跟踪提供商轻松集成，并为你现有的 Grafana 部署提供了一套强大的入口可观测性仪表板。

与现有的环境集成

TEG 不仅适用于绿地部署的启动，还可以直接与传统环境以及现代云原生环境集成。它可以帮助你在现有的应用生态系统和你正在构建的云原生目标之间架起桥梁。

引入现有的可观测性堆栈

你的组织可能已经有一个可观测性系统，你的应用和运营团队已经训练有素地使用它。TEG 可以轻松地嵌入到现有的基础设施中，并在你的组织中运行。TEG 将使 Envoy 的丰富指标集导出，让你的应用团队对其应用流量的行为有最佳的洞察，并看到他们所做配置更改的效果。TEG 还为运行它的平台团队提供了仪表板和警报功能，使你能够自信地操作并快速解决发现的问题。

简单的负载平衡

Envoy 非常强大，但要使其启动并运行简单用例可能很难——像 Istio 这样的系统提供 Envoy 入口管理作为更广泛功能套件的一部分，也附带了许多与简单、流畅的操作体验相冲突的额外功能。这就是 Envoy Gateway 存在的原因：使 Envoy 的强大功能易于用于入口用例。

简单的 API 网关

组织中绝大多数 API 网关的使用归结为三件事：认证发起请求的用户；限制用户对服务的访问；在此 API 端点的服务实例之间进行负载平衡。TEG 简化了在传统和云原生环境中完成这三项任务的过程。

TEG 的架构

下图展示的是 TEG 的架构图。

从架构图中可以看出，Tetrate Enterprise Gateway for Envoy (TEG) 的架构设计包括以下主要组件和流程：

主要组件

1. Kubernetes Cluster

   • Envoy Gateway：作为控制平面，配置和管理 Envoy 代理，消费 Kubernetes Gateway API 的配置。
   • Metrics Collection：使用 Prometheus 或 OpenTelemetry (OTEL) 作为指标收集点，用于监控 Envoy Proxy 的性能和健康状态。

2. Envoy Proxy

   • 作为数据平面，直接处理所有进入的流量，支持基于 Kubernetes Gateway API 的配置。

3. Coraza WAF

   • 作为 TEG 的一部分部署，执行 WAF 规则以保护应用免受恶意请求攻击。

4. Redis Rate Limit Store

   • 作为全局速率限制的存储解决方案，用于跨所有 Envoy 实例维护统一的速率限制计数。

5. Your OIDC Server

   • 处理 OAuth2.0 和 OIDC 认证流程，确保只有经过认证的用户可以访问特定的路由和服务。

工作流程

1. 流量入口

   • 所有外部流量首先通过上游的负载均衡器，然后被路由到 Envoy Proxy。

2. Envoy Proxy 处理

   • Envoy Proxy 根据 Kubernetes Cluster 中的 Envoy Gateway 的配置处理流量。
   • 配置信息包括路由规则、安全策略（如 WAF 和速率限制）等。

3. 安全和认证

   • Coraza WAF：在流量到达应用前，根据配置的 WAF 规则进行检查和过滤，提高安全性。
   • OIDC 认证：OIDC Server 处理认证，Envoy Proxy 根据 OIDC Server 的验证结果决定是否允许访问。

4. 速率限制

   • 使用 Redis 存储进行速率限制，Envoy Proxy 将根据从 Redis 获取的数据执行速率限制策略。

5. 性能监控

   • Envoy Proxy 的性能和健康状态通过集成的指标收集系统（Prometheus 或 OTEL）进行监控。

配置和管理

• 用户可以通过 Kubernetes Gateway API 定义和应用 Envoy Proxy 的配置。
• 这包括定义专用网关的具体配置，如安全规则、路由策略等。

这种架构设计利用了 Kubernetes 的灵活性和扩展性，并通过 Envoy 提供了强大的流量管理和安全功能。

部署 TEG

执行下面的命令部署 TEG V0.0.0：

export REGISTRY="oci://docker.io/tetrate"
export CHART_VERSION="v0.0.0-latest"
helm install teg ${REGISTRY}/teg-envoy-gateway-helm \
 --version ${CHART_VERSION} \
 -n envoy-gateway-system --create-namespace

检查部署：

kubectl get pod -n envoy-gateway-system

你将看到下面的结果：

NAMESPACE              NAME                                                       READY   STATUS    RESTARTS        AGE
envoy-gateway-system   envoy-gateway-596dfbcb88-tx7xb                             1/1     Running   0               3m55s
envoy-gateway-system   envoy-ratelimit-674b8c955c-jhlfn                           2/2     Running   2 (3m48s ago)   3m54s
envoy-gateway-system   teg-envoy-gateway-64fd8c8fbb-59b4l                         1/1     Running   0               3m55s
envoy-gateway-system   teg-redis-86bb7d9b9d-27n44                                 1/1     Running   0               3m55s

部署示例应用：

kubectl create namespace httpbin
kubectl apply -n httpbin -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml

部署 Envoy Proxy：

cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: dedicated-gateway
  namespace: httpbin
spec:
  gatewayClassName: teg
  listeners:
    - name: http
      protocol: HTTP
      port: 80
EOF

然后你会在 envoy-gateway-system 命名空间下看到一个新的 Envoy 代理。

部署 HTTPRoute，给网关配置路由：

cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin
  namespace: httpbin
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: dedicated-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /httpbin/
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /
      backendRefs:
        - group: ""
          kind: Service
          name: httpbin
          port: 8000
EOF

这个路由配置中有一个 URLRewrite filter，重写 URL 前缀，去掉了 /httpbin/ 部分。

发送流量测试：

export DEDICATED_GATEWAY_IP=$(kubectl get gateway/dedicated-gateway -n httpbin -o jsonpath='{.status.addresses[0].value}')
curl -i http://${DEDICATED_GATEWAY_IP}/httpbin/get

作为 Istio 的入口网关

Istio 提供了成熟且灵活的入口网关支持，基于与 Tetrate Enterprise Gateway（TEG）相同的 Envoy 代理。Istio 主要专注于处理集群内服务之间的通信。相较之下，TEG 设计用于向外界暴露应用，处理人类用户的请求，并支持如 OIDC 单点登录等高级功能。通过结合 Istio 网格和 TEG 的高级网关功能，两者可以共同使用，以提升整体应用的可访问性和安全性。

以下图示展示了 Istio 网格中入口网关的流量路径。

下图展示了在引入 TEG 之后，流量如何从 Istio 网格边缘进入到内部。

将 TEG 集成到 Istio 网格中，通过在 TEG 上配置 sidecar 来颁发证书，同时避免 sidecar 拦截 TEG 中的流量。然后通过 Envoy Gateway 控制入口网关的流量路径。

为 TEG 与 Istio 的互操作做准备

为了使 TEG 作为 Istio 的入口网关，应注意以下关键点：

• 在安装 Istio 时，避免启用 Ingress Gateway。我们将手动安装并配置 TEG 作为 Istio 的入口网关。
• 由于 Istio 和 TEG 都使用 Envoy 作为代理，我们需要让 Istio 为 TEG 的网关 Pod 注入 Envoy sidecar，以便 TEG 可以安全地与 Istio 数据平面通信。
• 配置 Envoy Gateway 创建的 Envoy 代理的路由类型为 Service 而非 Endpoint，确保 Envoy 代理能正确找到路由。

为 TEG 的命名空间添加标签，以确保数据平面获得 Istio sidecar 的注入。

kubectl label namespace envoy-gateway-system --overwrite=true istio-injection=enabled

我们还需要配置 TEG 的 sidecar，使其不处理进入网关的 Envoy 流量。注入 sidecar 的目的是使 Envoy Gateway 的组件及其创建的代理能够被纳入 Istio 网格，并挂载正确的证书进行安全通信。

spec:
  ports:
  - port: 18000
    appProtocol: tls

kubectl patch service -n envoy-gateway-system envoy-gateway \
     --type strategic --patch-file control-plane-tls.yaml

配置 Envoy Gateway 中的 sidecar 不拦截流量：

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: data-plane-sidecars
  namespace: envoy-gateway-system
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyDeployment:
        pod:
          annotations:
            traffic.sidecar.istio.io/includeInboundPorts: ""
  routingType: Service

kubectl apply -f teg-sidecars-no-inbound.yaml

修改 GatewayClass 的配置，将上述 sidecar 配置应用到 Envoy Gateway 数据平面的所有 EnvoyProxy 上：

spec:
  parametersRef:
    group: gateway.envoyproxy.io
    kind: EnvoyProxy
    namespace: envoy-gateway-system
    name: data-plane-sidecars

kubectl patch gatewayclass teg --patch-file gtwcls-use-envoyproxy.yaml --type merge

安装 Istio

使用 minimal profile 部署 Istio，从而不部署 Ingress Gateway：

istioctl install --set profile=minimal -y

重启 TEG 控制平面

现在 Istio 的 sidecar 注入已准备就绪，我们将重启所有 TEG 控制平面 Pod，它们将带有 sidecar 重新启动。

for d in envoy-gateway envoy-ratelimit teg-envoy-gateway teg-redis; \
    do kubectl rollout restart deployment -n envoy-gateway-system $d; \
    done

部署测试应用

此步应在安装 Istio 之后进行，以确保它们也获得 sidecar 的注入。

kubectl create namespace httpbin
kubectl label namespace httpbin --overwrite=true istio-injection=enabled
kubectl apply -n httpbin -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml

配置 TEG

现在我们配置 TEG 处理边缘流量。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: apps
  namespace: httpbin
spec:
  gatewayClassName: teg
  listeners:
  - name: http
    protocol: HTTP
    port: 80

kubectl apply -f apps-gateway.yaml

部署应用网关，包含以下容器：

• istio-init：由 Istio 注入，负责修改 pod 中的 iptables
• envoy：由 TEG 控制，作为入口网关
• istio-proxy：由 Istio 注入，负责与集群内部 pod 联系
• shutdown-manager：由 TEG 控制，负责 Pod 启停

创建 HTTP 路由：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin
  namespace: httpbin
spec:
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: apps
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /httpbin/
    filters:
    - type: URLRewrite
      urlRewrite:
        hostname: httpbin.httpbin.svc.cluster.local
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - kind: Service
      name: httpbin
      port: 8000

kubectl apply -f httpbin-route.yaml

发送测试请求

获取网关的负载均衡器 IP 地址，并发送测试请求：

export GATEWAY_URL=$(kubectl get svc -n envoy-gateway-system -l gateway.envoyproxy.io/owning-gateway-name=apps -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')
curl -v -H Host:www.example.com http://$GATEWAY_URL/httpbin/get

你将看到来自 httpbin 服务的正确响应，如下所示：

*   Trying 34.41.0.90:80...
* Connected to 34.41.0.90 (34.41.0.90) port 80
> GET /httpbin/get HTTP/1.1
> Host:www.example.com
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< server: envoy
< date: Wed, 31 Jul 2024 08:21:58 GMT
< content-type: application/json
< content-length: 282
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 11
<
{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Host": "www.example.com",
    "User-Agent": "curl/8.7.1",
    "X-Envoy-Attempt-Count": "1",
    "X-Envoy-External-Address": "123.120.227.173"
  },
  "origin": "123.120.227.173",
  "url": "http://www.example.com/get"
}
* Connection #0 to host 34.41.0.90 left intact

启用严格的 mTLS

运行下面的命令启用严格的 mTLS：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

kubectl apply -f strict-mtls.yaml

为网关启用 TLS

创建用于服务签名的根证书和私钥：

mkdir example_certs
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example_certs/example.com.key -out example_certs/example.com.crt

为 www.example.com 创建证书和私钥：

openssl req -out example_certs/www.example.com.csr -newkey rsa:2048 -nodes -keyout example_certs/www.example.com.key -subj "/CN=www.example.com/O=www organization"
openssl x509 -req -sha256 -days 365 -CA example_certs/example.com.crt -CAkey example_certs/example.com.key -set_serial 0 -in example_certs/www.example.com.csr -out example_certs/www.example.com.crt

为入口网关创建 secret：

kubectl create -n httpbin secret tls httpbin-credential \
  --key=example_certs/www.example.com.key \
  --cert=example_certs/www.example.com.crt

配置入口网关：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: apps
  namespace: httpbin
spec:
  gatewayClassName: teg
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: httpbin-credential

kubectl apply -f tls-apps-gateway.yaml

发送测试请求：

curl -v -H Host:www.example.com --resolve "www.example.com:443:$GATEWAY_URL" \
  --cacert example_certs/example.com.crt "https://www.example.com:443/httpbin/get"

你将可以通过 HTTPS 访问网格内的 httpbin 服务。

总结

Tetrate Enterprise Gateway 为企业提供了一种强大的网关解决方案，能够在云原生环境中高效地暴露和管理应用服务。通过其基于 Envoy 的架构和对 Kubernetes Gateway API 的支持，TEG 不仅确保了高性能的流量管理，还大幅简化了网关的部署和维护。无论是面对复杂的安全需求还是高流量的业务场景，TEG 都能提供可靠的支持，帮助企业实现其业务连续性和技术创新。

参考

• Using TEG in Conjunction with an Istio Service Mesh - docs.tetrate.io

2024-07-20 07:30:55

今天 Envoy Proxy 1.31.0 发布，这是今年继 1.29、1.30 以来发布的第三个大版本。Envoy Proxy 1.31.0 的发布标志着此开源网络代理项目在性能优化和功能增强方面又迈出了重要一步。此版本包括了一系列引人注目的新特性、行为变化和新配置选项，下面我们将逐一解析这些更新，帮助你充分利用 Envoy 的最新能力。

新特性

1. HTTP/3 “Happy Eyeballs” 特性: HTTP/3的支持现在更为智能，新加入的“happy eyeballs”算法可以在多个 IP 地址族中更快找到最优连接路径，提升连接的可靠性和速度。
2. Proxy Protocol 类型元数据支持: 在代理协议监听器中，默认现在会填充类型化的元数据，为高级路由和策略实施提供更多的灵活性和精确控制。
3. Redis 命令支持: Envoy 现在支持所有 Bloom 1.0.0 的 Redis 命令，扩展了与 Redis 交互的能力，尤其适用于需要高级数据结构操作的场景。

行为变化

1. Thread Local 存储变更: SlotImpl 类的行为更新，其析构函数现可在任何线程上被调用，提高了线程局部存储的灵活性。
2. HTTP/2 和 QUIC 性能提升: 默认启用新的 HTTP/2 编解码器和对 HTTP/3 的优化，包括性能改进和新的连接尝试机制，显著提升了性能和稳定性。

弃用与移除

此版本中，多个旧有的配置和运行时标志被正式弃用和移除，以清理代码库并提升维护效率。这包括一些老旧的 TLS 和 HTTP 配置选项，用户应检查并更新他们的配置以免受到影响。

结论

Envoy 1.31.0 的发布提供了许多值得关注的新特性和改进，不仅增强了其作为现代微服务架构核心组件的地位，也进一步证明了其作为业界领先代理解决方案的能力。无论是在性能提升还是功能拓展方面，Envoy 1.31.0 都为用户带来了实质性的好处。

确保查看完整更新文档，了解所有详细的配置指南和更新说明，以充分利用 Envoy 1.31.0 的潜力。

Envoy 的每次更新都是基于社区的反馈和贡献，我们期待看到你如何利用这些新特性来优化你的应用和服务。如果你有任何问题或需要帮助，欢迎在 Slack 或 GitHub 上与社区交流。

2024-07-17 13:36:15

Envoy Gateway 是由 Envoy Proxy 社区推动的一个开源 API 网关项目，结合了 Contour、Emissary 等项目力量。这个指南将帮助你理解如何贡献代码和参与社区。

开始之前

了解项目的目标和愿景是非常重要的。Envoy Gateway 旨在作为一个独立或基于 Kubernetes 的应用程序网关，使用 Gateway API 资源来管理 Envoy 代理。

如何参与

1. 沟通协作

在开发前，建议通过GitHub或Slack与社区交流。始终创建一个 GitHub Issue 来讨论你的想法。

2. 贡献准则

遵守贡献准则，它包括代码规范和社区行为准则。

3. 提交代码

• 签署 DCO：确保你的提交信息包含 DCO 签名。
• 创建 PR：Fork 仓库后，提交 PR。确保通过所有自动化测试。
• 代码审查：PR 会被维护人员审查，一旦满足条件，将会被合并。

构建和测试指南

环境准备

• 必需工具：
  • Go（版本 1.22+）
  • Make（版本 4.0+）
  • Docker（可选，版本 20.10.16+，用于构建镜像）
  • Python3
• 设置步骤：确保所有工具均已安装并配置好环境变量。

代码构建

• 构建命令：
  • 构建全部二进制文件：make build
  • 仅构建 Envoy Gateway：make build BINS="envoy-gateway"
  • 构建控制工具 egctl：make build BINS="egctl"

测试

• 运行测试：执行 make test 来进行 Go 语言的测试。
• 生成测试数据：执行 make testdata 来生成 YAML 格式的测试数据。

Lint 检查

• 执行 Lint：运行 make lint 确保代码风格和标准一致性（注意修正现有的拼写错误）。

镜像操作

• 构建镜像：IMAGE=docker.io/<dockerhub-id>/gateway-dev make image
• 推送多架构镜像：IMAGE=docker.io/<dockerhub-id>/gateway-dev make push-multiarch

部署和调试

• 本地集群创建：使用 make create-cluster 在 Kind 上创建测试/开发用的集群。
• 部署到 Kubernetes：使用 IMAGE=docker.io/<dockerhub-id>/gateway-dev TAG=<image-tag> make kube-deploy 将 Envoy Gateway 部署至 Kubernetes。
• 部署示例应用：执行 make kube-demo 部署 demo 后端服务及相关网络资源。
• 删除部署：执行 make kube-demo-undeploy 删除示例应用。执行 make kube-undeploy 删除 Envoy Gateway。

 NAMESPACE              NAME                                                  READY   STATUS    RESTARTS      AGE
 default                backend-96f75bbf-tcdf7                                1/1     Running   1 (97s ago)   13h
 envoy-gateway-system   envoy-default-eg-e41e7b31-668f754989-wb7xr            2/2     Running   2 (97s ago)   13h
 envoy-gateway-system   envoy-gateway-b457dc69b-l77cr                         1/1     Running   2 (97s ago)   13h
 kube-system            coredns-5dd5756b68-b494d                              1/1     Running   1 (97s ago)   14h
 kube-system            coredns-5dd5756b68-j46bx                              1/1     Running   1 (97s ago)   14h
 kube-system            etcd-envoy-gateway-control-plane                      1/1     Running   1 (97s ago)   14h
 kube-system            kindnet-sq4b4                                         1/1     Running   1 (97s ago)   14h
 kube-system            kube-apiserver-envoy-gateway-control-plane            1/1     Running   1 (97s ago)   14h
 kube-system            kube-controller-manager-envoy-gateway-control-plane   1/1     Running   2 (97s ago)   14h
 kube-system            kube-proxy-4x72s                                      1/1     Running   1 (97s ago)   14h
 kube-system            kube-scheduler-envoy-gateway-control-plane            1/1     Running   2 (97s ago)   14h
 local-path-storage     local-path-provisioner-6f8956fb48-shjcz               1/1     Running   2 (59s ago)   14h
 metallb-system         controller-5c6b6c8447-kjl4n                           1/1     Running   2 (59s ago)   14h
 metallb-system         speaker-6zlrb                                         1/1     Running   1 (97s ago)   14h

调试 Envoy 配置

• 端口转发设置：

  export ENVOY_DEPLOYMENT=$(kubectl get deploy -n envoy-gateway-system --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg -o jsonpath='{.items[0].metadata.name}')
  kubectl port-forward deploy/${ENVOY_DEPLOYMENT} -n envoy-gateway-system 19000:19000
  

• 访问：在浏览器中打开 http://localhost:19000 访问 Envoy 管理界面进行配置调试。
• 网络环境适配：在中国大陆进行构建和推送镜像时，可能需要设置 Docker 代理以确保依赖的镜像能够下载。详细操作可参考设置 Docker 代理。

#!/bin/bash
echo "Pull the images and load them into the kind cluster..."
docker pull envoy-gateway-control-plane quay.io/metallb/controller:v0.13.10
docker pull envoy-gateway-control-plane quay.io/metallb/speaker:v0.13.10
docker pull envoy-gateway-control-plane docker.io/jimmysong/gateway-dev:435a4dc1
docker pull envoy-gateway-control-plane envoyproxy/envoy:distroless-dev
docker pull envoy-gateway-control-plane gcr.io/k8s-staging-gateway-api/echo-basic:v20231214-v1.0.0-140-gf544a46e
 
kind load docker-image -n envoy-gateway --nodes envoy-gateway-control-plane quay.io/metallb/controller:v0.13.10
kind load docker-image -n envoy-gateway --nodes envoy-gateway-control-plane quay.io/metallb/speaker:v0.13.10
kind load docker-image -n envoy-gateway --nodes envoy-gateway-control-plane docker.io/jimmysong/gateway-dev:435a4dc1
kind load docker-image -n envoy-gateway --nodes envoy-gateway-control-plane envoyproxy/envoy:distroless-dev
kind load docker-image -n envoy-gateway --nodes envoy-gateway-control-plane gcr.io/k8s-staging-gateway-api/echo-basic:v20231214-v1.0.0-140-gf544a46e

更多资源

想深入了解如何进行高级测试和贡献，详见 Envoy Gateway 开发文档。

加入我们，与全球开发者共同推进 Envoy Gateway 的成长，同时提升你的开发技能和对开源社区的理解。

加入 Envoy Gateway 中文交流群

为了便于中文和中国时区的用户交流，Envoy Gateway 社区成立的微信群，详见通知，该群成立于 2023 年 4 月，目前已有 400 多名成员。你可以联系联系我、刘训灼、赵化冰等入群。

参考

• Envoy Gateway Developer Guide - gateway.envoyproxy.io

2024-07-12 11:51:52

最近我观看了一部名为 Fantastic Planet 的电影，这部电影给了我极大的震撼，令人意想不到的是，这居然是一部上世纪七十年代的作品。

在这里我想跟你分享一下这部电影，及其引申作品，还有我对这部电影的一些看法。

原始星球中的世界观

《Fantastic Planet》（法语原名“La Planète sauvage”，中文译名“原始星球”）以其独特的世界观和强烈的象征意义吸引了无数观众。这部电影描绘了一个名为 Ygam 的星球，上面居住着智慧而庞大的蓝色生物 Draags 和人类大小的 Oms。Draags 对 Oms 既是宠物又是实验对象，这种关系象征着权力和压迫。电影通过这种超现实的设定，探讨了奴役与反抗、文化冲突与共生的深刻主题。

请看下面的片段。

电影中处处都有一种诡异的氛围，其中的配乐也极具特色。

剧情介绍

《Fantastic Planet》的故事主要围绕一个年轻的 Om（人类），名为 Terr 展开。Terr 是在 Draags 的世界中被当作宠物养大的，但他利用一次偶发的机会逃脱了。当他的“主人”Tiwa 在一次学习过程中分心时，Terr 抓住机会逃离，并最终找到了一群野生的 Oms。电影中，Draags 是智慧而高大的蓝色生物，对 Oms 实施着类似宠物和奴隶的管理。在 Terr 的带领下，他和他的同伴们开始探索 Ygam 星球，学习 Draags 的技术和知识，并最终找到了反抗 Draags 统治的方法。

这部电影的剧情充满转折，不仅展现了 Terr 成长的旅程，还揭示了两种文明之间的冲突与和解，最终迫使 Draags 重新考虑对 Oms 的态度，导致了两个种族之间的和解。

故事线

电影的情节主要围绕 Terr 的成长和他最终领导 Om 反抗 Draags 的统治展开。故事的主要阶段包括：

1. 成长与学习：在 Tiwa 的家中，Terr 接触到了 Draags 的学习装置，这些装置通过直接向大脑传递信息的方式教授知识。虽然这些装置主要是为 Draags 设计的，但 Terr 利用它们秘密学习了 Draags 的语言和科技知识。

2. 逃离与自由：随着对 Draags 文化的理解加深，Terr 意识到自己的奴役地位，决定逃离 Tiwa 的家。他带走了一个重要的学习装置，这成为他和其他 Om 反抗 Draags 的关键工具。

3. 野生 Om 社区：逃离后，Terr 加入了一个野生 Om 社区，他们居住在 Ygam 星球的荒野中。在那里，Terr 分享了他从 Draags 那里学到的知识，帮助他们提高技术水平，从而更好地抵抗 Draags 的迫害。

4. 反抗与冲突：随着技术和组织的发展，Terr 和其他 Om 开始更加积极地反抗 Draags。他们策划并执行了多次行动，干扰 Draags 的冥想，最终引发了双方的直接冲突。

5. 和解与共存：电影的结尾，经过一系列的斗争和破坏，双方达到了一种脆弱的和解。Draags 开始重新考虑对 Oms 的态度，而 Oms 也获得了更多的自由和生存空间。故事以一种暗示未来可能的和平共存的方式结束。

Draags 的弱点

Draags 的主要弱点之一是他们对精神冥想和学习的依赖，这是他们文化的一个核心部分。Draags 通过冥想和精神投射来维持他们的社会结构和知识传承。这种精神活动虽然展示了他们的高度智慧，但也使他们在某种程度上依赖于固定的环境和仪式，一旦这种平衡被打破，他们的社会秩序和个体能力就会受到影响。

Oms 如何打败 Draags

在电影中，Oms 最初是处于被动和受压迫的状态，他们被视为宠物或实验对象。然而，随着故事的发展，Oms 开始积累知识和技能，特别是在 Terr 的领导下，他偷学了 Draags 的知识并分享给其他 Oms。Oms 使用这些知识制造了自己的武器和通讯设备，组织起来进行抵抗。

Oms 的转变点是他们学会了干扰 Draags 的冥想仪式。他们发现，通过破坏 Draags 进行精神投射的特定设施，可以直接影响 Draags 的精神和身体健康。最终，Oms 通过一系列策略和战斗，迫使 Draags 重视他们的需求和权利，从而达到了一种新的平衡和相互理解。

电影的寓意和时代背景

《Fantastic Planet》在七十年代的社会政治背景下具有丰富的象征意义。这一时期，世界各地都充斥着社会动荡，包括越南战争、民权运动、以及对传统权威和社会结构的广泛质疑。

1. 种族和阶级冲突：Draags 和 Oms 之间的关系象征着种族和阶级冲突，反映了现实世界中的压迫和不平等。电影通过展示 Oms 的奋斗和最终的抗争成功，传递了对自由和平等的追求，与世界各地的解放运动和社会变革呼应。
2. 技术和伦理：Draags 的先进技术和文化并没有使他们对 Oms 的对待更加人道，这引发了关于科技进步与伦理责任之间的关系的讨论。这一主题在当时科技迅速发展的背景下尤为重要，提示观众科技应该如何服务于社会的整体福祉。
3. 环境意识：电影中对环境和其他物种的描绘也反映了当时日益增长的环保意识。Draags 和 Oms 对环境的不同态度和影响暗示了人类活动对地球生态系统的影响，以及必须采取行动以避免灾难性后果的紧迫感。

结局

在《Fantastic Planet》的结尾，两个种族之间的和解并不是基于完全的和谐或理想化的情感联系，而是基于力量均衡。

和解的保持

电影中的和解通过展示两种文明之间达成的一种平衡来描绘，其中 Oms 通过获得知识和技术，能够在某种程度上与 Draags 站在同一个水平线上。Oms 学会了干扰 Draags 的冥想仪式，显示了他们能够影响 Draags 的生活和幸福。这种能力的证明迫使 Draags 重新评估他们对 Oms 的看法，并接受 Oms 作为平等的存在。因此，双方的和解更多地基于力量平衡和相互依赖，而不仅仅是单方面的宽恕或让步。

核大战的共同毁灭

这种通过显示破坏力来达成和解的方式，在某种程度上类似于冷战时期的“共同毁灭”概念。在核大战策略中，共同毁灭（Mutually Assured Destruction, MAD）是一种阻止核战争的理论，它基于的假设是两个拥有大量核武器的对手如果发动核战争，将导致双方的彻底毁灭。因此，恐惧和自我保护的本能阻止了核战争的发生。

在《Fantastic Planet》中，虽然没有直接的核武器，但 Oms 通过获得足够的知识和技术，以及能够干预 Draags 的生活方式的能力，建立了一种形式的战略平衡。这使得 Draags 必须承认 Oms 的权利和地位，从而防止了进一步的冲突和破坏，确保了两个种族的共存。

这样的和解和平衡展现了一种基于相互尊重和理解的共存方式，同时也提醒了现实世界中力量平衡的脆弱性和维持和平的复杂性。

关于电影及角色名称的解读

这部电影的译名及其中的角色名称也富有深意。

电影的译名与时代背景

《Fantastic Planet》的不同译名映射出不同文化对这部电影的解读。法语原名“La Planète sauvage”带有“野性”的暗示，强调了电影中野生与文明的对比；而英文名“Fantastic Planet”则更强调奇幻元素。中文译名有“原始星球”、“神奇星球”、“奇幻星球”等，结合了这两种元素，既体现了电影的奇异美学，也暗示了其深刻的哲理。这些译名反映了上世纪七十年代的文化背景，当时社会动荡和对权威的质疑正酝酿之中。

角色名称解读

Fantastic Planet 中的角色和名称富有象征意义，每个名字背后都携带着一定的文化或哲学含义，有助于增强电影的主题和故事。

Draags - 这个名字可能派生自“drag”或“dragoon”，象征着他们的统治地位和力量。Draags 这个名字暗示了他们对 Oms 的支配和冷漠态度。

Oms - 这个名字可能来源于法语单词“homme”，意味“人”。这个名称强调了他们的人性和在 Draags 眼中被视为次等的地位。

Terr - 主角 Terr 的名字来源于“terre”，法语中的“地球”或“土地”。这个名字强调了他作为 Om（类人种族）与自然和地球的紧密联系，同时也体现了他的地位和他的成长旅程。

Tiwa - Terr 的“主人”，一位年轻的 Draag 女性。她的名字可能来源于“twee”，荷兰语中的“二”或表示幼小、可爱的意思，这反映了她相对年轻和她对 Terr 的看待方式，即作为一个宠物或小孩。

精彩的配乐

《Fantastic Planet》（奇幻星球）的配乐是由法国作曲家 Alain Goraguer 创作的，这部音乐成为了电影的一个显著特色，与其独特的视觉风格和深刻的主题完美结合。Goraguer 的音乐风格融合了爵士、电子乐和管弦乐，为电影带来了一种梦幻般的、超现实的氛围。

1. 电子音乐元素：Goraguer 在音乐中广泛使用了电子合成器，为电影提供了一种前卫的科技感。这种使用在 1970 年代初期是相对新颖的，与电影中的科幻主题和未来主义美学形成了和谐的统一。

2. 爵士风格的影响：配乐中还融入了爵士音乐的元素，特别是在一些轻松或不安的场景中。这些爵士风格的曲目增加了音乐的动态范围，使观众在情感上更加投入电影的世界。

3. 管弦乐的运用：电影音乐还包括了传统的管弦乐部分，尤其是在描绘 Draags 的文化和仪式时。这种传统元素与电子和爵士的现代感形成对比，强调了 Draags 社会的复杂性和高度发展。

4. 节奏和氛围：整个配乐在节奏和氛围上都非常独特，既有悬疑和紧张的片段，也有平静和沉思的片段。这种多样性使得音乐本身几乎成为电影叙事的一个角色。

Alain Goraguer 的配乐为《Fantastic Planet》增添了一层额外的意义和情感深度，使其成为观众和批评家赞誉的对象。这种音乐与电影的结合，为观众提供了一次全面的感官体验，是电影受欢迎的重要因素之一。

导演及其影响

René Laloux 的导演生涯以其独树一帜的视觉风格和深刻的寓意著称。《Fantastic Planet》的视觉设计和故事叙述对许多后来的电影制作人产生了影响，其中包括印度导演 Tarsem Singh。Singh 的作品如《The Cell》（2000 年）和《The Fall》（2006 年）中，同样可以看到对 Laloux 奇幻和超现实风格的致敬。

The Cell 是一部科幻惊悚片，中文译作“入侵脑细胞”，讲述了一个男子突然接到一个被绑架女子的电话，随后展开了一场横跨整个城市的紧张营救行动。

The Fall 是一部视觉艺术电影，中文译作“坠入”，通过一个受伤的特技演员在医院里向一个小女孩讲述的五个奇幻英雄的故事，探索了故事讲述的力量和现实与想象的界限。

个人感想

通过 Terr 的经历，电影《Fantastic Planet》深入探讨了知识、自由与自我实现的重要性，并且通过 Terr 这一角色展示了不同文明间的冲突、理解与和解。Terr 不仅仅是反叛的象征，更是连接不同世界、开启和平共存可能性的桥梁。

Oms 如何利用技术和知识战胜 Draags 的过程突显了教育和智慧在社会变革中的核心作用，同时也展现了如何通过团结和策略战胜强大对手的智慧。电影中的和解是一种脆弱的平衡，随时可能因新的冲突而被打破。

观看《Fantastic Planet》是一次视觉与思维的双重震撼，电影中的超现实场景和丰富的社会隐喻促使我深思现实世界中的类似问题。这部作品对权力、压迫及解放的深刻描绘，不仅仅是视觉上的享受，更是对人类社会的深刻反思，提供了宝贵的启示和思考。

2024-07-11 19:45:20

前言

随着企业信息系统越来越多地采用微服务架构，如何在多集群环境中实现服务的高效、安全地跨集群访问成为了一个重要的挑战。Istio 作为一种流行的服务网格解决方案，提供了丰富的功能来支持跨集群服务的无缝连接。

在部署和使用多集群服务网格时有以下难点：

• 跨集群的服务注册发现与路由
• 集群间服务的身份识别与认证

本文将深入探讨如何在多集群多网格的 Istio 部署中，通过实施 SPIRE 联邦和东西向网关暴露服务的方式，实现跨集群的无缝访问。通过一系列配置和部署示例，本文旨在为读者提供一个清晰的指南，帮助理解和解决多集群服务网格部署中遇到的常见问题和挑战。

Istio 的部署模型

Istio 文档中根据集群、网络、控制平面、网格、信任域及租户等维度划分了多种部署模型，我将其总结并附上适用场景说明如下表所示。

选择合适的部署模型需要考虑到实际的业务需求、安全要求、管理复杂度以及成本等因素。在生产环境中，往往是对多种部署模型的组合使用。

下表展示了在实际应用中如何结合不同的部署模型来满足更复杂的业务和技术需求：

这些混合模型提供了高度的灵活性和可扩展性，能够满足各种复杂的部署要求。在选择混合模型时，组织需要考虑到管理复杂性、成本、安全要求以及业务需求，以确定最合适的部署策略。通过适当的规划和设计，Istio 的灵活部署模型可以帮助组织构建出既安全又高效的服务网格架构。在大多数场景下，单信任域的多集群 + 单网格 + 多控制平面已足够满足需要。

本文将聚焦多集群 + 多网格 + 多控制平面 + 多信任域的混合部署模型，这是一种相当复杂的场景，如果你可以完成这种场景的部署，那么其他场景也就不在话下了。

多集群 Istio 服务网格中的 FQDN

网格间的服务要想互相访问，必须了解各自的 FQDN。FQDN 通常由服务名、命名空间和顶级域（如 svc.cluster.local）组成。在 Istio 的多集群或多网格设置中，可以通过不同的机制（如ServiceEntry、VirtualService、Gateway 配置）来控制和管理服务的路由和访问，而不是通过修改 FQDN 来实现。

多集群服务网格中的 FQDN 与单集群并没有什么不同，通常遵循以下格式：

<service-name>.<namespace>.svc.cluster.local

也许你会想到通过 meshID 来区分网格？meshID 主要用于区分和管理在同一环境中或跨环境的多个 Istio 网格，meshID 并不用于直接构造服务的 FQDN。

跨集群的服务注册发现与路由

在 Istio 多网格环境中，东西向网关（East-West Gateway）起着关键作用，它不仅处理网格间的入口和出口流量，还支持服务的发现和连接。当一个集群需要访问另一个集群中的服务时，它通过这个网关路由到目标服务。

下图展示了跨集群的服务注册发现与路由的过程。

在跨集群的 Istio 网格配置中，服务注册、发现和路由的流程是至关重要的，它们确保了不同集群中的服务可以相互发现并通信。以下是跨集群 Istio 网格中服务注册、发现与路由的基本流程：

1. 服务注册

在每个 Kubernetes 集群中，当一个服务被部署时，它的信息会被注册到 Kubernetes 的 API Server。这包括服务的名称、标签、选择器、端口等信息。

2. 同步到 Istiod

Istiod，作为控制平面，负责监控 Kubernetes API Server 的状态变化。每当有新的服务被注册或现有服务被更新时，Istiod 会自动检测到这些变化。Istiod 接着提取必要的服务信息并构建内部的服务和端点的配置。

3. 跨集群服务发现

为了使一个集群中的服务能够发现并通信到另一个集群的服务，Istiod 需要将服务端点信息同步到所有相关集群。这通常通过以下两种方式之一实现：

• DNS 解析：Istio 可配置为利用 CoreDNS 或类似服务，在 DNS 查询中返回跨集群的服务端点。当一个服务尝试解析另一个集群中的服务时，DNS 查询会返回可以访问的远程服务的 IP 地址。在本文中我们将启用 Istio 的 DNS 代理实现跨集群的服务发现。在一个服务同时存在于本地和远程集群中时，在本地执行 DNS 查询只会返回本地服务的 ClusterIP，若该服务只存在于远程集群中时，DNS 查询将返回远程服务所在集群的东西向网关的负载均衡器地址，该特性也可以用于跨集群的故障恢复。
• 服务入口同步：通过设置特定的 ServiceEntry 配置，使得一个集群的 Envoy 代理知道如何通过东西向网关找到并路由到另一个集群的服务。

4. 路由和负载均衡

当服务 A 需要与服务 B 通信时，它的 Envoy 代理首先解析服务 B 的名称获取 IP 地址，即服务 B 所在集群的东西向网关的负载均衡器地址。接着该东西向网关将请求路由到目标服务。Envoy 代理可以根据配置的负载均衡策略（如轮询、最少连接数等），选择最佳的服务实例来发送请求。

5. 流量管理

Istio 提供了丰富的流量管理功能，例如请求路由、故障注入、流量复制等。这些规则在 Istio 的控制平面中定义，并推送到各个 Envoy 代理执行。这样可以在跨集群环境中灵活地控制和优化服务间的通信。

集群间服务的身份识别与认证

当不同集群中运行的服务需要相互通信时，正确的身份认证和授权是确保服务安全的关键。使用 SPIFFE 可以帮助标识和验证服务的身份，但在多集群环境中需要确保这些身份是唯一且可验证的。

为此，我们将设置 SPIRE 联邦来为多集群的服务分配身份并实现跨集群的身份认证：

• 使用 SPIFFE 来标识服务身份：在 SPIFFE 框架下，每个服务都会被分配一个格式为spiffe://<trust-domain>/<namespace>/<service>的唯一标识符。在多集群环境中，可以通过包括集群名称在内的“trust domain”来确保身份的唯一性。例如，可以设置spiffe://foo.com/ns/default/svc/service1和spiffe://bar.com/ns/default/svc/service1，以区分不同集群中相同名称的服务。
• 使用 SPIRE 联邦来管理集群间的证书：它可以增强多集群服务网格中的安全性。SPIRE（SPIFFE Runtime Environment）提供了一个高度可配置的平台，用于服务身份验证和证书颁发。当使用 SPIRE 联邦时，可以实现跨集群的服务认证，通过为每个 SPIRE 集群创建 Trust Bundle 实现跨集群的身份认证。

以下是实现 SPIRE 联邦的步骤说明。

1. 配置 Trust Domain

每个集群都配置为一个单独的 trust domain。这样，每个集群内的服务都将具有基于其所在 trust domain 的唯一 SPIFFE ID。例如，集群 1 的服务可能拥有 ID spiffe://cluster1/ns/default/svc/service1，而集群 2 的相同服务则为 spiffe://cluster2/ns/default/svc/service1。

2. 建立 Trust Bundle

在 SPIRE 中配置 trust relationships 以允许不同 trust domain 的节点和工作负载相互验证。这涉及到 trust domain 之间交换和接受彼此的 CA 证书或 JWT keys，确保跨集群通信的安全性。

3. 配置 SPIRE Server 和 Agent

在每个集群中部署 SPIRE Server 和 SPIRE Agent。SPIRE Server 负责管理证书颁发和续签，而 SPIRE Agent 负责将证书和密钥安全地分发给集群内的服务。

4. 使用 Workload API

服务可以通过 SPIRE 的 Workload API 请求和更新其身份证书。这样，服务即使在不同集群中运行，也能持续验证其身份，并安全地与其他服务通信。我们将配置 Istio 网格中的代理共享 SPIRE Agent 中的 Unix Domain Socket，从而访问 Workload API 来管理证书。

5. 自动化证书轮换

我们将使用 cert-manager 作为 SPIRE 的 UpstreamAuthority，配置 SPIRE 自动轮换服务证书和密钥，增强系统的安全性。通过自动化轮换，即使证书被泄露，攻击者也只能在很短的时间内利用这些证书。

通过这些步骤，你可以建立一个跨集群的、安全的服务身份验证框架，使得各个集群的服务能够安全地识别和通信，从而有效地降低安全风险并简化证书管理。这样的配置不仅增强了安全性，还通过分散的信任域提高了系统的可扩展性和灵活性。

部署多集群

下图展示了 Istio 多集群及 SPIRE 联邦的部署模型。

下面我将演示如何在多集群 Istio 网格中实现无缝地跨集群无缝访问。

1. 在 GKE 中创建两个 Kubernetes 集群，分别命名为 cluster-1 和 cluster-2
2. 分别在这两个集群中部署 SPIRE 并设置联邦
3. 分别在两个集群中安装 Istio，注意配置信任域、东西向网关、入口网关、 sidecarInjectorWebhook 挂载 SPIFFE UDS 的 workload-socket，并启用 DNS 代理
4. 部署测试应用并验证跨集群的无缝访问

我们部署的各组件版本如下：

• Kubernetes: v1.29.4
• Istio: v1.22.1
• SPIRE: v1.5.1
• cert-manager: v1.15.1

我将所有命令及步骤说明保存在 Github 上：rootsongjc/istio-multi-cluster，你可以按照该项目中的说明操作。下面是对各主要步骤的说明。

1. 准备 Kubernetes 集群

打开 Google Cloud Shell 或本地终端，并确保你已经安装了 gcloud CLI。使用以下命令创建两个集群：

gcloud container clusters create cluster-1 --zone us-central1-a --num-nodes 3
gcloud container clusters create cluster-2 --zone us-central1-b --num-nodes 3

2. 部署 cert-manager

使用 cert-manager 作为根 CA 为 istiod 和 SPIRE 颁发证书。

./cert-manager/install-cert-manager.sh

3. 部署 SPIRE 联邦

SPIRE 联邦的基本信息如下：

注意：信任域不需要与 DNS 名称一致，但需要与 Istio Operator 配置中的信任域相同。

执行下面的命令部署 SPIRE 联邦：

./spire/install-spire.sh

想了解 Istio 中使用 SPIRE 进行身份管理的详情，请参考使用 cert-manager 和 SPIRE 管理 Istio 中的证书。

4. 安装 Istio

我们将使用 IstioOperator 来安装 Istio，其中为每个集群配置了：

• 自动 Sidecar 注入
• 入口网关
• 东西向网关
• DNS 代理
• SPIRE 集成
• 访问远程 Kubernetes 集群的 Secret

执行下面的命令安装 Istio：

istio/install-istio.sh

验证流量联邦

为了验证多集群安装的正确性，我们将在两个集群中分别部署不同版本的 helloworld 应用，然后在 cluster-1 中访问 helloworld 服务，以测试以下跨集群访问场景：

1. 东西向流量联邦：跨集群的服务冗余
2. 东西向流量联邦：处理非本地目标服务
3. 南北向流量联邦：通过远程入口网关访问服务

执行下面的命令在两个集群中部署 helloworld 应用：

./example/deploy-helloword.sh

东西向流量联邦：跨集群的服务冗余

部署完成 helloworld 应用后，从 cluster-1 的 sleep pod 访问 hellowrold 服务：

kubectl exec --context=cluster-1 -n sleep deployment/sleep -c sleep \
	-- sh -c "while :; do curl -sS helloworld.helloworld:5000/hello; sleep 1; done"

下图展示的是该场景下的部署架构及流量路由路径。

从请求结果既有 helloworld-v1 又有 helloworld-v2 的响应来看，说明跨集群的服务冗余生效了。

验证 DNS

此时，因为 helloworld 服务既存在于本地又在远程集群中，若你在 cluster-1 中查询 helloworld 服务的 DNS 名称：

kubectl exec -it deploy/sleep --context=cluster-1 -n sleep -- nslookup helloworld.helloworld.svc.cluster.local

你将得到 cluster-1 集群中的 helloworld 服务的 ClusterIP。

验证流量路由

接下来我们将通过查看 Envoy 代理配置来验证跨集群的流量路由路径。

在 cluster-1 中查看 helloworld 服务的端点：

istioctl proxy-config endpoints deployment/sleep.sleep --context=cluster-1 --cluster "outbound|5000||helloworld.helloworld.svc.cluster.local"

你将得到类似下面的输出：

ENDPOINT               STATUS      OUTLIER CHECK     CLUSTER
10.76.3.22:5000        HEALTHY     OK                outbound|5000||helloworld.helloworld.svc.cluster.local
34.136.67.85:15443     HEALTHY     OK                outbound|5000||helloworld.helloworld.svc.cluster.local

这两个端点，一个是 cluster-1 中的 helloworld 服务的端点，另一个是 cluster-2 的 istio-eastwestgateway 服务的负载均衡器地址。Istio 将为跨集群的 TLS 连接设置 SNI，在 cluster-2 中将通过 SNI 区分目标服务。

执行下面的命令，在 cluster-2 中查询前面 SNI 的端点：

istioctl proxy-config endpoints deploy/istio-eastwestgateway.istio-system --context=cluster-2 --cluster "outbound_.5000_._.helloworld.helloworld.svc.cluster.local"

你将得到类似下面的结果：

ENDPOINT           STATUS      OUTLIER CHECK     CLUSTER
10.88.2.4:5000     HEALTHY     OK                outbound_.5000_._.helloworld.helloworld.svc.cluster.local

这个端点就是 helloworld 服务在 cluster-2 集群中的端点。

通过以上步骤，你应该了解了跨集群冗余服务的流量路径。接下来我们将删除 cluster-1 中的 helloworld 服务，不需要对 Istio 做任何配置，就可以自动实现故障转移。

东西向流量联邦：故障转移

执行下面的命令将 cluster-1 中的 helloworld 副本数量缩容为 0：

kubectl -n helloworld scale deploy helloworld-v1 --context=cluster-1 --replicas 0

再次从 cluster-1 中访问 helloworld 服务：

kubectl exec --context=cluster-1 -n sleep deployment/sleep -c sleep \
	-- sh -c "while :; do curl -sS helloworld.helloworld:5000/hello; sleep 1; done"

依然可以获得来自 helloworld-v2 的响应。

现在，直接删除 cluster-1 中的 helloworld 服务：

kubectl delete service helloworld -n helloworld --context=cluster-1

依然可以获得来自 helloworld-v2 的响应，这说明跨集群的故障转移生效了。

下图展示了该场景下的流量路径。

验证 DNS

此时，因为 helloworld 服务既存在于本地又在远程集群中，若你在 cluster-1 中查询 helloworld 服务的 DNS 名称：

kubectl exec -it deploy/sleep --context=cluster-1 -n sleep -- nslookup helloworld.helloworld.svc.cluster.local

你将得到 cluster-2 集群中东西向网关的地址和 15443 端口。

南北向流量联邦：通过远程入口网关访问服务

通过入口网关访问远程集群中的服务，是最传统的跨集群访问方式，下图展示了该场景下的流量路径。

执行下面的命令在 cluster-2 中创建 Gateway 和 VirtualService：

kubectl apply --context=cluster-2 \
	-f ./examples/helloworld-gateway.yaml -n helloworld

获取 cluster-2 中的入口网关地址：

GATEWAY_URL=$(kubectl -n istio-ingress --context=cluster-2 get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

执行下面的验证可以通过远程入口网关访问服务：

kubectl exec --context="${CTX_CLUSTER1}" -n sleep deployment/sleep -c sleep \
	-- sh -c "while :; do curl -s http://$GATEWAY_URL/hello; sleep 1; done"

你将得到来自 helloworld-v2 的响应。

验证身份

执行下面的命令获取 cluster-1 集群中 sleep pod 中的证书：

istioctl proxy-config secret deployment/sleep -o json --context=cluster-1| jq -r '.dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes' | base64 --decode > chain.pem
split -p "-----BEGIN CERTIFICATE-----" chain.pem cert-
openssl x509 -noout -text -in cert-ab
openssl x509 -noout -text -in cert-aa

如果在输出的消息中看到下面的字段，说明身份分配正确：

Subject: C=US, O=SPIFFE

URI:spiffe://foo.com/ns/sample/sa/sleep

查看 SPIRE 中的身份信息：

kubectl --context=cluster-1 exec -i -t -n spire spire-server-0 -c spire-server \
	-- ./bin/spire-server entry show -socketPath /run/spire/sockets/server.sock --spiffeID spiffe://foo.com/ns/sleep/sa/sleep

你将看到类似下面的输出：

Found 1 entry
Entry ID         : 9b09080d-3b67-44c2-a5b8-63c42ee03a3a
SPIFFE ID        : spiffe://foo.com/ns/sleep/sa/sleep
Parent ID        : spiffe://foo.com/k8s-workload-registrar/cluster-1/node/gke-cluster-1-default-pool-18d66649-z1lm
Revision         : 1
X509-SVID TTL    : default
JWT-SVID TTL     : default
Selector         : k8s:node-name:gke-cluster-1-default-pool-18d66649-z1lm
Selector         : k8s:ns:sleep
Selector         : k8s:pod-uid:6800aca8-7627-4a30-ba30-5f9bdb5acdb2
FederatesWith    : bar.com
DNS name         : sleep-86bfc4d596-rgdkf
DNS name         : sleep.sleep.svc

生产环境建议

对于生产环境，建议使用统一网关，通过 Tier-2 架构，在 Tier-1 边缘网关配置全局的流量路由，该边缘网关将把转写的 Istio 配置下发给 Tier-2 集群中的各个入口网关。

下图展示了使用 TSB 部署的 Tier2 架构的 Istio 服务网格，其中使用 SPIRE 联邦。

我们将这四个 Kubernetes 集群分为 Tier1 集群（tier1）和 Tier2 集群（cp-cluster-1、cp-cluster-2 和 cp-cluster-3）。在 T1 中安装 Edge Gateway，而在 T2 中安装 bookinfo 和 httpbin 应用程序。每个集群将拥有独立的信任域，所有这些集群将构成 SPIRE 联邦。

下图展示了用户通过入口网关访问 bookinfo 和 httpbin 服务的流量路由。

你需要在 Istio 之上创建一个适用于多集群的逻辑抽象层，关于 TSB 中的统一网关的详细信息，请参考 TSB 文档.

总结

本文详细介绍了在 Istio 多集群网格环境中实现服务身份验证、DNS 解析和跨集群流量管理的关键技术和方法。通过精确配置 Istio 和 SPIRE 联邦，我们不仅增强了系统的安全性，还提高了服务间通信的效率和可靠性。遵循这些步骤，你将能够构建一个强大的、可扩展的多集群服务网格，满足现代应用的复杂需求。

参考

• Deploying a Federated SPIRE Architecture - spiffe.io
• Install Multi-Primary on different networks -istio.io
• Istio SPIRE Integration - istio.io
• DNS Proxying - istio.io
• Attesting Istio workload identities with SPIFFE and SPIRE - developer.ibm.com
• Expanding into New Frontiers - Smart DNS Proxying in Istio - istio.io
• 使用 cert-manager 和 SPIRE 管理 Istio 中的证书 - jimmysong.io

2024-07-02 19:40:40

随着 Istio 1.22 版本的发布，Istio API 已正式升级至 v1 版本，同期，Kubernetes Gateway API 也更新至 v1.1 版本。本篇文章旨在深入探索 Ingress API、Istio API 与 Kubernetes Gateway API 之间的联系与区别，并详述它们在现实应用中的选择及迁移策略。

前言

之前，我曾撰写一篇文章，讨论了 为何 Gateway API 是 Kubernetes 与服务网格入口中的未来方向。文章中指出，作为 Kubernetes 的初始入口网关，Ingress 的资源模型由于过于简单，难以满足当下的可编程网络需求。作为其接班人，Gateway API 近年来发展迅速，获得了广泛支持，包括众多新兴的开源网关项目如 Envoy Gateway 也选择基于 Gateway API 开发。此外，一些传统网关项目也开始适配 Gateway API，或通过 ingress2gateway 这样的工具进行迁移。

Gateway API，作为 Kubernetes 入口网关的最新成果，通过角色划分来分离关注点，并支持跨 namespace，更适合多云环境。它整合了入口网关（南北向）与服务网格（东西向，集群内路由）的重叠功能，为云原生时代的统一流量管理提供了新的参考模型。

Ingress API、Gateway API 与 Istio API 都能实现网关功能，它们之间具体有何联系与区别？本文将为你揭晓这一迷题，并提供 Kubernetes 环境中网关的选择和迁移策略。

Kubernetes 中的流量管理

随着微服务架构的广泛应用和日益增长的复杂性，Kubernetes 的流量管理工具也在不断演进以适应各种技术需求。Ingress API、Istio API 与 Kubernetes Gateway API 分别标志着这一演变的不同阶段。

Ingress API 提供了 Kubernetes 的基本流量管理功能，允许用户通过定义简单的路由规则（例如 HTTP 和 HTTPS）来管理外部访问集群内服务的流量。其设计虽简洁，但功能有限，主要适用于规模较小、结构较简单的应用场景。

相比之下，Istio API 作为服务网格的一部分，提供了一系列高级流量管理功能，如流量镜像、金丝雀发布和断路器，适合于需要复杂流量管理的大规模微服务架构。

为了克服 Ingress API 的局限性并集成类似 Istio 的高级功能，Kubernetes Gateway API 因应而生。它不仅在设计上提供了更高的灵活性和扩展性，还通过社区的广泛支持，成为连接传统 Ingress 实现和现代服务网格技术如 Istio 的桥梁，目前主流的开源网关都是基于 Gateway API 或已进行适配。

以下表格概述了这三者的核心特点和推荐使用场景：

Gateway API v1.1 的推出，特别是其在提升与现有 Ingress 配置兼容性方面的改进，为用户提供了一个平稳的迁移途径，使从传统的 Ingress 解决方案向更现代的、功能更全面的 Gateway API 的过渡变得更为顺畅。

从 Ingress 迁移到 Kubernetes Gateway API

若想从 Ingress 迁移到 Gateway API，请按以下步骤操作：

1. 理解关键差异：与 Ingress 相比，Gateway API 引入了多种新的概念和资源类型，如 Gateway、HTTPRoute 和 TLSRoute。这些资源提供了更多的配置选项和灵活性，请参阅 Gateway API 文档以了解其配置。
2. 配置入口点：创建 Gateway 资源配置，明确定义如何接收外部流量，包括配置协议、端口和 TLS 终端。
3. 映射旧资源：将现有的 Ingress 资源映射到对应的 Gateway API 资源。例如，Ingress 中的 host 和 path 规则需要转换为 HTTPRoute 中的路由规则。
4. 测试与部署：在正式迁移之前，在测试环境中验证新的 Gateway API 配置，确保所有流量路由正常，无安全漏洞。

为了简化迁移过程，你可以使用工具如 ingress2gateway，该工具能自动将 Ingress 配置转换为 Gateway API 格式。

实际迁移示例

以下是一个简单的 HTTP 网关配置示例，展示了如何将 Ingress 迁移到 Gateway API。

假设现有一个 Ingress 配置如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

要将其迁移到 Gateway API，首先需要创建一个 Gateway 对象：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        kinds
          - kind: HTTPRoute

请确保 gatewayClassName 指向你集群中配置的有效 GatewayClass。GatewayClass 通常由集群管理员设置，是一个为 Gateway 提供配置的资源。

接下来，创建 HTTPRoute 资源来定义路由规则，将流量路由到后端服务：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: "/"
    backendRefs:
    - name: example-service
      port: 80

在此示例中，我们看到：

• Ingress 对象中的规则被直接映射到 HTTPRoute 对象中。
• 路由规则中的主机名匹配、路径匹配以及后端服务配置保持不变，只是对象和字段名称有所不同。

考虑的挑战

虽然可以将 Ingress 迁移到 Gateway API，并可能同时运行它们，但需要考虑以下挑战和迁移的必要性：

• 功能差异：某些 Ingress 控制器的特定功能可能在 Gateway API 中没有直接对应，可能需要通过额外的配置或自定义资源来实现。
• 多资源管理：Gateway API 的使用可能涉及比 Ingress 更多的资源类型和更复杂的配置，这可能增加管理的复杂性。

对于现有的 Ingress 和 Istio API 用户，是否需要迁移到 Gateway API 取决于具体情况。以下是一些迁移建议：

• 新部署：建议直接采用 Gateway API，以便利用其先进特性和预见未来的发展。
• 现有部署：如果现有系统运行稳定且无需高级特性，可以继续使用现有 API；如果希望利用 Gateway API 的新特性或计划未来长期发展，逐步迁移则是一个理智的选择。

对于不同网关对 Gateway API 的支持情况，可以参考 Gateway API 实现项目的一致性报告了解详细信息。

总结

Ingress API、Istio API 和 Kubernetes Gateway API 各具特色，适应不同的应用场景和需求。选择合适的 API，进行合理的规划和管理，可以显著提高系统的灵活性和稳定性。随着 Gateway API 的持续发展和成熟，它将越来越成为未来流量管理的主流选择。

选择合适的网关技术，结合你的具体需求和现有架构，可以更好地管理和优化流量，确保应用的高效和稳定运行。随着技术的进步和社区的发展，Gateway API 提供了一个强大且灵活的框架，使得从传统的 Ingress 迁移到更现代的解决方案变得更为简单和高效。

参考

• Migrating from Ingress - gateway-api.sigs.k8s.io
• Extending Gateway API support in Istio - istio.io

2024-06-26 16:55:45

微信是我们在日常生活和工作中不可或缺的通讯工具，许多用户都有在同一台设备上登录多个微信账号的需求。尽管官方客户端不直接支持这一功能，但通过一些简单的技巧，你可以在 Mac 电脑上实现微信的多开功能。

你可能看到过一些介绍如何在 Mac 上实现微信多开的文章或视频，那些技巧大多已经失效，有的可用的也只能在一台电脑上同时登录两个微信，本文将详细介绍如何在 Mac 上同时运行任意多个微信实例。

下面是演示视频。

下面是详细步骤。

步骤一：创建微信的副本

首先，你需要在应用程序文件夹中找到微信应用程序（WeChat.app）并创建启动命令副本：

1. 打开访达（Finder）后，按下快捷键 CMD + Shift + G
2. 在弹出的输入框中输入目录 /Applications/WeChat.app/Contents/MacOS
3. 在新打开的目录中选中 WeChat，鼠标右键选择 创建别名（Make Alias） 即创建了一个启动微信的副本。你也可以通过安装 OPT + CMD 按钮拖动 WeChat 文件到当前或另个目录比如桌面上来创建一个别名（快捷方式）。

步骤二：启动多个微信实例

如果你想同时登录 N 个微信，则依次双击刚创建的微信副本 N + 1 次。比如你想同时登录 3 个微信，那就打开这个副本 4 次。

保持这些窗口在运行状态，你可以将它们最小化，但是不要关闭它们。在这个过程中，你可能会注意到，系统只会打开两个微信登录界面。

步骤三：退出其中一个微信

当两个微信登录界面打开后，手动退出其中一个已经开启的微信。

步骤四：触发多开功能

关闭一个微信后，系统会再次打开 N-1 个新的微信窗口。现在你就可以通过这些微信的登录界面登录到不同的微信账户了。

总结

以上方法只需要使用最新的官方版本的微信即可，可以做到任意多开。希望这篇指南能帮助你更高效地使用微信，满足你的多账户管理需求。如有任何问题或需要进一步的帮助，欢迎留言讨论。

2024-06-16 06:11:53

2024 年 3 月，一个特别的机会将我带到了法国巴黎——参加 KubeCon EU 2024。这是一场汇集了来自全球的云计算和开源技术爱好者的盛会。利用这次会议的机会，我不仅深入了解了最新的技术趋势，还抓住机会体验了这座城市的历史、文化和日常生活。我的巴黎之行从 3 月 16 日开始，持续到 3 月 24 日，这期间我尽可能多地探索了这座充满魅力的城市。

签证篇章

对于我们中国人来说，无论何时何地，出国的第一步总是签证的申请。尤其是法国申根签证，需要准备众多材料，包括公司证明信、行程单等，但幸好我所在的公司性质让这一切变得相对容易。令人感到略有安慰的是，与申请日本签证相比，法国签证不需要冻结巨额资金或提供庞大的银行存款证明。这次我获得了六个月的签证有效期，这对于我未来的欧洲行计划提供了更多的灵活性和可能性。

到达巴黎

从北京直飞巴黎的旅程总是充满期待。我乘坐的法国航空公司航班，从北京时间凌晨起飞，经过长达 13 小时的旅程后，于巴黎时间早晨 6 点多抵达。归途则选择了在伊斯坦布尔转机，让旅行的回忆更添一分异国情调。

第一印象

戴高乐机场处处可见的中文标牌，字句优雅，显示了法国人对细节的用心。尽管通关时排队等候了近一个小时，但多样化的人流让巴黎的国际化氛围愈发显著。从机场乘坐穿梭地铁时，我体验了三次才成功挤上车，可见人流之多。使用 Bolt 打车服务时，因为语言不通，还得到了一位好心法国人的帮助，他用法语帮我与司机沟通，这让我深感法国人的友好与热心。

在巴黎戴高乐机场随处可见中文标识，很多地方只有英文、法文和中文三种文字的标识。

巴黎的生活细节

在巴黎的每一处，都能看到那些独具特色的垃圾桶，它们不仅方便实用，还在安全上做了考虑。例如，一些垃圾桶是为了防爆而设计的，能安全投放玻璃瓶和易拉罐，而另一些仅用透明塑料袋覆盖，也是出于同样的安全考量。这些细节体现了城市管理的精细与周到。

巴黎的垃圾分类采用彩色编码垃圾桶系统，旨在促进适当的废物处理。垃圾箱有不同的颜色：黄色用于纸张和塑料等可回收物，棕色用于可堆肥食物残渣，白色用于酒瓶等玻璃物品，绿色/灰色用于其他废物。该系统可帮助居民有效地分类垃圾，促进回收利用和适当的废物管理实践。

食在巴黎

尽管西餐中的牛排和糕点让人难以抗拒，我还是更偏爱家乡的味道。在巴黎，我找到了一家名为杨小厨的川菜馆，其牛肉面虽与国内有所不同，但味道可口，价格亲民。此外，巴黎街头的水果与我在网上购买的相比，不仅价格合理，而且味道也极佳，特别是我喜爱的啤梨。

另外在很多地铁口还有街头巷尾也有社区小摊及烘焙店。

住在巴黎

巴黎，法国的首都，不仅以其浪漫和历史著称，同时其行政区划也具有独特的结构。巴黎市通常被分为“大巴黎”和“小巴黎”。小巴黎指的是巴黎市内环，即第一到二十区，涵盖了大部分著名的历史地标和文化地区，总面积约为 105 平方公里。而大巴黎则包括小巴黎及其周边的郊区，形成一个更为广泛的都市区。

下图中环形道路是 Boulevard Périphérique，即巴黎环形高速公路。这条道路环绕着巴黎的 20 个区，这些区域共同构成了所谓的“小巴黎”。

巴黎的 20 个区（arrondissements）按照螺旋状的顺序从市中心向外延伸，包括了市内最核心的商业、居住以及文化区域。这些区域的总面积大约为 105 平方公里（约 40.5 平方英里），从 1 区的市中心向外逐渐扩展至 20 区。

这些区域是巴黎市的行政区划，而“小巴黎”这个名词通常是指的这些内环的区域，即由环形公路所环绕的巴黎市内部区域。因此，图中显示的 20 个区确实组成了“小巴黎”。

相比之下，北京的二环面积约为 62 平方公里，三环面积约为 159 平方公里，小巴黎的面积在二者之间，下图展示了在同等比例尺下的小巴黎和北京三环的地图。

我此行住宿的地点位于巴黎的 15 区，这里是巴黎最大的一个区，位于塞纳河左岸（按塞纳河流向）。15 区不仅居住环境宜人，交通便利，而且距离诸如埃菲尔铁塔等著名景点也非常近，步行大约 20 分钟即可到达。我下榻的住所是一栋三层高的联排公寓，底层设有车库和会客厅，而居住区则分布在二楼和三楼，共有五个房间，旁边还有某国的大使馆官邸，增添了一份特别的国际氛围。

行在巴黎

巴黎的道路规划别具一格，道路交错纵横，并非严格的南北走向，加之红绿灯设置在街角，使得初来乍到的人有些不适应。这里的自行车道十分发达，我租了一辆助力自行车，穿行在巴黎的街头巷尾，感受到前所未有的自由与惬意。巴黎的地铁系统复杂多样，但支付方式极为方便，大部分支付都可以通过信用卡完成。

对于游客来说，在小巴黎短距离出行首选方式是自行车。巴黎街头随处可见可供租赁的自行车，你可以下载 App 注册扫码支付后即可使用，注意需要绑定信用卡。有些自行车道是在路的中间，路面上有明确标识自行车道。这些自行车都是助力车，大多维护的比较好，但是也有一些存在故障，需要仔细辨别。另外巴黎的街道较窄，行人也很少遵守红绿灯，可能是因为红绿灯太多了吧。

巴黎的地铁票种类繁多，从单次票、日票到周票、月票一应俱全，适应不同游客的需求。然而，许多外地游客在购票环节都会遇到困惑，需要一些时间来熟悉系统。

巴黎地铁（Métro de Paris）始建于 1900 年，是世界上最早的地铁系统之一。这个广泛的地铁网络包括 16 条线路，覆盖总长度达 225 公里。巴黎地铁不仅连接城市中心和外围区域，还扩展到了一些近郊区域，每年服务数亿乘客，是巴黎公共交通系统的核心部分。因为建造时间比较久远，很多设施都比较老旧，比如车厢陈旧，车厢门要手动打开，运行噪音大，没有电梯等。

医疗体验

在巴黎的第二天，我因饮食不当而开始腹泻，持续了两天后才好转。在这期间，我去了当地的药店买药。药店早上 8 点准时开门，门口总是有人排队等候，这种准时和秩序让我印象深刻。

法国的医疗体系被认为是世界上最好的之一，无论是急诊还是药品购买，都非常便捷。药品的质量和种类也相当丰富，能够满足不同病症的需求。

游在巴黎

在 KubeCon EU 期间，我利用空闲时间游览了几处巴黎的著名景点。埃菲尔铁塔是必须打卡的地方，我登上了二层平台，俯瞰整个巴黎，景色壮观。卢浮宫则是艺术爱好者的天堂，蒙娜丽莎的微笑吸引了无数游客驻足。虽然巴黎圣母院还在维修中，但夜晚的圣母院依旧散发着无尽的魅力。

卢浮宫

卢浮宫（Louvre Museum）是世界上最大和最著名的博物馆之一。它最初建于 12 世纪作为皇宫，直到 1793 年开放为公众博物馆。卢浮宫收藏了超过 38 万件展品，跨越从古代文明到 19 世纪的艺术与历史文物。其中最著名的作品包括《蒙娜丽莎》、《维纳斯的诞生》和《胜利女神像》等。

卢浮宫里人流量最大的地方就是《蒙娜丽莎》，很多人在那里排起了长龙，只为一睹她那神秘的微笑。

万神殿

巴黎万神殿，最初建造为教堂，现作为一个纪念馆，位于法国巴黎的拉丁区。这座建筑最初是为了纪念圣日内瓦瑞，后转变为纪念法国伟大人物的安息之地。建筑风格融合了古典与新古典元素，其宏伟的圆顶和庄严的柱廊使它成为巴黎的一个显著地标。万神殿内部装饰豪华，包括傅科摆锤和许多重要法国历史人物的墓穴。

万神殿内的傅科摆，由法国物理学家利昂·福科于 1851 年设计，以证明地球自转的直接效应。这个简单但引人注目的实验包括一根悬挂的铁球，通过其自由摆动，观察者可以看到摆动平面相对于地面缓慢旋转的现象，这一旋转是地球自转的直接证据。福科摆锤不仅是物理学的一个重要实验，也成为了科学与艺术的结合象征。

塞纳河

清晨的塞纳河如诗如画，漫步在河畔，感受到巴黎的静谧与美好。

塞纳河是法国的一条主要河流，流经巴黎市中心。河流全长约 777 公里，起源于勃艮第地区的普拉特高原，最终流入英吉利海峡。塞纳河穿过巴黎时，河两岸布满了历史悠久的桥梁和著名的景点，如巴黎圣母院和埃菲尔铁塔。河流不仅是巴黎的重要交通水道，也是旅游和休闲的热门地点，常有游船在此穿梭，提供观光和餐饮服务。

马德莱娜教堂

马德莱娜教堂（Église de la Madeleine）是一座罗马天主教的教堂，以其古典希腊神庙风格著称。这座教堂建于 19 世纪初，外部有 52 根科林斯式柱子环绕。虽然外观极其庄严、类似神庙，但内部装饰华丽，拥有精美的雕刻和壁画。马德莱娜教堂不仅是宗教活动的场所，也常用于举行音乐会，特别是古典音乐演出。

圣心堂

圣心堂（Basilique du Sacré-Cœur）位于法国巴黎蒙马特高地，是一座罗马天主教教堂，以其白色圆顶著称。这座教堂建于 1875 年至 1914 年间，是为了纪念普法战争中的法国阵亡将士而兴建的。圣心堂采用了罗曼 - 拜占庭风格的建筑设计，内部装饰华丽，拥有壮观的马赛克和雕塑。它不仅是巴黎的一个重要宗教地点，也因其位于城市之巅，提供了俯瞰巴黎全景的绝佳视角。

除此之外，我还在骑行过程中游览了巴黎圣母院、香榭丽舍大道、爱丽舍宫、小皇宫、凯旋门、协和广场、杜乐丽花园、卢森堡公园等，限于篇幅不在此展开。

关于奥运会

现代奥运会是法国人在巴黎提倡的，可能是法国人对奥运会已经司空见惯，也有可能是为了尽可能不打扰本地人的生活，此次巴黎之行，感受不到任何奥运会将在巴黎召开的气氛。只有一些标志性建筑旁在搭建一些展台可能是为了供奥运会使用，以及一些商店在售卖奥运会纪念品。

评论

最近在中文互联网上，经常看到一些视频介绍巴黎的治安、环境是如何的不堪，比如街道上很多小偷、随地大小便、找不到厕所等。幸运的是我并没有遇到小偷，也没听到同伴有这样的遭遇。但是确实在一些街道尤其是景区周边闻到一些尿骚味，也遭遇了几个流浪汉问我要烟。还有就是卢浮宫里找不到厕所，唯一找到的一个男厕所还在维修中。

总结

巴黎这座城市以其独特的魅力和丰富的文化底蕴给我留下了深刻的印象。这里的人们热情友好，景色美丽动人。虽然在一些游客密集的地方可能会稍显杂乱，但这也是任何旅游城市难以避免的现象。巴黎之行充满了美好的回忆，让人流连忘返，期待未来再次踏上这片浪漫的土地。也希望这篇游记能对初次踏上这篇土地人有所帮助。

2024-06-14 19:14:40

Istio 依赖 Kubernetes 来进行服务发现，这通常意味着必须在 Kubernetes 集群中部署微服务并使用 Kubernetes 服务发现。然而，很多现有的微服务项目还在使用如 Consul、Eureka 这样的第三方服务注册表，本文将探讨如何将这些现有的微服务的注册表与 Istio 集成。

Istio 对非 Kubernetes 服务的支持

Istio 最初只支持 Kubernetes 服务，但随着时间的推移，为了适应更广泛的应用场景，它开始支持像 Consul 这样的第三方服务注册表。通过引入 Mesh Configuration Protocol（MCP），Istio 能够与各种服务发现后端通信，如 Consul，从而管理非 Kubernetes 环境中的服务。在 Istio 1.1 版本中，引入了 ServiceEntry 资源对象，这使得用户可以手动将外部服务添加到 Istio 的服务注册表中，并在 Istio 1.8 中取消了对 Consul 的直接支持，转而通过 ServiceEntry 提供了一种更灵活的方式来集成和管理所有服务，无论它们是否托管在 Kubernetes 上。

Istio 代理配置的高层架构

下图展示了 Istio 代理配置的高层架构，揭示了配置如何从各种源被摄取、转换，并最终服务于 Envoy 代理。

要想详细了解 Istiod 的架构，可以参考 Istio 架构详解。

配置摄取过程详解

• ConfigStore: 负责读取多种类型的资源并进行聚合。包括：
  • XDS Client: 通过 xDS 协议读取资源。
  • CRD Client: 从 Kubernetes 自定义资源定义（CRD）读取资源。
  • Filesystem Client: 从文件系统读取资源。
• ServiceDiscovery: 聚合面向服务的内部资源。使用的组件包括：
  • Kube Controller: 依据 Kubernetes 核心类型运行。
  • ServiceEntry Controller: 依据 Istio 类型运行。

配置翻译与服务

配置从 ConfigStore 和 ServiceDiscovery 聚合后，由 Config Translator 翻译成适合代理的格式，然后通过 XDS Server 服务于 Envoy 代理。这是将动态配置应用于代理的最终步骤。

第三方注册表同步

为了集成第三方服务注册表，我们可以实现一个 Operator，该 Operator 监视第三方服务注册表并将服务以 ServiceEntry 和 WorkloadEntry 资源形式推送至 Kubernetes API 服务器。以下流程图展示了该同步过程。

第三方服务注册表同步的步骤说明

1. Operator 向第三方服务注册表发起查询请求。
2. 第三方服务注册表返回当前注册的服务数据。
3. Operator 将服务数据转换为 Istio 的 ServiceEntry 对象。
4. Operator 将 ServiceEntry 推送至 Kubernetes API 服务器。
5. Kubernetes API 服务器将变更通知 Istiod。
6. Istiod 更新 Envoy Proxies 的配置。
7. Operator 定期检查第三方服务注册表以监控服务变化，发现变更后更新 ServiceEntry 并重新推送至 Kubernetes API 服务器，完成服务同步。

Istio Registry Sync

Tetrate 开发的 Istio Registry Sync 是一个扩展 Operator，可以作为 TIS 的 add-on 运行。它支持非 Kubernetes 服务注册表（如 AWS Cloud Map 和 Consul）与 Istio 的集成。此工具提供了以下几个使用场景：

• 混合应用集成: 在混合环境中，如使用 Consul 的传统应用与 AWS Cloud Map 中的微服务可以通过 Istio Registry Sync 实现无缝的服务发现。
• 动态端点管理: 在服务频繁扩缩的环境中，Istio Registry Sync 能快速反映来自配置注册表的变更，确保 Istio 服务网格中的流量管理策略准确有效。
• 统一的监控与安全态势: 通过将所有环境的服务集成至 Istio，可以利用 Istio 提供的服务健康指标和统一的安全协议，如 mTLS，确保跨所有服务的加密和认证通信。

总结

通过上述方法，你可以有效地将 Istio 与第三方服务注册表集成，无论是通过开发自定义的 Operator 还是使用现成的 Istio Registry Sync 工具。这样不仅能够保持服务的现代化，还能确保在不同环境之间的高效协同工作。

参考资料

• Istio Pilot Architecture - github.com
• Istio Registry Sync Documentation - docs.tetrate.io

2024-06-11 16:23:50

最近 Istio 1.22 发布包含大量的重大更新，本文将为你分享这个发布带来的新特性及应用建议。

Ambient 模式进入 Beta 阶段

虽然 Ambient 模式现已进入 Beta 阶段，但这并不意味着我们可以完全告别 Sidecar。尽管 Istio 官方宣称 Ambient 模式可以简化操作并显著减少内存和 CPU 使用，但它仍然存在局限性和潜在的复杂性问题。例如，虽然取消了 Sidecar，但需引入新的 ztunnel 和 waypoint 组件，这可能带来新的挑战。关于 Ambient 模式进入 Beta 模式的详细信息请参阅 Istio 官方博客。

Ambient 模式带来的新的挑战

• Ambient mode 对 L7 流量的管理仍未成熟
• mTLS 被强制在 namespace 级别开启，也就是说使用 Ambient 模式你无法关闭 mTLS
• Ambient 模式的无宕机升级仍未解决
• 缺少 与 Sidecar 模式共存和迁移的最佳实践

关于 Sidecar 模式和 Ambient 模式的对比，详见 Istio Ambient 模式的局限性解析。

Istio API 升级

Istio Istio 1.22 版本中，关键 API 如流量管理、安全、Telemetry 相关的 API 都已正式升级到 v1 版本。你只需要将原有配置的 API 版本修改为 v1 即可，除此之外不需要任何更改。这些 API 早已成熟，你可以放心的使用 v1 版本，对于对稳定性要求较高的环境，Istio 添加了验证准入策略确保只有 v1 API 和字段可以在 Istio API 中使用。

例如下面的 AuthorizationPolicy 示例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: finance-to-supply-chain
  namespace: finance
spec:
  selector:
    matchLabels:
      app: finance-app
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["finance"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/supply1", "/api/supply2"]
    when:
    - key: request.headers[:authority]
      values: ["supply-chain-service.supply-chain.svc.cluster.local"]

其他扩展类的 API 如 EnvoyFilter、WasmPlugin、ProxyConfig 还未成熟，因此还停留在 alpha 或 beta 阶段。关于 API 升级的更多信息，请参考 v1 API 博客。

Gateway API 升级

Gateway API 已更新至版本 1.1.0，现已普遍可用。这一更新扩展了 Istio 的流量管理能力，但需要注意 Istio 原生 API 与 Gateway API 的兼容性问题。在迁移到新 API 时应谨慎，以避免依赖尚未完全成熟的特性。更多详情，请查看 Gateway API v1.1 博客。

增量 xDS 默认启动

Istio 1.22 版本默认启用了增量 xDS，这是一个优化配置分发的机制。与传统的 State of the World（SotW）模式相比，增量 xDS 仅将变更的配置发送给 Envoy 代理，从而显著减少了网络传输的数据量和控制平面的资源消耗。这一变更尤其适用于配置频繁更新的大规模部署环境，能够提高配置更新的效率和性能。此外，增量 xDS 还有助于在网络环境复杂或配置动态变化的情况下，更高效地管理服务网格的配置更新。

更多关于 xDS 的介绍请参考Envoy xDS 及 Istio 中的配置分发流程介绍。

AuthorizationPolicy 的路径模板支持通配符

在 Istio 1.22 中，AuthorizationPolicy 新增了对路径模板的支持，极大增强了路径匹配的灵活性和精确性。而在此之前，AuthorizationPolicy 的路径配置并不支持通配符。此功能允许使用基于 Envoy 的 URI 模板匹配来定义 HTTP 请求中的路径。路径可以包括简单的通配符（* 和 **）或具名变量，从而精确匹配单个或多个路径组件。例如，路径模板 /foo/{*} 能匹配 /foo/bar 但不匹配 /foo/bar/baz，而 /foo/{**}/ 则可以匹配任何以 /foo/ 开头的路径。这种灵活的路径模板设计，特别适用于动态和复杂的路由规则，进一步加强了 Istio 的安全策略工具箱。

下图展示了 AuthorizationPolicy 的路径匹配的通配符规则。

了解更多关于路径模板的具体应用和规则，你可以参考 Envoy 的官方文档。

总结

Istio 1.22 版本引入了多项重要更新和改进，尽管某些特性被广泛宣传，但在实际使用中需要进行详细评估和适当的测试。希望本篇博客能帮助你更深入地理解和应用这些新特性，以在实际操作中获得最佳效果。

参考

• Gateway API v1.1: Service mesh, GRPCRoute, and a whole lot more - kubernetes.io

2024-06-10 10:38:16

三年前，我与 Addo 环游了新疆北疆，那次旅行让我久久难忘，尤其是伊犁河谷地带，始终萦绕在心头。这次端午佳节，我决定再赴伊犁，开启一场自驾之旅。

经过精心策划，我从北京出发，途经乌鲁木齐转机，来到美丽的伊宁。在这里，我们租了一辆车，开始了为期一周、总行程 1344 公里的自驾之旅。

航拍视频

在这段视频中，你将看到我在旅途中拍摄的壮丽航拍画面。从广阔的草原到清澈的湖泊，从巍峨的雪山到蜿蜒的公路，这些美景都在视频中得到了完美的呈现。

伊宁喀赞其

我们的第一站是伊宁市的喀赞其民俗村，这是一个充满民族风情的小镇。这里的街道两旁是独具特色的传统民居，五彩斑斓的墙壁和蓝色的大门，仿佛童话世界。喀赞其的生活气息浓厚，街上随处可见当地居民的日常生活场景。

伊犁河

从喀赞其出发，我们前往了伊犁河。伊犁河的河水清澈见底，两岸绿树成荫，广阔的湿地景色宜人。我们在伊犁湿地公园观看了一场壮美的日落，沉醉于大自然的美景中。

喀拉峻

第三站是喀拉峻草原。广阔的草原上，牛羊成群，远处的雪山与蓝天白云相映成趣，构成了一幅绝美的自然画卷。这里平均海拔 2000 多米，空气格外清新，每一口呼吸都让人感到无比的舒畅。我在这里露营了一晚，经过了一夜的风雨，第二天雨过天晴日出时，阳光洒在身上暖洋洋的，眺望远处的日照金山。

琼库什台

接下来，我们来到了琼库什台。这个哈萨克族的原始村庄虽然多了一些商业气息，但依然保留着原始的魅力。草原和河谷里新开的民宿和饭店让更多游客慕名而来。我们骑马前往后山，体验了最纯粹的自然风光。尤其是夕阳西下时，在山顶看着连绵起伏的草原和远处的雪山交相辉映，相映成趣。

夏塔古道

夏塔古道是此次行程中的重要景点。古道曾是丝绸之路上的一部分，沿途高山峡谷景色壮丽。尽管景区尚未开放，我们还是通过无人机航拍领略了这里的冰川河谷。

伊昭公路

伊昭公路被誉为新疆最美的公路之一。沿途风景从高山到草原，从森林到湖泊，变幻多姿。行驶在悬崖峭壁上，不禁感叹开路人的艰辛。

赛里木湖

最后一站是赛里木湖，位于博尔塔拉蒙古自治州。这个高山湖泊的湖水清澈见底，碧蓝如普鲁士蓝，四周环绕着雪山和草原，景色如诗如画。我们在湖边漫步，夜宿赛里木湖西岸，感受这座号称“大西洋的最后一滴眼泪”的静谧与壮丽。

这次新疆伊犁自驾之旅不仅让我领略了壮丽的自然风光，还体验了当地独特的民族文化。通过航拍镜头，我记录下了这一路的美景，制作成了一个视频与大家分享。

美食

伊犁不仅风景如画，美食也令人垂涎。红柳烤肉的鲜香、辣子肉的香辣（当地人将它作为早餐，配合花卷一起吃）、椒麻鸡的麻辣、赛里木湖的高山鲑鱼籽炒饭的鲜香，都是我旅途中难忘的味道。

另外新疆的干果、奶酪和牛肉干也是不错的伴手礼。

总结

这次旅程将成为我人生中一段难忘的回忆。新疆伊犁的美景与魅力，让我深深地爱上了这片土地。如果有机会，我一定会再来这里，探索更多未尽的风景。

希望这篇游记能带给你一些关于新疆伊犁的美好回忆。如果你也有机会去新疆旅行，一定不要错过这些美丽的景点。

2024-06-04 16:18:06

在 Istio 项目的早期采用全局状态（State of the World，简称 SotW）的方式推送配置给 Envoy 代理。一旦有一个服务变更，就要将全局配置推送给所有 Sidecar，造成巨大的网络负担及控制平面的性能损耗。Istio 社区从几年前就开始开发增量 xDS 以解决此问题，并在最近几个 Istio 版本中支持了增量 xDS。在最近的 Istio 1.22 发布中，增量 xDS 成为默认开启的功能。本文将为你介绍 xDS、增量 xDS 及 Istio 的配置分发方式。

什么是 xDS？

xDS（Extensible Discovery Service）是一种通信协议，用于在微服务架构中管理服务发现和动态配置。这种机制被广泛用于 Envoy 代理和 Istio 服务网格中，以管理各种类型的资源配置，如路由、服务发现、负载均衡设置等。

xDS 包含哪些发现服务？

xDS 包括以下主要的发现服务，每种服务都负责不同类型的网络资源配置：

1. LDS（Listener Discovery Service）：管理 Envoy 监听器的配置，这些监听器定义了如何接收和处理入站连接。
2. RDS（Route Discovery Service）：提供路由信息，定义了如何根据指定规则将请求路由到不同的服务。
3. CDS（Cluster Discovery Service）：管理集群信息，集群代表一组逻辑上类似的后端服务实例。
4. EDS（Endpoint Discovery Service）：提供具体服务实例的网络地址，这些服务实例组成了 CDS 中定义的集群。
5. SDS（Secret Discovery Service）：管理安全相关的配置，如 TLS 证书和私钥。
6. VHDS（Virtual Host Discovery Service）：为 RDS 提供虚拟主机配置，允许动态更新虚拟主机而不重启连接。
7. SRDS（Scoped Route Discovery Service）：管理路由作用域，提供基于不同条件（如请求头部）的动态路由选择。
8. RTDS（Runtime Discovery Service）：提供运行时配置，这些配置可用于实验性功能或精细调整系统行为。
9. ECDS（Extension Config Discovery Service）：为特定过滤器提供动态配置更新的服务。目前，网络过滤器、HTTP 过滤器和监听器过滤器都支持 ECDS。

这些服务共同支持动态配置的分发和更新，使得基于 Envoy 的应用架构能够实时适应变化，提高可扩展性和灵活性。每种服务的实现可以独立进行，也可以通过聚合方式（如 ADS）进行统一管理。CNCF 也成立了 xDS API 工作组来推动 xDS API 为 L4/L7 数据平面配置提供事实上的标准，类似于 SDN 中 OpenFlow 在 L2/L3/L4 中所扮演的角色。

xDS 协议的变体

xDS 协议主要包括以下变体：

1. State of the World (SotW)：单独的 gRPC 流为每种资源类型提供完整数据，通常在 Envoy 代理初次启动时使用，也是 Istio 最早使用的 xDS 协议类型。
2. 增量 xDS（Delta xDS）：为每种资源类型提供变化的部分数据，从 2021 年开始开发，在 Istio 1.22 版本中开始默认开启。
3. 聚合发现服务（ADS）：一个 gRPC 流聚合所有资源类型的数据。
4. 增量 ADS（Delta ADS）：一个 gRPC 流聚合所有资源类型的增量数据。

下表概述了 xDS 协议的四种变体，包括对每个变体的解释、使用场景以及优缺点的对比。这些变体为不同的网络环境和服务需求提供了多种选择，可以根据具体情况选择最合适的协议变体以优化服务的性能和资源使用。

使用 xDS 协议的服务网格可以更灵活地管理微服务之间的通信和配置，减少了配置变更的延迟，提高了系统的响应速度和可靠性。

在 Istio 中，DiscoveryServer 作为 Envoy 的 xDS API 的实现，负责监听 gRPC 接口并根据 Envoy 的需求动态推送配置。它能够处理各种资源类型的请求，并根据服务的变更实时更新 Envoy 配置。此外，它还支持安全特性，如验证客户端证书，确保只有合法的服务实例可以接收配置数据。

xDS 变体的配置示例

使用 xDS 协议的变体通常涉及在 Envoy 代理或与之类似的服务网格配置中指定 xDS 服务器的详细信息。虽然不同的服务网格和代理服务器的配置细节可能有所不同，下面是一些通用的 YAML 配置示例，说明如何指定 xDS 服务器以及如何使用这些协议变体。

State of the World (SotW)

在 Envoy 的配置中，你可以通过静态资源或通过 API 动态获取资源的方式来使用 SotW。这里是一个简单的 Envoy 配置示例，显示了如何静态定义集群和监听器：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

static_resources:
  listeners:
    - address:
        socket_address: { address: 0.0.0.0, port_value: 80 }
      filter_chains:
        - filters:
            - name: envoy.http_connection_manager
              config:
                stat_prefix: ingress_http
                codec_type: auto
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: local_service
                      domains: ["*"]
                      routes:
                        - match: { prefix: "/" }
                          route: { cluster: local_service }
                    http_filters:
                      - name: envoy.router
                  clusters:
        - name: local_service
            connect_timeout: 0.25s
            type: STATIC
            lb_policy: ROUND_ROBIN
            hosts: [{ socket_address: { address: 127.0.0.1, port_value: 80 } }]

增量 xDS

增量 xDS 的配置需要在 xDS 服务端支持增量协议，并在客户端配置中指定使用增量 xDS。Envoy 启动配置中需要添加 API 版本来启用增量 xDS：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

dynamic_resources:
  cds_config:
    api_config_source:
      api_type: DELTA_GRPC
      grpc_services:
        envoy_grpc:
          cluster_name: xds_cluster
  lds_config:
    api_config_source:
      api_type: DELTA_GRPC
      grpc_services:
        envoy_grpc:
          cluster_name: xds_cluster

聚合发现服务 (ADS)

使用 ADS 时，所有资源类型的配置通过一个单一的 API 端点聚合。这在 Envoy 配置中指定：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

dynamic_resources:
  cds_config:
    ads: {}
  lds_config:
    ads: {}
  ads_config:
    api_type: GRPC
    grpc_services:
      envoy_grpc:
        cluster_name: xds_cluster

增量 ADS

增量 ADS 通过在 ADS 配置中指定增量 API 类型，可以实现更为细粒度的更新：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

dynamic_resources:
  cds_config:
    ads: {}
    resource_api_version: V3
  lds_config:
    ads: {}
    resource_api_version: V3
  ads_config:
    api_type: DELTA_GRPC
    grpc_services:
      envoy_grpc:
        cluster_name: xds_cluster

这些配置示例需要根据你的具体环境和需求进行调整。更多细节和高级配置，你可以参考 Envoy 文档。

Istio 如何发送配置给 Envoy sidecar？

得益于 xDS 协议，如 Istio、Envoy Gateway 等可以通过 API 远程动态分发配置到 Envoy 代理。下图展示了 Istio 的配置分发流程（Sidecar 模式）。

Istio 中配置分发的主要流程说明：

1. 声明式配置：用户通过 YAML 文件或其他配置管理工具定义服务网格的配置。这些配置可以包括路由规则、安全策略、遥测设置等。
2. Kubernetes：Istio 配置文件被提交到 Kubernetes 集群中，通常是通过 kubectl apply 命令或其他 CI/CD 工具。Kubernetes 接收到配置文件并将其存储在 etcd 数据库中。
3. Istiod：Istiod 是 Istio 的控制平面组件，负责管理和分发配置。它监听从 Kubernetes API 服务器中传入的事件，获取相关配置变更，并对其进行处理。Istiod 解析配置文件，生成相应的路由规则和策略，并通过 xDS API 将这些配置分发到数据平面（Envoy 代理）。
4. xDS API：Istiod 使用 xDS API 将配置下发到各个 Envoy 代理中。
5. Envoy Proxy：Envoy 是 Istio 的数据平面组件，运行在每个服务的旁路（sidecar）容器中，拦截并管理所有入站和出站流量。Envoy 代理通过 xDS API 接收来自 Istiod 的配置，并根据这些配置进行流量管理、策略执行和遥测数据收集。
6. Pod：每个服务实例运行在一个 Pod 中，Pod 内部包含一个应用容器和一个 Envoy 代理容器。Envoy 代理拦截应用容器的所有网络流量，并根据配置进行处理。

这个配置分发流程确保了 Istio 能够动态管理和配置服务网格中的所有服务实例，提供一致的流量管理和策略执行。

xDS 的发展与 Istio 中的 Delta xDS 实现

起初，xDS 采用了“全局状态”（State of the World，简称 SotW）的设计，这意味着任何一个配置的更改都需要向 Envoy 发送所有配置的完整状态。这种方法在网络和控制平面上造成了巨大的负担，尤其是在大规模服务部署时。

在 2021 年的 EnvoyCon 上，Aditya Prerepa 和 John Howard 分享了 Istio 如何实现 Delta xDS，这是一种增量式的 xDS 实现。与传统的 SotW xDS 相比，Delta xDS 只发送变更的配置，显著减少了需要通过网络发送的配置数据量，从而提高了效率和性能。这种方法特别适用于那些配置频繁变更的环境，因为它只更新变化的部分而不是整个配置。

在实现 Delta xDS 的过程中，Istio 团队面临了多个挑战，包括如何确保配置更新的正确性以及避免潜在的资源泄漏。他们通过采用干运行（Dry-run）模式来并行运行 SotW 和 Delta 生成器，逐步发现并修复了实现中的缺陷。此外，他们还引入了新的 Envoy 类型，如虚拟主机发现服务（Virtual Host Discovery Service），以支持更细粒度的配置分发。

Delta xDS 增量配置

下图展示了 Delta xDS 增量配置的流程。

Delta xDS 配置流程如下：

1. 初始完整配置：控制平面向代理发送初始完整配置，此时使用的是 StoW 模式。
2. 订阅配置变更：代理从控制平面订阅配置变更。
3. 检查配置变更：控制平面检查相对于代理已知状态的配置变更。
4. 计算差异：控制平面计算当前配置与代理持有的前一配置之间的差异（增量）。
5. 仅发送差异：控制平面仅发送变更的配置（差异）给代理，代理应用这些差异增量更新其配置。

该流程确保只有必要的变更被传输和应用，提高了效率并减少了网络和代理资源的负载。

SotW vs Delta xDS

虽然 Delta xDS 解决了在大规模网络下的配置分发的性能问题，但是 SotW 模式依然有它存在的意义，比如在初次下发配置的情况下。下表对比了 Istio 中的两种配置分发方式：SotW (State of the World) 和 Delta xDS。

这个表格从数据传输量、效率、复杂性、资源消耗、实时性以及适用场景等多个角度对 SotW 和 Delta XDS 进行了对比，有助于在不同的使用环境中做出合适的选择。

总结

在这篇文章中我分享了 xDS 的组成及 Istio 中配置分发的流程，还有 xDS 的两种模式 SotW 和 Delta xDS。随着 Delta xDS 在 Istio 1.22 版本中成为默认配置，这将有助于用户在大规模网络环境下轻松使用 Istio。

参考

• xDS REST and gRPC protocol - envoyproxy.io

2024-05-31 10:21:36

最近我用 Fuse 和 Hugo 导出的全站结构化数据（压缩后仅 2MB）做的即时搜索，还有快捷搜索地址 https://jimmysong.io/search/?q=关键词，定制了下结果展示页面，这就是开源的强大之处，任何地方都可以私人订制。

概览

下面我将分享下如何为你的 Hugo 网站添加即时搜索功能。大体步骤如下：

1. 导出 Hugo 网站的结构化数据
2. 使用 Fuse 库构建搜索的 JavaScript 代码
3. 添加前端搜索模板
4. 自动化更新网站结构化数据
5. 进一步优化

1. 导出 Hugo 网站的结构化数据

首先，你需要为你的 Hugo 网站创建一个 JSON 文件，它将包含所有页面的必要元数据，如标题、描述、链接等。你可以通过 Hugo 的自定义输出格式来实现这一点。

在你的 Hugo 配置文件（通常是 config.toml 或 config.yaml）中，添加一个自定义输出格式：

[outputs]
home = ["HTML", "RSS", "JSON"]

[outputFormats.JSON]
mediaType = "application/json"
baseName = "index"
isPlainText = false

然后，在你的内容模板中（如 layouts/_default/list.json.json），定义输出的 JSON 结构：

{
  "data": [
    {{ range .Pages }}
    {
      "title": "{{ .Title }}",
      "url": "{{ .Permalink }}",
      "summary": "{{ .Summary }}"
    }
    {{ if not (eq .Next nil) }},{{ end }}
    {{ end }}
  ]
}

这将为你的整个站点生成一个 index.json 文件，其中包含所有页面的基本信息。当然你可能不想导出网站的所有页面，可以通过 Hugo 的语法，可定制化导出的 Section 或者不同类型页面。

2. 使用 Fuse 库构建搜索的 JavaScript 代码

接下来，使用 Fuse.js 库来实现前端的即时搜索功能。首先，你需要在你的网站中包含 Fuse.js 的库文件。你可以从 jsDelivr 等 CDN 加载它：

<script src="https://cdn.jsdelivr.net/npm/fuse.js/dist/fuse.min.js"></script>

然后，在你的 JavaScript 文件中，加载并解析 index.json 文件，并使用 Fuse.js 进行搜索：

fetch('/index.json')
  .then(response => response.json())
  .then(data => {
    const fuse = new Fuse(data.data, {
      keys: ['title', 'summary'],
      includeScore: true
    });

    document.getElementById('search-input').addEventListener('input', function (e) {
      const results = fuse.search(e.target.value);
      displayResults(results);
    });
  });

function displayResults(results) {
  const searchResults = document.getElementById('search-results');
  searchResults.innerHTML = '';
  results.forEach(result => {
    const elem = document.createElement('div');
    elem.innerHTML = `<a href="${result.item.url}">${result.item.title}</a>`;
    searchResults.appendChild(elem);
  });
}

具体实现可以参考 wowchemy-search.js。

3. 添加前端搜索模板

在你的网站中添加一个搜索框和结果显示区域：

<input type="text" id="search-input" placeholder="输入搜索词">
<div id="search-results"></div>

另外你还可以添加搜索快捷键，一般是组合键 ⌘/CTRL + K 来快速打开搜索页面。

具体实现可以参考 这个前端模板。

4. 自动化更新网站结构化数据

为了保证搜索结果的实时性，可以通过 GitHub Actions 或其他 CI/CD 工具来自动化 Hugo 网站的构建和部署流程，确保 index.json 文件始终是最新的。

创建一个 .github/workflows/hugo_build.yml 文件，定义自动化流程：

name: Build and Deploy
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    - name: Set up Hugo
      uses: peaceiris/actions-hugo@v2
      with:
        hugo-version: 'latest'
    - name: Build
      run: hugo --minify
    - name: Deploy
      uses: peaceiris/actions-gh-pages@v3
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}
        publish_dir: ./public

另外如果你的网站支持多语言，可以为每种语言分别生成 index.json 文件，并在不同的语言页面加载对应的索引文件。

5. 进一步优化

• 缓存优化：为 index.json 设置合理的缓存策略，以减少服务器负载和提高响应速度。如果你是会用的是 Github Pages 作为静态网站，那么可以忽略这一步。
• 数据压缩：压缩你的 index.json 文件，你可以选择导出网站的部分数据，比如某些 Section 的数据，对 Content 进行截取，或者压缩文件成 gz 格式，在 JavaScript 加载后再在前端解压，这样可以减少网络数据传输。
• 搜索结果高亮：增加搜索结果中关键词的高亮显示，提升用户体验。
• 高级搜索选项：允许用户通过特定字段（如作者、分类）进行过滤搜索。
• 网络优化：异步加载用于搜索的 JavaScript 文件，

通过这些步骤，你可以有效地为你的 Hugo 网站添加一个高效且可定制的即时搜索功能。

总结

本文介绍了如何为 Hugo 网站添加即时搜索功能，并提供了进一步优化搜索功能的建议，包括缓存优化、搜索结果高亮显示和高级搜索选项。这不仅展示了开源技术的强大自定义能力，也使网站用户能更快更准确地找到所需信息。

2024-05-24 10:20:20

在微服务中常见的认证方式详解这篇博客中我们介绍到了 OAuth 2.0 认证，该身份认证协议有多种实现方式，其中最流行的就是 OpenID Connect（OIDC）认证。OIDC 能够为用户提供身份验证和授权。本文将介绍如何使用 Envoy Gateway 在 API 网关级别实现 OIDC 认证。

Envoy Gateway 支持的认证方式

Envoy Gateway 是一个使用 Envoy 实现的高性能的 API 网关，支持多种认证方式来保护 API 和微服务：

1. JWT 认证: 使用 JSON Web Tokens（JWT）进行认证。
2. mTLS（双向 TLS）: 使用双向 TLS 确保客户端和服务器之间的安全通信。
3. HTTP Basic 认证: 使用用户名和密码进行基本认证。
4. OIDC 认证: 使用 OpenID Connect 协议进行身份验证和授权。
5. 外部认证：外部认证调用外部 HTTP 或 gRPC 服务来检查传入的 HTTP 请求是否经过认证。

本文重点介绍如何在 Envoy Gateway 中配置和使用 OIDC 认证从而在网关侧实现单点登录。

什么是 OIDC？

OpenID Connect（OIDC）是一个基于 OAuth 2.0 的身份验证协议。它允许客户端通过认证服务器验证用户身份，并获取有关用户的信息。

OIDC 认证流程如下图所示：

OIDC 为 OAuth 2.0 增加了身份验证层，通过引入 ID Token 和标准化的 UserInfo Endpoint，使 OAuth 2.0 不仅能够用于授权，还可以用于安全地验证用户身份，从而实现单点登录（SSO）和用户身份信息的获取。

为什么要实现单点登录？

单点登录（Single Sign-On, SSO）是一种身份验证方式，它允许用户使用一个账户登录多个独立的应用系统，通过一次身份验证即可无缝访问所有相关应用，减少重复输入用户名和密码的麻烦，从而提升用户体验。SSO 集中管理用户身份和认证，增强了系统安全性，并简化了 IT 管理流程。

对于微服务架构，SSO 尤其重要，因为它在各个微服务之间实现统一的认证和授权，避免了每个服务单独实现身份验证逻辑的需求，减少了用户重复登录的麻烦，并提高了用户体验。集中管理的方式还可以统一应用安全策略，更有效地监控和响应安全事件，提升系统的整体安全性。同时，通过使用标准化的令牌（如 JWT），SSO 简化了微服务之间的身份验证过程，提高了开发效率，让开发人员能够专注于业务逻辑的实现。

示例：使用 Envoy Gateway 和 Auth0 的单点登录

接下来我们将使用 Auth0 作为身份供应商，演示如何使用 Envoy Gateway 在 API 网关端实现单点登录。

你可以在 Bilibili 上查看该示例演示。

基于 Auth0 实现单点登录

首先我们先说明下示例中 Envoy Gateway 基于 Auth0 实现单点登录的详细流程，如下图所示。

步骤说明：

1. 用户访问网站：用户通过浏览器访问 https://www.example.com。
2. 请求转发：浏览器向 Envoy Gateway 发送 GET 请求。
3. 检查 ID 令牌：Envoy Gateway 检查用户请求的 cookie 是否包含有效的 ID 令牌。
4. 重定向到身份提供商：如果没有找到 ID 令牌，Envoy Gateway 将用户重定向到身份提供商（Identity Provider，IdP）的授权端点，在这里是 Auth0，关于 Auth0 如何实现 Login 的详细信息请查看 Auth0 文档。
5. 用户登录：用户在身份提供商的登录页面输入用户名和密码，并提交凭证进行登录。
6. 获取授权码：用户成功登录后，身份提供商将用户重定向回 Envoy Gateway，并在 URL 中包含授权码。
7. 交换 ID 令牌：Envoy Gateway 使用授权码向身份提供商请求 ID 令牌。
8. 设置 Cookie：身份提供商返回 ID 令牌，Envoy Gateway 将其设置为用户的 cookie。
9. 重定向：Envoy Gateway 将 URL 重定向到 https://www.example.com。
10. 验证 ID 令牌：Envoy Gateway 验证用户请求中的 ID 令牌。
11. 路由请求：验证通过后，Envoy Gateway 将请求路由到后端应用（App）。

通过上述流程，Envoy Gateway 实现了单点登录功能。用户的 HTTP 请求在没有得到授权的情况下都会被转发单点登录页面。除了 Auth0 以外，Envoy Gateway 还支持多个身份提供商，如 Azure AD、Keycloak、Okta、OneLogin、Salesforce、UAA 等。

下面我们将按照时序图中的流程配置 Auth0 和 Envoy Gateway。

在 Auth0 上创建应用

请参考以下步骤在 Auth0 上设置一个 Regular Web Application：

1. 访问 Auth0 并注册一个免费账户。
2. 创建一个新的应用，并选择常规 Web 应用程序。
3. 在应用设置中，记录或设置以下字段：
   • Domain ：{DOMAIN}
   • Client ID：{CLIENT_ID}
   • Client Secret：{CLIENT_SECRET}
   • Allowed Callback URLs：https://www.example.com/oauth2/myapp/callback
   • Allowed Logout URLs：https://www.example.com/myapp/logout

记住上面的 Auth0 字段，我们将用它们来配置 Envoy Gateway 的安全策略。

下面展示的是 Auth0 的配置页面截图，在设置好用户后并创建普通 Web 应用后，你只需要配置这两个地方。

以上就是 Auth0 的全部配置，接下来我们将安装和配置 Envoy Gateway。

安装 Envoy Gateway

参考 Envoy Gateway 快速开始在 minikube 上安装 Envoy Gateway：

minikube start --driver=docker --cpus=2 --memory=2g
helm install eg oci://docker.io/envoyproxy/gateway-helm --version v1.0.1 -n envoy-gateway-system --create-namespace
kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v1.0.1/quickstart.yaml -n default

参考安全网关，为 Envoy Gateway 配置 TLS：

# 创建根证书和私钥来签署证书
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt

# 为 www.example.com 创建证书和私钥
openssl req -out www.example.com.csr -newkey rsa:2048 -nodes -keyout www.example.com.key -subj "/CN=www.example.com/O=example organization"
openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in www.example.com.csr -out www.example.com.crt

# 将证书/密钥存储在 Secret 中
kubectl create secret tls example-cert --key=www.example.com.key --cert=www.example.com.crt

更新快速开始中创建的网关，使其包含 443 端口并引用 example-cert Secret 的 HTTPS Listener：

echo '[
  {
    "op": "add",
    "path": "/spec/listeners/-",
    "value": {
      "name": "https",
      "protocol": "HTTPS",
      "port": 443,
      "tls": {
        "mode": "Terminate",
        "certificateRefs": [
          {
            "kind": "Secret",
            "group": "",
            "name": "example-cert"
          }
        ]
      }
    }
  }
]' | kubectl patch gateway eg --type=json --patch-file /dev/stdin

创建 HTTPRoute，为 /myapp 端点增加一条到backend 服务的路由：

cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: myapp
spec:
  parentRefs:
  - name: eg
  hostnames: ["www.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /myapp
    backendRefs:
    - name: backend
      port: 3000
EOF

配置 Envoy Gateway 的 OIDC 认证

创建一个 Kubernetes Secret，用于存储 OAuth Client 的 Client Secret：

kubectl create secret generic auth0-client-secret --from-literal=client-secret=${CLIENT_SECRET}

创建一个安全策略（SecurityPolicy）：

cat <<EOF | kubectl apply -f -
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: oidc-example
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: eg
  oidc:
    provider:
      issuer: "https://${DOMAIN}"
    clientID: "${CLIENT_ID}"
    clientSecret:
      name: "auth0-client-secret"
    redirectURL: "https://www.example.com/myapp/oauth2/callback"
    logoutPath: "/myapp/logout"
EOF

注意事项

• 此处的 issuer 应该填写成 Auth0 Domain。
• redirectURL 的值需要出现在 Auth0 配置的 Allowed Callback URLs 中。
• logoutPath 是必须的，即使其 URL 端点并为实现 logout 逻辑。

在这个示例中我们为 Envoy Gateway 网关设置了 OIDC，修改 targetRef 到 HTTPRoute，也可以为单个路由设置 OIDC。关于 ODIC 的具体配置，请参考 Envoy Gateway API 文档。

验证单点登录：登入

将 www.example.com 添加到本地的 /etc/hosts 文件中：

echo "127.0.0.1 www.example.com" | sudo tee -a /etc/hosts

配置应用程序的端口转发，以便你可以在本地通过域名访问示例应用：

export ENVOY_SERVICE=$(kubectl get svc -n envoy-gateway-system --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg -o jsonpath='{.items[0].metadata.name}')

sudo kubectl -n envoy-gateway-system port-forward service/${ENVOY_SERVICE} 443:443

现在在浏览器中访问 https://www.example.com，跳过证书风险提示，页面将跳转到 Auth0 的登录界面，如下图所示，选择使用 Google 账户登录。

在登录完成后，浏览器将跳转会 https://www.example.com 页面，并展示 HTTP 请求结果，如下面的 JSON 代码所示。

{
  "path": "/",
  "host": "www.example.com",
  "method": "GET",
  "proto": "HTTP/1.1",
  "headers": {
    /*Omit*/
    "Authorization": [
      "Bearer eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIiwiaXNzIjoiaHR0cHM6Ly9kZXYtYXdoam15MzhnZzVxeng3dS51cy5hdXRoMC5jb20vIn0..IiH9LnxmnrGAVy-q.eQV_0Ssetw9mmrEaJNLlBowGJNX51awhh67WSejPrksuGU9e9-DcPJQqmR67ONFzTXWR6CFy4Rfgs4btsmEtvCtiNTCgrBHP90ddbOTg_pK31WnsQ7NThyRfGwoogSaAtK6hFrC2pxFaLj0XL7XvSPk-OaTzK1Zh1da1IM1cmWAWiBRc3nQiVWRDrExPo8-i5SawFe0jIcwytVSaRiX5Polyd3cZ7A7nlei-vDLCfj0HVzOO605nF7ED2dBSnZyev1sg14q598f3X2Vfhi2oJlnbiulGZIlpXgGbcPhzAJJxyEe6qpRpNg7Hbk8Ya-i8gUTwwNysrgm3.Zu5kD_6DzSfZPvwemttXYQ"
    ],
    "Cookie": [
      "OauthHMAC-167a6c5=RPdscXEBap0NeSIppJXoxkHt0qvMz4fNHXo2uvgDgIY=; OauthExpires-167a6c5=1716540771; BearerToken-167a6c5=eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIiwiaXNzIjoiaHR0cHM6Ly9kZXYtYXdoam15MzhnZzVxeng3dS51cy5hdXRoMC5jb20vIn0..IiH9LnxmnrGAVy-q.eQV_0Ssetw9mmrEaJNLlBowGJNX51awhh67WSejPrksuGU9e9-DcPJQqmR67ONFzTXWR6CFy4Rfgs4btsmEtvCtiNTCgrBHP90ddbOTg_pK31WnsQ7NThyRfGwoogSaAtK6hFrC2pxFaLj0XL7XvSPk-OaTzK1Zh1da1IM1cmWAWiBRc3nQiVWRDrExPo8-i5SawFe0jIcwytVSaRiX5Polyd3cZ7A7nlei-vDLCfj0HVzOO605nF7ED2dBSnZyev1sg14q598f3X2Vfhi2oJlnbiulGZIlpXgGbcPhzAJJxyEe6qpRpNg7Hbk8Ya-i8gUTwwNysrgm3.Zu5kD_6DzSfZPvwemttXYQ; IdToken-167a6c5=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImFKWkxWbnNrai0tYmhsNlJzVm51OCJ9.eyJpc3MiOiJodHRwczovL2Rldi1hd2hqbXkzOGdnNXF6eDd1LnVzLmF1dGgwLmNvbS8iLCJhdWQiOiJUZzhlNWVoa0xKM2hka3cxTzREMTBQd21QeTcxZHZtdiIsImlhdCI6MTcxNjQ1NDM3MSwiZXhwIjoxNzE2NDkwMzcxLCJzdWIiOiJnb29nbGUtb2F1dGgyfDExMjc0NDc3OTAyMjMzMTA0ODY0MCIsInNpZCI6IjRlSjhDZnZuZjd5Mm1kaE94QXBTY0JiUEhjOS1rZUVLIn0.r9dwIy_HeiO5_I3UlohLkeRES5FGoxqQnwmcA00cA_kdc5mUxgeVopXIhBUjJnTKv7bOUVJvFw21ew4gqVRJfllDyG-s_XfhSW1-lEXmCc2bGYDtOzva6k2S_VRgyMKfG04_DWFuTgO_pLtix28aYq8cGzKJ_VglT_KgRhoktzJu4Js5iCv9JPnydRJmpvRJwX3tDv_Q3mmUSazaLkhOTdiBJFrGlS07qEzJ_iWANZgR8uDNhpXdmlcqpb3MZkkMulr5-jXIgEhBQKpw28tUiSlzh6EpAVuBH9T1w8bUmFRzCc6JPPamJRfflYW5onNgYHDfcU0RpvpsCHRHRAZbdA"
    ],
    /*Omit*/
    "User-Agent": [
      "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36"
    ],
    "X-Envoy-Internal": [
      "true"
    ],
    "X-Forwarded-For": [
      "10.244.0.51"
    ],
    "X-Forwarded-Proto": [
      "https"
    ],
    "X-Request-Id": [
      "c1e64057-c5c8-4fb2-a304-25c291eeed32"
    ]
  },
  "namespace": "default",
  "ingress": "",
  "service": "",
  "pod": "backend-55d64d8794-4qvgd"
}

此时通过 Chrome 浏览器的 Inspector - Application - Cookies 查看到 ID Token 如下图所示：

编写代码 Python 代码，validate_id_token.py，解析 ID Token 并验证其有效性：

import jwt
import requests
from jwt.algorithms import RSAAlgorithm
import argparse
import json
import base64

def base64url_decode(input):
    rem = len(input) % 4
    if rem > 0:
        input += '=' * (4 - rem)
    return base64.urlsafe_b64decode(input)

def get_signing_key(jwk_url, kid):
    jwks = requests.get(jwk_url).json()
    for jwk in jwks['keys']:
        if jwk['kid'] == kid:
            return RSAAlgorithm.from_jwk(jwk)
    raise Exception('Public key not found.')

def validate_token(token, audience, issuer, jwk_url):
    headers = jwt.get_unverified_header(token)
    kid = headers['kid']
    signing_key = get_signing_key(jwk_url, kid)

    decoded_token = jwt.decode(
        token,
        signing_key,
        algorithms=["RS256"],
        audience=audience,
        issuer=issuer
    )
    return decoded_token

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description='Validate a JWT token.')
    parser.add_argument('token', type=str, help='The JWT token to validate')
    args = parser.parse_args()

    token = args.token

    # 解析 token 的 payload 部分，提取 audience 和 issuer
    header, payload, signature = token.split('.')
    decoded_payload = base64url_decode(payload)
    payload_json = json.loads(decoded_payload)

    audience = payload_json['aud']
    issuer = payload_json['iss']
    jwk_url = f"{issuer}.well-known/jwks.json"

    try:
        decoded = validate_token(token, audience, issuer, jwk_url)
        print("Token is valid. Decoded payload:")
        for key, value in decoded.items():
            print(f"{key}: {value}")
    except Exception as e:
        print(f"Token validation failed: {e}")

安装依赖的包：

pip install pyjwt requests

运行代码：

python validate_id_token.py ${ID_TOKEN}

你将看到类似下面的输出：

Token is valid. Decoded payload:
iss: https://dev-awhjmy38gg5qzx7u.us.auth0.com/
aud: Tg8e5ehkLJ3hdkw1O4D10PwmPy71dvmv
iat: 1716470905
exp: 1716506905
sub: google-oauth2|112744779022331048640
sid: 4W_hQNJJ8ftDL8S3Cozp8GEu2Au4_e9N

通过该 ID Token 的值可以得出：

• 该令牌由 Auth0 签发（iss 字段）。
• 该令牌的受众是特定的应用或 API（aud 字段），对于 Auth0，这个值是 Client ID。
• 令牌是在 2024 年 5 月 23 日 04:08:25 UTC 签发的（iat 字段），并将在 2024 年 5 月 23 日 14:08:25 UTC 过期（exp 字段）。
• 令牌所代表的主体（用户）的唯一标识符是 google-oauth2|112744779022331048640（sub 字段）。在这里，这个标识符表明使用 Google OAuth2 登录的用户
• 会话 ID 是 4W_hQNJJ8ftDL8S3Cozp8GEu2Au4_e9N（sid 字段），用于会话管理。

验证单点登录：登出

由于我们的示例应用中没有实现 Auth0 的 Logout 逻辑，所以我们需要通过 HTTP 请求明确告知 Auth0 要 logout，在浏览器中访问该 URL：

https://${DOMAIN}/v2/logout?client_id=${CLIENT_ID}

请将 ${DOMAIN} 和 ${CLIENT_ID 修改为你的 Auth0 应用程序的配置项。关于 Auth0 如何登出 OIDC 端点的详细说明请查看 Auth0 文档。

登出后，页面将再次跳转到登录页面，在登录后，页面将重定向到 https://www.example.com。

总结

通过以上步骤，你可以在 Envoy Gateway 中实现 OIDC 认证，确保 API 的安全性。这种方法不仅能提供灵活的身份验证机制，还能简化应用程序的身份管理。通过集成 Auth0 等身份提供商，Envoy Gateway 可以轻松实现单点登录，提升用户体验和系统安全性。未来，你可以根据需求进一步配置和优化 Envoy Gateway，充分利用其强大的认证和授权功能，以满足更复杂的安全要求和业务需求。

参考

• Envoy Gateway OIDC Authentication - gateway.envoyproxy.io
• Log Users Out of Auth0 with OIDC Endpoint - auth0.com

2024-05-22 13:54:49

在现代微服务架构中，安全性是一个至关重要的方面。随着微服务数量的增加，如何确保服务间的安全通信成为了一个挑战。本文将介绍几种常见的微服务认证方式，帮助你在设计和实现微服务系统时选择合适的认证方案。

微服务中常用的认证方式

下表列出了几种微服务中常用的认证方式，并从优点、缺点、适用场景和现实示例等维度进行比较。

下面我们将详细介绍这几种常见的认证方式。

JWT 认证

JWT（JSON Web Token）最早由 IETF JSON Web Token (JWT) 工作组提出，并在 2015 年作为 RFC 7519 标准正式发布。JWT 的设计目标是提供一种紧凑且自包含的方式，用于在各方之间安全地传递信息。由于其易于使用和无状态的特性，JWT 迅速被广泛采用，成为身份验证和信息交换的标准之一，特别是在微服务和现代 Web 应用中。

下图展示的是 JWT 认证流程。

JWT 认证流程说明：

1. 用户提供凭证
2. 客户端请求访问令牌
3. 认证服务器返回 JWT 令牌
4. 客户端带 JWT 令牌请求资源服务器
5. 资源服务器验证 JWT

JWT 的格式说明及示例

JWT（JSON Web Token）由三个部分组成：头部（Header）、载荷（Payload）和签名（Signature），分别通过 Base64 编码后用点（.）连接在一起组成。

1. 头部（Header）：头部包含令牌类型和签名算法。

   {
     "alg": "HS256",
     "typ": "JWT"
   }
   

2. 载荷（Payload）：载荷包含声明（claims），即关于用户或其他数据的断言。

   {
     "sub": "1234567890",
     "name": "John Doe",
     "iat": 1516239022
   }
   

3. 签名（Signature）：签名由编码后的头部、编码后的载荷以及一个密钥通过头部中指定的算法生成。

   HMACSHA256(
     base64UrlEncode(header) + "." +
     base64UrlEncode(payload),
     secret
   )
   

下面是一个 JWT 令牌示例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

OAuth 2.0

OAuth（Open Authorization）协议最早由 Blaine Cook 和 Chris Messina 在 2006 年提出。最初的目标是为 Twitter 提供一个开放的授权标准。OAuth 1.0 于 2007 年发布，提供了一个允许用户授权第三方应用访问其资源的标准化方式，但由于其复杂的签名机制和其他安全问题，受到了一些限制。

为了克服这些缺点，IETF（Internet Engineering Task Force）成立了 OAuth 工作组，旨在开发一个更简化、更灵活的授权协议。2012 年，OAuth 2.0 正式发布（RFC 6749 和 RFC 6750）。OAuth 2.0 简化了授权流程，增加了多种授权模式，如授权码模式、简化模式、资源所有者密码凭证模式和客户端凭证模式。

OAuth 2.0 迅速成为行业标准，广泛应用于各种网络服务和应用程序，如 Google、Facebook、GitHub 等。在此基础上，出现了多个扩展和补充协议（如 OpenID Connect），进一步增强了 OAuth 2.0 的功能和安全性。

OAuth 2.0 的发展和扩展使其成为现代互联网身份验证和授权的重要基石，提供了灵活和安全的解决方案，满足了不断变化的网络应用需求。

下图展示的是 OAuth 2.0 认证流程。

OAuth 2.0 认证流程说明：

1. 用户请求访问资源
2. 客户端请求认证
3. 用户登录并授权
4. 认证服务器返回授权码
5. 客户端交换授权码获取访问令牌
6. 客户端带访问令牌请求资源服务器

OAuth 2.0 授权码

在 OAuth 2.0 授权码模式中，授权码是客户端在用户授权后从授权服务器获取的短期凭证，用于交换访问令牌。授权码是一个临时的字符串，可以在授权服务器和客户端之间传递以获得更安全的访问令牌。

OAuth 2.0 扩展

OAuth 2.0 在发展过程中，为了适应不同的场景，发展出了众多的扩展，下表罗列出一些常用的扩展名称、主要功能及适用场景。

OAuth 2.0 授权流程（以 Github 为例）

GitHub 使用 OAuth 2.0 来授权第三方应用访问用户的 GitHub 数据。OAuth 2.0 令牌在 GitHub 上被称为 “access tokens”，用于验证和授权访问 GitHub API。它提供了一种安全、标准化的方法，允许第三方应用在用户授权的情况下访问 GitHub 资源。通过使用访问令牌，应用程序可以代表用户执行各种操作，如读取用户信息、访问仓库、创建 gists 等。这个过程确保了用户的安全和隐私，同时简化了应用程序的认证和授权流程。

以下是使用 GitHub OAuth 2.0 令牌的详细流程和示例：

1. 用户授权：用户在第三方应用程序的界面上点击“Login with GitHub”按钮。应用程序将用户重定向到 GitHub 的授权页面。

2. 获取授权码：用户在 GitHub 授权页面上登录并同意授权，GitHub 会将用户重定向回应用程序，并在 URL 参数中附带一个授权码（authorization code）。

   示例：

   https://yourapp.com/callback?code=AUTHORIZATION_CODE
   

3. 交换访问令牌：应用程序服务器使用授权码向 GitHub 的授权服务器请求访问令牌。

   请求示例：

   POST https://github.com/login/oauth/access_token
   Content-Type: application/json
   Accept: application/json
   
   {
     "client_id": "YOUR_CLIENT_ID",
     "client_secret": "YOUR_CLIENT_SECRET",
     "code": "AUTHORIZATION_CODE",
     "redirect_uri": "https://yourapp.com/callback"
   }
   

4. GitHub 返回访问令牌：GitHub 验证请求并返回访问令牌。

   响应示例：

   {
     "access_token": "YOUR_ACCESS_TOKEN",
     "token_type": "bearer",
     "scope": "repo,gist"
   }
   

5. 使用访问令牌访问资源：应用程序使用获取的访问令牌访问 GitHub API。

   请求示例：

   curl -H "Authorization: token YOUR_ACCESS_TOKEN" https://api.github.com/user
   

   响应示例：

   {
     "login": "github-user",
     "id": 1,
     "node_id": "MDQ6VXNlcjE=",
     "avatar_url": "https://github.com/images/avatar.jpg",
     "name": "Github User",
     "company": "GitHub",
     "blog": "https://example.com",
     "location": "Earth",
     "email": "[email protected]"
   }
   

访问令牌的特点和使用

1. 权限范围（Scopes）：访问令牌的权限范围由用户在授权时指定，可以包括读取用户资料、访问用户仓库、管理 gists 等。例如，在上述示例中，scope 包含 repo 和 gist。

2. 有效期和刷新：访问令牌的有效期可以是长期的也可以设置时间范围，直到用户主动撤销。

3. 安全传输：访问令牌应通过 HTTPS 传输，以确保其不被截获。

mTLS

mTLS（Mutual TLS）是一种在客户端和服务器之间进行双向身份验证的技术，最早起源于 TLS（传输层安全协议），TLS 的前身 SSL（安全套接层）协议于 1995 年由 Netscape 开发。随着互联网安全需求的增加，TLS 逐步发展为一个高度安全的通信标准，而 mTLS 则在此基础上进一步提升了安全性，通过要求双方互相验证身份，广泛应用于金融、医疗等对安全性要求极高的领域。

下图展示的是 mTLS 认证流程。

mTLS 认证流程说明：

1. 客户端与服务器互相发送证书
2. 双方验证对方证书
3. 建立安全连接

更多关于 TLS 和 mTLS 的内容请参考博客 如何理解 Istio 中的 mTLS 流量加密。

Basic 认证

Basic 认证是一种最早由 HTTP/1.0 规范（RFC 1945）定义的简单认证机制，它通过将用户名和密码进行 Base64 编码后附加到 HTTP 请求头中进行身份验证。由于实现简单且易于使用，Basic 认证在早期的 Web 应用中被广泛采用。然而，由于其固有的安全性问题（如明文传输容易被截获），它在现代应用中通常与 HTTPS 一起使用，或被更安全的认证方式所替代。

下图展示的是 Basic 认证流程。

Basic 认证流程说明：

1. 用户提供用户名和密码
2. 客户端带用户名和密码请求资源服务器
3. 资源服务器验证

Basic 示例

Basic 认证使用 Base64 编码的用户名和密码进行认证。下面是使用 curl 命令进行 Basic 认证请求的示例：

curl -u <username>:<password> https://api.example.com/data

如果用户名为 admin，密码为 password123，请求示例如下：

curl -u admin:password123 https://api.example.com/data

API Key 认证

API Key 认证是一种通过在请求中包含预先分配的唯一密钥来进行身份验证的方法，最早在 2000 年代初随着 Web API 的兴起而流行。API Key 认证由于其简单易用和便于管理的特性，被广泛应用于各种公共和私有 API 中。尽管它的安全性较低，容易被滥用，但在许多场景中仍然是控制访问的一种有效手段，特别是对于不需要高度安全保护的应用。

下图展示的是 API Key 认证流程。

API Key 认证流程说明：

1. 客户端带 API Key 请求资源服务器
2. 资源服务器验证 API Key

API Key 示例

API Key 是在请求中传递的一个唯一标识符，用于验证客户端身份。API Key 通常通过 HTTP 请求头或 URL 参数传递。

HTTP 请求头中的 API Key 示例：

curl -H "Authorization: ApiKey YOUR_API_KEY" https://api.example.com/data

URL 参数中的 API Key 示例：

curl https://api.example.com/data?api_key=YOUR_API_KEY

API Key 格式通常是一个字符串，包含字母和数字，例如：

1234567890abcdef1234567890abcdef

总结

在微服务架构中选择合适的认证方式至关重要。不同的认证方式在安全性、复杂性和适用场景上各有优劣。本文介绍了 JWT、OAuth 2.0、mTLS、Basic 认证和 API Key 认证五种常见的认证方式，并提供了它们的优缺点和适用场景。此外，其他常见的认证方式如 SAML、LDAP、Kerberos 和 OpenID Connect 也广泛应用于不同的互联网应用场景，特别是在单点登录和跨域认证方面。希望这些信息能帮助你在设计和实现微服务系统时选择最合适的认证方案。

2024-05-16 11:28:34

Istio 1.22 版本的发布标志着 Ambient 模式正式进入 beta 阶段，随之发布了一篇标题为 告别 Sidecar：Istio 的 Ambient 模式在 v1.22 中达到 Beta 的博客，声称 Layer 4 和 Layer 7 的功能现已可用于生产环境。其实社区早在一个月前的 KubeCon EU 上就宣布了这一里程碑。这种激动人心的宣传似乎在暗示我们可以彻底抛弃 Sidecar 模式，但事实真是如此吗？

为什么不急于告别 Sidecar 模式？

虽然我对新技术持开放态度，但完全告别 Sidecar 模式可能为时尚早。每种模式都有其特定的应用场景和优缺点。下面，我将详细分享 Ambient 模式相较于 Sidecar 模式的一些限制，帮助大家更好地理解两者之间的差异。

Ambient 模式与 Sidecar 模式的关键区别

流量管理

Ambient 模式的 L7 流量管理支持尚未成熟，尚未达到生产环境的可用水平。相较之下，Sidecar 模式在这方面更为稳定和可靠。

安全性

在 Ambient 模式下，mTLS 被强制在 namespace 级别开启，而 Sidecar 模式则赋予用户更大的灵活性，可以选择是否启用 mTLS。这种灵活性对于某些应用场景尤为重要。

可观测性

对于 L7 层的遥测数据，Ambient 模式能否像 Sidecar 模式一样对每个 pod 进行精确的监控和追踪仍是一个疑问。Sidecar 模式在可观测性方面已被广泛验证，其能力更为成熟。

运维

部署方面，Ambient 模式推荐使用 Helm，仅支持 Kubernetes 平台，而 Sidecar 模式还支持虚拟机和混合云环境。此外，Ambient 模式尚未得到主要云厂商的官方支持。在升级过程中，Ambient 模式的爆炸半径更大，暂不支持金丝雀发布，推荐使用蓝绿部署。对于从 Sidecar 模式向 Ambient 模式的迁移或二者共存，仍缺乏最佳实践。

扩展性

目前对于 Wasm 插件的支持，Ambient 模式仍不明确，而 Sidecar 模式在这方面已经有了较为完善的支持。

其他功能特性

Dual Stack 模式在 Sidecar 模式下虽然仍处于实验阶段，但至少已有一定的实现，而 Ambient 模式是否支持这一特性仍不明朗。

总结

虽然 Istio 1.22 带来了令人兴奋的 Ambient 模式，但在完全告别 Sidecar 模式之前，我们需要慎重考虑这些限制和差异。每种模式都有其独特的优势和适用场景，用户应根据自身需求做出明智的选择。我将继续对 Ambient 模式进行测试和追踪，更多深入解读敬请关注本博客。

2024-05-08 11:20:49

在 Kubernetes 环境下选择正确的网络通信工具至关重要。根据Tetrate 的讨论，选择取决于网络通信的类型：南北向流量还是东西向流量。对于主要处理外部请求的服务，Envoy Gateway 是理想选择，它不仅高效管理流量，还能在你向微服务架构过渡时提供无缝集成。

本文将探讨 Envoy Gateway 在 Kubernetes 上部署的优势，及其它与服务网格的关系，展示为何它是暴露服务到公网的理想选择。

Envoy Gateway 及其在服务网格中的角色概述

Envoy Gateway 是一个围绕 Envoy Proxy 构建的 Kubernetes 原生 API 网关，它旨在降低用户采用 Envoy 作为 API 网关的难度，并为供应商建立 API 网关（例如 Tetrate Enterprise Gateway for Envoy）增值产品奠定基础。

Envoy Gateway 不仅是管理南北流量的理想选择，也可作为连接和保护服务网格中服务的关键组件。它还通过提供安全的数据传输、流量路由、负均衡及故障恢复等功能，增强了微服务之间的通信效率和安全性。Envoy Gateway 利用其内置的 Envoy Proxy 技术，可以处理大量的并发连接和复杂的流量管理策略，同时保持较低的延迟和高吞吐量。

此外，Envoy Gateway 与 Kubernetes Gateway API 的紧密集成使得它能够以声明式的方式进行配置和管理，极大简化了服务网格中网关的部署和更新过程。这种集成不仅提升了操作效率，还使得 Envoy Gateway 能够在不增加额外复杂性的前提下，与服务网格如 Istio 这样的解决方案无缝协作。

下图展示了 Envoy Gateway 与服务网格的关系。

在 Kubernetes 集群中，Envoy Gateway 负责管理南北向流量，即进出集群的流量，并通过 Kubernetes Gateway API 进行配置，后者定义了服务的路由规格。集群内服务直接连接到 Pods。服务网格部分，由控制平面（如 Istio 或 Linkerd）配置数据平面中的 Envoy Sidecars，这些 Sidecars 负责处理集群内部的东西向流量。在这个系统中，Envoy Gateway 可以与服务网格相互协作，但它们各自独立地管理不同方向的流量。

设想一下，Envoy Gateway 像是一个城市的主要入口（比如海关），所有的数据流，就像各种车辆，都得通过这个大门进出。它就像一个严格的守门员，负责审查、指导，确保每个数据包，就像每个乘客，都能被准确地送到目的地。在 Kubernetes 这座城市中，Envoy Gateway 管理着所有进城的流量，它确保数据流可以安全、高效地进入城市，并被准确地送达给城市内部的服务。

进入城市之后，服务网格就接管了，这就像城市内部的一系列交通网络。服务网格中的 Envoy sidecars 就好比是这座城市内部的出租车或者公交车，负责把数据包从海带到它们在城市内部的具体目的地。Envoy Gateway 负责将外部请求顺利引入，之后服务网格负责在集群内部继续高效地处理这些请求。

Envoy Gateway 对 Kubernetes Gateway API 的支持，可以看作是对我们城市交通信号系统的一个重大升级。这不仅为进入城市的数据流提供了更加清晰和个性化的指引，而且让整个城市的交通运行更加智能化。

Envoy Gateway 的核心功能和优势

Envoy Gateway 提供了几个核心功能，使其成为 API 网关的突出选择：

• 简化配置：通过与 Kubernetes Gateway API 直接集成，Envoy Gateway 允许开发者使用 Kubernetes 自定义资源以声明方式配置路由规则、安全策略和流量管理。
• 性能和可扩展性：基于经过实战测试的 Envoy Proxy，它提供卓越的性能和可扩展性，轻松处理数千个服务和每秒数百万个请求。
• 安全功能：内置支持各种安全措施，如 SSL/TLS 终止、OAuth2、OIDC 认证以及细粒度访问控制。
• 可观测性：提供全面的监控能力，包括详细的度量、日志和追踪，这对于诊断和理解流量行为至关重要。

与 Gateway API 的关系

在 Kubernetes 环境中引入的 Gateway API 为集成和配置 Ingress 网关提供了一种新的强大方法，它与传统的 Ingress 相比具有更高的灵活性和功能性。正如我在 Gateway API：Kubernetes 和服务网格入口中网关的未来 中所讨论的，Gateway API 通过区分角色和提供跨命名空间支持，更适应多云环境，且已被多数 API 网关采用。这种 API 设计支持了 ingress 网关（南北向流量）与服务网格（东西向流量，跨集群路由）的融合，使得 Envoy Gateway 成为 Kubernetes 和服务网格中统一未来的网关解决方案。通过引入 Gateway API，Envoy Gateway 强化了其作为云原生环境中前沿代理的角色，使得用户能够更灵活地管理其流量和策略。

Kubernetes Gateway API 是 Envoy Gateway 的基石，它提供了一种更具表达性、灵活性和以角色为导向的方式来配置 Kubernetes 生态系统中的网关和路由。该 API 提供了如 GatewayClass、Gateway、HTTPRoute 等自定义资源定义（CRD），Envoy Gateway 利用这些资源创建用户友好且一致的配置模型，与 Kubernetes 的原生原则保持一致。

Envoy Gateway 架构概览

Envoy Gateway 的架构设计旨在轻量级和简洁。它包括一个动态配置运行作为数据平面的 Envoy 代理的控制平面。这种关注点的分离确保了网关可以随着流量的增长而扩展，而不影响控制平面的效率。

Envoy Gateway 的架构图如下所示。

在这个架构图的核心是 Envoy Gateway，它是 Envoy 代理的执行实例，负责处理从 Kubernetes 集群进出的所有流量。初始启动时，Envoy Gateway 通过配置文件提供静态配置，建立其操作的基本参数。

Envoy Gateway 配置的动态方面由提供者处理，该提供者定义了网关与 Kubernetes 或其他动态配置输入源的交互。资源监视器负责监视 Kubernetes 资源的更改，特别关注与自定义资源定义（CRD）相关的 CRUD 操作。

随着更改的发生，资源转换器介入将这些外部资源转换为 Envoy Gateway 可以理解的形式。这一转换过程进一步由特定于提供者的基础设施管理器促进，后者负责管理与特定云或基础设施提供商相关的资源，塑造中间表示形式的基础设施，这对于网关的功能至关重要。

然后，该中间表示形式转变为 xDS 中间表示形式，作为 Envoy 理解和执行的最终 xDS 配置的先导。xDS 翻译器承担将这种中间表示形式转换为具体的 xDS 配置的角色。

这些配置由 xDS 服务器交付并执行，该服务器作为服务，根据其收到的 xDS 配置，认真管理 Envoy 实例。Envoy 作为实际运行的代理，最终从 xDS 服务器接收这些配置，解释并实现它们以有效管理流量请求。

最终，所有请求经过 Envoy 的处理后被重定向到了 Envoy Gateway 路由的流量的最终目的地，也就是后端服务。

与其他网关的比较

与 Istio 的入口网关或 NGINX Ingress 等其他流行解决方案相比，Envoy Gateway 凭借其与 Kubernetes 的原生集成以及利用 Envoy 全部潜力的专注，而脱颖而出。下图从多方面对比了目前流行的一些开源的 API 网关。

快速开始使用 Envoy Gateway

要快速上手 Envoy Gateway，你可以通过以下简化步骤快速搭建一个本地实验环境。首先，启动一个本地 Kubernetes 集群：

minikube start --driver=docker --cpus=2 --memory=2g

接下来，部署 Gateway API CRD 和 Envoy Gateway 本身：

helm install eg oci://docker.io/envoyproxy/gateway-helm --version v1.0.1 -n envoy-gateway-system --create-namespace

然后，安装网关配置并部署一个示例应用：

kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v1.0.1/quickstart.yaml -n default

为了暴露 LoadBalancer 服务，这里我们使用端口转发作为示例。你也可以选择使用 minikube tunnel 或安装 MetalLB 作为负载均衡器：

export ENVOY_SERVICE=$(kubectl get svc -n envoy-gateway-system --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg -o jsonpath='{.items[0].metadata.name}')
kubectl -n envoy-gateway-system port-forward service/${ENVOY_SERVICE} 8888:80 &

通过以下命令测试你的 Envoy Gateway 是否正常工作：

curl --verbose --header "Host: www.example.com" http://localhost:8888/get

想了解更多详细的安装和配置步骤，请访问 Envoy Gateway 网站。通过这些步骤，你可以快速开始探索 Envoy Gateway 的功能。

总结

Envoy Gateway 不仅优化了云原生时代的七层网关配置，而且为从边缘网关向服务网格过渡提供了一个平滑的道路。由于服务网格的推广面临一些挑战，如对应用的侵入性和运维团队推动问题，边缘网关则更易于被开发团队接受。Envoy Gateway 采用简化的 Kubernetes Gateway API，提高了流量管理和可观测性的能力。此外，Envoy Gateway 到 Istio 的过渡对于已熟悉 Envoy 功能的团队来说，将是一个自信的技术进步，同时还支持从标准的 Kubernetes Gateway API 到 Istio Ingress Gateway 的无缝切换，或者作为一个定制解决方案继续与 Istio 协作。这些特点使得 Envoy Gateway 成为一个在云原生时代值得投资的网关选择。

请继续关注本系列博客的后续部分，我们将深入探讨如何配置和优化 Envoy Gateway，提供实用指南并展示更广泛的实际应用案例。

2024-05-07 21:11:49

近日 CNCF 发布了 KubeCon EU 2024 的透明度报告，KubeCon + CloudNativeCon Europe 2024 在巴黎举办，这是有史以来最大规模的一次会议，我也有幸能亲临现场参加，巴黎的美景和会议的氛围让我久久难以忘怀。

我们见证了开源和云原生社区的力量，以及它如何推动技术的下一个重大转变 —— 人工智能。在这次会议上，CNCF 宣布成立 AI 工作组，并推出了第一版云原生 AI 白皮书，随后有创建了云原生 AI Landscape。

增长与多样性

本次活动迎来了超过 12,000 名参与者，大部分来自欧洲（78%），其中 52% 为首次参会者。来自不同地区的参与者都表现出了对云原生技术的热情。我们还看到了业务运营、开发者和架构师等多样化的职能背景，这突显了云原生技术跨领域的广泛应用。

下表来自不同国家的参会人数 Top 10：

创新与交流

活动期间，有 331 场会议和 19 场主题演讲，覆盖了人工智能、应用开发、平台工程等多个热门领域。本届 KubeCon 首次举办了面向研究者的海报会话和项目馆导览，帮助参会者更好地了解各个项目。

社区与包容性

KubeCon 致力于支持多样性、公平性和包容性。活动提供的多样性午餐和 Peer Group Mentoring 等活动，为参与者提供了建立联系和互帮互助的平台。（PS. 会场提供的餐饮实在是让我喜欢不了，尤其是茶的味道，还有硬邦邦的面包）

环保与可持续性

在环保和可持续性方面，主办方选择了具有环保意识的会场，并实施了减少食物浪费和回收废物的措施。这体现了 CNCF 对环境保护的承诺。

展望未来

展望未来，我们期待将 KubeCon 的魔力带到全球更多地区。无论是即将到来的 KubeCon + CloudNativeCon China 2024 还是其他地区的活动，我都非常期待与你相见。我也向 KubeCon China 提交了一个 Panel session，如果能够入选，今年 8 月我们将在香港相见。

结论

KubeCon + CloudNativeCon Europe 2024 不仅是技术的盛会，更是社区力量的展示。如你想了解更多细节，请查看我之前关于 KubeCon + CloudNativeCon Europe 的回顾。

我们希望这篇透明性报告能帮助你更好地理解活动的影响力，并激励你参与未来的 KubeCon 活动。

2024-04-29 09:27:49

亲爱的云原生社区的朋友们，我很高兴向大家推荐 Isovalent 最新推出的电子书《Kubernetes 网络和 Cilium 网络工程师指南（英文原版）》。

作为一名资深的云原生倡导者，我深知 Kubernetes 网络对于网络工程师来说是一个巨大的挑战。但是，随着 Kubernetes 在企业中的广泛应用，学习 Kubernetes 网络知识已经变得非常重要和紧迫。这本电子书正是为了帮助网络工程师们克服这些挑战而诞生的。

这本 56 页的电子书由 Isovalent 的 Senior Staff Technical Marketing Engineer Nico Vibert 撰写，内容涵盖了 Kubernetes 网络的方方面面，包括 Cilium 这个事实上的 Kubernetes 网络层。即使你不是网络工程师，相信你也能轻松理解和学习这本书的内容。

这本电子书就像一本使用说明手册，为网络工程师们提供了一个循序渐进的学习路径。从 Kubernetes 网络的基础知识，到 Cilium 的高级功能，再到实际的部署和运维，应有尽有。相信这本书一定会成为网络工程师学习 Kubernetes 网络的必备资料。

根据这本由 Isovalent 推出的电子书《Kubernetes Networking and Cilium: An Instruction Manual for the Network Engineer》的内容，我为大家总结了以下几点。

本书亮点

1. 全面介绍了 Kubernetes 网络的基础知识，包括容器网络接口 (CNI)、网络模型等，为网络工程师打下坚实的基础。
2. 深入探讨了 Cilium 这个事实上的 Kubernetes 网络层，详细讲解了它提供的各种功能，如路由、交换、负载均衡、防火墙、监控等。
3. 系统介绍了如何在 Kubernetes 中配置和管理网络，包括使用 kubectl 命令行工具、应用 YAML 配置文件等。
4. 重点阐述了 Cilium 的身份感知安全机制，以及如何使用网络策略进行精细化的网络访问控制。
5. 讲解了 Kubernetes 中的负载均衡机制，包括 ClusterIP、NodePort 和 Ingress 等服务类型。
6. 探讨了 Kubernetes 集群跨多个集群的联通方案，以及如何实现跨集群的负载均衡和安全策略。

适读人群

这本电子书主要面向 Kubernetes 网络工程师，帮助他们全面掌握 Kubernetes 网络的方方面面知识。即使不是网络工程师，对云原生技术感兴趣的读者也能从中受益，学习 Kubernetes 网络的基础知识。

中文版

如果你想阅读该书的中文版，请访问这里获取。中文版由 Isovalent 的黄力一翻译。

2024-04-17 18:54:49

本文将深入探讨 Istio CNI 插件的设计理念、实现方式以及如何通过 Ambient Mode 来解决传统模式中存在的安全和权限问题。本文内容包括：

• Init 容器的安全风险及其解决方案。
• Istio CNI 的工作原理及其优势。
• Ambient Mode 的实现机制及其与 CNI 的集成。

Istio 网络要求与解决方案概览

Istio 服务网格通过 Sidecar 模式实现应用流量的拦截和管理。该模式通过在应用程序 Pod 中注入 Sidecar Proxy 和 init 容器，并使用 iptables 规则来管理网络流量。详细的部署和操作过程请参见 Istio 中的 Sidecar 注入、透明流量劫持及流量路由过程详解。虽然此方法在多数 Kubernetes 平台上有效，但对高权限的依赖在多租户环境中引发了安全方面的担忧。

Istio-init 的局限性

Istio 在其网络配置初期采用了 istio-init 容器来初始化流量拦截规则，这需要容器具有高级权限来修改网络配置，如 IPTables 规则。虽然这种方法实现了对流量的有效管理，但它也显著提高了权限需求并增加了安全风险。根据 Istio 官方文档，istio-init 容器默认被注入到 Istio 网格中的 Pod 里，以便将网络流量劫持到 Istio 的 Sidecar 代理。这一过程需要对部署 Pod 的 Service Account 赋予 NET_ADMIN 容器权限，可能与某些组织的安全政策相悖。

Istio CNI 插件

为响应这一挑战，Istio 社区推出了 Istio CNI 插件，该插件避免了对 init 容器的需求，允许直接在 Kubernetes 的网络层面操作，从而降低权限需求并简化部署流程，但是存在 CNI 兼容性问题。

Ambient 模式的引入

Istio 的 Ambient Mode 是一种创新的无 sidecar 方案，它通过 使用 Geneve 隧道 或 Istio CNI 提高网络的灵活性和安全性。

直到最近 Istio 社区才推出适配任意 CNI 的通用的解决方案。此模式解决了与任意 CNI 的兼容性问题，使 Istio 能够在不影响现有网络策略的前提下，更有效地管理服务间的流量。

NET_ADMIN 权限的安全考虑

在 Kubernetes 和 Docker 等容器化环境中，NET_ADMIN 权限允许容器内的进程执行广泛的网络相关操作。这包括修改 iptables 规则、更改网络接口配置、管理 IP 路由表，以及控制网络相关的内核参数。然而，这种权限的使用引发了安全上的考虑，特别是在权限过度和潜在的攻击面方面。

最佳实践包括：

• 限制使用范围：只在必要时授予 NET_ADMIN 权限，并通过 Kubernetes 网络策略加以限制。
• 持续监控与审计：对使用 NET_ADMIN 权限的容器进行严格的日志记录和监控。

Istio CNI 插件的工作原理

Istio CNI 插件是一个二进制文件，作为代理安装在每个节点的文件系统中。以下流程图说明了 Istio CNI 节点代理的工作原理：

• Istio CNI Node Agent 充当安装在每个节点上的代理。
• 安装 Istio CNI 插件并更新节点的 CNI 配置。
• 代理监控 CNI 插件和配置路径的更改。
• 在 Sidecar 模式下，它使用 pod 的 iptables 处理 sidecar 网络设置。
• 在 Ambient 模式下，它将 pod 事件同步到环境监控服务器，然后该服务器在 pod 内配置 iptables。
• 节点需要提升权限，例如 CAP_SYS_ADMIN 、 CAP_NET_ADMIN 和 CAP_NET_RAW 才能在任一模式下运行。

解析 Istio Ambient Mode 与 Kubernetes CNI 的冲突

Istio 的 Ambient Mode 是为了适配所有 CNI 而设计的一种模式，它通过 ztunnel 来透明地处理 Pod 内的流量转发，而不影响现有的 CNI 配置。这种模式下，Ambient Mode 通过 ztunnel 管理流量，使其流经 Istio 服务网格，而标准的 CNI 则侧重于为 Pod 提供标准化的网络接入。

CNI 的主要职责是解决 Kubernetes Pod 之间的网络连通性，例如分配 IP 地址和转发数据包。相比之下，Ambient Mode 需要将流量导入 ztunnel，这与 CNI 的网络配置可能存在不兼容，主要问题包括：

• 主流 CNI 的网络配置可能会与 Istio 的 CNI 扩展冲突，导致流量处理中断。
• 如果部署的网络策略依赖于 CNI，那么使用 Istio CNI 时可能会影响这些策略的执行。

为解决这些问题，可以通过将 ztunnel 运行在与 Pod 相同的用户空间中，避免与 CNI 修改过的内核空间的冲突。这样，Pod 可以直接连接到 ztunnel，绕过 CNI 的影响。

下面的时序图描述了 Ambient mode 下的流程：