是 Google 基於 Borg 開源的容器編排排程，用於管理容器叢集自動化部署、擴容以及運維的開源平臺。作為雲原生計算基金會 CNCF（Cloud Native Computing Foundation）最重要的元件之一（CNCF 另一個畢業專案 Prometheus ），它的目標不僅僅是一個編排系統，而是提供一個規範，可以讓你來描述叢集的架構，定義服務的最終狀態，Kubernetes 可以幫你將系統自動地達到和維持在這個狀態，Kubernetes 也可以對容器(Docker)進行叢集管理和服務編排（Docker Swarm 類似的功能）,對於大多開發者來說，以容器的方式執行一個程式是一個最基本的需求，跟多的是 Kubernetes 能夠提供路由閘道器、水平擴充套件、監控、備份、災難恢復等一系列運維能力（強烈建議閱讀

使用 Kubernetes，可以快速高效地響應客戶需求：

• 動態地對應用進行擴容。
• 無縫地釋出新特性。
• 僅使用需要的資源以優化硬體使用。

Kubernetes 這個名字源自希臘語，意思是“舵手”，也是“管理者”，“治理者”等詞的源頭。k8s 是 Kubernetes 的簡稱（用數字『8』替代中間的8個字母『ubernete』）。

為何要使用容器技術

下面是一些關鍵點:

• 以應用程式為中心的管理： 將抽象級別從在虛擬硬體上執行作業系統上升到了在使用特定邏輯資源的作業系統上執行應用程式。
• 開發和運維的關注點分離: 提供構建和部署的分離；這樣也就將應用從基礎設施中解耦。
• 敏捷的應用建立和部署: 相對使用虛擬機器映象，容器映象的建立更加輕巧高效。
• 持續開發，持續整合以及持續部署: 提供頻繁可靠地構建和部署容器映象的能力，同時可以快速簡單地回滾(因為映象是固化的)。
• 鬆耦合，分散式，彈性，自由的微服務: 應用被分割為若干獨立的小型程式，可以被動態地部署和管理 -- 而不是一個執行在單機上的超級臃腫的大程式。
• 開發，測試，生產環境保持高度一致: 無論是再膝上型電腦還是伺服器上，都採用相同方式執行。
• 相容不同的雲平臺或作業系統上: 可執行與 Ubuntu，RHEL，on-prem 或者 Google Container Engine，覆蓋了開發，測試和生產的各種不同環境。
• 資源分離: 帶來可預測的程式效能。
• 資源利用: 高效能，大容量。

Kubernetes 不是 PaaS（平臺即服務）

• Kubernetes 並不對支援的應用程式型別有任何限制。 它並不指定應用框架，限制語言型別，Kubernetes 旨在支援各種多種多樣的負載型別：只要一個程式能夠在容器中執行，它就可以在Kubernetes中執行。
• 由於 Kubernetes 執行再應用層而不是硬體層，所以它提供了一些一般 PaaS 提供的功能，比如部署，擴容，負載均衡，日誌，監控，等等。無論如何，Kubernetes 不是一個單一應用，所以這些解決方案都是可選可插拔的。
• Kubernetes 並不是單單的"編排系統"；“編排”的技術定義為按照指定流程執行一系列動作：執行A，然後B，然後C。相反，Kubernetes 有一系列控制程序組成，持續地控制從當前狀態到指定狀態的流轉。無需關注你是如何從A到C：只需結果如此。這樣將使得系統更加易用，強大，健壯和彈性。

Kubernetes 核心元件

Kubernetes 叢集可以部署在物理機或虛擬機器上,用於協調高度可用的計算機叢集，這些計算機群集被連線作為單個單元工作。 Kubernetes 的抽象性允許您將容器化的應用程式部署到叢集，而不必專門將其繫結到單個計算機。為了利用這種新的部署模型，應用程式需要以將它們與各個主機分離的方式打包: 它們需要被容器化。容器化應用程式比過去的部署模型更靈活和可用，其中應用程式直接安裝到特定機器上，作為深入整合到主機中的軟體包。

Kubernetes 叢集由兩種型別的資源組成:

• Master 節點是叢集的排程節點 (Master 節點管理叢集，而 Node 用於託管正在執行的應用程式)
• Node 節點是應用程式實際執行的工作節點(Node節點使用 Master 公開的 Kubernetes API 與 Master 通訊)

Master 負責管理叢集，Node 協調叢集中的所有活動，例如排程應用程式、維護應用程式的所需狀態、擴充套件應用程式和滾動更新。每個工作節點都有一個 Kubelet，Node 節點上還應具有處理容器操作的工作，例如 Docker 或 rkt。

Master

Kubernetes 裡的 Master 指的是叢集控制節點，每個 Kubernetes 叢集裡需要有一個 Master節 點來負責整個叢集的管理和控制，基本上 Kubernetes 所有的控制命令都是發給它，它來負責具體的執行過程，我們後面所有的執行命令基本都是在 Master 上執行的，它就是整個叢集的“首腦”。

Master節點上執行著以下的一組程序

• kube-apiserver 叢集控制的入口,提供了 HTTP Rest 介面的關鍵服務程序，是 Kubernetes 裡所有資源的增刪改查等操作的唯一入口，也是叢集控制的入口進行。

• kube-controller-manager，Kubernetes 裡所有資源物件的自動化控制中心，比如故障檢測、自動擴充套件、滾動更新等。

• kube-scheduler 負責 Pod 資源排程。

• etcd 用於共享配置和服務發現，儲存 Kubernetes 叢集所有的網路配置和物件的狀態資訊。

Node

除了 Master，Kubernetes 叢集中的其它機器又被稱為 Node 節點，是 Kubernetes 叢集中的工作負載節點，每個 Node都會被 Master 分配一些工作負載（Docker 容器），當某個Node 宕機時，其上的工作負載會被 Master 自動轉移到其它節點上。

每個 Node 節點上都執行著以下的一組關鍵程序：

• kubelet：負責 Pod 對應的容器的建立，啟動等任務，同時與Master節點密切協作。

• kube-proxy：實現 Kubernetes Service 的通訊與負載均衡機制的重要元件。

• lube-proxyContainer Runtime（Docker, rkt, runc）：負責本機的容器建立和管理工作。

基本物件與術語

Pod

Pod 是一組緊密關聯的容器集合，它們共享 PID、IPC、Network 和 UTS namespace，是Kubernetes 排程的基本單位。Pod 的設計理念是支援多個容器在一個 Pod 中共享網路和檔案系統，可以通過程序間通訊和檔案共享這種簡單高效的方式組合完成服務。

Label

Label 是識別 Kubernetes 物件的標籤，以 key/value 的方式附加到物件上（key最長不能超過63位元組，value 可以為空，也可以是不超過253位元組的字串）。 Label 不提供唯一性，並且實際上經常是很多物件（如 Pods）都使用相同的 label 來標誌具體的應用。 Label 定義好後其他物件可以使用 Label Selector 來選擇一組相同 label 的物件（比如 Service 用 label 來選擇一組 Pod）。Label Selector支援以下幾種方式：

• 等式，如app=nginx和env!=production
• 集合，如env in (production, qa)
• 多個label（它們之間是AND關係），如app=nginx,env=test

Namespace

Namespace 是對一組資源和物件的抽象集合，比如可以用來將系統內部的物件劃分為不同的專案組或使用者組。常見的 pods, services,deployments 等都是屬於某一個 namespace 的（預設是default），而 Node, PersistentVolumes 等則不屬於任何 namespace。

ReplicationController

在舊版本的 Kubernetes 中，只有 ReplicationController物件。它的主要作用是確保Pod以你指定的副本數執行，即如果有容器異常退出，會自動建立新的 Pod 來替代；而異常多出來的容器也會自動回收。可以說，通過 ReplicationController，Kubernetes實現了叢集的高可用性。

ReplicaSet

ReplicaSet 是 ReplicationController 的代替物，因此用法基本相同，唯一的區別在於 ReplicaSet 支援集合式的 selector。雖然也 ReplicaSet 可以獨立使用，但建議使用 Deployment 來自動管理 ReplicaSet，這樣就無需擔心跟其他機制的不相容問題（比如 ReplicaSet 不支援 rolling-update 但 Deployment 支援），並且 Deployment 還支援版本記錄、回滾、暫停升級等高階特性。

Deployment

Deployment 確保任意時間都有指定數量的 Pod“副本”在執行。如果為某個 Pod 建立了 Deployment 並且指定3個副本，它會建立3個 Pod，並且持續監控它們。如果某個 Pod 不響應，那麼 Deployment 會替換它，保持總數為3。如果之前不響應的 Pod 恢復了，現在就有4個 Pod 了，那麼 Deployment 會將其中一個終止保持總數為3。如果在執行中將副本總數改為5，Deployment 會立刻啟動2個新 Pod，保證總數為5。Deployment 還支援回滾和滾動升級。

當建立 Deployment 時，需要指定兩個東西：

• Pod 模板：用來建立 Pod 副本的模板
• Label 標籤：Deployment 需要監控的 Pod 的標籤。

現在已經建立了 Pod 的一些副本，那麼在這些副本上如何均衡負載呢？我們需要的是 Service。

StatefulSet

StatefulSet 是為了解決有狀態服務的問題（對應 Deployments 和 ReplicaSets是為無狀態服務而設計），其應用場景包括

• 穩定的持久化儲存，即 Pod 重新排程後還是能訪問到相同的持久化資料，基於 PVC 來實現
• 穩定的網路標誌，即 Pod 重新排程後其 PodName 和 HostName 不變，基於 Headless Service（即沒有Cluster IP的Service）來實現
• 有序部署，有序擴充套件，即 Pod 是有順序的，在部署或者擴充套件的時候要依據定義的順序依次依次進行（即從0到N-1，在下一個Pod執行之前所有之前的 Pod 必須都是 Running 和 Ready 狀態），基於 init containers來實現
• 有序收縮，有序刪除（即從N-1到0）

DaemonSet

DaemonSet 保證在每個Node上都執行一個容器副本，常用來部署一些叢集的日誌、監控或者其他系統管理應用。典型的應用包括：

• 日誌收集，比如 fluentd，logstash 等
• 系統監控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
• 系統程式，比如 kube-proxy, kube-dns, glusterd, ceph 等

Service

Service 是應用服務的抽象，通過 labels 為應用提供負載均衡和服務發現。匹配 labels 的Pod IP 和埠列表組成 endpoints，由 kube-proxy 負責將服務 IP 負載均衡到這些endpoints 上。每個 Service 都會自動分配一個 cluster IP（僅在叢集內部可訪問的虛擬地址）和 DNS 名，其他容器可以通過該地址或 DNS 來訪問服務，而不需要了解後端容器的執行。

Job

Job 負責批量處理短暫的一次性任務 (short lived one-off tasks)，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束。

Kubernetes 支援以下幾種 Job：

• 非並行 Job：通常建立一個 Pod 直至其成功結束
• 固定結束次數的 Job：設定 .spec.completions，建立多個 Pod，直到 .spec.completions 個 Pod 成功結束
• 帶有工作佇列的並行 Job：設定 .spec.Parallelism 但不設定 .spec.completions，當所有Pod結束並且至少一個成功時，Job 就認為是成功

CronJob

CronJob 即定時任務，就類似於 Linux 系統的 crontab，在指定的時間週期執行指定的任務。在 Kubernetes 1.5，使用 CronJob 需要開啟 batch/v2alpha1 API，即–runtime-config=batch/v2alpha1。

Horizontal Pod Autoscaler（HPA）

Horizontal Pod Autoscaling 可以根據 CPU 使用率或應用自定義 metrics 自動擴充套件 Pod 數量（支援replication controller、deployment和replica set），從而合理的擴充套件效能與使用資源。

總結

上述只是對 Kubernetes 的一些簡單概述，對於 Kubernetes 本身還是很複雜的，特別是要應用到生產環境中去，需要熟悉各元件的工作機制，另外還需要考慮到網路 ，儲存，監控，故障轉移，高可用，以及安全性等因素。