在 2024 年 KubeCon EU 大会上，Gateway API、多集群管理、服务网络以及网络安全成为了网络技术的焦点。本文将为您详细介绍这些热门主题。

01

更高效的流量管理

Ingress-nginx 2024 工作计划

Ingress-nginx 是一个基于 Nginx 的 Ingress 控制器，负责处理进入集群的流量。在会议上，Marco Ebert 和 James Strong 详细介绍了 ingress-nginx 的工作内容及其面临的挑战。

在 2024 年，Ingress-nginx 的工作会主要围绕以下几个方面展开：首先，改善 Helm Chart 的测试与发布流程，确保更加高效和稳定；其次，他们将主要版本升级到了 v2，并开始支持 Gateway API；第三，计划实施控制面与数据面的拆分，以优化大集群扩展性能和安全性。

02

网格技术升级

Sidercar 的过去，现在和未来

Services Mesh 是基础设施一个非常酷的工具，他允许你开箱即用的获得可观察性，可靠性和安全性，并无需对应用程序和代码进行任何更改。Services Mesh 实现的原理，一般是通过注入 sidercar proxy，使其与容器在同一网络命名空间运行，其运行寿命与业务容器一样长，并且只会接管流量，当接管流量时，可以添加重试，超时，负载均衡这种超酷的功能。

来自 Kong 的 Mike 和来自 Buoyant 的 Matei 就分享了 Sidercar 的过去，现在和未来。

在过去，k8s 的 Pod 中只有 initContainers 和 containers 来声明容器，而实现 sidercar 容器需要通过额外 hook 处理生命周期。

最近，随着 sidercar subgroup 工作组的成立，KEP-753 被推进，在 k8s 1.29 中，SidercarContainer 已经是 Beta 并且默认开启，你可以使用原生的方式在 initContainer 中声明 sidercar，只需要将 restartPolicy 的值设置为 Always，sidercar 的生命周期也更明确和稳定。

众所周知，sidercar 并不是实现 Services Mesh 流量代理的唯一方法，你还可以选择使用主机代理，以及 Ambient。例如在主机上运行代理的模型，虽然相比 sidercar 模型减少了资源占用，以及网络组件不需要处理 Pod Sidecar 级别的生命周期，但是主机代理升级期间，你需要让业务尽可能均匀分布在不同机器，以避免升级所带来的流量中断，同时 mTLS 的密钥管理和同主机不同的 Pod 流量突发处理也上升为主机级别。这些不同的模型都有自己的优缺点，比较好的方式就是根据自己的业务进行研究选择。

在未来，原生 SidercarContainer 的一些工作还在进行，例如在 KEP-4438 中会优化与 ML 一些相关的场景，以及改进资源管理，并逐步过渡到 GA。

03

优化网络连接

使用 Cilium Service Mesh 连接多云

Cilium Service Mesh 是基于 eBPF 技术的一种服务网格实现，它提供了高效的网络连接和安全策略管理。Cilium 利用 Linux 内核的 eBPF 技术来动态插入网络安全策略，从而在操作系统级别提供网络和应用程序的安全性、可见性和控制。

来自 Isovalent 的 Liz Rice 演示了使用 Cilium Service Mesh 连接 AWS 和 Google 集群进行负载均衡和故障转移，以及网络策略定义。

04

更全面的安全保障

停止泄露 Kubernetes Services 的 DNS 信息

来自 Google 的 John Belamaric 和来自 Ivnati 的 Yong Tang 分享了关于 Kubernetes Services 的 DNS 查询信息泄漏带来的安全问题，这个分享具有独特的视角。在 Kubernetes 基于角色的控制访问 RBAC，而 RBAC 可以定义哪些用户可以做什么，其原则是权限最小访问原则。但 DNS 是基于 UDP，会将查询暴露给所有用户，这正好与权限最小访问原则有点冲突。分享中演示了如何通过最小权限的 RBAC 账号，一步步的通过 DNS 的的反向查找，找出集群运行服务的种类，以及查看该服务的端口，这可能会带来安全问题。

John Belamaric 和 Yong Tang 分享了使用 CoreDNS 的防火墙插件策略，来避免 Kubernetes Services 的 DNS 泄露导致的安全问题。