caicloud / kube-ladder

Learning Kubernetes, The Chinese Taoist Way

Table of Contents generated with DocToc

• Kubernetes 学习路径
  • 背景
  • 学习路径
    • 第一阶段 炼气期（2-4 周，每周 3-5 小时）
      • 目标
      • 路径
      • 心法
    • 第二阶段 筑基期（4-6 周，每周 8-10 小时）
      • 目标
      • 路径
      • 心法
    • 第三阶段 金丹期（2-4 周，每周 3-5 小时）
      • 目标
      • 路径
      • 心法
    • 第四阶段 元婴期（4-6 周，每周 8-10 小时）
      • 目标
      • 路径
      • 心法
    • 第五阶段 化神期（3-5 周，每周 6-8 小时）
      • 目标
      • 路径
      • 心法
    • 第六阶段 练虚期（4-6 周，每周 8-10 小时）
      • 目标
      • 路径
      • 心法
    • 第七阶段 大乘期（终身学习）
      • 目标
      • 路径
      • 心法
  • 许可协议

Kubernetes 学习路径

背景

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

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

• 官方文档缺少明确的"梯度"，信息错综复杂
• 资料较为分散，查找信息费时费力
• Kubernetes 发展很快，书籍或者网上教程容易过时

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

学习路径

注意：

• 术语来自才云科技工程师 gaocegege 所著《适合系统工程师的"机器学习"学习路径》
• 注意这是学习路径，不是一个教程！
• 大多数概念都会给出官方链接，如果需要深入了解请自行查找！

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

目标

• Kubernetes 的背景
• 安装 Kubernetes 环境
• Kubernetes 基本概念和使用方法

路径

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

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

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

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

• 官方 Tutorial：Learn Kubernetes Basics
• 官方 Guestbook 样例：Guestbook Example
• Kubernetes Tutorial for Beginners

心法

🤨

• 请反复加深对上面资源的操作熟练度。如果你是第一次接触 Kubernetes，或者仅了解过一点 Kubernetes 的知识，那么基（ken）本（ding）是不明白 Kubernetes 底层到底发生了什么。请不要心急，姑且把它当成一个黑盒工具即可 🛠。
• 你可能会在网上看到更多的概念，如 PVC、Ingress、Priority 等。炼气阶段，请不要尝试学习过多的资源类型。Kubernetes 有非常多的概念和类似的资源，我们这里熟悉最核心的概念即可，否则易走火入魔 👻，切记。当我们打通任督二脉之时，所有的新概念都不过尔尔。

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

目标

• Kubernetes 的基本架构
• Kubernetes 容器调度的基本流程

路径

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

• Master & Node
  • 知道什么是 Kubernetes Master，什么是 Node
  • 知道两者的关系，知道它们是如何通信的
• Master 组件
  • API Server。Kubernetes 如何接收请求，又是如何将结果返回至客户端。
  • Etcd。了解 Etcd 主要功能机制。
  • Controller Manager。Kubernetes 控制器是其架构中最为核心的一环，我们需要了解控制器的原理，List-Watch 的基本原理，知道 Kubernetes 默认情况下大致包含哪些类型的控制器。
  • Scheduler。熟悉 Kubernetes 的调度流程是怎样的，调度器在整个调度流程中的角色。
• Node 组件
  • Kubelet。知道 Kubelet 是如何接受调度请求并启动容器的。
  • Kube-proxy。了解 Kube-proxy 的作用，提供的能力是什么。
  • Container Runtime。了解都有哪些 Container Runtime，主要了解 Docker 一些基本操作与实现原理。
• 核心 Addons & Plugins
  • DNS。DNS 为集群的服务发现提供的支持，Kubernetes 1.13 开始默认使用 CoreDNS。
  • Network Plugin。Kubernetes 多节点环境需要部署网络插件才可以使用，默认情况下使用 flannel 即可。

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

• 官方文档：Kubernetes Components
• feisky 的博客：Kubernetes 指南之核心原理
• kubectl run 的背后流程（难）：What happens when I type kubectl run?
• kubectl run 的背后流程中文版：kubectl 创建 Pod 背后到底发生了什么？

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

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

心法

💪

• 请不要死记硬背 Kubernetes 架构，要开动大脑 🧠去理解其背后设计的原因。
• 筑基期是比较困难的一个阶段，如果感觉一头雾水，请不要气馁，你不是一个人。当你感觉进入了瓶颈时，可以尝试寻找身边的战友，总结一些你的问题并寻求答案 🍻。

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

目标

• Kubernetes API 结构
• 熟悉 Kubernetes 各个子系统
• 熟悉 Kubernetes 排错相关内容

路径

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

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

• Kubernetes 的 API 是如何控制版本的
• Kubernetes 的 API 是如何分组的
• Kubernetes 对象的表示方法与设计理念
• Kubernetes API 的访问控制

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

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

• 架构 Architecture
• 应用 Apps
• 存储 Storage
• 网络 Network
• 权限 Auth
• 节点 Node
• 调度 Scheduling
• 命令行 CLI
• 多集群 MultiCluster
• 云平台 CloudProvider
• 扩展性 Scalability
• 弹性伸缩 Autoscaling
• 监控日志 Instrumentation

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

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

• 官方文档：Kubernetes Troubleshooting
• feisky 的博客：Kubernetes 集群排错指南

心法

🌱

• 本阶段的重点是"耳听六路 🙈 眼观八方 🙉"。前两个阶段接触到了很多 Kubernetes 的细节，本阶段需要对 Kubernetes 的全貌有个更加清晰的认识。很多内容可能看不太懂，但请在你的心中埋下一颗种子。

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

目标

• 加深对各个资源的理解
• 学习更多 Kubernetes 概念和知识

路径

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

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

• 计算

  • Pod Lifecycle & Healthcheck & RestartPolicy
  • Pod Init-Container
  • Horizontal Pod Autoscaler (HPA)
  • 更多控制器：Job、CronJob、Daemonset、StatefulSet、ReplicaSet

• 网络

  • Service 实现，主要了解 iptables 的实现（可选：ipvs 模式）
  • Ingress 原理和常用的 nginx ingress 操作
  • DNS 服务的原理，以及 CoreDNS 方案

• 存储

  • Volume 以及底层存储类型
  • PV/PVC、StorageClass

• 安全

  • AuthN, AuthZ & Admission Control
  • NetworkPolicy
  • ServiceAccount
  • Pod/Container SecurityContext
  • Pod Security Policy (PSP)

• 调度

  • Pod/Node Affinity & Anti-affinity
  • Taint & Toleration
  • Priority & Preemption
  • Pod Disruption Budget

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

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

心法

🧘‍♂️🧘‍♀️

• 本阶段难度指数高，请合理调整你的心境。渡劫 🌋 成功后，你对 Kubernetes 的掌握将会进入一个新的台（tian）阶（keng）。
• 学习相关功能时，可以回顾其所在 SIG，看看能不能发现有用的资源。

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

目标

• 学习更多 Kubernetes 集群层面的功能
• 更加深入学习 Kubernetes 架构和组件能力

路径

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

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

• kube-api-server
• kube-scheduler
• kube-controller-manager
• kube-proxy
• kubelet
• kubectl

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

• https://github.com/kubernetes/kube-scheduler
• https://github.com/kubernetes/kube-controller-manager
• https://github.com/kubernetes/kube-proxy
• https://github.com/kubernetes/kubelet
• https://github.com/kubernetes/kubectl

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

Master

• Dynamic Admission Control
  • 动态准入控制（在练虚期阶段需要更加深入的了解）
  • 对应 API Server --admission-control-config-file 参数
• Advanced Auditing
  • 提供可动态配置的审计功能
  • 对应 API Server 带有 --audit- 前缀的参数
• Etcd Configuration
  • 提供各种与 Etcd 相关的配置，例如 Kubernetes event TTL
  • 对应 API Server 带有 --etcd- 前缀的参数
• All Admission Controllers
  • 列举所有 Kubernetes 所支持的 Admission Controllers，每个 Admission 都与 Kubernetes 特定的功能相关联
  • 对应 API Server --enable-admission-plugins 参数，该参数注释列举了所有的默认 Admission Controllers
• Garbage Collection
  • 启用后，Kubernetes 会自动根据 OwnerReferences 来回收 API 资源
  • 对应 Controller-Manager --enable-garbage-collector 参数
• Concurrent Sync Limiting
  • 避免过多的资源同步导致集群资源的消耗
  • 对应 Controller-Manager 带有 --concurrent 前缀的参数
• All Controllers
  • 列举所有 Kubernetes 所支持的 Controllers，每个 Controller 都与 Kubernetes 特定的功能相关联
  • 对应 Controller-Manager --controllers，该参数注释列举了所有的默认 Controllers

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

• API-Server --max-requests-inflight, --min-request-timeout
• API-Server --watch-cache, --watch-cache-sizes
• Controller-Manager --node-eviction-rate
• Controller-Manager --pod-eviction-timeout
• Controller-Manager --terminated-pod-gc-threshold
• Controller-Manager --pv-recycler-minimum-timeout-*

Node

• Kubelet Eviction
  • 当节点资源不足时，Kubernetes 通过驱逐 Pods 的方式确保节点的稳定性
  • 对应 Kubelet 带有 --eviction- 前缀的参数，例如 --eviction-hard
• Image GC
  • 清理容器镜像占用的磁盘空间
  • 对应 Kubelet 带有 --image-gc- 前缀的参数，以及 --minimum-image-ttl-duration 等参数
• Resource Reserve
  • 为系统资源预留一定的资源，确保节点的稳定性
  • 对应 Kubelet --kube-reserved、--kube-reserved-cgroup 等参数
• CPU Manager
  • 提供更多的 CPU 管理能力，例如静态 CPU 亲和性
  • 对应 Kubelet --cpu-manager-* 前缀的参数
• Storage Limit
  • 避免节点过度挂载数据卷
  • 对应 FeatureGate AttachVolumeLimit

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

• Kubelet & Kubeproxy --hostname-override
• Kubelet --cgroups-per-qos
• Kubelet --fail-swap-on
• Kubelet --host-*
• Kubelet --max-pods, --pods-per-core
• Kubelet --resolv-conf
• Kubeproxy --nodeport-addresses

心法

😇

• 通过组件配置学习 Kubernetes 功能是我们需要具备的一个常规能力，或许比较枯燥，但对我们的修炼大有裨益。
• 如果你对 Kubernetes “无穷无尽”的功能感到有点迷茫，这是一个很正常的现象。除非是深度参与 Kubernetes 的开发，否则一定会有很多遗漏的地方。我们只要保持两个基本点不动摇：1. 懂 Kubernetes 架构和最核心的能力；2. 懂得怎么快速定位我们需要的能力。关于第二点，我们将在大乘期介绍，stay tuned！

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

目标

• 对 Kubernetes 的扩展机制了如指掌
• 可以编写 Kubernetes 控制器，能够基于扩展机制灵活地二次开发

路径

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

API 资源扩展能力

• Annotation：保存少量非结构化第三方数据
• Finalizer：资源删除时，用户调用外部系统的钩子
• CustomResourceDefinition：自定义 Kubernetes API
• API Aggregation：多个 API Server 聚合，适用于较大量的 API 定制

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

• kubebuilder：来自 Kubernetes 官方的 API 扩展项目
• sample-controller：来自 Kubernetes 官方的一个样例
• operator-sdk：来自红帽的一个 operator 库
• shell-operator：适合运维开发使用的 shell operator 库
• meta-controller：来自 Google 的一个更加"傻瓜"式编写控制器的库

API 访问扩展能力

• 认证 Webhook：用户认证时，调用外部服务，仅支持静态配置
• 鉴权 Webhook：用户鉴权时，调用外部服务，仅支持静态配置
• 动态访问控制 Webhook：请求访问控制时，调用外部服务，支持动态增加外部服务

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

调度器扩展能力

• 扩展接口（Scheduler Extender）：类似 Webhook，调用外部服务进行调度决策
• 多调度器：支持在 Kubernetes 运行多个调度器调度不同作业
• 调度器框架：定义一套 Go API，使用户无需 fork Kubernetes Scheduler 代码即可完成“代码级”的定制

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

网络扩展能力

• 网络插件 CNI：使用 CNI 插件，可以选择任何我们需要的网络方案
• 自定义 Ingress 控制器：Ingress 定义了一套 API 接口，我们可以选择任意实现
• 自定义 NetworkPolicy 控制器：同上，可选实现包括 Calico、Cilium 等
• 自定义 DNS 控制器：Kubernetes 定义了一套 DNS 规范，我们可以选择任意实现

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

存储扩展能力

• FlexVolume：Kubernetes 提供的一种动态对接存储方案，支持用户自定义存储后端
• 存储插件 CSI：使用 CSI 插件，可以选择任何我们需要的存储方案

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

运行时扩展能力

• 运行时接口 CRI：使用 CRI 插件，可以选择任何我们需要的运行时方案

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

特殊硬件或资源扩展能力

• 扩展资源 Extended Resource：通过 Kubernetes 原生 API 方式支持添加自定义资源
• 设备插件 Device Plugin：使用 Device Plugin 插件，可以对接任何我们需要的硬件

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

监控扩展能力

• 自定义监控：支持使用自定义监控组件如 Prometheus 提供监控指标

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

云供应商扩展能力

• 云控制器 Cloud Controller Manager：支持可插拔云服务提供商

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

命令行插件

• Kubectl Plugin：kubectl plugin 支持扩展 kubectl 子命令，与 API 扩展能力结合可以提供近乎原生的使用方法。

心法

• 推荐实现一个端到端的 Kubernetes 控制器，可以对整个 Kubernetes 的二次开发有更加深入的了解。此外，针对所有的扩展能力，建议先建立一个全面的认识，再根据需要深入某一项能力。
• 我们除了通过用户手册来学习上面的技术，也可多参考 Kubernetes 的花式设计文档，主要是 Design Proposals、KEPs。

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

目标

• 了解 Kubernetes 生态项目
• 跟踪 Kubernetes 社区发展
• 跟踪 CNCF 社区发展

路径

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

• 如何跟进 Kubernetes 的新功能，以及现有功能的更多细节？
• 如何了解 Kubernetes 整个生态环境的发展？

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

• Helm：作为 Kubernetes 生态里的 brew、dnf、dpkg，Helm 为 Kubernetes 提供了包管理能力，方便用户快速部署安装各种服务。
• Harbor：Harbor 与 Kubernetes 无直接关系，但作为云原生环境下最常用的镜像仓库解决方案，了解 Harbor 十分重要。
• Prometheus：Prometheus 是云原生环境下最重要的监控组件。
• Istio：Istio 是服务网格的关键项目，但较为复杂，可以尝试简单了解。

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

GitHub 仓库

• Kubernetes Enhancement：关注新特性的讨论
• Kubernetes Community：关注社区组织情况
• CNCF TOC：关注 CNCF 进展，各种新项目讨论等
• Awesome Kubernetes：Kubernetes 项目之学不动系列

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

Twitter 账号

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

• Tim Hockin
• Clayton Coleman
• Daniel Smith
• Brian Grant
• Vishnu Kannan
• Saad Ali
• Kelsey Hightower
• Joe Beda
• Brendan Burns
• Michelle Noorali

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

• Kube Weekly
• Kube List

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

Blog 账号

• Kubernetes Blog
• CNCF Blog
• Caicloud Blog

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

心法

🐲

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

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

许可协议

• 本文遵守创作共享 CC BY-NC-SA 3.0 协议
• 商业目的转载，请联系 [email protected]
• 如有任何版权问题，请联系 [email protected] 和 [email protected]

kube-ladder's Issues

[Initiation] Add initial work

/assign

• Owners file
• readme
• kubernetes labs

cargo.caicloud.io dns错误

由于 cargo.caicloud.io 无法解析，导致一些镜像拉取出错：

10月 26 16:10:20 worker-1 kubelet[3824]: E1026 16:10:20.697384 3824 pod_workers.go:190] Error syncing pod c4162aea-6f57-4e45-80ba-ee11f08f9faf ("kube-flannel-ds-amd64-n776j_kube-system(c4162aea-6f57-4e45-80ba-ee11f08f9faf)"), skipping: failed to "CreatePodSandbox" for "kube-flannel-ds-amd64-n776j_kube-system(c4162aea-6f57-4e45-80ba-ee11f08f9faf)" with CreatePodSandboxError: "CreatePodSandbox for pod "kube-flannel-ds-amd64-n776j_kube-system(c4162aea-6f57-4e45-80ba-ee11f08f9faf)" failed: rpc error: code = Unknown desc = failed pulling image "cargo.caicloud.io/caicloud/pause-amd64:3.1": Error response from daemon: Get "https://cargo.caicloud.io/v2/\": dial tcp: lookup cargo.caicloud.io on 114.114.114.114:53: no such host"

希望修复一下

cni 配置缺失

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

What happened:
kube-ladder/tutorials/lab3-manual-installtion.md
少配置了cni，会导致kubelet启动报错
What you expected to happen:
增加如下配置

 mkdir -p /etc/cni/net.d/
 
cat <<EOF> /etc/cni/net.d/10-flannel.conf
{
"name": "cbr0",
"type": "flannel",
"delegate": {
"isDefaultGateway": true
}
} 
EOF

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

lab1中minicube版本是否错误？

您好，我是刚入门的小白一枚， 按lab1流程走时发现”确认你的 minikube 至少是 v1.2.0“， 但我查看最新版本才到v1.12，是原文笔误了吗，还是我理解错误了，求解答，感谢！

minikube

lab2提到的很多的 resource/xxx.yaml 能不能开源一下？

如上

k8s二进制安装缺少网络插件

mkdir -p /opt/cni/bin
cd /opt/cni/bin
wget https://github.com/containernetworking/plugins/releases/download/v0.7.1/cni-plugins-amd64-v0.7.1.tgz
tar -xzvf cni-plugins-amd64-v0.7.1.tgz
rm -rf cni-plugins-amd64-v0.7.1.tgz

kubectl run 不会再创建deployment了。

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind feature

What happened:
按照文档中的安装kubectl时，会安装最新的kubectl，而kubectl 1.18之后，链接中这一步里的kubectl run不再会创建deployment了。困扰了我很久，后来才找到了是版本原因。（而且官方--help里也还是说会创建deploymetn），修改一下吧，以免其他人踩坑。
https://github.com/caicloud/kube-ladder/blob/master/tutorials/lab2-application-and-service.md#create-deployment

What you expected to happen:
修改一下kubectl的安装，或者提示一下吧！

How to reproduce it (as minimally and precisely as possible):
kubectl修改这个特性的pr。kubernetes/kubernetes#87077

Anything else we need to know?:

Fix emojis

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind feature

What happened:

Emojis are not working properly when converting from gdoc to markdown.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

/assign @bbbmj

lab2_answer

lab2-application-and-service

1. 学习 kubectl proxy 命令及其含义。回答如何通过 proxy 访问 kubernetes 集群？

   Kubernetes Proxy API 是一种特殊的 API，Kube-APIServer 只是代理这类 API 的 HTTP 请求，然后将请求转发到某个节点上的 Kubelet 进程监听的端口上。最后实际是由该端口上的 REST API 响应请求。

   • kubectl proxy

     kubectl proxy --port=8080 &
     

     • 现在，你可以使用 Kubernetes Proxy API 进行访问。比如：需要访问一个服务，可以使用 /api/v1/namespaces/<NAMESPACE>/services/<SERVICE-NAME>/proxy/

2. 学习 kubectl port-forward 命令及其含义。回答如何通过 port-forward 访问应用？

   从 Kubernetes v1.10 开始，kubectl port-forward 允许使用资源名称（例如 pod 名称）来选择匹配的 pod 来进行端口转发。

   kubectl port-forward 命令转发了本地端口到 pod 端口的连接。它的手册现在这里可以查看。相比于 kubectl proxy，kubectl port-forward 也可以转发 TCP 流量而 kubectl proxy 只能转发 HTTP 流量。

   • kubectl port-forward redis-master-765d459796-258hz 7000:6379

     这相当于

     kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
     

     或者

     kubectl port-forward deployment/redis-master 7000:6379 
     

     或者

     kubectl port-forward rs/redis-master 7000:6379
     

     或者

     kubectl port-forward svc/redis-master 7000:6379
     

     以上所有命令都应该有效。输出应该类似于：

     I0710 14:43:38.274550    3655 portforward.go:225] Forwarding from      127.0.0.1:7000 -> 6379
     I0710 14:43:38.274797    3655 portforward.go:225] Forwarding from      [::1]:7000 -> 6379
     

3. 修改 Pod label 使其与 Deployment 不相符，集群有什么变化？

   • deployment 会发现少了自己的 pod，重新启动一个拥有自己 label 的 pod；当然，修改的那个 pod 还存在

4. 进一步学习 kubectl run。回答如何向 Pod 注入环境变量？如何查看是否注入成功？

   • kubectl run

     • 通过 kubectl run --env 设置环境变量

     kubectl run nginx-test --image=nginx:1.15.2  --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=onemore" --env="ONE=more" -n onemore
     

     • 可以查看到该 pod template 中的 Environment 有刚才定义的环境变量信息

     kubectl describe -n onemore deployments.apps nginx-test
     

5. 进一步学习 kubectl rollout。回答如何通过 kubectl rollout 将应用回滚到指定版本？

   • 使用 kubectl rollout history deployment/nginx-deployment 查看 deployment 升级历史

     $ kubectl rollout history deployment/nginx-deployment
     deployments "nginx-deployment"
     REVISION  CHANGE-CAUSE
     1         kubectl apply --filename=nginx-test.yml --record=true
     2         kubectl replace --filename=nginx-test.yml --record=true
     

     • 回滚到上一个版本

       kubectl rollout undo deployment/nginx-deployment
       

     • 回滚到指定版本

       kubectl rollout undo deployment/nginx-deployment --to-revision=2
       

     • Note: 如果 CHANGE-CAUSE 为空，那是因为在创建 deployment 时没有使用 --record 选项

6. Pod LivenessProbe 实验中，检查方式采用的是 http 模式。回答如何使用 exec 进行健康检查？请写出 yaml 文件。

   • 参考资料
   • exec_livenessProbe.yaml

     apiVersion: v1
     kind: Pod
     metadata:
       labels:
         test: liveness
       name: liveness-exec
     spec:
       containers:
       - name: liveness
         image: k8s.gcr.io/busybox  
         args:
         - /bin/sh
         - -c
         - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
         livenessProbe:
           exec:
             command:
             - cat
             - /tmp/healthy
           initialDelaySeconds: 5
           periodSeconds: 5
     

7. 进一步学习 Pod Lifecycle。回答如何使用 PostStart Hook？请写出 yaml 文件。

   • 参考资料

     apiVersion: v1
     kind: Pod
     metadata:
       name: test-post-start
     spec:
       containers:
       - name: test-post-start-container
         image: busybox
         command: ["/bin/sh", "-c", "sleep 5 && echo $(date) 'written by         entrypoint' >> log.log && sleep 600"]
         lifecycle:
           postStart:
             exec:
               command: ["/bin/sh", "-c", "sleep 30 && echo $(date) 'written by      post start' >> log.log"]
           preStop:
             exec:
               command: ["/bin/sh", "-c", "sleep 15 && echo $(date) 'written by      post stop' >> log.log"]
     

8. 登录宿主机，使用 docker ps 查看 Pod，如何理解 docker ps 输出？

   • docker ps 会列出所有运行中的容器
   • docker ps –a 会列出所有的容器，不管是运行的，还是停止的

   ---

   10张图带你深入理解Docker容器和镜像

   • docker images 会列出了所有顶层（top-level）镜像
     • 实际上，在这里我们没有办法区分一个镜像和一个只读层，所以我们提出了 top-level 镜像。只有创建容器时使用的镜像或者是直接 pull 下来的镜像能被称为顶层（top-level）镜像，并且每一个顶层镜像下面都隐藏了多个镜像层
   • docker images –a 列出了所有的镜像，也可以说是列出了所有的可读层
     • 要查看某一个 image-id 下的所有层，可以使用 docker history 来查看
   • docker stop 会向运行中的容器发送一个 SIGTERM 的信号，然后停止所有的进程
   • docker kill 向所有运行在容器中的进程发送了一个不友好的 SIGKILL 信号
   • docker pause 它利用了cgroups的特性将运行中的进程空间暂停
     • 具体的内部原理你可以在这里找到：https://www.kernel.org/doc/Doc ... m.txt，但是这种方式的不足之处在于发送一个SIGTSTP信号对于进程来说不够简单易懂，以至于不能够让所有进程暂停。
   • docker rm 会移除构成容器的可读写层
     • [注意，这个命令只能对非运行态容器执行]
   • docker rmi 会移除构成镜像的一个只读层
     • 你只能够使用 docker rmi 来移除最顶层（top level layer）（也可以说是镜像），你也可以使用 -f 参数来强制删除中间的只读层
   • docker commit 将容器的可读写层转换为一个只读层，这样就把一个容器转换成了不可变的镜像
   • docker build 非常有趣，它会反复的执行多个命令
   • docker exec 会在运行中的容器执行一个新进程
   • docker inspect 会提取出容器或者镜像最顶层的元数据
   • docker save 会创建一个镜像的压缩文件，这个文件能够在另外一个主机的 Docker 上使用
     • 和 export 命令不同，这个命令为每一个层都保存了它们的元数据。这个命令只能对镜像生效
   • docker export 创建一个 tar 文件，并且移除了元数据和不必要的层，将多个层整合成了一个层，只保存了当前统一视角看到的内容
   • docker history 递归地输出指定镜像的历史镜像

9. 学习使用 Secret，然后创建一个 Secret 并在 Pod 内访问。请写出 secret 和 pod 的 yaml 文件。

   • 创建 secret

     • game.properties

       enemies=aliens
       lives=3
       enemies.cheat=true
       enemies.cheat.level=noGoodRotten
       secret.code.passphrase=UUDDLRLRBABAS
       secret.code.allowed=true
       secret.code.lives=30
       

       kubectl create secret generic game-secret --from-file=game.properties
       

     • pod_secret.yaml

       apiVersion: v1
       kind: Pod
       metadata:
         name: pod-secret
       spec:
         restartPolicy: Never
         containers:
           - name: test-container
             image: busybox:1.26
             command: ["/bin/sh"]
             args: ["-c", "cat /etc/config/game.properties && sleep 60"]
             volumeMounts:
             - name: config-volume
               mountPath: /etc/config
             resources:
               requests:
                 cpu: "0.1"
                 memory: "100Mi"
               limits:
                 cpu: "0.1"
                 memory: "100Mi"
         volumes:
           - name: config-volume
             secret:
               secretName: game-secret
       

10. ConfigMap 实验中，我们采用文件加载的方式使用 ConfigMap。请写出利用环境变量加载 configmap 的例子。

    • 创建 configmap

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: demo-configmap-1
        namespace: xxx
      data:
        DEPLOYMENT_ENV: test
      

    • 利用环境变量加载 configmap

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: xxx
        namespace: xxx
        labels:
          app: xxx
      spec:
        strategy:
          type: Recreate
        selector:
          matchLabels:
            app: xxx
        template:
          metadata:
            labels:
              app: xxx
          spec:
            containers:
            - name: demo
              image: xxx/demo:0.0.1
              imagePullPolicy: IfNotPresent
              args: ["--spring.profiles.active=$(DEPLOYMENT_ENV_KEY)"]
              ports:
              - containerPort: 8080
              env:
              - name: DEPLOYMENT_ENV_KEY
                valueFrom:
                  configMapKeyRef:
                    name: demo-configmap-1
                    key: DEPLOYMENT_ENV
      

萌新问题

照着lab3-manual-installtion文档，手动安装了集群，基本跑得通，途中遇到2个问题

1. 不知道为啥需要手动创建clusterRolebinging，绑定system:node角色到system:nodes组，不然node节点没有权限list资源
2. flannel 以及 coreDNS 内部镜像是内部仓库地址的，若docker没登录会导致镜像拉取失败

Add more concepts to lab4

/assign

Caicloud 招聘

招聘岗位

• 云平台软件工程师
• 产品经理

工作地点：杭州，上海，成都，北京

---

云平台软件工程师

薪资：15k-40k

经验：1-3 年 /3-5 年 /5-10 年

学历：本科及以上

工作地点：杭州、上海、成都，北京

负责才云容器平台的各类后端系统和组件的设计、开发、维护工作；

任职要求：

• 1-3 年 /3-5 年 /5-10 年以上后端开发经验；
• 熟悉计算机体系结构、数据结构和算法、操作系统、数据库、网络等基础原理；
• 精通 Golang 或至少一类后端编程语言（ C++/JAVA/Python 等）且具备快速转向 Golang 的能力；
• 熟悉各类开源类库、数据库、中间件的开发使用；
• 有分布式的软件架构设计、开发和运维经验，能快速定位和调试问题；
• 有良好的测试习惯以保证高质量软件的产出；
• 优秀的沟通协作能力、分析解决问题能力和学习能力；
• [加分项] 熟悉 docker、kubernetes 及相关云原生系统的优先；

---

产品经理

薪资：15k-40k

经验：1-3/3-5

学历：本科及以上

工作地点：杭州

• 参与云平台整体产品的策划，根据市场及用户反馈，制定产品线路、落实项目方案；
• 负责产品的生命周期管理，包括需求搜集、版本规划、设计研发、客户落地、持续运营、迭代改进产品等，达成业务目标；
• 同开发团队、销售团队、运营团队紧密合作，协调不同岗位人员的工作，推动产品发展；
• 参与产品的测试、验收，需要为产品的整体质量负责；
• 跟进产品关键数据指标，用户反馈，制定产品的迭代计划；

任职要求：

• 有产品经理相关经验，具有很强的责任心；
• 对云计算行业有较深刻理解、思维活跃、调理清晰，有较高的逻辑分析和理解能力；
• 良好的写作能力、书面交流能力、沟通能力、团队协作能力；
• 保持热情，在日常工作中始终保持积极主动的态度，抗压能力强；
• 熟悉虚拟化、网络、存储等云计算相关技术；
• 加分项：有 Docker 使用经验，熟悉 Kubernetes, Mesos 架构者优先考虑；有有良好英文读写能力者，优先考虑；

---

简历投递方式

网站： https://caicloud.io/jobs

邮箱： [email protected]

感谢阅读，期待加入

kubectl run 的背后流程中文版

你好，这是我翻译的 ”kubectl run 的背后流程“ 中文版，可以考虑收录：https://mp.weixin.qq.com/s/ctdvbasKE-vpLRxDJjwVMw

镜像失效了

拉取镜像时，报此错误

Error response from daemon: Get "https://cargo.caicloud.io/v2/": x509: certificate is not valid for any names, but wanted to match cargo.caicloud.io

Add more effective link

/assign

issue

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug
/kind feature

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Frt

Asass

Translate lab1 to Chinese

/assign

/meow