k8s集羣架構及基本操做

時間 2019-12-31

標籤 k8s 集羣架構基本欄目負載均衡简体版

原文原文鏈接

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

kubernetes是由什麼組成的？

在硬件級別，一個kubernetes集羣由不少節點組成，這些節點被分紅如下兩種類型：node

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

控制面板（master）

控制面板用於控制集羣並使它工做。它包含多個組件，組件能夠運行在單個主節點上或者經過副本分別部署在多個主節點以確保高可用性。nginx

master中的組件有：web

注意：master節點默認不參加工做，若是有須要咱們能夠將它設置爲參加工做，可是通常不建議這麼作，由於master節點用於負責控制並管理集羣，因此很是重要，通常保持默認讓它不參加工做便可。docker

APIserver：apiserver是k8s集羣中的前端接口，各類客戶端工具以及k8s其餘組件能夠經過它管理集羣中的各類資源。vim
Scheduler：負責決定將pod放在那哪一個node刪運行。在調度的過程當中，會考慮集羣的節點狀態，當前各個節點的負載情況，以及對應調度高可用，性能等需求。後端
Controller manager：負責管理k8s集羣的各類資源。保證資源處於用戶指望的狀態。api
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的信息：

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

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