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"