K8s 部署應用必備

應用部署邏輯

知識點介紹：

當希望在Kubernetes上部署應用程式時，通常要定義三個元件;

• 部署（Deployment）：這是建立Pod應用程式副本的方法；
• 服務（Service）：將流量排程到Pods的內部負載平衡器；
• 入口（Ingress）：描述流量如何從叢集外部流到服務。

Cluster介紹：

Cluster（叢集）是計算、儲存和網路資源的集合，Kubernetes利用這些資源執行各種基於容器的應用。
最簡單的Cluster可以只有一臺主機（既是Master也是Node）。

Master介紹：

Master是Cluster的大腦，它的主要職責是排程、即決定應用放在那裡執行。
Master執行Linux作業系統，可以是物理機也可以是虛擬機器
為了實現高可用，可以執行多個Master

Node介紹：

Node的職責是執行容器應用
Node由Master管理，Node負責監控並彙報容器狀態，並根據Master的要求管理容器的生命週期
Node執行在Linux作業系統，可以是物理機也可以是虛擬機器

Controller介紹

Kubernetes通常不會直接建立Pod，而是通過controller管理pod。controller中定義了pod的部署特性，比如有幾個副本，在什麼樣的Node上執行等。為了滿足不同的應用場景，Kubernetes提供了多種Controller，包括Deployment，RePlicaSet、DaemonSet、StatefulSet、Job等。
各個Controller介紹
Deployment
DepolyMent是最常見的Controller，比如我們可以通過建立Deployment來部署應用。
Deployment可以管理Pod的多個副本，並確保Pod按期望執行。
RePlicaSet
RePlicaSet實現了pod的多副本管理
使用Deployment時會自動建立RePlicaSet，也就是說Deployment是通過RePlicaSet來管理Pod的多個副本的，我們通常不需要直接使用RePlicaSet。
 DaemonSet
DaemonSet用於每個Node最多隻執行一個Pod場景，正如其名稱所揭示的，DaemonSet通常用於執行daemon。
 StatefulSet
StatefulSet能夠保證Pod的每個副本在整個生命週期中名稱是不變的。而其他Controller不提供這個功能
當某個Pod發生故障需要刪除並重新啟動時，Pod的名稱將會發生變化。同時StatefulSet會保證副本按照固定的順序啟動、更新或者刪除。
Joba
Job用於執行結束就刪除的應用。而其他Controller中的pod通常是長期持續執行。
Service介紹
Deployment可以部署多個副本，每個Pod都有自己的IP，Pod可能會被頻繁的銷燬和重啟，它們的IP會隨時變化，用IP來訪問Deployment不太現實。
Service定義了外界訪問一組特定的Pod的方式，Service有自己的IP和埠，Service為Pod提供了負載均衡。
NameSpace介紹
namespace可以將一個物理的Cluster邏輯上劃分成多個虛擬的Cluster，每一個Cluster就是一個namespace，不同namespace裡面的資源是完全隔離的

Pod介紹：
 Pod是Kubernetes的最小工作單元
 每個Pod包含一個或多個容器，Pod中的容器會作為一個整體被Master排程到一個Node上執行。
Kubernetes引入Pod的目的
 可管理性
有些容器天生就需要有緊密的聯絡，一起工作。Pod提供了比容器更高層次的抽象，將它們封裝到一個部署單元中。
Kubernetes以Pod為最小單位進行排程、擴充套件、共享資源、管理生命週期。
 通訊和資源共享
Pod中的所有容器使用同一個網路namespace，即相同的IP地址和Port空間。它們可以直接用localhost通訊。
同樣的、這些容器可以共享儲存，當Kubernetes掛在volume到Pod，本質上是將volume掛載到Pod中的每一個容器。
Pod的兩種使用方式
 執行單一容器
one-container-per-Pod 是Kubernetes最常見的模型，這種情況下，只是將單個容器封裝成Pod；
即便是隻有一個容器，Kubernetes管理的也是Pod而不是直接管理容器。

 執行多個容器
對於那些聯絡非常緊密的，而且需要直接共享資源的容器，應該放在同一個Pod中。
比如下面這個Pod包含兩個容器：一個File Puller，一個是Web Server。File Puller會定期從外部的Content Manager中拉取最新的檔案，將其存放在共享的volume中。Web Server從volume中讀取檔案，響應controller的請求。這兩個容器是緊密協作的，他們一起為Consumer提供最新的資料。同時他們也通過volume共享資料。所以放到一個pod是最合適的。
在Kubernetes叢集中，Pod 是所有業務型別的基礎，它是一個或多個容器的組合。這些容器共享儲存、網路和名稱空間，以及如何執行規範。在Pod中，所有容器都被統一安排排程，並執行在共享的上下文中。對於具體應用而言，Pod是他們的邏輯主機，Pod包含業務相關的多個應用容器。
Kubernetes不只是支援Docker容器，它也支援其它容器。
Pod的上下文可以理解成多個linux名稱空間的聯合：
 PID名稱空間（同一個Pod中應用可以看到其它程式）
 網路名稱空間（同一個Pod中的應用對相同的IP地址和埠有限）
 IPC名稱空間（同一個Pod中的應用可以通過VPC或者POSIX進行通訊）
 UTS名稱空間（同一個Pod中的應用共享一個主機名稱）
在Pod中，容器共享一個IP地址和埠空間，他們可以通過localhost發現彼此。
在不同Pod中的容器，擁有不同的IP地址，因此不能直接在程式間進行通訊。
容器之間通常通過Pod IP地址進行通訊。
在Pod被建立時，會分配一個唯一ID，並被排程到Node中，直到Pod被終止或刪除。如果Pod所在的Node當機，給定的Pod不會被重新排程，它將被完全相同的Pod代替。
一般來說，使用者不應該直接建立Pod，即是建立單個的Pod也應該通過控制器建立。在叢集範圍內，控制器為Pod提供自愈能力，以及副本和部署管理。
一個多容器的Pod會包含一個檔案拉取器和一個Web伺服器，此web伺服器會使用一個持久化儲存卷在容器中共享儲存
每一個pod都會被指派一個唯一的ip地址，在pod中每一個容器共享網路命名儲存空間，包括IP和網路埠。當pod中的容器需要和pod外的實體進行通訊時，則需要通過埠等網路資源。
Pod能夠被指定共享儲存卷的集合，在pod中所有容器能訪問共享儲存卷，允許這些容器共享資料，儲存卷也允許在一個pod持久化資料，以防止其中的容器需要被重啟。
Pod的工作方式：
Pod是一個臨時存在的實體，所以Kubernetes不會直接建立一個獨立的pod。當直接建立一個獨立的pod，如果缺少資源或者所被排程到的node失敗，則pod會被刪除。
重啟pod和重啟pod中的容器不是同一個概念，pod自身不會執行，它只是容器執行的環境。通過控制器能建立和管理多個pod，並在叢集範圍內處理副本、部署和提供自愈能力。
例如：當一個Node失敗，控制器可以自動在另外的節點上部署一個完全一樣的副本。控制器是Pod模板來建立pod。
Pod模板是一個被包含在其它物件（例如：Deployment、StatefulSet、DaemonSet等）中的Pod規格
Pod重啟策略：
在pod中的容器可能會由於異常等原因導致其終止退出，Kubernetes提供了重啟策略以重啟容器。重啟策略對同一個Pod中的所有容器起作用，容器的重啟，是由Node上的kubelet執行。Pod支援三種重啟策略，在配置檔案中通過restartPolicy欄位設定重啟策略。
  Always：只要退出就重啟；
  OnFailure：只有在失敗退出（exit code ！= 0 ）時，才會重啟。
  Never：只要退出，就不再重啟；
這裡的重啟是指在Pod的宿主Node上進行本地重啟，而不是排程到其它Node上。
Volume介紹
Docker的資料持久化方式
Volume繞過container的檔案系統，直接將資料寫到host機器上，只是volume是被docker管理的，docker下所有的volume都在host機器上指定的目錄下（/var/lib/docker/volumes）

資料持久化介紹
狹義的理解: “持久化”僅僅指把域物件永久儲存到資料庫中；廣義的理解,“持久化”包括和資料庫相關的各種操作。
● 儲存：把域物件永久儲存到資料庫。
● 更新：更新資料庫中域物件的狀態。
● 刪除：從資料庫中刪除一個域物件。
● 載入：根據特定的OID，把一個域物件從資料庫載入到記憶體。
● 查詢：根據特定的查詢條件，把符合查詢條件的一個或多個域物件從資料庫載入內在存中。
2．為什麼要持久化？
持久化技術封裝了資料訪問細節，為大部分業務邏輯提供物件導向的API。
● 通過持久化技術可以減少訪問資料庫資料次數，增加應用程式執行速度；
● 程式碼重用性高，能夠完成大部分資料庫操作；
● 鬆散耦合，使持久化不依賴於底層資料庫和上層業務邏輯實現，更換資料庫時只需修改配置檔案而不用修改程式碼。
部署過程：
一旦執行了Kubernetes叢集，就可以在其上部署應用；
1、 建立Deployment配置，Deployment將指揮Kubernetes如何建立和更新應用程式的例項。
2、 建立Deployment成功後，master節點將應用例項排程到叢集中的各個節點上
3、 建立應用例項成功後，Kubernetes deployment控制器會持續監控這些例項
4、 如果託管例項的節點關閉或被刪除，deployment控制器會將該例項替換為叢集中的另一個節點上的例項。這提供一種自我修復機制解決故障維護問題
5、 控制器管理pod
a) Deployment：無狀態部署，例如web，微服務 ，API；
b) StatefulSet：有狀態部署，例如資料庫，ZK、ETCD；
c) DaemonSet：守護程式部署，例如監控Agent，日誌Agent；
d) Job&CronJob：批處理，例如資料庫庫備份、郵件通知；
6、 pod資料持久化
容器部署過程一般會有以下三種資料：
 啟動時需要的初始資料，可以是配置檔案；
 啟動過程中產生的臨時資料，該臨時資料需要多個容器間共享；
 啟動過程中產生的業務資料