Pod是kubernetes系统中的最小调度单元，也是基础单元，而其他的大多数资源对象都是用于支撑和扩展pod对象功能的。而pod的创建可以通过命令创建或者将pod资源定义为资源清单，再通过定义的清单创建。
一、通过命令创建pod
通过命令创建的pod的为自主式pod,不受pod控制器的管理，创建的语法格式为：
kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=bool]
二、通过资源配置清单的方式创建
Pod在kubernetes中也是一种资源，pod资源的定义也是通过”apiVersion”、”kind”、”meadata”、”spec”、”status”五个字段组成，除”status”字段中的信息为系统自动生成外，其余各字段都需要管理员定义。
1、pod中容器的管理
Pod中容器的定义主要是在spec字段下的containers字段下定义，containers字段是定义pod时其嵌套字段spec中的必选项，用于为pod指定要创建的容器列表。
（1）Containers中关于容器的字段中常用字段有：
1）name：必选字段，用于指定容器名称
2）image：为可选字段，定义容器运行时的镜像，但是自助式的pod不能省略此字段。
3）imagePullPolicy：用于指定镜像的获取策略，主要的值有：
Always：当镜像不存在时或不是最新镜像时则从指定的仓库中去拉去镜像
IfNotPresent：当需要运行的镜像在本地不存在时则从指定的仓库中下载镜像
Nerver：仅使用本地镜像，不去仓库中下载镜像
（2）暴露pod中服务的端口
Containers字段中的ports字段用于暴露容器的端口，容器的ports字段的值是一个列表，由一到多个端口对象组成，常用的嵌套字段如下：
1）containerPort：为必选字段，指定在Pod对象的的ip地址上暴露的容器的端口。
2）name：当前端口端口名称，需在当前pod中唯一，此端口可被Serviece资源调用。
3）protocol：端口相关的协议，值为tcp或udp
Pod对象的ip地址仅可在当前集群内可达，集群外是无法访问，当集群外需要访问pod中的服务时,可定义node节点的IP地址及端口，将pod中服务端口映射到node上，外部通过node节点访问；一般都不建议这样做，常用的做法是通过service的NodePort模式访问pod内的服务。
4）hostPort：主机端口
5）hostIP：主机端口要绑定主机的ip
# 定义一个pod资源指定镜像以及端口
[root@master01 test01]# cat test03.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-nginx
spec:
containers:
- name: nginx-test01
image: nginx:1.12
ports:
- name: http
containerPort: 80
protocol: TCP
hostPort: 33333
（3）定义pod中容器的运行程序及指令
运行docker容器时运行的应用程序由Dockerfile中ENTRYPOINT指令定义，传递的参数则通过CMD指令指定，ENTRYPOINT不存在时，CMD可用于同时指定程序和参数。而kubernetes中containers字段中的command字段能够指定不同于镜像默认运行的应用程序，可通过args字段传参，并会覆盖镜像中的默认定义；如果只定义了command字段，则会覆盖镜像中的默认指定及参数，如果只定义了args字段，则会将参数传递到容器中。
（4）为pod中的容器定义环境变量
Docker中程序的配置文件可以通过配置环境变量或者将配置文件挂载到宿主机上实现一个容器在不同的场景下使用不同的配置文件。Kubernetes中也已通过配置环境变量为Pod中容器传递参数。Kubernetes中的环境变量由containers中得evn字段定义；环境变量通常由name和value字段构成。
# 创建一个运行mysql数据库的pod资源并通过环境变量设置密码
[root@master01 test01]# cat test05.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-env
spec:
containers:
- name: mysql-env
image: mysql
env:
- name: "MYSQL_ROOT_PASSWORD"
value: "123456"
# 创建pod
[root@master01 test01]# kubectl apply -f test04.yaml
pod/test-env created
# 查看pod中容器的环境变量
[root@master01 test01]# kubectl exec -it test-env -- printenv
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=test-env
TERM=xterm
MYSQL_ROOT_PASSWORD=123456
（5）设置pod中容器共享节点网络名称空间
Kubernetes中有一些pod中的容器需要共享节点的名称空间，比如通过kubeadm部署的kubernetes集群中的kube-apiserver、kube-scheduler等需要共享节点的名称空间，执行系统及的管理任务。如果pod中的容器需要共享节点的网络名称空间只需设置spec.HostNetwork的属性为true即可。同时，还可通过设置”spec.hostPID”及”spec.hostIPC”共享工作节点的PID及IPC。
# 定义一个运行tomcat容器的pod资源，共享节点的网络名称空间
[root@master01 test01]# cat test06.yaml
apiVersion: v1
kind: Pod
metadata:
name: tomcat-net
spec:
containers:
- name: tomcat-hostnet
image: tomcat
hostNetwork: true
# 创建pod
[root@master01 test01]# kubectl apply -f test06.yaml
# 查看node监听的端口
[root@node01 ~]# lsof -i :8080
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 29856 root 56u IPv6 2949386 0t0 TCP *:webcache (LISTEN)
（6）pod资源中安全设置
Pod对象的安全上下文定义在spec.securityContext字段中，容器的安全定义在spec.containers[].securityContest字段中，各字段的具体用法可通过”kubectl explain”命令查看。
# 创建一个pod资源并以非root用户运行容器中服务
[root@master01 test01]# cat test07.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-sec
spec:
containers:
- name: busybox-sec
image: busybox
command: ["/bin/sh","-c","sleep 3600"]
securityContext:
runAsNonRoot: true
runAsUser: 1000
allowPrivilegeEscalation: false
[root@master01 test01]# kubectl exec -it test-sec -- ps
PID USER TIME COMMAND
1 1000 0:00 sleep 3600
2、pod中标签与标签选择器的定义与管理
Pod中label（标签）的主要功能就是对pod进行分类管理，从而提升运维及管理效率；而标签选择器（label selector）则可以挑选出符合过滤条件的资源完成需要的操作。
标签是键值类型的数据，能够附加于kubernetes的任何资源对象上，标签可以在创建资源时指定也可按需添加，一个对象可以拥有多个标签。
（1）pod资源的标签管理
Pod资源的标签在metadata.labels中定义。
# 在pod资源中定义标签
[root@master01 test01]# cat test08.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-labels
labels:
env: dev
version: v1.0
spec:
containers:
- name: nginx-labels
image: nginx:1.12
在pod定义了标签创建资源后，就可以通过标签筛选需要的资源。
# 查看所有的标签
[root@master01 test01]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deploy-54b5756c7-jrvhk 1/1 Running 0 3d21h pod-template-hash=54b5756c7,run=nginx-deploy
pod-example 1/1 Running 1 46h <none>
test-env 1/1 Running 0 3h13m <none>
test-labels 1/1 Running 0 22s env=dev,version=v1.0
# 列出有指定标签的资源信息
[root@master01 test01]# kubectl get pods -L env
NAME READY STATUS RESTARTS AGE ENV
nginx-deploy-54b5756c7-jrvhk 1/1 Running 0 3d21h
pod-example 1/1 Running 1 46h
test-env 1/1 Running 0 3h15m
test-labels 1/1 Running 0 2m37s dev
当pod创建好之后，可以通过”kubectl label”命令为pod资源添加标签，如果pod中已经有了指定键名的标签，可以通过”--overwrite”命令强制覆盖原有的标签。
# 为指定的pod添加新的标签
[root@master01 test01]# kubectl label pods test-labels app=cache
pod/test-labels labeled
# 修改指定pod的标签
[root@master01 test01]# kubectl label pods test-labels env=production --overwrite
pod/test-labels labeled
（2）标签选择器的使用
标签选择器用于表达标签的查询条件或选择标准，在使用标签选择器时，要注意多个选择器之间的关系为“与”操作，使用空值得标签选择器意味着每个资源对象都被选中，空的标签选择器无法选出任何内容。
# 列出app不等于cache的资源
[root@master01 test01]# kubectl get pods -l "app!=cache" --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deploy-54b5756c7-jrvhk 1/1 Running 0 3d21h pod-template-hash=54b5756c7,run=nginx-deploy
pod-example 1/1 Running 1 47h <none>
test-env 1/1 Running 0 3h39m <none>
# 列出标签app不等于cach且run等于nginx-deploy的pod资源
[root@master01 test01]# kubectl get pods -l "app!=cache,run=nginx-deploy" -L run,app
NAME READY STATUS RESTARTS AGE RUN APP
nginx-deploy-54b5756c7-jrvhk 1/1 Running 0 3d21h nginx-deploy
kubernetes api支持基于等值关系和集合关系的的选择器，基于集合关系的标签选择器支持in、notin、和exists三种操作符。
# 列出标签app为cache或者backend的pod资源
[root@master01 test01]# kubectl get pods -l "app in (cache,backend)" -L app
NAME READY STATUS RESTARTS AGE APP
test-labels 1/1 Running 0 35m cache
# 列出不存在env标签的资源
[root@master01 test01]# kubectl get pods -l '!env' --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deploy-54b5756c7-jrvhk 1/1 Running 0 3d22h pod-template-hash=54b5756c7,run=nginx-deploy
pod-example 1/1 Running 1 47h <none>
test-env 1/1 Running 0 3h53m <none>
3、Pod节点选择器
Pod节点选择器nodeSelector能够让Pod对象基于集群中的工作节点的标签来挑选运行pod的node节点。在使用pod节点选择器之前需要为node资源添加标签，添加标签的方法同为pod资源添加标签的方法相同。
# 为两个node节点分别添加标签
[root@master01 test01]# kubectl label nodes node01.dayi123.com server=nginx
node/node01.dayi123.com labeled
[root@master01 test01]# kubectl label nodes node02.dayi123.com server=tomcat
node/node02.dayi123.com labeled
pod资源中定义节点选择器时通过spec.nodeSelector字段定义。
# 定义一个pod资源，让其运行在node1节点上
[root@master01 test01]# cat test09.yaml
apiVersion: v1
kind: Pod
metadata:
name: node-select-test
labels:
env: dev
spec:
containers:
- name: nginx-slect
image: nginx:1.12
nodeSelector:
server: nginx
4、pod资源注解
除了标签之外，Pod与其他各种资源还能使用资源注解（annotation）；与标签类似，注解也是键值类型的数据，注解仅用于为资源提供元数据信息。而资源的注解可由用户手动添加，也可由工具程序自动附加并使用。
（1）管理资源注解
资源注解的创建可在定义资源时使用metadata.annotations字段指定，也可在资源创建后通过”kubectl annotate”命令进行附加。
# 定义资源时添加资源注解
[root@master01 test01]# cat test10.yaml
apiVersion: v1
kind: Pod
metadata:
name: annotation-test
labels:
env: dev
annotations:
server-explain: tomcat server is node02
spec:
containers:
- name: tomcat-node02
image: tomcat
# 为创建好的资源添加资源注解
[root@master01 test01]# kubectl annotate pods annotation-test auth="dayi123"
（2）查看资源注解
资源注解的查看可以通过”kubectl desribe”查看，或者pod导出为yaml格式查看。
# 查看资源注解
[root@master01 test01]# kubectl describe pods annotation-test
Name: annotation-test
Namespace: default
Priority: 0
PriorityClassName: <none>
Node: node01.dayi123.com/192.168.17.197
Start Time: Fri, 11 Jan 2019 02:45:07 -0500
Labels: env=dev
Annotations: auth: dayi123
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"server-explain":"tomcat server is node02"},"labels":{"env":"dev"},"name":"anno...
server-explain: tomcat server is node02
5、pod的生命周期
Pod对象自从创建开始到终止退出的时间范围称为pod的生命周期，这段时间内pod会处于多种不同的状态并执行一些操作。
（1）pod生命周期中的重要行为
1）初始化容器
2）生命周期的钩子函数
3）容器的探测
（2）容器的重启策略
当pod中的容器程序发生崩溃或容器申请超出限制的资源时都可能会导致pod对象的终止，而pod终止后是否应该重建pod对象取决于重启策略restartPolicy属性定义。定义该属性的字段为spec.restartPolicy，主要有如下的值：
1）Always：只要pod对象终止就将其重启，该值为默认值
2）OnFailure：仅在Pod对象出现错误时将其重启
3）Nerver：从不重启
6、Pod资源存活性检测
Kubernetes对容器的存活性检测能够发现不可能用状态的容器，并对该容器进行重启等操作。Kubernetes存活性探测的主要方法有ExecAction、TCPSocketAction、HTTPGetAction。
（1）使用exec探针检测容器的存活性
Exec探针通过在目标容器中执行由用户自定义的命令来判断容器的健康状态，exec探针由”spec.containers.livenessProbe.exec”字段定义，该字段只有一个”command”属性来定义要执行的命令。
# 使用exec探针，检测文件是否存在，文件不存在时该pod会被重启
[root@master01 test01]# cat test11.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: lineness-exec
name: lineness-exec
spec:
containers:
- name: test-lineness-exec
image: busybox
args: ["/bin/sh","-c","touch /tmp/test123;sleep 60 ;rm -rf /tmp/test123;sleep 300"]
livenessProbe:
exec:
command: ["test","-f","/tmp/test123"]
# 一段时间后，查看pod时发现该pod的已经被重启了两次
[root@master01 test01]# kubectl get pods
NAME READY STATUS RESTARTS AGE
lineness-exec 1/1 Running 2 4m20s
（2）使用http探针
基于http的探测是向目标容器发起一个http请求，根据其响应码进行结果的判定，该字段通过”spec.containers.livenessProbe.httpGet”字段定义，相关的字段有：
1）port：必选字段，用于定义请求的端口
2）httpHeaders：自定义的请求报文首部
3）path：请求的http资源路径，
4）scheme：建立连接使用的协议，默认为http
# 使用http探针检测指定页面是否存在
[root@master01 test01]# cat test12.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-http
spec:
containers:
- name: test-lineness-http
image: nginx:1.12
ports:
- name: http
containerPort: 80
lifecycle:
postStart:
exec:
command: ["/bin/sh","-c","echo testhttp >/usr/share/nginx/html/testhttp"]
livenessProbe:
httpGet:
path: /testhttp
port: http
scheme: HTTP
（3）使用TCP探针
基于TCP的存活性探测是用于向容器的特定端口发起TCP请求并尝试建立连接进行结果判定。该探针的使用主要是通过”spec.containers.livenessProble.tcpSocket”字段来定义。主要的字段有：
1）host：请求连接的目标IP地址，默认为Pod ip
2）port：必选字段，请求连接的目标端口。
（4）存活性探测的行为属性
除了个探测器的自身字段属性为，还可以配置一些其他的行为属性，其他的行为属性字段在”spec.containers.livenessProbe”字段下设置，主要有：
1）initialDelySeconds：设置存活性探测的延迟时长，即容器启动多久之后开始第一次探测，默认为0。
2）timeoutSeconds：存活性探测的超时时长，，默认为1s,最小值也为1s.
3）periodSeconds：存活性探测的频度，默认为10s,最小可设置为1s
4）successThreshold：处于失败状态时，探测器操作连续多少次的成功才被认为是通过检测，默认为1
5）failureThreshold：处于成功状态时，探测操作至少连续多少次的失败才被视为是检测不通过。默认为3
这些属性设置后都可以通过” kubectl describe”命令查看，各项设置在该命令输出的liveness字段中，delay为存活性探测的延迟时长，timeout为存活性探测的超时时长，period为存活性探测的频率，success为失败状态转为成功状态时的探测成功次数，failure为成功转失败是的探测失败次数。
Liveness: http-get http://:http/testhttp delay=0s timeout=1s period=10s #success=1 #failure=3
7、Pod的就绪性探测
Pod的就绪性探测主要用于在探测到容器尚未就绪时，触发依赖于其就绪状态的操作，确保不会有客户端请求接入此pod操作。就绪性探测也支持Exec、HTTP GET和TCP Socket三种探测方式。就绪性探测的使用方法同存活性探测的使用方法基本相同，就绪性探测主要通过”pod.spec.containers.readinessProbe”字段来设置。
在未定义就绪性探测的Pod对象在Pod进入“Running”状态后将立刻就绪。