Cilium v1.13 正式发布

Cilium 最近两年真的是很火了。我在 2019 年折腾 Cilium 的时候，那时候它还处于不温不火的状态。比如我当时发布了一篇 K8S 生态周报| cilium 1.6 发布 100% kube-proxy 的替代品 | MoeLove ，很多人还在好奇 cilium 到底是什么。

到了 2020 年的时候，它就开始逐步得到了重视。所以我写了被 Google 选择的下一代数据面 Cilium 是什么 | MoeLove这篇文章，感兴趣的小伙伴可以看看。

在 2021 年底，cilium 发布了自己的 Service Mesh ，我写了倍受关注的 Cilium Service Mesh 到底怎么玩？- 上手实践 | MoeLove。

如今过去了一年多的时间，Cilium 也从 v1.11 升级到了 v1.13，它在 Cilium Service Mesh 上也做了更多的完善，我们一起来看看这个版本中值得关注的内容吧。

Gateway API 的支持更加完善

Cilium 现在提供了一个完全一致的 Gateway API 实现。Gateway API 是南北向负载均衡和流量路由到 Kubernetes 集群的新标准，也是下一代 Ingress 的规范。可以说 Gateway API 代表了 Kubernetes 集群中流量管理的未来。

Gateway API 的开发源于意识到 Ingress API 有一些局限性：首先，它没有提供用户需要定义的高级负载均衡的能力，它仅原生支持 HTTP 流量和基于内容的请求路由。

其次，用户管理变得不切实际：供应商最终通过利用 annotations 解决了 Ingress API 缺乏功能的问题。annotations 虽然非常强大，但最终造成了从一个 Ingress controller 到另一个 Ingress controller 的不一致。比如 Kubernetes Ingress-NGINX 和 Apache APISIX Ingress 使用的 annotations 就不一样。

第三，由于 Ingress API 是一个单一的 API 资源，它受到操作限制：它根本不适合具有共享负载均衡基础设施的多团队集群。

Gateway API 旨在提供所有核心路由需求，并解决从 5 年以上使用Ingress资源中汲取的一些操作经验教训。其关键设计原则之一是它以角色为导向。API 资源模型反映了在创建和管理流量管理期间看到的职责分离。它使网络架构师能够构建共享网络基础设施，可供许多不同的团队和非协调团队使用。

在 Cilium 1.13 中，Cilium Gateway API 通过了所有 Gateway API 一致性测试（v0.5.1），并支持以下用例：

HTTP路由
TLS终止
HTTP流量分割/加权
HTTP头修改

注意，如果是想要使用这个能力，需要在部署 Cilium 的时候添加 --set kubeProxyReplacement=strict --set gatewayAPI.enabled=true 的配置，当然 kubeProxyReplacement=partial 也能用。

要检查配置是否正确可以执行如下命令：

(MoeLove) ➜ cilium config view | grep -w "enable-gateway-api"
enable-gateway-api                             true
enable-gateway-api-secrets-sync                true

关于如何使用我就不演示了，大家如果有需要可以在文章下评论。

其他

可以通过增加 "service.cilium.io/lb-l7": "enabled" 这个 annotations，利用内置的 Envoy 来实现 L7 的负载均衡；
自 Cilium 1.12 推出 Ingress API 资源后，得到了快速采用。Cilium Ingress 现在可以在共享 Kubernetes LoadBalancer 资源的情况下部署，实现多个 Ingress 资源共享同一负载均衡器资源和 IP，极大地降低了云工程师的成本。
提供了数据平面的 mTLS, 使得 Cilium 可以在同一集群中的对等节点上对终端进行身份验证，并根据成功的互相认证控制数据平面的连接。这算是为以后基于 Pod 的 mTLS 提供基础。

可观测性

Hubble 支持开启 Tracing 的应用程序和 Grafana Tempo 集成；
Grafana 中增加了一个 Hubble Datasource Plugin，允许在 Grafana 进行更加方便的可视化操作；

K8S 生态周报| Cilium 和 Istio 的新版本带来众多新特性第1张

http-connectivity-dashboard.png

此外，还有很多网络和安全方面的改进和增强，更多详细信息请参考其 ReleaseNote

Istio v1.17 正式发布

Istio v1.17 终于正式发布了，这是 2023 年发布的首个大版本。这个版本支持 Kubernetes v1.23~v1.26，同时包含了很多值得关注的特性。

基于 Helm 的安装达到 Beta

自 Istio 0.4 起，除了使用 istioctl 进行安装外，便开始支持基于 Helm 安装了，直到现在终于可以达到 Beta 阶段了。用户现在可以通过 values.yaml 来完整的配置安装 istio 所需的各类参数了。

Canary 升级和版本标签已经达到 Beta

这个特性是从 istio v1.6 开始引入的，实际上是允许用户使用金丝雀发布的模式，来对 Istio 控制面进行升级，而避免对现有环境的影响。

版本标签（revision tags）是从 Istio v1.10 开始引入的，可以认为是对 Canary 升级的一种改进，有助于减少操作员在使用修订版本时必须进行的更改数量，从而安全地升级Istio控制平面。

对双栈的支持

Kubernetes 1.16 中引入了对 IPv6 的支持，并在 1.22 版中升级到了稳定版。Istio 从 1.16 版开始了支持 IPv6 的基础工作，本次 1.17 版增加了以下功能：

在双栈集群上部署单栈或双栈IP地址的服务：这样用户可以任意的使用单栈或双栈服务，例如，用户可以在双栈 Kubernetes 集群上分别部署 IPv4、IPv6 和双栈 IP 家族的 3 个服务，使这些服务通过 sidecar 相互访问。
为网关的监听器增加额外的源地址配置以支持双栈模式，以便服务网格外的 IPv4 和 IPV6 客户端可以访问网关。这仅适用于通过 gateway controller 自动部署的网关，Kubernetes 的 Gateway 应已支持双栈。

其他

支持Istio的filter patching：增加了对listener filter patching的支持，使用户可以在Istio的EnvoyFilter资源中执行ADD、REMOVE、REPLACE、INSERT_FIRST、INSERT_BEFORE、INSERT_AFTER等操作。
支持QAT PrivateKeyProvider：增加了对QuickAssist Technology (QAT) PrivateKeyProvider在SDS中的支持，并增加了相应的配置选项，为网关和sidecar选择QAT私钥提供程序。
RequestAuth API增强：增加了将JWT claims复制到HTTP请求标头中的支持。
istioctl命令增强：增加了一些功能，包括对istioctl admin log的revision标志，对istioctl proxy-config ecds的支持，对istioctl proxy-config log的支持，以及对istioctl analyze的--revision标志。

额外一说，Istio 之前虽然已经宣布了 Ambient 模式，但是该特性并没有全合并到 Istio 主线中。现在它终于合并进去了，并将在 Istio v1.18 中发布。

更多关于 Istio v1.17 的详细变更，请参考其 ReleaseNote

Kubernetes Ingress-NGINX v1.6.4 发布

containerd v1.6.18 发布

这是一个 patch 版本，但同样包含了几个值得关注的变更：

修复了 CVE-2023-25153，在导入OCI镜像时，某些文件没有对读取的字节数进行限制。如果一个恶意制作的镜像包含了一个非常大的文件，且没有对其进行限制，可能会导致拒绝服务攻击；
修复了 CVE-2023-25173，这是一个关于 supplementary groups 未正确设置的 bug 。

在Linux系统中，每个用户都属于一个主组和多个附加组。主组是用户默认组，而附加组则是用户除了默认组之外的其他组。在容器技术中，附加组用于控制容器中进程的访问权限。容器进程的权限是由容器的用户和用户组来控制的。如果容器中的进程需要访问主机上的资源，例如文件或网络端口，则必须使用与主机用户和组相匹配的身份验证信息。因此，通过在容器启动命令中设置附加组，可以限制容器中进程的权限，以保证容器的安全性。

更多关于此版本的详细变更，可参考其 ReleaseNote

上游进展

Implement kubectl debug profiles: general, baseline, and restricted by sding3 · Pull Request #114280 · kubernetes/kubernetes
(kubectl debug): Support debugging via files by ardaguclu · Pull Request #111453 · kubernetes/kubernetes

kubectl debug 允许启动 ephemeral 容器并附加到 pod 命名空间或主机命名空间。这有助于简化调试，允许从常规运行时镜像中移除常见的调试工具，如 gdb 或 strace。然而，如果没有所需的能力标志或其他安全设置以允许增强访问，则这些高级工具有时可能无法使用。反过来，使用新的 Pod 安全工具的人可能会遇到调试容器违反命名空间策略的问题。

这个 PR 添加了"general", "baseline", 和 "restricted"（以及向后兼容的 "legacy"）策略选项，可应用于 ephemeral 容器。这是对 KEP-1441 的实现，后续还会增加 "sysadmin" 和 "netadmin" 配置文件，以提升权限方面的问题。

此外，#111453 中为 kubectl debug 增加了 -f 的参数，如果有更多需要传递的信息，可以使用该方式。

kubeadm: backup kubelet config for "upgrade node" and "upgrade apply" by chendave · Pull Request #114695 · kubernetes/kubernetes

在使用 kubeadm upgrade 时候，会自动将 Kubelet 的配置文件备份到 /etc/kubernetes/tmp/ 目录下，并命名为 kubeadm-kubelet-configxxxx 的形式。

其他

Kubernetes Release Kubernetes v1.27.0-alpha.2 · kubernetes/kubernetes;
etcd Release v3.4.24 · etcd-io/etcd 修复了一个 etcdserver 可能会提示未启动的 learner 的问题，以及减少了 mvcc 仅计数范围的开销，将 RangeOptions.limit 参数推入索引树中，以减少内存开销；
vault Release v1.13.0-rc1 · hashicorp/vault
Pixie 计划成为 CNCF 孵化项目了