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

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

GKE & Cilium

Google 声明将选择 Cilium 作为 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 的替代品》 一文中,我就曾介绍过 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 发布》 一文中,介绍过 containerd v1.4.0-rc.0 相关的内容,有兴趣的朋友可以结合着看。

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

  • 支持镜像的 lazy pull:

    • 主要适用场景:FaaS,Python/Ruby/Java/dotNet 等镜像环境;
    • 实现插件 stargz-snapshotter;
    • 基于 Stargz/CRFS 完成;
  • CRI 模式下支持 MCS 多类别的安全;

  • 添加 cgroup v2 的支持:

    • 支持 eBPF 集成;
    • 改善 OOM 控制;
  • 改善 rootless 模式的支持;

    • 资源控制需要 systemd 和 cgroup v2 的支持;
    • overlayfs snapshotter 可通过 FUSE-overlayfs 完成,需要 4.18 及以上内核;
  • 支持不重启 daemon 的情况下,重加载 CNI 配置;

更多关于此版本中的变更,请查看其 ReleaseNote

Istio v1.7 正式发布

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

在易用性方面,新版本中提供了 Istio 分析工具 可通过 istioctl analyze --all-namespaces 使用;

在可靠性方面,你可以将应用程序的启动延迟到 sidecar 启动之后

安全性方面,主要就是针对非 Kubernetes (VM) 环境的一些优化了。

感兴趣的朋友可以参考其 ReleaseNote

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】

TheMoeLove