k8s之深入解剖Pod（二）

目錄：

　　Pod配置管理：ConfigMap

　　容器內獲取Pod資訊：Downward API

　　Pod生命週期和重啟策略

　　Pod健康檢查

 

一、ConfigMap

將應用所需的配置資訊與程式進行分離，可以使應用程式更好的被複用，通過不同的配置實現更靈活的功能。如果將應用打包成映象，再用環境變數或者外掛檔案的方式掛載配置，在大型容器叢集中會變得異常繁瑣，所以出現了統一的配置管理：ConfigMap

（1）ConfigMap：容器應用的配置管理

典型用法如下：

1、生成為容器內的環境變數

2、設定容器啟動命令的啟動引數（需設定為環境變數）

3、以Volume的形式掛載為容器內部的檔案或目錄

ConfigMap以一個或多個key：value的形式儲存在k8s系統中供應用使用，既可以用於表示一個變數的值，也可以表示一個完整配置檔案的內容。

 

（2）建立方式

1、通過yaml檔案進行建立

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-1
data:
  home_path: /usr/soft

　　

需要將配置定義在data下面，上述yaml檔案中在data中定義了一個key是home_path，value是/usr/soft的配置。

使用如下命令建立：

kubectl create -f cm_1.yaml

　　

 

 

檢視建立的ConfigMap:

kubectl get cm
或
kubectl get configmap

　　

 

 

檢視ConfigMap的詳細內容：

kubectl describe cm/cm-1

　　

 

 

2、通過kubectl命令列建立

直接通過kubectl create configmap，可使用引數--from-file或--from-literal指定內容，並且可以在一行命令中指定多個引數。

（1）通過--from-file引數從檔案中進行建立，可以指定key的名稱，也可以在一個命令列中建立包含多個key的ConfigMap

例如：在當前目錄下建立一個檔名為config_1.conf，檔案內容就是“value1”

使用如下命令建立configmap，名為config-1

kubectl create configmap config-1 --from-file=config_1.conf

　　

檢視：其會以檔名為key，檔案內容為value建立一條資料

 

 

（2）通過--from-file引數從目錄中進行建立，該目錄下的每個配置檔名都被設定為key，檔案的內容被設定為value

例如：在configmap目錄下由三個檔案

 

 

使用如下命令建立：

kubectl create configmap cm-name --from-file=file-dir

　　

 

 

檢視詳細資料：其會以檔名作為key，檔案內容作為value

 

 

（3）--from-literal從文字中進行建立，直接將指定的key=value建立為configmap的內容

例如：建立一個key為name，value為Liusy的configmap資料

kubectl create configmap cm-3 --from-literal=name=liusy

　　

 

 

（3）ConfigMap使用

以上述常見的cm-1為例

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-1
data:
  home_path: /usr/soft

　　

1、環境變數方式

本文建立一個Pod執行著nginx例項，在環境變數中使用cm-1的配置

apiVersion: v1
kind: Pod
metadata:
  name: cm-nginx
spec:
  containers:
  - name: cm-nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    env:
    - name: home
      valueFrom:
        configMapKeyRef:
          name: cm-1
          key: home_path

　　

建立好Pod後進入容器：

 

 

檢視環境變數：

 

 

可以看到，home環境變數的值正是cm-1中配置的路徑

2、volumeMount模式

比如定義一個Pod，其中定義一個volume，volume中引用名為cm-1的configmap，將key為home_path的value值寫入homtpath.txt檔案中，在容器中的configfiles目錄上掛載這個volume

apiVersion: v1
kind: Pod
metadata:
  name: mount-pod
spec:
  volumes:
  - name: cm-volume
    configMap:
      name: cm-1
      items:
      - key: home_path
        path: homepath.txt
  containers:
  - name: mount-pod
    image: nginx
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: cm-volume
      mountPath: /configfiles

　　

建立Pod後進入容器：

 

 

可以看到，configfiles目錄下確實生成了一個homepath.txt檔案，來檢視以下檔案的內容：

 

 

（4）ConfigMap使用限制

• ConfigMap必須在Pod之前建立
• ConfigMap有Namespace限制，只有在同一Namespace下才可使用
• 靜態Pod無法使用ConfigMap

 

二、容器內獲取Pod資訊：Downward API

在Pod建立之後，會被分配唯一的名字、IP地址，並處於某個Namespace中，那麼這些資訊在Pod中應該怎麼獲取呢，就是利用Downward API。

Downward API可以通過以下兩種方式將Pod資訊注入容器內部。

1、環境變數

用於單個變數（也就是在Pod定義中是單值的，非陣列），可以將Pod資訊和Container資訊注 入容器內部。

比如下例中將Pod的name、namespace、ip注入為環境變數

apiVersion: v1
kind: Pod
metadata:
  name: pod-name
  namespace: kube-system
spec:
  containers:
  - name: pod-name
    image: nginx
    imagePullPolicy: IfNotPresent
    env:
    - name: name
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: ns
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: ip
      valueFrom:
        fieldRef:
          fieldPath: status.podIP

　　

建立Pod之後進入容器檢視相應的環境變數：

 

 

又比如下例中將resource注入為環境變數

apiVersion: v1
kind: Pod
metadata:
  name: pod-name1
spec:
  containers:
  - name: c1
    image: nginx
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        cpu: "125m"
        memory: "32Mi"
      limits:
        cpu: "250m"
        memory: "64Mi"
    env:
    - name: req_cpu
      valueFrom:
        resourceFieldRef:
          containerName: c1
          resource: requests.cpu
    - name: lim_cpu
      valueFrom:
        resourceFieldRef:
          containerName: c1
          resource: limits.cpu
    - name: lim_me
      valueFrom:
        resourceFieldRef:
          containerName: c1
          resource: limits.memory

　　

建立Pod後進入容器檢視：

 

 

2、volume掛載

將陣列類資訊生成為檔案並掛載到容器內部。例如labels、annotations等

例如下例中將label資訊通過volume掛載到容器的label目錄

apiVersion: v1
kind: Pod
metadata:
  name: pod-volume
  labels:
    name: pod-volume
    age: zero
spec:
  containers:
  - name: c1
    image: nginx
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: v-l
      mountPath: /labels
      readOnly: false
  volumes:
  - name: v-l
    downwardAPI:
      items:
      - path: "labels"
        fieldRef:
          fieldPath: metadata.labels

　　

上述yaml中建立了一個volume，通過items設定，會生成path值的檔案，檔案的內容就是相應的資訊，在容器中將volume掛載到/labels目錄下：

建立之後進入容器檢視檔案：

 

 

三、Pod生命週期和重啟策略

Pod的狀態包括以下幾種：

 

 

Pod的重啟策略應用於Pod內的所有容器，並且僅在Pod所處的Node上有kubelet進行判斷和重啟操作，當某個容器異常退出或者健康檢查失敗時，kubelet將根據RestartPolicy設定進行相應的操作。在spec.restartPolicy中配置相應的重啟策略

重啟策略有如下三個：

spec:
  restartPolicy: [Always|Never|OnFailure]

　　

• Always：Pod一旦終止執行，kubelet都會進行重啟，這也是預設值
• Never：不會進行重啟
• OnFailure：容器非正常退出（即是退出碼不為0），kubelet會重啟容器，反之不會重啟。

kubelet重啟失效容器的時間間隔以sync-frequency乘以2n來計算，例如1,2,4,8等，最長延時5分鐘，且在重啟10分鐘之後重置該時間。

Pod的重啟策略與控制方式息息相關，當前可用於管理Pod的控制器包括RC，Job，DaemonSet及直接通過kubelet管理的靜態Pod，每種控制器對Pod的重啟策略如下：

• RC、DaemonSet：必須設定為Always，保證容器持續執行
• Job：OnFailure或Never，執行完就退出
• kubelet：在Pod失效時自動重啟它，不論RestartPolicy是什麼值，並且也不會進行健康檢查。

四、Pod健康檢查

k8s提供了Pod健康檢查機制，對於檢測到故障服務會被及時自動下線，以及通過重啟服務的方式使服務自動恢復。可通過兩類探針來檢查：LivenessProbe和ReadinessProbe

1、LivenessProbe

用於判斷容器是否存活（running狀態），如果探測到容器不健康，則kubelet殺掉此容器，並根據重啟策略做相應的處理。

kubelet定期執行LivenessProbe來判斷容器的健康狀態，有三種實現方式：

（1）ExecAction

在容器內部執行一個命令，如果返回0，則表明容器健康。

apiVersion: v1
kind: Pod
metadata:
  name: live-exec
spec:
  containers:
  - name: live-exec
    image: nginx
    args:
    - /bin/sh
    - -c
    - echo ok > /tmp/health;sleep 10;rm -rf /tmp/health;sleep 1000
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/health
      initialDelaySeconds: 5
      timeoutSeconds: 1

　　

上述yaml是在容器啟動時將ok輸出到/tem/health檔案中，10s過後刪除此檔案。看效果：

kubectl describe  pods/live-exec

　　

 

 

當檔案被刪除之後，探針探測到容器不健康，所以會進行重啟

（2）TCPSocketAction

通過容器的IP地址和埠號進行TCP檢查，如果能建立TCP連線，則說明容器健康

apiVersion: v1
kind: Pod
metadata:
  name: live-tcp
spec:
  containers:
  - name: live-tcp
    image: nginx
    imagePullPolicy: IfNotPresent
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      timeoutSeconds: 1

　　

（3）HttpGetAction

通過容器的IP、埠及路徑呼叫HTTP Get方法，響應碼大於200，小於400，容器健康

apiVersion: v1
kind: Pod
metadata:
  name: live-httpget
spec:
  containers:
  - name: live-httpget
    image: nginx
    imagePullPolicy: IfNotPresent
    livenessProbe:
      httpGet:
        path: /_status/healthz
        port: 80
        host: host
        scheme: HTTP
        httpHeaders:
        - name: string
          value: string
      initialDelaySeconds: 15
      timeoutSeconds: 1

　　

2、ReadinessProbe

用於判斷容器是否啟動完成（ready狀態），可接受請求。如果檢測到失敗，則Pod的狀態將被修改。Endpoint Controller將從service的Endpoint中刪除包含該容器所在Pod的Endpoint，此Pod不再接收請求。

此探針使用方式和上述livenessProbe相同。
例如：ExecAction方式

apiVersion: v1
kind: Pod
metadata:
  name: read-exec
spec:
  containers:
  - name: read-exec
    image: nginx
    command: ["/bin/bash","-c","mkdir /health;sleep 10;rm -rf /health;sleep 10;mkdir /health;sleep 600"]
    readinessProbe:
      exec:
        command: ["ls","/health"]
      initialDelaySeconds: 5
      timeoutSeconds: 1

　　

上述yaml在容器啟動建立一個目錄，10s後刪除，再10s後建立此目錄，看容器健康檢測情況

 

 

其在檢測出容器啟動失敗後會定時去檢測，不會重啟容器，直至檢測到容器健康。

對於每種探測方式，都需要配置以下兩個引數：

• initialDelaySeconds：啟動後多久進行健康檢查，單位是秒
• timeoutSeconds：健康檢查傳送請求後的等待響應的超時時間，單位是s，超時未響應，則會重啟該pod

===============================

我是Liusy，一個喜歡健身的程式設計師。

歡迎關注微信公眾號【Liusy01】，一起交流Java技術及健身，獲取更多幹貨，領取Java進階乾貨，領取最新大廠面試資料，一起成為Java大神。

來都來了，關注一波再溜唄。