pod详解

发布和yaml文件的初步了解。

pod环节；

pod的生命周期

kubectl get cs

kubectl get node

kubectl get pod -n kube-system

kubectl create deployment nginx2  --image=nginx:1.22  --replicas=1

kubectl get pod 查看是否能正常创建pod

检查环境

pod是什么？

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

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

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

在一个pod当中运行一个容器是最常用的方式。

在一个pod当中同时运行多个容器，在一个pod当中可以同时封装几个需要耦合的互相协作的容器。

这些多个容器共享资源，也可以互相协作组成一个service单位。

不论运行一个容器还是多个容器，k8s管理的都是pod而不是容器。

一个pod内的容器，必须都运行在同一个节点上。基于现代容器技术的要求，一个pod运行一个容器，一个容器只运行一个进程。横向扩展，方便扩缩容。

解耦：一个pod内运行多个容器，耦合度太高，一旦一个进程失败，整个pod将全部失败。

（一个pod只运行一个容器）实现解耦，基于一个pod可以创建多个副本，实现高可用和负载均衡。

管理方便，简单直观。

pause

pod内的容器可以共享资源。共享机制：pause底层基础容器来提供共享资源的机制。

pause容器是基础容器，也可以成为父容器。管理pod内容器的共享操作。

pause还可以管理容器的生命周期。

k8s提供了pause容器

1、为pod内的所有容器提供一个命名空间

2、启动容器的pid命名空间，每个pod中都作为pid为1的进程（init进程。所有pod的父进程），回收僵尸进程。

也就是pause进程是这个pod内的所有进程的父进程

pod里面是容器，容器运行的是进程   每个进程都有pid

pause  父进程  1   在pod内部管理容器的进程。

3、创建pod时，先创建pause容器，然后拉取镜像，生成容器，形成pod。

由pause提供pod的基础环境

LNMP

Linux  pause容器

n

m

p 都运行在Linux系统上

注：kubelet来管理node节点，节点上的容器还是它来管理

pause的作用是管理pod内的容器

第一步：master节点发出指令，pod使用的镜像nginx，pod的副本数

第二步：kube-scheduler来分配执行的node节点

第三步：node节点的kubelet收到master指令

第四步：pause容器先启动，提供命名空间，进程管理pid1  来为pod内的容器提供共享服务以及容器的进程管理。

pause内的容器共享两种资源

网络：

每个pod都会被分配一个集群内部的唯一ip地址。和pod内的容器共享网络，pod在集群内部的ip地址和端口

pod内部的容器可以使用localhost互相通信。pod中的容器服务与外部通信时，从共享的资源当中进行分配，宿主机的端口映射。

共享网络就是pod和容器共享一个ip地址

10:05

pause管理内部的pid 1

存储：

pod可以指定多个共享的volume，pod内的容器共享这些volume。

volume可以是实际数据的持久化。

防止pod重新构建之后文件消失。

总结：

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

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

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

docker images

每个集群上都有pause

服务由容器来提供，应用程序由容器来提供

容器内部的网络由kube-proxy管理，kubelet负责拉取镜像

kube-controller-manager 端点控制器来分配ip地址

pod外再设置一个初始镜像的原因：

1、pod内部有一组容器，挂了一个，就算整个pod失效了吗？引入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、failed：pod中的容器非正常退出。发生了错误，需要通过查看详情和日志来定位问题。

5、UnKown：由于某些原因，k8s集群无法获取pod的状态。APIserver出了问题

6、terminating：终止中，pod正在被删除，里面的容器正在终止。终止过程中，资源回收，垃圾清理，以及终止过程中需要执行的命令。

初始化容器

基础容器                                                                poststart：表示容器运行时，执行的第一条命令

pause                                                                     prestop：  容器结束时，执行的最后一条命令

                                                                               容器钩子                        

                                探针：探测pod内部的容器状态是否正常                                

                                liveness：存活探针（伴随整个pod的生命周期，随时检测容器的健康状态）

                                readiness：流量探针

                                启动探针

                                                                 如果容器出了问题，pod将不再是ready状态

只有初始化容器运行完毕，而且是成功运行完毕之后，才会创建pod业务容器

创建pod的容器分类：

1、基础容器：pause

2、init容器（初始化容器）：init C

1和2这个过程中，pod的状态就是init：0/3  1/3  2/3  3/3

3、业务容器

定义一个业务容器

vim init.yaml

apiVersion:v1

kind:  pod

metadata:

  name:  nginx-init

spec:

  containers:

  -  name:  nginx

     image:  nginx:1.22

#定义的业务容器

#定义了两个init容器，创建完pause之后。分别运行centos  centos1之后，才会拉起nginx。

  initContainers：

    -  name:  init-centos

       image:centos:7

       command:["echo","hello,world"]

    -  name：init-centos1

       images：centos:7

      command:["echo","I am ready"]

init容器的作用：

环境变量

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

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

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

总结：init容器提供了应用容器运行之前的先决条件，提供了一种阻塞或者延迟机制来控制应用容器的启动。

只有前置条件满足，才会创建pod的应用容器。

k8s的一种机制：

88+88+88

88*3

Temminated：运行完容器之后即终止

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

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

3、所有的init容器没有成功之前，pod是不会进入ready状态的。

init容器与server无关。不能对外提供访问。

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

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

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

vim init.yaml

apiVersion:  v1

kind:  Pod

metadata:

  name:centos

spec:

  restartPolicy: Always Never OnFailure

k8s的pod的重启策略（基于容器的状态）：

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

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

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

#在deployment的YAML文件当中，重启的策略只能是always，可以不写

  containers:

  -  name：centos

     image：centos:7

     command：["echo","I am ready"]

补充：pod的重启策略针对的是pod内的所有的容器，也就是全部重启

vim init1.yaml

apiVersion:  apps/v1

kind:  Deployment

metadata:

  name:centos

  labels:

     wdf:  test

spec:

  replicas:  1

  selector:

    matchLabels:

      wdf:  test

    template:

      metadata:

        labels:

           wdf:  test

       spec:

         containers:

          -  name:  centos1

             image:  centos:7

             command：["echo","123"]

总结：

pause容器：底层容器/基础容器

提供pod内容器的网络和存储共享，以及pod内容器退出之后的资源回收。

init容器：人为设定的，业务容器启动之前的必要条件。

pod的声明周期：

1、pause基础容器

2、init容器---------全部成功退出----------业务容器

3、poststart  prestop   容器的钩子

启动时命令和退出时的命令

4、探针：探测容器的健康状态。伴随pod的整个声明周期（除了启动探针）。

总结：pod就是来封装容器的，业务是容器。服务也是容器。端口也是容器。