Kubernetes雜記
兩個月前我在看《k8s in action》這本書，因為中間有段時間比較忙，沒有能認真看完。最近準備開始重新學習，並打算以深入到部分元件原始碼的方式來學習。不過看原始碼之前，我還是想再理清一下k8s的相關知識點，同時也能更好理解一下其設計思想。
我發現《k8s in action》這本書真的很好，很多理念都闡述得非常清楚，並在每章末尾附上了那一章的知識總結。當你需要回憶一下某個章節的大致內容時，只需要到那一章的末尾看看Summary那一節就可以了。把所有章節的總結內容放在一起，就基本概括了Kubernetes的大部分知識點。因此，下面我將書中這些總結性的文字大致翻譯過來，以便於經常回顧這些知識點和設計理念，但你看起來，就是沒有系統沒有邏輯的內容，因為都是一個個的知識點，沒有連成線、畫成面。
1
單體應用容易部署，但隨著時間的推移變得難維護，甚至不可擴充套件。
基於微服務的應用架構可以讓每個元件更容易部署，但難以配置和部署讓應用執行起來像一個單一的系統。
Linux容器提供了傳統虛擬機器相似的好處，但更輕量級，硬體資源利用率更高。
Docker給之前已有的Linux容器技術帶來的變化是，增加了容器應用的部署速度和降低部署複雜性。
Kubernetes把整個資料中心抽象成一個資源池提供給應用程式。
開發者可以將應用部署到Kubernetes叢集上，不需要運維人員輔助。
Kubernetes具有failover功能，系統運維人員可以睡好覺。
2
Pod可以執行多個程序，就像在沒有容器時候的物理主機一樣。
使用YAML或JSON描述符來建立Pod，然後可以檢視Pod狀態。
Lable和Lable Selector是用來組織Pod，並使得對多個Pod進行操作變得容易，同時可以將Pod排程到滿足某些特性的節點。
Annotations允許將更大塊的資料附加到Pod，無論是通過人為手動的，還是通過工具或者類庫。
Namespaces使得不同的team可以共享同一個Kubernetes叢集，而看起來卻像是在使用不同的叢集一樣。
你可以指定liveness探測方法，讓Kubernetes在你的容器處於非健康狀態(是否健康，由你的應用來定義)時重啟。
3
不要直接建立Pod，這樣它們會在誤刪除、節點失效時得不到重建。ReplicationController總是保證正在執行的Pod數等於所指定的數目。Pod的水平擴充套件就是修改ReplicationController上指定的副本數那麼簡單。
Pod不被ReplicationController擁有，如需，可在ReplicationController鍵進行遷移。
ReplicationController通過Pod的模板來建立一個新的Pod，修改模板對已經在執行的Pod沒有影響。
ReplicationController應該被ReplicaSet和Deployment替代，它們具有相同的功能，並有額外更強的特性。
ReplicationController和ReplicaSet將Pod隨機排程到某個節點，而DaemonSet保證每個節點上都執行單一例項的Pod，Pod在DaemonSet中定義。
執行批處理的Pod可以通過Kubernetes的Job資源來建立，而不是直接使用ReplicationController建立。
需要偶爾或定時執行的Jobs，可通過CronJob資源來建立。
4
將匹配某個Lable selector的多個Pod通過單一的IP、埠暴露出去。
從叢集外部訪問Service，需要將Service的type設定為NodePort或者LoadBalancer。
Pod可以通過環境變數來找到Service的IP和埠。
通過一個Ingress暴露多個HTTP Service。
使用Pod容器的readiness探測來決定一個Pod是否應該包含在service endpoints中。
建立一個包含多個容器的Pod，並讓這些容器操作同一個檔案的方法是給這個Pod新增一個Volume並mount到每一個容器中。
使用emptyDir捲來儲存臨時的、非持久化的資料，使用gitRepo捲來讓某個目錄在Pod啟動時被填充以Git倉庫上的內容。
使用hostPath捲來訪問位於主機上的檔案。
將外部儲存mount到一個卷，這樣這些資料在Pod重啟後依然存在。
將Pod和儲存設施解耦的辦法，是使用PersistentVolumes和PersistentVolumeClaims。
將配置資訊放到ConfigMap，使得配置和Pod的模板解耦。
將敏感的資料資訊保持在Secret以便安全傳送到容器內部。建立一個Docker-registry Secret，並使用它從私有映象庫中拉取映象。
通過maxSurge和maxUnavailable來控制滾動更新的比率。
5
API Server的客戶包括使用者(人)和執行在Pod中的應用。
執行在Pod的應用都有一個ServiceAccount。
Users、ServiceAccount和groups關聯。預設的，Pod執行在預設的ServiceAccount下，這是預設為每個namespace建立的。也已建立額外的ServiceAccount並與Pod關聯。
Roles和ClusterRoles定義了對每個resource可進行的操作。
RoleBindings和ClusterRoleBindings將Role和ClusterRoles繫結到users、groups、ServiceAccounts。每個Cluster都具有預設的ClusterRoles和預設的ClusterRoleBindings。
6
Pod可以使用節點的Linux 名稱空間而不是自己的。
容器可以被配置成以某個user/group的身份執行，而不是用定義在容器映象中的身份。
容器可以執行在privileged模式，可以直接訪問所在節點的裝置。容器可以只讀執行，這樣就無法往其檔案系統寫東西。
叢集級別的PodSecurityPolicy資源可以限制使用者建立對主機節點有安全威脅的Pod。
NetworkPolicy用來限制Pod的進、出網路包。
7
根據容器的CPU需求，未使用的CPU時間會被分配給容器，容器不會因為使用CPU過多而被殺掉，但會因為使用記憶體過多被殺掉。
在執行overcommit的系統，容器可能會被殺掉以釋放記憶體給更重要的Pod使用，具體是由Pod的QoS級別和真實記憶體使用情況來決定。
可以使用LimitRange物件來定義一個Pod最小、最大和預設的資源需求。
可以使用ResourceQuota物件來限制一個名稱空間內所有Pod對資源的需求。
要使得Pod可自動橫向擴充套件，可通過建立一個HorizontalPodAutoscaler物件並將其指向Deployment、ReplicaSet或ReplicationController並指定Pod對CPU的需求，同時還可以進行條件的自定義，然後在滿足條件時自動伸縮。目前不支援Pod垂直擴充套件。
8
自定義資源可以通過建立CustomResourceDefinition物件來註冊到API Server。自定義物件可被儲存、更新、返回、刪除，同時需要一個自定義的controller來讓這些物件得以生成。
Helm是一個包管理器，它使得部署已經存在的應用時不需要你構建資源的manifest，其實就是類似於yum。
微信掃碼，進入【技術人成長】社群逛逛。
