Caicloud CTO 精解 Kubernetes，CNCF and Beyond

Posted 2021-04-16 才云Caicloud

邓德源丨Caicloud CTO 

曾为美国谷歌集群管理组核心成员，主要参与开发集群管理系统。主要负责管理运维工程师提交的生产环境变更请求，自动化风险分析，自动化生产环境准备工作，以及各种集群容错处理。保证系统升级、软硬件错误等均能及时被发现并处理，谷歌集群能 24/7 小时不间断工作。作为核心成员参加了开发基于容器集群的谷歌开源项目（ Kubernetes ），一度成为全球前十的贡献者和贡献最高的华人。

2017 年 12 月 17 日，Caicloud CTO 邓德源受邀在“K8sMeetup 北京站”上以《Kubernetes，CNCF and Beyond》为主题进行演讲。以下是现场精彩回顾。

今天我主要分享一下怎样参与 Kubernetes 和 CNCF 的项目。

CNCF 和 Kubernetes 发展：困难和解决方案

Agenda

现在大家知道 CNCF 有十多个项目了，为什么是这些项目进入，后面有什么项目，以及 Kubernetes 怎么发展和管理的，我们都会进行讲解。

Kubernetes 数据（来自 Dan Kohn）

首先 Kubernetes 这里有个数据，来自 KubeCon。 Kubernetes Commits 数排名第 9， Issues 数排名第二。

Kubernetes 组件

Kubernetes 到底怎么样发展成为一个如此规模的项目呢？继续往下，可以看到围绕 Kubernetes 的几个组件外有非常多其它的组件：比如说监控层面，我们有 Heapster，存储方面有 CSI，网络方面也有 CNI，服务发现有 DNS，所有这些小的组件，对于 Kubernetes 都是它的插件方式。但是在它的 1.0、2.0 版本发布的时候，这些组件还没有抽象为完全独立的东西。比如说这个 Cloud Provider，大家知道 Kubernetes 可以运行在裸金属环境上，但是对于 Kubernetes 来讲，它不可能说我只运行在裸金属，或者 GCE 跑在谷歌上，它要抽象出一个 Cloud，它就会形成它外围的东西。对于 Kubernetes 来讲什么是它核心的东西，这是 Kubernetes 现在非常关心的问题。

Kubernetes 组件

所以接下来会看到，Kubernetes 发展的这么快，这么多的组件，它是怎么样维持它现在的增长的。一开始 Kubernetes 才开始做的时候也就五六个 founder，他们写了很多的代码，他们一群人，当时想提一个功能进去的时候，只发一个需求，说这个地方不对，发一些代码更改，就把 Kubernetes 改掉了。

现在 Kubernetes 成长非常快了。2015 年的时候，Kubernetes 出现了一个叫 Commit Rate 问题。代码的贡献者越来越多了，从原来十几二十个贡献者到了几百个贡献者，但是合进去的 PR 还是一样的。

SIG 的定义

这说明了什么问题呢？说明贡献者越多，但是 Kubernetes 的发展其实并没有更快地去跟着贡献者的人数而增长。所以这个问题就导致了社区做了很多的工作，我们后面会看到怎么做的这些工作。首先它把所有的 Kubernetes 的功能拆成了很多的 SIG，比如说有 APIS，有 APPS，每一个 SIG 都是管理 Kubernetes 的单独部分，就相当于 Linux 里面有很多子系统，不同的子系统就有 leader 做跟子系统相关的工作。

Kubernetes SIGs 前期出现的问题

但是现在出现了很多的问题，很多的 SIG 混合在一起。

• 比如说我做这两个，它们在功能上有一些冲突

• 比如说做节点层面和跟存储有关联，跟网络小组可能也会有关联

这时候小组之间应该怎么合作呢？

Kubernetes SIGs 问题解决方案

为了解决这个问题出现了几个解决方案：

• 第一个解决方案是，要非常谨慎地开一些 SIG。我知道之前也有阿里云提到 SIG 阿里云或者 SIG Azure。但社区非常谨慎，你开了 SIG 就要把它当成系统去维护。

• 第二个解决方案是，会有临时的很多的 Working Group，比如说 Container Identity 处理容器和其它容器鉴权的东西，就有一个工作小组做这些事情。这些小组定义一些管理层的任务。

• 第三个解决方案是，SIG PM 小组。PM 大家知道，对于 PM 来讲，一个公司来讲一个 PM 是非常重要的角色。但是 Kubernetes 发展了两年多，上万个 Commits，有 300 万行代码，这样的发展到现在它是没有 PM 的。

SIG PM 主要做什么

那么 SIG PM 主要做这几件事情：

• Project Direction

• 各个不同的 SIG 怎么去合作

• 怎样确保 Kubernetes 稳定增长

• 做 Marketing，这个现在已经有一定的效果了

• 最后就是怎么样确保 Kubernetes 的发布是非常高效的

2017 年 SIG PM 工作总结

2017 年 SIG PM 工作总结

SIG PM 总结了 Kubernetes 2017 年几个大的工作，一个是 APPs，发布了 1.9，包括节点，还有很多其它的认为是比较大的一些计划。

SIG PM 2018 年改动计划

SIG PM 2018 年会做什么改动呢？

如果大家对 Kubernetes 做功能比较感兴趣，会发现它有很多的 Proposal，大家知道我现在要去做存储，Kubernetes 可以提供一些价值给你。如果想让这个 Volume 做扩容怎么办，这个时候就是提一个 Proposal，然后让大家看，看完之后代码写进去，然后 1.9 发布了，可以对 Volume 进行扩容。

但是这样的节奏已经没办法支撑 Kubernetes 的发展。所以 2018 年时候会有一个比较大的变化，我们会有一个叫 KEP 的一个东西，Kubernetes 学习了很多其它社区的优点，把  Proposal 变成了 KEP。这样当我们对 Kubernetes 的发展比较关心的时候， 不用等到它发布的时候我再知道它有什么功能，我只要看 KEP，我就知道它有什么功能了。这个 KEP 对于开发者而言是一个非常好的程序，对于开发者而言如果真的想贡献给 Kubernetes，我看 KEP 就知道怎么样贡献，它在什么样的阶段。

KEP Sample

这边是一个 KEP，这个 KEP 里就写出来我到底需要做什么事情，谁来负责这样一个事情。然后不同的兴趣小组，比如说这个 KEP 它涉及到了网络，涉及到了发布，涉及到了存储，那可能它是一个比较大的功能点，那每一个小组，到了那个阶段，谁负责这个事情，我们都可以看到。

SIG PM Reference

这面有很多的链接，大家可以回头去看，我们最后会有一个总结，大家怎么样寻找 Kubernetes 里的信息。

SIG-Architecture

第二个就是 SIG Architecture，Kubernetes 是一个编排系统，但怎么定义编排系统，核心是什么，所以这个可以在 SIG Architecture 里解决。Nucleus 这块，我们可以看一下 Kubernetes 对这边整体的总结，我们这层里面的所有东西都是 Kubernetes 支持的，我们都必须有的，就是说只要你说你是一个支持 Kubernetes 的平台，那么下面一层你就只能用 Kubernetes 提供给你的。上面一层是 Kubernetes 基于 Application 做的 Layer，其实它就是把它跑在每一个机器上，你可以不用的，你自己实现一套，但是这边所有的实现都是你可以用，但是你也可以不用。

SIG-Architecture 

SIG-Architecture 

SIG-Architecture 

SIG Architecture 在不断的完善这个图，定义 Kubernetes 到底是什么。在这次 KubeCon 的主题就是 Boring，这些核心很稳定了，不需要再改了，改的都是上面的东西。

SIG-contribx

SIG-contribx 相关 Reference

上面提到的都是怎么去管 Kubernetes 项目，实际上还有一个 SIG-contribx，它的作用是让新的人参与到 Kubernetes 里去，里面会有非常多的工作，比如说怎么去做 Mentoring，怎么样让它更好的贡献给 Kubernetes。

技术相关 SIG-docs

刚刚提到的四五个都是跟技术无关的事，其实还有很多跟技术相关的 SIG，我们怎么样在 Kubernetes 里找到我们相关的东西呢，首先 Community 是很重要的地方，假设我现在对 Kubernetes 网络发展非常感兴趣，现在就打开这个 REPOSITORY，打开它的 Meeting  Agenda，它会给到你所有的状态信息，我们只要有了这个东西，我们对于 Kubernetes 的现状非常了解。那如果我们想看一些比较细节的东西，可以去到 Features 里面，里面会要把发布的东西总结起来。我们刚刚提到 SIG PM 会做这个事情，但是现在每个 SIG 小组都要更新这个东西。

这边把 Kubernetes 怎么样去运作的给大家讲讲，实际上本身是很简单的，但是因为开源社区去做 PM 相关的东西比较困难也是比较新的东西，所以这边给大家讲一讲，让大家能够参与到社区。

CNCF：项目 & 蓝图

CNCF  Overview

   

下面讲 CNCF，我不知道大家对于 Cloud Native 的理解，但是对于 CNCF 来说，最重要的属性有以下三点：

• 第一点认为一定是 Container packaged

• 第二点所有的都是通过平台化做管理

• 第三点就是应用本身是为服务导向的

也有一种说法，如果你的项目想要是 Cloud Native

• 第一你要用 Go 语言写

• 第二取好听的名字

• 第三加上 .io 域名

符合以上三点，你就是 Cloud Native 的了。当然，这是一个玩笑。

“标准化”蓝图

CNCF 整体的目标是要建立一个蓝图，这个蓝图里的所有的组件都是标准化的，比如说这个网络 SDN 和 Infrastructure 之间有标准的接口。每一个组件都有一个接口，也就是说你定义好了接口没关系，但是我怎么用这个接口，一定要有一个 reference implementation。所以说现在 CNCF 所有的项目都是围绕着这么一个所谓的标准化里去做的一个计划。

CNCF 14 个项目

CNCF 现在 14 个项目，包括 Kubernetes 在内的所有项目都没有达到毕业的标准。其中，Incubating 就是我接受你了，但是不知道你行不行，但是我先接受你帮助你做广告，如果你不行，12 个月之后我就把你给干掉（比如 Core DNS）；但如果你可以的话，我就让你进入 Incubating。

进入 Incubating 意味着至少有三个独立公司在生产上用你，并且你有一个非常健壮的社区，里面的人都是比较稳定，然后不断地有新人参与。

进入 Graduation 还会有更苛刻的要求。

CNCF 其它项目

下面我们就来我们看看其它项目长什么样子的，Minio 这个项目就是跟 S3 兼容的 Object  Store；像 nats、CockroachDB 等这些项目都在讨论阶段。

正在讨论中的 6 个项目

目前六个项目正在讨论中，一个叫做 Istio 这个项目大家都非常地了解。但是因为存在很多问题，这个项目在前天 Proposal 被关掉了，后期会讨论怎么进入 CNCF 里面，但是会搁置一段时间。

OPA 就是在云原生的环境下怎么样做 Policy Enforcement，我的 Container 怎么认为它是它自己，这个 Container 它有权限做什么事情。

SPIFFE 是一个认证框架。我们现在都是以 IP 为导向的，一个 IP 下面可能有非常多的东西。比如说一个 IP 里面跑了很多个容器，每一个容器都做了不同的事情，我怎么知道这个服务做的东西是合法的呢？又比如这个服务是博客的前端，怎么知道你在真正的服务博客而不是做其它的任务？所以 SPIFFE 的项目得到了很大的关注。

Vitess，国内基本上不用。这就是一个 Youtube 开源的做 mysql 集群解决方案。

ROOK 做云商环境下存储的管理。

InfraKit，部署基础设施。

类似的项目非常多，大家可以参考一下。

这些项目其实回过头来，刚刚那幅图可以看到，像 lstio、OPA、SPIFFE 都是弥补刚才的空缺的。

2018 年 Kubernetes 的项目可能扩展到 18、19 个。

CNCF- The People

这些项目为什么可以进，进来以后 CNCF 拿什么东西宣传它们。对于我们技术而言这个 TOC 就是关注的点，它们来决定能不能进，怎么进。我们看的所有的项目，包括它所处的阶段都可以在这个地方找到，我们可以看一下发展的进程。

CKA 与 CKAD

CKA

最后给大家讲一下 CKAs，有很多线下同事交流说对 CKA 感兴趣。CKA 是认证这个人是否具备 Kubernetes 管理经验的考试。考试涵盖面非常广，从应用到网络到存储，到怎么安装部署 Kubernetes 都会考。

CKA

我举个例子。就是你坐在一台电脑前，它给你一个集群，一个 Master，三个 Nodes。其中一个 Node 不健康，你可以登录到任何一个节点去玩儿，然后找到那个出问题的节点，你要知道哪个节点是出问题的，然后登到节点去看为什么出问题。这个电脑后边会有一个人一直看着你，然后会有二三十道题让你答。

CKAD

这个考试有一定的问题，就是我一定要懂 Kubernetes 的运维知识。实际很多情况下我们用 Kubernetes 的时候不需要运维，一个节点坏掉了，我不用关心它是不是挂掉了。所以这次我们也做了一个 CKAD 的考试认证考拟，这个人员要知道怎么样部署业务。有了这么一个认证，不管是对自己而言，或者对公司而言我都可以相信我现在招的这个人是会开发云原生业务的。在 Austin 的时候，我们有 4 天在定 Domain。

CKAD 现在还没有公布出来，但是后续应该是可以公开的：就是我们共有 7 个点，会测试开发人员对知识的理解程度，时间是 2 小时。所以可以看到我们在推进的过程中也是动了很多的心思。

CNCF Upcoming  Events

这是 Upcoming  Events，明年 11 月 15 号会在上海有一个 Kubecon。谢谢大家！

 

-END-  

推荐阅读：