Cilium 是一个开源项目，旨在为云原生环境提供网络、安全和可观测性，例如 Kubernetes 集群和其他容器编排平台。本博客展示了如何使用 Cilium 和 BGP 将您的 Kubernetes 服务暴露给外部世界。 BGP 边界网关协议（BGP）是一种标准化的外部网关协议，旨在在互联网上的自治系统（AS）之间交换路由和可达性信息。该协议被分类为路径矢量协议，因此它根据由网络管理员配置的路径、网络策略或规则集来做出路由决策。它参与制定核心路由决策，这使得它对互联网的正常运行至关重要。 BGP 专为健壮性和可扩展性而开发，用于在大型网络之间路由数据，包括 ISP 和其他大型组织。它确保了无环的域间路由，并有助于维护稳定的网络结构。BGP 可以处理数千个路由，并以其随着网络增长而扩展的能力而脱颖而出。由于其灵活性和对路由策略的控制，它被广泛使用，使其能够快速响应网络变化。
本文讲述了一个关于K8s默认参数引起的性能问题的案例。文章中详细介绍了问题的时间线、现象、排查过程以及最终的解决方案。同时，还对系统资源瓶颈、应用程序瓶颈和具体排查过程进行了详细的分析和说明。
9 月 26-28 日，由 Linux 基金会、CNCF 主办的 KubeCon + CloudNativeCon + Open Source Summit China 2023 在上海举办。作为社区积极贡献者和最终用户，字节跳动和火山引擎团队在此次大会上进行了 7 个分享，本系列内容根据此次会议分享整理而成，欢迎关注！ 在 KubeCon CN 2023 的「 Open AI + 数据 | Open AI + Data」专题中，火山引擎软件工程师胡元哲分享了《使用 KubeRay 和 Kueue 在 Kubernetes 中托管 Ray 工作负载｜Sailing Ray workloads with KubeRay and Kueue in Kubernetes》议题。以下是本次演讲的文字稿。 本文将从 Ray 为何得到 AI 研究者们的青睐，在字节如何使用 KubeRay 来托管 Ray 应用，Kueue 如何管理和调度 RayJob 三个方面进行介绍。
本文比较了 Kubernetes 的内置自动伸缩器（HPA 和 VPA）和 KEDA 项目的优缺点，分析了它们在不同场景下的适用性和效果，展示了 KEDA 如何解决 HPA 和 VPA 无法覆盖的复杂需求。
这份报告回顾了 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 版本升级来说吧。记得曾经经历过集群的原地升级：团队的几个人经过多次、多个环境的演练，还要在凌晨的时候进行生产环境的升级。幸好最后是有惊无险，整个过程的体验就像是下图一样：为飞行中的飞机换引擎。
