k8s集羣架構及基本操作

首先在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規則來做到負載均衡。

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

k8s基本操作

k8s中各個組件的yaml文件存放位置：

kubernetes默認的名稱空間有以下四個：

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

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

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

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

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

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

以上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

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

//外網測試通過該暴露的端口來訪問集羣web界面：
url:http://172.16.1.30:30400/



需要知道的是集羣中的任何一臺主機都是可以進行訪問的，不是隻有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 

[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：

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的地址：

//接下來通過查看iptables規則：
[root@master yaml]# iptables-save
//找到集羣ip的轉發規則：

##它會跳轉到另一個規則，我們來查看這個值：

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

//接下來我們分別通過上面它跳轉的另一個規則，來查看ip地址：



// DNAT是目標地址轉換，我們接下來查看pod的信息：

可以看到是負載均衡的分配到各個節點，這就體現了它的一個原理。

———————— 本文至此結束，感謝閱讀 ————————