这份报告回顾了 Cilium 项目在 2023 年的成就和进展，包括贡献者增长、版本亮点、用户调查结果、生产环境案例、社区活动和引用、以及 2024 年的发展方向。报告显示，Cilium 项目已经成为云原生网络、可观测性和安全性的领导者，得到了广泛的认可和采用。报告还展示了 Cilium 项目的健康状况和活跃度，通过数据和图表展示了项目的里程碑和提交情况。报告最后感谢了社区的支持和贡献，以及期待未来的更多创新和协作。
这篇文章介绍了集群网格的概念和优势，以及如何使用 Calico Open Source 的多种方法，实现跨集群的服务间通信和负载均衡。
在 Kubernetes 上部署应用程序后，通常的下一步是让用户可以访问它。我们通常使用Ingress 控制器[1]，例如 Nginx、Haproxy、Traefik 或来自云提供商的控制器，来引导传入的流量到应用程序，管理负载平衡、TLS 终止等等。 然后，我们必须从众多可用的选项[2] 中进行选择。Cilium 是其中一个相对较新的选项，旨在处理所有这些网络方面的问题。 Cilium[3] 是一个基于 eBPF 的开源网络和安全解决方案，其采用速度增长迅猛。它可能是提供最多功能的网络插件之一。我们不会涵盖所有功能，但其中一个功能涉及使用Gateway API[4] (GAPI) 管理传入流量。
在过去的十年里，源代码交付过程发生了显著变化。在这个过程的部署方面，最近的适应是采用了一种声明式和版本控制的方法来定义应用程序所需的基础设施状态和配置，通常称为 "GitOps"。这种方法在云原生应用程序和容器编排平台（如 Kubernetes）的背景下变得流行起来，因为在这些环境中管理复杂的分布式系统可能会很具挑战性。 由于这种所需的状态具有声明性质，它指向了特定/静态版本的应用程序。这带来了显著的好处，特别是可以在进行更改之前审计更改、回滚到先前状态并保持可重复的设置。然而，在不需要管道来更改应用程序的状态/配置的情况下，我们如何迁移到更新的应用程序版本而避免手动版本调整呢？ 这就是 Argo CD Image Updater 的作用所在；它验证容器镜像的更近版本是否可用，随后触发应用程序的 Kubernetes 资源的必要更新，或者可选择更新关联的版本控制。
有了多集群服务和跨集群的流量调度之后，使用 Kubernetes 的方式会发生很大的变化。流量的管理不再限制单一集群内，而是横向跨越了多个集群。最重要的是这一切“静悄悄地”发生，对应用来说毫无感知。 就拿 Kubernetes 版本升级来说吧。记得曾经经历过集群的原地升级：团队的几个人经过多次、多个环境的演练，还要在凌晨的时候进行生产环境的升级。幸好最后是有惊无险，整个过程的体验就像是下图一样：为飞行中的飞机换引擎。
本文概述了HPA扩容慢的原因包括扩容的响应时间和每次扩容的副本数。响应时间受到metrics-server和kubelet收集监控信息的周期影响，而扩缩容的速度则由监控数据和扩缩容行为控制决定。此外，HPA controller执行效率和应用ready时间也会影响扩缩容速度。在大量的HPA对象的集群中，HPA controller可能会有性能瓶颈，而pod从启动到ready的时间则取决于多个因素，包括pod调度、kubelet响应、镜像下载、容器创建、应用启动和应用readiness。
在前面的《容器云平台中权限模型的设计思路》中，我从平台方的视角介绍了如何建设 IAM（Identity and Access Management，身份与访问管理）系统，用来给各个业务应用提供统一的认证、鉴权的能力。 本期，我将从业务侧的角度出发，跟大家讲讲如何将 Kubernetes Gateway API 和 Istio 的能力与 IAM 系统相结合，构建适用于微服务应用的鉴权体系。
