广西城乡建设厅网站首,网站建设指数是什么意思,受欢迎的广州网站设计,WordPress主题里的AD文章目录集群部署痛点kubeadm 的工作原理kubeadm init 的工作流程kubeadm join 的工作流程kubeadm 的部署配置参数集群部署痛点 Kubernetes 的部署一直以来都是挡在初学者前面的一只“拦路虎”。尤其是在 Kubernetes 项目发布初期#xff0c;它的部署完全要依靠一堆由社区维护…
文章目录集群部署痛点kubeadm 的工作原理kubeadm init 的工作流程kubeadm join 的工作流程kubeadm 的部署配置参数集群部署痛点 Kubernetes 的部署一直以来都是挡在初学者前面的一只“拦路虎”。尤其是在 Kubernetes 项目发布初期它的部署完全要依靠一堆由社区维护的脚本。 Kubernetes 作为一个 Golang 项目已经免去了很多类似于 Python 项目要安装语言级别依赖的麻烦。但是除了将各个组件编译成二进制文件外用户还要负责为这些二进制文件编写对应的配置文件、配置自启动脚本以及为 kube-apiserver 配置授权文件等等诸多运维工作。
目前各大云厂商最常用的部署的方法是使用 SaltStack、Ansible 等运维工具自动化地执行这些步骤。
但即使这样这个部署过程依然非常繁琐。因为SaltStack 这类专业运维工具本身的学习成本就可能比 Kubernetes 项目还要高。
难道 Kubernetes 项目就没有简单的部署方法了吗
这个问题在 Kubernetes 社区里一直没有得到足够重视。直到 2017 年在志愿者的推动下社区才终于发起了一个独立的部署工具名叫kubeadm。
这个项目的目的就是要让用户能够通过这样两条指令完成一个 Kubernetes 集群的部署
创建一个 Master 节点
$ kubeadm init将一个 Node 节点加入到当前集群中
$ kubeadm join Master 节点的 IP 和端口 是不是非常方便呢
kubeadm 的工作原理
在上一篇详细介绍了 Kubernetes 的架构和它的组件。在部署时它的每一个组件都是一个需要被执行的、单独的二进制文件。所以不难想象SaltStack 这样的运维工具或者由社区维护的脚本的功能就是要把这些二进制文件传输到指定的机器当中然后编写控制脚本来启停这些组件。
不过在理解了容器技术之后你可能已经萌生出了这样一个想法为什么不用容器部署 Kubernetes 呢
这样我只要给每个 Kubernetes 组件做一个容器镜像然后在每台宿主机上用 docker run 指令启动这些组件容器部署不就完成了吗
事实上在 Kubernetes 早期的部署脚本里确实有一个脚本就是用 Docker 部署 Kubernetes 项目的这个脚本相比于 SaltStack 等的部署方式也的确简单了不少。
但是这样做会带来一个很麻烦的问题即如何容器化 kubelet。
我在上一篇文章中已经提到 kubelet 是 Kubernetes 项目用来操作 Docker 等容器运行时的核心组件。可是除了跟容器运行时打交道外kubelet 在配置容器网络、管理容器数据卷时都需要直接操作宿主机。
而如果现在 kubelet 本身就运行在一个容器里那么直接操作宿主机就会变得很麻烦。对于网络配置来说还好kubelet 容器可以通过不开启 Network Namespace即 Docker 的 host network 模式的方式直接共享宿主机的网络栈。可是要让 kubelet 隔着容器的 Mount Namespace 和文件系统操作宿主机的文件系统就有点儿困难了。
比如如果用户想要使用 NFS 做容器的持久化数据卷那么 kubelet 就需要在容器进行绑定挂载前在宿主机的指定目录上先挂载 NFS 的远程目录。
可是这时候问题来了。由于现在 kubelet 是运行在容器里的这就意味着它要做的这个“mount -F nfs”命令被隔离在了一个单独的 Mount Namespace 中。即kubelet 做的挂载操作不能被“传播”到宿主机上。
对于这个问题有人说可以使用 setns() 系统调用在宿主机的 Mount Namespace 中执行这些挂载操作也有人说应该让 Docker 支持一个–mnthost 的参数。
但是到目前为止在容器里运行 kubelet依然没有很好的解决办法也不推荐你用容器去部署 Kubernetes 项目。
正因为如此kubeadm 选择了一种妥协方案
把 kubelet 直接运行在宿主机上然后使用容器部署其他的 Kubernetes 组件。
所以使用 kubeadm 的第一步是在机器上手动安装 kubeadm、kubelet 和 kubectl 这三个二进制文件。kubeadm 的作者已经为各个发行版的 Linux 准备好了安装包只需要执行
$ apt-get install kubeadm就可以了。
接下来你就可以使用“kubeadm init”部署 Master 节点了。
kubeadm init 的工作流程
执行 kubeadm init 指令后kubeadm 首先要做的是一系列的检查工作以确定这台机器可以用来部署 Kubernetes。这一步检查我们称为“Preflight Checks”它可以省掉很多后续的麻烦。
其实Preflight Checks 包括了很多方面比如
Linux 内核的版本必须是否是 3.10 以上Linux Cgroups 模块是否可用机器的 hostname 是否标准在 Kubernetes 项目里机器的名字以及一切存储在 Etcd 中的 API 对象都必须使用标准的 DNS 命名RFC 1123。用户安装的 kubeadm 和 kubelet 的版本是否匹配机器上是不是已经安装了 Kubernetes 的二进制文件Kubernetes 的工作端口 10250/10251/10252 端口是不是已经被占用ip、mount 等 Linux 指令是否存在Docker 是否已经安装……
在通过了 Preflight Checks 之后kubeadm 要为你做的是生成 Kubernetes 对外提供服务所需的各种证书和对应的目录。
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 集群中还有 Aggregate APIServer 等特性也需要用到专门的证书这里就不再一一列举了。需要指出的是你可以选择不让 kubeadm 为你生成这些证书而是拷贝现有的证书到如下证书的目录里 /etc/kubernetes/pki/ca.{crt,key} 这时kubeadm 就会跳过证书生成的步骤把它完全交给用户处理。
证书生成后kubeadm 接下来会为其他组件生成访问 kube-apiserver 所需的配置文件。这些文件的路径是/etc/kubernetes/xxx.conf
ls /etc/kubernetes/
admin.conf controller-manager.conf kubelet.conf scheduler.conf这些文件里面记录的是当前这个 Master 节点的服务器地址、监听端口、证书目录等信息。这样对应的客户端比如 schedulerkubelet 等可以直接加载相应的文件使用里面的信息与 kube-apiserver 建立安全连接。
接下来kubeadm 会为 Master 组件生成 Pod 配置文件。在上一篇介绍过 Kubernetes 有三个 Master 组件 kube-apiserver、kube-controller-manager、kube-scheduler而它们都会被使用 Pod 的方式部署起来。
你可能会有些疑问这时Kubernetes 集群尚不存在难道 kubeadm 会直接执行 docker run 来启动这些容器吗
当然不是。
在 Kubernetes 中有一种特殊的容器启动方法叫做“Static Pod”。它允许你把要部署的 Pod 的 YAML 文件放在一个指定的目录里。这样当这台机器上的 kubelet 启动时它会自动检查这个目录加载所有的 Pod YAML 文件然后在这台机器上启动它们。
从这一点也可以看出kubelet 在 Kubernetes 项目中的地位非常高在设计上它就是一个完全独立的组件而其他 Master 组件则更像是辅助性的系统容器。
在 kubeadm 中Master 组件的 YAML 文件会被生成在 /etc/kubernetes/manifests 路径下。比如kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:annotations:scheduler.alpha.kubernetes.io/critical-pod: creationTimestamp: nulllabels:component: kube-apiservertier: control-planename: kube-apiservernamespace: kube-system
spec:containers:- command:- kube-apiserver- --authorization-modeNode,RBAC- --runtime-configapi/alltrue- --advertise-address10.168.0.2...- --tls-cert-file/etc/kubernetes/pki/apiserver.crt- --tls-private-key-file/etc/kubernetes/pki/apiserver.keyimage: k8s.gcr.io/kube-apiserver-amd64:v1.11.1imagePullPolicy: IfNotPresentlivenessProbe:...name: kube-apiserverresources:requests:cpu: 250mvolumeMounts:- mountPath: /usr/share/ca-certificatesname: usr-share-ca-certificatesreadOnly: true...hostNetwork: truepriorityClassName: system-cluster-criticalvolumes:- hostPath:path: /etc/ca-certificatestype: DirectoryOrCreatename: etc-ca-certificates...关于一个 Pod 的 YAML 文件怎么写、里面的字段如何解读在后续专门的文章中会详细分析。在这里只需要关注这样几个信息
这个 Pod 里只定义了一个容器它使用的镜像是k8s.gcr.io/kube-apiserver-amd64:v1.11.1 。这个镜像是 Kubernetes 官方维护的一个组件镜像。
这个容器的启动命令commands是 kube-apiserver --authorization-modeNodeRBAC …这样一句非常长的命令。其实它就是容器里 kube-apiserver 这个二进制文件再加上指定的配置参数而已。
如果你要修改一个已有集群的 kube-apiserver 的配置需要修改这个 YAML 文件。
这些组件的参数也可以在部署时指定稍后会讲解到。
在这一步完成后kubeadm 还会再生成一个 Etcd 的 Pod YAML 文件用来通过同样的 Static Pod 的方式启动 Etcd。所以最后 Master 组件的 Pod YAML 文件如下所示
$ ls /etc/kubernetes/manifests/
etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml而一旦这些 YAML 文件出现在被 kubelet 监视的 /etc/kubernetes/manifests 目录下kubelet 就会自动创建这些 YAML 文件中定义的 Pod即 Master 组件的容器。
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 init 的最后一步就是安装默认插件。Kubernetes 默认 kube-proxy 和 DNS 这两个插件是必须安装的。它们分别用来提供整个集群的服务发现和 DNS 功能。其实这两个插件也只是两个容器镜像而已所以 kubeadm 只要用 Kubernetes 客户端创建两个 Pod 就可以了。
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 上这样一个新的节点就部署完成了。
接下来你只要在其他节点上重复这个指令就可以了。
kubeadm 的部署配置参数
前面讲解了 kubeadm 部署 Kubernetes 集群最关键的两个步骤kubeadm init 和 kubeadm join。相信你一定会有这样的疑问kubeadm 确实简单易用可是我又该如何定制我的集群组件参数呢
比如我要指定 kube-apiserver 的启动参数该怎么办
在这里我强烈推荐你在使用 kubeadm init 部署 Master 节点时使用下面这条指令
$ kubeadm init --config kubeadm.yaml这时你就可以给 kubeadm 提供一个 YAML 文件比如kubeadm.yaml它的内容如下所示我仅列举了主要部分
apiVersion: kubeadm.k8s.io/v1alpha2
kind: MasterConfiguration
kubernetesVersion: v1.11.0
api:advertiseAddress: 192.168.0.102bindPort: 6443...
etcd:local:dataDir: /var/lib/etcdimage:
imageRepository: k8s.gcr.io
kubeProxy:config:bindAddress: 0.0.0.0...
kubeletConfiguration:baseConfig:address: 0.0.0.0...
networking:dnsDomain: cluster.localpodSubnet: serviceSubnet: 10.96.0.0/12
nodeRegistration:criSocket: /var/run/dockershim.sock...通过制定这样一个部署参数配置文件你就可以很方便地在这个文件里填写各种自定义的部署参数了。比如我现在要指定 kube-apiserver 的参数那么我只要在这个文件里加上这样一段信息
...
apiServerExtraArgs:advertise-address: 192.168.0.103anonymous-auth: falseenable-admission-plugins: AlwaysPullImages,DefaultStorageClassaudit-log-path: /home/johndoe/audit.log然后kubeadm 就会使用上面这些信息替换 /etc/kubernetes/manifests/kube-apiserver.yaml 里的 command 字段里的参数了。
而这个 YAML 文件提供的可配置项远不止这些。比如你还可以修改 kubelet 和 kube-proxy 的配置修改 Kubernetes 使用的基础镜像的 URL默认的 k8s.gcr.io/xxx 镜像 URL 在国内访问是有困难的指定自己的证书文件指定特殊的容器运行时等等。 笔记来源于极客时间《深入剖析Kubernetes》
