“
「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」 [1] 。
”
Google 选择 Cilium 作为 GKE 网络的数据面
GKE & Cilium
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 主要的功能：
Cilium 核心功能 - https://moelove.info
在去年 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 中较为关键的特性：
主要适用场景：FaaS，Python/Ruby/Java/dotNet 等镜像环境；
实现插件
stargz-snapshotter
[6] ;
资源控制需要 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 而言更加轻量和易于配置。主要受众目标是：
它主要依赖的组件如下：
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】
TheMoeLove
参考资料
[1] 「k8s生态」: https://zhuanlan.zhihu.com/container
[2] GKE 使用 Cilium 的声明: https://cloud.google.com/blog/products/containers-kubernetes/bringing-ebpf-and-cilium-to-google-kubernetes-engine
[3] Cilium 主页: https://cilium.io/
[4] cilium 1.6 发布: https://zhuanlan.zhihu.com/p/79757835
[5] containerd v1.4.0-rc0 发布: https://zhuanlan.zhihu.com/p/178227659
[6] stargz-snapshotter: https://github.com/containerd/stargz-snapshotter
[7] containerd v1.4 release note: https://github.com/containerd/containerd/releases/tag/v1.4.0
[8] Istio 分析工具: https://istio.io/latest/docs/ops/diagnostic-tools/istioctl-analyze/
[9] istio 延迟启动: https://medium.com/@marko.luksa/delaying-application-start-until-sidecar-is-ready-2ec2d21a7b74
[10] Istio v1.7: https://istio.io/latest/news/releases/1.7.x/announcing-1.7/
