k8s基礎知識

k8s相關知識可以參考k8s官方指導

https://kubernetes.io/zh/docs/home/

概述

Kubernetes是一個開源的容器編排部署管理平臺，用于管理云平臺中多個主機上的容器化應用，Kubernetes的目標是讓部署容器化的應用簡單并且高效（powerful），Kubernetes提供了應用部署、規劃、更新、維護的一種機制，

Kubernetes一個核心的特點就是能夠自主地管理容器來保證云平臺中的容器按照用戶的期望狀態運行著（比如用戶想讓apache一直運行，用戶不需要關心怎么去做，Kubernetes會自動去監控，然后去重啟、新建，總之，讓apache一直提供服務，），管理員可以加載一個微型服務，讓規劃器來找到合適的位置，同時，Kubernetes也系統提升工具以及人性化方面，讓用戶能夠方便的部署自己的應用，

容器與Kubernetes

容器

容器與Docker

容器技術起源于Linux，是一種內核虛擬化技術，提供輕量級的虛擬化，以便隔離行程和資源，盡管容器技術已經出現很久，卻是隨著Docker的出現而變得廣為人知，Docker是第一個使容器能在不同機器之間移植的系統，它不僅簡化了打包應用的流程，也簡化了打包應用的庫和依賴，甚至整個作業系統的檔案系統能被打包成一個簡單的可移植的包，這個包可以被用來在任何其他運行Docker的機器上使用，

容器和虛擬機具有相似的資源隔離和分配方式，容器虛擬化了作業系統而不是硬體，更加便攜和高效，

圖1 容器 vs 虛擬機

相比于使用虛擬機，容器有如下優點：

更高效的利用系統資源
由于容器不需要進行硬體虛擬以及運行完整作業系統等額外開銷，容器對系統資源的利用率更高，無論是應用執行速度、記憶體損耗或者檔案存盤速度，都要比傳統虛擬機技術更高效，因此，相比虛擬機技術，一個相同配置的主機，往往可以運行更多數量的應用，
更快速的啟動時間
傳統的虛擬機技術啟動應用服務往往需要數分鐘，而Docker容器應用，由于直接運行于宿主內核，無需啟動完整的作業系統，因此可以做到秒級、甚至毫秒級的啟動時間，大大節約了開發、測驗、部署的時間，
一致的運行環境
開發程序中一個常見的問題是環境一致性問題，由于開發環境、測驗環境、生產環境不一致，導致有些問題并未在開發程序中被發現，而Docker的鏡像提供了除內核外完整的運行時環境，確保了應用運行環境一致性，
更輕松的遷移
由于Docker確保了執行環境的一致性，使得應用的遷移更加容易，Docker可以在很多平臺上運行，無論是物理機、虛擬機，其運行結果是一致的，因此可以很輕易的將在一個平臺上運行的應用，遷移到另一個平臺上，而不用擔心運行環境的變化導致應用無法正常運行的情況，
更輕松的維護和擴展
Docker使用的分層存盤以及鏡像的技術，使得應用重復部分的復用更為容易，也使得應用的維護更新更加簡單，基于基礎鏡像進一步擴展鏡像也變得非常簡單，此外，Docker團隊同各個開源專案團隊一起維護了大批高質量的官方鏡像，既可以直接在生產環境使用，又可以作為基礎進一步定制，大大的降低了應用服務的鏡像制作成本，

Docker容器典型使用流程

Docker容器有如下三個主要概念：

鏡像：Docker鏡像里包含了已打包的應用程式及其所依賴的環境，它包含應用程式可用的檔案系統和其他元資料，如鏡像運行時的可執行檔案路徑，
鏡像倉庫：Docker鏡像倉庫用于存放Docker鏡像，以及促進不同人和不同電腦之間共享這些鏡像，當編譯鏡像時，要么可以在編譯它的電腦上運行，要么可以先上傳鏡像到一個鏡像倉庫，然后下載到另外一臺電腦上并運行它，某些倉庫是公開的，允許所有人從中拉取鏡像，同時也有一些是私有的，區域分人和機器可接入，
容器：Docker容器通常是一個Linux容器，它基于Docker鏡像被創建，一個運行中的容器是一個運行在Docker主機上的行程，但它和主機，以及所有運行在主機上的其他行程都是隔離的，這個行程也是資源受限的，意味著它只能訪問和使用分配給它的資源（CPU、記憶體等），

典型的使用流程如圖2所示：

圖2 Docker容器典型使用流程

首先開發者在開發環境機器上開發應用并制作鏡像，
Docker執行命令，構建鏡像并存盤在機器上，
開發者發送上傳鏡像命令，
Docker收到命令后，將本地鏡像上傳到鏡像倉庫，
開發者向生產環境機器發送運行鏡像命令，
生產環境機器收到命令后，Docker會從鏡像倉庫拉取鏡像到機器上，然后基于鏡像運行容器，

Kubernetes

Kubernetes是什么

Kubernetes是一個很容易地部署和管理容器化的應用軟體系統，使用Kubernetes能夠方便對容器進行調度和編排，

對應用開發者而言，可以把Kubernetes看成一個集群作業系統，Kubernetes提供服務發現、伸縮、負載均衡、自愈甚至選舉等功能，讓開發者從基礎設施相關配置等解脫出來，

Kubernetes可以把大量的服務器看做一臺巨大的服務器，在一臺大服務器上面運行應用程式，無論Kubernetes的集群有多少臺服務器，在Kubernetes上部署應用程式的方法永遠一樣，

圖1 在Kubernetes集群上運行應用程式

Kubernetes集群架構

Kubernetes集群包含master節點和node節點，應用部署在node節點上，且可以通過配置選擇應用部署在某些特定的節點上，

Kubernetes集群的架構如下所示：

圖2 Kubernetes集群架構

Master節點

Master節點是集群的控制節點，由API Server、Scheduler、Controller Manager和ETCD四個組件構成，

API Server：各組件互相通訊的中轉站，接受外部請求，并將資訊寫到ETCD中，
Controller Manager：執行集群級功能，例如復制組件，跟蹤Node節點，處理節點故障等等，
Scheduler：負責應用調度的組件，根據各種條件（如可用的資源、節點的親和性等）將容器調度到Node上運行，
ETCD：一個分布式資料存盤組件，負責存盤集群的配置資訊，

在生產環境中，為了保障集群的高可用，通常會部署多個master，如CCE集群的高可用模式就是3個master節點，

Node節點

Node節點是集群的計算節點，即運行容器化應用的節點，

kubelet：kubelet主要負責同Container Runtime打交道，并與API Server互動，管理節點上的容器，
kube-proxy：應用組件間的訪問代理，解決節點上應用的訪問問題，
Container Runtime：容器運行時，如Docker，最主要的功能是下載鏡像和運行容器，
Kubernetes的擴展性

Kubernetes開放了容器運行時介面（CRI）、容器網路介面（CNI）和容器存盤介面（CSI），這些介面讓Kubernetes的擴展性變得最大化，而Kubernetes本身則專注于容器調度，
CRI（Container Runtime Interface）：容器運行時介面，提供計算資源，CRI隔離了各個容器引擎之間的差異，而通過統一的介面與各個容器引擎之間進行互動，
CNI（Container Network Interface）：容器網路介面，提供網路資源，通過CNI介面，Kubernetes可以支持不同網路環境，例如華為云CCE就是開發的CNI插件支持Kubernetes集群運行在華為云VPC網路中，
CSI（Container Storage Interface）：容器存盤介面，提供存盤資源，通過CSI介面，Kubernetes可以支持各種型別的存盤，例如華為云CCE就可以方便的對接華為云塊存盤（EVS）、檔案存盤（SFS）和物件存盤（OBS），

Pod
Pod是Kubernetes創建或部署的最小單位，一個Pod封裝一個或多個容器（container）、存盤資源（volume）、一個獨立的網路IP以及管理控制容器運行方式的策略選項，
Deployment
Deployment是對Pod的服務化封裝，一個Deployment可以包含一個或多個Pod，每個Pod的角色相同，所以系統會自動為Deployment的多個Pod分發請求，
StatefulSet
StatefulSet是用來管理有狀態應用的物件，和Deployment相同的是，StatefulSet管理了基于相同容器定義的一組Pod，但和Deployment不同的是，StatefulSet為它們的每個Pod維護了一個固定的ID，這些Pod是基于相同的宣告來創建的，但是不能相互替換，無論怎么調度，每個Pod都有一個永久不變的ID，
Job
Job是用來控制批處理型任務的物件，批處理業務與長期伺服業務（Deployment）的主要區別是批處理業務的運行有頭有尾，而長期伺服業務在用戶不停止的情況下永遠運行，Job管理的Pod根據用戶的設定把任務成功完成就自動退出（Pod自動洗掉），
CronJob
CronJob是基于時間控制的Job，類似于Linux系統的crontab，在指定的時間周期運行指定的任務，
DaemonSet
DaemonSet是這樣一種物件（守護行程），它在集群的每個節點上運行一個Pod，且保證只有一個Pod，這非常適合一些系統層面的應用，例如日志收集、資源監控等，這類應用需要每個節點都運行，且不需要太多實體，一個比較好的例子就是Kubernetes的kube-proxy，
Service
Service是用來解決Pod訪問問題的，Service有一個固定IP地址，Service將訪問流量轉發給Pod，而且Service可以給這些Pod做負載均衡，
Ingress
Service是基于四層TCP和UDP協議轉發的，Ingress可以基于七層的HTTP和HTTPS協議轉發，可以通過域名和路徑做到更細粒度的劃分，
ConfigMap
ConfigMap是一種用于存盤應用所需配置資訊的資源型別，用于保存配置資料的鍵值對，通過ConfigMap可以方便的做到配置解耦，使得不同環境有不同的配置，
Secret
Secret是一種加密存盤的資源物件，您可以將認證資訊、證書、私鑰等保存在Secret中，而不需要把這些敏感資料暴露到鏡像或者Pod定義中，從而更加安全和靈活，
PersistentVolume（PV）
PV指持久化資料存盤卷，主要定義的是一個持久化存盤在宿主機上的目錄，比如一個NFS的掛載目錄，
PersistentVolumeClaim（PVC）
Kubernetes提供PVC專門用于持久化存盤的申請，PVC可以讓您無需關心底層存盤資源如何創建、釋放等動作，而只需要申明您需要何種型別的存盤資源、多大的存盤空間，

kubectl

kubectl是Kubernetes集群的命令列工具，您可以將kubectl安裝在任意一臺機器上，通過kubectl命令操作Kubernetes集群

# kubectl cluster-info
Kubernetes master is running at https://*.*.*.*:5443
CoreDNS is running at https://*.*.*.*:5443/api/v1/namespaces/kube-system/services/coredns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

執行kubectl get nodes可以查看集群中的Node節點資訊，

# kubectl get nodes
NAME            STATUS    ROLES     AGE       VERSION
192.168.0.153   Ready     <none>    7m        v1.15.6-r1-20.3.0.2.B001-15.30.2
192.168.0.207   Ready     <none>    7m        v1.15.6-r1-20.3.0.2.B001-15.30.2
192.168.0.221   Ready     <none>    7m        v1.15.6-r1-20.3.0.2.B001-15.30.2

Kubernetes物件的描述

kubernetes中資源可以使用YAML描述（如果您對YAML格式不了解，可以參考YAML語法），也可以使用JSON，其內容可以分為如下四個部分：

typeMeta：物件型別的元資訊，宣告物件使用哪個API版本，哪個型別的物件，
objectMeta：物件的元資訊，包括物件名稱、使用的標簽等，
spec：物件的期望狀態，例如物件使用什么鏡像、有多少副本等，
status：物件的實際狀態，只能在物件創建后看到，創建物件時無需指定，

圖4 YAML描述檔案

Pod、Label和Namespace

Pod：Kubernetes中的最小調度物件

什么是Pod

Pod是Kubernetes創建或部署的最小單位，一個Pod封裝一個或多個容器（container）、存盤資源（volume）、一個獨立的網路IP以及管理控制容器運行方式的策略選項，

Pod使用主要分為兩種方式：

Pod定義好后就可以使用kubectl創建，如果上面YAML檔案名稱為nginx.yaml，則創建命令如下所示，-f表示使用檔案方式創建，

如果去查詢Kubernetes的資源，您會看到還有一個status欄位，status描述kubernetes資源的實際狀態，創建時不需要配置，這個示例是一個最小集，其他引數定義后面會逐步介紹，

Pod中運行一個容器，這是Kubernetes最常見的用法，您可以將Pod視為單個封裝的容器，但是Kubernetes是直接管理Pod而不是容器，
Pod中運行多個需要耦合在一起作業、需要共享資源的容器，通常這種場景下應用包含一個主容器和幾個輔助容器（SideCar Container），如圖1所示，例如主容器為一個web服務器，從一個固定目錄下對外提供檔案服務，而輔助容器周期性的從外部下載檔案存到這個固定目錄下，
圖1 Pod
實際使用中很少直接創建Pod，而是使用Kubernetes中稱為Controller的抽象層來管理Pod實體，例如Deployment和Job，Controller可以創建和管理多個Pod，提供副本管理、滾動升級和自愈能力，通常，Controller會使用Pod Template來創建相應的Pod，

創建Pod

kubernetes中資源可以使用YAML描述（如果您對YAML格式不了解，可以參考YAML語法），也可以使用JSON，如下示例描述了一個名為nginx的Pod，這個Pod中包含一個名為container-0的容器，使用nginx:alpine鏡像，使用的資源為100m core CPU、200Mi記憶體，

apiVersion: v1                      # Kubernetes的API Version
kind: Pod                           # Kubernetes的資源型別
metadata:
  name: nginx                       # Pod的名稱
spec:                               # Pod的具體規格（specification）
  containers:
  - image: nginx:alpine             # 使用的鏡像為 nginx:alpine
    name: container-0               # 容器的名稱
    resources:                      # 申請容器所需的資源
      limits:
        cpu: 100m
        memory: 200Mi
      requests:
        cpu: 100m
        memory: 200Mi
  imagePullSecrets:                 # 拉取鏡像使用的證書，在CCE上必須為default-secret
  - name: default-secret

如上面YAML的注釋，YAML描述檔案主要為如下部分：

metadata：一些名稱/標簽/namespace等資訊，
spec：Pod實際的配置資訊，包括使用什么鏡像，volume等，

存活探針（Liveness Probe）

存活探針

Kubernetes提供了自愈的能力，具體就是能感知到容器崩潰，然后能夠重啟這個容器，但是有時候例如Java程式記憶體泄漏了，程式無法正常作業，但是JVM行程卻是一直運行的，對于這種應用本身業務出了問題的情況，Kubernetes提供了Liveness Probe機制，通過檢測容器回應是否正常來決定是否重啟，這是一種很好的健康檢查機制，

毫無疑問，每個Pod最好都定義Liveness Probe，否則Kubernetes無法感知Pod是否正常運行，

Kubernetes支持如下三種探測機制，

HTTP GET：向容器發送HTTP GET請求，如果Probe收到2xx或3xx，說明容器是健康的，
TCP Socket：嘗試與容器指定埠建立TCP連接，如果連接成功建立，說明容器是健康的，
Exec：Probe執行容器中的命令并檢查命令退出的狀態碼，如果狀態碼為0則說明容器是健康的，

與存活探針對應的還有一個就緒探針（Readiness Probe），將在就緒探針（Readiness Probe）中會詳細介紹，

Label：組織Pod的利器

為什么需要Label

當資源變得非常多的時候，如何分類管理就非常重要了，Kubernetes提供了一種機制來為資源分類，那就是Label（標簽），Label非常簡單，但是卻很強大，Kubernetes中幾乎所有資源都可以用Label來組織，

Label的具體形式是key-value的標記對，可以在創建資源的時候設定，也可以在后期添加和修改，

以Pod為例，當Pod變得多起來后，就顯得雜亂且難以管理，如下圖所示，

圖1 沒有分類組織的Pod

如果我們為Pod打上不同標簽，那情況就完全不同了，如下圖所示，

圖2 使用Label組織的Pod

添加Label

Label的形式為key-value形式，使用非常簡單，如下，為Pod設定了app=nginx和env=prod兩個Label，

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:                     # 為Pod設定兩個Label    
    app: nginx    
    env: prod
spec:
  containers:
  - image: nginx:alpine
    name: container-0
    resources:
      limits:
        cpu: 100m
        memory: 200Mi
      requests:
        cpu: 100m
        memory: 200Mi
  imagePullSecrets:
  - name: default-secret

Pod有了Label后，在查詢Pod的時候帶上--show-labels就可以看到Pod的Label，

$ kubectl get pod --show-labels
NAME              READY   STATUS    RESTARTS   AGE   LABELS
nginx             1/1     Running   0          50s   app=nginx,env=prod

Namespace：資源分組

為什么需要Namespace

Label雖然好，但只用Label的話，那Label會非常多，有時候會有重疊，而且每次查詢之類的動作都帶一堆Label非常不方便，Kubernetes提供了Namespace來做資源組織和劃分，使用多Namespace可以將包含很多組件的系統分成不同的組，Namespace也可以用來做多租戶劃分，這樣多個團隊可以共用一個集群，使用的資源用Namespace劃分開，

不同的Namespace下面可以有相同的名字，Kubernetes中大部分資源可以用Namespace劃分，不過有些資源不行，它們屬于全域資源，不屬于某一個Namespace，后面會逐步接觸到，

通過如下命令可以查詢到當前集群下的Namespace，

$ kubectl get ns
NAME               STATUS   AGE
default            Active   36m
kube-node-realease Active   36m
kube-public        Active   36m
kube-system        Active   36m

Namespace的隔離說明

Namespace只能做到組織上劃分，對運行的物件來說，它不能做到真正的隔離，舉例來說，如果兩個Namespace下的Pod知道對方的IP，而Kubernetes依賴的底層網路沒有提供Namespace之間的網路隔離的話，那這兩個Pod就可以互相訪問，

Pod的編排與調度

Deployment

什么是Deployment

在Pod：Kubernetes中的最小調度物件這個章節介紹了Pod，Pod是Kubernetes創建或部署的最小單位，但是Pod是被設計為相對短暫的一次性物體，Pod可以被驅逐（當節點資源不足時）、隨著集群的節點崩潰而消失，Kubernetes提供了Controller（控制器）來管理Pod，Controller可以創建和管理多個Pod，提供副本管理、滾動升級和自愈能力，其中最為常用的就是Deployment，

圖1 Deployment

一個Deployment可以包含一個或多個Pod副本，每個Pod副本的角色相同，所以系統會自動為Deployment的多個Pod副本分發請求，

Deployment集成了上線部署、滾動升級、創建副本、恢復上線的功能，在某種程度上，Deployment實作無人值守的上線，大大降低了上執行緒序的復雜性和操作風險，

創建Deployment

以下示例為創建一個名為nginx的Deployment負載，使用nginx:latest鏡像創建兩個Pod，每個Pod占用100m core CPU、200Mi記憶體，

apiVersion: apps/v1      # 注意這里與Pod的區別，Deployment是apps/v1而不是v1
kind: Deployment         # 資源型別為Deployment
metadata:
  name: nginx            # Deployment的名稱
spec:
  replicas: 2            # Pod的數量，Deployment會確保一直有2個Pod運行         
  selector:              # Label Selector
    matchLabels:
      app: nginx
  template:              # Pod的定義，用于創建Pod，也稱為Pod template
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:latest
        name: container-0
        resources:
          limits:
            cpu: 100m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
      imagePullSecrets:
      - name: default-secret

從這個定義中可以看到Deployment的名稱為nginx，spec.replicas定義了Pod的數量，即這個Deployment控制2個Pod；spec.selector是Label Selector（標簽選擇器），表示這個Deployment會選擇Label為app=nginx的Pod；spec.template是Pod的定義，內容與Pod中的定義完全一致，

將上面Deployment的定義保存到deployment.yaml檔案中，使用kubectl創建這個Deployment，

使用kubectl get查看Deployment和Pod，可以看到READY值為2/2，前一個2表示當前有2個Pod運行，后一個2表示期望有2個Pod，AVAILABLE為2表示有2個Pod是可用的，

$ kubectl create -f deployment.yaml
deployment.apps/nginx created

$ kubectl get deploy
NAME           READY     UP-TO-DATE   AVAILABLE   AGE
nginx          2/2       2            2           4m5s

Deployment如何控制Pod

繼續查詢Pod，如下所示，

$ kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
nginx-7f98958cdf-tdmqk   1/1       Running   0          13s
nginx-7f98958cdf-txckx   1/1       Running   0          13s

如果刪掉一個Pod，您會發現立馬會有一個新的Pod被創建出來，如下所示，這就是前面所說的Deployment會確保有2個Pod在運行，如果刪掉一個，Deployment會重新創建一個，如果某個Pod故障或有其他問題，Deployment會自動拉起這個Pod，

$ kubectl delete pod nginx-7f98958cdf-txckx

$ kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
nginx-7f98958cdf-tdmqk   1/1       Running   0          21s
nginx-7f98958cdf-tesqr   1/1       Running   0          21s

看到有如下兩個名為nginx-7f98958cdf-tdmqk和nginx-7f98958cdf-tesqr的Pod，其中nginx是直接使用Deployment的名稱，-7f98958cdf-tdmqk和-7f98958cdf-tesqr是kubernetes隨機生成的后綴，

您也許會發現這兩個后綴中前面一部分是相同的，都是7f98958cdf，這是因為Deployment不是直接控制Pod的，Deployment是通過一種名為ReplicaSet的控制器控制Pod，通過如下命令可以查詢ReplicaSet，其中rs是ReplicaSet的縮寫，

$ kubectl get rs
NAME               DESIRED   CURRENT   READY     AGE
nginx-7f98958cdf   2         2         2         1m

這個ReplicaSet的名稱為nginx-7f98958cdf，后綴-7f98958cdf也是隨機生成的，

Deployment控制Pod的方式如圖2所示，Deployment控制ReplicaSet，ReplicaSet控制Pod，

圖2 Deployment通過ReplicaSet控制Pod

如果使用kubectl describe命令查看Deployment的詳情，您就可以看到ReplicaSet，如下所示，可以看到有一行NewReplicaSet: nginx-7f98958cdf (2/2 replicas created)，而且Events里面事件確是把ReplicaSet的實體擴容到2個，在實際使用中您也許不會直接操作ReplicaSet，但了解Deployment通過控制ReplicaSet來控制Pod會有助于您定位問題，

$ kubectl describe deploy nginx
Name:                   nginx
Namespace:              default
CreationTimestamp:      Sun, 16 Dec 2018 19:21:58 +0800
Labels:                 app=nginx

...

NewReplicaSet:   nginx-7f98958cdf (2/2 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  5m    deployment-controller  Scaled up replica set nginx-7f98958cdf to 2

升級

在實際應用中，升級是一個常見的場景，Deployment能夠很方便的支撐應用升級，

Deployment可以設定不同的升級策略，有如下兩種，

RollingUpdate：滾動升級，即逐步創建新Pod再洗掉舊Pod，為默認策略，
Recreate：替換升級，即先把當前Pod刪掉再重新創建Pod，

Deployment的升級可以是宣告式的，也就是說只需要修改Deployment的YAML定義即可，比如使用kubectl edit命令將上面Deployment中的鏡像修改為nginx:alpine，修改完成后再查詢ReplicaSet和Pod，發現創建了一個新的ReplicaSet，Pod也重新創建了，

$ kubectl edit deploy nginx

$ kubectl get rs
NAME               DESIRED   CURRENT   READY     AGE
nginx-6f9f58dffd   2         2         2         1m
nginx-7f98958cdf   0         0         0         48m

$ kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
nginx-6f9f58dffd-tdmqk   1/1       Running   0          21s
nginx-6f9f58dffd-tesqr   1/1       Running   0          21s

Deployment可以通過maxSurge和maxUnavailable兩個引數控制升級程序中同時重新創建Pod的比例，這在很多時候是非常有用，配置如下所示，

spec:
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate

maxSurge：與Deployment中spec.replicas相比，可以有多少個Pod存在，默認值是25%，比如spec.replicas為 4，那升級程序中就不能超過5個Pod存在，即按1個的步伐升級，實際升級程序中會換算成數字，且換算會向上取整，這個值也可以直接設定成數字，
maxUnavailable：與Deployment中spec.replicas相比，可以有多少個Pod失效，也就是洗掉的比例，默認值是25%，比如spec.replicas為4，那升級程序中就至少有3個Pod存在，即洗掉Pod的步伐是1，同樣這個值也可以設定成數字，

在前面的例子中，由于spec.replicas是2，如果maxSurge和maxUnavailable都為默認值25%，那實際升級程序中，maxSurge允許最多3個Pod存在（向上取整，2*1.25=2.5，取整為3），而maxUnavailable則不允許有Pod Unavailable（向上取整，2*0.75=1.5，取整為2），也就是說在升級程序中，一直會有2個Pod處于運行狀態，每次新建一個Pod，等這個Pod創建成功后再刪掉一個舊Pod，直至Pod全部為新Pod，

回滾

回滾也稱為回退，即當發現升級出現問題時，讓應用回到老的版本，Deployment可以非常方便的回滾到老版本，

例如上面升級的新版鏡像有問題，可以執行kubectl rollout undo命令進行回滾，

$ kubectl rollout undo deployment nginx
deployment.apps/nginx rolled back

Deployment之所以能如此容易的做到回滾，是因為Deployment是通過ReplicaSet控制Pod的，升級后之前ReplicaSet都一直存在，Deployment回滾做的就是使用之前的ReplicaSet再次把Pod創建出來，Deployment中保存ReplicaSet的數量可以使用revisionHistoryLimit引數限制，默認值為10，

StatefulSet

為什么需要StatefulSet

在Deployment中講到了Deployment，Deployment控制器下的Pod都有個共同特點，那就是每個Pod除了名稱和IP地址不同，其余完全相同，需要的時候，Deployment可以通過Pod模板創建新的Pod；不需要的時候，Deployment就可以洗掉任意一個Pod，

但是在某些場景下，這并不滿足需求，比如有些分布式的場景，要求每個Pod都有自己單獨的狀態時，比如分布式資料庫，每個Pod要求有單獨的存盤，這時Deployment就不能滿足需求了，

詳細分析下有狀態應用的需求，分布式有狀態的特點主要是應用中每個部分的角色不同（即分工不同），比如資料庫有主備，Pod之間有依賴，對應到Kubernetes中就是對Pod有如下要求：

Pod能夠被別的Pod找到，這就要求Pod有固定的標識，
每個Pod有單獨存盤，Pod被洗掉恢復后，讀取的資料必須還是以前那份，否則狀態就會不一致，

Kubernetes提供了StatefulSet來解決這個問題，其具體如下：

StatefulSet給每個Pod提供固定名稱，Pod名稱增加從0-N的固定后綴，Pod重新調度后Pod名稱和HostName不變，
StatefulSet通過Headless Service給每個Pod提供固定的訪問域名，Service的概念會在Service中詳細介紹，
StatefulSet通過創建固定標識的PVC保證Pod重新調度后還是能訪問到相同的持久化資料，

Job和CronJob

DaemonSet

親和與反親和調度

配置管理

ConfigMap
Secret

Kubernetes網路

容器網路
Service
Ingress
就緒探針（Readiness Probe）
NetworkPolicy

持久化存盤

Volume
PV、PVC和StorageClass

認證與授權

ServiceAccount
RBAC

彈性伸縮

彈性伸縮

k8s部署

搭建Kubernetes集群

Kubernetes網站上有多種搭建Kubernetes集群的方法，例如minikube、kubeadm等

我們在這里主要說兩種，一種是kubeadm方式，另一種是二次封裝的方式，方便后續私有化部署以及容器平臺的建設，

kubeadm方式

二次封裝--sealos方式

應用容器化

市場上存在各個不同的服務應用，這里介紹幾個常用的容器化應用改造

整體應用容器化改造時，一般需要執行如下流程，

Tomcat 應用

jar 應用

PHP應用

Python 應用

k8s CICD 建設

Devops運維平臺建設

1.cmdb管理

2.主機管理

3.k8s集群管理

4.集成CICD

5.監控

6.告警

7.知識庫建設

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/289533.html

標籤：其他

上一篇：OSI七層模型和TCP/IP四層（TCP與UDP）（筆記）

下一篇：Nginx 的安裝

k8s摘要

k8s相關知識可以參考k8s官方指導

https://kubernetes.io/zh/docs/home/

概述

k8s CICD 建設

Devops運維平臺建設