pod是k8s系统的基础单元，是资源对象模型中可由用户创建或部署的最小组件，也是在k8s系统上运行容器化应用的资源对象。
1. 容器与pod资源对象
单个容器通常只运行一个应用。pod是一组容器的集合，这些容器共享Network、UTS及IPC名称空间，具有相同的域名、主机名和网络接口，并可通过IPC直接通信，为一个Pod对象中的各容器提供网络名称空间等共享机制的是底层基础容器pause。
分布式系统包含以下几种模型：
1）Sidecar pattern（边车模型或跨斗模型）：即为pod的主应用容器提供协同的辅助应用容器，每个应用独立运行，最为典型的代表是将主应用容器中的日志使用agent收集至日志服务中时，可以将agent运行为辅助应用容器，即sidecar。另一个典型的应用是为主应用容器中的database server启动本地缓存。
2）Ambassador pattern（大使模型）：即为远程服务创建一个本地代理，代理应用运行于容器中，主容器的应用通过代理容器访问远程服务。
3）Adapter pattern（适配器模型）：此种模型一般用于将主应用容器中的内容进行标准化输出。
2. 镜像及其获取策略
各工作节点负责运行pod对象，而pod的核心功用在于运行容器，因此工作节点上必须配置容器运行引擎，如docker等。启动容器时，容器引擎将首先于本地查找指定的镜像文件，不存在的镜像则需要从指定的镜像存库下载至本地。
一个pod对象至少存在一个容器,containers字段在spec中必选，其中name指定容器名称，必选；image方便更高级别的管理类资源等能覆盖此字段，可选；k8s系统支持用户自定义镜像文件的获取策略，例如在网络资源比较紧张时可以禁止从仓库中获取镜像文件。容器的"imagePullPolicy"字段用于为其指定镜像获取策略，它的值包括：
Always：镜像标签为“latest”或镜像不存在时总是从指定的仓库中获取镜像。
IfNotPresent：仅当本地镜像缺失时方才从目标仓库下载镜像。
Never：禁止从仓库下载镜像，即仅适用本地镜像。
3. 暴露端口
容器的ports字段的值是一个列表，由一到多个端口组成：
containerPort：必选，指定在Pod对象的IP地址上暴露的容器端口，范围为（0,65536），使用时，应该总是指定容器应用正常监听这的端口。
name：当前端口的名称，必须符合IANA_SVC_NAME规范且在当前pod内必须是唯一的，此端口名可被service资源调用。
protocol：端口相关的协议，其值仅可为TCP或UDP，默认为TCP。
pod对象的IP地址仅在当前集群内可达，它们无法直接接收来自集群外部客户端的请求流量，尽管它们的服务可达性不受工作节点边界的约束，但依然受制于集群边界。一个简单的解决方案是通过其所在的工作节点的ip地址和端口将其暴露都集群外部。
ps: hostPort和NodePort类型的service对象暴露端口的方式不同，NodePort是通过所有节点暴露容器服务，而hostPort则是经由Pod对象所在节点的IP地址来进行。
4. 自定义运行的容器化应用
容器的command字段能够指定不同于镜像默认运行的应用程序，并且可以同时使用args字段进行参数传递，它们将覆盖镜像中的默认定义。如果仅为容器定义args字段，那么它将作为参数传递给镜像中默认指定运行的应用程序；如果仅为容器定义了command字段，那么它将覆盖镜像中定义的程序及参数，并以无参数方式运行应用程序。
5. 环境变量
非容器化的传统管理方式中，复杂应用程序的配置信息多数由配置文件进行指定，用户可借助于简单的文本编辑器完成配置管理。但容器隔离出的环境中的应用程序，用户就不得不穿透容器边界在容器内进行配置编辑并进行重载，这种方式复杂且低效。于是，由环境变量在容器启动时传递配置信息就成为一种备受青睐的方式。
通过环境变量配置容器化应用时，需要在pod对象中配置env字段：
name：环境变量的名称，必选。
value：传递给环境变量的值，通过$(VAR_NAME)引用，逃逸格式为$$(VAR_NAME)，默认值为空。
6. 共享节点的网络名称空间
同一个pod对象的各容器均运行于一个独立的、隔离的Network名称空间中，共享同一个网络协议栈及相关的网络设备。通过设置spec.hostNetwork的属性为true即可创建共享节点网络名称空间的pod对象：
spec:
...
hostNetwork: true
进入pod内会打印工作节点的网络设备及其相关的接口信息。这就意味着，Pod对象中运行的容器化应用也将监听于其所在的工作节点的ip地址之上。可以通过直接向 node3.ilinux.io节点发起请求。
还可以通过spec.hostPID和spec.hostIPC来共享工作节点的PID和IPC名称空间。
7. 设置pod对象的安全上下文
pod对象的安全上下文用于设定Pod或容器的权限和访问控制功能。pod对象的安全上下文定义在spec.securityContext字段中，而容器的安全上下文则定义在spec.containers[].securityContext字段中，且二者可嵌套使用的字段还有所不同。
8. 管理资源标签
kubectl get pods --show-labels # 显示pod的所有标签 kubectl get pods -L env,tier # 显示pod的指定标签 kubectl label pods/pod_name env=production # 为pod添加env标签 kubectl label pods/pod_name env=testing --overwrite # 为pod重新赋值，强制覆盖
9. 资源注解
kubectl annotate pod st-pgsql-o create-by="allin" # 为pod添加create-by注解 kubectl annotate pod st-pgsql-o create-by- # 为pod删除create-by注解
10. Pod对象的生命周期
pod对象的生命周期主要包括：运行初始化容器（init container）、容器启动后钩子（post start hook）、容器的存活性探测（liveness probe）、就绪性探测（readiness probe）、容器终止前钩子（pre stop hook）等。
重要行为：
1） 初始化容器
初始化容器即应用程序的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作（如等待其他关联组件服务可用、基于环境变量或配置模板为应用程序生成配置文件、从配置中心获取配置等），两种典型特征：
a.初始化容器必须运行直至完成，如果运行失败，k8s要重启它直到成功完成；
b.每个初始化容器必须按定义的顺序串行执行。
设置spec.restartPolicy为“Never”，则运行失败的初始化容器不被重启。
spec.initContainers字段设置初始化容器，类似于spec.Container
2）生命周期钩子函数
postStart：容器创建完成之后立即运行的钩子处理器，K8s无法确保它一定会于容器中的ENTRYPOINT之前运行。
preStop：容器终止操作之前立即运行，同步的方式调用，在其完成之前会阻塞删除容器的操作的调用。
钩子处理器实现方式有“EXEC”和“HTTP”，前一种是直接在当前容器运行用户的命令；后一种则是在当前容器中向某URL发起HTTP请求。
钩子函数嵌套在 “spec.lifecycle” 嵌套字段中。
3） 容器的重启策略
容器程序发生崩溃或容器申请超出限制的资源等原因都可能会导致pod对象的终止，是否应该重建pod对象则取决于其重启策略（restartPolicy）属性的定义：
Always：但凡Pod对象终止就将其重启，此为默认设定；
OnFailure：仅在Pod对象出现错误时方才将其重启；
Never：从不重启
4）设置exec探针
spec.continers.livenessProbe字段用于定义探针。