為什麼要用Kubernetes？
K8s控制節點-Master概念
K8s計算節點-Node概念
什麼是Pod？
為什麼要引入Pod?
建立一個Pod
零當機釋出應用必備知識：Pod三種探針
零當機必備知識：StartupProbe
零當機必備知識：Liveness和Readiness
零當機必備知識：Pod退出流程
零當機必備知識：PreStop的使用
容器管理
自動恢複
健康檢查
彈性擴容
内部通訊
高可用
Kubernetes是谷歌以Borg為前身，基于谷歌15年生産環境經驗的基礎上開源的一個項目，Kubernetes緻力于提供跨主機叢集的自動部署、擴充、高可用以及運作應用程式容器的平台。
k8s節點一般分為master節點和node節點，master節點一般三個足以，三個master節點承載成百上千node節點完全沒有問題，node節點可以橫向擴容
node節點用于部署應用程式，master節點不允許部署應用程式，它隻負責控制，排程工作
叢集的控制中樞，各個子產品之間資訊互動都需要經過Kube-APIServer，同時它也是叢集管理、資源配置、整個叢集安全機制的入口。
叢集的狀态管理器，保證Pod或其他資源達到期望值，也是需要和APIServer進行通信，在需要的時候建立、更新或删除它所管理的資源。
叢集的排程中心，它會根據指定的一系列條件，選擇一個或一批最佳的節點，然後部署我們的Pod。
鍵值資料庫，報錯一些叢集的資訊，一般生産環境中建議部署三個以上節點（奇數個）。
master節點在安裝完成之後，可能在很長一段時間都不會有任何的變化，是以在進行架設計的時候，要給足master節點資源，因為每次修改master節點是一件特别複雜的事情
我們在master節點綁定證書，每個證書綁定在master節點的ip位址或者主機名，如果我們在之前生成證書的時候沒有預留的話，那我們可能就需要重新生成一份證書，再把之前的證書都替換掉，而且還要替換node節點上面的證書，過程非常麻煩，是以一開始要給足資源，比如一次性給三台16核64G
Etcd也特别重要，一次性給足資源，未來五到十年，node節點的個數在500到1000之間的話，我們的master節點是完全不需要做任何變化的
node節點和master節點的差別：node節點比較具有動态性，添加、删除
Kubelet：負責監聽節點上Pod的狀态，同時負責上報節點和節點上面Pod的狀态，負責與Master節點通信，并管理節點上面的Pod。
Kube-proxy：負責Pod之間的通信和負載均衡，将指定的流量分發到後端正确的機器上。
監聽Master節點增加和删除service以及endpoint的消息，調用Netlink接口建立相應的IPVS規則。通過IPVS規則，将流量轉發至相應的Pod上。
Ipvs映射規則
主機通路node節點30372端口，通過ipvs規則，反向代理到kubernetes-dashboard上面的ip位址172.25.244.214的8443端口，是以就能通路到dashboard
監聽Master節點增加和删除service以及endpoint的消息，對于每一個Service，他都會建立一個iptables規則，将service的clusterIP代理到後端對應的Pod。
不推薦使用Iptables的原因是：當我們的規則特别多的時候，它的性能就會急劇下降
Calico：符合CNI标準的網絡插件，給每個Pod生成一個唯一的IP位址，并且把每個節點當做一個路由器。Cilium，eBPF
CoreDNS：用于Kubernetes叢集内部Service的解析，可以讓Pod把Service名稱解析成IP位址，然後通過Service的IP位址進行連接配接到對應的應用上。
Docker：容器引擎，負責對容器的管理。
Pod是Kubernetes中最小的單元，它由一組、一個或多個容器組成，每個Pod還包含了一個Pause容器，Pause容器是Pod的父容器，主要負責僵屍程序的回收管理，通過Pause容器可以使同一個Pod裡面的多個容器共享存儲、網絡、PID、IPC等。
檢視系統pod
Pause容器
因為一個應用不可能單個容器就能支撐的，需要很多微服務支撐，可能出現一種情況就是兩個服務，A服務和B服務之間需要網絡互通，延遲非常小，而且兩個服務有資料的依賴性，服務B需要用到服務A産生的檔案，如果直接用k8s裸機的話，服務A和服務B不一定會在同一台主控端上，當副本數非常大的時候，很難保證兩個檔案可以共享一個目錄
每個pod有一個唯一的ip位址，便于管理
從k8s的角度看，它作為一個非常流行的編排工具，需要相容很多的容器技術，是以通過pod管理不同的符合該标準的容器，而沒有直接操作容器
其他容器技術：https://kubernetes.io/docs/setup/production-environment/container-runtimes/
建立pod
檢視pod
檢視labels
label與yaml檔案中的配置一緻
删除pod
删除之後就找不到pod了，是以生産環境中一般不會直接使用，很難保證業務正常運作，一般使用進階資源deployment，daemonset，StatefulSets
Pod探針
Pod探針的檢測方式
StartupProbe
LivenessProbe
ReadinessProbe
StartupProbe：k8s1.16版本後新加的探測方式，用于判斷容器内應用程式是否已經啟動。如果配置了startupProbe，就會先禁止其他的探測，直到它成功為止，成功後将不在進行探測。
LivenessProbe：用于探測容器是否運作，如果探測失敗，kubelet會根據配置的重新開機政策進行相應的處理。若沒有配置該探針，預設就是success。
ReadinessProbe：一般用于探測容器内的程式是否健康，它的傳回值如果為success，那麼久代表這個容器已經完成啟動，并且程式已經是可以接受流量的狀态。
ExecAction
TCPSocketAction
HTTPGetAction
ExecAction：在容器内執行一個指令，如果傳回值為0，則認為容器健康。
TCPSocketAction：通過TCP連接配接檢查容器内的端口是否是通的，如果是通的就認為容器健康。
HTTPGetAction：通過應用程式暴露的API位址來檢查程式是否是正常的，如果狀态碼為200~400之間，則認為容器健康。
生産環境推薦使用HTTPGetAction
檢視coredns的deployment檔案
查找livenessProbe
它請求了8080端口的/health，如果檢測成功，則容器不會被重新開機
查找readinessProbe
它請求了8181端口的/ready，如果檢測成功，則可以加上endpoint，開始接受流量，開始工作
探針檢查參數配置
為什麼要引入StartupProbe？
如果容器啟動特别慢，單獨配置一個StartupProbe，它會先禁用另外兩個探針，直到程式啟動完成，再檢測它的狀态
編輯pod.yaml，取消注釋
啟動容器
修改pod.yaml
建構容器
擷取IP
通路nginx
編輯pod.yaml
可以看到如果exec的指令不存在會報錯Liveness probe failed
修改exec指令為ls
重新建立
可以看到健康檢查通過
Liveness和Readiness推薦使用接口級健康檢查，參考 coredns
可以看到 coredns 的 livenessProbe 請求了一個 /health 的接口，readinessProbe 請求了一個 /ready 的接口
使用者執行删除操作：kubectl delete po nginx
執行PreStop的指令
Endpoint删除該Pod的IP位址
Pod變成Terminating
Pod變成Terminating之後有一個寬限期，讓我們做一些清理的動作，或者後置的動作
Prestop：先去請求eureka接口，把自己的IP位址和端口号，進行下線，eureka從系統資料庫中删除該應用的IP位址。然後容器進行sleep 90；kill <code>pgrep java</code>
如果sleep時間過長，需要修改terminationGracePeriodSeconds
檢視pod退出時間
可以看到隻執行了40s，并沒有sleep 90s，是以我們需要配置terminationGracePeriodSeconds
設定 terminationGracePeriodSeconds
可以看到退出時間延長了，但是也沒有真正的執行sleep 90s，是以配置的時候需要注意一下，因為k8s并不知道你執行了什麼操作，無法判斷PreStop的執行時間，是以會強制性的删除
http://www.kubeasy.com/
本作品采用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協定進行許可。
歡迎轉載、使用、重新釋出，但務必保留文章署名 鄭子銘 （包含連結： http://www.cnblogs.com/MingsonZheng/ ），不得用于商業目的，基于本文修改後的作品務必以相同的許可釋出。