转载自Kubernetes搭建之kubeadm-init探究
写在前面
如果想要搭建私有的k8s集群业界有几个方案,比如kubeadm、Rancher、Minikube等,其中前两种方式搭建的k8s集群可以在生产中使用,而Minikube搭建的集群则可以用来自己本地调试开发。
由于Kubeadm是官方推荐的集群搭建方式,因此想着把这个命令探索一番。一方面可以对这个命令更加了解,以后使用这个命令搭建集群时也能够更自信;另一方面可以借助这个过程来探究搭建k8s的细节,了解它的一砖一瓦是如何垒砌成为庞大的集群的,对以后集群的运维也将有非常大的帮助。
kubeadm-init
kubeadm是什么
首先,kubeadm是一个构建k8s集群的工具。它提供的kubeadm init
和kubeadm join
两个命令是快速构建k8s集群的最佳实践。 其次,kubeadm工具只为构建最小可用集群,它只关心集群中最基础的组件,至于其他的插件(比如dashboard、CNI等)则不会涉及。 不过,从我的经验来看,这些已经足够。
使用kubeadm构建一个master节点
通过kubeadm init [flags]命令可以启动一个master节点。其中[flags]代表了kubeadm init命令可以传入的参数。
如果查看官方介绍,可以发现kubeadm init可以传入的参数比较多,这里只简单介绍几种(其他的大家可以到 这里查看 ):
- –apiserver-bind-port int32 Default: 6443 可以通过这个参数指定API-server的工作端口,默认是6443。
- –config string 可以通过这个命令传入kubeadm的配置文件,需要注意的是,这个参数是实验性质的,不推荐使用。
- –dry-run 带了这个参数后,运行命令将会把kubeadm做的事情输出到标准输出,但是不会实际部署任何东西。强烈推荐!
-h, --help 输出帮助文档。 - –node-name string 指定当前节点的名称。
- –pod-network-cidr string 通过这个值来设定pod网络的IP地址网段;设置了这个值以后,控制平面会自动给每个节点设置CIDRs(无类别域间路由,Classless Inter-Domain Routing)。
- –service-cidr string Default: “10.96.0.0/12” 设置service的CIDRs,默认为 10.96.0.0/12。
- –service-dns-domain string Default: “cluster.local” 设置域名称后缀,默认为cluster.local。
- 其他参数。
kubeadm-init的工作流
在运行了 kubeadm init 命令以后,都进行了那些操作呢?这里主要就是跟着官方文档来翻译一遍了:
- 首先会运行一系列预检代码来检查系统的状态;大部分的检查只会抛出一个警告,也有一部分会抛出异常错误从而导致工作流推出(比如没有关闭swap或者没有安装docker)。官方给出一个参数–ignore-preflight-errors=, 我估计八成大家用不到,除非真的明白自己在做啥。。。
- 生成一个用来认证k8s组件间调用的自签名的CA(Certificate Authority,证书授权);这个证书也可以通过–cert-dir(默认是/etc/kubernetets/pki)的方式传入,那么这一步就会跳过。
- 把kubelet、controller-manager和scheduler等组件的配置文件写到/etc/kubernets/目录,这几个组件会使用这些配置文件来连接API-server的服务;除了上面几个配置文件,还会生成一个管理相关的admin.conf文件。
- 如果参数中包含–feature-gates=DynamicKubeletConfig,会把kubelet的初始化配置文件写入/var/lib/kubelet/config/init/kubelet这个文件;官方给出一坨文字解释,这里先不探究了,因为我没有用到。。。
- 接下来就是创建一些 静态pod 的配置文件了,包括API-server、controller-manager和scheduler。假如没有提供外部etcd,还会另外生成一个etcd的静态Pod配置文件。这些静态pod会被写入/etc/kubernetes/manifests,kubelet进程会监控这个目录,从而创建相关的pod。
- 假如第五步比较顺利,这个时候k8s的控制面进程(api-server、controller-manager、scheduler)就全都起来了。
- 如果传入了参数–feature-gates=DynamicKubeletConfig,又会对kubelet进行一坨操作,因为没有用到,所以这里不做详细探究。
- 给当前的节点(Master节点)打label和taints,从而防止其他的负载在这个节点运行。
- 生成token,其他节点如果想加入当前节点(Master)所在的k8s集群,会用到这个token。
- 进行一些允许节点以 Bootstrap Tokens) 和 TLS bootstrapping 方式加入集群的必要的操作:
- 设置RBAC规则,同时创建一个用于节点加入集群的ConfigMap(包含了加入集群需要的所有信息)。
- 让Bootstrap Tokens可以访问CSR签名的API。
- 给新的CSR请求配置自动认证机制。
- 通过API-server安装DNS服务器(1.11版本后默认为CoreDNS,早期版本默认为kube-dns)和kube-proxy插件。这里需要注意的是,DNS服务器只有在安装了CNI(flannel或calico)之后才会真正部署,否则会处于挂起(pending)状态。
到这里基本上就告一段落了。
就这样,把kubeadm init命令具体的操作流程过了一遍,其实完全可以使用–dry-run参数,通过观察输出来看看到底包含哪些流程。上面的流程是按照最新的文档(截止到北京时间2018-11-28晚23时),关于其他版本(比如1.8 )都可以到github上查找。
其他
这里只列出几个作者比较感兴趣的点,其他的点大家可以到官网去查看。
通过传入配置文件的方式来运行kubeadm init
就像前面描述的,kubeadm init可以通过配置–config参数来传入配置文件。从官网描述来看,这个特性还不怎么稳定,不过就实践经验来看,其实是可以用的。
使用自己定制的镜像
默认情况下kubeadm会到k8s.gcr.io拉取镜像,不过对于一些私有化部署(比如国内存在墙的情况下,上面的地址是访问不到的),就需要自定义镜像地址了。 这种方式需要通过配置文件的方式才能实现,允许传入的参数包括:
通过unifiedControlPlaneImage来让所有的控制平面组件(api-server、controller-manager、scheduler等)使用统一的镜像而不是分离开的镜像(应该适用于自定义镜像的情况)。
通过etcd.image来定义etcd所使用的镜像。
需要注意,配置文件中的kubernetesVersion字段或者命令行传入的–kubernetes-version会影响镜像的版本。
kubeadm内置的kubelet相关配置文件
kubeadm的安装包事先配置了kubelet的运行方式,定义了比较多的参数来定制化kubelet的运行。这里不细描述了,感兴趣可以自行钻研。
配置CRI运行时环境
即可以通过改写kubelet的启动文件来设置容器运行时环境,目前可以选择的有Docker、cri-containerd、rkt等,默认是docker。建议使用docker就好了,除非知道自己在做什么,可以尝试其他的容器运行时环境。
小结
文本简单介绍了kubeadm的子命令kubeadm init以及此命令的工作流程。主要参考了英文的官方文档内容,进行了简单的翻译。如果大家对kubeadm init感兴趣想要详细钻研,建议到官网页面进行探究;不过本文作为中文材料,作者有选择性的把一些点列出来,对于初学者来说也具有一定的参考价值。