本文主要是介绍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
[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/
这篇关于K8S 生态周报| Google 选择 Cilium 作为 GKE 下一代数据面的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
