Pod:

Pod是 kubernetes 的最基本的操作單元，包含一個或多個緊密相關的容器

kubernetes 使用pod在容器之上再封裝一層，其一個很重要的原因是，docker容器之間的通訊受到docker網路機制的限制。在docker中，因為每個容器內的網路不同，在以前，往往需要通過link方式才能訪問另一個容器提供服務，但是這種方式，docker官網已經不再推薦，docker官方推薦讓兩個需要通訊的容器放在同一個網路，三劍客之一的docker-compose就能提供了這樣的條件。kubernetes通過pod的概念將多個容器組合在一個虛擬的 主機內，可以實現容器之間僅需通過localhost就能相互通訊了

kubernetes 設計了pod物件，將每個服務程序包裝到相應的pod中，使其成為pod中執行的一個容器，在使用時，我們會將 pod物件打上 標籤，例如 提供mysql服務功能的pod，我們會為該pod打上name=mysql的標籤. 然後將 mysql service 的標籤選擇器設定為 mysql ， 這樣pod 物件 和 service 就能關聯起來了

pod 的 proxy 介面的作用： 在kubernetes叢集之外訪問某個pod容器的服務（HTTP服務）時，可以用Proxy API實現，這種場景多用於管理目的，比如逐一排查Service的Pod副本，檢查哪些Pod的服務存在異常問題

kubernetes的pod使用分兩種主要方式：

（1）pod中執行一個容器 "one-container-per-pod"模式是kubernetes最常見的用法。在這種情況下，你可以將pod視為當個封裝的容器，但是kubernetes是直接管理pod而不是容器

（2）pods中執行多個需要一起工作的容器。pod可以封裝緊密耦合的應用，它們需要由多個容器組成，它們之間能夠共享資源、

 

 

Replication Controller 簡稱 RC：

Replication Controller 是 kubernetes 系統中的核心概念，用於定義pod副本的數量。在master內，controller manager 程序通過RC的定義來完成pod的建立，監控，啟停等操作

當我們定義了一個RC並提交到kubernetes叢集中以後，master節點上的controller manager元件就得到通知，定期巡檢系統中當前存活的目標pod,並確保目標pod例項的數量剛好等於此RC的期望值，如果有多個pod副本在執行，系統就會停掉一些pod，否則系統就會再自動建立一些pod。可以說，通過RC，kubernetes實現了使用者應用叢集的高可用性，並且大大減少了系統管理員在傳統IT環境中需要完成的許多手工運維工作

在執行的時候，我們可以通過修改RC的副本數量，來實現Pod的動態縮放(scaling)

kubectl scale rc jxc --replicas=3

刪除RC並不會影響通過該RC已建立好的pod，為了刪除所有pod，可以設定replicas=0，然後更新該RC。另外，客戶端工具kubectl提供了stop和delete命令來完成一次性刪除

RC 和 RC控制的全部pod

指定容器的配額：

對指定容器實施配額管理非常簡單，只要在pod或 rc 的定義檔案中設定 resources屬性即可為某個容器指定配額。目前支援CPU和Memory兩類資源的配額限制。

例如

apiVersion: v1
kind: ReplicationController
metadata:
  name: jxc
  labels:
    name: jxc
spec:
  replicas: 1
  selector:
    name: jxc
  template:
    metadata:
      labels:
        name: jxc
    spec:
      containers:
      - name: jxc
        image: 192.168.255.128:5000/jxc:0.0.3
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: 0.5
            memory: 500Mi

以上配置表示，系統將對容器 限制 CPU為0.5，可用記憶體限制為500MIB位元組

kubernetes 啟動一個容器時，會將CPU的配額 值乘以1024 並轉為整數傳遞給docker run 的 --cpu-shares 引數， 之所以乘以1024 是因為docker的

cpu-shares 引數是以1024為基數基數CPU時間的。 關於 docker 的 cpu-shares 引數 解析 請參考 https://blog.csdn.net/weixin_39639119/article/details/83046676

，同樣的，memory 配額也會被轉換為整數傳遞給 docker run 的 --memory引數。

 

全域性預設配額：

通常情況下，我們將會定義非常多的 rc，如果 每個 資源 都要我們 設定 配額的話，那會顯得 十分麻煩，

我們可以通過 建立 LimitRange物件 設定全域性預設配額。

vim pod-container-limits.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: limit-range-1
spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2"
        memory: 1Gi
      min:
        cpu: 250m
        memory: 32Mi
    - type: "Container"
      max:
        cpu: "2"
        memory: 1Gi
      min:
        cpu: 250m
        memory: 32Mi
      default:
        cpu: 250m
        memory: 64Mi

~                           

上述 設定表明：

任意 pod內所有容器的CPU 使用 限制在 0.25 -2

任意 pod 內所有 容器 的記憶體 使用限制在 32Mi - 1Gi

任意容器的 CPU使用限制在0.25 - 2，預設值為64Mi

任意容器的記憶體使用限制在 32Mi - 1Gi,預設值為64Mi

 

 

kubectl replace -f pod-container-limits.yaml

kubectl describe limits limit-range-1

[[email protected] kubefile]# kubectl describe limits limit-range-1 Name: limit-range-1 Namespace: default Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Pod cpu 250m 2 - - - Pod memory 32Mi 1Gi - - - Container memory 32Mi 1Gi 64Mi 64Mi - Container cpu 250m 2 250m 250m -

 

執行 kubectl create 命令 建立該 pod

[[email protected] kubefile]# kubectl describe pod jxc

Limits: cpu: 250m memory: 64Mi Requests: cpu: 250m memory: 64Mi

建立成功後，檢視該pod的詳細資訊，可以看到系統中LimitRange的設定對新建立的容器進行了資源限制(使用了LimitRange中的預設值)

 

如果，我們在pod的定義檔案中指定了配額引數，則可遵循區域性覆蓋全域性的原則，當不能超過了全域性設定的最大值

 

replica set:

由於replication controller 與kubernetes程式碼中的模組replication controller 同名，同時這個詞也無法準確表達它的本意，所以在kubernetes 1.2 的時候，它就升級成了另外一個新的概念 -- replica set。二者之間唯一的區別是，Replica Set支援了基於集合的Label Selector功能

ReplicaSet是支援新的set-based 選擇器要求的下一代 ReplicationController。它主要用作Deployment 協調pod建立，刪除和更新。雖然ReplicaSets可以獨立使用，但它主要被

Deployment協調pod建立，刪除和更新。建議使用Deployment而不是直接使用ReplicaSets

 

 

Deployment:

學過saltstack都值得，salt有一個狀態模組，只要你在salt配置檔案描述好狀態，salt就會將你指定的主機狀態改變到你的目標狀態。

Deployment也能剛這樣的事情，你只需要在Deployment中描述您想要的目標狀態是什麼。Deployment Controller就會幫你將Pod 和

ReplicaSet的實際狀態改變到您的目標狀態

典型用例：

（1）建立一個Deployment物件來生成對應的ReplicaSet,並完成Pod副本的建立過程

（2） 檢查Deployment的狀態來檢視部署動作是否完成，pod副本的數量是否達到預期的值

（3）更新Deployment以建立新的Pod，通過修改pod-template-spec欄位來宣告pod的新狀態。這會建立一個新的

replicaSet, Deployment 會按照控制的速率將pod從舊的ReplcaSet移動到新的ReplicaSet中

（4）如果當前狀態不穩定，則回滾到一個早先的Deployment版本

（5）擴容 Deployment 以滿足更高的負載

（6）檢視 Deployment 狀態，判斷髮布是否成功

（7）清除舊的replicaSets

 

建立deployment

[[email protected] kubefile]# vim ku-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: jxc-deployment
  labels:
    web: jxc
spec:
  replicas: 1
  selector:
    matchLabels:
      web: jxc
  template:
    metadata:
      labels:
        web: jxc
    spec:
      containers:
      - name: jxc
        image: 192.168.255.128:5000/jxc:0.0.3
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080

建立 deployment

kubectl create -f ku-deployment.yaml --record

-- record 當我們需要檢視 歷史版本時，可以很方便的檢視每次 revision變化

 

檢視deployment 的 建立詳情

[[email protected]node1 kubefile]# kubectl describe deployment jxc-deployment

[[email protected] kubefile]# kubectl get deployments

[[email protected] kubefile]# kubectl get rs

 

runing說明啟動成功

[[email protected] kubefile]# kubectl get pods

NAME READY STATUS RESTARTS AGE

jxc-deployment-3952983837-mw8df 1/1 Running 0 3m

 

 

 

更新

deployment的更新

當 使用 kubectl edit 命令 時，就可以 編輯 yaml 檔案，當deployment的pod template的 label 發生更新或者映象發生 更改時

，才會觸發更新 訊號（rollout）

例如將 jxc:0.0.3 更改為 jxc0.0.4

kubectl edit deployment/jxc-deployment

spec: containers: - image: 192.168.255.128:5000/jxc:0.0.4 imagePullPolicy: IfNotPresent name: jxc ports: - containerPort: 8080 protocol: TCP resources: {} terminationMessagePath: /dev/termination-log dnsPolicy: ClusterFirst restartPolicy: Always securityContext: {} terminationGracePeriodSeconds: 30

 

[[email protected] kubefile]# kubectl rollout status deployment/jxc-deployment

deployment "jxc-deployment" successfully rolled out

 

 

回退

當deployment 更新時，就會建立一個revision。我們可以通過設定.spec.revisionHistoryLimit來指定deployment最多保留多少個

revision歷史記錄。預設會保留所有的revision；如果將該項設定為0，deployment就不允許回退了

 

我們先用 kubectl edit deployment/jxc-deployment 將 版本 修改為一個不存在的版本

spec: containers: - image: 192.168.255.128:5000/jxc:0.0.6 imagePullPolicy: IfNotPresent name: jxc ports: - containerPort: 8080 protocol: TCP resources: {} terminationMessagePath: /dev/termination-log dnsPolicy: ClusterFirst restartPolicy: Always securityContext: {} terminationGracePeriodSeconds: 30

 

[[email protected] kubefile]# kubectl rollout status deployment/jxc-deployment

Waiting for rollout to finish: 0 of 1 updated replicas are available...

通過 該 命令 ， 我們可以得知 版本更新 卡住了

[[email protected] kubefile] kubectl get pods

NAME READY STATUS RESTARTS AGE

jxc-deployment-4197170976-8sph2 0/1 ImagePullBackOff 0 2m

pods 也處於 ImagePullBackOff 狀態

 

我們 需要 回退到穩定的版本

我們 先 檢視 deployment 歷史版本記錄

[[email protected] kubefile]# kubectl rollout history deployment/jxc-deployment

deployments "jxc-deployment"

REVISION CHANGE-CAUSE

1 kubectl create -f ku-deployment.yaml --record

2 kubectl edit deployment/jxc-deployment

3 kubectl edit deployment/jxc-deployment

 

檢視當個 version 資訊

kubectl rollout history deployment/jxc-deployment --revision=2

deployments "jxc-deployment" with revision #2 Labels: pod-template-hash=4034379550 web=jxc Annotations: kubernetes.io/change-cause=kubectl edit deployment/jxc-deployment Containers: jxc: Image: 192.168.255.128:5000/jxc:0.0.4 Port: 8080/TCP Volume Mounts: <none> Environment Variables: <none> No volumes.

回退到 上一個版本

 kubectl rollout undo deployment/jxc-deployment

[[email protected] kubefile]# kubectl rollout undo deployment/jxc-deployment deployment "jxc-deployment" rolled back [[email protected] kubefile]# kubectl get pods NAME READY STATUS RESTARTS AGE jxc-deployment-4034379550-pjfp9 1/1 Running 0 3s

回退到指定版本

kubectl rollout undo deployment/jxc-deployment --to-revision=2

[[email protected] kubefile]# kubectl rollout undo deployment/jxc-deployment --to-revision=1 deployment "jxc-deployment" rolled back [[email protected] kubefile]# kubectl get pods NAME READY STATUS RESTARTS AGE jxc-deployment-3952983837-tq31x 1/1 Running 0 4s

 

擴容

kubectl scale deployment deployment/jxc-deployment --replicas 2

[[email protected] kubefile]# kubectl scale deployment jxc-deployment --replicas 2 deployment "jxc-deployment" scaled [[email protected] kubefile]# kubectl get pods NAME READY STATUS RESTARTS AGE jxc-deployment-3952983837-jzzzv 1/1 Running 0 4s jxc-deployment-3952983837-tq31x 1/1 Running 0 2m

 

暫停和 恢復

當需要對 deployment 進行多次修改時， 我們可以 先暫時，再恢復，防止 不必要的rollout

kubectl rollout pause deployment/jxc-deployment

[[email protected] kubefile]# kubectl rollout pause deployment/jxc-deployment deployment "jxc-deployment" paused

 

我 把 映象的版本改為 0.0.4 ，然後恢復

kubectl rollout resume deploy jxc-deployment

[[email protected] kubefile]# kubectl rollout resume deploy jxc-deployment deployment "jxc-deployment" resumed

 

 

Horizontal Pod Autoscaling

HPA 的操作物件是RC，RS 或 Deployment對應的Pod，根據觀察到的CPU等實際使用量與使用者的期望值進行比對，做出是否需要增減例項數量的決策

kubernetes 根據 pod當前系統的負載來自動擴容，如果系統負載超過預定值，就開始增加pod的個數，如果低於某個值，就自動減少pod的個數。在v1.6

版本之前，僅支援使用CPU負載作為是否擴容的判定條件；自v1.6版本開始提供了根據應用自定義指標進行自動擴容和縮容的功能

我們可以通過建立 yaml 檔案，來實現自動擴容

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: jxc
  namespace: default
spec:
  maxReplicas: 10
  minReplicas: 1
  scaleTargetRef:
    kind: Deployment
    name: jxc
  targetCPUUtilizationPercentage: 90

kubectl create -f jxc-hpa.yaml

上述 指令碼的意思 是 當名為 jxc 的 deployment 的 pod副本的CPU使用率 超過 90%時，會觸發自動擴容行為。但 擴容或縮容都必須滿足約束條件

pod 的副本數量 在 1-10 之間