Kubernetes入門培訓（內含PPT）

"本文主要從docker、docker-compose由淺到深介紹了Kubernetes核心功能，關注回覆【ppt】獲得演示文稿"

1、Docker

Docker是基於操作系統的沙盒技術，使得用戶更簡單和完整的去打包自己的應用。

爲了說明docker底層實現，現在介紹下面幾個概念。

docker底層是基於linux的操作系統級別的虛擬化技術LXC實現；

LXC是通過CGroup實現了虛擬化資源管理，用來保證應用資源的隔離和應用系統資源的限制；

服務器運行了多個服務，這些服務之間是可以互相影響的，其中的一個服務可以查看另外一個服務，這些是我們不願意看到的，我們更希望同一臺機器運行的服務能夠完全隔離，互不影響就像運行在多臺機器上一樣。而linux爲我們提供了NameSpaces爲我們提供了分離進程樹、網絡接口、資源掛載點的方法，docker正是利用了linux的NameSpaces技術實現了不同容器間資源的隔離；

如果我們進入docker命令進入容器內部會發現只能看到當前容器的目錄而不能看到原系統的目錄，而linux的chroot又稱（change root）具有改變當前系統的根目錄功能。docker正是利用chroot的功能而實現了容器內部目錄與原系統目錄隔離的效果。

通過NameSpaces文件系統、網絡並與宿主機器之間的進程相互隔離，CGroup實現了CPU、內存等物理資源的隔離，docker鏡像本質上是一個基於linux底層文件系統的壓縮包，雖然Docker是最近幾年流行起來即使，但是 Docker 的核心技術其實已經有很多年的歷史了，Linux Namespaces、CGroup和 UnionFS 三大技術支撐了目前 Docker 的實現，也是 Docker 能夠出現的最重要原因。

具體使用可借鑑：如何使用docker？

2、docker-compose

Docker-compose是一個單節點編排技術。

如果把docker比喻成一堆雜亂無章的集裝箱，而compose能夠對這些集裝箱整理歸類，作爲一個整體啓動運行，docker-compose是以docker爲核心進行構建的，本身只支持單節點編排，在複雜多變的生產環境是無法投入使用的。

具體使用可借鑑：起飛的感覺，docker-compose

3、Kubernetes

工業級的編排平臺主要提供服務的部署、彈性和管理；

Kubernetes是希臘語，翻譯中文是“舵手、飛行員”的意思。

k8s，省略中間8個ubernete替換爲8，而得來k8s。

如果說docke把應用打包成鏡像，那麼Kubernetes保證容器化應用簡單高效運行。他跟docker-swarm、moby項目不同，它不在以docker爲核心，而是把docker作爲一個運行時組件，更多是提供應用部署，規劃，更新，維護，在複雜多變的生產環境中，這些往往是我們更加需要的。

3.1、Kubernetes核心功能

1 服務發現和負載均衡；

主要通過Service資源對象其底層是基於iptables實現。

2 服務自動裝箱；

主要是通過調度組件Scheduler實現，它能夠自動給幫助我們把容器調度到某幾臺機器上自動啓動運行。

3 容器存儲編排；

Kubernetes有跟compose類似的編排yml文件，讓存儲的生命週期和容器的生命週期有一個鏈接。

4 容器故障恢復；

在集羣環境中經常會因爲系統原因、以及宿主機問題導致容器不可用，Kubernetes會幫助我們把不可用的容器進行恢復或者轉移到正常節點上面去。

5 自動發佈和回滾；

Kubernetes能夠對我們的應用進行自動的發佈和回滾，並且根據不同應用場景提供了不同發佈和回滾策略。

6 配置和密鑰存儲；

Kubernetes提供了ConfigMap解決了集羣環境中配置文件的存儲問題，其底層是基於數據卷實現，原應用不用修改任何代碼即可無縫對接。

7 服務水平伸縮；

Kubernetes爲了讓集羣更具有彈性提供了水平伸縮功能，如果線上有某種大流量活動，我們可以直接水平擴展應用部署應用的數量，當活動結束後，再減少應用部署的數量，從而高效應對高併發場景。

8 批量執行以及守護進程任務；

Kubernentes可以對Job類型的任務，進行批量的執行，比如數據同步、備份等；如果我們想要集羣環境中每個節點都運行一份守護進程進行節點任務執行，我們可以使用Kubernetes DeamonSet資源類型進行任務執行。

9 探針。

Kubernetes主要提供了存活和就緒兩種探針，支持http、tcp、socket或者腳本的形式進行檢測服務是否正常，對原有服務架構沒有任何侵入性。

3.2、圖文演示Kubernetes部分特性

Kubernetes的調度器Scheduler可以把用戶提交的容器，根據其規格大小調度到其中的一個節點上。如下動圖所示：

Kubernetes平臺有健康檢查的功能，當集羣中的某個節點或者應用出現故障時，能夠自動轉移到健康節點上。如下動圖所示：

Kubernetes具備HPA自動擴容的能力，目前只支持按照CPU指標和用戶自定義（比如TPS或QPS）達到某個數量級觸發自動擴容，當請求高峯過去之後，pod可以恢復到原來的水平。如下圖所示檢測到白色節點負載過高，自動把服務複製兩份，分發到其它節點運行：

3.3、架構介紹

Kubernetes基於兩層架構設計，主要包含主節點master和計算節點node，master包含web UI界面和cli命令行，支持多個master高可用部署，master主要下發命令到node，node主要用於容器任務執行。

master

master主要包含 APIServer、Scheduler、Controller、Etcd等組件。

API Server提供了資源的增、刪、改、查等操作的唯一入口，並提供認證、授權、訪問控制、API註冊和發現等機制，集羣內部組件與組件之間不能直接調用，調用過程都要經過ApiServer，其中Apiserver支持高可用配置。

Scheduler負責資源的調度策略，能夠按照預設的策略把pod調度到相應的節點上，支持熱備。

Controller負責維護集羣的狀態，資源對象的自動化控制中心，比如故障檢測、自動擴展、滾動更新、服務帳戶和令牌控制器等功能都是由Kubernetes Controller完成，支持熱備。

etcd主要功能保存整個集羣的狀態；etcd本身是一個獨立與Kubernetes集羣之外的分佈式存儲系統。支持高可用配置。

node

Kubernetes的業務是在node上運行，而業務都是以最小單元pod進行運行的，而pod中可以運行一個或者多個容器，pod本身在kubelet組件上運行，它通過跟apiserver進行交互獲得pod的狀態。

node主要包含Kubelet、kube-proxy、Container Runtime、存儲插件、網路插件等。

kubelet主要負責pod的創建、啓動停止等任務，與master節點密切交互完成集羣管理和運行的基本功能。

kube-proxy 主要用於通過Service提供集羣內部的服務發現和負載均衡。

Container Runtime主要負責鏡像管理以及pod內容器運行環境配置。

Kubernetes提供了多種資源對象，可以根據需求選擇使用，如下表所示：

資源對象	Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling
配置對象	Node、Namespace、Service、Secret、ConfigMap、Ingress、Label、ThirdPartyResource、 ServiceAccount
存儲對象	Volume、Persistent Volume及三方插件（NFS、ceph、gfs）
策略對象	SecurityContext、ResourceQuota、LimitRange

3.4、圖文說明pod在Kubernetes集羣平臺執行過程

用戶可以通過命令行提交一個pod到API Server，API Server把pod當前信息存儲到etcd數據庫中，Scheduler調度器根據pod規格資源配置調度某個節點上，通知API Server把調度的節點信息和pod存儲到etcd中，API Server會通知相應節點的kubelet執行啓動，kubelet首先調用Container RunTime配置容器以及運行環境，然後調度存儲插件配置存儲，網絡插件配置網絡，從而完成容器的運行。

3.5、核心概念介紹

最小調度以及資源單位，這裏我們思考下爲什麼pod是最小調度單位？這裏我們舉個例子：我們有個多進程應用（比如rsyslog就是多進程應用），其中包含三個進程p1，p2，p3，這三個進程必須運行在一臺機器上，每個進程需要佔用0.5GB內存，現在我們有三臺機器，node1（2G）node2（1G）node3（1G）；假設pod不是最小調度單位，p1調度到node2上，這完全是有可能的，因爲node2資源足夠p1使用，緊接着p2也被調度到node2上，那麼問題來了p3呢？當然我們可以通過加鎖的方式解決，但是如何加鎖呢，都是問題，但是Kubernetes通過把pod作爲最小調度單位從而解決了此問題；
包含一個或者多個容器，如果說我們服務之間存在大量rpc調用，這時我們可以把應用放在一個pod中運行，共享同一個網絡環境，直接本地調用，而pod和pod之間是網絡隔離，可以通過Service訪問；
定義容器運行時方式（命令和環境變量）；
提供給容器共享的運行環境（網絡和進程空間）。

Deployment

定義pod副本數量、版本等；
通過ReplicaSet控制pod數量（自動重啓失敗的pod）；
按照指定策略控制版本（版本升級、回滾、重新生成）；

deployment是一個控制器，能夠用來控制pod數量跟期望數量一致，配置pod的發佈方式，Deployment會按照給定策略進行發佈pod，保證在更新過程中不可用數量在限定範圍內。看了上面的介紹感覺像是Deployment直接控制pod，其實不然，Deployment控制ReplicateSet　ReplicateSet控制pod副本的數量，pod所屬於replicaset，同一個replicaset下的pod版本都是一樣的。

Volume

Pod中一個或者多個容器可以訪問的目錄
支持多種存儲的抽象本地存儲、分佈式存儲、雲存儲

在docker中volume就是對應磁盤或者其它容器中的目錄，docker對它的管理比較鬆散，沒有生命週期管理，而Kubernetes中的volume的生命週期和pod的生命週期相同。相比與pod中的容器來說，存儲數據可能比容器生命週期更長，並且在容器重新啓動後保留存儲信息。在Kubernetes支持多種類型的卷，而Pod可以同時使用各種類型和任意數量的存儲卷。

Service

提供訪問多個pod的穩定訪問方式（IP、域名、環境變量）。

說到Service不得不介紹kubernetes網絡模型和通信方式

網絡模型
一個完整的Kubernetes集羣應該包含三層網絡，首先第一層是mater和node節點之間的網絡，這個網絡需要在部署kubernetes集羣之前配置完成
第二層網絡是pod的網絡通過kubenet或者cni插件實現，用於pod之間或者內部的通信，集羣中的所有pod均處在同一個網絡平面空間內，可以直接通信。
第三層網絡是Service資源的網絡，是一個虛擬網絡，用於爲Kubernetes集羣配置IP地址，但此地址並不配置於任何主機或者容器的網絡接口之上，而是通過kubeproxy配置爲iptables規則，將發往該地址的所有流量調度至後端的pod之上。
通信方式
同一個pod的內部通信；
各個pod彼此通信；
pod和service的通信；
集羣外部流向service的通信。
端口介紹

containerPort：一個信息性數據，只是爲集羣提供一個可以快速瞭解相關 pod可以訪問端口的途徑，而且顯式指定容器端口，無論你是否指定都不影響其他節點上的客戶端pod對其進行訪問；

port：服務提供端口，用於kubernetes集羣內部服務訪問；

targetPort：pod目標端口，如果不設置使用默認port端口，port和 nodePort的數據通過這個端口進入到Pod內部，Pod裏面的container的端口映射到這個端口，提供服務；

nodePort：外部用戶訪問端口。

3.6、API基礎知識

通過命令行提交一個pod到時候，其提交的內容是yml，yml是一種特殊資源配置文件，主要包含apiversion、kind、metadata、spec幾部分組成。

apiVersion 描述當前操作的資源對象。

kind：資源類型，比如Pod、Department等

metadata就是寫上當前pod的名稱，比如nginx。剛剛介紹的 Deployment，它可能是代表一組的 Pod，它是一組 Pod 的抽象，一組 Pod 就是通過 label selector 來表達的，Service通過選擇一組pod統一進行訪問。

spec描述了pod預期達到狀態，比如內部需要哪些container運行，需要哪些鏡像，暴露什麼端口等等信息，需要在這裏定義。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2 # tells deployment to run 2 pods matching the template 
  template: # create pods using pod definition in this template 
    metadata:
     # unlike pod-nginx.yaml, the name is not included in the meta data as a unique name is 
     #       # generated from the deployment name  
     labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: docker.hub.com/ops/openresty:1.15.8.2-6
        ports:
        - containerPort: 80

3.7、操作演示

1 查看集羣當前狀態

[root@k8s-master ~]# kubectl get node
NAME         STATUS   ROLES    AGE   VERSION
k8s-master   Ready    master   161d   v1.14.2
k8s-node1    Ready    <none>   161d   v1.14.2
k8s-node2    Ready    <none>   29d   v1.14.2

2 查看deployments資源

[root@k8s-master src]# kubectl get deployments
No resources found.

3 執行

[root@k8s-master src]# kubectl apply -f nginx_deploy.yaml 
deployment.apps/nginx-deployment created

4 查看執行狀態，可以發現容器已經按照期望執行

[root@k8s-master src]# kubectl get deployments
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           28s
[root@k8s-master src]# kubectl describe deployment nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Sun, 02 Feb 2020 09:55:48 +0800
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 1
                        kubectl.kubernetes.io/last-applied-configuration:
                          {"apiVersion":"apps/v1beta1","kind":"Deployment","metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},"spec":{"re...
Selector:               app=nginx
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        docker.hub.com/ops/openresty:1.15.8.2-6
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-66db8ddc49 (2/2 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  58s   deployment-controller  Scaled up replica set nginx-deployment-66db8ddc49 to 2

4 修改nginx_deploy.yaml文件，把副本數量修改爲4

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 4 # tells deployment to run 2 pods matching the template 
  template: # create pods using pod definition in this template 
    metadata:
     # unlike pod-nginx.yaml, the name is not included in the meta data as a unique name is 
     #       # generated from the deployment name  
     labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: docker.hub.com/ops/openresty:1.15.8.2-6
        ports:
        - containerPort: 80

5 擴容 nginx deployment，發現副本數量已經從2變成4個

[root@k8s-master src]# kubectl apply -f nginx_deploy.yaml 
deployment.apps/nginx-deployment configured
[root@k8s-master src]# kubectl describe deployment nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Sun, 02 Feb 2020 09:55:48 +0800
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 1
                        kubectl.kubernetes.io/last-applied-configuration:
                          {"apiVersion":"apps/v1beta1","kind":"Deployment","metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},"spec":{"re...
Selector:               app=nginx
Replicas:               4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        docker.hub.com/ops/openresty:1.15.8.2-6
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-66db8ddc49 (4/4 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  9m15s  deployment-controller  Scaled up replica set nginx-deployment-66db8ddc49 to 2
  Normal  ScalingReplicaSet  8s     deployment-controller  Scaled up replica set nginx-deployment-66db8ddc49 to 4

如上所述主要演示了deployment對象的啓動和擴容過程，當然我們也可以執行升級，回退等操作。

參考 https://k8s.io/examples/application/deployment-update.yaml

4、總結

本文主要介紹了從docker到Kubernetes編排平臺的演進過程，然後介紹了Kubenetes自身架構以及核心概念，最後演示了應用的部署和擴容。關注回覆【ppt】可獲得演示文稿。

Kubernetes入門培訓（內含PPT）

K8S集羣模式下fluent-bit日誌收集方案設計和實踐

輕量級日誌收集轉發 | fluent-bit指令詳解（一）

輕量級日誌收集轉發 | fluent-bit配置詳解（二）

面對海量日誌，爲什麼選用fluentd作爲核心組件？

輕量級日誌收集轉發 | fluent-bit外部插件詳解（三）

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結