pod的相关知识

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

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

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

k8s中pod的两种使用方式

(1)一个pod中运行一个容器。"每个po中一个容器"的模式是最常见的用法:在这种使用方式中,你可以把pod想象成是单个容器的封装,kterentes管理的是Pod而不是直接管理容器。

(2)在一个Pod中同时运行多个容器。一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器,它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个servie单位。

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

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

一个pod内的多个容器,必须都运行在一个节点上。基于现在容器技术的要求,一个pod运行一个容器,一个容器只运行一个进程。这样做是为了:横向扩展,方便扩缩容。解耦。一个pod内会运行多个容器,耦合度太高,导致整个集群全部失败。实现解耦,基于pod可以创建多个副本,实现高可用和负载均衡。

管理方便,简单直观。

pod内的容器共享资源,共享机制:pause

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

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

k8s提供了pause容器

pause作用

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

2.启动容器的pid命名空间,每个pod中都作为pid为1的进程(init进程),回收僵尸进程。

3.创建pod时,先创建pause容器,然后再拉取镜像,生成容器,形成pod

pid为1,是所有进程的父进程。
每创建好一个pod就会自动生成一个pause。

k8s创建pod的工作流程

  • 第一步:master节点发出指令,pod使用的镜像nginx,pod的副本数。
  • 第二步:kube-scheduler来分配执行的node节点。
  • 第三步:node节点的kubelet收到master,拉pause,拉nginx:1.22 pod1
  • 第四步:pause容器先启动,提供命名空间,进程管理管理pid1,来为pod内的容器提供共享服务以及容器的进程管理

pause容器共享两种资源

1.网络资源:

每个pod都会分配一个集群内部的唯一IP地址,pod内的容器共享。pod在集群内部的IP地址和端口。

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

2.存储资源

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

volume可以实现数据的持久化。

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

pause总结:

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

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

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

pod外再设置一个初始镜像:

1.pod内部都有一组容器,挂了一个,就算pod失效了吗?引入pause机制,代表整个容器组的状态。

可以解决pod内部容器整体的状态判断。

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

举个不太恰当的例子:kubelect相当于市长,pause相当于区长。kubelect发布指令创建pod,创建pod的具体操作通过pause来完成。pause管理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.UNknow:

因为某些原因,k8s集群无法获取pod的状态。APIserver出了问题。

  • 6.terminating :

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

创建pod的容器分类

1.基础容器:pause

2.init容器(初始化容器):init c

1和2这个过程中,pod的状态就算init:0/3

3.业务容器

(绿---》蓝---》黄)

init容器的作用:环境变量

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

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

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

总结init:

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

只有前置条件满足,才会创建Pod内的应用容器。

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

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

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

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

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

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

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

实验模拟

cd /opt
vim init.yaml

aplVersion: v1
kind: Pod
metadata: 
  name: nginx-init
spec:
  containrts:
  - 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
    image: centos:7
    command: ["echo","I am ready"]

wq

kubectl apply -f init.yaml
kubectl describe pod nginx-init
kubectl get pod -o wide

aplVersion: v1
kind: Pod
metadata: 
  name: centos
spec:
  restartPolicy: onFailure
#k8s的pod的重启策略
#always:只要容器退出总是重启,无论容器的状态码是否正常。默认策略,可以不加(默认)
#never:只要容器退出,不论是否正常,都不重启
#onFailure:只有状态码非0,才会重启
#在deployment的yaml文件当中,退出策略只能是always
  containers:
  - name: centos
    image: centos:7
    command: ["echo","I am ready"]

wq

pod的重启策略

  • always:只要容器退出总是重启,无论容器的状态码是否正常。默认策略,可以不加(默认)
  • never:只要容器退出,不论是否正常,都不重启
  • onFailure:只有状态码非0,才会重启

pod的重启策略的对象是整个pod集群!

总结:

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

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

init容器:人为设定的,业务容器启动之间的必要条件。

pod的生命周期:

1.pause基础容器

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

3.portstart prestop 容器的钩子

启动时命令 和 退出时命令

4.探针:探测容器的健康状态。伴随pod的生命周期(除了启动探针)

容器重启策略

pod用来封装容器,业务是容器,服务也是容器,端口也是容器。

k8s每日检查

kubectl get cs
kubectl get node
kubectl get pod -n kube-system

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐