本文翻译自 Mathew Duggan 的文章 K8s Service Meshes: The Bill Comes Due。本文既包含作者的个人观点，也涵盖了客观事实的描述。大家保持批判性思维，审慎阅读。 文章讨论了 Kubernetes（K8s）服务网格技术的最新发展，重点分析了四种主要的服务网格解决方案：Linkerd、Cilium、Istio 和 Consul Connect，以及云提供商服务网格的概况。每种技术都有其独特之处，包括架构设计、易用性、功能以及与 Kubernetes 的集成方式。 此外，文章还探讨了这些技术的定价模型，指出免费服务网格时代的结束，以及企业在选择服务网格解决方案时需要考虑的成本因素。随着服务网格技术的发展，企业需要仔细评估各种选项，以找到最适合其特定需求和预算的解决方案。 以下是原文的翻译。 当你开始使用 Kubernetes 时，你将获得的第一个建议之一是安装服务网格。当然，这是在你需要安装的其他 900 项事务之上。对于那些不知情的人来说，当你开始使用时，k8s 中的一切默认对其他所有事物开放，并且服务之间的流量不进行加密。由于服务间流量加密和控制哪些服务可以与哪些服务通信需要类似 JWT 和客户端证书的东西，即使这越来越成为任何技术栈的要求，团队通常也不热衷于承担这项工作。

在云原生技术的不断发展和演进中，云原生社区一直致力于推动各种创新和最佳实践的交流与分享。继 Kubernetes、Istio、Envoy、可观测性等特别兴..趣小组（SIG）之后，社区再次迎来新的里程碑——Kubernetes Gateway API SIG（下文简称 Gateway API SIG）的成立。 Gateway API SIG 成立的意义 Gateway API SIG 的成立标志着云原生社区在网络层面的进一步深化和专业化。Kubernetes Gateway API 作为 Kubernetes 网络层的一个重要组成部分，其重要性日益凸显。这个新成立的 SIG 旨在聚集对 Kubernetes 网络、特别是 Gateway API 感兴趣的开发者和专家，共同推动该领域的技术进步和生态建设。 在这次成立的 Gateway API SIG 中，我们特别联合了国内众多知名的 Gateway API 实现项目的维护者和贡献者，包括 BIG-IP Kubernetes Gateway、Easegress、Envoy Gateway、NGINX Gateway Fabric、Flomesh Service Mesh、Higress、Istio、Kong KIC 等。通过 Gateway API SIG，这些行业领先者将能够更深入地与国内开发者进行交流和合作，共同推动 Gateway API 技术的发展和应用。 Gateway API SIG 的核心任务 Gateway API SIG 将专注于以下几个核心任务：

随着云计算的兴起，企业的网络基础设施迅速发展和演变。无论是公有云、私有云还是边缘计算，都为企业带来了前所未有的机会和挑战。流量管理技术，如 CDN、隧道、WAF 等，也不断适应新的需求和环境。 背景 怎么会有这么多的流量管理设施？ 云计算推动网络变革 公有云，如 AWS、Google Cloud、阿里云、华为云、腾讯云等，为企业提供了可扩展的、按需付费的计算资源。相比于传统的数据中心，公有云为企业节省了大量的前期投入，同时提供了高度的弹性和可扩展性。这些头部云供应商在运营商之外，部署了高质量的跨地域网络。同时推动数据中心内部网络的高带宽、软件化。 私有云则是为企业提供了定制化的解决方案，将云的优势结合到企业的私有环境中。这允许企业对数据和应用有更多的控制，同时仍然享受云计算的好处。以 VMWare、OpenStack、Kubernetes 为主要驱动力，推动了自有数据中心里私有云网络的进化。

KCD DaLian was held successfully on April 15th. It was a whole day conference with 2 tracks, Kubernetes multi-cluster, and software supply chain security, 20 topics, 22 lecturers from DaLian, Shanghai, Beijing, and Shenzhen in China, as well as more than 220 participants attending the conference. Beautiful city, impressive conference Dalian is a coastal city in the northeast of China, it is not only famous for its delicious seafood, and comfortable living environment, but also for the IT high-tech industry. A lot of top foreign companies have sites in DaLian, such as IBM, Oracle, SAP, Rakuten, etc. IT developers have exceeded 2.5 million. However, Dalian never held such big Cloud Native events before. Meetup (a half day, 4-5 topics) was organized by China Cloud Native Community in 2020,2021 and 2022. So organizing such big events is a huge challenge for organizers, Kevin,Addo and Mike. A lot of things needed to be done, such as looking for sponsors, CFP, hotel reservations, participants check-in, and so on. Fortunately, all the problems were solved because of our great sponsors, and excellent volunteers: Sponsors - flomesh,Jfrog, Rakuten

丹尼尔·E·艾森布德，程逸，卡洛·孔塔瓦利，科迪·史密斯， 罗曼·科诺诺夫，埃里克·曼 - 希尔舍，阿尔达斯·奇林吉罗格鲁，本·切尼， 尚文涛†* 和吉纳·迪伦·侯赛因‡* 谷歌公司 †加利福尼亚大学洛杉矶分校 ‡ SpaceX maglev-nsdi@google.com

Katran 创造了一种基于软件的负载均衡解决方案，它重新设计了数据转发平面，利用了最近内核工程中的创新。 全球数十亿人使用 Facebook 的服务，我们的基础设施工程师创造了一系列系统，优化了网络流量，为每个人提供了快速可靠的访问方式。今天，我们开源了这项工作的一部分，发布了 Katran 转发平面软件库，该库驱动 Facebook 基础设施中使用的网络负载均衡器。Katran 提供了一种基于软件的负载均衡解决方案，完全重新设计了转发平面，充分利用了最近内核工程中的两项创新：快速数据路径（XDP）和 eBPF 虚拟机。Katran 目前在 Facebook 的服务点（PoPs）的后端服务器上部署，它帮助我们提高了网络负载均衡的性能和可扩展性，减少了如在没有传入包时的繁忙循环等效率低下的问题。我们将其分享给开源社区，希望其他人可以提高他们负载均衡器的性能，并把 Katran 作为未来工作的基础。 在 Facebook 规模上处理请求的挑战 为了管理 Facebook 规模的流量，我们部署了一个分布全球的服务点网络，作为我们数据中心的代理。鉴于请求量极高，服务点和数据中心都面临着如何让大量的（后端）服务器对外界呈现为一个单一虚拟单元，以及如何在这些后端服务器之间有效分配工作负载的挑战。 这些挑战通常是通过在每个位置公布一个虚拟 IP 地址（VIP）来解决的。然后，目标为 VIP 的数据包被无缝地分发到后端服务器中。然而，分发算法需要考虑到后端服务器通常在应用层操作并终止 TCP 连接的事实。这个任务由网络负载均衡器（通常被称为 4 层负载均衡器或 L4LB，因为它操作数据包而不是处理应用级请求）来处理。图 1 说明了 L4LB 与其他网络组件的关系。 图 1: 网络负载均衡器在多个后端服务器前面，后端服务器运行后端应用，将每个客户端连接的所有数据包一致性地发送到一个特定的后端服务器。

本文详细介绍了 BeyondCorp 前端基础架构的实现。重点介绍了访问代理（Access Proxy），我们在其实施过程中遇到的挑战以及在设计和推出过程中所学到的经验教训。我们还涉及了一些当前正在进行的项目，以提升员工访问内部应用程序的整体用户体验。 在迁移到 BeyondCorp 模型时（前文已讨论过的“BeyondCorp：企业安全的新方法”[^1] 和“BeyondCorp：Google 的设计与部署”[^2]），Google 需要解决许多问题。如何在所有仅限内部的服务中执行公司策略成为一个显著的挑战。传统的方法可能会将每个后端与设备信任推断器集成，以评估适用的策略；然而，这种方法会显著减慢我们能够推出和更改产品的速度。 为了应对这个挑战，Google 实施了一个集中的策略执行前端访问代理（Access Proxy，AP）来处理粗粒度的公司策略。我们实现的 AP 足够通用，可以使用相同的 AP 代码库来实现逻辑上不同的网关。目前，访问代理同时实现了 [^2] 中讨论的 Web 代理和 SSH 网关组件。由于 AP 是唯一允许员工访问内部 HTTP 服务的机制，我们要求所有内部服务都迁移到 AP 后面。 不出所料，仅处理 HTTP 请求的初步尝试证明是不够的，因此我们不得不针对其他协议提供解决方案，其中许多协议需要端到端加密（例如 SSH）。这些额外的协议需要进行一些客户端的更改，以确保设备能够正确地识别给 AP。 AP 和访问控制引擎（共享的 ACL 评估器）的组合提供了两个主要的优势。通过为所有请求提供一个共同的日志记录点，它使我们能够更有效地进行取证分析。我们还能够比以前更快、更一致地更改执行策略。

Kubernetes Community Days 大连峰会将于 2023 年 4 月 15 日（周六） 在 大连高新园区海创科技交流中心 3 楼海创厅 举行。 参会指引 活动将于 9:00 正式开始，8:20 开始签到入场； 入场时请提供活动行门票二维码（可通过活动行 App、小程序，或者短信提醒中的链接获取二维码）进行验票，还没有领取门票的小伙伴可扫描下面海报上的二维码报名领取； 距离会场最近的地铁口是 海事大学地铁站 D 口； 现场为大家准备了茶歇（早晨下午各一场，早晨 10:20，下午 15:35），有精美糕点与饮品 大会不提供午餐，由于议程安排紧凑，建议就近就餐； 会场分为“多集群”和“安全”专场，可选择感兴趣议题参加