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进程),回收僵尸进程(pause是pod的父进程)

pod里面是容器,容器运行的是进程 pid
pause  父进程   1    在pod内部管理容器进程

3、创建pod时,先创建pause容器,然后拉去镜像,生成容器,形成pod

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

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

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

总结

每个pod都有一个基础容器(pause容器)

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

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

pod外在设置初始镜像(原因)

1、pod内部有一组容器,挂了一个,就算这个pod失效了吗?引入pause机制,代表整个容器组的状态,可以解决对pod内部容器整体状态的判断

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

pod的分类

1、自主式pod pod不会自我修复的,pod内容器的进程终止,被删除,缺少资源被驱逐,这个pod没有办法自愈 (deployment daemonset)

2、控制器管理pod 滚动升级,可以自愈(自动重启),可以管理pod的数量以及pod的扩缩容

pod的生命周期

1、pending 挂起状态 pod已被创建,但是尚未被分配到运行的node节点

出现pending原因
节点上资源不够,需要等待其他pod的调度

2、running 运行中,pod已经被分配到了node节点,pod内部的所有容器都已经启动,运行状态正常,稳定

3、Complete(successed) 容器内部的进程运行完毕之后,正常退出,没有发生错误

4、faild pod中的容器非正常退出,发生了错误,需要通过查看详情和日志来定位问题

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

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

k8s之Pod的基础(上)_第1张图片

初始化容器  pause

初始化容器运行完,而且时成功运行完成之后才会创建pod的业务容器

poststart和prestop(容器钩子)
poststart    表示容器运行时执行的第一个命令
prestop	容器结束时执行的最后一个命令

探针
存活探针   livnessProbe
流量探针   readnessProbe
启动探针
容器状态是否正常
存活探针和流量探针会伴随整个pod的生命周期,如果容器出了问题,pod将不在时ready状态

先有pause在创建初始化容器,初始化创建完毕之后才创建pod的业务容器
创建pod的容器分类

1、基础容器 pause

2、init容器(初始化容器) init c

3、业务容器

在master节点
创建基于
vim /opt/init.yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-init
spec:
  containers:
  - name: nginx
    image: nginx:1.22
#定义的业务容器
#定义了两个init容器,分别运行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"]
init容器的作用

环境变量

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

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

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

总结

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

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

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

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

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

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

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

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

pause容器:底层容器(基础容器),提供pod内的网络和存储共享号,以及pod内容器退出之后资源回收

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

pod的生命周期:

1、pause基础容器

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

3、poststart prestop 容器的钩子

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

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

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

你可能感兴趣的:(kubernetes,容器,云原生)