二進制Metrics&Dashboard安裝
二進制高可用叢集可用性驗證
生産環境k8s叢集關鍵性配置
Bootstrapping: Kubelet啟動過程
Bootstrapping: CSR申請和證書頒發原理
Bootstrapping: 證書自動續期原理
安裝CoreDNS
安裝Metrics Server
安裝dashboard
安裝對應版本（推薦）
如果更改了k8s service的網段需要将coredns的serviceIP改成k8s service網段的第十個IP
安裝coredns
安裝最新版CoreDNS（不推薦）
檢視狀态
狀态
強制删除一直處于Terminating的pod
在新版的Kubernetes中系統資源的采集均使用Metrics-server，可以通過Metrics采集節點和Pod的記憶體、磁盤、CPU和網絡的使用率。
安裝metrics server
等待metrics server啟動然後檢視狀态
節點狀态
檢視pod狀态
pod狀态
安裝指定版本dashboard
安裝最新版dashboard
登入dashboard
Dashboard用于展示叢集中的各類資源，同時也可以通過Dashboard實時檢視Pod的日志和在容器中執行一些指令等。
官方GitHub位址：https://github.com/kubernetes/dashboard
可以在官方dashboard檢視到最新版dashboard
建立管理者使用者
執行
在谷歌浏覽器（Chrome）啟動檔案中加入啟動參數，用于解決無法通路Dashboard的問題，因為使用的證書是自簽名（屬性->快捷方式->目标，粘貼到最後）
更改dashboard的svc為NodePort：
修改 type: ClusterIP 為 type:NodePort
修改完成之後會暴露一個端口号，檢視端口号：
端口号
根據自己的執行個體端口号，通過任意安裝了kube-proxy的主控端或者VIP的IP+端口即可通路到dashboard：通路Dashboard：https://192.168.232.236:31874（請更改18282為自己的端口），選擇登入方式為令牌（即token方式）
檢視token值：
token值
安裝busybox
Pod必須能解析Service
Pod必須能解析跨namespace的Service
每個節點都必須要能通路Kubernetes的kubernetes svc 443和kube-dns的service 53
Pod和Pod之前要能通（同namespace能通信、跨namespace能通信、跨機器能通信）
叢集安裝成功後預設的kubernetes server
每個節點都必須要能通路Kubernetes的kubernetes svc 443和kube-dns的service 53（發送鍵輸入到所有的會話）
Pod和Pod之前要能通（同namespace能通信、跨namespace能通信、跨機器能通信）（取消發送鍵輸入到所有的會話）
建立一個帶有三個副本的deployment
docker配置
controller-manager配置
kubelet配置
kubelet-conf.yml
安裝總結
（發送鍵輸入到所有的會話）
更新配置
注釋新版本已經預設配置，設定證書過期時間
（發送鍵輸入到所有的會話，取消node節點）
k8s預設加密方式會被識别為漏洞，需要修改加密方式
kubelet下載下傳鏡像的deadline，避免重複循環加載
檢視日志
驗證
kubeadm
二進制
自動化安裝
安裝需要注意的細節
Master節點安裝不需要寫自動化。
添加Node節點，playbook。
上面的細節配置
生産環境中etcd一定要和系統盤分開，一定要用ssd硬碟。
Docker資料盤也要和系統盤分開，有條件的話可以使用ssd硬碟
Bootstrapping：自動為node節點頒發證書
二進制高可用安裝生成證書的時候，我們為每個k8s元件都生成了一個kubeconfig檔案，比如controller-manager.kubeconfig，配置中儲存了apiserver的一些資訊，以及它去連接配接apiserver的證書
kube-controller-manager.service指定了kubeconfig，元件啟動的時候會通過config檔案去連接配接apiserver進行認證，通訊
kube-controller-manager.service和kube-scheduler.service是我們自己頒發證書，但是kubelet不建議通過這種方式，建議使用TLS BootStrapping，它會自動地為node節點的kubelet頒發證書，那麼它是如何生成的呢？
使用node02節點舉例
當我們配置一個節點的時候，節點上面是沒有kubelet.kubeconfig檔案的，它是通過bootstrap-kubelet.kubeconfig與apiserver進行互動，然後自動申請了一個kubelet.kubeconfig檔案，kubelet啟動的時候如果缺少kubelet.kubeconfig檔案，就會這樣申請
删除kubelet.kubeconfig
檢視kubelet配置檔案
在配置中可以看到指定了bootstrap-kubeconfig檔案
指定了kubeconfig檔案，但是這個檔案是沒有的，kubelet啟動的時候會通過前面描述的方式申請一個新的kubelet.kubeconfig
重新開機kubelet，可以看到生成了kubelet.kubeconfig證書，生成之後就可以和apiserver進行互動
TLS BootStrapping 官方文檔：https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#initialization-process
在一個k8s叢集中，工作節點的元件kubelet和kube-proxy需要連接配接master節點的元件，尤其是apiserver。為了確定連接配接是私有的，強烈建議為每一個用戶端配置一個TLS證書在所有的節點上
kubelet啟動過程
查找kubeconfig檔案，檔案一般位于/etc/kubernetes/kubelet.kubeconfig
從kubeconfig檔案中檢索APIServer的URL和證書
然後去和APIServer進行互動
檢視證書
檢視kubelet.kubeconfig證書有效期：
然後使用OpenSSL即可檢視證書過期時間（100年有效期）：
官方文檔：https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#bootstrap-initialization
1、 Kubelet啟動
2、 Kubelet檢視kubelet.kubeconfig檔案，假設沒有這個檔案
3、 Kubelet會檢視本地的bootstrap.kubeconfig
4、 Kubelet讀取bootstrap.kubeconfig檔案，檢索apiserver的url和一個token
5、 Kubelet連結apiserver，使用這個token進行認證
a) Apiserver會識别tokenid，apiserver會檢視該tokenid對于的bootstrap的一個secret
secret就是二進制高可用安裝叢集的時候建立的bootstrap.secret.yaml
如果要修改bootstrap.secret.yaml的token-id和token-secret，需要保證 c8ad9c 字元串一緻的，并且位數是一樣的。還要保證上個指令的黃色字型：c8ad9c.2e4d610cf3e7426e與你修改的字元串要一緻
根據字尾c8ad9c找到token
讀取secret中的内容，得到token-id，token-secret
解密token-id，與配置檔案kubectl config中的token=c8ad9c.2e4d610cf3e7426e的字首一緻
解密token-secret，與配置檔案kubectl config中的token=c8ad9c.2e4d610cf3e7426e的字尾一緻
驗證通過之後才會進入下一步
b) 找個這個secret中的一個字段auth-extra-groups，apiserver把這個token識别成一個username，名稱是system:bootstrap:，屬于system:bootstrappers這個組，這個組具有申請csr的權限，該組的權限綁定在一個叫system:node-bootstrapper的clusterrole
解密auth-extra-groups查詢組名
clusterrole是k8s叢集級别的權限控制，它作用整個k8s叢集
clusterrolebinding是叢集權限的綁定，它可以幫某個clusterrole綁定到一個使用者、組或者seviceaccount
檢視clusterrole
檢視system:node-bootstrapper
檢視clusterrolebinding
可以看到clusterrolebinding把一個名為system:node-bootstrapper的ClusterRole綁定到一個名為system:bootstrappers:default-node-token的Group
檢視Group是否一緻，解密auth-extra-groups查詢組名
c) CSR：相當于一個申請表，可以拿着這個申請表去申請我們的證書。
6、 經過上面的認證，kubelet就有了一個建立和檢索CSR的權限
7、 Kubelet為自己建立一個CSR，名稱為kubernetes.io/kube-apiserver-client-kubelet
8、 CSR被允許有兩種方式：
a) K8s管理者使用kubectl手動的頒發證書
b) 如果配置了相關權限，kube-controller-manager會自動同意。
i. Controller-manager有一個CSRApprovingController。他會校驗kubelet發來的csr的username和group是否有建立csr的權限，而且還要驗證簽發着是否是kubernetes.io/kube-apiserver-client-kubelet
ii. Controller-manager同意CSR請求
9、 CSR被同意後，controller-manager建立kubelet的證書檔案
10、 Controller-manager将證書更新至csr的status字段
11、 Kubelet從apiserver獲驗證書
12、 Kubelet從擷取到的key和證書檔案建立kubelet.kubeconfig
13、 Kubelet啟動完成并正常工作
14、 可選：如果配置了自動續期，kubelet會在證書檔案過期的時候利用之前的kubeconfig檔案去申請一個新的證書，相當于續約。
15、 新的證書被同意或簽發，取決于我們的配置
檢視node-autoapprove-certificate-rotation
檢視名為system:certificates.k8s.io:certificatesigningrequests:selfnodeclient的ClusterRole
a) Kubelet建立的CSR是屬于一個組織：system:nodes
b) CN（比如域名）：system:nodes:主機名
http://www.kubeasy.com/
本作品采用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協定進行許可。
歡迎轉載、使用、重新釋出，但務必保留文章署名 鄭子銘 （包含連結： http://www.cnblogs.com/MingsonZheng/ ），不得用于商業目的，基于本文修改後的作品務必以相同的許可釋出。