k8s中Pod的理解
基本概念
Pod是Kubernetes集群中能够被创建和管理的最小部署单元,它是虚拟存在的。Pod是一组容器的集合，并且部署在同一个Pod里面的容器是亲密性很强的一组容器，Pod里面的容器，共享网络和存储空间，Pod是短暂的。
k8s中的Pod有下面两种使用方式
1、一个Pod中运行一个容器，这是最常见的用法。一个Pod封装一个容器，k8s直接对Pod管理即可；
2、一个Pod中同时运行多个容器，通常是紧耦合的我们才会放到一起。同一个Pod中的多个容器可以使用localhost通信，他们共享网络和存储卷。不过这种用法不常见，只有在特定的场景中才会使用。
k8s为什么使用Pod作为最小的管理单元
k8s中为什么不直接操作容器而是使用Pod作为最小的部署单元呢？
为了管理容器，k8s需要更多的信息，比如重启策略，它定义了容器终止后要采取的策略;或者是一个可用性探针，从应用程序的角度去探测是否一个进程还存活着。基于这些原因，k8s架构师决定使用一个新的实体，也就是Pod，而不是重载容器的信息添加更多属性，用来在逻辑上包装一个或者多个容器的管理所需要的信息。
如何使用Pod
1、自主式Pod
我们可以简单的快速的创建一个Pod类似下面：
catpod.yamlapiVersion:v1kind:Podmetadata:name:nginxspec:containers:-name:nginximage:nginx:1.14.2ports:-containerPort:80
创建
kubectlapply-fpod.yaml-nstudy-k8skubectlgetpod-nstudy-k8sNAMEREADYSTATUSRESTARTSAGEnginx1/1Running02m
自主创建的Pod,因为没有加入控制器来管理，这样创建的Pod，被删除，或者因为意外退出了，不会重启自愈，直接就会被删除了。所以，业务中，我们在创建Pod的时候都会加入控制器。
2、控制器管理的Pod
因为我们的业务长场景的需要，我们需要Pod有滚动升级，副本管理，集群级别的自愈能力，这时候我们就不能单独的创建Pod,我们需要通过相应的控制器来创建Pod,来实现Pod滚动升级，自愈等的能力。
对于Pod使用，我们最常使用的就是通过Deployment来管理。
Deployment提供了一种对Pod和ReplicaSet的管理方式。Deployment可以用来创建一个新的服务，更新一个新的服务，也可以用来滚动升级一个服务。借助于ReplicaSet也可以实现Pod的副本管理功能。
滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。
videployment.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentlabels:app:nginxspec:replicas:3selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.14.2ports:-containerPort:80
运行
kubectlapply-fdeployment.yaml-nstudy-k8skubectlgetpods-nstudy-k8sNAMEREADYSTATUSRESTARTSAGEnginx1/1Runningmnginx-deployment-66b6c48dd5-24sbd1/1Runningsnginx-deployment-66b6c48dd5-wxkln1/1Runningsnginx-deployment-66b6c48dd5-xgzgh1/1Runnings
因为上面定义了replicas:3也就是副本数为3，当我们删除一个Pod的时候，马上就会有一个新的Pod被创建。
同样经常使用的到的控制器还有DaemonSet和StatefulSet
DaemonSet：DaemonSet确保全部（或者某些）节点上运行一个Pod的副本。当有节点加入集群时，也会为他们新增一个Pod。当有节点从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。
StatefulSet：用来管理有状态应用的工作负载，和Deployment类似，StatefulSet管理基于相同容器规约的一组Pod。但和Deployment不同的是，StatefulSet为它们的每个Pod维护了一个有粘性的ID。这些Pod是基于相同的规约来创建的，但是不能相互替换：无论怎么调度，每个Pod都有一个永久不变的ID。
静态Pod
静态Pod是由kubelet进行管理的仅存在与特定node上的Pod，他们不能通过apiserver进行管理，无法与rc,deployment,ds进行关联，并且kubelet无法对他们进行健康检查。
静态Pod始终绑定在某一个kubelet，并且始终运行在同一个节点上。kubelet会自动为每一个静态Pod在Kubernetes的apiserver上创建一个镜像Pod（MirrorPod），因此我们可以在apiserver中查询到该Pod，但是不能通过apiserver进行控制（例如不能删除）。
为什么需要静态Pod?
主要是用来对集群中的组件进行容器化操作，例如etcdkube-apiserverkube-controller-managerkube-scheduler这些都是静态Pod资源。
因为这些Pod不受apiserver的控制，就不会不小心被删掉的情况，同时kube-apiserver也不能自己去控制自己。静态Pod的存在将集群中的容器化操作提供了可能。
静态Pod的创建有两种方式，配置文件和HTTP两种方式，具体参见。静态Pod的创建
Pod的生命周期
Pod在运行的过程中会被定义为各种状态，了解一些状态能帮助我们了解Pod的调度策略。当Pod被创建之后，就会进入健康检查状态，当Kubernetes确定当前Pod已经能够接受外部的请求时，才会将流量打到新的Pod上并继续对外提供服务，在这期间如果发生了错误就可能会触发重启机制。
不过Pod本身不具有自愈能力，如果Pod因为Node故障，或者是调度器本身故障，这个Pod就会被删除。所以Pod中一般使用控制器来管理Pod，来实现Pod的自愈能力和滚动更新的能力。
Pod的重启策略包括
Always只要失败，就会重启；
OnFile当容器终止运行，且退出码不是0，就会重启；
Never从来不会重启。
重启的时间，是以2n来算。比如（10s、20s、40s、…），其最长延迟为5分钟。一旦某容器执行了10分钟并且没有出现问题，kubelet对该容器的重启回退计时器执行重置操作。
管理Pod的重启策略是靠控制器来完成的。
Pod的几种状态
使用的过程中，会经常遇到下面几种Pod的状态。
Pending：Pod创建已经提交给k8s，但有一个或者多个容器尚未创建亦未运行，此阶段包括等待Pod被调度的时间和通过网络下载镜像的时间。这个状态可能就是在下载镜像；
Running：Pod已经绑定到一个节点上了，并且已经创建了所有容器。至少有一个容器仍在运行，或者正处于启动或重启状态；
Secceeded：Pod中的所有容器都已经成功终止，并且不会再重启；
Failed：Pod中所有的容器均已经终止，并且至少有一个容器已经在故障中终止；
Unkown：因为某些原因无法取得Pod的状态。这种情况通常是因为与Pod所在主机通信失败。
当pod一直处于Pending状态，可通过kubectldescribepodsnode_name-nnamespace来获取出错的信息
Pod如何直接暴露服务
Pod一般不直接对外暴露服务，一个Pod只是一个运行服务的实例，随时可能在节点上停止，然后再新的节点上用一个新的IP启动一个新的Pod,因此不能使用确定的IP和端口号提供服务。这对于业务来说，就不能根据Pod的IP作为业务调度。kubernetes就引入了Service的概念，它为Pod提供一个入口，主要通过Labels标签来选择后端Pod，这时候不论后端Pod的IP地址如何变更，只要Pod的Labels标签没变，那么业务通过service调度就不会存在问题。
不过使用hostNetwork和hostPort，可以直接暴露node的ip地址。
hostNetwork
这是一种直接定义Pod网络的方式，使用hostNetwork配置网络，Pod中的所有容器就直接暴露在宿主机的网络环境中，这时候，Pod的PodIP就是其所在Node的IP。从原理上来说，当设定Pod的网络为Host时，是设定了Pod中pod-infrastructure（或pause）容器的网络为Host，Pod内部其他容器的网络指向该容器。
catEOF./pod-host.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentlabels:app:nginxspec:replicas:1selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.14.2ports:-containerPort:80hostNetwork:trueEOF
运行
kubectlapply-fpod-host.yaml-nstudy-k8skubectlgetpods-nstudy-k8s-owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESnginx-deployment-6d47cff9fd-5bzjq1/1Running06m25s..56.kube-server8.zsnonenonecurl