現在主要負責的項目（容器雲）涉及到的概念和知識點，平時也有學習和記錄，但很碎片化，最近剛好有時間可以做一次系統的梳理。
一、Kubernetes是什麼及架構
1. k8s是什麼
先來一張Kubernetes官網的截圖，可以看到，官方對Kubernetes的定義：Kubernetes（k8s）是一個自動化部署、擴充和管理容器化應用程式的開源系統。
Kubernetes 這個單詞是希臘語，它的中文翻譯是“舵手”或者“飛行員”。在一些常見的資料中也會看到“ks”這個詞，也就是“k8s”，
它是通過将8個字母“ubernete ”替換為“8”而導緻的一個縮寫。 Kubernetes 為什麼要用“舵手”來命名呢？
這是一艘載着一堆集裝箱的輪船，輪船在大海上運着集裝箱奔波，把集裝箱送到它們該去的地方。Container 這個英文單詞也有另外的一個意思就是“集裝箱”。
Kubernetes 也就借着這個寓意，希望成為運送集裝箱的一個輪船，來幫助我們管理這些集裝箱，也就是管理這些容器。
這個就是為什麼會選用 Kubernetes 這個詞來代表這個項目的原因。更具體一點地來說：Kubernetes 是一個自動化的容器編排平台，
它負責應用的部署、應用的彈性以及應用的管理。
2. k8s能做什麼
- 服務的發現與負載的均衡
- 容器的自動裝箱，也會把它叫做 scheduling，就是“排程”，把一個容器放到一個叢集的某一個機器上，Kubernetes會幫助我們去做存儲的編排，讓存儲的聲明周期與容器的生命周期建立連接配接
- 容器的自動化恢複。在一個叢集中，經常會出現主控端的問題，導緻容器本身的不可用，Kubernetes會自動地對這些不可用的容器進行恢複
- 應用的自動釋出與應用的復原，以及與應用相關的配置密文的管理
- 對于 job 類型任務，Kubernetes可以去做批量的執行
- 為了讓這個叢集、這個應用更富有彈性，Kubernetes支援容器的水準伸縮
2.1. 排程
Kubernetes 可以把使用者送出的容器放到 Kubernetes 管理的叢集的某一台節點上去。Kubernetes 的排程器是執行這項能力的元件，
它會觀察正在被排程的這個容器的大小、規格。
比如，容器所需要的CPU以及它所需要的記憶體，然後在叢集中找一台相對比較空閑的機器來進行一次放置的操作。
2.2. 自動修複
Kubernetes 有節點健康檢查的功能，它會監測這個叢集中所有的主控端，當主控端本身出現故障，或者軟體出現故障的時候，
這個節點健康檢查會自動對它進行發現。接下來Kubernetes 會把運作在這些失敗節點上的容器進行自動遷移，
遷移到一個正在健康運作的主控端上，來完成叢集内容器的自動恢複。
2.3 水準伸縮
Kubernetes有業務負載檢查的能力，它會監測業務上所承擔的負載，如果這個業務本身的CPU使用率或記憶體占用過高，
或者響應時間過長，它可以對這個業務進行一次擴容。
比如，下面的例子中，黃顔色的過度忙碌，Kubernetes就可以把黃顔色負載從一份變為三份。接下來，
它就可以通過負載均衡把原來打到第一個黃顔色上的負載平均分到三個黃顔色的負載上去，以此來提高響應速度。
3. k8s的架構
Kubernetes 架構是一個比較典型的二層架構和server-client架構。Master作為中央管控節點，與Node建立連接配接。
所有 UI 的、clients、user側的元件，隻會和Master進行連接配接，把希望的狀态或者想執行的指令下發給 Master，
Master會把這些指令或者狀态下發給相應的節點，進行最終的執行。
Master
Kubernetes 的Master包含四個主要的元件：API Server、Controller、Scheduler以及etcd。
- API Server：提供了資源操作的唯一入口，并提供認證、授權、通路控制、API注冊和發現等機制。
Kubernetes 中所有的元件都會和API Server進行連接配接，元件與元件之間一般不進行獨立的連接配接，都依賴于API Server進行消息的傳送；
- Controller：控制器，它負責維護叢集的狀态，比如故障檢測、自動擴充、滾動更新等。上面的2個例子，第1個自動對容器進行修複、第2個自動水準擴張，都是由Controller 完成的；
- Scheduler：是排程器，負責資源的排程，按照預定的排程政策将Pod排程到相應的機器上。例如上面的例子，把使用者送出的pod，依據它對CPU、memory請求的大小，找一台合适的節點，進行放置；
- etcd：是一個分布式的存儲系統，儲存了整個叢集的狀态，比如Pod、Service等對象資訊。API Server 中所需要的原資訊都被放置在etcd中，etcd本身是一個高可用系統，通過etcd保證整個Kubernetes的Master元件的高可用性。
Node
Kubernetes 的 Node 是真正運作業務負載的，每個業務負載會以 Pod 的形式運作。一個 Pod 中運作的一個或者多個容器。
- kubelet：Master在Node節點上的Agent，是真正去運作 Pod 的元件，也是Node上最關鍵的元件，負責本Node節點上Pod的建立、修改、監控、删除等生命周期管理，同時Kubelet定時“上報”本Node的狀态資訊到API Server。它通過 API Server 接收到所需要 Pod 運作的狀态。然後送出到 Container Runtime 元件中。
- Container Runtime：容器運作時。負責鏡像管理以及Pod和容器的真正運作（CRI），可以了解為類似JVM
- Storage Plugin 或者 Network Plugin：對存儲跟網絡進行管理在 OS 上去建立容器所需要運作的環境，最終把容器或者 Pod 運作起來，也需要對存儲跟網絡進行管理。Kubernetes 并不會直接進行網絡存儲的操作，他們會靠 Storage Plugin 或者Network Plugin 來進行操作。使用者自己或者雲廠商都會去寫相應的 Storage Plugin 或者 Network Plugin，去完成存儲操作或網絡操作。
- Kube-proxy：負責為Service提供cluster内部的服務發現和負載均衡，完成 service 組網在 Kubernetes 自己的環境中，也會有 Kubernetes 的 Network，它是為了提供 Service network 來進行搭網組網的。真正完成 service 組網的元件是 Kube-proxy，它是利用了 iptable 的能力來進行組建 Kubernetes 的 Network，就是 cluster network。
元件間的通信
步驟說明：
1. 通過 UI 或者 CLI 送出1個 Pod 給 Kubernetes 進行部署，這個 Pod 請求首先會送出給API Server，下一步 API Server 會把這個資訊
寫入到存儲系統 etcd，之後 Scheduler 會通過 API Server 的 watch機制得到這個資訊：有1個Pod 需要被排程。
2. Scheduler會根據node叢集的記憶體狀态進行1次排程決策，在完成這次排程之後，它會向 API Server 報告：“OK！這個 Pod 需要被排程到XX節點上。”
API Server 接收後，會把這次的操作結果再次寫到 etcd 中。
3. API Server 通知相應的節點進行這個Pod真正的執行啟動。相應節點的 kubelet 會得到通知，然後kubelet 會去調 Container runtime 來
真正去啟動配置這個容器和這個容器的運作環境，去排程 Storage Plugin 來去配置存儲，network Plugin 去配置網絡。 二、Kubernetes核心概念
第一個概念：Pod
Pod 是 Kubernetes 的最小排程以及資源單元。可以通過 Kubernetes 的 Pod API 生産一個 Pod，讓 Kubernetes 對這個 Pod 進行排程，也就是把它放在某一個Kubernetes 管理的節點上運作起來。一個 Pod 簡單來說是對一組容器的抽象，它裡面會包含一個或多個容器。
如下圖，它包含了兩個容器，每個容器可以指定它所需要資源大小，當然，在這個 Pod 中也可以包含一些其他所需要的資源：比如說所看到的 Volume 卷這個存儲資源。
第二個概念：Volume
管理 Kubernetes 存儲，用來聲明在 Pod 中的容器可以通路的檔案目錄，一個卷可以被挂載在 Pod 中一個或者多個容器的指定路徑下面。
而 Volume 本身是一個抽象的概念，一個 Volume 可以去支援多種的後端的存儲。Kubernetes 的 Volume 支援很多存儲插件，
可以支援本地的存儲和分布式的存儲，比如像 ceph，GlusterFS；也可以支援雲存儲，比如阿裡雲上的雲盤、AWS 上的雲盤、Google 上的雲盤等等。
第三個概念：Deployment
Deployment 是在Pod上更為上層的一個抽象，它可以定義一組Pod 的副本數目、以及Pod的版本。一般用Deployment來做應用的真正的管理，
而Pod是組成Deployment最小的單元。
Kubernetes通過 Controller（控制器）維護Deployment中Pod 的數目，Controller也會去幫助Deployment自動恢複失敗的Pod。
比如，可以定義一個Deployment，這個Deployment裡面需要2個Pod，當1個Pod失敗的時候，控制器就會監測到，再去新生成1個Pod，
把Deployment中的Pod數目從1個恢複到2個。通過控制器，也可以完成釋出政策，比如進行滾動更新、重新生成的更新或者進行版本復原。
第四個概念：Service
Service：提供1個或者多個 Pod 執行個體的穩定通路位址
比如，一個 Deployment 可能有2個甚至更多個完全相同的 Pod。對于外部的使用者來講，通路哪個 Pod 都是一樣的，是以希望做一次負載均衡，
在做負載均衡的同時，隻需要通路某一個固定的 VIP，也就是 Virtual IP 位址，而不需要得知每一個具體的 Pod 的 IP 位址。
如果1個 Pod 失敗了，可能會換成另外一個新的。提供了多個具體的 Pod 位址，對外部使用者來說，要不停地去更新 Pod 位址。
當這個 Pod 再失敗重新開機之後，如果有一個抽象，把所有 Pod 的通路能力抽象成1個第三方的 IP 位址，實作這個的 Kubernetes 的抽象就叫 Service。
實作 Service 有多種入口方式：
1、ClusterIP：Service 在叢集内的唯一 ip 位址，我們可以通過這個 ip，均衡的通路到後端的 Pod，而無須關心具體的 Pod。
2、NodePort：Service 會在叢集的每個 Node 上都啟動一個端口，我們可以通過任意Node 的這個端口來通路到 Pod。
3、LoadBalancer：在 NodePort 的基礎上，借助公有雲環境建立一個外部的負載均衡器，并将請求轉發到 NodeIP:NodePort。
4、ExternalName：将服務通過 DNS CNAME 記錄方式轉發到指定的域名（通過 spec.externlName 設定）。 第五個概念：Namespace
Namespace：用來做一個叢集内部的邏輯隔離，包括鑒權、資源管理等。Kubernetes 的每個資源，比如Pod、Deployment、Service
都屬于一個 Namespace，同一個 Namespace 中的資源需要命名的唯一性，不同的 Namespace 中的資源可以重名。
K8S的API
Kubernetes API 是由 HTTP+JSON 組成的：使用者通路的方式是HTTP，通路API 中 content 的内容是JSON格式的。
用Kubectl 指令、Kubernetes UI或者Curl，直接與Kubernetes互動都是使用 HTTP + JSON 的形式。
如下圖，對于這個Pod類型的資源，它的HTTP通路的路徑就是 API，apiVesion: V1, 之後是相應的Namespaces，
以及Pods資源，最終是 Podname，也就是Pod的名字。
當送出一個 Pod，或者 get 一個 Pod 的時候，它的 content 内容都是用JSON 或者是YAML表達的。上圖中YAML的例子，
在這個YAML檔案中，對Pod資源的描述分為幾個部分。
第一個部分，一般是 API 的 version。比如在這個例子中是 V1，它也會描述我在操作哪個資源； kind 如果是 pod，在 Metadata 中，
就寫上這個 Pod 的名字；比如nginx。也會給pod打一些 label，在 Metadata 中，有時候也會去寫 annotation，也就是對資源的額外的一些使用者層次的描述。
比較重要的一個部分叫 Spec，Spec 也就是希望 Pod 達到的一個預期的狀态。比如pod内部需要有哪些 container 被運作；
這裡是一個name為nginx 的 container，它的 image 是什麼？它暴露的 port 是什麼？
當從 Kubernetes API 中去擷取這個資源的時候，一般在 Spec 下面會有一個status字段 ，它表達了這個資源目前的狀态；
比如一個 Pod 的狀态可能是正在被排程、或者是已經 running、或者是已經被 terminates（被執行完畢）。
Label是一個比較有意思的 metadata，可以是一組KeyValue的集合。
如下圖，第一個 pod 中，label 就可能是一個 color 等于 red，即它的顔色是紅顔色。當然也可以加其他 label，
比如size: big 就是大小，定義為大的，它可以是一組label。
這些 label 是可以被 selector（選擇器）所查詢的。就好比sql 類型的 select 語句。
通過label，kubernetes 的API層就可以對這些資源進行篩選。
例如，Deployment可能代表一組Pod，是一組Pod 的抽象，一組Pod就是通過label selector來表達的。
當然Service對應的一組Pod來對它們進行統一的通路，這個描述也是通過label selector來選取的一組Pod。
推薦
https://kubernetes.io/docs/home/（Kubernetes官方文檔）
http://docs.kubernetes.org.cn/（Kubernetes中文文檔）