参考：Kubernetes 入门实战课 | 极客时间 (opens new window) 9-10 讲

1. 在本地搭建小巧完备的 Kubernetes

容器编排（Container Orchestration）的事实标准就是专栏的主角——Kubernetes。

1.1 什么是 Kubernetes？

Google 发表 Borg 论文的同时，并将其用 Golang 重写，诞生了 Kubernetes，同时 Google 又联合 Linux 基金会成立了 CNCF（Cloud Native Computing Foundation，云原生基金会），并将 Kubernetes 作为种子项目，汇集了众多精英，打败了 Apache Mesos 和 Docker Swarm，成为了这个领域的唯一霸主。

Kubernetes 是一个生产级别的容器编排平台和集群管理系统，不仅能够创建、调度容器，还能够监控、管理服务器。

1.2 什么是 minikube？

minikube 小而美，便于初学者学习，可执行文件仅有不到100MB，运行镜像也不过1GB，但就在这么小的空间里却集成了Kubernetes的绝大多数功能特性，不仅有核心的容器编排功能，还有丰富的插件，例如Dashboard、GPU、Ingress、Istio、Kong、Registry等等，综合来看非常完善。

1.3 搭建 minikube

可以在 minikube 官网下载安装包，如下是官网命令的拷贝：

# Intel x86_64
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

# Apple arm64
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-arm64

sudo install minikube /usr/local/bin/

安装完成之后，你可以执行命令 minikube version，看看它的版本号，验证是否安装成功。

$ minikube version
minikube version: v1.30.1
commit: 08896fd1dc362c097c925146c4a0d0dac715ace0

不过 minikube 只能够搭建Kubernetes环境，要操作 Kubernetes，还需要另一个专门的客户端工具：kubectl，它也是一个命令行工具，用于与 Kubernetes 后台通信，实现容器和集群的管理功能。

kubectl 是一个与 Kubernetes、minikube 彼此独立的项目，所以不包含在 minikube 里，但 minikube 提供了安装它的简化方式，你只需执行下面的这条命令：

minikube kubectl

便会自动与当前 Kubernetes 版本匹配的 kubectl 下载下来，并存到内部目录中，然后我们就可以使用它来对Kubernetes“发号施令”了。

所以，在minikube环境里，我们会用到两个客户端：minikube 管理 Kubernetes 集群环境，kubectl 操作实际的 Kubernetes 功能。如下是 minikube 的环境示意图：

1.4 实际验证 minikube 环境

现在我们可以在本机上运行 minikube 来创建 Kubernetes 环境了。

使用命令 minikube start 会从 Docker Hub 上拉取镜像，以当前最新版本的 Kubernetes 启动集群。不过为了保证实验环境的一致性，我们可以在后面再加上一个参数 --kubernetes-version，明确指定要使用 Kubernetes 版本：

$ minikube start --kubernetes-version=v1.23.3

😄  minikube v1.30.1 on Ubuntu 20.04 (amd64)
❗  minikube skips various validations when --force is supplied; this may lead to unexpected behavior
✨  Automatically selected the docker driver. Other choices: none, ssh
🛑  The "docker" driver should not be used with root privileges. If you wish to continue as root, use --force.
💡  If you are running minikube within a VM, consider using --driver=none:
📘    https://minikube.sigs.k8s.io/docs/reference/drivers/none/

🧯  The requested memory allocation of 1987MiB does not leave room for system overhead (total system memory: 1987MiB). You may face stability issues.
💡  Suggestion: Start minikube with less memory allocated: 'minikube start --memory=1987mb'

📌  Using Docker driver with root privileges
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
💾  Downloading Kubernetes v1.23.3 preload ...
    > preloaded-images-k8s-v18-v1...:  400.43 MiB / 400.43 MiB  100.00% 11.87 M
    > index.docker.io/kicbase/sta...:  373.53 MiB / 373.53 MiB  100.00% 2.31 Mi
❗  minikube was unable to download gcr.io/k8s-minikube/kicbase:v0.0.39, but successfully downloaded docker.io/kicbase/stable:v0.0.39 as a fallback image
🔥  Creating docker container (CPUs=2, Memory=1987MB) ...
🐳  Preparing Kubernetes v1.23.3 on Docker 23.0.2 ...
❌  Unable to load cached images: loading cached images: stat /root/.minikube/cache/images/amd64/registry.k8s.io/coredns/coredns_v1.8.6: no such file or directory
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
💡  kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

现在Kubernetes集群就已经在我们本地运行了，你可以使用 minikube status、 minikube node list 这两个命令来查看集群的状态：

$ minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

$ minikube node list
minikube        192.168.49.2

从截图里可以看到，Kubernetes 集群里现在只有一个节点，名字就叫“minikube”，类型是“Control Plane”，里面有 host、kubelet、apiserver 三个服务，IP 地址是 192.168.49.2。

你还可以用命令 minikube ssh 登录到这个节点上，虽然它是虚拟的，但用起来和实机也没什么区别。

接下来我们可以使用 kubectl 来操作了，但 minikube 自带的 kubectl 与正常的有一点形式的区别，需要在命令前面加上 minikube 的前缀，后面再有个 --，像这样：

minikube kubectl -- version

为了方便，我们使用 Linux 的 alias 来为这个复杂的命令创建别名（写在 ~/.bashrc）中：

alias kubectl="minikube kubectl --"

然后 source ~/.bashrc 使其生效。

另外 kubectl 提供了命令自动补全功能，运行如下命令即可：

source <(kubectl completion bash)

现在，我们就可以愉快地使用 kubectl 了：

$ kubectl version --short
Client Version: v1.23.3
Server Version: v1.23.3

下面我们在 Kubernetes 上运行一个 Nginx 应用，命令与 Docker 一样，也是 run，不过形式上有一点区别，需要用 --image 来指定镜像，然后 Kubernetes 会自动拉取并运行：

$ kubectl run ngx --image=nginx:alpine
pod/ngx created

这里涉及 Kubernetes 里的一个非常重要的概念：Pod，你可以暂时把它理解成是“穿了马甲”的容器，查看Pod列表需要使用命令 kubectl get pod，它的效果类似 docker ps：

$ kubectl get pod
NAME   READY   STATUS    RESTARTS   AGE
ngx    1/1     Running   0          26s

kubectl 与 docker 命令类似，也可以拉取镜像运行，但操作的不是简单的容器，而是 Pod。

另外还要说一下 Kubernetes 的官网 https://kubernetes.io/zh/ (opens new window)，里面有非常详细的文档，包括概念解释、入门教程、参考手册等等，最难得的是它有全中文版本，我们阅读起来完全不会有语言障碍，希望你有时间多上去看看，及时获取官方第一手知识。

2. 自动化的运维管理：探究 Kubernetes 工作机制的奥秘

这一节就来看一下 Kubernetes 的内部架构和工作机制，了解它能傲视群雄的秘密所在。

2.1 云计算时代的操作系统

Kubernetes 管理了资源、服务，从某种角度来看，它可以说是一个集群级别的操作系统，主要功能就是资源管理和作业调度。Kubernetes 这个操作系统与 Linux 还有一点区别你值得注意。Linux 的用户通常是两类人：Dev 和 Ops，而在 Kubernetes 里则只有一类人：DevOps。

由于云原生的兴起，开发人员从一开始就必须考虑后续的部署运维工作，而运维人员也需要在早期介入开发，才能做好应用的运维监控工作。

2.2 Kubernetes 的基本架构

Kubernetes 的架构图如下图所示：

Kubernetes 采用了现今流行的“控制面/数据面”（Control Plane / Data Plane）架构，集群里的计算机被称为“节点”（Node），可以是实机也可以是虚机，少量的节点用作控制面来执行集群的管理维护工作，其他的大部分节点都被划归数据面，用来跑业务应用。

• Control Plan 的节点叫做 Master Node，一般简称 Master，可以说是 Kubernetes 的大脑和心脏。
• Data Plan 的节点叫做 Worker Node，一般简称 Worker 或 Node，相当于 Kubernetes 的手和脚，在 Master 的指挥下干活。

Node 的数量非常多，构成了一个资源池，Kubernetes 就在这个池里分配资源，调度应用。因为资源被“池化”了，所以管理也就变得比较简单，可以在集群中任意添加或者删除节点。

在这张架构图里，我们还可以看到有一个 kubectl，它就是 Kubernetes 的客户端工具，用来操作 Kubernetes，但它位于集群之外，理论上不属于集群。可以使用命令 kubectl get node 来查看 k8s 的节点状态：

$ kubectl get node
NAME       STATUS   ROLES                  AGE   VERSION
minikube   Ready    control-plane,master   93m   v1.23.3

可以看到当前的 minikube 集群里只有一个 Master，那 Node 怎么不见了？这是因为 Master 和 Node 的划分不是绝对的。当集群的规模较小，工作负载较少的时候，Master 也可以承担 Node 的工作，就像我们搭建的 minikube 环境，它就只有一个节点，这个节点既是 Master 又是 Node。

2.3 节点内部的结构

Kubernetes 的节点内部也具有复杂的结构，是由很多的模块构成的，这些模块又可以分成组件（Component）和插件（Addon）两类：

• 组件实现了 Kubernetes 的核心功能特性，没有这些组件 Kubernetes 就无法启动；
• 插件则是 Kubernetes 的一些附加功能，属于“锦上添花”，不安装也不会影响 Kubernetes 的正常运行。

接下来我先来讲讲 Master 和 Node 里的组件，然后再捎带提一下插件，理解了它们的工作流程，你就会明白为什么 Kubernetes 有如此强大的自动化运维能力。

2.3.1 Master 里的组件有哪些？

Master 里有 4 个组件，分别是 apiserver、etcd、scheduler、controller-manager。

• apiserver：整个 Kubernetes 系统的唯一入口，它对外公开了一系列的 RESTful API，并且加上了验证、授权等功能，所有其他组件都只能和它直接通信，可以说是 Kubernetes 里的联络员。
• etcd：一个高可用的 KV 数据库，用来持久化存储系统里的各种资源对象和状态。注意它只与 apiserver 有直接联系，也就是说任何其他组件想要读写 etcd 里的数据都必须经过 apiserver。
• scheduler：负责容器的编排工作，检查节点的资源状态，把 Pod 调度到最适合的节点上运行，相当于部署人员。因为节点状态和 Pod 信息都存储在 etcd 里，所以 scheduler 必须通过 apiserver 才能获得。
• controller-manager：负责维护容器和节点等资源的状态，实现故障检测、服务迁移、应用伸缩等功能，相当于监控运维人员。同样地，它也必须通过 apiserver 获得存储在 etcd 里的信息，才能够实现对资源的各种操作。

这4个组件也都被容器化了，运行在集群的 Pod 里，我们可以用 kubectl 来查看它们的状态，使用命令：

$ kubectl get pod -n kube-system
NAME                               READY   STATUS             RESTARTS   AGE
coredns-64897985d-64hv8            1/1     Running            0          100m
etcd-minikube                      1/1     Running            0          100m
kube-apiserver-minikube            1/1     Running            0          100m
kube-controller-manager-minikube   1/1     Running            0          100m
kube-proxy-r2b4g                   1/1     Running            0          100m
kube-scheduler-minikube            1/1     Running            0          100m
storage-provisioner                0/1     ImagePullBackOff   0          100m

2.3.2 Node 里的组件有哪些？

Master里的apiserver、scheduler等组件需要获取节点的各种信息才能够作出管理决策，那这些信息该怎么来呢？这就需要Node里的3个组件了，分别是 kubelet、kube-proxy、container-runtime：

• kubelet：Node 的代理，负责管理 Node 相关的绝大部分操作，Node 上只有它能够与 apiserver 通信，实现状态报告、命令下发、启停容器等功能，相当于是 Node 上的一个“小管家”。
• kube-proxy：Node 的网络代理，只负责管理容器的网络通信，简单来说就是为 Pod 转发 TCP/UDP 数据包，相当于是专职的“小邮差”。
• container-runtime：它是容器和镜像的实际使用者，通常为 Docker，在 kubelet 的指挥下创建容器，管理 Pod 的生命周期，是真正干活的“苦力”。

我们一定要注意，因为 Kubernetes 的定位是容器编排平台，所以它没有限定 container-runtime 必须是 Docker，完全可以替换成任何符合标准的其他容器运行时，例如 containerd、CRI-O 等等，只不过在这里我们使用的是 Docker。

这3个组件中只有 kube-proxy 被容器化了，而 kubelet 因为必须要管理整个节点，容器化会限制它的能力，所以它必须在 container-runtime 之外运行。

使用 minikube ssh 命令登录到节点后，可以用 docker ps 看到 kube-proxy：

$ minikube ssh
Last login: Sat Apr 22 11:43:55 2023 from 192.168.49.1

docker@minikube:~$ docker ps | grep kube-proxy
2089b7b713b1   9b7cc9982109           "/usr/local/bin/kube…"   2 hours ago      Up 2 hours                k8s_kube-proxy_kube-proxy-r2b4g_kube-system_86dd0c2b-f392-4327-82b8-32422e441a75_0
4d3598fc2131   k8s.gcr.io/pause:3.6   "/pause"                 2 hours ago      Up 2 hours                k8s_POD_kube-proxy-r2b4g_kube-system_86dd0c2b-f392-4327-82b8-32422e441a75_0

而 kubelet 用 docker ps 是找不到的，需要用操作系统的 ps 命令：

ps -ef | grep kubelet

现在，我们再把 Node 里的组件和 Master 里的组件放在一起来看，就能够明白 Kubernetes 的大致工作流程了：

• 每个 Node 上的 kubelet 会定期向 apiserver 上报节点状态，apiserver 再存到 etcd 里。
• 每个 Node 上的 kube-proxy 实现了 TCP/UDP 反向代理，让容器对外提供稳定的服务。
• scheduler 通过 apiserver 得到当前的节点状态，调度 Pod，然后 apiserver 下发命令给某个 Node 的 kubelet，kubelet 调用 container-runtime 启动容器。
• controller-manager 也通过 apiserver 得到实时的节点状态，监控可能的异常情况，再使用相应的手段去调节恢复。

其实，这和我们在 Kubernetes 出现之前的操作流程也差不了多少，但 Kubernetes 的高明之处就在于把这些都抽象化规范化了。于是，这些组件就好像是无数个不知疲倦的运维工程师，把原先繁琐低效的人力工作搬进了高效的计算机里，就能够随时发现集群里的变化和异常，再互相协作，维护集群的健康状态。

2.3.3 插件（Addons）有哪些？

只要服务器节点上运行了 apiserver、scheduler、kubelet、kube-proxy、container-runtime 等组件，就可以说是一个功能齐全的 Kubernetes 集群了。

不过就像Linux一样，操作系统提供的基础功能虽然“可用”，但想达到“好用”的程度，还是要再安装一些附加功能，这在Kubernetes里就是插件（Addon）。由于Kubernetes本身的设计非常灵活，所以就有大量的插件用来扩展、增强它对应用和集群的管理能力。

minikube也支持很多的插件，使用命令 minikube addons list 就可以查看插件列表：

插件中我个人认为比较重要的有两个：DNS 和 Dashboard。

• DNS 在 Kubernetes 集群里实现了域名解析服务，能够让我们以域名而不是 IP 地址的方式来互相通信，是服务发现和负载均衡的基础。由于它对微服务、服务网格等架构至关重要，所以基本上是 Kubernetes 的必备插件。
• Dashboard 就是仪表盘，为 Kubernetes 提供了一个图形化的操作界面，非常直观友好，虽然大多数 Kubernetes 工作都是使用命令行 kubectl，但有的时候在 Dashboard 上查看信息也是挺方便的。

你只要在 minikube 环境里执行一条简单的命令，就可以自动用浏览器打开 Dashboard 页面，而且还支持中文：

minikube dashboard

2.4 小结

小结一下这一节的要点：

1. Kubernetes 能够在集群级别管理应用和服务器，可以认为是一种集群操作系统。它使用“控制面/数据面”的基本架构，Master 节点实现管理控制功能，Worker 节点运行具体业务。
2. Kubernetes 由很多模块组成，可分为核心的组件和选配的插件两类。
3. Master 里有 4 个组件，分别是 apiserver、etcd、scheduler、controller-manager。
4. Node 里有 3 个组件，分别是 kubelet、kube-proxy、container-runtime。
5. 通常必备的插件有 DNS 和 Dashboard。

课外小贴士：

• 为确保控制面的高可用，Kubernetes 集群里都会部署多个 Master 节点，数量一般会是奇数 (3/5/7)，这是由 etcd 的特性决定的。
• etcd 由 CoreOS 公司开发，基于类 Paxos 的 Raft 算法实现数据一致性。
• controller-manager 是很多个 controller 的集合体每一个 controller 负责一种控制循环 (如 node con-troller、namespace controller)，但为了简化被合并在一个进程里执行。
• minikube 的 Dashboard 只允许在本机运行的浏览器访问，不过你也可以给它配置 Nginx 反向代理。