導讀：

Kubernetes如今風靡一時，所有主要的云服務提供商都將其作為部署云原生應用的解決方案。Kubernetes有哪些顯著的特性和工具優勢，讓企業開始接受它?本文作者給出了系統的梳理。

“Action without orchestration is burn out; orchestration w/o action is management.”

沒有編排的行動是完蛋的，沒有行動的編排是管理，行動加上編排是領導。― Orrin Woodward”

• Kubernetes是一種優化資源利用率的抽象概念，它允許跨節點集群高效地進行應用程序分發。
• Kubernetes，舵手 !
• Kubernetes是一個希臘語單詞，意思是“舵手”。

它是一個由谷歌開始的開源項目，從Borg衍生而來，在谷歌內部使用了好幾年，現在用于容器管理。目前由CNCF托管。

Kubernetes(縮寫為K8S)是一種抽象，它通過容器來優化CPU和內存等資源的利用率，從而可以跨多個節點高效地進行應用程序分發。K8S可以在裸金屬或任何云基礎設施提供商的任何地方運行。這個新工具是云無關的，聚焦于在基礎設施內部部署和調度容器，而不是直接利用節點/主機。

K8S提供的一些平臺特性是:

• 使用pod進行容器分組
• 自愈
• 自動伸縮
• DNS管理
• 負載均衡
• 滾動更新或回滾
• 資源監控和日志記錄

Kubernetes 架構

Kubernetes集群由主節點和一組worker/從屬節點組成。

Kubernetes的主節點組成部分是:

1. API服務器(API Server)：用戶通過Rest操作或kubectl cli與manifestyaml交互。它用于所有與API對象相關的操作，如pod創建，它是在etcd中存儲所需狀態的***組件。
2. 調度器(Scheduler)：用戶使用kubectl cli向API服務器發出一個命令來創建pod。在執行此操作之后，調度程序根據資源需求將pods分配給可用節點。
3. 控制器管理器(Controller Manager)：控制器管理器基于集群狀態對資源進行操作，并根據清單yaml進行更改，將當前狀態應用程序達到所需狀態。換句話說，控制器管理器可以將實際狀態與所需的狀態進行協調。在控制器管理器中有多個專用的控制器，以便簡化集群管理。例如，節點控制器檢查是否有當前正在運行的節點停機，并采取糾正措施，而復制控制器確保在節點中實際運行所需的pod數量。
4. etcd：所有關于集群狀態的配置信息都以key/value對的形式存儲在etcd中，這個組件由CoreOS實現。這些狀態顯示了集群中包含的節點和需要在其中運行的pods。
5. 插件(Addons)：為了將服務器DNS記錄添加到Kubernetes，我們需要一個集群DNS 插件。該插件有助于擴展與Kubernetes集群或節點相關的功能。還有許多其他的插件，比如用于日志記錄的fluntd、基于角色訪問的rbac等等。

安裝在Kubernetes節點中的組件是:

• Docker: Docker守護進程在每個節點中運行。如果容器鏡像不存在，那么它將從docker注冊中提取并運行。
• Kubelet: Kubelet節點代理定期檢查容器內容器的健康狀況。此外，它還確保按manifest安裝卷，并下載運行容器所需的敏感信息。它還將節點鏈接到API服務器。
• Kube-proxy: Kube-proxy在每個節點上運行，以便在pod中進行負載分配，并為外部主機提供可用的服務。它使用iptable規則或輪詢調度來將請求轉發到正確的容器。

對于高可用和容錯的Kubernetes生產和部署，需要多個主節點和一個單獨的etcd集群。如果運行了三個API服務器，則需要一個網絡負載平衡器來正確地將負載分配到服務器。***剩下的問題是需要三個角色來管理控制器管理器和調度器以維護集群狀態和分配節點。為了更高效、更可靠地執行它，只有一個參與者應該執行實際的更改，但是在機器宕機的情況下仍然需要其他實例。為了解決這個問題，我們可以在API中使用lease-lock 來執行主選，而使用它的標志是leader- elect。

Kubernetes通過以下任一種方式實現從Pod到Pod的聯網:

• 第2層(切換解決方案)
• 第3層(橋接解決方案)
• overlay解決方案(weave andflannel)

它們允許在集群中進行Pod和Pod之間的通信，并為每個Pod提供***的IP地址。

Kubernetes關鍵特性

Pod: Collection of Containers容器集

pod是K8S中的一個部署單元，它有一個單獨的IP地址。在它內部，Pause容器通過持有一個網絡的名稱空間、端口和ip地址來處理網絡，而這個地址又被pod中的所有容器使用。

ReplicationController

ReplicationController確保在給定的時間內啟動和運行所需的容器數量。Pod模板用于定義容器鏡像標識符、端口和標簽。使用liveness probes，它可以自動治愈pods，并按照期望的狀態維持pods數量。也可以通過使用kubectl來手動控制副本計數。

存儲管理

Pods本質是短暫的——任何儲存在pod或容器中的信息都會丟失。為了存儲數據，一個持久的系統是必需的，即使在一個pod被殺死或重新調度之后，如Amazon Elastic Block Storage (EBS)，谷歌GCE PD，或一個分布式文件系統，如網絡文件系統(NFS)或Gluster文件系統(GFS)。

資源監控

監控是成功運行基礎設施的關鍵之一，它是可靠性等級的基礎。Heapster是一個從kubelet收集指標的插件，與cAdvisor集成。cAdvisor用于收集與運行容器的CPU、內存、I/O和網絡統計數據相關的指標。由Heapster收集的數據存儲在influx DB中，并使用Grafana在UI中顯示。還有其他可使用的接收器，如Kafka或Elastic Search，可以用于存儲數據并顯示在用戶界面中。

健康檢查

kubernetes的健康檢查由kubelet代理完成。它分為liveness 和 readiness probes兩種。

處理程序主要有三種類型:

1. ExecAction:執行Shell命令，如果生成的退出代碼為0，則意味著實例是健康的。在任何其他情況下，實例不健康。
2. TCPAction: Kubelet將嘗試連接到指定的端口，如果它建立到給定socket的連接，診斷成功。
3. HTTPGetAction:基于應用程序公開的HTTP端點，kubelet對指定路徑上的容器IP地址執行HTTP GET請求，如果返回200到300個響應代碼，診斷就成功了。

每個probe通常有三個結果:

• 成功:容器通過診斷。
• 失敗:容器未通過診斷。
• 未知:診斷失敗，不要采取任何行動。

水平自動伸縮功能

自動伸縮使用基于負載的計算資源。K8S scale pod自動使用Horizontal Pod Autoscaler對象，從Heapster獲取度量數據，并相應地減少或增加pod的數量。例如，如果自動伸縮是基于內存利用率，那么控制器就會開始在pod中觀察內存使用情況，并根據容量對該副本計數進行擴展。

服務發現

Kubernetes pods是短暫的，ReplicationController 在任何節點上動態創建它們，因此在集群中發現服務是一個挑戰。服務需要發現一個IP地址和動態的端口，以便在集群中進行通信。

有兩種主要的方法來找到它——環境變量(Environment variables)和DNS。

更可取的是基于DNS的服務發現，它可以作為集群附加組件使用。跟蹤集群中的新服務，并為每個服務創建一組DNS記錄。

網絡

要完全管理集群，必須正確設置網絡，并解決三個網絡問題:

1. 容器到容器的通信：pods通過本地主機通信，并使用Pause容器網絡名稱空間，解決這個問題。
2. Pod-to-Pod通信：由軟件定義的網絡解決，如上面架構圖所示。
3. 外部到pod通信：由服務覆蓋。

Kubernetes提供了廣泛的網絡選擇。現在還支持容器網絡接口(CNI)插件，這是容器的通用插件架構。目前支持多種編排工具，如Kubernetes、Mesos和CloudFoundry。

有各種覆蓋插件:

1. Flannel來自CoreOS，是一個非常簡單的etcd后端覆蓋網絡。它創建了另一個虛擬的、可路由的IP / Pod網絡，運行在底層網絡之上;ergo，稱為覆蓋網絡。在這個覆蓋網絡中，每個Pod將被分配一個IP地址，并且會直接使用它們的IP進行通信。
2. Weave通過CNI插件提供與Kubernetes兼容的覆蓋網絡。

服務

Kubernetes服務是一種抽象，它將通信路由到一組pod，以提供一個微服務。Kube-proxy在每個節點上運行，并通過設置一組iptable規則來管理服務。

設立服務的模式有三種：

1. ClusterIP(只提供內部訪問)
2. NodePort(需要在端口上打開防火墻;不建議公開訪問)
3. 負載均衡器(由AWS或GKE等公有云供應商擁有)

ConfigMap和Secret

ConfigMap使注入基于環境的配置成為可能，同時使容器鏡像在多個環境中保持一致。這些可以通過安裝卷或環境變量(environment variables)來注入，并將這些值存儲在key/value格式中。

Secrets用于存儲敏感數據，如密碼、OAuth令牌等。

滾動部署和回滾

部署對象持有一個或多個副本集，以支持回滾機制。換句話說，每次更改部署配置時都會創建一個新的副本集，并保留以前的版本，以便有回滾選項。只有一個副本集將在特定時間處于活動狀態。

對于滾動部署，需要的策略類型是RollingUpdate和minReadySecs，它指定應用程序為服務流量所花費的時間。如果在應用程序pod還沒有準備好時，將其保持默認狀態，它將不可用。這個動作可以通過以下命令來完成:

或者，

通過替換部署yaml文件中的內容并運行以下命令:

如果新版本不像預期的那樣，那么可以通過運行以下命令回滾到以前的版本:

如果所需版本是前一版本以外的版本，則運行：

Logging 記錄

要監視應用程序的行為，必須檢查日志——每個pod生成多個日志。要開始在儀表板UI中搜索日志，必須有一些機制收集并將它們聚合到一個日志查看器中。為了說明這一點，Fluentd是一個開源工具，也是CNCF的一部分，與 Elastic Search 和 Kibana ***結合。