pod是kubernetes最重要的基本概念，它是kubernetes系统中最小的调度单位。每一个pod都有一个特殊的pause根容器，kubernetes为每个pod都提供了一个根容器，如果单独对一组容器进行管理，那么一个容器死亡，到底算不算整体死亡，为了解决这个难题，巧妙的设计了pause根容器对业务容器进行管理，所有的业务容器共享pause容器的IP、挂载的volume，简化了容器之间的通信问题。
pod分为普通的pod和静态pod。普通pod一旦被创建，就会被放入etcd中存储，随后被kubernetes master调度到node上进行绑定，接着pod被node上的kubelet进程实例化成一组相关的docker容器并启动。静态pod比较特殊，它并不存储在etcd里，而是被保存在某个具体node上的一个具体文件中。

pod管理

Pod在kubernetes中也是一种资源，pod资源的定义是通过“apiVersion”、“kind”、“metadata”、“spec”、“status”五个部分组成，除了“status”字段中的信息是系统自动生成外，其余各字段都需要管理员定义。
（1）Containers中关于容器的字段常用字段有：
1）name：必选字段，用于指定容器名称
2）image：可选字段，定义容器运行时的镜像，但是自助式pod不能省略此字段
3）imagePullPolicy：用于指定镜像的获取策略，主要的值有：
Always：当镜像不存在或不是最新镜像时，则从指定仓库中拉取镜像
IfNotPresent：当需要运行的镜像在本地不存在时，则从指定的仓库中下载镜像
Nerver：仅使用本地镜像，不去仓库中下载镜像
（2）暴露pod中服务的端口
Containers字段中的ports字段用于暴露容器的端口，容器的ports字段的值是一个列表，由一到多个端口对象组成，常用的嵌套字段如下：
1）containerPort：必选字段，指定在Pod对象的ip地址上暴露的容器端口
2）name：当前容器端口的名称，需在当前pod中唯一，此端口可以被Service资源调用
3）protocol：端口相关的协议，值为tcp或udp
Pod对象的ip地址仅可在当前集群内可达，集群外是无法访问的，当集群外需要访问pod中的服务时，可定义node节点的IP地址及端口，将pod中的服务端口映射到node上，外部通过node节点访问，一般都不建议这样做，常用的做法是通过service的NodePort模式访问pod内的服务
4）hostPort：主机端口
5）hostIP：主机端口要绑定主机ip

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: twf/nginx:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
      protocol: TCP

（3）为pod的容器定义环境变量

apiVersion: v1
kind: Pod
metadata:
  name: env-test
  labels:
    app: env
spec:
  containers:
  - name: nginx-env
    image: twf/nginx:v1
    ports:
    - name: http
      containerPort: 80
    env:
    - name: NGINX_ENV
      value: 'twf-v1'
    - name: NGINX_PORT
      value: '80'

（4）为pod容器共享节点的网络名称空间
通过hostNetwork设置true

apiVersion: v1
kind: Pod
metadata:
  name: hostnetwork
  labels:
    app: hostnetwork
spec:
  containers:
  - name: nginx-hostnetwork
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
  hostNetwork: true

#node节点查看暴露的服务
netstat -anpt |grep 80

（5）pod资源中安全设置
Pod对象的安全定义在spec.securityContext字段中，容器的安全定义在spec.containers.securityContext字段中

apiVersion: v1
kind: Pod
metadata:
  name: test-busybox
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["/bin/sh","-c","sleep 3600"]
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      allowPrivilegeEscalation: false

kubectl exec test-busybox -it -- ps

pod中标签与标签选择器的定义与管理

Pod中标签（label）的主要功能就是对pod进行分类管理，从而提升运维及管理效率；而标签选择器（label selector）则可以挑选出符合过滤条件的资源完成需要的操作。
标签是键值类型的数据，能够附加于kubernetes的任何资源对象上，标签可以在创建资源时指定也可以按需添加，一个对象可以拥有多个标签。
（1）pod资源的标签管理
Pod资源的标签在metadata.labels中定义

#在pod资源中定义标签
apiVersion: v1
kind: Pod
metadata:
  name: test-nginx
  labels:
    env: dev
    version: v1.0
spec:
  containers:
  - name: nginx
    image: nginx
#查看所有的标签
kubectl get pods --show-labels
#列出有指定标签的资源信息
kubectl get pods -L env

当pod创建好之后，也可以通过“kubectl label”命令为pod资源添加标签，如果pod中已经有了指定键名的标签，可以通过“–overwrite”命令强制覆盖原有标签

#为指定pod资源添加标签
kubectl label pods test-nginx app=cache
#修改指定pod资源标签
kubectl label pods test-nginx env=pro --overwrite

（2）标签选择器的使用
标签选择器用于表达标签的查询条件或选择标准，在使用标签选择器时，要注意多个选择器之间的关系为“与”操作，使用空值的标签选择器意味着每个资源对象都被选中，空的标签选择器无法选出任何内容。

#列出app不等于cache的资源
kubectl get pods -l "app!=cache" --show-labels
#列出标签app不等于cache且run等于nginx-deploy的pod资源
kubectl get pods -l "app!=cache,run=nginx-deploy" -L run,app

kubernetes api支持基于等值关系和集合关系的选择器，基于集合关系的标签选择器支持in、notin、exists三种操作符。

#列出标签app为cache或者backend的pod资源
kubectl get pods -l "app in (cache,backend)" -L app
#列出不等于env标签的pod资源
kubectl get pods -l "!env" --show-labels

Pod节点选择器

Pod节点选择器nodeSelector能够让pod对象基于集群中的工作节点的标签来挑选运行pod的node节点。在使用pod节点选择器之前，需要为node资源添加标签，添加标签的方法同为pod资源添加标签方法相同。

#为两个node节点分别添加标签
kubectl label nodes k8s-node1 server=nginx

Pod资源中定义节点选择器时通过spec.nodeSelector字段定义

#定义一个pod资源，让其运行在node1节点上
apiVersion: v1
kind: Pod
metadata: 
  name: test-nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.12
  nodeSelector:
    server: nginx

Pod资源注解

除了标签之外，Pod与其他各种资源还能使用资源注解（annotation）；与标签类似，注解也是通过键值类型的数据，注解仅用于为资源提供元数据信息。而资源的注解可由用户手动添加，也可由工具程序自动附加使用。
（1）管理资源注解
资源注解的创建可在定义资源时使用metadata.annotations字段指定，也可在资源创建后通过“kubectl annotate”命令进行附加。

#定义资源时添加资源注解
apiVersion: v1
kind: Pod
metadata:
  name: test-annotation
  labels:
    env: dev
  annotations:
    server-explain: nginx server is node1
spec:
  containers:
  - name: nginx
    image: nginx:1.12
  nodeSelector:
    server: nginx
    
#为创建好的资源添加资源注解
kubectl annotate pods test-annotation auth="123"

（2）查看资源注解
资源注解的查看可以通过“kubectl describe”查看，或者pod导出为yaml格式查看

#查看资源注解
kubectl describe pods test-annotation

Pod资源存活性检测

kubernetes对容器的存活性检测能够发现不可能用状态的容器，并对该容器进行重启等操作。jubernetes存活性探测的主要方法有ExecAction、TCPSocketAction、HTTPGetAction。
（1）使用exec探针检测容器的存活性
Exec探针通过在目标容器中执行由用户自定义的命令来判断容器的健康状态，exec探针由“spec.containers.livenessProbe.exec”字段组成，该字段只有一个“command”属性来定义要执行的命令。

apiVersion: v1
kind: Pod
metadata:
  name: test-exec
spec:
  containers:
  - name: busybox
    image: busybox
    args: ["/bin/sh","-c","touch /tem/test123;sleep 60;rm -rf /tem/test123;sleep 300"]
    livenessProbe:
      exec:
        command: ["test","-f","/tem/test123"]

#一段时间后查看pod重启情况
kubectl get pods

（2）使用http探针
基于http的探测是向目标容器发起一个http请求，根据其相应码进行结果的判定，该字段通过“spec.containers.livenessProbe.httpGet”字段定义，相关的字段有：
1）port：必选字段，用于定义请求的端口
2）httpHeaders：自定义的请求报文首部
3）path：请求http资源的路径
4）scheme：建立连接使用的协议，默认为http

apiVersion: v1
kind: Pod
metadata:
  name: test-http
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - name: http
      containerPort: 80
    lifecycle:
      portStart:
        exec:
          command: ["/bin/sh","-c","echo testhttp > /usr/share/nginx/html/testhttp"]
  livenessProbe:
    httpGet:
      port: http
      path: /testhttp
      scheme: HTTP

（3）使用TCP探针
基于TCP的存活性探测是用于向容器的特定端口发起TCP请求并尝试建立连接建立结果判定。该探针的使用主要是通过“spec.containers.livenessProbe.tcpSocket”字段来定义。主要字段有：
1）host：请求连接的目标IP地址，默认为Pod ip
2）port：必选字段，请求连接的目标端口

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  labels:
    app: web
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 20

（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为成功状态转为失败状态时的探测失败次数。

Pod的就绪性探测

Pod的就绪性探测主要用于在探测到容器尚未就绪时，触发依赖于其就绪状态的操作，确保不会有客户端请求接入此pod操作。就绪性探测也支持Exec、HTTP GET和TCP Socket三种探测方式。就绪性探测的使用方法同存活性探测使用方法基本相同，就绪性探测主要通过“pod.spec.containers.readinessProbe”字段设置
在未定义就绪性的Pod对象在Pod进入Running状态后将立即就绪

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  labels:
    app: web
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 20