當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

kubernetes(六)k8s核心组件学习

發(fā)布時(shí)間：2024/4/11 编程问答 49 豆豆

生活随笔收集整理的這篇文章主要介紹了 kubernetes(六)k8s核心组件学习小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

?

1.1 Master和Node?

Master

K8S集群中的控制節(jié)點(diǎn)，負(fù)責(zé)整個(gè)集群的管理和控制，可以做成高可用，防止一臺(tái)Master不可用。其中有一些關(guān)鍵的組件：API Server，Controller Manager，Scheduler等

Node

Node會(huì)被Master分配一些工作，當(dāng)某個(gè)Node不可用時(shí)，會(huì)將工作負(fù)載轉(zhuǎn)移到其他Node節(jié)點(diǎn)上。
Node上有一些關(guān)鍵的進(jìn)程：kubelet，kube-proxy，docker

1.2 kubeadm?

1.2.1kubeadm init

過程分析:

1.進(jìn)行一系列檢查[init之前的檢查]，以確定這臺(tái)機(jī)器可以部署kubernetes
? pre-flight check: ? ? ?
??(1)kubeadm版本與要安裝的kubernetes版本的檢查 ? ? ?
??(2)kubernetes安裝的系統(tǒng)需求檢查[centos版本、cgroup、docker等] ? ? ? ?
??(3)用戶、主機(jī)、端口、swap等
? (4)拉取創(chuàng)建集群需要的鏡像--這個(gè)在搭建之前就提前拉取了

2.生成kubernetes對(duì)外提供服務(wù)所需要的各種證書可對(duì)應(yīng)目錄，也就是生成私鑰和數(shù)字證書 ? ?
/etc/kubernetes/pki/* 下

? ? ??
(1)自建ca，生成ca.key和ca.crt ? ? ? ?
(2)apiserver的私鑰與公鑰證書 ?? ? ? ?
(3)apiserver訪問kubelet使用的客戶端私鑰與證書 ? ? ? ?
(4)sa.key和sa.pub ? ? ? ?
(5)etcd相關(guān)私鑰和數(shù)字證書

3.為其他組件生成訪問kube-ApiServer所需的配置文件xxx.conf (/etc/kubernetes下)

#集群的節(jié)點(diǎn)有了$HOME/.kube/config就可以使用kubectl和K8s集群打交道了,這個(gè)文件就是來自于上面的admin.config mkdir -p $HOME/.kube ???? sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config ????? sudo chown $(id -u):$(id -g) $HOME/.kube/configmaster節(jié)點(diǎn)初始化后執(zhí)行的這些步驟就是為了讓master節(jié)點(diǎn)可以通過kubectl和k8s集群交互其他節(jié)點(diǎn)如果想要通過kubectl和k8s交互,也需要這個(gè)文件

將master的admin.conf文件上傳到想通過Kubectl命令和k8s交互的worker節(jié)點(diǎn)
同樣保存到$HOME/.kube/config目錄下并授權(quán)即可

?4.為master生成靜態(tài)Pod配置文件，這些組件會(huì)被master節(jié)點(diǎn)上的kubelet監(jiān)聽到，并且創(chuàng)建對(duì)應(yīng)資源
/etc/kubernetes/manifests/目錄下?

5.為集群生成一個(gè)bootstrap token，設(shè)定當(dāng)前node為master，master節(jié)點(diǎn)將不承擔(dān)工作負(fù)載

6.將ca.crt等 Master節(jié)點(diǎn)的重要信息，通過ConfigMap的方式保存在etcd中，供后續(xù)部署node節(jié)點(diǎn)使用

7.安裝默認(rèn)插件，kubernetes默認(rèn)安裝kube-proxy和CoreDNS插件，dns插件安裝會(huì)出于pending狀態(tài)，需要等網(wǎng)絡(luò)插件安裝完成，比如calico?

1.2.2 join ??

kubeadm join 192.168.56.51:6443 --token 36j96r.o6pj47eh4rir3y2m \
? ? --discovery-token-ca-cert-hash sha256:37e61162ccc36c63c38bb8c7619331898d12bbad51aba766bdf6eeaf5111eb62

1.join前檢查
2.discovery-token-ca-cert-hash? 用于驗(yàn)證master身份? ?
3.token用于master驗(yàn)證node? ??

如果沒有及時(shí)保存最后的join信息，或者24小時(shí)之后過期了，這時(shí)候可以重新生成

[root@m ~]# kubeadm token create 855f8b.ee4vjcbjmgfcs3zq [root@m ~]# openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //' 37e61162ccc36c63c38bb8c7619331898d12bbad51aba766bdf6eeaf5111eb62#最后得到的新的join命令是這樣的,token更新，但是sha不變 kubeadm join 192.168.56.51:6443 --token 855f8b.ee4vjcbjmgfcs3zq \--discovery-token-ca-cert-hash sha256:37e61162ccc36c63c38bb8c7619331898d12bbad51aba766bdf6eeaf5111eb62

除了重新生成token,我們還可以通過命令獲取到當(dāng)前在使用的token

#在master上節(jié)點(diǎn)上，我們可以查看對(duì)應(yīng)的token的值 kubectl get secret -n kube-system | grep bootstrap-token bootstrap-token-855f8b bootstrap.kubernetes.io/token 6 3m36s #得到token的值 kubectl get secret/bootstrap-token-855f8b -n kube-system -o yaml #對(duì)token的值進(jìn)行解碼 echo NHRzZHp0Y2RidDRmd2U5dw==|base64 -d ? ?---> ee4vjcbjmgfcs3zq #最終token的值和我們?cè)谏厦嫔傻腡oken值一致 855f8b.ee4vjcbjmgfcs3zq

1.3核心組件

簡單說下k8s的核心組件：
1.kubectl
操作集群的客戶端，主要任務(wù)就是和集群打交道
2.kube-apiserver
整個(gè)集群的中樞紐帶，安全和權(quán)限校驗(yàn)也由它負(fù)責(zé)
3.kube-scheduler
單純地調(diào)度pod，按照特定的調(diào)度算法和策略，將待調(diào)度Pod綁定到集群中某個(gè)適合的Node，并寫入綁定信息，由對(duì)應(yīng)節(jié)點(diǎn)的kubelet服務(wù)創(chuàng)建pod
4.kube-controller-manager
負(fù)責(zé)集群中Node、Pod副本、服務(wù)的endpoint、命名空間、Service Account、資源配合等管理會(huì)劃分成不同類型的controller，每個(gè)controller都是一個(gè)死循環(huán)，在循環(huán)中controller通過apiserver監(jiān)視自己控制資源的狀態(tài)，一旦狀態(tài)發(fā)生變化就會(huì)努力改變狀態(tài)，直到變成期望狀態(tài)(對(duì)于一個(gè)多副本RS,停止一個(gè)pod之后會(huì)創(chuàng)建新的pod就是由controller manager管理控制的)
5.kubelet
集群中的每個(gè)節(jié)點(diǎn)上都會(huì)啟動(dòng)一個(gè)kubelet服務(wù)進(jìn)程，用于處理master節(jié)點(diǎn)下發(fā)到本節(jié)點(diǎn)的任務(wù)，管理pod和container。每個(gè)kubelet會(huì)向apiserver注冊(cè)本節(jié)點(diǎn)的信息，并向master節(jié)點(diǎn)上報(bào)本節(jié)點(diǎn)資源使用的情況
6.kube-proxy
在k8s集群中，每個(gè)Node上都會(huì)運(yùn)行一個(gè)kube-proxy(daemonset)，它是Service的透明代理兼負(fù)載均衡器，核心功能是將某個(gè)Service的訪問請(qǐng)求轉(zhuǎn)發(fā)到后端的多個(gè)Pod實(shí)例上
7.DNS
負(fù)責(zé)域名解析
8.dashboard
監(jiān)控面板，能夠監(jiān)測整個(gè)集群的狀態(tài)
9.etcd
整個(gè)集群的配置中心，所有集群的狀態(tài)數(shù)據(jù)，對(duì)象數(shù)據(jù)都存儲(chǔ)在etcd中。
kubeadm引導(dǎo)啟動(dòng)的K8s集群，默認(rèn)只啟動(dòng)一個(gè)etcd節(jié)點(diǎn)

1.4 API Server

https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-apiserver/

APIServer提供了K8S各類資源對(duì)象的操作，是集群內(nèi)各個(gè)功能模塊之間數(shù)據(jù)交互和通信的中心樞紐，是整個(gè)系統(tǒng)的數(shù)據(jù)總線和數(shù)據(jù)中心。通常我們通過kubectl與APIServer進(jìn)行交互。?
APIServer通過kube-apiserver的進(jìn)程提供服務(wù)，運(yùn)行在master節(jié)點(diǎn)上

我們平時(shí)一般通過kubectl來和apiserver進(jìn)行交互，但其底層kubectl與APIServer之間是通過REST API進(jìn)行調(diào)用的

1.4.1 REST API

The Kubernetes API server validates and configures data for the api objects which include pods, services, replicationcontrollers, and others. The API Server services REST operations and provides the frontend to the cluster’s shared state through which all other components interact.?

默認(rèn)情況，Kubernetes API Server提供兩個(gè)端口：

1.本地端口

該端口用于接收HTTP請(qǐng)求；
該端口默認(rèn)值為8080，可以通過API Server的啟動(dòng)參數(shù)“--insecure-port”的值來修改默認(rèn)值；
默認(rèn)的IP地址為“l(fā)ocalhost”，可以通過啟動(dòng)參數(shù)“--insecure-bind-address”的值來修改該IP地址；
非認(rèn)證或授權(quán)的HTTP請(qǐng)求通過該端口訪問API Server。

2.Secure Port

該端口默認(rèn)值為6443，可通過啟動(dòng)參數(shù)“--secure-port”的值來修改默認(rèn)值；
默認(rèn)IP地址為非本地（Non-Localhost）網(wǎng)絡(luò)端口，通過啟動(dòng)參數(shù)“--bind-address”設(shè)置;
該端口用于接收HTTPS請(qǐng)求；
用于基于Tocken文件或客戶端證書及HTTP Base的認(rèn)證；
用于基于策略的授權(quán)；
默認(rèn)不啟動(dòng)HTTPS安全訪問控制。

對(duì)于k8s集群的訪問操作，都是通過api server的rest api來實(shí)現(xiàn)的，就像請(qǐng)求后臺(tái)接口一樣(需要先開放api-server yaml文件里的insecure-port,將其修改成8080端口)

#訪問端口測試后發(fā)現(xiàn)，結(jié)果和使用kubectl執(zhí)行命令一樣 [root@m ~]# curl localhost:8080 [root@m ~]# curl localhost:8080/api [root@m ~]# curl localhost:8080/api/v1 [root@m ~]# curl localhost:8080/api/v1/pods [root@m ~]# curl localhost:8080/api/v1/pods/services

通過api-server創(chuàng)建資源等都需要權(quán)限校驗(yàn)，需要完成認(rèn)證，授權(quán)，準(zhǔn)入等驗(yàn)證后才可以操作資源，具體流程如下

1.4.2?API Server認(rèn)證(Authentication)

Authentication verifies who you are.就是如何識(shí)別客戶端的身份

K8s集群提供了多種識(shí)別客戶端身份的方式：

認(rèn)證的第一個(gè)維度

HTTPS證書認(rèn)證? ?基于CA根證書簽名的雙向數(shù)字證書認(rèn)證方式
HTTP Token認(rèn)證? 通過一個(gè)Token來識(shí)別合法用戶
HTTP Base認(rèn)證? ?通過用戶名+密碼的方式認(rèn)證

認(rèn)證的第二個(gè)維度

系統(tǒng)組件想要和apiserver進(jìn)行認(rèn)證，一般使用ServiceAccount

創(chuàng)建ServiceAccount一般會(huì)創(chuàng)建一個(gè)secret,這個(gè)secret會(huì)被自動(dòng)加入到創(chuàng)建的Pod中(如果該P(yáng)od沒有創(chuàng)建ServiceAccount,會(huì)使用集群默認(rèn)的ServceAccount)

1.4.3?API Server授權(quán)(Authorization)

Authorization verifies what you are authorized to do.

授權(quán)就是授予不同用戶不同的訪問權(quán)限，APIServer 目前支持以下幾種授權(quán)策略：

Webhook：基于HTTP回調(diào)機(jī)制通過外部REST服務(wù)檢查確認(rèn)用戶授權(quán)的訪問控制
ABAC：基于屬性的訪問控制，表示基于配置的授權(quán)規(guī)則去匹配用戶請(qǐng)求，判斷是否有權(quán)限。Beta 版本
RBAC：基于角色的訪問控制，允許管理員通過 api 動(dòng)態(tài)配置授權(quán)策略。Beta 版本

常用的是基于RBAC授權(quán)模式，之前很多yaml都是基于該方式進(jìn)行授權(quán)

使用Role,RoleBinding ; ClusterRole,ClusterRoleBinding 資源來實(shí)現(xiàn)RBAC權(quán)限控制
二者之間的區(qū)別在于ClusterRole定義的是和整個(gè)集群交互的權(quán)限

1.4.4?Admission Control(準(zhǔn)入控制)?

通過了前面的認(rèn)證和授權(quán)之后，還需要經(jīng)過準(zhǔn)入控制處理,通過之后apiserver 才會(huì)處理這個(gè)請(qǐng)求。相當(dāng)于最后的一組攔截器

常用的準(zhǔn)入控制器主要有：

AlwaysAdmit：允許所有請(qǐng)求
AlwaysDeny：拒絕所有請(qǐng)求
AlwaysPullImages：在啟動(dòng)容器之前總是去下載鏡像
ServiceAccount：將 secret 信息掛載到 pod 中，比如 service account token，registry key 等
...

1.5 Scheduler

In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that Kubelet can run them.?

通過調(diào)度算法，為待調(diào)度Pod列表的每個(gè)Pod，從Node列表中選擇一個(gè)最合適的Node。然后，目標(biāo)節(jié)點(diǎn)上的kubelet通過API Server監(jiān)聽到Kubernetes Scheduler產(chǎn)生的Pod綁定事件，獲取對(duì)應(yīng)的 Pod清單，下載Image鏡像，并啟動(dòng)容器。

架構(gòu)圖如下:

（1）預(yù)選調(diào)度策略：遍歷所有目標(biāo)Node，刷選出符合Pod要求的候選節(jié)點(diǎn)
（2）優(yōu)選調(diào)度策略：在(1)的基礎(chǔ)上，采用優(yōu)選策略算法計(jì)算出每個(gè)候選節(jié)點(diǎn)的積分，積分最高者勝出
? ?簡單來說就是先找到可用的，再找到最好的?

1.5.1預(yù)選策略

PodFitsHostPorts: Checks if a Node has free ports (the network protocol kind) for the Pod ports the Pod is requesting.
PodFitsHost: Checks if a Pod specifies a specific Node by its hostname.
PodFitsResources: Checks if the Node has free resources (eg, CPU and Memory) to meet the requirement of the Pod.

......

1.5.2 優(yōu)選策略?

SelectorSpreadPriority: Spreads Pods across hosts, considering Pods that belong to the same?Service,?StatefulSet?or?ReplicaSet.
InterPodAffinityPriority: Computes a sum by iterating through the elements of weightedPodAffinityTerm and adding “weight” to the sum if the corresponding PodAffinityTerm is satisfied for that node; the node(s) with the highest sum are the most preferred.