kubernetes in action 讀後感
在2019年，偶然間接觸到kubernetes技術。起初我是拒絕的，kubernetes集羣搭建稍許繁瑣；配置應用的yaml文件如此複雜；各種資源類型目不暇接。隨着我一步步對kubernetes的瞭解，後來真香！複雜的應用就幾個配置文件聲明一下，等幾分鐘就可以訪問到服務了；服務保持不間斷的狀態；許多與kubernetes配套的互補的解決方案等等。
在之後，在我讀完《kubernetes in action》這本書之後，結合之前的瞭解，對kubernetes有了新的認識，現在就和大家分享一下：
kubernetes設計理念
1.解耦
- kubernetes有許多的控制組件（ReplicationController管理器，ReplicationSet管理器，Deployment管理器，StateFulset管理器，Node管理器，Service管理器，Endpoint管理器，Namespace管理器，persistentVolume管理器等等）各司其職。當我們向API服務器聲明瞭關於這些管理器的配置時，APIServer會接收到相應的REST請求併發出聲明，這些管理器會根據APIserver發出的聲明創建出相應的資源，他們彼此獨立，互不依賴（ReplicationSet管理器，Deployment管理器還是有一定聯繫的）。
2.資源集中管理
- kubernetes對於卷存儲，祕鑰，配置，pod資源用量，pod權限等等。它們都可以通過聲明成爲集羣資源或者一種約定，當我們創建pod時，可以通過簡單的方式使用這些資源以及自動的遵守設定的約定。
3.應用程序對kubernetes無感知
-
研發人員不用關注每個應用所處的環境，雖然說獲取環境信息不會像在真實的操作系統那樣方便，但是kubernetes也提供了極其方便的獲取環境變量的方式（通過pod內部與API服務器進行交互，獲取元數據）
-
應用之間的通信不用通過IP+端口，而是利用service做簡單的配置，即使pod重新調度，之前service配置的關係也會將請求轉發到相應的pod，應用程序不需要關係自己在哪個節點。
4.kubernetes對應用的狀態是聲明式的
- 我們如果想要集羣達到什麼狀態，只需要通過APIserver幫助我們聲明我們的請求，之後的工作由各組件相互協調最終達到你期望的樣子。例如我們聲明一個deployment資源：用戶通過kubectl 或其他API客戶端將請求發送給API Srtver。API Server將請求存儲在etcd中，etcd反回確認消息，之後API Server申明此請求，kubernetes的Deployment控制器通過“watch”來獲取API Server的變化，創建ReplicaSet控制器，控制器會基於ReplicationSet創建的pod模板創建pod資源。之後kube-scheduler爲請求所要創建的pod選擇一個node節點，並反饋給API Server，API Server將信息存儲到etcd中，收到確認消息之後再聲明此次調度信息。之後相應節點上的kubelet調用相應節點中的Docker Engine來創建啓動容器組成pod。創建完成後將信息返回給API Server並存儲到etcd中，etcd確認收到消息，返回確認信息給API Server，API Server將確認信息返回給kubelet。
5.冗餘機制
- 無論是pod親和性調度，或者應用更新，亦或是kubernetes核心組件（etcd，master等），它們都強調一種冗餘機制，即使節點宕機，應用更新失敗，腦裂等突發狀況，總會有至少一個pod持續提供服務，在一段時間後，kubernetes會盡量讓集羣達到你聲明的狀態。
6.易拓展性
- kubernetes的pod支持橫向拓展和縱向拓展，動態的抵禦流量或者負載對於應用的壓力
- kubernetes的組件etcd，網絡組件CNI，日誌收集插件，監控插件等等，都是可以用其他技術替代的（從kubernetes剛開發到現在版本，這些功能都在尋找更好的技術來實現，比如flannel，Prometheus，EFK，sidecar等），這使得kubernetes能夠很好的融合新的先進技術。
kubernetes可以解決什麼樣的問題
應用在開發人員完成並經歷過測試之後，需要經歷這幾個步驟纔可以很好的被用戶使用。
1.部署
-
將應用部署到哪裏
kubernetes提供了污點和污點容忍，pod與node之間親和性調度和非親和性調度，pod和pod親和性調度和非親和性調度，以及基於每個節點的各個參數算出的比重值進行調度
-
如何部署應用，以及解決應用的依賴性
在pod中加入init容器來保證容器順序啓動
-
檢測部署成功
可以在pod裏設置就緒探針，存活探針等，設置失敗策略
2.運行
-
應用保持一直運行的狀態
kubernetes裏ReplicationSet控制器會保證pod的數量符合預期，當有pod不能工作時會重新調度pod
-
應用的流量，負載
kubernetes提供了橫向和縱向擴容縮容（HPA，VPA）
-
應用掛掉之後，再次啓動保持原來的狀態
kubernetes允許創建有狀態的應用（Statefulset），它們掛載一個持久卷，當應用重啓或重新調度時，相應的持久卷會被重新掛載上
3.更新
-
無感知更新
可以使用deployment進行滾動更新以及控制滾動更新的速率，在更新出錯時，也可以快速進行回滾恢復（更新過後，會保存ReplicationSet副本，可以快速進行恢復）
-
灰度發佈
利用service控制器通過label對流量進行分配到匹配標籤的pod
4.維護
-
如何進行監控
利用Prometheus監控kubernetes集羣
-
如何進行日誌收集
EFK或者是sidecar
kubernetes我認爲不足的地方
1.yaml文件配置起來稍顯複雜，字段的命名方式有些比較奇怪（helm據說可以簡單一點）
2.在國內因爲防火牆的原因，總是出現鏡像下載緩慢，失敗的情況
結語
kubernetes所有的設計都是爲了解放人力，讓研發，測試，運維可以高效的協同工作，通過一項項配置使得原來手動做的工作變得自動，讓原來難以管理的容器變得易於管理。雖然從提出概念到現在已經經歷了許久時間，許多公司原來的架構體系完全可以滿足需求。但是當我打開一個個開源軟件軟件官網，在安裝配置選項都有kubernetes的身影，國內一些雲服務廠商也在支持kubernetes。kubernetes已經不是如此的神祕。我相信用過的都會說真香！