Kubernetes 運維學習筆記

一、Kubernetes 介紹

Kubernetes是一個全新的基於容器技術的分散式架構領先方案, 它是Google在2014年6月開源的一個容器叢集管理系統，使用Go語言開發，Kubernetes也叫K8S。K8S是Google內部一個叫Borg的容器叢集管理系統衍生出來的，Borg已經在Google大規模生產執行十年之久。K8S主要用於自動化部署、擴充套件和管理容器應用，提供了資源排程、部署管理、服務發現、擴容縮容、監控等一整套功能。2015年7月，Kubernetes v1.0正式釋出，截止到2017年9月29日最新穩定版本是v1.8。Kubernetes目標是讓部署容器化應用簡單高效。

Kubernetes最初源於谷歌內部的Borg，提供了面向應用的容器叢集部署和管理系統。Kubernetes 的目標旨在消除編排物理/虛擬計算，網路和儲存基礎設施的負擔，並使應用程式運營商和開發人員完全將重點放在以容器為中心的原語上進行自助運營。Kubernetes 也提供穩定、相容的基礎（平臺），用於構建定製化的workflows 和更高階的自動化任務。

Kubernetes 具備完善的叢集管理能力，包括多層次的安全防護和准入機制、多租戶應用支撐能力、透明的服務註冊和服務發現機制、內建負載均衡器、故障發現和自我修復能力、服務滾動升級和線上擴容、可擴充套件的資源自動排程機制、多粒度的資源配額管理能力。Kubernetes 還提供完善的管理工具，涵蓋開發、部署測試、運維監控等各個環節。

二、Kubernetes主要功能

Kubernetes是docker容器用來編排和管理的工具，它是基於Docker構建一個容器的排程服務，提供資源排程、均衡容災、服務註冊、動態擴縮容等功能套件。Kubernetes提供應用部署、維護、 擴充套件機制等功能，利用Kubernetes能方便地管理跨機器執行容器化的應用，其主要功能如下：

資料卷: Pod中容器之間共享資料，可以使用資料卷。

應用程式健康檢查: 容器內服務可能程序堵塞無法處理請求，可以設定監控檢查策略保證應用健壯性。

複製應用程式例項: 控制器維護著Pod副本數量，保證一個Pod或一組同類的Pod數量始終可用。

彈性伸縮: 根據設定的指標（CPU利用率）自動縮放Pod副本數。

服務發現: 使用環境變數或DNS服務外掛保證容器中程式發現Pod入口訪問地址。

負載均衡: 一組Pod副本分配一個私有的叢集IP地址，負載均衡轉發請求到後端容器。在叢集內部其他Pod可通過這個ClusterIP訪問應用。

滾動更新: 更新服務不中斷，一次更新一個Pod，而不是同時刪除整個服務。

服務編排: 通過檔案描述部署服務，使得應用程式部署變得更高效。

資源監控: Node節點元件整合cAdvisor資源收集工具，可通過Heapster彙總整個叢集節點資源資料，然後儲存到InfluxDB時序資料庫，再由Grafana展示。

提供認證和授權: 支援屬性訪問控制（ABAC）、角色訪問控制（RBAC）認證授權策略。

除此之外, Kubernetes主要功能還體現在:
-使用Docker對應用程式包裝(package)、例項化(instantiate)、執行(run)。
- 將多臺Docker主機抽象為一個資源，以叢集的方式執行、管理跨機器的容器，包括任務排程、資源管理、彈性伸縮、滾動升級等功能。
-使用編排系統（YAML File）快速構建容器叢集，提供負載均衡，解決容器直接關聯及通訊問題
-解決Docker跨機器容器之間的通訊問題。
- 自動管理和修復容器，簡單說，比如建立一個叢集，裡面有十個容器，如果某個容器異常關閉，那麼，會嘗試重啟或重新分配容器，始終保證會有十個容器在執行，反而殺死多餘的。Kubernetes的自我修復機制使得容器叢集總是執行在使用者期望的狀態.當前Kubernetes支援GCE、vShpere、CoreOS、OpenShift。

kubernetes的叢集至少有兩個主機組成：master + node ，即為master/node架構。master為叢集的控制面板，master主機需要做冗餘，一般建議為3臺；而node主機不需要做冗餘，因為node的主要作用是執行pod，貢獻計算能力和儲存能力，而pod控制器會自動管控pod資源，如果資源少，pod控制器會自動建立pod，即pod控制器會嚴格按照使用者指定的副本來管理pod的數量。客戶端的請求下發給master,即把建立和啟動容器的請求發給master，master中的排程器分析各node現有的資源狀態，把請求呼叫到對應的node啟動容器。

可以理解為kubernetes把容器抽象為pod來管理1到多個彼此間有非常緊密聯絡的容器，但是LAMP的容器主機A,M,P只是有關聯，不能說是非常緊密聯絡，因此A,M,P都要執行在三個不同的pod上。在kubernetes中，要執行幾個pod，是需要定義一個配置檔案，在這個配置檔案裡定義用哪個控制器啟動和控制幾個pod，在每個pod裡要定義那幾臺容器，kubernetes通過這個配置檔案，去建立一個控制器，由此控制器來管控這些pod,如果這些pod的某幾個down掉後，控制器會通過健康監控功能，隨時監控pod，發現pod異常後,根據定義的策略進行操作，即可以進行自愈。

kubernetes內部需要5套證書，手動建立或者自動生成，分別為：
1.etcd內部通訊需要一套ca和對應證書。
2.etcd與外部通訊也要有一套ca和對應證書。
3.APIserver間通訊需要一套證書。
4.apiserver與node間通訊需要一套證書。
5.node和pod間通訊需要一套ca證書。

目前來說還不能實現把所有的業務都遷到kubernetes上，如儲存，因為這個是有狀態應用，出現錯誤排查很麻煩，所以目前kubernetes主要是執行無狀態應用。

所以一般而言，負載均衡器執行在kubernetes之外，nginx或者tomcat這種無狀態的應用運行於kubernetes叢集內部，而資料庫如mysql，zabbix，zoopkeeper等有狀態的，一般運行於kubernetes外部，通過網路連線，實現kubernetes叢集的pod呼叫這些外部的有狀態應用。

三、Kubernetes架構和元件

kubernetes主要由以下幾個核心元件組成：
etcd: 叢集的主資料庫，儲存了整個叢集的狀態; etcd負責節點間的服務發現和配置共享。etcd分散式鍵值儲存系統, 用於保持叢集狀態，比如Pod、Service等物件資訊。
kube-apiserver: 提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API註冊和發現等機制；這是kubernetes API，作為叢集的統一入口，各元件協調者，以HTTPAPI提供介面服務，所有物件資源的增刪改查和監聽操作都交給APIServer處理後再提交給Etcd儲存。
kube-controller-manager: 負責維護叢集的狀態，比如故障檢測、自動擴充套件、滾動更新等；它用來執行整個系統中的後臺任務，包括節點狀態狀況、Pod個數、Pods和Service的關聯等, 一個資源對應一個控制器，而ControllerManager就是負責管理這些控制器的。
kube-scheduler: 資源排程，按照預定的排程策略將Pod排程到相應的機器上；它負責節點資源管理，接受來自kube-apiserver建立Pods任務，並分配到某個節點。它會根據排程演算法為新建立的Pod選擇一個Node節點。
kubectl: 客戶端命令列工具，將接受的命令格式化後傳送給kube-apiserver，作為整個系統的操作入口。
kubelet: 負責維護容器的生命週期，負責管理pods和它們上面的容器，images映象、volumes、etc。同時也負責Volume（CVI）和網路（CNI）的管理；kubelet執行在每個計算節點上，作為agent，接受分配該節點的Pods任務及管理容器，週期性獲取容器狀態，反饋給kube-apiserver; kubelet是Master在Node節點上的Agent，管理本機執行容器的生命週期，比如建立容器、Pod掛載資料卷、下載secret、獲取容器和節點狀態等工作。kubelet將每個Pod轉換成一組容器。
container runtime: 負責映象管理以及Pod和容器的真正執行（CRI）；
kube-proxy: 負責為Service提供cluster內部的服務發現和負載均衡；它執行在每個計算節點上，負責Pod網路代理。定時從etcd獲取到service資訊來做相應的策略。它在Node節點上實現Pod網路代理，維護網路規則和四層負載均衡工作。
docker或rocket(rkt): 執行容器。

除了上面的幾個核心組建, 還有一些常用外掛(Add-ons)：
kube-dns: 負責為整個叢集提供DNS服務;
Ingress Controller: 為服務提供外網入口;
Heapster: 提供資源監控;
Dashboard: 提供GUI;
Federation: 提供跨可用區的叢集;
Fluentd-elasticsearch: 提供叢集日誌採集、儲存與查詢;

其中:
master元件包括: kube-apiserver, kube-controller-manager, kube-scheduler;
Node元件包括: kubelet, kube-proxy, docker或rocket(rkt);
第三方服務：etcd

Kubernetes Master控制組件，排程管理整個系統（叢集），包含如下元件:
Kubernetes API Server: 作為Kubernetes系統入口，其封裝了核心物件的增刪改查操作，以RESTful API介面方式提供給外部客戶和內部元件呼叫,維護的REST物件持久化到Etcd中儲存。
Kubernetes Scheduler: 為新建立的Pod進行節點(node)選擇(即分配機器)，負責叢集的資源排程。元件抽離，可以方便替換成其他排程器。
Kubernetes Controller: 負責執行各種控制器，目前已經提供了很多控制器來保證Kubernetes的正常執行。
Replication Controller: 管理維護Replication Controller，關聯Replication Controller和Pod，保證Replication Controller定義的副本數量與實際執行Pod數量一致。
Node Controller: 管理維護Node，定期檢查Node的健康狀態，標識出(失效|未失效)的Node節點。
Namespace Controller: 管理維護Namespace，定期清理無效的Namespace，包括Namesapce下的API物件，比如Pod、Service等。
Service Controller: 管理維護Service，提供負載以及服務代理。
EndPoints Controller: 管理維護Endpoints，關聯Service和Pod，建立Endpoints為Service的後端，當Pod發生變化時，實時更新Endpoints (即Pod Ip + Container Port)。
Service Account Controller: 管理維護Service Account，為每個Namespace建立預設的Service Account，同時為Service Account建立Service Account Secret。
Persistent Volume Controller: 管理維護Persistent Volume和Persistent Volume Claim，為新的Persistent Volume Claim分配Persistent Volume進行繫結，為釋放的Persistent Volume執行清理回收。
Daemon Set Controller: 管理維護Daemon Set，負責建立Daemon Pod，保證指定的Node上正常的執行Daemon Pod。
Deployment Controller: 管理維護Deployment，關聯Deployment和Replication Controller，保證執行指定數量的Pod。當Deployment更新時，控制實現Replication Controller和　Pod的更新。
Job Controller: 管理維護Job，為Jod建立一次性任務Pod，保證完成Job指定完成的任務數目
Pod Autoscaler Controller: 實現Pod的自動伸縮，定時獲取監控資料，進行策略匹配，當滿足條件時執行Pod的伸縮動作。

Kubernetes Node執行節點，執行管理業務容器，包含如下元件:
Kubelet: 負責管控容器，Kubelet會從Kubernetes API Server接收Pod的建立請求，啟動和停止容器，監控容器執行狀態並彙報給Kubernetes API Server。
Kubernetes Proxy: 負責為Pod建立代理服務，Kubernetes Proxy會從Kubernetes API Server獲取所有的Service資訊，並根據Service的資訊建立代理服務，實現Service到Pod的請求路由和轉發，從而實現Kubernetes層級的虛擬轉發網路。
Docker: Node上需要執行容器服務

Kubernetes的分層設計理念
Kubernetes設計理念和功能類似Linux的分層架構，如下圖:

核心層：Kubernetes最核心的功能，對外提供API構建高層的應用，對內提供外掛式應用執行環境;
應用層：部署(無狀態應用、有狀態應用、批處理任務、叢集應用等)和路由(服務發現、DNS解析等);
管理層：系統度量(如基礎設施、容器和網路的度量)，自動化(如自動擴充套件、動態Provision等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy等);
介面層：kubectl命令列工具、客戶端SDK以及叢集聯邦;
生態系統：在介面層之上的龐大容器叢集管理排程的生態系統，可以劃分為兩個範疇:
- Kubernetes外部：日誌、監控、配置管理、CI、CD、Workflow、FaaS、OTS應用、ChatOps等;
- Kubernetes內部：CRI、CNI、CVI、映象倉庫、Cloud Provider、叢集自身的配置和管理等;

四、Kubernetes基本物件概念

Kubernetes中的大部分概念Node、Pod、Replication Controller、Service等都可以看作一種“資源物件”，幾乎所有的資源物件都可以通過kubectl工具（API呼叫）執行增、刪、改、查等操作並將其儲存在etcd中持久化儲存。從這個角度來看，kubernetes其實是一個高度自動化的資源控制系統，通過跟蹤對比etcd庫裡儲存的“資源期望狀態”與當前環境中的“實際資源狀態”的差異來實現自動控制和自動糾錯的高階功能。

基本物件：
Pod: Pod是最小部署單元，一個Pod有一個或多個容器組成，Pod中容器共享儲存和網路，在同一臺Docker主機上執行; Pod 中的容器會作為一個整體被Master排程到一個Node上執行。pod 是一組container，pod裡面的container是共享網路棧和儲存卷等資源，是一個整體. pod 可以認為是容器組的概念，裡面有個infra container 負責pod內所有container 共享 namespace。docker的容器可以類比成OS中的程序，而K8S的pod則更像是OS中的“程序組”概念。
Service: Service一個應用服務抽象，定義了Pod邏輯集合和訪問這個Pod集合的策略。Service代理Pod集合對外表現是為一個訪問入口，分配一個叢集IP地址，來自這個IP的請求將負載均衡轉發後端Pod中的容器。Service通過LableSelector選擇一組Pod提供服務。
Volume: 資料卷，共享Pod中容器使用的資料。
Namespace: 名稱空間將物件邏輯上分配到不同Namespace，可以是不同的專案、使用者等區分管理，並設定控制策略，從而實現多租戶。名稱空間也稱為虛擬叢集。
Lable: 標籤用於區分物件（比如Pod、Service），鍵/值對存在；每個物件可以有多個標籤，通過標籤關聯物件。

基於基本物件更高層次抽象：
ReplicaSet:下一代ReplicationController。確保任何給定時間指定的Pod副本數量，並提供宣告式更新等功能。RC與RS唯一區別就是lableselector支援不同，RS支援新的基於集合的標籤，RC僅支援基於等式的標籤。
Deployment: Deployment是一個更高層次的API物件，它管理ReplicaSets和Pod，並提供宣告式更新等功能。官方建議使用Deployment管理ReplicaSets，而不是直接使用ReplicaSets，這就意味著可能永遠不需要直接操作ReplicaSet物件。負責無狀態應用pod控制，支援二級控制器（HPA，HorizontalPodAutoscaler水平pod自動控制器）。
StatefulSet: StatefulSet適合永續性的應用程式，有唯一的網路識別符號（IP），持久儲存，有序的部署、擴充套件、刪除和滾動更新。負責有狀態應用pod控制。
DaemonSet: DaemonSet確保所有（或一些）節點運行同一個Pod。當節點加入Kubernetes叢集中，Pod會被排程到該節點上執行，當節點從叢集中移除時，DaemonSet的Pod會被刪除。刪除DaemonSet會清理它所有建立的Pod。
Job: 一次性任務，執行完成後Pod銷燬，不再重新啟動新容器。還可以任務定時執行。Kubernetes中的Job 用於執行結束就刪除的應用。

API物件是K8s叢集中管理操作單元。K8s集群系每支援一項新功能，引入一項新技術，一定會新引入對應的API物件，支援對該功能的管理操作。例如副本集Replica Set對應的API物件是RS。Kubernetes中所有的配置都是通過API物件的spec去設定的，也就是使用者通過配置系統的理想狀態來改變系統，這是k8s重要設計理念之一，即所有的操作都是宣告式 (Declarative) 的而不是命令式(Imperative)的。宣告式操作在分散式系統中好處是穩定，不怕丟操作或執行多次，例如設定副本數為3的操作執行多次也還是一個結果, 而給副本數加1的操作就不是宣告式的, 執行多次結果就錯了。

Cluster
Cluster 是計算、儲存和網路資源的集合，Kubernetes 利用這些資源執行各種基於容器的應用

Master
kubernetes叢集的管理節點，負責管理叢集，提供叢集的資源資料訪問入口。擁有Etcd儲存服務（可選），執行Api Server程序，Controller Manager服務程序及Scheduler服務程序，關聯工作節點Node。Kubernetes API server提供HTTP Rest介面的關鍵服務程序，是Kubernetes裡所有資源的增、刪、改、查等操作的唯一入口。也是叢集控制的入口程序；Kubernetes Controller Manager是Kubernetes所有資源物件的自動化控制中心；Kubernetes Schedule是負責資源排程（Pod排程）的程序.

Node
Node是Kubernetes叢集架構中執行Pod的服務節點（亦叫agent或minion）。Node是Kubernetes叢集操作的單元，用來承載被分配Pod的執行，是Pod執行的宿主機。關聯Master管理節點，擁有名稱和IP、系統資源資訊。執行docker eninge服務，守護程序kunelet及負載均衡器kube-proxy. 每個Node節點都執行著以下一組關鍵程序:
-kubelet：負責對Pod對於的容器的建立、啟停等任務
-kube-proxy：實現Kubernetes Service的通訊與負載均衡機制的重要元件
-Docker Engine（Docker）：Docker引擎，負責本機容器的建立和管理工作

Node節點可以在執行期間動態增加到Kubernetes叢集中，預設情況下，kubelet會想master註冊自己，這也是Kubernetes推薦的Node管理方式，kubelet程序會定時向Master彙報自身情報，如作業系統、Docker版本、CPU和記憶體，以及有哪些Pod在執行等等，這樣Master可以獲知每個Node節點的資源使用情況，冰實現高效均衡的資源排程策略。、

Pod
運行於Node節點上，若干相關容器的組合。Pod內包含的容器執行在同一宿主機上，使用相同的網路名稱空間、IP地址和埠，能夠通過localhost進行通。Pod是Kurbernetes進行建立、排程和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個Pod可以包含一個容器或者多個相關容器。

Pod其實有兩種型別：普通Pod和靜態Pod，後者比較特殊，它並不存在Kubernetes的etcd儲存中，而是存放在某個具體的Node上的一個具體檔案中，並且只在此Node上啟動。普通Pod一旦被建立，就會被放入etcd儲存中，隨後會被Kubernetes Master排程到摸個具體的Node上進行繫結，隨後該Pod被對應的Node上的kubelet程序例項化成一組相關的Docker容器並啟動起來。在預設情況下，當Pod裡的某個容器停止時，Kubernetes會自動檢測到這個問起並且重啟這個Pod（重啟Pod裡的所有容器），如果Pod所在的Node宕機，則會將這個Node上的所有Pod重新排程到其他節點上。

Pod是在K8s叢集中執行部署應用或服務的最小單元，它是可以支援多容器的。Pod的設計理念是支援多個容器在一個Pod中共享網路地址和檔案系統，可以通過程序間通訊和檔案共享這種簡單高效的方式組合完成服務.比如你執行一個作業系統發行版的軟體倉庫，一個Nginx容器用來發布軟體，另一個容器專門用來從源倉庫做同步，這兩個容器的映象不太可能是一個團隊開發的，但是他們一塊兒工作才能提供一個微服務；這種情況下，不同的團隊各自開發構建自己的容器映象，在部署的時候組合成一個微服務對外提供服務。

kubernetes的最核心功能就是為了執行pod，其他元件是為了pod能夠正常執行而執行的。pod可以分為兩類：
1.自主式pod
2.控制器管理的pod

一個pod上有兩類元資料，label 和 annotation
label：標籤，對資料型別和程度要求嚴格，
annotation：註解，用於儲存自己定義的複雜元資料，用來描述pod的屬性

外部請求訪問內部的pod經過了三級轉發，第一級先到nodeip（宿主機ip）對應的埠，然後被轉為cluster ip的service 埠，然後轉換為PodIP的containerPort。

Kubernetes 引入 Pod 主要基於下面兩個目的：
-可管理性
有些容器天生就是需要緊密聯絡, 一起工作。Pod 提供了比容器更高層次的抽象，將它們封裝到一個部署單元中。Kubernetes 以 Pod 為最小單位進行排程、擴充套件、共享資源、管理生命週期。

-通訊和資源共享
Pod 中的所有容器使用同一個網路 namespace，即相同的 IP 地址和 Port 空間。它們可以直接用 localhost 通訊。同樣的，這些容器可以共享儲存，當 Kubernetes 掛載 volume 到 Pod，本質上是將 volume 掛載到 Pod 中的每一個容器。

File Puller 會定期從外部的 Content Manager 中拉取最新的檔案，將其存放在共享的 volume 中。Web Server 從 volume 讀取檔案，響應 Consumer 的請求。這兩個容器是緊密協作的，它們一起為 Consumer 提供最新的資料；同時它們也通過 volume 共享資料。所以放到一個 Pod 是合適的。

Controller
Kubernetes 通常不會直接建立 Pod，而是通過 Controller 來管理 Pod 的。Controller 中定義了 Pod 的部署特性，比如有幾個副本，在什麼樣的 Node 上執行等。為了滿足不同的業務場景, Kubernetes 提供了多種 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等.

Replication Controller (副本集RC)
Replication Controller用來管理Pod的副本，保證叢集中存在指定數量的Pod副本。叢集中副本的數量大於指定數量，則會停止指定數量之外的多餘容器數量，反之，則會啟動少於指定數量個數的容器，保證數量不變。Replication Controller是實現彈性伸縮、動態擴容和滾動升級的核心。

通過監控執行中的Pod來保證叢集中執行指定數目的Pod副本。少於指定數目，RC就會啟動執行新的Pod副本；多於指定數目，RC就會殺死多餘的Pod副本(這是k8s早期技術概念)

Replica Set (副本集RS）
RS是新一代RC，提供同樣的高可用能力，區別主要在於RS後來居上，能支援更多種類的匹配模式。副本集物件一般不單獨使用，而是作為Deployment的理想狀態引數使用.Replica Set 實現了 Pod 的多副本管理。使用 Deployment 時會自動建立 ReplicaSet，也就是說 Deployment 是通過 ReplicaSet 來管理 Pod 的多個副本，我們通常不需要直接使用 ReplicaSet。

Deployment (部署)
Deployment 是最常用的 Controller，Deployment 可以管理 Pod 的多個副本，並確保 Pod 按照期望的狀態執行。Deployment是一個比RS應用模式更廣的API物件，支援動態擴充套件。可以建立一個新的服務，更新一個新的服務，也可以是滾動升級一個服務。滾動升級一個服務，實際是建立一個新的RS，然後逐漸將新RS中副本數增加到理想狀態，將舊RS中的副本數減小到0的複合操作 (逐步升級新得副本，剔除舊的副本).
總結：RC、RS和Deployment只是保證了支撐服務的微服務Pod的數量.

DaemonSet
DaemonSet 用於每個 Node 最多隻執行一個 Pod 副本的場景。正如其名稱所揭示的，DaemonSet 通常用於執行 daemon。

StatefuleSet
StatefuleSet 能夠保證 Pod 的每個副本在整個生命週期中名稱是不變的。而其他 Controller 不提供這個功能，當某個 Pod 發生故障需要刪除並重新啟動時，Pod 的名稱會發生變化。同時 StatefuleSet 會保證副本按照固定的順序啟動、更新或者刪除。

Service

Service定義了Pod邏輯集合和訪問該集合的策略，是真實服務的抽象。Service提供了統一的服務訪問入口以及服務代理和發現機制，關聯多個相同Label的Pod，使用者不需要了解後臺Pod是如何執行。
外部系統訪問Service的問題:
-> 首先需要弄明白Kubernetes的三種IP這個問題
-Node IP：Node節點的IP地址
　 - Pod IP： Pod的IP地址
　 -Cluster IP：Service的IP地址
-> 首先,Node IP是Kubernetes叢集中節點的物理網絡卡IP地址，所有屬於這個網路的伺服器之間都能通過這個網路直接通訊。這也表明Kubernetes叢集之外的節點訪問Kubernetes叢集之內的某個節點或者TCP/IP服務的時候，必須通過Node IP進行通訊
->其次，Pod IP是每個Pod的IP地址，他是Docker Engine根據docker0網橋的IP地址段進行分配的，通常是一個虛擬的二層網路。

最後Cluster IP是一個虛擬的IP，但更像是一個偽造的IP網路，原因有以下幾點:
-> Cluster IP僅僅作用於Kubernetes Service這個物件，並由Kubernetes管理和分配P地址
-> Cluster IP無法被ping，他沒有一個“實體網路物件”來響應
-> Cluster IP只能結合Service Port組成一個具體的通訊埠，單獨的Cluster IP不具備通訊的基礎，並且他們屬於Kubernetes叢集這樣一個封閉的空間。
->Kubernetes叢集之內，Node IP網、Pod IP網於Cluster IP網之間的通訊，採用的是Kubernetes自己設計的一種程式設計方式的特殊路由規則。

RC、RS和Deployment只是保證了支撐服務的微服務Pod的數量，但是沒有解決如何訪問這些服務的問題。一個Pod只是一個執行服務的例項，隨時可能在一個節點上停止，在另一個節點以一個新的IP啟動一個新的Pod，因此不能以確定的IP和埠號提供服務。要穩定地提供服務需要服務發現和負載均衡能力。服務發現完成的工作，是針對客戶端訪問的服務，找到對應的的後端服務例項。在K8s叢集中，客戶端需要訪問的服務就是Service物件。每個Service會對應一個叢集內部有效的虛擬IP，叢集內部通過虛擬IP訪問一個服務。在K8s叢集中微服務的負載均衡是由Kube-proxy實現的。Kube-proxy是K8s叢集內部的負載均衡器。它是一個分散式代理伺服器，在K8s的每個節點上都有一個；這一設計體現了它的伸縮性優勢，需要訪問服務的節點越多，提供負載均衡能力的Kube-proxy就越多，高可用節點也隨之增多。與之相比，我們平時在伺服器端做個反向代理做負載均衡，還要進一步解決反向代理的負載均衡和高可用問題。

Kubernetes 執行容器（Pod）與訪問容器（Pod）這兩項任務分別由 Controller 和 Service 執行。

Namespace
名字空間為K8s叢集提供虛擬的隔離作用，K8s叢集初始有兩個名字空間，分別是預設名字空間default和系統名字空間kube-system，除此以外，管理員可以可以建立新的名字空間滿足需要。

Label
Kubernetes中任意API物件都是通過Label進行標識，Label的實質是一系列的Key/Value鍵值對，其中key於value由使用者自己指定。Label可以附加在各種資源物件上，如Node、Pod、Service、RC等，一個資源物件可以定義任意數量的Label，同一個Label也可以被新增到任意數量的資源物件上去。Label是Replication Controller和Service執行的基礎，二者通過Label來進行關聯Node上執行的Pod。

我們可以通過給指定的資源物件捆綁一個或者多個不同的Label來實現多維度的資源分組管理功能，以便於靈活、方便的進行資源分配、排程、配置等管理工作。
一些常用的Label如下：
版本標籤："release":"stable","release":"canary"......
環境標籤："environment":"dev","environment":"qa","environment":"production"
架構標籤："tier":"frontend","tier":"backend","tier":"middleware"
分割槽標籤："partition":"customerA","partition":"customerB"
質量管控標籤："track":"daily","track":"weekly"

Label相當於我們熟悉的標籤，給某個資源物件定義一個Label就相當於給它大了一個標籤，隨後可以通過Label Selector（標籤選擇器）查詢和篩選擁有某些Label的資源物件，Kubernetes通過這種方式實現了類似SQL的簡單又通用的物件查詢機制。

Label Selector在Kubernetes中重要使用場景如下:
->kube-Controller程序通過資源物件RC上定義Label Selector來篩選要監控的Pod副本的數量，從而實現副本數量始終符合預期設定的全自動控制流程;
->kube-proxy程序通過Service的Label Selector來選擇對應的Pod，自動建立起每個Service島對應Pod的請求轉發路由表，從而實現Service的智慧負載均衡;
->通過對某些Node定義特定的Label，並且在Pod定義檔案中使用Nodeselector這種標籤排程策略，kuber-scheduler程序可以實現Pod”定向排程“的特性;

Master管理節點和Node工作節點的各元件關係:

Kuberneter工作流程：
1）通過kubectl向kubernetes Master發出指令, Master節點主要提供API Server、Scheduler、Controller元件，接收kubectl命令，從Node節點獲取Node資源資訊，併發出調度任務。
2）Node節點提供kubelet、kube-proxy，每個node節點都安裝docker，是實際的執行者。kubernetes不負責網路，所以一般是用flannel或者weave。
3）etcd是一個鍵值儲存倉庫，etcd負責服務發現和node資訊儲存。不過需要注意的是：由於etcd是負責儲存，所以不建議搭建單點叢集，如zookeeper一樣，由於存在選舉策略，所以一般推薦奇數個叢集，如3，5，7。只要叢集半數以上的結點存活，那麼叢集就可以正常執行，否則叢集可能無法正常使用。

Master：叢集控制管理節點，所有的命令都經由master處理。

Node：是kubernetes叢集的工作負載節點。Master為其分配工作，當某個Node宕機時，Master會將其工作負載自動轉移到其他節點。

Node節點可動態增加到kubernetes叢集中，前提是這個節點已經正確安裝、配置和啟動了上述的關鍵程序，預設情況下，kubelet會向Master註冊自己，這也kubernetes推薦的Node管理方式。一旦Node被納入叢集管理範圍，kubelet會定時向Master彙報自身的情況，以及之前有哪些Pod在執行等，這樣Master可以獲知每個Node的資源使用情況，並實現高效均衡的資源排程策略。如果Node沒有按時上報資訊，則會被Master判斷為失聯，Node狀態會被標記為Not Ready，隨後Master會觸發工作負載轉移流程。

Pod：是kubernetes最重要也是最基本的概念。每個Pod都會包含一個 “根容器”，還會包含一個或者多個緊密相連的業務容器。

Kubernetes為每個Pod都分配了唯一IP地址, 稱之為PodIP, 一個Pod裡多個容器共享PodIP地址. 要求底層網路支援叢集內任意兩個Pod之間的直接通訊，通常採用虛擬二層網路技術來實現 (Flannel).

Label：是一個key=value的鍵值對，其中key與value由使用者指定, 可以附加到各種資源物件上, 一個資源物件可以定義任意數量的Label。可以通過LabelSelector（標籤選擇器）查詢和篩選資源物件。

RC：Replication Controller宣告某個Pod的副本數在任意時刻都符合某個預期值。定義包含如下：
- Pod期待的副本數（replicas）;
- 用於篩選目標Pod的Label Selector;
- 當Pod副本數小於期望時，用於新的建立Pod的模板template;

需要注意
- 通過改變RC裡的Pod副本數量，可以實現Pod的擴容或縮容功能;
- 通過改變RC裡Pod模板中的映象版本，可以實現Pod的滾動升級功能;

Service：“微服務”，kubernetes中的核心。通過分析、識別並建模系統中的所有服務為微服務，最終系統有多個提供不同業務能力而又彼此獨立的微服務單元所組成，服務之間通過TCP/IP進行通訊。每個Pod都會被分配一個單獨的IP地址，而且每個Pod都提供了一個獨立的Endpoint以被客戶端訪問。

客戶端如何訪問？
部署負載均衡器，為Pod開啟對外服務埠，將Pod的Endpoint列表加入轉發列表中，客戶端通過負載均衡器的對外IP+Port來訪問此服務。每個Service都有一個全域性唯一的虛擬ClusterIP，這樣每個服務就變成了具備唯一IP地址的“通訊節點”，服務呼叫就變成了最基礎的TCP網路通訊問題。

Volume：是Pod中能夠被多個容器訪問的共享目錄。定義在Pod之上，被一個Pod裡的多個容器掛載到具體的檔案目錄之下；Volume與Pod生命週期相同。Volume可以讓一個Pod裡的多個容器共享檔案、讓容器的資料寫到宿主機的磁碟上或者寫檔案到 網路儲存中，具體如下圖所示：

在kubernetes1.2的時候，RC就由Replication Controller升級成Replica Set，“下一代RC”。命令相容適用，Replica Set主要被Deployment這個更高層的資源物件所使用，從而形成一套Pod建立、刪除、更新的編排機制。當我們使用Deployment時，無需關心它是如何建立和維護ReplicaSet的，這一切是自動發生的。

Docker:既然k8s是基於容器的，那麼就不得不提到docker。2013年初，docker橫空出世，孕育著新思想的“容器”，Docker選擇容器作為核心和基礎，以容器為資源分割和排程的基本單位，封裝整個軟體執行時環境，為開發者和系統管理員設計，用於構建、釋出和執行分散式應用的平臺。是一個跨平臺、可移植並且簡單易用的容器解決方案。通過作業系統核心技術（namespaces、cgroups等）為容器提供資源隔離與安全保障。

上圖是一個image的簡單使用。我們可以通過一個dockerfile來build自己的image。可以把image上傳（push）到自己的私有映象倉庫，也可以從私有倉庫pull到本地進行使用。可以單獨使用命令列，直接run container，可以對container進行stop、start、restart操作。也可以對image進行save儲存操作以及載入load操作，大傢俱體可以根據自己的使用，選擇不同的操作即可。

Docker資源隔離技術
Docker選擇容器作為核心和基礎，以容器為資源分割和排程的基本單位，封裝整個軟體執行時環境，為開發者和系統管理員設計，用於構建、釋出和執行分散式應用的平臺。Docker是一個跨平臺、可移植並且簡單易用的容器解決方案, 通過作業系統核心技術（namespaces、cgroups等）為容器提供資源隔離與安全保障。

Docker監控
cAdvisor（Container Advisor）是Google開發的用於分析執行中容器的資源佔用和效能指標的開源工具。cAdvisor是一個執行時的守護程序，負責收集、聚合、處理和輸出執行中容器的資訊。對於每個容器，cAdvisor都有資源隔離引數、資源使用歷史情況以及完整的歷史資源使用和網路統計資訊的柱狀圖。cAdvisor不但可以為使用者提供監控服務，還可以結合其他應用為使用者提供良好的服務移植和定製。包括結合InfluxDB對資料進行儲存，以及結合Grafana提供web控制檯，自定義查詢指標，並進行展示:

當下配合Kubernetes叢集比較成熟的監控方案是:Prometheus +Grafana

五、Kubernetes叢集裡容器之間的通訊方式

Kubernetes叢集裡面容器是存在於pod裡面的，所以容器之間通訊，一般分為三種類型：
->pod內部容器之間
->pod與pod容器之間
->pod訪問service服務

1）pod內部容器之間
這種情況下容器通訊比較簡單，因為k8s pod內部容器是共享網路空間的，所以容器直接可以使用localhost訪問其他容器。k8s在啟動容器的時候會先啟動一個pause容器，這個容器就是實現這個功能的。

2）pod與pod容器之間
這種型別又可以分為兩種情況：
-> 兩個pod在同一臺主機上面
-> 兩個pod分佈在不同主機之上
第一種情況，就比較簡單了，就是docker預設的docker網橋互連容器。
第二種情況需要更為複雜的網路模型了，k8s官方推薦的是使用flannel組建一個大二層扁平網路，pod的ip分配由flannel統一分配，通訊過程也是走flannel的網橋。比如:

每個node上面都會建立一個flannel0虛擬網絡卡，用於跨node之間通訊。所以容器直接可以直接使用pod id進行通訊。跨節點通訊時，傳送端資料會從docker0路由到flannel0虛擬網絡卡，接收端資料會從flannel0路由到docker0，這是因為flannel會新增一個路由。

例如現在有一個數據包要從IP為172.17.13.2的容器發到IP為172.17.12.2的容器。根據資料傳送節點的路由表，它只與172.17.0.0/16匹配這條記錄匹配，因此資料從docker0出來以後就被投遞到了flannel0。同理在目標節點，由於投遞的地址是一個容器，因此目的地址一定會落在docker0對於的172.17.12.0/24這個記錄上，自然的被投遞到了docker0網絡卡。

flannel的原理:是將網路包封裝在udp裡面，所以傳送端和接收端需要裝包和解包，對效能有一定的影響。除了flannel，k8s也支援其他的網路模型，比較有名的還有calico。

3）pod 訪問service服務
這裡涉及到k8s裡面一個重要的概念service。它是一個服務的抽象，通過label（k8s會根據service和pod直接的關係建立endpoint，可以通過“kubectl get ep”檢視）關聯到後端的pod容器。Service分配的ip叫cluster ip是一個虛擬ip（相對固定，除非刪除service），這個ip只能在k8s叢集內部使用，如果service需要對外提供，只能使用Nodeport方式對映到主機上，使用主機的ip和埠對外提供服務。（另外還可以使用LoadBalance方式，但這種方式是在gce這樣的雲環境裡面使用的 ）。

節點上面有個kube-proxy程序，這個程序從master apiserver獲取資訊，感知service和endpoint的建立，然後做下面兩個事情：
->為每個service 在叢集中每個節點上面建立一個隨機埠，任何該埠上面的連線會代理到相應的pod
->叢集中每個節點安裝iptables規則，用於clusterip + port路由到上一步定義的隨機埠上面，所以叢集中每個node上面都有service的轉發規則：

比如下面是一個測試環境內容:

這些就是kube-proxy針對service “"smart/ccdb:port1521"” 在節點上面監聽的埠。

六、Kubernetes日常維護命令

七、Kubernetes叢集部署失敗的一般原因

1.錯誤的容器映象/非法的倉庫許可權
其中兩個最普遍的問題是：a)指定了錯誤的容器映象；b)使用私有映象卻不提供倉庫認證資訊。這在首次使用 Kubernetes 或者繫結 CI/CD 環境時尤其棘手。看個例子:

2.應用啟動之後又掛掉
無論你是在 Kubernetes 上啟動新應用，還是遷移應用到已存在的平臺，應用在啟動之後就掛掉都是一個比較常見的現象。看個例子:

3.缺失 ConfigMap 或者 Secret
Kubernetes 最佳實踐建議通過 ConfigMaps 或者 Secrets 傳遞應用的執行時配置。這些資料可以包含資料庫認證資訊，API endpoints，或者其它配置資訊。一個常見的錯誤是，建立的 deployment 中引用的 ConfigMaps 或者 Secrets 的屬性不存在，有時候甚至引用的 ConfigMaps 或者 Secrets 本身就不存在。

缺失 ConfigMap
第一個例子，我們將嘗試建立一個 Pod，它載入 ConfigMap 資料作為環境變數：

但是假如你通過 Volume 來訪問 Secrets 或者 ConfigMap會發生什麼呢？

缺失 Secrets
下面是一個pod規格說明，它引用了名為 myothersecret 的 Secrets，並嘗試把它掛為卷:

4.活躍度/就緒狀態探測失敗
在 Kubernetes 中處理容器問題時，需要注意的是：你的容器應用是 running 狀態，不代表它在工作！？

Kubernetes 提供了兩個基本特性，稱作活躍度探測和就緒狀態探測。本質上來說，活躍度/就緒狀態探測將定期地執行一個操作（例如傳送一個 HTTP 請求，開啟一個 tcp 連線，或者在你的容器內執行一個命令），以確認你的應用和你預想的一樣在工作。

如果活躍度探測失敗，Kubernetes 將殺掉你的容器並重新建立一個。如果就緒狀態探測失敗，這個 Pod 將不會作為一個服務的後端 endpoint，也就是說不會流量導到這個 Pod，直到它變成 Ready。

如果你試圖部署變更你的活躍度/就緒狀態探測失敗的應用，滾動部署將一直懸掛，因為它將等待你的所有 Pod 都變成 Ready。

這個實際是怎樣的情況？以下是一個 Pod 規格說明，它定義了活躍度/就緒狀態探測方法，都是基於8080埠對 /healthy 路由進行健康檢查：

5.超出CPU/記憶體的限制
Kubernetes 賦予叢集管理員限制 Pod 和容器的 CPU 或記憶體數量的能力。作為應用開發者，你可能不清楚這個限制，導致 deployment 失敗的時候一臉困惑。我們試圖部署一個未知 CPU/memory 請求限額的 deployment：

上面可知，叢集管理員設定了每個 Pod 的最大記憶體使用量為 100Mi。你可以執行 kubectl describe limitrange 來檢視當前租戶的限制。

那麼現在就有3個選擇：
- 要求你的叢集管理員提升限額；
- 減少 deployment 的請求或者限額設定；
- 直接編輯限額；

6.資源配額
和資源限額類似，Kubernetes 也允許管理員給每個 namespace 設定資源配額。這些配額可以在 Pods，Deployments，PersistentVolumes，CPU，記憶體等資源上設定軟性或者硬性限制。讓我們看看超出資源配額後會發生什麼。以下是我們的 deployment 例子:

上面可以看出，我們的 ReplicaSet 無法建立更多的 pods 了，因為配額限制了：exceeded quota: compute-resources, requested: pods=1, used: pods=1, limited: pods=1。

和資源限額類似，我們現在也有3個選項：
- 要求叢集管理員提升該 namespace 的配額
- 刪除或者收縮該 namespace 下其它的 deployment
- 直接編輯配額

7.叢集資源不足
除非你的叢集開通了叢集自動伸縮功能，否則總有一天你的叢集中 CPU 和記憶體資源會耗盡。這不是說 CPU 和記憶體被完全使用了,而是指它們被 Kubernetes 排程器完全使用了。如同我們在第 5 點看到的，叢集管理員可以限制開發者能夠申請分配給 pod 或者容器的 CPU 或者記憶體的數量。聰明的管理員也會設定一個預設的 CPU/記憶體 申請數量，在開發者未提供申請額度時使用。

如果你所有的工作都在 default 這個 namespace 下工作，你很可能有個預設值 100m 的容器 CPU申請額度，對此你甚至可能都不清楚。執行 kubectl describe ns default 檢查一下是否如此。我們假定你的 Kubernetes 叢集只有一個包含 CPU 的節點。你的 Kubernetes 叢集有 1000m 的可排程 CPU。當前忽略其它的系統 pods（kubectl -n kube-system get pods），你的單節點叢集能部署 10 個 pod(每個 pod 都只有一個包含 100m 的容器)。

10 Pods * (1 Container * 100m) = 1000m == Cluster CPUs

當你擴大到 11 個的時候，會發生什麼？下面是一個申請 1CPU（1000m）的 deployment 例子

Events 模組告訴我們 Kubernetes 排程器（default-scheduler）無法排程這個 pod 因為它無法匹配任何節點。它甚至告訴我們每個節點哪個擴充套件點失敗了（Insufficient cpu）。

那麼我們如何解決這個問題？如果你太渴望你申請的 CPU/記憶體 的大小，你可以減少申請的大小並重新部署。當然，你也可以請求你的叢集管理員擴充套件這個叢集（因為很可能你不是唯一一個碰到這個問題的人）。

現在你可能會想：我們的 Kubernetes 節點是在我們的雲提供商的自動伸縮群組裡，為什麼他們沒有生效呢？原因是，你的雲提供商沒有深入理解 Kubernetes 排程器是做啥的。利用 Kubernetes 的叢集自動伸縮能力允許你的叢集根據排程器的需求自動伸縮它自身。如果你在使用 GCE，叢集伸縮能力是一個 beta 特性。

8.持久化卷掛載失敗
另一個常見錯誤是建立了一個引用不存在的持久化卷（PersistentVolumes）的 deployment。不論你是使用 PersistentVolumeClaims（你應該使用這個！），還是直接訪問持久化磁碟，最終結果都是類似的。

下面是我們的測試 deployment，它想使用一個名為 my-data-disk 的 GCE 持久化卷：

Events模組留有我們一直在尋找的線索。我們的 pod 被正確排程到了一個節點（Successfully assigned volume-test-3922807804-33nux to gke-ctm-1-sysdig2-35e99c16-qwds），但是那個節點上的 kubelet 無法掛載期望的卷test-volume。那個卷本應該在持久化磁碟被關聯到這個節點的時候就被建立了，但是，正如我們看到的，controller-manager 失敗了：Failed to attach volume "test-volume" on node "gke-ctm-1-sysdig2-35e99c16-qwds" with: GCE persistent disk not found: diskName="my-data-disk" zone="us-central1-a"。

最後一條資訊相當清楚了：為了解決這個問題，我們需要在 GKE 的us-central1-a區中建立一個名為my-data-disk的持久化卷。一旦這個磁碟建立完成，controller-manager 將掛載這塊磁碟，並啟動容器建立過程。

9.校驗錯誤
看著整個 build-test-deploy 任務到了 deploy 步驟卻失敗了，原因竟是 Kubernetes 物件不合法。還有什麼比這更讓人沮喪的！

一眼望去，這個 YAML 檔案是正確的，但錯誤訊息會證明是有用的。錯誤說的是 found invalid field resources for v1.PodSpec，再仔細看一下 v1.PodSpec， 我們可以看到 resource 物件變成了 v1.PodSpec的一個子物件。事實上它應該是 v1.Container 的子物件。在把 resource 物件縮排一層後，這個 deployment 物件就可以正常工作了。

除了查詢縮排錯誤，另一個常見的錯誤是寫錯了物件名（比如 peristentVolumeClaim 寫成了 persistentVolumeClaim），這樣的錯誤有時會很費你的時間！

為了能在早期就發現這些錯誤，我推薦在 pre-commit 鉤子或者構建的測試階段新增一些校驗步驟。例如，你可以：
1.用 python -c 'import yaml,sys;yaml.safe_load(sys.stdin)' < test-application.deployment.yaml 驗證 YAML 格式
2.使用標識 --dry-run 來驗證 Kubernetes API 物件，比如這樣：kubectl create -f test-application.deploy.yaml --dry-run --validate=true

重要提醒：校驗 Kubernetes 物件的機制是在服務端的校驗，這意味著 kubectl 必須有一個在工作的 Kubernetes 叢集與之通訊。不幸的是，當前 kubectl 還沒有客戶端的校驗選項，但是已經有 issue（kubernetes/kubernetes #29410 和 kubernetes/kubernetes #11488）在跟蹤這個缺失的特性了。

10.容器映象沒有更新
可能使用 Kubernetes 的大多數人都碰到過這個問題，它也確實是一個難題。

這個場景就像下面這樣：
1.使用一個映象 tag（比如：rosskulinski/myapplication:v1） 建立一個 deployment
2.注意到 myapplication 映象中存在一個 bug
3.構建了一個新的映象，並推送到了相同的 tag（rosskukulinski/myapplication:v1）
4.刪除了所有 myapplication 的 pods，新的例項被 deployment 創建出了
5.發現 bug 仍然存在
6.重複 3-5 步直到你抓狂為止

這個問題關係到 Kubernetes 在啟動 pod 內的容器時是如何決策是否做 docker pull 動作的。

在 v1.Container 說明中，有一個選項 ImagePullPolicy：

因為我們把我們的映象 tag 標記為 :v1，預設的映象拉取策略是 IfNotPresent。Kubelet 在本地已經有一份 rosskukulinski/myapplication:v1 的拷貝了，因此它就不會在做 docker pull 動作了。當新的 pod 出現的時候，它仍然使用了老的有問題的映象。

有三個方法來解決這個問題：
1.切成 :latest tag（千萬不要這麼做！）
2.deployment 中指定 ImagePullPolicy: Always
3.使用唯一的 tag（比如基於你的程式碼版本控制器的 commit id）

在開發階段或者要快速驗證原型的時候，我會指定 ImagePullPolicy: Always 這樣我可以使用相同的 tag 來構建和推送。然而，在我的產品部署階段，我使用基於 Git SHA-1 的唯一 tag。這樣很容易查到產品部署的應用使用的原始碼。

所以說，當使用kubernetes時，我們有這麼多地方要當心，一般來說，大部分常見的部署失敗都可以用下面的命令定位出來：
1.kubectl describe deployment/<deployname>
2.kubectl describe replicaset/<rsname>
3.kubectl get pods
4.kubectl describe pod/<podname>
5.kubectl logs <podname> --previous

下面是一個bash指令碼，它在 CI/CD 的部署過程中任何失敗的時候，都可以跑。在 Jenkins等的構建輸出中，將顯示有用的 Kubernetes 資訊，幫助開發者快速找到任何明顯的問題。