iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 2
4
DevOps

從題目中學習k8s系列 第 2

【從題目中學習k8s】-【Day2】K8s 集群中有什麼

  • 分享至 

  • xImage
  •  

title: 【從題目中學習k8s】-【Day2】K8s 集群中有什麼
description: 以無比的恆毅力堅持30天鍊成鐵人--連續30天,一天發表一篇IT技術文章

【從題目中學習k8s】-【Day2】K8s 集群中有什麼

tags: DevOps CICD K8s Docker

Kubernetes架構

K8s是一個"集群(Cluster)"的架構,由一群節點(Node)集合而成,這些Node會將Application以容器的形式管理(要記住,在K8s中是不能直接對容器進行操作的,需要通過Pod。那Pod是甚麼呢?又為甚麼要這樣設計呢?放心,這些我們過兩天都會講到,就繼續看下去吧~)。
每個叢集當中會有一個Controller Plane 和數個Node,視你的需求而定(也可能有Multi-Controller Plane 的集群,類似Hot Standby的概念)。

Controller Plane在舊版的K8s稱為Master Node,而Node以前則叫做Slave/Worker Node或更早版本的Minion。兩者其實一樣,只是換了名詞而已

  • Controller Plane
    Controller Plane是整個K8s集群的大腦,是K8s運作的指揮中心。可以將Controller Plane看成一個特殊的Node,負責管理所有其他 Node。負責管理Pod的運作、生命週期、排程節點資源以及監控整個集群的狀態等等。是K8s中最重要的節點。通常Controller Plane會佔據一個獨立的Server(高可用佈署建議用三台Server),因為它太重要了!
  • Node
    NodeK8s的物件(resource-objects)實際運行的場所,可以對應到一台機器,像是筆電、虛擬機或是 AWS 上的一台 EC2 或 GCP 上的一台 Computer Engine (來源)。Node的工作是負責將Application以容器的形式運行在K8s集群中。

接下來介紹一下這些Node各自包含哪些組件吧~


Controller Plane

Controller Plane主要功能是Manage, Plan, Schedule, Monitor Node。一個 Controller Plane中包含四個組件:kube-apiserveretcdkube-schedulerkube-controller-manager

kube-apiserver

kube-apiserver是整個K8s集群最重要的組件,提供HTTP Rest介面的關鍵服務處理程序,是集群中各個節點的溝通橋樑,並管理整個 K8s 所需 API 的接口(Endpoint)。一旦kube-apiserver故障,整個集群就會無法操作,例如無法新增、刪除Pod等。另外,kube-apiserver也負責 K8s 中的請求的身份認證與授權

每個 Node 之間的溝通必須要透過 kube-apiserver,彼此之間是無法"直接"溝通的喔

etcd

用來存放 K8s Cluster 的資料作為備份,可以把他想像為整個集群的database,會記錄整個集群的狀態及資料。當 Controller Plane 故障時,可以透過 etcd 幫我們還原 Kubernetes 的狀態。

kube-scheduler

負責集群的資源調配,調度Pod運行在哪個Node上,是整個 Kubernetes 集群的調度員。

kube-controller-manager

負責管理並運行 K8s controller 的組件,負責監視 Cluster 狀態的組件,是K8s中所有resource-objects的自動化控制中心。kube-controller-manager又可以細分為:

  • Controller-Manager
  • Node-Controller
  • Replication-Controller

詳細功能可以不用深度了解,有個概念就可以了~

kube-controller-manager 的監視與更新也都需要透過訪問 kube-apiserver 達成

Node

Node的工作只有一個,那就是Host Application as Containers,而Node又包含三個組件:kubeletkube-proxyContainer Runtime

kubelet

對應api-server的接口,可以看成每個Node上的"實際執行者"或"操作者",負責接收來自api-server的訊息,並做出相對應的動作,例如,負責Pod對應的容器的建立、啟動或停止等。

kube-proxy

kube-proxy 是一個 network proxy,負責維護Node上的網路規則(iptables),這些規則允許從群集內部或外部的與Pod進行通訊。

kube-proxy是service的一部分概念。service會在之後幾天介紹

Container Runtime

Node上運行容器的執行程式,K8s預設是Docker,但也支援其他Runtime Engine,例如rkt、CRI-O、containerd, kata container等

K8s 本身只需要專注於 kubelet 以及 CRI (Container Runtime Interface) 標準的互動,第三方開發者則可以根據需求開發出各式各樣不同的產品,只要能夠滿足 CRI 標準,都可以作為K8s的Container Runtime Engine。因此不一定只能用Docker喔


YAML

這邊先提一下,在K8s中所有物件(resorce-object)都是用YAML File來描述。我們需要寫非常大量的YAML來創造物件,因此大家常常聽到K8s Engineering被稱為"YAML Engineering"就是這麼回事啦~如果對YAML格式不太熟悉的朋友可以參考這篇文章,裡面寫的滿詳細的。

YAML是一個可讀性高,用來表達資料序列化的格式。有點類似JSON檔。

而在K8s中的YAML檔,有四個欄位是必須的:apiVersionkindmetadataspec

apiVersion

apiVersion其實就是API的版本,因為k8s提供給每個物件的API版本都不同,需要跟著物件來更改需要的apiVersion

kind

kind就是我們這個YAML是要用來創造哪個物件。像是PodServiceDeployment等等。它們都有各自對應的apiVersion,像是:

kind apiVersion
Pod v1
Service v1
Deployment apps/v1
ReplicaSet apps/v1

metadata

metadata是用來描述這個物件的資訊,像是它的名稱,lable等。

spec

spec是這四個欄位中最重要的欄位,也是最複雜的,用來定義這個物件內有甚麼,也就是說,用來定義這個物件是要用來幹嘛的。例如一個Pod內有Container,那kind就是Pod,而Container的資訊則寫在spec欄位,代表這個Pod的功能是host一個Container,至於這個Container要做甚麼事,就寫在spec.containers.X 內囉~


結論

今天主要是介紹一下K8s整個集群的架構,先從一個比較High-Level的角度來切入,我想大家可能會比較容易理解。但今天只是個簡單的介紹,若要詳細了解每個組件到底在做甚麼,可以參考其他大神的文章,都寫得很好喔~
另外提一下,其實當我們在使用K8s的時候,不需要特地區分某個功能是由哪個組件implement,就算不知道使用上也不會有影響。但在troubleshooting的時候,如果對這些組件的功能都有了解,會比較容易debug唷~
明天就來實際建置我們的K8s集群吧~

參考資料

Kubernetes Components
Kubernetes 基礎教學

Thank you!

You can find me on


上一篇
【從題目中學習k8s】-【Day1】K8s初探
下一篇
【從題目中學習k8s】-【Day3】建立K8s Cluster環境-以kubeadm為例
系列文
從題目中學習k8s31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
Jay Chang
iT邦新手 5 級 ‧ 2020-11-27 11:27:51

關於 Container Runtime 的部分,rkt 已經停止開發了
看一下 k8s 官方文件 只列出三個常用的 container runtime

  • containerd
  • CRI-O
  • Docker

不知道 k8s 跟 CRI 跟 container runtimes 之間的版本怎搭配選擇的?

我要留言

立即登入留言