k8s 核心组件

前面介绍过,kudeadm 的思路,是通过把 k8s 主要的组件容器化,来简化安装过程。这时候你可能就有一个疑问,这时候 k8s 集群还没起来,如何来部署 pod?难道直接执行 docker run?当然是没有那么 low,其实在 kubelet 的运行规则中,有一种特殊的启动方法叫做“静态 pod”(static pod),只要把 pod 定义的 yaml 文件放在指定目录下,当这个节点的 kubelet 启动时,就会自动启动 yaml 文件中定义的 pod。从这个机制你也可以发现,为什么叫做 static pod,因为这些 pod 是不能调度的,只能在这个节点上启动,并且 pod 的 ip 地址直接就是宿主机的地址。在 k8s 中,放这些预先定义 yaml 文件的位置是 /etc/kubernetes/manifests,我们来看一下:

$ ll
总用量 16
-rw-------. 1 root root 1999 112 01:35 etcd.yaml
-rw-------. 1 root root 2674 112 01:35 kube-apiserver.yaml
-rw-------. 1 root root 2547 112 01:35 kube-controller-manager.yaml
-rw-------. 1 root root 1051 112 01:35 kube-scheduler.yaml

以下四个就是 k8s 的核心组件了,以静态 pod 的方式运行在当前节点上

  • etcd: k8s 的数据库,所有的集群配置信息、密钥、证书等等都是放在这个里面
  • kube-apiserver: 提供了 HTTP restful api 接口的关键服务进程, 是 kubernetes 里所有资源的增删改查等操作的唯一入口, 也是集群的入口进程,所有其他的组件都是通过 apiserver 来操作 kubernetes 的各类资源
  • kube-controller-manager: 负责管理容器 pod 的生命周期, kubernetes 里的所有资源对象的自动化控制中心, 可以理解为资源对象的"大总管"
  • kube-scheduler: 负责 pod 在集群中的调度, 相当于公交公司的"调度室"

具体操作来说,在之前的文章中已经介绍过,docker 架构调整后,已经拆分出 containerd 组件,所以现在是 kubelet 直接通过 cri-containerd 来调用 containerd 进行容器的创建(不走 docker daemon 了),从进程信息里面可以看出

$ ps -ef | grep containerd
root      3075     1  0 00:29 ?        00:00:55 /usr/bin/containerd
root      4740  3075  0 01:35 ?        00:00:01 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/ec93247aeb737218908557f825344b33dd58f0c098bd750c71da1bc0ec9a49b0 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      4754  3075  0 01:35 ?        00:00:01 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/f738d56f65b9191a63243a1b239bac9c3924b5a2c7c98e725414c247fcffbb8f -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      4757  3

其中 3075 这个进程就是由 docker 服务启动时带起来的 containerd daemon,4740 和 4754 是由 containerd 进程创建的 cotainerd-shim 子进程,用来真正的管理容器进程。多说一句,之前的 docker 版本这几个进程名字分别叫 docker-containerd,docker-cotainerd-shim,docker-runc, 现在的进程名字里面已经完全看不到 docker 的影子了,去 docker 化越来越明显了。

k8s 插件(addon)

  • CoreDNS: cncf 项目,主要是用来做服务发现,目前已经取代 kube-dns 作为 k8 默认的服务发现组件
  • kube-proxy: 基于 iptables 来做的负载均衡,service 会用到,这个性能不咋地,知道一下就好

我们执行一下

$ kubectl get pods -n kube-system
NAME                                      READY   STATUS    RESTARTS   AGE
coredns-86c58d9df4-284kz                  0/1     Pending   0          5m28s
coredns-86c58d9df4-mlxjl                  0/1     Pending   0          5m28s
etcd-miwifi-r1cm-srv                      1/1     Running   0          4m40s
kube-apiserver-miwifi-r1cm-srv            1/1     Running   0          4m52s
kube-controller-manager-miwifi-r1cm-srv   1/1     Running   0          5m3s
kube-proxy-fcjtg                          1/1     Running   0          5m28s
kube-scheduler-miwifi-r1cm-srv            1/1     Running   0          4m45s

可以看到 kubeadm 帮我们安装的,就是我上面提到的那些组件,并且都是以 pod 的形式安装。同时你也应该注意到了,coredns 的两个 pod 都是 pending 状态,这是因为网络插件还没有安装。我们根据前面提到的官方页面的说明安装网络插件,这边我用到的是 flannel,安装方式也很简单,标准的 k8s 式的安装

网络插件 kube-flannel

换源拉取镜像

docker pull registry.cn-shenzhen.aliyuncs.com/cp_m/flannel:v0.10.0-amd64
docker tag registry.cn-shenzhen.aliyuncs.com/cp_m/flannel:v0.10.0-amd64 quay.io/coreos/flannel:v0.10.0-amd64
docker rmi registry.cn-shenzhen.aliyuncs.com/cp_m/flannel:v0.10.0-amd64

安装 kube-flannel

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml

安装完之后我们再看一下 pod 的状态

$ kubectl get pods -n kube-system
NAME                                 READY   STATUS    RESTARTS   AGE
coredns-86c58d9df4-284kz             1/1     Running   0          24m
coredns-86c58d9df4-mlxjl             1/1     Running   0          24m
etcd-k8s-master                      1/1     Running   0          23m
kube-apiserver-k8s-master            1/1     Running   0          23m
kube-controller-manager-k8s-master   1/1     Running   0          23m
kube-flannel-ds-amd64-d4bbn          1/1     Running   0          24m
kube-proxy-fcjtg                     1/1     Running   0          24m
kube-scheduler-k8s-master            1/1     Running   0          23m

可以看到 coredns 的两个 pod 都已经启动,同时还多了一个 kube-flannel-ds-amd64-d4bbn,这正是我们刚才安装的网络插件 flannel。

注意

如果 kube-flannel-ds-amd64-d4bbn 的状态为 ImagePullBackOff, 则说明拉取镜像失败, 需要换源拉取, 参看前面的 "ERROR ImagePull" 错误解决

这时候我们再来看一下核心组件的状态

$ kubectl get componentstatus
NAME                 STATUS    MESSAGE              ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health": "true"}

可以看到组件的状态都已经 ok 了,我们再看看 node 的状态

$ kubectl get node
NAME         STATUS   ROLES    AGE   VERSION
k8s-master   Ready    master   32m   v1.14.2

node 的状态是 Ready,说明我们的 master 安装成功,至此大功告成!

默认的 master 节点是不能调度应用 pod 的,所以我们还需要给 master 节点打一个污点标记

kubectl taint nodes --all node-role.kubernetes.io/master-

如果在配置过程中有任何错误, 比如 kube-flannel-ds-amd64-d4bbn 出错, 可以使用以下命令查看错误 (比如会有拉取镜像错误):

kubectl describe pod kube-flannel-ds-amd64-d4bbn --namespace=kube-system

MIT Licensed | Copyright © 2018-present 滇ICP备16006294号

Design by Quanzaiyu | Power by VuePress