Google雲上用kubeadm搭建kubernetes集羣

1、環境準備
首先個人三個ubuntu雲主機的配置以下

cpu數量	內存	磁盤	Ubuntu
2	8G	20G	18.04LTS

並且能保證三臺機器都能鏈接外網，這裏用的谷歌雲主機，因此不用擔憂訪問外網問題，若是是本地搭建請參考另外一篇博文本地kubeadm搭建kubernetes集羣https://blog.51cto.com/13670314/2397626

這裏的全部命令都是在root用戶下操做的

2、安裝

1.在全部的節點上安裝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

上述安裝過程當中，kubeadm,kubectl,kubelet,kubernetes-cni這幾個二進制文件都會被自動安裝好。
直接使用+Ubuntu+的+docker.io+的安裝源，緣由是+Docker+公司每次發佈的最新的+Docker+CE（社區版）產品每每尚未通過+Kubernetes+項目的驗證，可能會有兼容性方面的問題。

2.部署kubernetes的Master節點

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

若是有報錯

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.

把apiServer改爲你對應的版本

再次運行kubeadm init --config kubeadm.yaml

這樣就能夠完成Master的部署了，稍等片刻，部署完成後，kubeadm會生成一條指令

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

kubeadm join 命令是用來給Master節點添加更多的Work節點的，記住此命令，下面會用到。

此外，kubeadm會提示提示第一次使用集羣所須要的配置命令。

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

由於Kubernetes 集羣默認須要加密方式訪問。因此，這幾條命令，就是將剛剛部署生成的 Kubernetes 集羣的安全配置文件，保存到當前用戶的.kube 目錄下，kubectl 默認會使用這個目錄下的受權信息訪問 Kubernetes 集羣。若是不這麼作的話，咱們每次都須要經過 export KUBECONFIG 環境變量告訴 kubectl 這個安全配置文件的位置。
如今，咱們就可使用 kubectl get命令來查看當前惟一一個節點的狀態了

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

主節點的狀態爲何會是NotReady，咱們查看一下master節點的詳細信息

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

會顯示

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

這是由於咱們尚未部署任何網絡插件

3.部署網絡插件

在 Kubernetes 項目「一切皆容器」的設計理念指導下，部署網絡插件很是簡單，只須要執行一句 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 3h57m
coredns-fb8b8dccf-p2p4k 1/1 Running 0 3h57m
etcd-instance-ubuntu-1 1/1 Running 0 3h56m
kube-apiserver-instance-ubuntu-1 1/1 Running 0 3h56m
kube-controller-manager-instance-ubuntu-1 1/1 Running 0 3h56m
kube-proxy-pksmg 1/1 Running 0 3h47m
kube-proxy-qb2cl 1/1 Running 0 3h57m
kube-proxy-z6q42 1/1 Running 0 3h47m
kube-scheduler-instance-ubuntu-1 1/1 Running 0 3h56m
kubernetes-dashboard-5f7b999d65-rkkqq 1/1 Running 0 3h29m
weave-net-f5kgb 2/2 Running 1 3h47m
weave-net-fxxq2 2/2 Running 0 3h47m
weave-net-nplfj 2/2 Running 0 3h50m

能夠看到全部pod都運行起來了 而剛剛部署的 Weave 網絡插件則在 kube-system 下面新建了一個名叫 weave-net-cmk27 的 Pod，通常來講，這些 Pod 就是容器網絡插件在每一個節點上的控制組件。 Kubernetes 支持容器網絡插件，使用的是一個名叫 CNI 的通用接口，它也是當前容器網絡的事實標準，市面上的全部容器網絡開源項目均可以經過 CNI 接入 Kubernetes，好比 Flannel、Calico、Canal、Romana 等等，它們的部署方式也都是相似的「一鍵部署」。至此，Kubernetes 的 Master 節點就部署完成了。若是你只須要一個單節點的 Kubernetes，如今你就可使用了。不過，在默認狀況下，Kubernetes 的 Master 節點是不能運行用戶 Pod 的，第4部分會講到如何處理。

4.部署 Kubernetes 的 Worker 節點
Kubernetes 的 Worker 節點跟 Master 節點幾乎是相同的，它們運行着的都是一個 kubelet 組件。惟一的區別在於，在 kubeadm init 的過程當中，kubelet 啓動後，Master 節點上還會自動運行 kube-apiserver、kube-scheduler、kube-controller-manger 這三個系統 Pod。 因此，相比之下，部署 Worker 節點反而是最簡單的，只須要兩步便可完成。
第一步，在全部 Worker 節點上執行2、安裝，第1節的全部步驟。
第二步，執行部署 Master 節點時生成的 kubeadm join 指令：

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

經過 Taint/Toleration 調整 Master 執行 Pod 的策略 前面提到過，默認狀況下 Master 節點是不容許運行用戶 Pod 的。而 Kubernetes 作到這一點，依靠的是 Kubernetes 的 Taint/Toleration 機制。 它的原理很是簡單：一旦某個節點被加上了一個 Taint，即被「打上了污點」，那麼全部 Pod 就都不能在這個節點上運行，由於 Kubernetes 的 Pod 都有「潔癖」。 除非，有個別的 Pod 聲明本身能「容忍」這個「污點」，即聲明瞭 Toleration，它才能夠在這個節點上運行。 其中，爲節點打上「污點」（Taint）的命令是：

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

這時，該 node1 節點上就會增長一個鍵值對格式的 Taint，即：foo=bar:NoSchedule
。其中值裏面的 NoSchedule，意味着這個 Taint 只會在調度新 Pod 時產生做用，而不會影響已經在 node1 上運行的 Pod，哪怕它們沒有 Toleration。

如今回到咱們已經搭建的集羣上來。這時，若是你經過 kubectl describe 檢查一下 Master 節點的 Taint 字段，就會有所發現了：

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

5.部署Dashboard可視化插件
在 Kubernetes 社區中，有一個很受歡迎的 Dashboard 項目，它能夠給用戶提供一個可視化的 Web 界面來查看當前集羣的各類信息。絕不意外，它的部署也至關簡單

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

部署完成以後，咱們就能夠查看+Dashboard+對應的+Pod+的狀態了

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

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

須要注意的是，因爲 Dashboard 是一個 Web Server，不少人常常會在本身的公有云上無心地暴露+Dashboard 的端口，從而形成安全隱患。因此，1.7 版本以後的 Dashboard 項目部署完成後，默認只能經過 Proxy 的方式在本地訪問。具體的操做，你能夠查看 Dashboard+項目的官方文檔。 而若是你想從集羣外訪問這個 Dashboard 的話，就須要用到 Ingress

6.部署容器存儲插件

爲何要部署Rook呢？
一般咱們創建容器的時候須要把數據卷掛在到宿主機上的目錄，或者文件掛在到容器的Mount Namespace中，
從而實現主機和容器共享這些目錄，可是，若是你在另外一臺機器上啓動一個容器，就沒有辦法看到其它機器上的容器掛載的數據卷，這就是所謂的容器典型特徵：無狀態。
這時候容器就須要持久化存儲，就是用來保存容器的狀態，存儲插件會在容器裏掛載一個基於網絡或者其餘機制的遠程數據卷，使得在容器裏建立的文件其實是保存在遠程存儲服務器上，或者是以分佈式的方式保存在多個節點上，與當前宿主機沒有任何綁定關係。這樣，不管你在其餘哪一個宿主機上啓動新的容器，均可以請求掛載指定的持久化存儲卷，從而訪問到數據卷裏保存的內容。這就是所謂持久化。

Rook 項目是一個基於 Ceph 的 Kubernetes 存儲插件（它後期也在加入對更多存儲實現的支持）。不過，不一樣於對 Ceph 的簡單封裝，Rook 在本身的實現中加入了水平擴展、遷移、災難備份、監控等大量的企業級功能，使得這個項目變成了一個完整的、生產級別可用的容器存儲插件。

部署Ceph存儲後端

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項目會將本身的Pod防止在由它管理的兩個Namesoace當中：

>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

這樣，一個基於 Rook 持久化存儲集羣就以容器的方式運行起來了，而接下來在 Kubernetes 項目上建立的全部 Pod 就可以經過 Persistent Volume（PV）和 Persistent Volume Claim（PVC）的方式，在容器裏掛載由 Ceph 提供的數據捲了。