Kubernetes 构建工具浅析-阿里云开发者社区

Kubernetes 集群的组件众多，要部署一套符合生产环境的集群并不是一件容易的事。不过随着云原生生态的逐渐成熟、社区的快速发展，特别是在它成为事实上的容器编排标准以后，基本所有的主流云平台都完全支持 Kubernetes，或把它作为核心的云解决方案。同时，本地部署也伴随着出现了各类成熟的主动化解决方案。

因此，当我们计划或者开始使用 Kubernetes 时，我们都应该尝试问自己一个问题：“我该如何进行第一次的部署？”。

在本文中，笔者将向大家介绍 4 种不同的技术，大家可以基于此 4 种不同的构建工具在自己的计算机上使用 Kubernetes。对于每一个，笔者尽可能都会对解决方案进行简短描述，并对其优缺点进行分析，以帮助大家能够对 Kubernetes 的有所了解。

Minikube

Minikube 是由 Kubernetes 社区维护的单机版的 Kubernetes 集群，其支持 macOS, Linux 、以及 Windows 等多种操作系统平台，基于其最新的官方 Stable 版本，并开始支持 Kubernetes 的大部分功能，从基础的容器编排管理，到高级特性如负载均衡、Ingress，权限控制等。非常适合作为 Kubernetes入门，或开发测试环境使用。

Minikube 支持以下 Kubernetes 功能：DNS、NodePorts、ConfigMaps 和 Secrets、Dashboards、容器运行时: Docker、CRI-O 以及 containerd、启用 CNI （容器网络接口）以及 Ingress 等等。其架构示意图如下所示：

下面我们以 Mac 环境为例，简要描述下 Minikube 相关部署过程，具体如下所示：

[administrator@JavaLangOutOfMemory ~ ]% /bin/zsh -c "$(curl -fsSL https://gitee.com/cunkai/HomebrewCN/raw/master/Homebrew.sh)"

[administrator@JavaLangOutOfMemory ~ ]% brew install minikube

[administrator@JavaLangOutOfMemory ~ ]% minikubestart

当然，我们还可以自定义参数进行启动，具体如下所示：

[administrator@JavaLangOutOfMemory ~ ]%  minikube start --iso-url=https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/iso/minikube-v1.x.x.iso
                 --registry-mirror=https://registry.docker-cn.com
                 --image-mirror-country=cn
                 --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers
                 --vm-driver=none
                 --memory=4096

部署完成后，检测相关配置参数等。

[administrator@JavaLangOutOfMemory ~ ]% kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.2", GitCommit:"092fbfbf53427de67cac1e9fa54aaa09a28371d7", GitTreeState:"clean", BuildDate:"2021-06-16T12:52:14Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.7", GitCommit:"132a687512d7fb058d0f5890f07d4121b3f0a2e2", GitTreeState:"clean", BuildDate:"2021-05-12T12:32:49Z", GoVersion:"go1.15.12", Compiler:"gc", Platform:"linux/amd64"}

[administrator@JavaLangOutOfMemory ~ ]% kubectl get node -o wide
NAME       STATUS   ROLES                  AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION     CONTAINER-RUNTIME
minikube   Ready    control-plane,master   15h   v1.20.7   192.168.49.2   <none>        Ubuntu 20.04.2 LTS   5.10.25-linuxkit   docker://20.10.7
[administrator@JavaLangOutOfMemory ~ ]% kubectl get pod -A
NAMESPACE     NAME                               READY   STATUS    RESTARTS   AGE
kube-system   coredns-74ff55c5b-p6dlz            1/1     Running   0          15h
kube-system   etcd-minikube                      1/1     Running   0          15h
kube-system   kube-apiserver-minikube            1/1     Running   0          15h
kube-system   kube-controller-manager-minikube   1/1     Running   0          15h
kube-system   kube-proxy-dcr72                   1/1     Running   0          15h
kube-system   kube-scheduler-minikube            1/1     Running   0          15h
kube-system   storage-provisioner                1/1     Running   3          15h

Minikube 是一个 Kubernetes-SIGs 项目，其实现方法为生成一个实质上是单节点K8s 集群的 VM。由于对一系列管理程序的支持，它可以在所有主要操作系统上使用。还允许并行创建多个实例。基于用户的角度而言，Minikube 是一款非常适合初学者的工具。使用 minikube start 命令行启动集群，几分钟后 Kubectl 就可以开始了。若要指定特定的 Kubernetes 版本，可以使用--Kubernetes version 标志参数即可。

Kind

Kind 即 “Kubernetes In Docker” 的缩写，顾名思义是使用 Docker 容器作为 Node 并将 Kubernetes 部署至其中的一个工具。官方文档中也把 Kind 作为一种本地集群搭建的工具进行推荐。Kind 是一个命令行工具，可帮助我们基于 Docker 镜像创建本地 Kubernetes 集群，使其能够模拟本地系统上的 Kubernetes 集群。

Kind 是另一个 Kubernetes SIGs 项目，但与 Minikube 相比有很大不同。顾名思义，它将集群移动到 Docker 容器中。与生成 VM 相比，这将显著加快启动速度。创建集群与 Minikube 的方法非常相似。执行类创建集群。通过使用不同的名称（-name）kind，可以并行创建多个实例。其架构示意图如下所示：

与 Minikube 类似，简要描述一下其部署过程，具体如下所示：

[administrator@JavaLangOutOfMemory ~ ]% brew install kind
==> Downloading https://mirrors.ustc.edu.cn/homebrew-bottles/bottles/kind-0.11.1.big_sur.bottle.tar.gz
######################################################################## 100.0%
==> Pouring kind-0.11.1.big_sur.bottle.tar.gz
==> Caveats
zsh completions have been installed to:
  /usr/local/share/zsh/site-functions
==> Summary
  /usr/local/Cellar/kind/0.11.1: 8 files, 8.4MB

[administrator@JavaLangOutOfMemory ~ ]% kind version 
kind v0.11.1 go1.16.4 darwin/amd64                                                                              kind v0.11.1 go1.16.4 darwin/amd64

接下来，将下面的配置内容保存至一个 YAML 文件中，比如名为 kind-config.yaml，具体如下所示：

kind: Cluster
apiVersion: kind.sigs.k8s.io/v1alpha3
kubeadmConfigPatches:
- |
  apiVersion: kubeadm.k8s.io/v1beta1
  kind: ClusterConfiguration
  metadata:
    name: config
  networking:
    serviceSubnet: 10.0.0.1/16
  imageRepository: registry.aliyuncs.com/google_containers
  nodeRegistration:
    kubeletExtraArgs:
      pod-infra-container-image: registry.aliyuncs.com/google_containers/pause:3.1
- |
  apiVersion: kubeadm.k8s.io/v1beta1
  kind: InitConfiguration
  metadata:
    name: config
  networking:
    serviceSubnet: 10.0.0.1/16
  imageRepository: registry.aliyuncs.com/google_containers
nodes:
- role: control-plane

[administrator@JavaLangOutOfMemory ~ ]% Kind create cluster --name demo-cls --config kind.yaml
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.21.1) 🖼
 ✓ Preparing nodes 📦
 ✓ Creating kubeadm config 📜
 ✓ Starting control-plane 🕹️
Cluster creation complete. You can now use the cluster with:
export KUBECONFIG="$(kind get kubeconfig-path --name="demo-cls")"
kubectl cluster-info

基于此解决方案，允许我们部署所有类型的集群：例如：单节点、1个 Master 和几个 Worker 以及多个 Master 和多个 Worker。不仅如此，这些集群非常容易部署。通常可以借助一个非常简单的 YAML 文件完成。

从本质上而言，Kind 并不是打包一个虚拟化镜像，而是直接将基于 K8S 组件运行在 Docker 环境。那么，此种模式能够带来了哪些好处呢？具体主要涉及以下方面：

1、不需要运行 Guest OS ，占用资源更低。

2、不基于虚拟化技术，可以在 VM 中使用。

3、文件更小，更利于移植。

K3s

基于其简单性。作为一个单一的二进制文件（约100MB）进行打包和部署，我们只需几秒钟就可以得到一个完全成熟的 Kubernetes 集群。安装体验就像在集群的每个节点上运行一个脚本一样简单。

基于其二进制文件封装实体，K3s 几乎运行了 Kubernetes 集群的所有组件，包括API server、Scheduler 和 Controller。默认情况下，每个 K3s 的安装都包括控制平面、Kubelet 和 Containerd运行时，这些已经足以运行 Kubernetes 工作负载。当然，也可以添加只运行 Kubelet Agent 和 Containerd 运行时的专用 Worker 节点，来调度和管理 Pod 生命周期。

与传统的 Kubernetes 集群相比，K3s 中的 Master 节点和 Worker 节点并没有明显的区别。可以在任何节点上调度和管理 Pod，不管它们扮演的是什么角色。所以，Master 节点和 Worker 节点的命名方式不适用于 K3s 集群。

在 K3s 集群中，将运行控制平面组件与Kubelet的节点称为 Server，而只运行 Kubelet 的节点称为 Agent。Server 和 Agent 都有容器运行时和一个 Kubeproxy ，管理整个集群的 Tunnel 和网络流量。其单节点架构示意图如下所示：

源自官网（同下）

K3s 单节点集群的架构如上图所示，该集群有一个内嵌 SQLite 数据库的单节点 K3s Server。在这种配置中，每个 Agent 节点都注册到同一个 Server 节点。K3s 用户可以通过调用 Server 节点上的 K3s API 来操作 Kubernetes 资源。

虽然单节点 k3s 集群可以满足各种用例，但对于 Kubernetes Control-Plane 的正常运行至关重要的环境，我们可以在高可用配置中运行 K3s。一个高可用 K3s 集群由以下几个部分组成：

1、K3s Server 节点：两个或更多的 Server 节点将为 Kubernetes API 提供服务并运行其他 Control-Plane 服务

2、外部数据库：与单节点 k3s 设置中使用的嵌入式 SQLite 数据存储相反，高可用 K3s 需要挂载一个 External Database 外部数据库作为数据存储的媒介。

其高可用架构示意图如下所示：

相对于上述的组件工具，K3s 部署起来较为简单，毕竟其已经被作为集成的组件进行部署运行，具体可参考如下命令行所示：

[administrator@JavaLangOutOfMemory ~ ]% curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh -

Kubeadm

Kubeadm 是一个基于 Kubeadm init 和 Kubeadm join 的工具组件，提供了一个创建 Kubernetes 集群的 “快捷途径” 的最佳实践。其通过执行必要的操作来启动和运行最小可用集群。依据其设计理念，仅关注启动引导，而非配置机器。同样的，安装各种 “锦上添花” 的扩展，例如 Kubernetes Dashboard、监控方案、以及特定云平台的扩展，都不在讨论范围内。理想情况下，使用 Kubeadm 作为所有部署工作的基准将会更加易于创建一致性集群。

其参考架构示意图如下所示：