pod的介绍

Pods被设计成相对短暂的、一次性的实体。 pod本身无法自我修复。如果将Pod调度到发生故障的节点，或者调度操作本身失败，则将Pod删除；同样，由于缺乏资源或Node维护，Pod也被删除。因此在Kubernetes中使用deployment、statefulset、daemonset等控制器管理pod。

查看pod的信息

[root@master ~]# kubectl explain pods
KIND:     Pod
VERSION:  v1

DESCRIPTION:
     Pod is a collection of containers that can run on a host. This resource is
     created by clients and scheduled onto hosts.

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata     <Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec <Object>
     Specification of the desired behavior of the pod. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

   status       <Object>
     Most recently observed status of the pod. This data may not be up to date.
     Populated by the system. Read-only. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

查看资源清单的举例

[root@master ~]# kubectl explain pods
	apiVersion   <string>	字符串，不包含子项
	kind <string>
	metadata     <Object>	对象，可以包含子项，子项唯一
    spec <Object>

[root@master ~]# kubectl explain pods.metadata
name <string>
namespace    <string>
labels       <map[string]string>   映射的字符串键值对列表，可以定义多个键值对

[root@master ~]# kubectl explain pods.spec
containers   <[]Object> -required-    必须有的项，对象列表，可以定义多个containers

pod的书写举例

apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: default
  labels:
    web1: tomcat
spec:
  containers:
  - name: tomcat1
   image: tomcat:8.5
   imagePullPolicy: IfNotPresent
  - name: busybox
   image: busylatest    #不能启动，没有日志，只是为了做实验使用  -c  查看tomcat的日志
   imagePullPolicy: IfNotPresent

常用的命令

查看pod的详细信息
kubectl describe pods web

删除pod
kubectl delete -f pod.yaml 

查看pod调度到哪个节点
kubectl get pods -o wide

查看pod日志
kubectl logs web

查看web这个pod里容器tomcat1的日志，你也可以通过describe这个pod来获取容器的名字
kubectl logs -c tomcat1 web

进入到刚才创建的pod，--选项终止符
kubectl exec -it web -- /bin/bash

假如pod里有多个容器，进入到pod里的指定容器，按如下命令：
kubectl exec -it web  -c tomcat1 -- /bin/bash 

Pod生命周期

同一个pod中可以运行多个容器，我们在创建一个pod时可以通过创建多个容器来实现pod的整个生命周期，一个pod的创建包含如下过程：

Init容器（也叫做初始化容器）

Init容器就是做初始化工作的容器。可以有一个或多个，如果多个按照定义的顺序依次执行，只有所有的初始化容器执行完后，主容器才启动。由于一个Pod里的存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到，Init Container可以在多种K8S资源里被使用到，如Deployment、DaemonSet, StatefulSet、Job等，但都是在Pod启动时，在主容器启动前执行，做初始化工作。

查看postStart怎么定义的，可以用如下命令：
kubectl explain pod.spec.initContainers

主容器：容器钩子

容器钩子是在pods.spec.containers.lifecycle下定义的

初始化容器启动之后，开始启动主容器，在主容器启动之前有一个post start hook（容器启动后钩子）和pre stop hook（容器结束前钩子）

postStart：该钩子在容器被创建后立刻触发，通知容器它已经被创建。如果该钩子对应的hook handler执行失败，则该容器会被杀死，并根据该容器的重启策略决定是否要重启该容器，这个钩子不需要传递任何参数

preStop：该钩子在容器被删除前触发，其所对应的hook handler必须在删除该容器的请求发送给Docker daemon之前完成。在该钩子对应的hook handler完成后不论执行的结果如何，Docker daemon会发送一个SGTERN信号量给Docker daemon来删除该容器，这个钩子不需要传递任何参数

查看postStart怎么定义的，可以用如下命令：
kubectl explain  pods.spec.containers.lifecycle.postStart

查看preStop怎么定义的，可以用如下命令：
kubectl explain  pods.spec.containers.lifecycle.preStop

容器探针：

livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success。

readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success

查看livenessProbe帮助命令：
kubectl explain pods.spec.containers.livenessProbe

查看readinessProbe帮助命令：
kubectl explain pods.spec.containers.readinessProbe

常见的pod状态

（1）Pending：挂起，我们在请求创建pod时，条件不满足，调度没有完成，没有任何一个节点能满足调度条件。已经创建了但是没有适合它运行的节点叫做挂起，调度没有完成。如pod的spec里定义了nodeSelector，nodeName参数

（2）Running：运行状态

（3）Failed异常停止：Pod 中的所有容器至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止

（4）Succeeded：表示成功状态

（5）Unknown：未知状态，所谓pod是什么状态是apiserver和运行在pod节点的kubelet进行通信获取状态信息的，如果节点之上的kubelet本身出故障，那么apiserver就连不上kubelet，得不到信息了，就会看Unknown
其他状态

Terminating 		停止中
ImagePullBackoff: 		镜像拉取失败
CrashLoopBackoff:		容器退出,kubelet正在将它重启
InvalidImageName :		无法解析镜像名称
ImageInspectError:		无法校验镜像
ErrImageNeverPull:		策略禁止拉取镜像
ImagePullBackoff:		正在重试拉取
RegistryUnavailable:		连接不到镜像中心
ErrImagePull:		通用的拉取镜像出错
CreateContainerConfigError:	不能创建kubelet使用的容器配置
CreateContainerError:	创建容器失败
internalLifecycle.PreStartContainer	执行hook报错
RunContainerError:		启动容器失败
PostStartHookError:		执行hook报错
ContainersNotInitialized :	容器没有初始化完毕ContainersNotReady:容器没有准备完毕
ContainerCreating:		容器创建中
PodInitializing:		 pod初始化中
DockerDaemonNotReady: 	docker还没有完全启动
NetworkPluginNotReady:	网络插件还没有完全启动

pod重启策略

Always：只要容器挂了就重启，默认重启策略就是Always

OnFailure：只有容器状态为错误的时候才重启

Never：从不重启容器

查看重启策略restartPolicy怎么定义的：
kubectl explain pods.spec.restartPolicy

pod label

（1）什么是标签？

标签其实就一对 key/value ，被关联到对象上，比如Pod,标签的使用我们倾向于能够标示对象的特殊特点，并且对用户而言是有意义的（就是一眼就看出了这个Pod是干什么的），标签可以用来划分特定组的对象（比如版本，服务类型等），标签可以在创建一个对象的时候直接给与，也可以在后期随时修改，每一个对象可以拥有多个标签，但是，key值必须是唯一的

（2）查看所有pod资源对象的标签

[root@master ~]# kubectl get pods --show-labels  -n kube-system
[root@master ~]# kubectl get pod --show-labels
NAME  READY  STATUS   RESTARTS  AGE  LABELS
web   1/1   Running  0      35s  web1=tomcat

查看带有指定标签的pod kubectl get pods -L web1

[root@master ~]# kubectl get pod -L web1
NAME  READY  STATUS   RESTARTS  AGE   WEB1
web   1/1   Running  0      5m29s  tomcat

查看拥有web1这个标签的资源对象，并且把标签显示出来，

[root@master ~]# kubectl get pods -l web1 --show-labels
NAME  READY  STATUS   RESTARTS  AGE   LABELS
web   1/1   Running  0      7m18s  web1=tomcat

（3）想修改资源的标签

打标签
[root@master ~]# kubectl label pods web release=new

查看标签是否打成功：
[root@master ~]# kubectl get pods --show-labels
NAME  READY  STATUS   RESTARTS  AGE  LABELS
web   1/1   Running  1      21h  release=new,web1=tomcat

删除标签
[root@master ~]# kubectl label pods web release-

（4）k8s的标签选择器：

与name和UID不同，label不提供唯一性。通常，我们会看到很多对象有着一样的label。通过标签选择器，客户端/用户能方便辨识出一组对象。

API目前支持两种标签选择器：基于等值的和基于集合的标签选择器。一个label选择器可以由多个必须条件组成，由逗号分隔。在多个必须条件指定的情况下，所有的条件都必须满足，因而逗号起着AND逻辑运算符的作用。

一个空的label选择器（即有0个必须条件的选择器）会选择集合中的每一个对象。

一个null型label选择器（仅对于可选的选择器字段才可能）不会返回任何对象。

基于等值关系的标签选择器：=、==、!=

基于相等性或者不相等性的条件允许用label的键或者值进行过滤。匹配的对象必须满足所有指定的label约束，尽管他们可能也有额外的label。有三种运算符是允许的，“=”，“==”和“!=”。前两种代表相等性（他们是同义运算符），后一种代表非相等性。例如：

environment = production tier != frontend

第一个选择所有键等于 environment 值为 production 的资源。后一种选择所有键为 tier 值不等于 frontend 的资源，和那些没有键为 tier 的label的资源。

要过滤所有处于 production 但不是 frontend 的资源，可以使用逗号操作符， environment=production,tier!=frontend

基于集合的标签选择器：in 、 notin、 exists

基于集合的label条件允许用一组值来过滤键。支持三种操作符: in ， notin ,和 exists(仅针对于key符号) 。例如：

environment in (production, qa) tier notin (frontend, backend)

第一个例子，选择所有键等于 environment ，且value等于 production 或者 qa 的资源。 第二个例子，选择所有键等于tier且值是除了frontend 和 backend 之外的资源，和那些没有label的键是 tier 的资源。 类似的，逗号操作符相当于一个AND操作符。因而要使用一个 partition 键（不管值是什么），并且 environment 不是 qa 过滤资源可以用 partition,environment notin (qa) 。

基于集合的选择器是一个相等性的宽泛的形式，因为 environment=production 相当于environment in (production) ，与 != and notin 类似。

基于集合与基于相等性的条件混合。例如：partition in (customerA,customerB),environment != qa

标签选择器根据定义的标签可以选择匹配到的资源对象

node label

（1）查看nodes节点的标签

[root@master ~]# kubectl get nodes --show-labels

（2）给node节点打标签：

[root@master ~]# kubectl label nodes node1 node011=haha
[root@master ~]# kubectl get nodes --show-labels 

（3）节点选择器nodeSelector

[root@master ~]# kubectl explain pods.spec.nodeSelector

[root@master ~]# cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: default
  labels:
    web1: tomcat
spec:
  containers:
  - name: tomcat1
    image: tomcat:8.5-jre8-alpine
  nodeSelector：
    node011：haha
#这个node011:haha标签是我们给node1节点打的
[root@master ~]# kubectl apply -f pod.yaml 

pod将运行在node1上如果node1和node2都有node011这个标签，那么nodeSelector则根据调度策略调度pod到相应的node节点上。