kuadm安装kubernetes的原理讲解

kubeadm作为kubernetes常用的一种安装方式，他的安装原理我们在这里理解一下
当我们创建一个master节点的时候我们可以执行

kubeadm init ....

当我们需要一个node节点的时候

kubeadm join

在执行kubeadm init 之前kubuadm会做一些提前检查，这些检查包括
CRI: 检查容器运行时是否有在运行
Service: 检查是否enable和active
Firewall: 检查防火墙是否有关闭
Port: 检查某些端口是否有放开
Privileged: 检查一些权限的问题
Dir Available: 检查目录是否有效
File Available: 检查文件是否有效
File Existing: 检查文件是否存在
File Content: 检查文件中是否有指定的内容
In Path: 检查某些可执行文件是否在指定的目录
Hostname: 检查主机名的格式
HTTP Proxy: 检查本机是否有Proxy设置
HTTP Proxy CIDR: 检查本机有哪些地址会走Proxy
System Verification: 检查系统版本
Kubernetes Version: 检查Kubernetes的版本
Kubelet Version: 检查Kubelet的版本
SwapCheck: 检查Swap是否关闭
External Etcd Version: 检查外部etcd的版本
Image Pull: 检查镜像仓库是否连通
Num CPU: 检查本机CPU数量是否符合kubeadm的最低要求
Mem: 检查本机内存是否符合kubeadm的最低要求
Linux 内核的版本必须是否是 3.10 以上？Linux Cgroups 模块是否可用？机器的 hostname 是否标准？在 Kubernetes 项目里，机器的名字以及一切存储在 Etcd 中的 API 对象，都必须使用标准的 DNS 命名（RFC 1123）。用户安装的 kubeadm 和 kubelet 的版本是否匹配？机器上是不是已经安装了 Kubernetes 的二进制文件？Kubernetes 的工作端口 10250/10251/10252 端口是不是已经被占用？ip、mount 等 Linux 指令是否存在？

Kubernetes 对外提供服务时，除非专门开启“不安全模式”，否则都要通过 HTTPS 才能访问 kube-apiserver。这就需要为 Kubernetes 集群配置好证书文件。kubeadm 为 Kubernetes 项目生成的证书文件都放在 Master 节点的 /etc/kubernetes/pki 目录下。在这个目录下，最主要的证书文件是 ca.crt 和对应的私钥 ca.key。此外，用户使用 kubectl 获取容器日志等 streaming 操作时，需要通过 kube-apiserver 向 kubelet 发起请求，这个连接也必须是安全的。kubeadm 为这一步生成的是 apiserver-kubelet-client.crt 文件，对应的私钥是 apiserver-kubelet-client.key。

在 Kubernetes 中，有一种特殊的容器启动方法叫做“Static Pod”。它允许你把要部署的 Pod 的 YAML 文件放在一个指定的目录里。这样，当这台机器上的 kubelet 启动时，它会自动检查这个目录，加载所有的 Pod YAML 文件，然后在这台机器上启动它们

Master 容器启动后，kubeadm 会通过检查 localhost:6443/healthz 这个 Master 组件的健康检查 URL，等待 Master 组件完全运行起来。然后，kubeadm 就会为集群生成一个 bootstrap token。在后面，只要持有这个 token，任何一个安装了 kubelet 和 kubadm 的节点，都可以通过 kubeadm join 加入到这个集群当中。这个 token 的值和使用方法，会在 kubeadm init 结束后被打印出来。在 token 生成之后，kubeadm 会将 ca.crt 等 Master 节点的重要信息，通过 ConfigMap 的方式保存在 Etcd 当中，供后续部署 Node 节点使用。这个 ConfigMap 的名字是 cluster-info。

kubeadm join 的工作流程这个流程其实非常简单，kubeadm init 生成 bootstrap token 之后，你就可以在任意一台安装了 kubelet 和 kubeadm 的机器上执行 kubeadm join 了。可是，为什么执行 kubeadm join 需要这样一个 token 呢？因为，任何一台机器想要成为 Kubernetes 集群中的一个节点，就必须在集群的 kube-apiserver 上注册。可是，要想跟 apiserver 打交道，这台机器就必须要获取到相应的证书文件（CA 文件）。可是，为了能够一键安装，我们就不能让用户去 Master 节点上手动拷贝这些文件。所以，kubeadm 至少需要发起一次“不安全模式”的访问到 kube-apiserver，从而拿到保存在 ConfigMap 中的 cluster-info（它保存了 APIServer 的授权信息）。而 bootstrap token，扮演的就是这个过程中的安全验证的角色。只要有了 cluster-info 里的 kube-apiserver 的地址、端口、证书，kubelet 就可以以“安全模式”连接到 apiserver 上，这样一个新的节点就部署完成了。

默认情况下 Master 节点是不允许运行用户 Pod 的。而 Kubernetes 做到这一点，依靠的是 Kubernetes 的 Taint/Toleration 机制。

基于 Kubernetes 开展工作时，你一定要优先考虑这两个问题：我的工作是不是可以容器化？我的工作是不是可以借助 Kubernetes API 和可扩展机制来完成？而一旦这项工作能够基于 Kubernetes 实现容器化，就很有可能像上面的部署过程一样，大幅简化原本复杂的运维工作。对于时间宝贵的技术人员来说，这个变化的重要性是不言而喻的。