Kubernetes 的安装与基本架构

走进云原生：在本机搭建 Kubernetes 小集群

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

安装环境

• minicube
  • kind 和 minikube，它们都可以在本机上运行完整的Kubernetes环境。
  • minikube最大特点就是“小而美”，可执行文件仅有不到100MB，运行镜像也不过1GB，但就在这么小的空间里却集成了Kubernetes的绝大多数功能特性，不仅有核心的容器编排功能，还有丰富的插件，例如Dashboard、GPU、Ingress、Istio、Kong、Registry等等，综合来看非常完善。
  • minikube只能够搭建Kubernetes环境
• kubectl
  • 用来操作Kubernetes的客户端工具
  • kubectl的作用有点类似之前我们学习容器技术时候的工具“docker”，它也是一个命令行工具，作用也比较类似，同样是与Kubernetes后台服务通信，把我们的命令转发给Kubernetes，实现容器和集群的管理功能。

所以，在minikube环境里，我们会用到两个客户端：minikube管理Kubernetes集群环境，kubectl操作实际的Kubernetes功能，和Docker比起来有点复杂。

实际验证 minikuybe 环境

前面的工作都做完之后，我们就可以在本机上运行minikube，创建Kubernetes实验环境了。

使用命令 minikube start 会从Docker Hub上拉取镜像时，命令：minikube start --kubernetes-version=v1.23.3 会出现问题，

The "docker" driver should not be used with root privileges. (无法用 root 权限执行 docker 驱动)

因为不能用 root 权限启动 minikube。对命令指定一些参数就可以了，命令改为如下：

 minikube start --kubernetes-version=v1.23.3 --driver=docker --container-runtime=containerd --image-mirror-country=cn --force

参考博客 (opens new window)

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

minikube status
minikube node list

在Kubernetes里运行一个Nginx应用

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

kubectl run ngx --image=nginx:alpine

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

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

关于云原生

所谓的“云”，现在就指的是Kubernetes，那么“云原生”的意思就是应用的开发、部署、运维等一系列工作都要向Kubernetes看齐，使用容器、微服务、声明式API等技术，保证应用的整个生命周期都能够在Kubernetes环境里顺利实施，不需要附加额外的条件。

换句话说，“云原生”就是Kubernetes里的“原住民”，而不是从其他环境迁过来的“移民”。

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

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

云计算时代的操作系统

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

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

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。

节点内部的结构

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

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

(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 里的信息，才能够实现对资源的各种操作。

API 对象就被 apiserver 存储在数据库 etcd 里，然后 kubelet、scheduler、controller-manager 等组件通过 apiserver 来操作它们，就在API对象这个抽象层次实现了对整个集群的管理。

这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) 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 的高明之处就在于把这些都抽象化规范化了。于是，这些组件就好像是无数个不知疲倦的运维工程师，把原先繁琐低效的人力工作搬进了高效的计算机里，就能够随时发现集群里的变化和异常，再互相协作，维护集群的健康状态。

(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

小结

小结一下这一节的要点：

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 反向代理。