Google云上用kubeadm搭建kubernetes集群

一、環(huán)境準(zhǔn)備
首先我的三個(gè)ubuntu云主機(jī)的配置如下

而且能保證三臺(tái)機(jī)器都能連接外網(wǎng)，這里用的谷歌云主機(jī)，所以不用擔(dān)心訪問(wèn)外網(wǎng)問(wèn)題，如果是本地搭建請(qǐng)參考另一篇博文本地kubeadm搭建kubernetes集群https://blog.51cto.com/13670314/2397626

這里的所有命令都是在root用戶下操作的

二、安裝

1.在所有的節(jié)點(diǎn)上安裝Docker和kubeadm

root@instance-ubuntu-1:~# apt-get install curl -y 
root@instance-ubuntu-1:~# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
root@instance-ubuntu-1:~#  cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF
root@instance-ubuntu-1:~# apt-get update
root@instance-ubuntu-1:~# apt-get install -y docker.io kubeadm

上述安裝過(guò)程中，kubeadm,kubectl,kubelet,kubernetes-cni這幾個(gè)二進(jìn)制文件都會(huì)被自動(dòng)安裝好。
直接使用+Ubuntu+的+docker.io+的安裝源，原因是+Docker+公司每次發(fā)布的最新的+Docker+CE（社區(qū)版）產(chǎn)品往往還沒(méi)有經(jīng)過(guò)+Kubernetes+項(xiàng)目的驗(yàn)證，可能會(huì)有兼容性方面的問(wèn)題。

2.部署kubernetes的Master節(jié)點(diǎn)

root@instance-ubuntu-1:~# vim kubeadm.yaml
apiVersion: kubeadm v1.11
kind: MasterConfiguration
controllerManagerExtraArgs:
horizontal-pod-autoscaler-use-rest-clients: "true"
horizontal-pod-autoscaler-sync-period: "10s"
node-monitor-grace-period: "10s"
apiServerExtraArgs:
runtime-config: "api/all=true"
kubernetesVersion: "stable-1.11"

root@instance-ubuntu-1:~# kubeadm init --config kubeadm.yaml

如果有報(bào)錯(cuò)

your configuration file uses an old API spec: "kubeadm.k8s.io/v1alpha1". Please use kubeadm v1.11 instead and run 'kubeadm config migrate --old-config old.yaml --new-config new.yaml', which will write the new, similar spec using a newer API version.

把a(bǔ)piServer改成你對(duì)應(yīng)的版本

再次運(yùn)行kubeadm init --config kubeadm.yaml

這樣就可以完成Master的部署了，稍等片刻，部署完成后，kubeadm會(huì)生成一條指令

kubeadm join 10.168.0.6:6443 --token k0jhnn.a7l33i18ehbl1aze \
--discovery-token-ca-cert-hash sha256:064420e731f201b1601bb0bb39ccfef0e581a83449a043b60036cfb4537e5c67

kubeadm join 命令是用來(lái)給Master節(jié)點(diǎn)添加更多的Work節(jié)點(diǎn)的，記住此命令，下面會(huì)用到。

此外，kubeadm會(huì)提示提示第一次使用集群所需要的配置命令。

root@instance-ubuntu-1:~# mkdir -p $HOME/.kube
root@instance-ubuntu-1:~# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
root@instance-ubuntu-1:~# chown $(id -u):$(id -g) $HOME/.kube/config

因?yàn)镵ubernetes 集群默認(rèn)需要加密方式訪問(wèn)。所以，這幾條命令，就是將剛剛部署生成的 Kubernetes 集群的安全配置文件，保存到當(dāng)前用戶的.kube 目錄下，kubectl 默認(rèn)會(huì)使用這個(gè)目錄下的授權(quán)信息訪問(wèn) Kubernetes 集群。如果不這么做的話，我們每次都需要通過(guò) export KUBECONFIG 環(huán)境變量告訴 kubectl 這個(gè)安全配置文件的位置。
現(xiàn)在，我們就可以使用 kubectl get命令來(lái)查看當(dāng)前唯一一個(gè)節(jié)點(diǎn)的狀態(tài)了

root@instance-ubuntu-1:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
instance-ubuntu-1 NotReady master 3h62m v1.14.1

主節(jié)點(diǎn)的狀態(tài)為什么會(huì)是NotReady，我們查看一下master節(jié)點(diǎn)的詳細(xì)信息

root@instance-ubuntu-1:~# kubectl describe node instance-ubuntu-1

會(huì)顯示

Ready False ... KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

這是因?yàn)槲覀冞€沒(méi)有部署任何網(wǎng)絡(luò)插件

3.部署網(wǎng)絡(luò)插件

在 Kubernetes 項(xiàng)目“一切皆容器”的設(shè)計(jì)理念指導(dǎo)下，部署網(wǎng)絡(luò)插件非常簡(jiǎn)單，只需要執(zhí)行一句 kubectl apply 指令，以 Weave 為例：

root@instance-ubuntu-1:~# kubectl apply -f https://git.io/weave-kube-1.6

部署完成后檢查一下

root@instance-ubuntu-1:~# kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-fb8b8dccf-lc69z 1/1 Running 0 3h67m
coredns-fb8b8dccf-p2p4k 1/1 Running 0 3h67m
etcd-instance-ubuntu-1 1/1 Running 0 3h66m
kube-apiserver-instance-ubuntu-1 1/1 Running 0 3h66m
kube-controller-manager-instance-ubuntu-1 1/1 Running 0 3h66m
kube-proxy-pksmg 1/1 Running 0 3h57m
kube-proxy-qb2cl 1/1 Running 0 3h67m
kube-proxy-z6q42 1/1 Running 0 3h57m
kube-scheduler-instance-ubuntu-1 1/1 Running 0 3h66m
kubernetes-dashboard-5f7b999d65-rkkqq 1/1 Running 0 3h39m
weave-net-f5kgb 2/2 Running 1 3h57m
weave-net-fxxq2 2/2 Running 0 3h57m
weave-net-nplfj 2/2 Running 0 3h60m

可以看到所有pod都運(yùn)行起來(lái)了 而剛剛部署的 Weave 網(wǎng)絡(luò)插件則在 kube-system 下面新建了一個(gè)名叫 weave-net-cmk27 的 Pod，一般來(lái)說(shuō)，這些 Pod 就是容器網(wǎng)絡(luò)插件在每個(gè)節(jié)點(diǎn)上的控制組件。 Kubernetes 支持容器網(wǎng)絡(luò)插件，使用的是一個(gè)名叫 CNI 的通用接口，它也是當(dāng)前容器網(wǎng)絡(luò)的事實(shí)標(biāo)準(zhǔn)，市面上的所有容器網(wǎng)絡(luò)開(kāi)源項(xiàng)目都可以通過(guò) CNI 接入 Kubernetes，比如 Flannel、Calico、Canal、Romana 等等，它們的部署方式也都是類(lèi)似的“一鍵部署”。至此，Kubernetes 的 Master 節(jié)點(diǎn)就部署完成了。如果你只需要一個(gè)單節(jié)點(diǎn)的 Kubernetes，現(xiàn)在你就可以使用了。不過(guò)，在默認(rèn)情況下，Kubernetes 的 Master 節(jié)點(diǎn)是不能運(yùn)行用戶 Pod 的，第4部分會(huì)講到如何處理。

4.部署 Kubernetes 的 Worker 節(jié)點(diǎn)
Kubernetes 的 Worker 節(jié)點(diǎn)跟 Master 節(jié)點(diǎn)幾乎是相同的，它們運(yùn)行著的都是一個(gè) kubelet 組件。唯一的區(qū)別在于，在 kubeadm init 的過(guò)程中，kubelet 啟動(dòng)后，Master 節(jié)點(diǎn)上還會(huì)自動(dòng)運(yùn)行 kube-apiserver、kube-scheduler、kube-controller-manger 這三個(gè)系統(tǒng) Pod。 所以，相比之下，部署 Worker 節(jié)點(diǎn)反而是最簡(jiǎn)單的，只需要兩步即可完成。
第一步，在所有 Worker 節(jié)點(diǎn)上執(zhí)行二、安裝，第1節(jié)的所有步驟。
第二步，執(zhí)行部署 Master 節(jié)點(diǎn)時(shí)生成的 kubeadm join 指令：

 >kubeadm join 10.168.0.6:6443 --token k0jhnn.a7l33i18ehbl1aze \
--discovery-token-ca-cert-hash sha256:064420e731f201b1601bb0bb39ccfef0e581a83449a043b60036cfb4537e5c67

通過(guò) Taint/Toleration 調(diào)整 Master 執(zhí)行 Pod 的策略 前面提到過(guò)，默認(rèn)情況下 Master 節(jié)點(diǎn)是不允許運(yùn)行用戶 Pod 的。而 Kubernetes 做到這一點(diǎn)，依靠的是 Kubernetes 的 Taint/Toleration 機(jī)制。 它的原理非常簡(jiǎn)單：一旦某個(gè)節(jié)點(diǎn)被加上了一個(gè) Taint，即被“打上了污點(diǎn)”，那么所有 Pod 就都不能在這個(gè)節(jié)點(diǎn)上運(yùn)行，因?yàn)?Kubernetes 的 Pod 都有“潔癖”。 除非，有個(gè)別的 Pod 聲明自己能“容忍”這個(gè)“污點(diǎn)”，即聲明了 Toleration，它才可以在這個(gè)節(jié)點(diǎn)上運(yùn)行。 其中，為節(jié)點(diǎn)打上“污點(diǎn)”（Taint）的命令是：

root@instance-ubuntu-1:~# kubectl taint nodes instance-ubuntu-1 foo=bar:NoSchedule

這時(shí)，該 node1 節(jié)點(diǎn)上就會(huì)增加一個(gè)鍵值對(duì)格式的 Taint，即：foo=bar:NoSchedule
。其中值里面的 NoSchedule，意味著這個(gè) Taint 只會(huì)在調(diào)度新 Pod 時(shí)產(chǎn)生作用，而不會(huì)影響已經(jīng)在 node1 上運(yùn)行的 Pod，哪怕它們沒(méi)有 Toleration。

現(xiàn)在回到我們已經(jīng)搭建的集群上來(lái)。這時(shí)，如果你通過(guò) kubectl describe 檢查一下 Master 節(jié)點(diǎn)的 Taint 字段，就會(huì)有所發(fā)現(xiàn)了：

root@instance-ubuntu-1:~# kubectl describe node master

5.部署Dashboard可視化插件
在 Kubernetes 社區(qū)中，有一個(gè)很受歡迎的 Dashboard 項(xiàng)目，它可以給用戶提供一個(gè)可視化的 Web 界面來(lái)查看當(dāng)前集群的各種信息。毫不意外，它的部署也相當(dāng)簡(jiǎn)單

kubectl create -f
https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

部署完成之后，我們就可以查看+Dashboard+對(duì)應(yīng)的+Pod+的狀態(tài)了

root@instance-ubuntu-1:~# kubectl get pods -n kube-system

kubernetes-dashboard-6948bdb78-f67xk 1/1 Running 0 1m

需要注意的是，由于 Dashboard 是一個(gè) Web Server，很多人經(jīng)常會(huì)在自己的公有云上無(wú)意地暴露+Dashboard 的端口，從而造成安全隱患。所以，1.7 版本之后的 Dashboard 項(xiàng)目部署完成后，默認(rèn)只能通過(guò) Proxy 的方式在本地訪問(wèn)。具體的操作，你可以查看 Dashboard+項(xiàng)目的官方文檔。 而如果你想從集群外訪問(wèn)這個(gè) Dashboard 的話，就需要用到 Ingress

6.部署容器存儲(chǔ)插件

為什么要部署Rook呢？
通常我們建立容器的時(shí)候需要把數(shù)據(jù)卷掛在到宿主機(jī)上的目錄，或者文件掛在到容器的Mount Namespace中，
從而實(shí)現(xiàn)主機(jī)和容器共享這些目錄，但是，如果你在另一臺(tái)機(jī)器上啟動(dòng)一個(gè)容器，就沒(méi)有辦法看到其它機(jī)器上的容器掛載的數(shù)據(jù)卷，這就是所謂的容器典型特征：無(wú)狀態(tài)。
這時(shí)候容器就需要持久化存儲(chǔ)，就是用來(lái)保存容器的狀態(tài)，存儲(chǔ)插件會(huì)在容器里掛載一個(gè)基于網(wǎng)絡(luò)或者其他機(jī)制的遠(yuǎn)程數(shù)據(jù)卷，使得在容器里創(chuàng)建的文件實(shí)際上是保存在遠(yuǎn)程存儲(chǔ)服務(wù)器上，或者是以分布式的方式保存在多個(gè)節(jié)點(diǎn)上，與當(dāng)前宿主機(jī)沒(méi)有任何綁定關(guān)系。這樣，無(wú)論你在其他哪個(gè)宿主機(jī)上啟動(dòng)新的容器，都可以請(qǐng)求掛載指定的持久化存儲(chǔ)卷，從而訪問(wèn)到數(shù)據(jù)卷里保存的內(nèi)容。這就是所謂持久化。

Rook 項(xiàng)目是一個(gè)基于 Ceph 的 Kubernetes 存儲(chǔ)插件（它后期也在加入對(duì)更多存儲(chǔ)實(shí)現(xiàn)的支持）。不過(guò)，不同于對(duì) Ceph 的簡(jiǎn)單封裝，Rook 在自己的實(shí)現(xiàn)中加入了水平擴(kuò)展、遷移、災(zāi)難備份、監(jiān)控等大量的企業(yè)級(jí)功能，使得這個(gè)項(xiàng)目變成了一個(gè)完整的、生產(chǎn)級(jí)別可用的容器存儲(chǔ)插件。

部署Ceph存儲(chǔ)后端

kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/ceph/operator.yaml

kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/ceph/cluster.yaml

在部署完成后，可以看到Rook項(xiàng)目會(huì)將自己的Pod防止在由它管理的兩個(gè)Namesoace當(dāng)中：

>root@instance-ubuntu-1:~# kubectl get pods -n rook-ceph-system
NAME                                                           READY     STATUS    RESTARTS   AGE
rook-ceph-agent-7cm42                                 1/1           Running          0             18s
rook-ceph-operator-78d4587c68c-7fj72         1/1           Running          0             44s
rook-discover-2ctcv                                        1/1           Running          0             18s

>root@instance-ubuntu-1:~# kubectl get pods -n rook-ceph
NAME                              READY     STATUS    RESTARTS   AGE
rook-ceph-mon0-kxrgh        1/1         Running          0              13s
rook-ceph-mon1-7dk2t        1/1         Running          0               5s

這樣，一個(gè)基于 Rook 持久化存儲(chǔ)集群就以容器的方式運(yùn)行起來(lái)了，而接下來(lái)在 Kubernetes 項(xiàng)目上創(chuàng)建的所有 Pod 就能夠通過(guò) Persistent Volume（PV）和 Persistent Volume Claim（PVC）的方式，在容器里掛載由 Ceph 提供的數(shù)據(jù)卷了。