k8s集群架構及基本操作

發布時間：2020-06-27 20:53:26 來源：網絡閱讀：624 作者：wx5b9c94b17c62a 欄目：云計算

首先在k8s集群中要知道有兩個部署工具：
kubeadm：自動化部署k8s集群的工具。
kubectl： k8s命令行工具，用于接收用戶輸入的指令。

kubernetes是由什么組成的？

在硬件級別，一個kubernetes集群由很多節點組成，這些節點被分成以下兩種類型：

主節點：它承載著kubernetes控制和管理整個集群系統的控制面板
工作節點： 它們運行用戶實際部署的應用。

控制面板（master）

控制面板用于控制集群并使它工作。它包含多個組件，組件可以運行在單個主節點上或者通過副本分別部署在多個主節點以確保高可用性。

master中的組件有：

注意：master節點默認不參加工作，如果有需要我們可以將它設置為參加工作，但是一般不建議這么做，因為master節點用于負責控制并管理集群，所以非常重要，一般保持默認讓它不參加工作即可。

APIserver：apiserver是k8s集群中的前端接口，各種客戶端工具以及k8s其他組件可以通過它管理集群中的各種資源。
Scheduler：負責決定將pod放在那哪個node刪運行。在調度的過程中，會考慮集群的節點狀態，當前各個節點的負載狀況，以及對應調度高可用，性能等需求。
Controller manager：負責管理k8s集群的各種資源。保證資源處于用戶期望的狀態。
ectd：多數據中心，負責保存k8s集群的配置信息和各種資源的狀態信息，當數據發生變化的時候，etcd會通知k8s集群的其他組件。
Pod：是k8s集群里邊最小的單位。每個pod里邊運行一個或多個container（一般只運行一個）

Node節點組件有：

kubelet：是Node節點的代理，當Schedule確定某一個node上運行pod之后，會將pod的具體配置信息（image，volume）等發送給該節點的kubelet，kubelet根據這些信息創建和運行容器，并向master報告運行狀態。
自動修復功能：如果某個節點中的容器宕機，它會自動殺死掉，然后重新創建一個容器。
kube-Proxy（負載均衡）：service在邏輯上代表了后端的多個pod，外界通過service訪問pod。
service接收到的請求是如何轉發到pod上？這就是kube-proxy要完成的工作。通過iptables規則來做到負載均衡。

k8s集群架構及基本操作
各組件之間是怎樣交互的呢？：
首先用戶通過kubectl發送部署命令，傳到集群中APIserver，APIserver得到指令后，通知Controller Manager創建一個deployment的資源對象，得到確認后，又將指令傳給APIserver，APIserver會與etcd進行溝通，etcd會調取集群中的各種資源信息，接下來由Schedule來執行調度，決定將pod分配給集群中的哪個節點來運行。最后kubelet會根據要求在各自節點上創建并運行pod。

k8s基本操作

k8s中各個組件的yaml文件存放位置：
k8s集群架構及基本操作

kubernetes默認的名稱空間有以下四個：
k8s集群架構及基本操作

1）創建一個控制器，部署一個Deployment的資源對象
[root@master ~]# kubectl run nginx-deploy --image=nginx --port=80 --replicas=2

k8s集群架構及基本操作

參數解釋：
kubectl run：運行一個資源對象，后面跟自定義名稱
--image: 指定鏡像，也就是你要部署的服務
--port: 指定該服務的端口
--replicas：創建2個副本

//查看Deployment資源對象
[root@master ~]# kubectl  get deployments. -o wide

k8s集群架構及基本操作

參數解釋：
-o wide: 加上該參數，顯示的內容更寬泛一點
READY：表示所達到的期望值，2/2 表示有2個可用。
AVAILABLE：表示為可用的數

它會自動的去下載鏡像（nginx鏡像），也可以提前將鏡像上傳到服務器上，從本地進行下載。

//查看pod運行到哪個節點之上：（包括顯示pod的ip地址）
[root@master ~]# kubectl get pod -o wide

k8s集群架構及基本操作
以上pod分配的ip地址是在我們初始化集群時，指定官方提供的pod網絡中的網段。

一個pod中會有兩種容器（其中）：
USR，MNT，PID是相互隔離的
UTS，IPC，NET是相互共享的

2）service-暴露資源：（暴露端口給外網）
#如果外網想要訪問k8s中提供的服務，就必須創建一個service的資源對象。

[root@master ~]# kubectl expose deployment  nginx-deploy --name=myweb --port=80 --type=NodePort
service/myweb exposed

參數解釋：
expose：暴露端口
nginx-deploy：暴露名稱為nginx-deploy的資源對象
--name：自定義名稱myweb
--port：指定端口80
--type：指定類型nodeport

#其實上面就相當于是創建了個service。

//查看service映射出來的資源對象：
[root@master ~]# kubectl get service
k8s集群架構及基本操作

解釋：
CLUSTER-IP：統一的一個集群接口，為集群內部通信的地址。
80:32326/TCP：80為服務端口，后面的端口是暴露給外網的（隨機生成，范圍是30000-32767）

//外網測試通過該暴露的端口來訪問集群web界面：
url:http://172.16.1.30:30400/
k8s集群架構及基本操作

需要知道的是集群中的任何一臺主機都是可以進行訪問的，不是只有master。

3）手動刪除節點上的容器，然后再次查看Deployment資源對象，查看Pod是否維持在用戶所期望的數量？IP地址是否有變化？

[root@master ~]# kubectl  get pod -o wide  #查看pod分配的節點
NAME                            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
nginx-deploy-59f5f764bb-h7pv2   1/1     Running   0          44m   10.244.1.2   node01   <none>           <none>
nginx-deploy-59f5f764bb-x2cwj   1/1     Running   0          44m   10.244.2.2   node02   <none>           <none>

在node01上刪除容器：
[root@node01 ~]# docker ps

k8s集群架構及基本操作

[root@node01 ~]# docker rm -f 47e17e93d911

//再次查看Deployment資源對象：
[root@master ~]# kubectl  get deployments. -o wide
NAME           READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS     IMAGES   SELECTOR
nginx-deploy   2/2     2            2           48m   nginx-deploy   nginx    run=nginx-deploy

//查看pod
[root@master ~]# kubectl  get pod -o wide
NAME                            READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
nginx-deploy-59f5f764bb-h7pv2   1/1     Running   0          50m   10.244.1.2   node01   <none>           <none>
nginx-deploy-59f5f764bb-x2cwj   1/1     Running   0          50m   10.244.2.2   node02   <none>           <none>

可以看pod還是維持在我們所期望的數量，并且pod的ip地址也是沒有變化的，你會發現當你刪除節點上的容器時，它會馬上自動生成一個新的pod。這是為什么呢？
其實是通過集群中controller manager組件來保證資源處于用戶所期望的狀態，就是說當你定義副本時，你定義了2個，它會保證你一直運行著2個pod，如果少了，會進行增加。

kube-proxy實現負載均衡的底層原理

1）首先我們創建一個deployment+service的資源對象，定義副本數量3個

[root@master yaml]# vim nginx.yaml 
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: web-server
    spec:
      containers:
      - name: nginx
        image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: NodePort
  selector:
    app: web-server
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80
    nodePort: 30000

//執行yaml文件：
[root@master yaml]# kubectl apply -f  nginx.yaml 
deployment.extensions/nginx-deploy configured
service/nginx-svc created

//查看pod：
[root@master yaml]# kubectl  get pod 
NAME                            READY   STATUS    RESTARTS   AGE
nginx-deploy-56558c8dc7-gq9dt   1/1     Running   0          18s
nginx-deploy-56558c8dc7-jj5fv   1/1     Running   0          18s
nginx-deploy-56558c8dc7-z5sq4   1/1     Running   0          17s

//查看service：
k8s集群架構及基本操作
2）分別進入pod修改每個pod的默認訪問界面（確保界面不同）。。。。。。。

3）訪問界面，驗證是否會有輪詢效果：

[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No1
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No2
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No3
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No2
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No1
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No3
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No1
[root@master yaml]# curl 172.16.1.30:30000
nginx-version:No2

可以看到訪問頁面是會有輪詢效果的，雖然靠的是kube-proxy組件來實現負載均衡的底層原理的，但主要通過iptables規則來實現負載均衡的。
詳細過程如下：

//首先我們查看一下Cluster ip的地址：
k8s集群架構及基本操作

//接下來通過查看iptables規則：
[root@master yaml]# iptables-save
//找到集群ip的轉發規則：
k8s集群架構及基本操作
##它會跳轉到另一個規則，我們來查看這個值：

以上的值是它實現負載均衡隨機算出的平均值，我們前面有3個副本，第一次是1/3的概率（%0.3），分配完，第二次和第三次就是1/2的概率了（%0.5）。第三次就沒有詳細的顯示出它的一個概率了，但我們知道它的概率也是%0.5。