Kubernetes Pod入门

一：概念

Pod是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及运行规范。在Pod中，所有容器都被统一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器。所以，Pod是一组具有共享命名空间、IP地址和端口的容器的集合。

1:从使用的角度来看

在实际的使用时，单个容器是无法单独来支撑我们的应用的，往往需要很多微服务才能组成一个系统，并且还会存在A服务依赖B服务，B服务需要和C服务共用某个目录。另外，在使用裸容器时，很难实现对容器内进行健康检查以及横向扩容等操作，而Pod可以轻松解决这些问题。

2:从Kubernetes的角度来看

Docker只是容器Runtime(运行时)的一种们还有很多容器Runtime,比如Rkt、CRI-O等，而Kubernetes作为目前最流行的容器编排工具，需要支持各个Runtime并且不依赖于底层Runtime的实现技术，于是就抽象出了Pod这个概念，用于管理多个紧密相连的符合CRI标准的容器。

Pod可以简单的理解为一组、一个或多个容器，每个Pod还包含一个Pause容器，Pause容器是Pod的父容器，主要负责僵尸进程的回收管理。同时，通过Pause容器可以使同一个Pod里面的不同容器共享存储、网络、PID、IPC等，容器之间可以使用Localhost:Port的方式相互访问，可以使用volume实现数据共享。根据Docker的构造，Pod可以被创建为一组具有共享命名空卷、IP地址和端口的容器。

Pod有两个必须知道的特点：

网络：每一个Pod都会被指派一个唯一的Ip地址，在Pod中的每一个容器共享网络命名空间，包括Ip地址和网络端口。在同一个Pod中的容器可以同locahost进行互相通信。当Pod中的容器需要与Pod外的实体进行通信时，则需要通过端口等共享的网络资源。
存储：Pod能够被指定共享存储卷的集合，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据。存储卷也允许在一个Pod持久化数据，以防止其中的容器需要被重启。 

二：Pod的状态 

(1)kubectl命令创建pod

kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx"

(2)查看pod

kubectl get pods -n default

(3)显示Pod的更多信息

kubectl get pod nginx -o wide

 (4)查看pod日志

cur110.244.58.195
kubectl logs nginx

(5)以yaml格式显示Pod详细信息

kubectl get pod nginx -o yaml

(6)显示资源的详细描述信息 

kubectl describe pod nginx

备注：

kubect.l  get:常用于查看同一资源类型的一个或多个资源对象，可以使用-o参数自定义输出格式。
kubectl describe:侧重于描述指定资源的各方面的详细信息，不仅会返回节点信息，还会返回在其上运行的Pod的摘要、节点事件等信息。

 (7)在Pod的容器中执行命令

kubectl exec nginx -c nginx -date

备注：
-c:指定Pod中容器的名字

 (8)登录到Pod中的容器中

kubectl exec -it nginx -c nginx -bash

备注：
kubectl exec -it nginx --bash
如果登录的时候不指定容器，就登录到Pod中的第一个容器中。

(9)在线编辑运行中的资源对象

kubectl edit pod nginx

(10)将pod的端口映射到宿主机 

kubectl port-forward --address 0.0.0.0 pod/nginx 8080:80
Forwarding from 0.0.0.0:8080 -80

注意：
此命令会在前台运行，此时就可以在其他客户端用该k8s主机的IP地址和8080的端口号进行访问了，Ctrl+c停止，但停止后就没有这个映射了

(11)在宿主机和Pod的容器之间拷贝文件

kubectl cp nginx:etc/fstab /opt/aaa.txt
kubectl cp /opt/aaa.txt nginx:etc/bbb.txt

(12)Pod的状态

kubectl get pods -n default

可以看到此时的Pod的状态是Running,Pod的状态不仅仅只有Running,常见的其他状态如下表所示： 

Pod状态字段Phase(阶段)的不同取值
状态    说明
pending（挂起）    Pod已经被Kubernetes系统接收，但是仍有一个或多个容器未被创建，可以通过kubectl describe查看处于Pending状态的原因。
Running（运行中）    Pod己经被绑定到一个节点上，并且所有的容器都已经被创建，而且至少有一个是运行的状态、正在启动或者重启，可以通过kubectl logs查看Pod的日志。
Succeeded    所有容器执行成功，并终止，并且不会再次重启，可以通过kubectl logs查看Pod的日志
Failed（失败）    所有容器都已终止，并且至少一个容器以失败的方式终止，也就是说这个容器要么以非零状态退出，要么被系统终止，可以通过logs和describe查看Pod的日志和状态
Unknown（未知）    通常是由于通信问题造成的无法获得Pod的状态
ImagePullBackoff
ErrImagePull    镜像拉取失败，一般是由于镜像不存在、网络不通或者需要登录认证引起的，可以使用describe命令查看具体的原因
CrashLoopBackoff    容器启动失败，可以通过logs命令查看具体的原因，一般为启动命令不正确、健康检查不通过等原因
OOMKilled    容器内存溢出，一般是容器的内存Limit设置的过小，或者程序本身有内存溢出，可以通过logs查看程序的启动日志
Terminating    Pod正在被删除，可以通过describe查看状态
SysctlForbiden    Pod自定义了内核配置，但kubectl没有添加内核配置或配置的内核参数不支持，可以通过describe查看具体原因
Completed    容器内部主进程退出，一般计划任务执行结束会显示该状态，此时可以通过logs查看容器日志
ContainerCreating    Pod正在创建，一般正在下载镜像，或者有配置不当的地方，可以通过describe查看具体原因

 (13)删除Pod

kubectl delete pod nginx

 三：Pod探针

在生产环境中，进程正常启动并不代表应用能正常处理请求，所以合理的设计应用的健康检查尤其重要。在使用裸机或裸容器部署时，一般很难对应用做很完善的健康检查，而Pod提供的探针可以很方便的用来检测容器的应用是否正常。目前探针有3种检测方式，可以根据不同的场景选择合适的健康检查方式。检查方式如下表所示。

Pod探针的实现方式
实现方式说明
ExecAction 在容器内执行一个指定的命令，如果命令返回值为0，则认为容器健康
TCPSocketAction    通过TCP连接检查容器指定的端口，如果端口开放，则认为容器健康
HTTPGetAction    对指定的URL进行Get请求，如果状态码在200-400之间，则认为容器健康
 上述的检查方式可以被周期性的执行，每次检查容器后可能得到的容器状态如下表所示。

Pod探针检查容器后可能得到的状态
状态                           说明
Success（成功）    容器通过检查
Failure（失败）    容器检查失败
Unknown（未知）    诊断失败，因此不采取任何措施
Pod探针有三类，分别是：livenessProbe（存活探针)、readinessProbe（就绪探针)、startupProbe(启动探针)。

livenessProbe(存活探针)：判断容器是否正常运行，如果失败则杀掉容器（不是pod),再根据重启策略决定是否重启容器
readinessProbe(就绪探针)：判断容器是否能够进入ready状态，探针失败则进入noready状态，并从service的endpoints中剔除此容器
startupProbe(启动探针)：判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态

四：Pod镜像拉取策略和重启策略

镜像拉取策略
操作方式    说明
Always    总是拉取，无论镜像是否存在，总是拉取
Never    无论是否存在都不拉取
IfNotPressent    镜像不存在时拉取镜像，是k8s默认的策略，但是如果tag为latest,则总是拉取
指定拉取策略：
kubectl run nginx  --image=nginx:1.7.9 --labels="app=nginx"  --image-pull-policy=Never

Pod重启策略
操作方式    说明
Always    默认策略，容器失效时，自动重启该容器
OnFailure    容器以不为0的状态码终止，自动重启该容器
Never    无论何种状态，都不会重启
指定重启策略：
kubectl delete pod nginx
kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx"--restart=OnFailure

五：Pod文件语法

(1)Pod文件的一级属性

一级属性主要包含5部分：

apiVersion<string>版本，由kubernetes内部定义，版本号必须可以用kubectl  api-versions查询到
kind <string>类型，由kubernetes内部定义，版本号必须可以用kubectl  api-resources查询到
metadata<Object>元数据，主要是资源标识和说明，常用的有name、namespace、labels等
spec<Object>描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述
status<Object>状态信息，里面的内容不需要定义，由kubernetes自动生成

(2)spec(规格)属性

在一级属性中，spec是研究的重点，它的常见子属性有：

containers<[ ]Object>容器列表，用于定义容器的详细信息
nodeName<String>根据nodeName的值将pod调度到指定的Node节点上
nodeSelector<map[]>根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node上
hostNetwork<boolean>是否使用主机网络模式，默认为false,如果设置为true,表示使用宿主机网络
volumes<[ ]Object>存储卷，用于定义Pod上面挂在的存储信息
restartPolicy<string>重启策略，表示Pod在遇到故障的时候的处理策略

(3)通过kubectl  explain命令来查看每种资源的可配置项

kubect1 explain pod
kubectl explain deployment
kubectl explain service
kubectl explain pod.metadata
kubectl explain pod.spec.containers
备注：
查看某种资源可以配置的一级属性
#kubectl explain资源类型
查看属性的子属性
#kubectl explain资源类型.属性

4:运行kubect!create命令创建此Pod

kubectl create -f frontend-localredis-pod.yaml

5:查看已经创建的Pod

kubectl get pods

6:查看pod详细创建信息

kubectl describe pod redis-php

7:删除pod 

kubectl delete -f frontend-localredis-pod.yaml

六：Pod启动阶段（相位phase）

Pod创建完之后，一直到持久运行起来，中间有很多步骤，也就有很多出错的可能，因此会有很
多不同的状态
1:pod的启动过程包含的步骤
(1)调度到某台node上。kubernetes根据一定的优先级算法选择一台node节点将其作为Pod运行的node
(2)拉取镜像
(3)挂载存储配置等
(4)运行起来。如果有健康检查，会根据检查的结果来设置其状态

2:phase的可能状态
(1)Pending:表示APIServer创建了Pod资源对象并己经存入了etcd中，但是它并未被调度完成（比如还没有调度到某台node上），或者仍然处于从仓库下载镜像的过程中
(2)Running:Pod已经被调度到某节点之上，并且Pod中所有容器都已经被kubelet创建。至少有一个容器正在运行，或者正处于启动或者重启状态（也就是说Running状态下的Pod不一定能被正常访问)
(3)Succeeded:有些pod不是长久运行的，比如job、cronjob,一段时间后Pod中的所有容器都被成功终止，并且不会再重启。需要反馈任务执行的结果

(4)Failed:Pod中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止，比如command写的有问题
(5)Unknown:表示无法读取Pod状态，通常是kube-contro1ler-manager无法与Pod通信