k8s的pod基础

pod:pod是k8s中最小的资源管理组件。

pod也是最小化运行容器化的应用的资源管理对象。

pod是一个抽象的概念，可以理解为一个或者多个容器化应用的集合。

在一个pod当中运行一个容器是最常用的方式。在一个pod当中同时运行多个容器，在一个pod当中可以同时封装几个需要耦合的互相协作的容器。这些多个容器共享资源，也可以互相协作组成一个service单位。不论运行一个容器还是多个容器，k8s管理的都是pod而不是容器。

一个pod内的容器，必须都运行在同一节点。基于现代容器技术的要求，一个pod运行一个容器，一个容器只运行一个进程。横向扩展，方便扩缩容
解耦，一个pod内运行多个容器，耦合度太高，一旦一个进程失败，整个pod将全部失败。实现解耦，基于pod可以创建多个副本实现高可用和负载均衡。
管理方便，简单直观。

pod内的容器共享资源。共享机制：pause底层基础容器来提供共享资源的机制。
pause是基础容器，也可以称为父容器。管理pod内容器的共享操作。
pause还可以管理容器的生命周期。

k8s提供了pause容器
1、为pod内的所有容器提供一个命名空间
2、启动容器的pid命名空间，每个pod中都作为pid为1的进程（init进程），回收僵尸进程。
3、创建pod时，先创建pause容器，然后拉取镜像，生成容器，形成pod。

pause容器共享两种资源

网络：

每个pod都会被分配一个集群内部的唯一ip地址。pod内的容器共享网络，pod在集群内部的ip地址和端口。pod内部的容器可以使用localhost互相通信。pod的中容器与外部通信时，从共享的资源当中进行分配。宿主机的端口映射。
存储：

pod可以指定多个共享的volume,pod内的容器共享这些volume。
volume可以是实现数据的持久化。
防止pod重新构建之后文件消失。

总结：

每个pod都有一个基础容器pause容器。

pause容器对应的镜像属于k8s集群的一部分。创建集群就会有pause这个基础镜像。

pod里面包含了一个或者多个相关的容器（应用）

pod外再设置一个基础镜像的原因：

1、在一组容器作为一个单元的情况下，难以对整体的容器简单地进行判断及有效地进行行动。比如，一个容器死亡了，此时是算整体挂了么?那么引入与业务无关的Pause容器作为Pod的基础容器，以它的状态代表着整个容器组的状态，这样就可以解决该问题。

2、pod内的容器共享IP共享volume,解决了容器内网络通信的问题，解决了容器内部文件共享的问题。

pod的分类：

自主式pod：pod不会自我修复，pod内容器的进程终止，被删除，缺少资源被驱逐，这个pod没有办法自愈。deployment daemanset。
控制器管理pod：滚动升级，可以自愈（自动重启），可以管理pod的数量以及pod的扩缩容。

pod的生命周期：

1、pending 挂起
pod已被创建，但是尚未被分配到运行的node节点。（节点上资源不够，需要等待其他pod的调度）
2、running：运行中，pod已经被分配到了node节点，pod内部的所有容器都已经启动，运行状态正常，稳定。
3、complete：容器内部的进程运行完毕，正常退出。没有发生错误。
? ? ?successded:
4、faild:pod中的容器非正常退出。发生了错误，需要通过查看详情和日志来定位问题。5、UNkown:由于某些原因，k8s集群无法获取pod的状态。APlserver出了问题
6、terminating:终止中，pod正在被删除，里面的容器正在终止。终止过程中，资源回收，垃圾清理，以及终止过程中需要执行的命令。

创建pod的容器分类：

1.基础容器：pause

2.init容器（初始化容器）：init c1和2这个过程中。pod的状态init：3/3

3、业务容器

init容器的作用：

1.环境变量可以在创建的过程中为业务容器定制好相关的代码和工具。

2.init容器独立与业务容器，他是单独构建的一个镜像，对业务容器不产生任何安全影响。

3.init容器能以不同于pod内应用容器的文件系统视图运行。secrets的权限。 应用容器无法访问secerts的权限。

总结：init容器提供了应用容器运行之前的先决条件，提供了一种阻塞或者延迟机制来控制应用容器的启动。只有前置条件满足，才会创建pod的应用容器。

1、在pod的启动过程中，容器时按照初始化容器先启动，每个容器必须在下一个容器启动之前，要成功退出。

2、如果运行失败，会按照容器的重启策略进行指定动作，restartPolicy Always never onFailure(非正常退出才会重启）

3、所有的init容器没有成功之前，pod是不会进入ready状态的。init容器与service无法。不能对外提供访问。

4、如果重启pod，所有的init容器一定会重新执行。

5、如果修改init容器的spec(参数),只限制于image,其他的修改字段都不生效（基于deployment)。

6、每个容器的名称都要唯一，不能重复。

总结

pause容器：底层容器/基础容器
提供pod内容器的网络和存储共享，以及pod内容器退出之后资源回收。
init容器：人为设定的，业务容器启动之间的必要条件。
pod的生命周期：
1、pasue基础容器
2、init容器----全部成功退出-------业务容器
3、poststart prestop 容器的钩子
启动时命令和退出时的命令
4、探针：探测容器的健康状态。伴随pod的整个生命周期（除了启动探针）。
总结：pod就是用来封装容器的，业务是容器。服务也是容器。端口也是容器。

?编写业务容器加初始化容器的demo：

vim nginx_init.yaml?
apiVersion: v1
kind: Pod
metadata:
? name: myapp01
? namespace: default
spec:
? containers:
? - image: nginx:1.41
? ? name: nginx
? ? ports:
? ? - containerPort: 80
? ? ? protocol: TCP
? initContainers:
? - name: init-test1
? ? image: busybox:1.28
? ? command: ['sh', '-c', "until nslookup test1 ; do echo waiting is for ?test1 && sleep 5 ; done " ]
? - name: init-test2
? ? image: busybox:1.28
? ? command: ['sh', '-c', "until nslookup test2 ; do echo waiting is for ?test2 && sleep 5 ; done " ]
?
?
kubectl apply -f nginx_init.yaml?

Always：只要容器退出，总是重启，无论容器的状态码是否正常。默认策略，可以不加

Never：只要容器退出，不论是否正常，都不重启

OnFailure：只要容器的转态码非0才会重启，正常退出不重启。