在16年開始聽說的k8s，那時候dokcer非常的火，當時也研究了一部分，也算了解docker,後續沒有使用場景，於是就沒有繼續深入的學習。隨著微服務的架構越來越流程，k8s應用場景也就再合適不過了。公司最近準備使用k8s做微服務架構，並且k8s的技術已經成熟，很多公司已經在生產上大規模使用,所以打算學習k8s。今天翻閱了k8s的官方文檔，發現學習的成本還是比較大的，k8s的組件比較多，屬於重量級，而且官方文檔不怎麽友好，不好找想要東西。所以，在這裏把學習過程分享出來，同時記錄下學習筆記，方便以後查閱。

1.master

k8s集群的管理節點，負責管理集群，提供集群的資源數據訪問入口。擁有Etcd存儲服務（可選），運行Api Server進程，Controller Manager服務進程及Scheduler服務進程，關聯工作節點Node。Kubernetes API server提供HTTP Rest接口的關鍵服務進程，是Kubernetes裏所有資源的增、刪、改、查等操作的唯一入口。也是集群控制的入口進程；Kubernetes Controller Manager是Kubernetes所有資源對象的自動化控制中心；Kubernetes Schedule是負責資源調度（Pod調度）的進程.

組件：

• kube-apiserver: APIServer負責對外提供RESTful的Kubernetes API服務，它是系統管理指令的統一入口，任何對資源進行增刪改查的操作都要交給APIServer處理後再提交給etcd。
• kube-controller-manager：如果說APIServer做的是“前臺”的工作的話，那controller manager就是負責“後臺”的。每個資源一般都對應有一個控制器，而controller manager就是負責管理這些控制器的。比如我們通過APIServer創建一個pod，當這個pod創建成功後，APIServer的任務就算完成了。而後面保證Pod的狀態始終和我們預期的一樣的重任就由controller manager去保證了
• kube-scheduler: scheduler的職責很明確，就是負責調度pod到合適的Node上。如果把scheduler看成一個黑匣子，那麽它的輸入是pod和由多個Node組成的列表，輸出是Pod和一個Node的綁定，即將這個pod部署到這個Node上。Kubernetes目前提供了調度算法，但是同樣也保留了接口，用戶可以根據自己的需求定義自己的調度算法。

2.node

Node是Kubernetes集群架構中運行Pod的服務節點，可以是物理機器、虛擬機、雲主機等。默認情況kubelet會向Master註冊自己，一旦Node被納入集群管理範圍，kubelet會定時向Master匯報自身的情報，包括操作系統，Docker版本，機器資源情況等。如果Node超過指定時間不上報信息，會被Master判斷為“失聯”，標記為Not Ready，隨後Master會觸發Pod轉移。

組件：

• kubelet: 負責對Pod對於的容器的創建、啟停等任務
• kube-proxy: 實現Kubernetes Service的通信與負載均衡機制的重要組件
• Docker Engine（DockerDo): docker引擎，負責本機容器的創建和管理工作

3.pod

Pod是Kubernetes的基本操作單元,每個Pod中有個根容器(Pause容器)，Pause容器的狀態代表整個容器組的狀態，其他業務容器共享Pause的IP，即Pod IP，共享Pause掛載的Volume，這樣簡化了同個Pod中不同容器之間的網絡問題和文件共享問題。

特點：

1. Kubernetes集群中，同宿主機的或不同宿主機的Pod之間要求能夠TCP/IP直接通信，因此采用虛擬二層網絡技術來實現，例如Flannel，Openvswitch(OVS)等，這樣在同個集群中，不同的宿主機的Pod IP為不同IP段的IP，集群中的所有Pod IP都是唯一的，不同Pod之間可以直接通信。
2. Pod有兩種類型：普通Pod和靜態Pod。靜態Pod即不通過K8S調度和創建，直接在某個具體的Node機器上通過具體的文件來啟動。普通Pod則是由K8S創建、調度，同時數據存放在ETCD中。
3. Pod IP和具體的容器端口（ContainnerPort）組成一個具體的通信地址，即Endpoint。一個Pod中可以存在多個容器，可以有多個端口，Pod IP一樣，即有多個Endpoint。
4. Pod Volume是定義在Pod之上，被各個容器掛載到自己的文件系統中，可以用分布式文件系統實現後端存儲功能。
5. Pod中的Event事件可以用來排查問題，可以通過kubectl describe pod xxx 來查看對應的事件。
6. 每個Pod可以對其能使用的服務器上的計算資源設置限額，一般為CPU和Memory。K8S中一般將千分之一個的CPU配置作為最小單位，用m表示，是一個絕對值，即100m對於一個Core的機器還是48個Core的機器都是一樣的大小。Memory配額也是個絕對值，單位為內存字節數。
7. 資源配額的兩個參數:

• Requests:該資源的最小申請量，系統必須滿足要求。
• Limits:該資源最大允許使用量，當超過該量，K8S會kill並重啟Pod。

4.Replication Controller

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

5. Label

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

特點：

1. Label是一個鍵值對，可以附加在任何對象上，比如Node,Pod,Service,RC等。Label和資源對象是多對多的關系，即一個Label可以被添加到多個對象上，一個對象也可以定義多個Label。
2. Label的作用主要用來實現精細的、多維度的資源分組管理，以便進行資源分配，調度，配置，部署等工作。
3. Label通俗理解就是“標簽”，通過標簽來過濾篩選指定的對象，進行具體的操作。k8s通過Label Selector(標簽選擇器)來篩選指定Label的資源對象，類似SQL語句中的條件查詢（WHERE語句）。
4. Label Selector有基於等式和基於集合的兩種表達方式，可以多個條件進行組合使用：

• 基於等式：name=redis-slave（匹配name=redis-slave的資源對象）;env!=product(匹配所有不具有標簽env=product的資源對象)
• 基於集合：name in (redis-slave,redis-master);name not in (php-frontend)（匹配所有不具有標簽name=php-frontend的資源對象）

使用場景

1. kube-controller進程通過資源對象RC上定義的Label Selector來篩選要監控的Pod副本數，從而實現副本數始終保持預期數目。
2. kube-proxy進程通過Service的Label Selector來選擇對應Pod，自動建立每個Service到對應Pod的請求轉發路由表，從而實現Service的智能負載均衡機制。
3. kube-scheduler實現Pod定向調度：對Node定義特定的Label，並且在Pod定義文件中使用NodeSelector標簽調度策略。

6. Deployment

Deployment是kubernetes 1.2引入的概念，用來解決Pod的編排問題。它是一個更高層次的API對象，可以管理ReplicaSets和Pod，並提供聲明式更新等功能。 官方建議使用Deployment管理ReplicaSets，而不是直接使用ReplicaSets，這就意味著可能永遠不需要直接操作ReplicaSet對象。

其特點在於可以隨時知道Pod的部署進度，即對Pod的創建、調度、綁定節點、啟動容器完整過程的進度展示。通過在Deployment中描述你所期望的集群狀態，Deployment Controller會將現在的集群狀態在一個可控的速度下逐步更新成你所期望的集群狀態。Deployment主要職責同樣是為了保證pod的數量和健康，90%的功能與Replication Controller完全一樣，可以看做新一代的Replication Controller。但是，它又具備了Replication Controller之外的新特性：

　　　　Replication Controller全部功能：Deployment繼承了上面描述的Replication Controller全部功能。

　　　　事件和狀態查看：可以查看Deployment的升級詳細進度和狀態。

　　　　回滾：當升級pod鏡像或者相關參數的時候發現問題，可以使用回滾操作回滾到上一個穩定的版本或者指定的版本。

　　　　版本記錄: 每一次對Deployment的操作，都能保存下來，給予後續可能的回滾使用。

　　　　暫停和啟動：對於每一次升級，都能夠隨時暫停和啟動。

　　　　多種升級方案：Recreate----刪除所有已存在的pod,重新創建新的; RollingUpdate----滾動升級，逐步替換的策略，同時滾動升級時，支持更多的附加參數，例如設置最大不可用 pod數量，最小升級間隔時間等等。

使用場景

1. 創建一個Deployment對象來生成對應的Replica Set並完成Pod副本的創建過程。
2. 檢查Deployment的狀態來確認部署動作是否完成（Pod副本的數量是否達到預期值）。
3. 更新Deployment以創建新的Pod(例如鏡像升級的場景)。
4. 如果當前Deployment不穩定，回退到上一個Deployment版本。
5. 掛起或恢復一個Deployment。

7.Service

Service定義了Pod的邏輯集合和訪問該集合的策略，是真實服務的抽象。Service提供了一個統一的服務訪問入口以及服務代理和發現機制，關聯多個相同Label的Pod，用戶不需要了解後臺Pod是如何運行。

特點：

• Service一個應用服務抽象，定義了Pod邏輯集合和訪問這個Pod集合的策略。
• Service代理Pod集合對外表現是為一個訪問入口，分配一個集群IP地址，來自這個IP的請求將負載均衡轉發後端Pod中的容器。
• Service通過Lable Selector選擇一組Pod提供服務。

• Node IP：Node節點的IP地址，NodeIP是集群中每個節點的物理網卡IP地址，是真實存在的物理網絡，kubernetes集群之外的節點訪問kubernetes內的某個節點或TCP/IP服務的時候，需要通過NodeIP進行通信。
• Pod IP： Pod的IP地址，Pod IP是每個Pod的IP地址，是Docker Engine根據docker0網橋的IP段地址進行分配的，是一個虛擬二層網絡，集群中一個Pod的容器訪問另一個Pod中的容器，是通過Pod IP進行通信的，而真實的TCP/IP流量是通過Node IP所在的網卡流出的。
• Cluster IP：
  1. Service的Cluster IP是一個虛擬IP(由虛擬網絡創造)，只作用於Service這個對象，由kubernetes管理和分配IP地址（來源於Cluster IP地址池）。
  2. Cluster IP無法被ping通，因為沒有一個實體網絡對象來響應。
  3. Cluster IP結合Service Port組成的具體通信端口才具備TCP/IP通信基礎，屬於kubernetes集群內，集群外訪問該IP和端口需要額外處理。
  4. k8s集群內Node IP 、Pod IP、Cluster IP之間的通信采取k8s自己的特殊的路由規則，與傳統IP路由不同。

8.Namespace

命名空間將對象邏輯上分配到不同Namespace，可以是不同的項目、用戶等區分管理，並設定控制策略，從而實現多租戶。 命名空間也稱為虛擬集群。

9、Volume

　　在Docker的設計實現中，容器中的數據是臨時的，即當容器被銷毀時，其中的數據將會丟失。如果需要持久化數據，需要使用Docker數據卷掛載宿主機上的文件或者目錄到容器中。在Kubernetes中，當Pod重建的時候，數據是會丟失的，Kubernetes也是通過數據卷掛載來提供Pod數據的持久化的。Kubernetes數據卷是對Docker數據卷的擴展，Kubernetes數據卷是Pod級別的，可以用來實現Pod中容器的文件共享。目前，Kubernetes支持的數據卷類型如下：

　　　　1) EmptyDir

　　　　2) HostPath

　　　　3) GCE Persistent Disk

　　　　4) AWS Elastic Block Store

　　　　5) NFS

　　　　6) iSCSI

　　　　7) Flocker

　　　　8) GlusterFS

　　　　9) RBD

　　　　10) Git Repo

　　　　11) Secret

　　　　12) Persistent Volume Claim

　　　　13) Downward API

本地數據卷

　　EmptyDir、HostPath這兩種類型的數據卷，只能最用於本地文件系統。本地數據卷中的數據只會存在於一臺機器上，所以當Pod發生遷移的時候，數據便會丟失。該類型Volume的用途是：Pod中容器間的文件共享、共享宿主機的文件系統。

EmptyDir

　　如果Pod配置了EmpyDir數據卷，在Pod的生命周期內都會存在，當Pod被分配到 Node上的時候，會在Node上創建EmptyDir數據卷，並掛載到Pod的容器中。只要Pod 存在，EmpyDir數據卷都會存在（容器刪除不會導致EmpyDir數據卷丟失數據），但是如果Pod的生命周期終結（Pod被刪除），EmpyDir數據卷也會被刪除，並且永久丟失。

　　EmpyDir數據卷非常適合實現Pod中容器的文件共享。Pod的設計提供了一個很好的容器組合的模型，容器之間各司其職，通過共享文件目錄來完成交互，比如可以通過一個專職日誌收集容器，在每個Pod中和業務容器中進行組合，來完成日誌的收集和匯總。

HostPath

　　HostPath數據卷允許將容器宿主機上的文件系統掛載到Pod中。如果Pod需要使用宿主機上的某些文件，可以使用HostPath。

網絡數據卷

　　Kubernetes提供了很多類型的數據卷以集成第三方的存儲系統，包括一些非常流行的分布式文件系統，也有在IaaS平臺上提供的存儲支持，這些存儲系統都是分布式的，通過網絡共享文件系統，因此我們稱這一類數據卷為網絡數據卷。

　　網絡數據卷能夠滿足數據的持久化需求，Pod通過配置使用網絡數據卷，每次Pod創建的時候都會將存儲系統的遠端文件目錄掛載到容器中，數據卷中的數據將被水久保存，即使Pod被刪除，只是除去掛載數據卷，數據卷中的數據仍然保存在存儲系統中，且當新的Pod被創建的時候，仍是掛載同樣的數據卷。網絡數據卷包含以下幾種：NFS、iSCISI、GlusterFS、RBD（Ceph Block Device）、Flocker、AWS Elastic Block Store、GCE Persistent Disk

Persistent Volume和Persistent Volume Claim

　　理解每個存儲系統是一件復雜的事情，特別是對於普通用戶來說，有時候並不需要關心各種存儲實現，只希望能夠安全可靠地存儲數據。Kubernetes中提供了Persistent Volume和Persistent Volume Claim機制，這是存儲消費模式。Persistent Volume是由系統管理員配置創建的一個數據卷（目前支持HostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、iSCSI、GlusterFS、RBD），它代表了某一類存儲插件實現；而對於普通用戶來說，通過Persistent Volume Claim可請求並獲得合適的Persistent Volume，而無須感知後端的存儲實現。Persistent Volume和Persistent Volume Claim的關系其實類似於Pod和Node，Pod消費Node資源，Persistent Volume Claim則消費Persistent Volume資源。Persistent Volume和Persistent Volume Claim相互關聯，有著完整的生命周期管理：

　　　　1) 準備：系統管理員規劃或創建一批Persistent Volume；

　　　　2) 綁定：用戶通過創建Persistent Volume Claim來聲明存儲請求，Kubernetes發現有存儲請求的時候，就去查找符合條件的Persistent Volume（最小滿足策略）。找到合適的就綁定上，找不到就一直處於等待狀態；

　　　　3) 使用：創建Pod的時候使用Persistent Volume Claim；

　　　　4) 釋放：當用戶刪除綁定在Persistent Volume上的Persistent Volume Claim時，Persistent Volume進入釋放狀態，此時Persistent Volume中還殘留著上一個Persistent Volume Claim的數據，狀態還不可用；

　　　　5) 回收：是否的Persistent Volume需要回收才能再次使用。回收策略可以是人工的也可以是Kubernetes自動進行清理（僅支持NFS和HostPath）

信息數據卷

　　Kubernetes中有一些數據卷，主要用來給容器傳遞配置信息，我們稱之為信息數據卷，比如Secret（處理敏感配置信息，密碼、Token等）、Downward API（通過環境變量的方式告訴容器Pod的信息）、Git Repo（將Git倉庫下載到Pod中），都是將Pod的信息以文件形式保存，然後以數據卷方式掛載到容器中，容器通過讀取文件獲取相應的信息。

持續更新....

kubernets學習之路(1)--概念總結