书籍来源：《Kubernetes进阶实战（第2版）》
一边学习一边整理读书笔记，并与大家分享，侵权即删，谢谢支持！
附上汇总贴：Kubernetes进阶自学系列 | 汇总_COCOgsta的博客-CSDN博客
作为一个典型的分布式项目，Kubernetes集群的部署一直是初学者难以逾越的“天堑”。较简单的方式是，基于kubeadm一类的部署工具运行两条命令即可拉起一个真正的分布式集群。
2.1.1 kubeadm部署工具
kubeadm是Kubernetes社区提供的集群构建工具，它负责构建一个最小化可用集群并执行启动等必要的基本步骤。kubeadm仅关心如何初始化并拉起一个集群，其职责仅限于图2-1中的Layer2和Layer3中的部分附件，至于准备基础设施的Layer1和包含其他附件的Layer3则不在其职责之内。
换句话说，kubeadm仅仅是为集群添加最为要紧的核心附件CoreDNS和kube-proxy。余下的其他附件，例如Kubernetes Dashboard、监控系统和日志系统等必要的附加组件则不在kubeadm考虑范围内。
kubeadm的核心工具是kubeadm init和kubeadm join，前者用于创建新的控制平面节点（见图2-2），后者则用于将节点快速连接到指定的控制平面，它们是创建Kubernetes集群最佳实践的“快速路径”。
此外，kubeadm token命令负责可管理集群构建后节点加入集群时使用的认证令牌，以供新节点基于预共享密钥在首次联系API Server时进行身份认证。而删除集群构建过程中生成的文件并重置回初始状态，则是kubeadm reset命令的功能。其他几个可用的工具包括kubeadm config和kubeadm upgrade等。
kubeadm并不仅仅是一键安装类的解决方案，它把集群本身视为不可变组件，而升级操作等同于全新部署或就地更新。目前，kubeadm已经成为越来越多的组织或企业部署测试或生产环境时的选择。
2.1.2 集群组件运行模式
etcd、kube-apiserver、kube-controller-manager、kube-scheduler、kubelet和kube-proxy，这些组件自身也是应用程序，除了kubelet和Docker等容器引擎之外，其他几个组件同样可以运行为容器。
以集群的组件是否以容器方式运行，以及是否运行为自托管模式为标准，Kubernetes集群可部署为3种运行模式。
1）独立组件模式：Master各组件和Node各组件直接以守护进程方式运行于节点之上，以二进制程序部署的集群隶属于此种类型，如图2-3所示。
2）静态Pod模式：控制平面的各组件以静态Pod对象形式运行在Master主机之上，而Node主机上的kubelet和Docker运行为系统级守护进程，kube-proxy托管于集群上的DaemonSet控制器，如图2-4所示。
3）自托管（self-hosted）模式：类似于第二种模式，但控制平面的各组件运行为Pod对象（非静态），并且这些Pod对象同样托管运行在集群之上，且同样受控于DaemonSet类型的控制器。
使用kubeadm部署的Kubernetes集群可运行为第二种或第三种模式，默认为静态Pod对象模式，当需要使用自托管模式时，可使用kubeadm init命令的–features-gates=selfHosting选项激活。
2.1.3 kubeadm init工作流程
kubeadm拉起一个Kubernetes集群主要需要两个步骤：先在第一个Master主机上运行kubeadm init命令初始化控制平面，待其完成后，在其他主机上运行kubeadm join命令逐一加入控制平面，进而成为集群成员。
初始化一个控制平面需要一系列复杂的过程，kubeadm init命令将其分割成多个阶段逐一实现，例如环境预检（preflight）、启动kubelet（kubelet-start）、为集群生成所需CA及数字证书（cert）等10多个阶段，各阶段的描述可参考kubeadm init --help命令提供的配置信息。
kubeadm init命令通过以下过程拉起Kubernetes的控制平面节点。
1）执行由众多步骤组成的环境预检操作，以确保节点配置能够满足运行为Master主机的条件。
2）生成自签名的CA，并为各组件生成必要的数字证书和私钥，相关文件存储在由–cert-dir选项指定的目录下，默认路径为/etc/kubernetes/pki，相关的CA和证书如图2-5所示。
3）Kubernetes集群的各个组件以API Server为中心完成彼此间的协作，但它们需要将相关的认证信息转换格式，并保存于kubeconfig配置文件中以便组件调用。
4）control-plane阶段用于为API Server、Controller Manager和Scheduler生成静态Pod配置清单，而etcd阶段则为本地etcd存储生成静态Pod配置清单，它们都会保存于/etc/kubernetes/manifests目录中。因此，这两个阶段创建生成的各配置清单将会启动Master组件的相关Pod。
5）等到控制平面的各组件成功启动后，会进入upload-config阶段。这个阶段会将kubeadm和kubeconfig的配置存储为kube-system名称空间中的ConfigMap资源对象。而upload-certs阶段需要显式地由–upload-certs选项激活，它会将kubeadm的证书存储在Secret资源对象中，以供后加入的其他Master节点使用。
6）mark-control-plane阶段负责为当前主机打上
node-role.kubernetes.io/master=，将其标记为Master，并为该主机设置node-role.kubernetes.io/master:NoSchedule污点，以防止其他工作负载Pod运行在当前主机上。
7）bootstrap-token阶段会生成引导令牌，其他Node主机需要使用该令牌在加入集群时与控制平面建立双向信任。换句话说，只要持有Bootstrap Token，任何节点都可使用kubeadm join命令加入该集群。该令牌也可由kubeadm token命令进行查看、创建和删除等管理操作。
8）kubelet-finalize阶段进行一些必要的配置，以允许节点通过Bootstrap Token或TLS Bootstrap机制加入集群中。这类配置包括：生成ConfigMap，设置RBAC以允许节点加入集群时能获取到必要的信息，允许Bootstrap Token访问CSR签署API，以及能够自动签署CSR请求等。
9）最后一个阶段则是为集群添加必要的基本附件，如CoreDNS和kube-proxy，它们都以Pod形式托管运行在当前集群之上。
上述过程的简要执行流程如图2-6所示。基于二进制程序包以手动方式部署Kubernetes集群时，这些步骤和流程都需要逐步调试实现，使得许多人或望而生畏或浅尝辄止。
2.1.4 kubeadm join工作流程
根据用户的设定，新加入的主机可以成为新的Master主机（Master HA模式中的其他节点），也可以成为Worker主机（工作节点）。
随后，同控制平面建立双向信任关系是新节点加入集群的关键一步，这种双向信任可分为发现和TLS引导程序两个阶段。发现阶段是让新节点通过共享令牌向指定的API Server发送请求以获取集群信息。TLS引导程序阶段是让控制平面借助TLS Bootstrap机制为新节点签发数字证书以信任请求加入的节点，如图2-7所示。
接下来的过程会因新加入节点的不同角色而有所区别。kubeadm将为加入集群主机的工作节点基于接收到的数字证书生成kubelet.conf配置文件，这样kubelet程序便能够以该配置文件接入到集群当中并进行安全通信，再由kube-proxy的DaemonSet控制器为此节点启动kube-proxy Pod。
2.1.5 kubeadm配置文件
初始化集群的kubeadm inti命令也可通过–config选项让配置文件接收配置信息，它支持InitConfiguration、ClusterConfiguration、KubeProxyConfiguration和KubeletConfiguration这4种配置类型，而且仅InitConfiguration或ClusterConfiguration其中之一为强制要求提供的配置信息。
下面给出了一个完整的ClusterConfiguration的配置框架及各字段的简要说明，为了节省篇幅，省略了controllerManager和scheduler中也可以额外配置的存储卷。
yaml复制代码apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
etcd:
local: # 堆叠式etcd拓扑，与external字段互斥
imageRepository: "k8s.gcr.io" # 获取etcd容器镜像仓库
imageTag: "3.4.3" # etcd容器镜像的标签
dataDir: "/var/lib/etcd" # 数据目录
extraArgs: # 额外参数，例如监听的URL和端口，可省略
listen-client-urls: https://172.29.9.1:2379
serverCertSANs: # 服务器证书的Subject列表
- "k8s-master01.ilinux.io"
peerCertSANs: # 集群成员内部通信的对等证书Subject列表
- "172.29.9.1"
# external: # 外部etcd集群拓扑，与local互斥
# endpoints: # 外部etcd集群的成员端点列表
# - "10.100.0.1:2379"
# - "10.100.0.2:2379"
# caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt" # CA的证书
# certFile: "/etcd/kubernetes/pki/etcd/etcd.crt" # 客户端证书
# keyFile: "/etcd/kubernetes/pki/etcd/etcd.key" # 证书配对的私钥
networking: # 网络定义
serviceSubnet: "10.96.0.0/12" # Service网络地址
podSubnet: "10.100.0.0/24" # Pod网络地址
dnsDomain: "cluster.local" # 集群域名后缀
kubernetesVersion: "v1.19.0" # Kubernetes自身的版本
controlPlaneEndpoint: "k8s-api.ilinux.io:6443" # 控制平面端点
apiServer: # 配置API Server
extraArgs: # 额外指定的参数
authorization-mode: "Node,RBAC"# 支持的授权机制
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt # 激活内置签名者
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
extraVolumes: # 用到的存储卷，可省略
- name: "some-volume"
hostPath: "/etc/some-path"
mountPath: "/etc/some-pod-path"
readOnly: false
pathType: File
certSANs: # API Server服务器端证书的Subject列表
- "k8s-master01.ilinux.io"
timeoutForControlPlane: 4m0s
controllerManager: # 控制器管理器相关的配置
extraArgs:
"node-cidr-mask-size": "24" # 为节点分别配置podCIDR时使用的掩码长度
scheduler: # 调度器相关的配置
extraArgs:
address: "127.0.0.1" # 监听的地址
certificatesDir: "/etc/kubernetes/pki" # 证书文件目录
imageRepository: "k8s.gcr.io" # k8s集群组件镜像文件仓库
useHyperKubeImage: false # 是否使用HyperKubeImage
clusterName: "example-cluster" # 集群名称
: pod-with-
若默认值符合配置期望，上面这些ClusterConfiguration的配置参数中的大多数字段都可以省略。