【讀書筆記】10 Kubernetes一鍵部署利器 kubeadm

《深入剖析Kubernetes - 09? 從容器到容器云 談?wù)凨ubernetes的本質(zhì)》

kubeadm 簡化部署操作，僅需要以下2個(gè)操作即可創(chuàng)建一個(gè)k8s 集群

#?創(chuàng)建一個(gè)?Master?節(jié)點(diǎn)
$?kubeadm?init

#?將一個(gè)?Node?節(jié)點(diǎn)加入到當(dāng)前集群中
$?kubeadm?join

k8s 每個(gè)組件都是一個(gè)獨(dú)立的二進(jìn)制文件，部署過程無非就是將二進(jìn)制跟配置文件分布到指定機(jī)器，并通過腳本啟停進(jìn)程，這些工作在物理機(jī)時(shí)代完全可以通過saltstack 或者ansible 來完成，但后續(xù)運(yùn)維成本會比較高，得自己實(shí)現(xiàn)進(jìn)程監(jiān)控，健康檢查等等。

既然k8s 做服務(wù)編排，自然可以解決服務(wù)發(fā)現(xiàn)，服務(wù)注冊，健康檢查等功能。

具體方法是，master機(jī)器上 先手動在機(jī)器上安裝kubeadm、kubelet、kubectl 這3個(gè)二進(jìn)制文件；

而node 節(jié)點(diǎn)上面則只需要安裝kubelet / kubeadm 然后通過kubeadm join 添加到集群內(nèi)部即可

一、kubeadm init 工作流程

（1）檢查機(jī)器環(huán)境是否滿足

1、linux內(nèi)核是否3.10 以上

2、cgroups 模塊是否啟用

3、hostname 是否符合標(biāo)準(zhǔn)（遵循DNS命名規(guī)則）

4、kubeadm 和 kubelet 版本是否匹配

5、是否已安裝kubernetes 二進(jìn)制文件

6、10250/10251/10252 等端口是否被占用

7、ip、mount 等指令是否存在

8、docker 是否安裝

... ...

（2）生成kubernetes 對外提供服務(wù)所需證書和對應(yīng)目錄

默認(rèn)放在/etc/kubernetes/pki 目錄下

主要有ca.crt / ca.key

apiserver-kubelet-client.crt / apiserver-kubelet-client.key

（3）為master組件生成Pod 配置文件

即api-server、scheduler、controller-manager 以static-pod 方式部署

static-pod 允許將yaml 文件放在指定目錄，在kubelet 啟動時(shí)指定該目錄，此時(shí)它會自動檢查該目錄并加載所有pod yaml文件并啟動相應(yīng)pod

為什么要用static pod？

剛創(chuàng)建集群的時(shí)候，上面并沒有api-server 、kubectl ，無法創(chuàng)建相關(guān)的pod，故只能通過這種方式啟動pod。

master 組件yaml文件生成目錄為：/etc/kubernetes/manifests

ls?/etc/kubernetes/manifests/
etcd.yaml??kube-apiserver.yaml??kube-controller-manager.yaml??kube-scheduler.yaml

這里有個(gè)api-server.yaml 的例子：

apiVersion:?v1
kind:?Pod
metadata:
??annotations:
????scheduler.alpha.kubernetes.io/critical-pod:?""
??creationTimestamp:?null
??labels:
????component:?kube-apiserver
????tier:?control-plane
??name:?kube-apiserver
??namespace:?kube-system
spec:
??containers:
??-?command:
????-?kube-apiserver
????-?--authorization-mode=Node,RBAC
????-?--runtime-config=api/all=true
????-?--advertise-address=10.168.0.2
????...
????-?--tls-cert-file=/etc/kubernetes/pki/apiserver.crt
????-?--tls-private-key-file=/etc/kubernetes/pki/apiserver.key
????image:?k8s.gcr.io/kube-apiserver-amd64:v1.11.1
????imagePullPolicy:?IfNotPresent
????livenessProbe:
??????...
????name:?kube-apiserver
????resources:
??????requests:
????????cpu:?250m
????volumeMounts:
????-?mountPath:?/usr/share/ca-certificates
??????name:?usr-share-ca-certificates
??????readOnly:?true
????...
??hostNetwork:?true
??priorityClassName:?system-cluster-critical
??volumes:
??-?hostPath:
??????path:?/etc/ca-certificates
??????type:?DirectoryOrCreate
????name:?etc-ca-certificates
??...

通過這么一個(gè)yaml配置文件，告訴k8s 創(chuàng)建相應(yīng)的api object ， 這個(gè)api對象定義參考上述yaml 文件

（4）為該集群生成bootstrap token

供worknode 節(jié)點(diǎn) 通過kubeadm join 加入到該集群

（5）安裝默認(rèn)插件

例如kube-proxy / dns （以容器的方式部署）

二、kubeadm join 工作流程

為了方便部署操作，不需要手動從master 上面拷貝證書到每臺worknode ， kubeadm 至少需要發(fā)起一次"不安全模式" 的訪問到api-server，從而拿到保存在configmap中的cluster-info，而bootstrap token 扮演的就是這個(gè)過程中安全驗(yàn)證的角色。

三、指定kubeadm 部署參數(shù)

$ kubeadm init --config kubeadm.yaml

在kubeadm.yaml 配置文件中定義

PS：kubeadm 的不足之處在于，它并沒有解決像etcd 、master 等組件的高可用部署，而是單點(diǎn)部署。