{ "componentChunkName": "component---src-templates-issues-tsx", "path": "/issues/322", "result": {"data":{"issuesJson":{"id":"5d17d9af-6993-5919-a449-ff29365b218e","title":"caicloud/kube-ladder: 文档旨在为广大从业者提供一个 Kubernetes 学习路径，为大家提供一定的指引","number":322,"bodyHTML":"
\n



\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Reposcaicloud/kube-ladder
Views\"views\"
Stars\"stars\"
Forks\"forks\"
License\"license\"
UpdatedAt\"last-commit\"
CreatedAt\"create-at\"
\n\n

\"\"

\n\n
\n\n\n

Table of Contents generated with DocToc

\n\n\n

Kubernetes 学习路径

\n

背景

\n

本文由 才云科技（Caicloud） 于 2019 年内部推出，现以开源的形式进行维护

\n

目前云计算行业对于 Kubernetes 学习的需求日益增加，但市面上关于 Kubernetes 的资源良莠不齐，存在几个问题：

\n\n

本文档旨在为广大从业者提供一个 Kubernetes 学习路径，为大家提供一定的指引。我们最终的目标是让所有人剥茧抽丝般地了解 Kubernetes，不仅仅知道怎么用 Kubernetes，还知道 Kubernetes 各个功能是如何设计的。在学习路径后期，我们还可以很\"自然\"的联想到正确的设计思路。

\n

学习路径

\n

注意：

\n\n

第一阶段 炼气期（2-4 周，每周 3-5 小时）

\n

目标

\n\n

路径

\n

学习任何系统的之前，了解其出现的背景和意义都是必不可少的，为什么会出现 Kubernetes？它解决了什么问题？有没有其他类似的系统？这里推荐阅读才云科技 CEO 张鑫在 2017 年文章《从风口浪尖到十字路口，写在 Kubernetes 两周年之际》。

\n

接下来，在了解 Kubernetes 系统本质之前，我们需要对 Kubernetes 有一个较为\"感性\"的认识，打消对 Kubernetes 的畏难情绪。这里，我们推荐使用 minikube 或 kind 部署一个本地环境，然后开始部署一个\"真实\"的应用（minikube 安装需要使用科学上网，或使用“国内版” minikube）。如果想一开始就挑战更高难度的安装方式（不推荐），可以使用 kubeadm 或者手动部署所有组件。关于安装，可以参考文档 lab1-installation。

\n

在安装好环境之后，可以开始动手实践最基本的 Kubernetes 概念。在第一阶段，我们推荐熟练使用以下常用资源和概念：Pod、Node、Label、Event、Service、Configmap & Secret、Deployment、Namespace。相关学习可以参考文档 lab2-application-and-service。

\n

（可选）仅完成上述内容可能还不足以让我们非常熟悉 Kubernetes 的基本概念，下面列出其他可以参考的资料，大家也可以按照自己的方式去搜索相关的资料：

\n\n

心法

\n

🤨

\n\n

第二阶段 筑基期（4-6 周，每周 8-10 小时）

\n

目标

\n\n

路径

\n

短暂接触 Kubernetes 概念之后，我们需要知其然并且知其所以然，因此在第二阶段我们开始学习 Kubernetes 基本架构。学习 Kubernetes 基本架构至少需要了解以下内容：

\n\n

首先可以阅读书籍或网上博客，推荐阅读：

\n\n

接下来，推荐从 0 开始部署一个 Kubernetes 集群（不使用任何工具），来加深对各个组件的理解：解决部署中出现的各种问题，查看组件启动日志等等。如果时间有限，也可以尝试使用 kubeadm 等工具来部署集群。目前 Kubernetes 集群部署自动化已经做得比较完善，但出于学习目的，再次墙裂推荐手动安装。关于手动安装集群，可以参考文档 lab3-manual-installtion。

\n

在本阶段修炼结束后，我们至少应该对以下问题了如指掌：Kubernetes 组件是如何交互，来启动容器，并对外提供服务的？

\n

心法

\n

💪

\n\n

第三阶段 金丹期（2-4 周，每周 3-5 小时）

\n

目标

\n\n

路径

\n

当我们可以熟练使用 Kubernetes 的基本资源，并且对 Kubernetes 的基本架构有了充足了认识，接下来需要对 Kubernetes 的 API 结构和子系统要有一个比较全面的认识，同时也要开始更加系统的了解排查问题相关的内容。

\n

要知道 Kubernetes API 是其最引以为傲的设计，掌握 API 的关键是需要了解：

\n\n

我们可以通过浏览 Kubernetes API 代码仓库来了解 Kubernetes API 组（Group）的信息。所有的资源定义代码都遵循 <group>/<version>/types.go 的规范，例如上述 Deployment 资源是定义在 apps group 中。我们可以在 apps/v1/types.go 中查找到关于 Deployment 的定义。

\n

接下来，我们可以通过浏览 Kubernetes/Community 代码仓库来了解各个兴趣小组（SIG），\"SIG\" 是 Special Interest Group 的简称。Kubernetes 的演进都是通过 SIG 来推动的，因此了解 SIG 的分工对我们理解 Kubernetes 非常重要。一般来讲，一个 SIG 对应着一个 Kubernetes 子系统，例如，sig-apps 负责决定是否引入新的 API，或者现有 API 是否需要升级等等。我们通过查看 Community 中带有 \"sig-\" 前缀的目录来了解 SIG 的工作内容、会议纪要等等。这里简单列举 Kubernetes 重要的子系统：

\n\n

（可选）细心的你可能会发现以 \"wg-\" 开头的目录，例如 \"wg-resource-management\"。\"wg\" 是 working group 的简称，是针对需要涉及多个 SIG 之间合作而展开的一种工作组，独立于任何 SIG 。例如 resource management 会涉及到 Node、Storage、Scheduling 等 SIGs。

\n

作为一个承上启下的阶段，我们需要总结一些 Kubernetes 排错的能力，推荐阅读：

\n\n

心法

\n

🌱

\n\n

第四阶段 元婴期（4-6 周，每周 8-10 小时）

\n

目标

\n\n

路径

\n

不出意外，你现在对 Kubernetes 基本的资源已经很熟练了，对 Kubernetes 内部组件和它们的交互比较清晰，还对 Kubernetes 的 API 全貌和组织结构也有一定的了解。如果出了意外 🤔，请重新回顾你的学习过程。

\n

本阶段，我们围绕几个关键方向来学习 Kubernetes，加深对其各个技术点的认识（这里只列出本阶段需要学习的核心能力，其他功能请量力而学）：

\n\n

总结一下，1）本阶段我们接触到更多的资源，包括：HPA、Job、CronJob、DaemonSet、StatefulSet、Ingress、Volume、PV/PVC、StorageClass、NetworkPolicy、PSP。2）更加深入了解已学资源的使用，例如 Init-Container、SecurityContext、Affinity 等。这些能力最终都会体现在各个资源的 API 上，例如 Affinity 是 Pod API 结构的一个字段，Scheduler 通过解析这个字段来进行合理的调度。未来如果有更多的能力，我们都可以通过解读不同资源的 API 字段来一探究竟。

\n

本阶段相关学习可以参考文档 lab4。

\n

心法

\n

🧘‍♂️🧘‍♀️

\n\n

第五阶段 化神期（3-5 周，每周 6-8 小时）

\n

目标

\n\n

路径

\n

当我们了解了 Kubernetes API 的设计理念，学习到了足够多的 API 资源及其使用方法之后，让我们再回顾一下 Kubernetes Master & Node 架构，以及它们运行的组件。事实上，Kubernetes 的每个组件都有很强的可配置性和能力，我们可以围绕 Kubernetes 的每个组件，来学习 Kubernetes 较为“隐晦”的功能。

\n

推荐通过 Kubernetes Command Line Reference 来了解这些组件的配置：

\n\n

同时，Kubernetes 提供了 FeatureGate 来控制不同的特性开关，我们可以通过 FeatureGate 来了解 Kubernetes 的新特性。此外，为了方便开发者和配置管理，Kubernetes 把所有配置都挪到了相对应的 GitHub 代码仓库中，即：

\n\n

当然，直接裸看配置有点硬核。为方便入手，下面我们简单总结部分功能（笼统的分为 Master 和 Node）：

\n

Master

\n\n

其它值得注意的参数包括：

\n\n

Node

\n\n

其它值得注意的参数包括：

\n\n

心法

\n

😇

\n\n

第六阶段 练虚期（4-6 周，每周 8-10 小时）

\n

目标

\n\n

路径

\n

本阶段我们可以开始了解 Kubernetes 各种扩展机制。如果说 Kubernetes 的 API 和架构设计是其重要的基石，那么扩展机制使得 Kubernetes 在各个生态领域开花结果。下面我们尝试列举出所有的扩展方式，每一种扩展都有其优势和局限性，请自行思考。注意这里提到的扩展机制指的是架构上的扩展，而非功能层面的扩展，例如 Pod 支持各种 Probe 来进行健康检查，包括自定义，这里我们不归为扩展机制的能力。

\n

API 资源扩展能力

\n\n

学习 API 资源扩展的一个重要方式是创建一个扩展资源，或者编写一个自己的控制器。强烈推荐自行编写一个控制器，这里列出几个常见的工具：

\n\n

API 访问扩展能力

\n\n

Kubernetes API 访问扩展主要是通过 Webhook 来实现。注意只有访问控制支持动态增加外部服务，认证鉴权的外部服务在启动 API Server 的时候就注册完毕，无法在后续增加，主要原因是动态增加外部认证鉴权服务，带来的安全风险过大。

\n

调度器扩展能力

\n\n

针对简单场景，我们可以直接使用 Scheduler Extender 即可，例如按 GPU 型号调度。复杂调度场景可以使用多调度器或调度器框架，例如基于流图的调度器 poseidon，批处理调取器 kube-batch 等。一般而言，使用 Extender 即可满足大多数场景。

\n

网络扩展能力

\n\n

网络插件 CNI 是容器网络标准，Kubernetes 提供了良好的支持，常用插件包括 flannel、Calico 等等。对于 Ingress、NetworkPolicy、DNS，相信到目前为止大家应该可以理解，其本质上是 Kubernetes 定义的一套 API，底层实现可插拔，用户可以有自己的选择。

\n

存储扩展能力

\n\n

FlexVolume 是 Kubernetes 自带的对接外部存储的方案，用户编写少量的代码即可加入自定义存储后端，适用于简单场景。存储插件 CSI 是容器网络标准，Kubernetes 提供了良好的支持，同时为方便第三方实现，还提供了一整套 SDK 解决方案。所有底层存储相关的能力都与 CSI 密切相关。

\n

运行时扩展能力

\n\n

运行时接口 CRI 是 Kubernetes 提出，为解决支持多种运行时而提供的方案。任何运行时，只需实现 CRI 相关的接口，即可接入 Kubernetes 中，包括 Docker、Containerd、gVisor、Kata 等。

\n

特殊硬件或资源扩展能力

\n\n

对于简单场景，例如静态汇报资源数量，可以直接使用 Extended Resource 扩展 Kubernetes 所支持的硬件。Device Plugin 的核心是自动接入各种特殊硬件如 Nvidia、Infiniband、FPGA 等。在资源汇报层面 Device Plugin 目前也使用了 Extended Resource 的能力，但由于 Extended Resource 的局限性，Device Plugin 未来也可以与其他 API 对接。目前使用最多的 Device Plugin 主要是 Nvidia 的 GPU device plugin。

\n

监控扩展能力

\n\n

自定义监控包括 Custom Metrics 和 External Metrics，例如 Prometheus adaptor。

\n

云供应商扩展能力

\n\n

云扩展能力的目标是使各个云供应商可以在不改变 Kubernetes 源码的情况下，接入其服务。每个云供应商都有独立的项目。

\n

命令行插件

\n\n

心法

\n

\":godmode:\"

\n\n

第七阶段 大乘期（终身学习）

\n

目标

\n\n

路径

\n

目前为止，我们学习了很多 Kubernetes 的概念，但也只是其最重要的部分。在本阶段，我们需要专注以下几个问题：

\n\n

首先，让我们一起来学习几个重要的项目。围绕 Kubernetes 的生态环境建设是其成为容器标准的关键。

\n\n

以上，我们仅列出了极少量的重要项目，Kubernetes 周边的项目十分之多，令人咂舌 😱。因此大乘期的你，需要开始持续跟踪 Kubernetes 及其生态的发展，甚至可以推动其发展，接下来我们列举一些靠谱资源：

\n

GitHub 仓库

\n\n

关注 GitHub 仓库可以让你了解最一手的进展，但是信息量一般较大，讨论很多难度也比较大。不过对于大乘期的你来讲，应该不是问题 😉。另外，这里还包含很多 Kubernetes 系统内部的设计，例如调度器的优化方案、资源垃圾回收方案等，值得了解和学习。

\n

Twitter 账号

\n

下面推荐几个 Kubernetes 项目的核心人员。大牛都喜欢用 Twitter 交（si）流（bi），可以关注一波。感兴趣的话题可以去交流，大牛都十分耐撕（nice。

\n\n

除此之外，Twitter 上还有不少项目和其他 Weekly 性质的 Twitter，推荐几个账号关注：

\n\n

Twitter 会根据你的喜好推荐其他相关内容，接下来就自由发挥。

\n

Blog 账号

\n\n

可以关注的优秀 Blog 很多，这里就不一一列举。

\n

心法

\n

🐲

\n

请坚持学习！送上一句黑鸡汤：

\n

\"The last thing you want is to look back on your life and wonder... if only.\"\n

\n

许可协议

\n","updatedAt":"2025-05-21T16:08:22Z","upvoteCount":null,"author":{"login":"eryajf","avatarUrl":"https://avatars.githubusercontent.com/u/33259379?u=e4a4090a38ac2473aaed4ef9945233636776c6c3&v=4","url":"https://github.com/eryajf"},"category":null,"labels":{"edges":[{"node":{"name":"更多","color":"25B472"}},{"node":{"name":"文档","color":"604862"}},{"node":{"name":"caicloud","color":"62c8e3"}}]},"comments":{"edges":[]}}},"pageContext":{"number":322,"previous":{"title":"aquasecurity/kube-hunter: 在 Kubernetes 集群中追踪安全弱点","number":321},"next":{"title":"noovertime7/kubemanage: 一个简单易用的 K8s 管理平台，前端使用 Vue3 ，后端使用 Gin+Gorm ，未来将支持多集群接入","number":323}}}, "staticQueryHashes": ["151096407","2861350382"]}