k8s集群架構(gòu)及基本操作

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

kubernetes是由什么組成的？

在硬件級別，一個(gè)kubernetes集群由很多節(jié)點(diǎn)組成，這些節(jié)點(diǎn)被分成以下兩種類型：

• 主節(jié)點(diǎn)：它承載著kubernetes控制和管理整個(gè)集群系統(tǒng)的控制面板
• 工作節(jié)點(diǎn)： 它們運(yùn)行用戶實(shí)際部署的應(yīng)用。
  

  控制面板（master）

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

master中的組件有：

注意：master節(jié)點(diǎn)默認(rèn)不參加工作，如果有需要我們可以將它設(shè)置為參加工作，但是一般不建議這么做，因?yàn)閙aster節(jié)點(diǎn)用于負(fù)責(zé)控制并管理集群，所以非常重要，一般保持默認(rèn)讓它不參加工作即可。

• APIserver：apiserver是k8s集群中的前端接口，各種客戶端工具以及k8s其他組件可以通過它管理集群中的各種資源。

• Scheduler：負(fù)責(zé)決定將pod放在那哪個(gè)node刪運(yùn)行。在調(diào)度的過程中，會(huì)考慮集群的節(jié)點(diǎn)狀態(tài)，當(dāng)前各個(gè)節(jié)點(diǎn)的負(fù)載狀況，以及對應(yīng)調(diào)度高可用，性能等需求。

• Controller manager：負(fù)責(zé)管理k8s集群的各種資源。保證資源處于用戶期望的狀態(tài)。

• ectd：多數(shù)據(jù)中心，負(fù)責(zé)保存k8s集群的配置信息和各種資源的狀態(tài)信息，當(dāng)數(shù)據(jù)發(fā)生變化的時(shí)候，etcd會(huì)通知k8s集群的其他組件。

• Pod：是k8s集群里邊最小的單位。每個(gè)pod里邊運(yùn)行一個(gè)或多個(gè)container（一般只運(yùn)行一個(gè)）

Node節(jié)點(diǎn)組件有：

• kubelet：是Node節(jié)點(diǎn)的代理，當(dāng)Schedule確定某一個(gè)node上運(yùn)行pod之后，會(huì)將pod的 具體配置信息（image，volume）等發(fā)送給該節(jié)點(diǎn)的kubelet，kubelet根據(jù)這些信息創(chuàng)建和運(yùn)行容器，并向master報(bào)告運(yùn)行狀態(tài)。
  自動(dòng)修復(fù)功能： 如果某個(gè)節(jié)點(diǎn)中的容器宕機(jī)，它會(huì)自動(dòng)殺死掉，然后重新創(chuàng)建一個(gè)容器。

• kube-Proxy（負(fù)載均衡）：service在邏輯上代表了后端的多個(gè)pod，外界通過service訪問pod。
  service接收到的請求是如何轉(zhuǎn)發(fā)到pod上？這就是kube-proxy要完成的工作。通過iptables規(guī)則來做到負(fù)載均衡。

各組件之間是怎樣交互的呢？：
首先用戶通過kubectl發(fā)送部署命令，傳到集群中APIserver，APIserver得到指令后，通知Controller Manager創(chuàng)建一個(gè)deployment的資源對象，得到確認(rèn)后，又將指令傳給APIserver，APIserver會(huì)與etcd進(jìn)行溝通，etcd會(huì)調(diào)取集群中的各種資源信息，接下來由Schedule來執(zhí)行調(diào)度，決定將pod分配給集群中的哪個(gè)節(jié)點(diǎn)來運(yùn)行。最后kubelet會(huì)根據(jù)要求在各自節(jié)點(diǎn)上創(chuàng)建并運(yùn)行pod。

k8s基本操作

k8s中各個(gè)組件的yaml文件存放位置：

kubernetes默認(rèn)的名稱空間有以下四個(gè)：

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

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

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

參數(shù)解釋：
-o wide: 加上該參數(shù)，顯示的內(nèi)容更寬泛一點(diǎn)
READY：表示所達(dá)到的期望值，2/2 表示有2個(gè)可用。
AVAILABLE：表示為可用的數(shù)

它會(huì)自動(dòng)的去下載鏡像（nginx鏡像），也可以提前將鏡像上傳到服務(wù)器上，從本地進(jìn)行下載。

//查看pod運(yùn)行到哪個(gè)節(jié)點(diǎn)之上：（包括顯示pod的ip地址）
[root@master ~]# kubectl get pod -o wide

以上pod分配的ip地址是在我們初始化集群時(shí)，指定官方提供的pod網(wǎng)絡(luò)中的網(wǎng)段。

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

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

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

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

#其實(shí)上面就相當(dāng)于是創(chuàng)建了個(gè)service。

//查看service映射出來的資源對象：
[root@master ~]# kubectl get service

解釋：
CLUSTER-IP：統(tǒng)一的一個(gè)集群接口，為集群內(nèi)部通信的地址。
80:32326/TCP：80為服務(wù)端口，后面的端口是暴露給外網(wǎng)的（隨機(jī)生成，范圍是30000-32767）

//外網(wǎng)測試通過該暴露的端口來訪問集群web界面：
url:http://172.16.1.30:30400/



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

3）手動(dòng)刪除節(jié)點(diǎn)上的容器，然后再次查看Deployment資源對象，查看Pod是否維持在用戶所期望的數(shù)量？IP地址是否有變化？

[root@master ~]# kubectl  get pod -o wide  #查看pod分配的節(jié)點(diǎn)
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 

[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還是維持在我們所期望的數(shù)量，并且pod的ip地址也是沒有變化的，你會(huì)發(fā)現(xiàn)當(dāng)你刪除節(jié)點(diǎn)上的容器時(shí)，它會(huì)馬上自動(dòng)生成一個(gè)新的pod。這是為什么呢？
其實(shí)是通過集群中controller manager組件來保證資源處于用戶所期望的狀態(tài)，就是說當(dāng)你定義副本時(shí)，你定義了2個(gè)，它會(huì)保證你一直運(yùn)行著2個(gè)pod，如果少了，會(huì)進(jìn)行增加。

kube-proxy實(shí)現(xiàn)負(fù)載均衡的底層原理

1）首先我們創(chuàng)建一個(gè)deployment+service的資源對象，定義副本數(shù)量3個(gè)

[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

//執(zhí)行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：

2）分別進(jìn)入pod修改每個(gè)pod的默認(rèn)訪問界面（確保界面不同）。。。。。。。

3）訪問界面，驗(yàn)證是否會(huì)有輪詢效果：

[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

可以看到訪問頁面是會(huì)有輪詢效果的，雖然靠的是kube-proxy組件來實(shí)現(xiàn)負(fù)載均衡的底層原理的，但主要通過iptables規(guī)則來實(shí)現(xiàn)負(fù)載均衡的。
詳細(xì)過程如下：

//首先我們查看一下Cluster ip的地址：

//接下來通過查看iptables規(guī)則：
[root@master yaml]# iptables-save
//找到集群ip的轉(zhuǎn)發(fā)規(guī)則：

##它會(huì)跳轉(zhuǎn)到另一個(gè)規(guī)則，我們來查看這個(gè)值：

以上的值是它實(shí)現(xiàn)負(fù)載均衡隨機(jī)算出的平均值，我們前面有3個(gè)副本，第一次是1/3的概率（%0.3），分配完，第二次和第三次就是1/2的概率了（%0.5）。第三次就沒有詳細(xì)的顯示出它的一個(gè)概率了，但我們知道它的概率也是%0.5。

//接下來我們分別通過上面它跳轉(zhuǎn)的另一個(gè)規(guī)則，來查看ip地址：



// DNAT是目標(biāo)地址轉(zhuǎn)換，我們接下來查看pod的信息：

可以看到是負(fù)載均衡的分配到各個(gè)節(jié)點(diǎn)，這就體現(xiàn)了它的一個(gè)原理。

———————— 本文至此結(jié)束，感謝閱讀 ————————