你一定要了解的Kubernetes
| 前言 |
隨著容器技術的發展，Docker近幾年突然崛起，變得炙手可熱，已經成為容器技術的事實標準。然而想要在生成環境中成功部署和操作容器的關鍵是容器編排技術，市場上有各種各樣的容器編排工具（如Docker原生的Swarm），其中谷歌公司開發的Kubernetes得到開源社群的全力支援，IBM、惠普、微軟、RedHat等業界巨頭紛紛加入，Kubernetes已經成為GitHub上的明星開源專案。
| 簡介 |
Kubernetes這個名字源於希臘語，是舵手的意思，所以它的Logo既像一張漁網，又像一個羅盤。有意思的是Docker的Logo為馱著集裝箱在大海上遨遊的鯨魚，Kubernetes與Docker的關係可見一斑。
Kubernetes（也常稱K8s，用8代替8個字元“ubernete”而成的縮寫。）是一個全新的基於容器技術的分散式架構方案，它源自Google內部大規模叢集管理系統——Borg，也是CNCF（Cloud Native Computing Foundation，今屬Linux基金會）最重要的專案之一，旨在讓部署容器化的應用簡單並且高效。
Kubernetes 具備完善的叢集管理能力，包括多層次的安全防護和准入機制、多租戶應用支撐能力、透明的服務註冊和服務發現機制、內建負載均衡器、故障發現和自我修復能力、服務滾動升級和線上擴容、可擴充套件的資源自動排程機制、多粒度的資源配額管理能力。還提供完善的管理工具，涵蓋開發、部署測試、運維監控等各個環節。
Kubernetes 於2015年7月22日迭代到 v 1.0並正式對外公佈，截至2018年1月5日穩定版已經發布到 v.1.9.1。無論是英文還是中文社群都非常活躍，全球開源解決方案領導者 RedHat 公司已經將自己Paas產品OpenShift V3 的底層技術換成了Kubernetes與Docker。Kubernetes儼然已經成為全新容器生態的領導者。
| 架構 |
Kubernetes使用Go語言開發，叢集採用 Master/Node（最初稱為Minion，後改名Node） 的結構，Master（主節點）控制整個叢集，Node（從節點）為叢集提供計算能力。使用者可以通過命令列或者Web頁面的方式來操作叢集。
Master是Kubernetes叢集的大腦，負責公開叢集的API，排程部署和管理整個叢集。叢集至少有一個Master節點，如果在生產環境中要達到高可用，還需要配置Master叢集。
Master主要包含API Server、Scheduler、Controller三個元件，需要etcd元件來儲存整個叢集的狀態。
etcd：由CoreOS開發，是一個高可用、強一致性的服務發現儲存倉庫，為Kubernetes叢集提供儲存服務，類似於zookeper。
API Server： kubernetes最重要的核心元件之一，提供資源操作的唯一入口（其他模組通過API Server查詢或修改資料，只有API Server才直接操作etcd），並提供認證、授權、訪問控制、API註冊和發現等機制。
Scheduler：負責資源的排程，按照預定的排程策略將Pod（k8s中排程的基本單位）排程到相應的Node上。
Controller：通過API Server來監控整個叢集的狀態，並確保叢集處於預期的工作狀態，比如故障檢測、自動擴充套件、滾動更新等。
Node是Kubernetes叢集的工作節點，可以是物理機也可以是虛擬機器。Node需要包含容器、kubelet、kube-proxy等元件。Fluentd用來提供日誌收集功能（可選）。
kubelet：維護容器的生命週期，同時也負責Volume（CVI）和網路（CNI）的管理。每個節點上都會執行一個kubelet服務程序，接收並執行Master發來的指令，管理Pod及Pod中的容器。每個kubelet程序會在API Server上註冊節點自身資訊，定期向Master節點彙報節點的資源使用情況，並通過cAdvisor監控節點和容器的資源。
kube-proxy： 為 Service 提供叢集內部的服務發現和負載均衡，監聽 API Server 中 service和endpoint的變化情況，並通過iptables等方式來為服務配置負載均衡。
Docker： 每臺Node上需要安裝Docker來執行映象，但是Docker不是唯一選擇，Kubernetes支援多種容器，比如CoreOS公司的Rkt容器（之前稱為Rocket，現更名為Rkt）。
| 資源物件 |
API物件是Kubernetes叢集中的管理操作單元。叢集中的眾多技術概念分別對應著API物件，每個API物件都有3大類屬性：
metadata（元資料）：用來標識API物件，包含namespace、name、uid等。
spec （規範）：描述使用者期望達到的理想狀態，所有的操作都是宣告式（Declarative）的而不是命令式（Imperative），在分散式系統中的好處是穩定，不怕丟操作或執行多次。比如設定期望3個執行Nginx的pod，執行多次也還是一個結果，而給副本數加1的操作就不是宣告式的，執行多次結果就錯了。
status（狀態）：描述系統當前實際達到的狀態，比如期望3個pod，現在實際建立好了2個。
在Kubernetes眾多的API物件中，Pod是最重要的也是最基礎的，是kubernetes中可以建立的最小部署單元。Pod就像是豌豆莢一樣，它可以由一個或者多個容器組成，這些容器共享儲存、網路和配置項。
目前Kubernetes中的業務型別可以分為長期伺服型（long-running）、批處理型（batch）、節點後臺支撐型（node-daemon）和有狀態應用型（stateful application）這四種類型，而這四種類型的業務又可以由不同型別的Pod控制器來完成，分別為：Deployment、Job、DaemonSet和StatefulSet。
Deployment： 複製控制器（Replication Controller，RC）是叢集中最早的保證Pod高可用的API物件，副本集（Replica Set，RS）是它的升級，能支援更多種類的匹配模式。部署(Deployment)又是比RS應用模式更廣的API物件，以Kubernetes的發展方向，未來對所有長期伺服型的的業務的管理，都會通過Deployment來管理。
Service： Deployment保證了Pod的數量，但是沒有解決如何訪問Pod的問題，一個Pod只是一個執行服務的例項，隨時可能在一個節點上停止，在另一個節點以一個新的IP啟動一個新的Pod，因此不能以確定的IP和埠號提供服務。要穩定地提供服務需要服務發現和負載均衡能力，Service可以穩定為使用者提供服務。
Job： 用來控制批處理型任務，Job管理的Pod根據使用者的設定把任務成功完成就自動退出了。
DaemonSet： 後臺支撐型服務的核心關注點在叢集中的Node，要保證每個Node上都有一個此類Pod執行。比如用來收集日誌的Pod。
StatefulSet： 不同於RC和RS，StatefulSet主要提供有狀態的服務，StatefulSet中Pod的名字都是事先確定的，不能更改，每個Pod掛載自己獨立的儲存，如果一個Pod出現故障，從其他節點啟動一個同樣名字的Pod，要掛載上原來Pod的儲存繼續以它的狀態提供服務。比如資料庫服務MySQL，我們不希望一個Pod故障後，MySQL中的資料即丟失。
| 小結 |
事實上，Kubernetes的資源物件不止這些，要熟練的操作Kubernetes並瞭解其原理還有很長的路要走。本文只是巨集觀上的介紹了Kubernetes，對於想要了解Kubernetes的朋友是個不錯的開始。