k8s-pod

 

1.概述

Pod對象是一組容器的集合，這些容器共享Network、UTS及IPC名稱空間，因此具有相同的域名、主機名和網絡接口，並可通過IPC直接通信。絕大多數場景中都應該在一個容器中僅運行一個進程，這也是Docker及Kubernetes使用容器的標準方式。

這樣也更能符合容器的輕量化設計、運行之目的。

 

2.pod 對象

1）鏡像策略

 imagePullPolicy字段用於爲其指定鏡像獲取策略

Always：鏡像標籤爲“latest”或鏡像不存在時總是從指定的倉庫中獲取 鏡像；

IfNotPresent：僅當本地鏡像缺失時才從標準倉庫下載鏡像；

Never：禁止從倉庫下載鏡像，即僅使用本地鏡像。

 

apiVersion: v1 
kind: Pod 
metadata: 
  name: nginx-pod 
spec: 
  containers: 
  - name: nginx 
    image: nginx:latest 
     imagePullPolicy: Always 

 

2）暴露端口

containerPort <integer>：必選字段，指定在Pod對象的IP地址上暴露的 容器端口，有效範圍爲（0，65536）；使用時，應該總是指定容器應該正 常監聽着的端口。

name <string>：當前端口的名稱，必須符合IANA_SVC_NAME規範 且在當前Pod內必須是唯⼀的；此端口名可被Service資源調用。

apiVersion: v1 
kind: Pod 
metadata: 
  name: pod-example 
spec: 
  containers: 
  - name: myapp 
    image: ikubernetes/myapp:v1 
    ports： 
    - name: http 
      containerPort: 80

Pod對象的IP地址僅在當前集羣內可達，它們無法直接接收來自集羣外部客戶端的請求流量，儘管它們的服務可達性不受工作節點邊界的約束，但依然受制於集羣邊界。一個簡單的解決方案是通過其所在的工作節點的IP地址和端口將其暴露到集羣外部。

hostPort <integer>：主機端口，它將接收到的請求通過NAT機制轉發至由containerPort字段指定的容器端口。

hostIP <string>：主機端⼜要綁定的主機IP，默認爲0.0.0.0，即主機之上所有可用的IP地址；考慮到託管的Pod對象是由調度器調度運行的，工作節點的IP地址難以明確指定，因此此字段通常使⽤默認值。

需要注意的是，hostPort與NodePort類型的Service對象暴露端口的方式式 不同，NodePort是通過所有節點暴露容器服務，hostPort則是經由Pod對 象所在節點的IP地址來進行。

 

3）環境變量

 

通過環境變量配置容器化應⽤時，需要在容器配置段中嵌套使用env字段，它的值是一個由環境變量構成的列表。環境變量通常由name和value字段構成。

name<string> ：環境變量的名稱，必選字段。

value<string> ：傳遞給環境變量的值，通過$（VAR_NAME）引用，逃逸格式爲“$$（VAR_NAME）”，默認值爲空。

 

apiVersion: v1 
kind: Pod 
metadata: 
  name: pod-with-env 
spec: 
  containers: 
  - name: filebeat 
    image: ikubernetes/filebeat:5.6.5-alpine 
    env: 
    - name: REDIS_HOST 
      value: db.ilinux.io:6379
    - name: LOG_LEVEL 
      value: info 

這些環境變量可直接注如容器的shell環境中，無論它們是否真正被用到。

 

4）共享節點網路命名空間

 

同一個Pod對象的各容器均運行於一個獨立的、隔離的Network名稱空間中，共享同一個⽹絡協議棧及相關的網絡設備，也有一些特殊的Pod對象需要運行於所在節點的名稱空間中，執行系統級的管理 任務，例如查看和操作節點的⽹絡資源甚至是網絡設備等。

 

事實上，僅需要設置spec.hostNetwork的屬性爲true即可創建共享節點網絡名稱空間的Pod對象

apiVersion: v1 
kind: Pod 
metadata: 
  name: pod-use-hostnetwork 
spec: 
  containers: 
  - name: myapp 
    image: redis 
  hostNetwork: true

#創建pod
[root@node1 k8s_ymal]# kubectl apply -f pod_use_hostnet.yaml 
pod/pod-use-hostnetwork created
[root@node1 k8s_ymal]# kubectl get pod -o wide
NAME                  READY   STATUS    RESTARTS   AGE     IP              NODE            NOMINATED NODE
pod-use-hostnetwork   1/1     Running   0          2m23s   192.168.1.105   192.168.1.105   <none>
[root@node1 k8s_ymal]# kubectl delete pod pod-use-hostnetwork 
pod "pod-use-hostnetwork" deleted

5）標籤與標籤選擇器

對於附帶標籤的資源對象，可使用標籤選擇器（Label Selector）挑選出符合過濾條件的資源以完成所需要的操作，如關聯、查看和刪除等。

創建資源時，可直接在其metadata中嵌套使用“labels”字段以定義要附 加的標籤項。例如，下面的Pod資源清單文件實例pod-with-labels.yaml中使 用了兩個標籤env=qa和tier=frontend：

apiVersion: v1 
kind: Pod 
metadata: 
  name: pod-with-labels 
  labels: 
    env: qa 
    tier: frontend 
spec: 
  containers: 
  - name: myapp 
    image: ikubernetes/myapp:v1

#kubectl get pods --show-labels

Pod對象的spec.nodeSelector可用於定義節點標籤選擇器，用戶事先爲特定部分的Node資源對象設定好標籤，然後配置Pod對象通過節點標籤選 擇器進行匹配檢測，從而完成節點親和性調度。

 kubectl label nodes node01.ilinux.io disktype=ssd

apiVersion: v1 
kind: Pod 
metadata: 
  name: pod-with-nodeselector 
  labels: 
    env: testing 
spec: 
  containers: 
  - name: myapp 
    image: ikubernetes/myapp:v1 
  nodeSelector: 
    disktype: ssd 

6）存活性探測

存活性探測是隸屬 於容器級別的配置，kubelet可基於它判定何時需要重啓一個容器。 Pod spec爲容器列表中的相應容器定義其專用的探針（存活性探測機 制）即可啓用存活性探測。目前，Kubernetes的容器⽀持存活性探測的⽅ 法包含以下三種：ExecAction、TCPSocketAction和HTTPGetAction。

 

exec

apiVersion: v1 
kind: Pod 
metadata: 
  labels: 
    test: liveness-exec 
  name: liveness-exec 
spec: 
  containers: 
  - name: liveness-exec-demo 
    image: busybox 
    args: ["/bin/sh", "-c", " touch /tmp/healthy; sleep 60; rm -rf /tmp/healthy; 
sleep 600"] 
  livenessProbe: 
    exec: 
      command: ["test", "-e", "/tmp/healthy"] 
    initialDelaySeconds: 5s 
    timeoutSeconds: 2s 
    periodSeconds: 5s

http

下面是一個定義在資源清單文件liveness-http.yaml中的實例，它通過 lifecycle中的postStart hook創建了一個專專於httpGet測試的頁面文件 healthz

 

apiVersion: v1 
kind: Pod 
metadata: 
  labels: 
    test: liveness 
  name: liveness-http 
spec: 
  containers: 
  - name: liveness-http-demo 
    image: nginx:1.12-alpine 
    ports: 
    - name: http 
      containerPort: 80 
    lifecycle: 
      postStart: 
        exec: 
          command: ["/bin/sh", "-c", " echo Healthy > /usr/share/nginx/html/ 
healthz"] 
    livenessProbe: 
      httpGet: 
        path: /healthz 
        port: httpscheme: HTTP

 TCP

下面是一個定義在資源清單文件liveness-tcp.yaml中的實例，它向Pod IP的80/tcp端口發起連接請求，並根據連接建立的狀態判定測試結果

apiVersion: v1 
kind: Pod 
metadata: 
  labels: 
    test: liveness 
  name: liveness-tcp 
spec: 
  containers: 
  - name: liveness-tcp-demo 
    image: nginx:1.12-alpine 
    ports: 
    - name: http 
      containerPort: 80 
  livenessProbe: 
    tcpSocket: 
      port: http 

6）就緒性探測

Pod對象啓動後，容器應該通常需要一段時間才能完成其初始化過 程，例如加載配置或數據，甚⾄有些程序需要運行某類的預熱過程

與存活性探測機制類似，就緒性探測是用來判斷容器就緒與否的週期 性（默認週期爲10秒鐘）操作，它用於探測容器是否已經初始化完成並可服務於客戶端請求，探測操作返回“success”狀態時，即爲傳遞容器已經“就 緒”的信號

 

apiVersion: v1 
kind: Pod 
metadata: 
  labels: 
    test: readiness-exec 
  name: readiness-exec 
spec: 
  containers: 
  - name: readiness-demo 
    image: busybox 
    args: ["/bin/sh", "-c", "while true; do rm -f /tmp/ready; sleep 30; touch /tmp/ready; sleep 300; done"] 
    readinessProbe: 
      exec: 
        command: ["test", "-e", "/tmp/ready"] 
      initialDelaySeconds: 5 
      periodSeconds: 5

7）資源需求和資源限制

 

資源需求

其請求使用的CPU資源大小爲200m，這意味着一個CPU核心足以確保其以期望的最快方式運行。另外，配置清單中期望使 用的內存大小爲128Mi，不過其運行時未必真的會用到這麼多。考慮到內存爲非壓縮型資源，其超出指定的大小在運行時存在被OOM killer殺死的 可能性，於是請求值也應該就是其理想中使用的內存空間上限。

Kubernetes的調度器會根據容器的requests屬性中定義的資源需求量來判定僅哪些節點可接收運行相關的Pod資源

apiVersion: v1 
kind: Pod 
metadata: 
  name: stress-pod 
spec: 
  containers: 
  - name: stress 
    image: ikubernetes/ stress-ng 
    command: ["/usr/bin/stress-ng", "-m 1", "-c 1", "-metrics-brief"] 
    resources: 
      requests: 
        memory: "128Mi" 
        cpu: "200m"

# kubectl create -f pod-resources-test.yaml

資源限制

apiVersion: v1 
kind: Pod 
metadata: 
  name: memleak-pod 
  labels: 
    app: memleak 
spec: 
  containers: 
  - name: simmemleak 
    image: saadali/simmemleak 
    resources: 
      requests: 
        memory: "64Mi" 
        cpu: "1" 
      limits: 
        memory: "64Mi" 
        cpu: "1"