Kubernetes集群概述/體系結構/相關核心概念

Kubernetes是什么？

業界簡稱為：K8S，是首字母和末尾之母之間有8個字母，所以叫K8S，不知為何這樣起名？

1、它是一個全新的基于容器技術的分布式架構方案。Kubernetes是谷歌嚴格保密十幾年的秘密武器---Borg的一個開源版本，據說在GG員工都簽署了保密協議，即使離職也不能泄露機密（業界大數據框架：Hadoop，也是受GG公開文獻啟發GFS和BigTable ）。

2、若我們的系統設計遵循Kubernetes的設計思想，可以說那些傳統系統架構中和業務沒有多大關系的底層代碼或功能模塊，可以消除，我們不必再為應用的負載均衡和部署等問題而煩惱

3、Kubernetes是一個開放的開放平臺。有Google、Redhat等開源基礎設施的大碗們共同發起了一個為：CNCF(Cloud Native Computing Foundation)的基金會。

4、Kubernetes是一個完備的分布式系統支撐平臺。

為什么要用Kubernetes？

1、可以和微服務完美結構，構成微服務架構。

2、K8S內的服務的彈性擴容機制可以應對突發流量

3、K8S架構的靈活及超強的橫向擴容能力可以提高我們的競爭力

4、基于容器技術，構建公司DevOps、CI/CD、持續交付，縮短開發周期

Kuberntes的體系架構

下圖為K8S的體系架構

Kubernetes的主要核心組件：

在上圖中的左側節點則是Master節點，右側是Node節點：

Master節點的主要作用是控制和管理整個集群的狀態并接收外部用戶的操作請求。它主要運行三中服務進程，分別是：kube-apiserver、kube-scheduler、kube-controller-manager,具體作用如下：

• kube-apiserver

kube-apiserver是整個Kubernetes集群的核心，也是部署Kubernetes最先啟動的組件，其他所有的組件都會在啟動時接入這個服務，主要是提供資源操作的統一入口， 通過RestAPI將集群的狀態信息存儲etcd集群。

• kube-scheduler

主要負責資源的調度，根據集群當前的資源使用情況及復雜的調度算法將Pod調度到適合運行或特定的服務節點上。

• kube-controller-manager

kube-controller-manager服務負責管理K8S集群中各種資源的狀態，諸如：故障檢測、滾動更新等。

Node節點是實際執行用戶任務的地方，其上有兩種服務進程，分別是：kube-proxy和kubelet，具體作用如下：

• kube-proxy

設計kube-proxy服務是為了解決從Node節點中的Pod對K8S特定Service訪問時的路由問題，每當K8S創建一個Service的Endpoint，各個Node節點上的kube-proxy進程就會修改節點系統的iptables規則，使得當該節點上的Pod訪問相應Endpoint的虛擬Ip和端口時，請求會被分發到正確的節點和容器進行處理

• kubelet
  

kubelet直接負責節點上容器的生命周期，同時也負責Volume和網絡（CNI）的管理

其他的核心組件：

etcd：保存集群的狀態，整個集群的狀態數據都存于此，因此構建K8S集群時，etcd也最好是集群的，同時要對etcd的數據進行備份

Heapster：? 提供資源監控

kube-dns：負責為整個集群提供DNS服務

Kuberntes核心概念

在Kubernetes集群中，服務器的角色分為Master和Node,此兩種不同角色分別運行著不同的服務進程。

• Pod

  Pod表示的是一個或多個容器的組合，它是K8S最基本的調度和操作單位，每個Pod里都有一個特殊的容器，被稱為：”根容器“的pause容器。

  在同一個Pod中的容器總會被調度和部署到同一個節點上，并共享相同的數據卷和網絡棧，也即是Pod里的多個容器能夠同時掛載同一個外部數據卷，這對于部署緊密的服務是十分有作用的。
  

• Label

????? Labe（標簽）其實是一個K-V的鍵值對形式，用于標記Pod、Node、Namespace或其他任何資源對象的鍵值對。主要用于在查詢或選擇時對資源進行條件過濾。

• Service

  Service是Kubernetes集群對外提供的用戶業務功能抽象，表現為一個獨立的虛擬IP和端口，其實這個Service就是我們經常提起的微服務架構中的一個微服務。

  其實它的后端是由單個Pod或多個Pod的副本組成的容器結合，有K8S提供實際訪問的路由能力。通過這層，K8S能夠在后端完成諸如：服務和切換、負載均衡、依據資源情況的節點調度等。
  

  那這個Service和RC、Pod是什么關系呢？見下圖

  
  

  若公司有上百個或上千Service，這些Service之間有鏈路調用關系，那如何進行監控這些服務呢？

  ?一是在這些service中打印日志信息，通過ELK或EFK進行收集分析，二是通過服務網格來構建（Service Mesh）監控
  

• RC（Replication Controller）

  RC是在早期K8S版本中用于管理Pod副本對象的概念，其實其也包含了ReplicaSet和Deployment的作用，但不具有部署版本管理的功能，所以在1.2以后的版本中，建議使用Deployment和ReplicaSet替代它，不過優先使用Deployment
  

• Deployment

  Deployment是K8S在1.2版本引入的新概念，用于更好的解決Pod的編排問題。其實Deployment在內部使用了Replica Set來實現的，也即是說：Deployment所保存的部署描述信息是用來創建ReplicaSet對象，每個Deployment對象都會對應一個運行著的ReplicaSet對象，后者實際管理Pod副本的運行：

  大致方向如下：

  ?Deployment->ReplicaSet->Pod
  

• Ingress

  Ingress本質上是一個負載均衡，它被用來將集群中的用戶服務通過統一的IP地址暴露給外界。
  

• Namespace

  Namespace（命名空間）在很多情況下用于實現多租戶的資源隔離，K8S中除了Node和Label以外的大多數資源，例如：Pod，Service、LimitRange等，都是在創建特定Namespace里的（default是默認的namespace）
  

• sts（StatefulSet）

  STS是在Kubernetes1.5版本前稱為PetSet，用于部署和運行有持久化狀態服務的方式。在K8S中，Pod的管理對象RC、Deployment、Job都是面向無狀態的服務，利用STS可以部署MySQL集群、MongoDB集群、ZK集群、Redis集群等
  

• Job

  Job是用來批量執行一次性任務。每個Job同樣會對應一個或多個Pod，這些Pod執行是有 時間限制的，程序結束后，Job將被標記為成功或失敗。
  

• Volume

  Volume（存儲卷）是Pod中能夠被多個容器訪問的共享目錄。