K8S 生态周报| Google 选择 Cilium 作为 GKE 下一代数据面

“

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」^[1]。

”

Google 选择 Cilium 作为 GKE 网络的数据面

Google 声明^[2]将选择 Cilium^[3] 作为 GKE 网络的数据面 V2 以便增加其容器安全性和可观测性。

Kubernetes 最强的能力之一便是其开发者优先的网络模型，可以提供简单易用的功能，比如：L3/L4 service 和 L7 ingress 以便将流量引入 Kubernetes 集群，以及多租户的网络隔离等。

但随着越来越多的企业使用 Kubernetes , 用例范围越来越广，围绕多云，安全性，可观察性和可扩展性等方面均提出了新的要求。此外，诸如 service mesh 和 serverless 等技术，均需要来自底层 Kubernetes 的更多自定义。这些新要求最终汇聚到一起得出来的结论便是：需要一个更具可编程性的数据平面，该平面可执行 Kubernetes 感知的数据包操作，并且还不会损失性能。

Cilium 的出现恰恰满足了这些需求，它基于 eBPF 技术的实现，使 Linux 内核具备了 Kubernetes 的意识。它可以很好的满足现在新的对容器负载的可伸缩性，可观察性以及安全等方面相关的要求。此外， Cilium 所提供的功能也远超了传统 CNI 提供的功能，不仅有传统的 Network Policy， service 和 LB ，还有 Flow & Policy logging 以及内置运维和安全侧的 metrics 等。

背后的故事

Google 首次参与 Cilium 项目大概是去年 12 月，后来越来越多的 Google 工程师加入进来，也贡献了很多核心功能，比如上文中提到的 Policy Logging 等功能。此外还有很多，比如自动检测 EndpointSlices ，对 Pod IP 的 IPv6 邻居发现的支持，还有基于 socket cookie 的负载均衡等。

当然，Google 是有实力可以直接基于 eBPF 来构建其数据平面的，但它选择了参与 Cilium 社区，这也是对 Cilium 社区多年来工作的认可，这也让社区成员非常开心。

相信今后将会有更多有趣的特性被加入进来。

以下是 Cilium 主要的功能：

在去年 8 月份的 《K8S 生态周报| cilium 1.6 发布 100% kube-proxy 的替代品》^[4] 一文中，我就曾介绍过 Cilium 项目及其所用技术，也针对该项目写了自己的看法，感兴趣的朋友可以看看。

另外一个比较有意思的信息是，2017 年 Google 与 Calico 背后的公司 Tigera 合作，为 GKE 引入了 Calico 。Cilium 是否会取代 Calico 呢？

最后，如果你想要在 GKE 中使用 Cilium ，可以使用如下命令：

gcloud beta container clusters create <cluster name> \--enable-dataplane-v2 --release-channel rapid \--cluster-version 1.17.9-gke.600 --zone <zone name>

containerd v1.4.0 发布

本周 containerd 终于迎来了 v1.4.0 版本的正式发布，距离上一个正式大版本 v1.3.0 已经过去了近 10 个月，并且在正式发布之前，也先后经过了 3 个 beta 版本和 2 个 rc 版，可以看出此次发布还是很慎重的。

我在之前的 《K8S 生态周报| runc v1.0-rc92 发布》^[5] 一文中，介绍过 containerd v1.4.0-rc.0 相关的内容，有兴趣的朋友可以结合着看。

以下是此 v1.4 中较为关键的特性：

• 支持镜像的 lazy pull:

• • 主要适用场景：FaaS，Python/Ruby/Java/dotNet 等镜像环境；

  • 实现插件 stargz-snapshotter^[6];

  • 基于 Stargz/CRFS 完成；

• CRI 模式下支持 MCS 多类别的安全；

• 添加 cgroup v2 的支持：

• • 支持 eBPF 集成；

  • 改善 OOM 控制；

• 改善 rootless 模式的支持；

• • 资源控制需要 systemd 和 cgroup v2 的支持；

  • overlayfs snapshotter 可通过 FUSE-overlayfs 完成，需要 4.18 及以上内核；

• 支持不重启 daemon 的情况下，重加载 CNI 配置；

更多关于此版本中的变更，请查看其 ReleaseNote^[7]

Istio v1.7 正式发布

Istio v1.7 主要集中在易用性，安全性和可靠性上，并针对非 Kubernetes 环境做了一些优化。

在易用性方面，新版本中提供了 Istio 分析工具^[8] 可通过 istioctl analyze --all-namespaces 使用；

在可靠性方面，你可以将应用程序的启动延迟到 sidecar 启动之后^[9]；

安全性方面，主要就是针对非 Kubernetes （VM） 环境的一些优化了。

感兴趣的朋友可以参考其 ReleaseNote^[10]

k3s 成为了 CNCF sandbox 项目

k3s 目标是提供一种通过 CNCF 一致性认证的生产级 Kubernetes 发行版，但相比 Kubernetes 而言更加轻量和易于配置。主要受众目标是：

• Edge

• IoT

• CI Pipeline

• 开发到生产一致的环境

• ARM 设备

它主要依赖的组件如下：

• containerd 和 runc

• Flannel

• CoreDNS

• CNI

• Host utilities (iptables, socat, etc)

• Ingress controller (traefik)

• Embedded service loadbalancer

• Embedded network policy controller

就我个人而言，我对 k3s 的了解&兴致仅限于它刚发布之时，后续偶尔会稍微看下相关的信息，但未在生产中使用过。

现在 k3s 的定位已经明确为 Kubernetes 的一种发行版，我觉得这个决定还是很明智的（相比 fork 而言）。之前听说国内有几个公司在搞 k3s on ARM 之类的，不过也没听到后续的结果，可能还是会面临一些问题吧。

生产使用我个人还是建议选择 Kubernetes 或者可选择 OpenShift 之类的。（有特殊场景或需求的另说）

题外话

以上便是我觉得本周值得关注的内容了，上周发起的“关于使用 Helm v2 or v3 ”的投票结果出来了， 参与投票的朋友中有 7 成在用 Helm v3 。

本期讨论内容：你在用哪个网络插件呢？以及选择它的原因 ， 欢迎留言参与讨论！

欢迎订阅我的文章公众号【MoeLove】

参考资料

[1]

「k8s生态」: https://zhuanlan.zhihu.com/container

GKE 使用 Cilium 的声明: https://cloud.google.com/blog/products/containers-kubernetes/bringing-ebpf-and-cilium-to-google-kubernetes-engine

Cilium 主页: https://cilium.io/

cilium 1.6 发布: https://zhuanlan.zhihu.com/p/79757835

containerd v1.4.0-rc0 发布: https://zhuanlan.zhihu.com/p/178227659

stargz-snapshotter: https://github.com/containerd/stargz-snapshotter

containerd v1.4 release note: https://github.com/containerd/containerd/releases/tag/v1.4.0

Istio 分析工具: https://istio.io/latest/docs/ops/diagnostic-tools/istioctl-analyze/

istio 延迟启动: https://medium.com/@marko.luksa/delaying-application-start-until-sidecar-is-ready-2ec2d21a7b74

Istio v1.7: https://istio.io/latest/news/releases/1.7.x/announcing-1.7/