k8s-Master&Node

前言

我們從前面可以知道容器可以簡單地理解爲 :
容器”，實際上是一個由 Linux Namespace、Linux Cgroups 和 rootfs 三種技術構建出來的進程的隔離環境。
從這個結構中我們不難看出，一個正在運行的 Linux 容器，其實可以被“一分爲二”地看待：

• 容器鏡像 （Container Image）:容器的靜態視圖, 是一組聯合掛載在 /var/lib/docker/aufs/mnt 上的 rootfs；
• 容器運行時 (Container Runtime) : 一個由 Namespace+Cgroups 構成的隔離環境.

k8s 的全局架構

總的來說 , k8s架構中, 都由 Master 和 Node 兩種節點組成，而這兩種角色分別對應着控制節點和計算節點。
K8S

• Master
  • Controller Manager : 控制器管理
  • API Server : API 服務
  • Scheduler : 調度相關
• Node

然後我們再來仔細看一下 Pod 中的細節.

Kubelet --> Container Runtime

Kubelet 通過一個叫 CRI（Container Runtime Interface）的遠程調用接口和容器進行交互 (比如 Docker) 進行交互

Kubelet --> Device Plugin

Kubelet 通過gRPC 協議同一個叫作 Device Plugin 的插件進行交互。這個插件，是 Kubernetes 項目用來管理 GPU 等宿主機物理設備的主要組件，也是基於 Kubernetes 項目進行機器學習訓練、高性能作業支持等工作必須關注的功能。

Kubelet --> Networking

Kubelet 通過CNI（Container Networking Interface）來控制網絡連接

Kubelet --> Volume Plugin

Kubelet 通過 CSI（Container Storage Interface) 來控制存儲相關的功能

Container Runtime --> OS

容器則是通過 OCI 同底層的操作系統進行交互，例如linux 操作系統, 即：是對 Linux 操作系統的調用（操作 Linux Namespace 和 Cgroups 等）。

我們編程的時候做上層設計一般都是做接口 , 而實現則是繼承接口就可以了, 所以這個地方也可看出 k8s 的高度.

另外一張 K8s 簡易架構圖

(圖片來自 : https://blog.csdn.net/fajing_feiyue/article/details/107732453)

可以看到 Master 管理着 Node , 而 Node 裏面又有多個 Pod

Master 節點

Kubemetes 裏的Master 指的是集羣控制節點，每個Kubemetes 集羣裏需要有一個Master
節點來負責整個集羣的管理和控制，基本上Kubemetes 所有的控制命令都是發給它，它來負責
具體的執行過程，我們後面所有執行的命令基本都是在Master 節點上運行的。Master 節點通常
會佔據一個獨立的X86 服務器(或者一個虛擬機)，一個主要的原因是它太重要了，它是整個
集羣的"首腦"，如果它右機或者不可用，那麼我們所有的控制命令部將失效。

Master 節點上運行着以下一組關鍵進程。

• Kubemetes API Server (kube-apiserver) ，提供了HTTP Rest 接口的關鍵服務進程，是Kubemetes 裏所有資源的增、刪、改、查等操作的唯-入口，也是集羣控制的入口進程。

• Kubemetes Controller Manager ( kube-controller-manager ), Kubemetes 裏所有資源對象的自動化控制中心，可以理解爲資源對象的"大總管"。後面我們看到的哪些什麼 RepeatSet 之類的對象

• Kubemetes Scheduler Ckube-scheduler) ，負責資源調度CPod 調度)的進程，相當於公交公司的"調度室"。

其實Master 節點上往往還啓動了→個etcd Server 進程，因爲Kubemetes 裏的所有資源對象
的數據全部是保存在etcd 中的。(試想一下假如沒有持久化的工具, 那麼只能放在內存中, 那麼重啓的時候就會都消失了, 所以)

Node 節點

除了Master ， Kubemetes 集羣中的其他機器被稱爲Node 節點，， Node 節點可以是一臺物理主機，也可以是二臺虛擬機。Node 節點纔是Kubemetes 集羣中的工作負載節點，每個Node 都會被Master 分配一些工作負載(工作負載指的是容器 ,例如 : docker )，當某個Node 巖機時，其上的工作負載會被Master 自動轉移到其他節點上去。每個Node 節點上都運行着以下一組關鍵進程。

• kubelet: 負責Pod 對應的容器的創建、啓停等任務，同時與Master 節點密切協作，實現集羣管理的基本功能。
• kube-proxy: 實現Kubemetes Se凹lce 的通信與負載均衡機制的重要組件。
• Docker Engine (docker ): Docker 引擎，負責本機的容器創建和管理工作。Node 節點可以在運行期間動態增加到Kubemetes 集羣中，前提是這個節點上己經正確安裝、配置和啓動了上述關鍵進程，在默認情況下kubelet 會向Master 註冊自己，這也是Kubemetes推薦的Node 管理方式。一旦Node 被納入集羣管理範圍， kubelet 進程就會走時向Master 節點彙報自身的情報，例如操作系統、Docker 版本、機器的CPU 和內存情況，以及之前有哪些Pod在運行等，這樣Master 可以獲知每個Node 的資源使用情況，並實現高效均衡的資源調度策略。而某個Node 超過指定時間不上報信息時，會被Master 判定爲"失聯"， Node 的狀態被標記爲不可用CNot Ready) ，隨後Master 會觸發"工作負載大轉移"的自動流程。

Pod

開始覺得Pod 對應着一臺虛擬機 ,但是，過段時間，你會發現 Pod 中的每個容器都有一個隔離的文件系統，並且從一個容器內部，你看不到在同一 Pod 的其他容器中運行的進程。好吧！也許 Pod 不是一個微型的服務器，而只是一組具有共享網絡堆棧的容器。

這東西最搞笑 , Node 我是改變不了的, 要不就是一臺物理機 ,要不就是一臺虛擬機 ,都可認爲是 Node , 而 Pod 作爲基本單位, 是可以調度的. 比如某個 Pod 被調度到 NodeA 部署,但是部署失敗了, 那麼就有可能被調度到 NodeB 中去部署, 這也是爲啥 Pod 是 k8s 中的最基本的調度單位 .

k8s 是如何編排的

下面這一段來自課程

按照這幅圖的線索，我們從容器這個最基礎的概念出發，首先遇到了容器間“緊密協作”關係的難題，於是就擴展到了 Pod；有了 Pod 之後，我們希望能一次啓動多個應用的實例，這樣就需要 Deployment 這個 Pod 的多實例管理器；而有了這樣一組相同的 Pod 後，我們又需要通過一個固定的 IP 地址和端口以負載均衡的方式訪問它，於是就有了 Service。

可是，如果現在兩個不同 Pod 之間不僅有“訪問關係”，還要求在發起時加上授權信息。最典型的例子就是 Web 應用對數據庫訪問時需要 Credential（數據庫的用戶名和密碼）信息。那麼，在 Kubernetes 中這樣的關係又如何處理呢？

Kubernetes 項目提供了一種叫作 Secret 的對象，它其實是一個保存在 Etcd 裏的鍵值對數據。這樣，你把 Credential 信息以 Secret 的方式存在 Etcd 裏，Kubernetes 就會在你指定的 Pod（比如，Web 應用的 Pod）啓動時，自動把 Secret 裏的數據以 Volume 的方式掛載到容器裏。這樣，這個 Web 應用就可以訪問數據庫了。

除了應用與應用之間的關係外，應用運行的形態是影響“如何容器化這個應用”的第二個重要因素。

爲此，Kubernetes 定義了新的、基於 Pod 改進後的對象。比如 Job，用來描述一次性運行的 Pod（比如，大數據任務）；再比如 DaemonSet，用來描述每個宿主機上必須且只能運行一個副本的守護進程服務；又比如 CronJob，則用於描述定時任務等等。

如此種種，正是 Kubernetes 項目定義容器間關係和形態的主要方法。

可以看到，Kubernetes 項目並沒有像其他項目那樣，爲每一個管理功能創建一個指令，然後在項目中實現其中的邏輯。這種做法，的確可以解決當前的問題，但是在更多的問題來臨之後，往往會力不從心。

相比之下，在 Kubernetes 項目中，我們所推崇的使用方法是：

• 首先，通過一個“編排對象”，比如 Pod、Job、CronJob 等，來描述你試圖管理的應用；
• 然後，再爲它定義一些“服務對象”，比如 Service、Secret、Horizontal Pod Autoscaler（自動水平擴展器）等。這些對象，會負責具體的平臺級功能。

這種使用方法，就是所謂的“聲明式 API”。這種 API 對應的“編排對象”和“服務對象”，都是 Kubernetes 項目中的 API 對象（API Object）。

可以看到 service 和 deployment實際上是一個邏輯概念 , 這裏可以這麼理解, 例如我們應用中有個推送模塊--push 模塊, 爲了防單點故障,所以該模塊部署有三份,,模塊對外提供推送服務(service) , 那麼 "推送服務"就可以作爲一個 service ,而前面講到的三份部署可以抽象成一個 deployment .

問題

Pod service Job 是個邏輯概念嗎? Pod 裏的容器是不是隻能在同一臺機器上(同一個集羣節點上)

除了容器 , 其他都是邏輯概念 ,也就是不存在實物的 ,而鏡像是真實存在 .
同一個Pod 中的容器需要共享同一組網絡等其他NameSpec , 所以需要在同一個節點上 .

總結

k8s 的更像是一個集大成的工具 ,而 docker 則是容器的代表 ,從另外一個方面來說 k8s 中的工作負載不僅可以是 docker ,還可以是其他容器 .在我看來 K8S 主要編排的兩個重要作用是 :

• 處理好應用間的關係
• 它對一些常用的共有應用變成了它的"API 對象" , 這大大地使得應用從基礎框架解決出來 ,只專心負責業務就夠了.

參考資料 :

• <<09丨從容器到容器雲：談談Kubernetes的本質>> 這一個要好好看看
• https://zhuanlan.zhihu.com/p/32618563
• https://www.bilibili.com/video/BV1Et411j7R2?p=4 推薦一看的課程
• https://blog.csdn.net/fajing_feiyue/article/details/107732453