?

1.1 Master和Node?

Master

K8S集群中的控制節點，負責整個集群的管理和控制，可以做成高可用，防止一臺Master不可用。 其中有一些關鍵的組件：API Server，Controller Manager，Scheduler等

Node

Node會被Master分配一些工作，當某個Node不可用時，會將工作負載轉移到其他Node節點上。
Node上有一些關鍵的進程：kubelet，kube-proxy，docker

1.2 kubeadm?

1.2.1kubeadm init

?

過程分析:

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

2.生成kubernetes對外提供服務所需要的各種證書可對應目錄，也就是生成私鑰和數字證書 ? ?
/etc/kubernetes/pki/* 下

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

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

?

#集群的節點有了$HOME/.kube/config就可以使用kubectl和K8s集群打交道了,這個文件就是來自于上面的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節點初始化后執行的這些步驟就是為了讓master節點可以通過kubectl和k8s集群交互 其他節點如果想要通過kubectl和k8s交互,也需要這個文件

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

?4.為master生成靜態Pod配置文件，這些組件會被master節點上的kubelet監聽到，并且創建對應資源
/etc/kubernetes/manifests/目錄下?

5.為集群生成一個bootstrap token，設定當前node為master，master節點將不承擔工作負載

6.將ca.crt等 Master節點的重要信息，通過ConfigMap的方式保存在etcd中，供后續部署node節點使用

7.安裝默認插件，kubernetes默認安裝kube-proxy和CoreDNS插件，dns插件安裝會出于pending狀態，需要等網絡插件安裝完成，比如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? 用于驗證master身份? ?
3.token用于master驗證node? ??

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

[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,我們還可以通過命令獲取到當前在使用的token

#在master上節點上，我們可以查看對應的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 #對token的值進行解碼 echo NHRzZHp0Y2RidDRmd2U5dw==|base64 -d ? ?---> ee4vjcbjmgfcs3zq #最終token的值 和我們在上面生成的Token值一致 855f8b.ee4vjcbjmgfcs3zq

1.3核心組件

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

1.4 API Server

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

APIServer提供了K8S各類資源對象的操作，是集群內各個功能模塊之間數據交互和通信的中心樞紐，是整個系統的數據總線和數據中心。通常我們通過kubectl與APIServer進行交互。?
APIServer通過kube-apiserver的進程提供服務，運行在master節點上

我們平時一般通過kubectl來和apiserver進行交互，但其底層kubectl與APIServer之間是通過REST API進行調用的

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.?

默認情況，Kubernetes API Server提供兩個端口：

1.本地端口

• 該端口用于接收HTTP請求；
• 該端口默認值為8080，可以通過API Server的啟動參數“--insecure-port”的值來修改默認值；
• 默認的IP地址為“localhost”，可以通過啟動參數“--insecure-bind-address”的值來修改該IP地址；
• 非認證或授權的HTTP請求通過該端口訪問API Server。

2.Secure Port

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

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

#訪問端口測試后發現，結果和使用kubectl執行命令一樣 [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創建資源等都需要權限校驗，需要完成認證，授權，準入等驗證后才可以操作資源，具體流程如下

1.4.2?API Server認證(Authentication)

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

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

認證的第一個維度

• HTTPS證書認證? ?基于CA根證書簽名的雙向數字證書認證方式
• HTTP Token認證? 通過一個Token來識別合法用戶
• HTTP Base認證? ?通過用戶名+密碼的方式認證

認證的第二個維度

系統組件想要和apiserver進行認證，一般使用ServiceAccount

創建ServiceAccount一般會創建一個secret,這個secret會被自動加入到創建的Pod中(如果該Pod沒有創建ServiceAccount,會使用集群默認的ServceAccount)

1.4.3?API Server授權(Authorization)

Authorization verifies what you are authorized to do.

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

• Webhook：基于HTTP回調機制通過外部REST服務檢查確認用戶授權的訪問控制
• ABAC：基于屬性的訪問控制，表示基于配置的授權規則去匹配用戶請求，判斷是否有權限。Beta 版本
• RBAC：基于角色的訪問控制，允許管理員通過 api 動態配置授權策略。Beta 版本

常用的是基于RBAC授權模式，之前很多yaml都是基于該方式進行授權

使用Role,RoleBinding ; ClusterRole,ClusterRoleBinding 資源來實現RBAC權限控制
二者之間的區別在于ClusterRole定義的是和整個集群交互的權限

1.4.4?Admission Control(準入控制)?

通過了前面的認證和授權之后，還需要經過準入控制處理,通過之后apiserver 才會處理這個請求。相當于最后的一組攔截器

常用的準入控制器主要有：

• AlwaysAdmit：允許所有請求
• AlwaysDeny：拒絕所有請求
• AlwaysPullImages：在啟動容器之前總是去下載鏡像
• 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.?

通過調度算法，為待調度Pod列表的每個Pod，從Node列表中選擇一個最合適的Node。 然后，目標節點上的kubelet通過API Server監聽到Kubernetes Scheduler產生的Pod綁定事件，獲取對應的 Pod清單，下載Image鏡像，并啟動容器。

架構圖如下:

（1）預選調度策略：遍歷所有目標Node，刷選出符合Pod要求的候選節點
（2）優選調度策略：在(1)的基礎上，采用優選策略算法計算出每個候選節點的積分，積分最高者勝出
? ?簡單來說就是先找到可用的，再找到最好的?

1.5.1預選策略

• 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 優選策略?

• 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.

......

?

總結

以上是生活随笔為你收集整理的kubernetes(六)k8s核心组件学习的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。