目錄：nginx

Pod配置管理：ConfigMap程序員

容器內獲取Pod信息：Downward API面試

Pod生命週期和重啓策略api

Pod健康檢查數組

1、ConfigMapbash

將應用所需的配置信息與程序進行分離，可使應用程序更好的被複用，經過不一樣的配置實現更靈活的功能。若是將應用打包成鏡像，再用環境變量或者外掛文件的方式掛載配置，在大型容器集羣中會變得異常繁瑣，因此出現了統一的配置管理：ConfigMap微信

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

典型用法以下：tcp

一、生成爲容器內的環境變量spa

二、設置容器啓動命令的啓動參數（需設置爲環境變量）

三、以Volume的形式掛載爲容器內部的文件或目錄

ConfigMap以一個或多個key：value的形式保存在k8s系統中供應用使用，既能夠用於表示一個變量的值，也能夠表示一個完整配置文件的內容。

（2）建立方式

經過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
複製代碼

經過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
複製代碼

環境變量方式

本文建立一個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中配置的路徑

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

2、容器內獲取Pod信息：Downward API

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

Downward API能夠經過如下兩種方式將Pod信息注入容器內部。

環境變量

用於單個變量（也就是在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後進入容器查看：

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目錄下：

建立以後進入容器查看文件：

3、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是什麼值，而且也不會進行健康檢查。

4、Pod健康檢查

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

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
複製代碼

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大神。

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

k8s之深刻解剖Pod（二）