Pod简介
Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。
一个Pod封装一个应用容器，Pod代表部署的一个单位。
Pods提供两种共享资源：网络和存储。
网络：每个Pod被分配一个独立的IP地址，Pod中的每个容器共享网络命名空间，包括IP地址和网络端口。
存储：Pod可以指定一组共享存储volumes。Pod中的所有容器都可以访问共享volumes，允许这些容器共享数据。
Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。
POD生命周期
Pod 的 status 定义在 PodStatus 对象中，其中有一个 phase 字段。
- 挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。
- 运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
- 成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。
- 失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
- 未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。
容器存活探针
探针 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。
- ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
- TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
- HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
livenessProbe：指示容器是否正在运行。
readinessProbe：指示容器是否准备好服务请求。
诊断结果状态：
- 成功：容器通过了诊断。
- 失败：容器未通过诊断。
- 未知：诊断失败，因此不会采取任何行动。
重启策略
PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always，意味着容器在探测失败时被杀死并重新启动。
给容器和Pod分配内存资源
配置内存申请和限制
memory-request-limit.yaml
apiVersion: v1
kind: Pod
metadata:
name: memory-demo
spec:
containers:
- name: memory-demo-ctr
image: vish/stress
resources:
limits:
memory: "200Mi"
requests:
memory: "100Mi"
args:
- -mem-total
- 150Mi
- -mem-alloc-size
- 10Mi
- -mem-alloc-sleep
- 1s
创建一个容器的Pod，这个容器申请100M的内存，并且内存限制设置为200M,args代码段提供了容器所需的参数。-mem-total 150Mi告诉容器尝试申请150M 的内存。
在mem-example命名空间中创建pod：
# kubectl create -f memory-request-limit.yaml --namespace=mem-example
验证Pod的容器是否正常运行:
# kubectl get pod memory-demo --namespace=mem-example
查看Pod的详细信息:
# kubectl get pod memory-demo --output=yaml --namespace=mem-example
-----------------
...
resources:
limits:
memory: 200Mi
requests:
memory: 100Mi
...
POD实际使用内存约为150M。
删除Pod:
# kubectl delete pod memory-demo --namespace=mem-example
当创建POD时内存超出限制内存，则POD会被kill掉，reason: OOMKilled。
当创建POD时内存超出节点能力范围时，Pod的状态是Pending，因为Pod不会被调度到任何节点，它会一直保持在Pending状态下，因为节点上没有足够的内存。
如果没有内存限制，则容器使用内存资源没有上限，容器可以使用当前节点上所有可用的内存资源。
给容器和Pod分配CPU资源
给容器声明CPU限制
cpu-request-limit.yaml
apiVersion: v1
kind: Pod
metadata:
name: cpu-demo
spec:
containers:
- name: cpu-demo-ctr
image: vish/stress
resources:
limits:
cpu: "1"
requests:
cpu: "0.5"
args:
- -cpus
- "2"
会创建一个只有一个容器的Pod，这个容器申请0.5个CPU，并且CPU限制设置为1. cpus "2"代码告诉容器尝试使用2个CPU资源。
在cpu-example命名空间中创建pod:
# kubectl create -f cpu-request-limit.yaml --namespace=cpu-example
验证Pod的容器是否正常运行:
# kubectl get pod cpu-demo --namespace=cpu-example
查看Pod的详细信息:
# kubectl get pod cpu-demo --output=yaml --namespace=cpu-example
--------------
resources:
limits:
cpu: "1"
requests:
cpu: 500m
当创建的pod申请的CPU资源超过集群node所提供的资源，那么pod会一直处于Pending状态，那是因为这个Pod并不会被调度到任何节点上，所以它会一直保持这种状态。
如果你指定容器的CPU限额，则容器使用CPU资源没有上限，它可以使用它运行的Node上所有的CPU资源。
通过环境变量向容器暴露 Pod 信息
使用 Pod 字段作为环境变量的值
dapi-envars-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-envars-fieldref
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "sh", "-c"]
args:
- while true; do
echo -en '\n';
printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;
printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;
sleep 10;
done;
env:
- name: MY_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: MY_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: MY_POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: MY_POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: MY_POD_SERVICE_ACCOUNT
valueFrom:
fieldRef:
fieldPath: spec.serviceAccountName
restartPolicy: Never
env 字段是 EnvVars 的数组。数组中的第一个元素指定 MY_NODE_NAME 环境变量从 Pod 的 spec.nodeName 字段中获取其值。字段是 Pod 的字段，不是 Pod 中的容器的字段。
创建pod：
# kubectl create -f dapi-envars-pod.yaml
查看容器日志：
# kubectl logs dapi-envars-fieldref
-------------
minikube
dapi-envars-fieldref
default
172.17.0.48
default
配置文件的 command 和 args 字段。当容器启动时，它将 5 个环境变量的值写到标准输出中。每十秒钟重复一次。
进入容器内查看环境变量：
MY_POD_SERVICE_ACCOUNT=default
...
MY_POD_NAMESPACE=default
MY_POD_IP=172.17.0.4
...
MY_NODE_NAME=minikube
...
MY_POD_NAME=dapi-envars-fieldref
使用容器字段作为环境变量的值
dapi-envars-container.yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-envars-resourcefieldref
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox:1.24
command: [ "sh", "-c"]
args:
- while true; do
echo -en '\n';
printenv MY_CPU_REQUEST MY_CPU_LIMIT;
printenv MY_MEM_REQUEST MY_MEM_LIMIT;
sleep 10;
done;
resources:
requests:
memory: "32Mi"
cpu: "125m"
limits:
memory: "64Mi"
cpu: "250m"
env:
- name: MY_CPU_REQUEST
valueFrom:
resourceFieldRef:
containerName: test-container
resource: requests.cpu
- name: MY_CPU_LIMIT
valueFrom:
resourceFieldRef:
containerName: test-container
resource: limits.cpu
- name: MY_MEM_REQUEST
valueFrom:
resourceFieldRef:
containerName: test-container
resource: requests.memory
- name: MY_MEM_LIMIT
valueFrom:
resourceFieldRef:
containerName: test-container
resource: limits.memory
restartPolicy: Never
env 字段是 EnvVars 的数组。数组中的第一个元素指定 MY_CPU_REQUEST 环境变量从名为 test-container 的容器的 requests.cpu 字段中获取其值。类似地，其他环境变量从容器字段中获取它们的值。
创建pod，查看pod日志：
# kubectl create -f dapi-envars-container.yaml
# kubectl logs dapi-envars-resourcefieldref
--------------
1
1
33554432
67108864
原文地址：https://www.cnblogs.com/aresxin/p/Kubernetes-Pod.html