k8s之pod

1、pod:k8s中最小的资源管理组件,最小化运行容器化应用的资源管理对象

(1)pod是一个抽象的概念,可以理解为一个或者多个容器化应用的集合
(2)一个pod中运行一个容器是最常用的方式
(3)一个pod中同时运行多个容器,在一个pod中可以同时封装多个需要耦合的互相协作的容器,这些多个容器共享资源,互相协作组成一个service单位
(4)一个pod内的容器,必须都运行在一个node节点上,基于现代容器技术的要求,就是一个pod运行一个容器一个容器只运行一个进程
①横向扩展,方便扩缩容
②解耦,一个pod内运行多个容器耦合度太高,一旦一个进程失败,整个pod将全部失败,实现解耦,基于pod可以创建多个副本,实现高可用和负载均衡
③管理方便,简单直观
(5)不论运行一个或者多个容器,k8s管理的都是pod而不是容器

2、pod内的容器共享资源(共享机制)

(1)共享机制:pause底层基础容器来提供共享资源的机制
①pause是基础容器,也可以称为父容器,管理pod内容器的共享操作
②pause还可以管理容器的生命周期
(2)k8s提供了pause容器(pause的作用)
①为pod内的所有容器提供了统一的命名空间
②启动容器的pid命名空间(进程号),每个pod中,pause都作为pid为1的进程(init进程),可回收僵尸进程(pause作为所有容器进程的父进程,管理pod内部的容器进程)
③创建pod时,先创建pause容器,然后再拉取镜像生成容器,最后形成pod(pause来分配和回收容器的资源

(3)kubelet和pause

①kubelet管理node节点上的容器的生命周期,pause管理pod中的容器

k8s之pod_第1张图片

(4)设置基础镜像pause的作用
①引入pause机制,代表整个容器组的状态,可以解决对pod内部容器整体状态的判断
②pod内的容器共享ip、volume挂载卷,解决了容器内网络通信的问题,解决了容器内部文件共享的问题
(5)pause容器共享两种资源

网络资源

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

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

存储资源

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

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

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

k8s之pod_第2张图片

3、总结

(1)每个pod都有一个基础容器,pause容器
(2)pause容器对应的镜像属于k8s集群的一部分,创建集群就会有pause这个基础镜像
(3)pod里面包含了一个或者多个相关的容器(应用)

4、pod的分类

自主式pod

此类pod不会自我修复,若pod内容器的进程终止或被删除、缺少资源被驱逐,这种pod没有办法自愈

控制器管理pod

能滚动升级、自愈(自动重启)、管理pod的数量以及pod的扩缩容

5、pod的生命周期(重点)

pod生命周期的状态:

pending

挂起,pod已被创建,尚未被分配到运行的node节点(原因:节点上资源不够、需要等待其他pod的调度)

running

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

complete/

successded

容器内部的进程运行完毕,正常退出,没有发生错误

failed

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

unknow

由于某些原因,k8s集群无法获取pod的状态,一般是APIserver出现问题

terminating

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

crashloopbackoff

pod当中的容器退出,kubelet正在重启

imagepullbackoff

正在重试拉取镜像(网络问题/镜像仓库挂了)

errimagepull

拉取镜像出错(网速太慢/镜像名称写错/镜像仓库挂了)

Evicte

pod被驱赶(node节点的资源不够部署pod,或者是资源不足,kubelet自动选择一个pod驱逐)

k8s之pod_第3张图片

6、创建pod的容器分类

(1)基础容器:pause container
(2)init容器(初始化容器):init container(init容器运行完即被终止)
①前两个过程中,pod的状态是init:3/3,才会进入业务容器

init容器的作用

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

 检测依赖环境

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

• init容器能以不同于pod内业务容器的文件系统试图运行,secrets的权限,业务容器无法访问secrets的权限

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

(3)业务容器:main container

7、pod容器创建的过程(实例)

k8s之pod_第4张图片

k8s之pod_第5张图片

k8s之pod_第6张图片

(1)pod创建过程的总结

①在pod的启动过程中,容器按照:初始化容器先启动,每个容器必须在下一个容器启动之前成功退出
②如果运行失败,会按照容器的重启策略进行指定动作,restartPolicy(always、never、onfailure—非正常退出才会重启)
③所有的init容器没有成功之前,pod是不会进入ready状态的,init容器与service无关,不能对外提供访问
如果重启pod,所有的init容器一定会重新执行
⑤如果修改init容器的spec(参数),只限制于image,其他的修改字段都不生效(基于deployment)
⑥每个容器的名称都要唯一,不能重复

8、k8s的pod的重启策略(基于容器的状态,针对pod内的所有容器)

(1)三种重启策略(docker的重启策略和pod的重启策略的对比

k8s的pod的重启策略(重)

Always

deployment的yaml文件只能是Always,pod的yaml三种模式都可以。不论正常退出还是非正常退出都重启

On Failure

只有状态码非0才会重启,正常退出是不重启的

Never

正常退出和非正常退出都不重启

容器退出了,pod才会重启,pod可以有多个容器,只要有一个容器退出,整个pod都会重启,pod内的所有容器都会重启

docker的重启策略(重)

Never

docker的默认策略

On-failure

非正常退出,才会重启容器

unless-stopped

只要容器退出就会重启,docker的守护进程启动时,已经停止的容器不再重启

always

只要容器退出就会重启

单机部署;docker

集群化部署容器:k8s(至少3个节点)

k8s之pod_第7张图片

(2)On Failure策略
①状态码正常

k8s之pod_第8张图片

k8s之pod_第9张图片

②状态码不正常

k8s之pod_第10张图片

k8s之pod_第11张图片

k8s之pod_第12张图片

9、总结

(1)pause容器:底层容器/基础容器
①pause提供pod内容器的网络和存储共享,以及pod内容器退出之后的资源回收
(2)init容器:人为设定的,业务容器启动之前的必要条件
(3)pod的生命周期
①第一步:起pause基础容器
②第二步:init容器全部成功退出,才起业务容器
③poststart、prestop:容器的钩子
④探针:探测容器的健康状态,伴随pod的整个生命周期(除了启动探针)
(4)pod就是用来封装容器的,业务是容器,服务也是容器,端口也是容器

10、yaml文件快速生成(生成特定的模版)

(1)生成deployment的模版:kubectl create deployment nginx1 --image=nginx:1.22 --replicas=3 --dry-run=client -o yaml > /opt/test1.yaml

--dry-run=client

只是调用api的对象不执行命令

k8s之pod_第13张图片

(2)生成pod的模版:kubectl run nginx1 --image=nginx:1.22 --dry-run=client -o yaml > /opt/test1-pod.yaml

(3)生成service的模版:kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort --dry-run=client -o yaml > /opt/test1-service.yaml

11、pod内的容器使用节点资源的限制

(1)request:需要的资源
(2)limit:最高能占用系统多少资源(限制)
①生产中设置limit,需要多少,最多也只能占用多少
(3)k8s中pod的资源限制(两个限制):CPU、内存

创建pod时,一定要给容器设置资源限制

CPU限制:

CPU的限制格式:1、2、0.5、0.2、0.3(要么是整数,要么是小数点后只能跟一位)

①单位:m(millicores)来表示CPU,CPU的时间分片原理

②CPU时间分片:通过周期性的轮流分配CPU时间给各个进程,多个进程可以在CPU上交替执行,在k8s中就是表示占用CPU的比率

1000m:表示一个CPU

④100m就是最小单位:0.1

1

可占用1个CPU

0.5

可占用半个CPU

0.2

可占用一个CPU的五分之一

0.1

是最小单位

内存限制:单位Ki、Mi、Gi、Ti

(4)实例

k8s之pod_第14张图片

(5)问题:centos7默认没有持久化命令,默认运行一次即退出,要加command

k8s之pod_第15张图片

k8s之pod_第16张图片

k8s之pod_第17张图片

(6)测试

k8s之pod_第18张图片

k8s之pod_第19张图片

k8s之pod_第20张图片

k8s之pod_第21张图片

k8s之pod_第22张图片

12、镜像的拉取策略

IfNotPresent

默认策略,如果本地镜像已经存在,就不再拉取,本地没有才回去镜像仓库拉取——适用于外部部署,事前要把docker的镜像导入到目标主机

Always

不论镜像是否存在,创建时(重启)都会重新拉取镜像——一般不用

Never

仅仅使用本地镜像,本地没有也不会主动拉取——适用于本地部署

k8s之pod_第23张图片

(1)设置镜像拉取策略

k8s之pod_第24张图片

13、pod的容器健康检查(探针probe—重点

(1)探针:k8s对容器执行的定期检查、诊断,探针将伴随整个容器的生命周期
(2)探针的三种规则(三种方式)

①存活探针(livenessProbe):探测容器是否正常运行

• 如果发现探测失败会杀掉容器,容器会根据重启策略来决定是否重启,不是杀掉pod

检测失败后,会杀死容器,然后重启

②就绪探针:探测容器是否进入ready状态,并做好接受请求的准备

探测失败,ready 0/1,没有进入ready状态。service会把这个资源对象的端点从当中剔除,service也不会把请求转发到这个pod

③启动探针:只在容器启动时探测

• 只是在容器的启动后开始检测,容器内的应用是否启动成功。在启动探测成功之间,所有的其他探针都会处于禁用状态,但是一旦启动探针结束,后续的操作不再受启动探针的影响。在一个容器当中可以有一个或者多个探针。

所有探针策略,伴随整个pod的生命周期,除了启动探针

(3)probe的检测方法

probe的检测方法(适用于上述三种探针)

exec

在容器内部执行命令,如果命令的返回码是0,表示成功

适用于需要在容器内自定义命令来检查容器的健康状态

httpGet

对外部容器发起了一次get请求,可以添加path,指定访问的资源,返回码在200<=x<400之间(200<=x<400),都表示成功

适用于检查容器能否响应http的请求,web容器(Tomcat、nginx等等)

tcpSocket

端口,对指定端口上的容器的IP地址进行tcp检查(三次握手)

相当于telnet,检测指定容器的监听端口是否打开,能否和指定的容器监听端口进行通信,端口打开就认为探测成功

适用于检查特定容器的端口监听状态

诊断结果

成功,容器通过了,正常运行

失败,存活探针会重启

未知状态,诊断失败

(4)exec检测(以存活探针为例)

①检测正常

k8s之pod_第25张图片

k8s之pod_第26张图片

k8s之pod_第27张图片

②检测不正常
删除文件:kubectl exec -it centos-6d4764b9df-mpzmf -- rm -rf /opt/1.txt

k8s之pod_第28张图片

(4 )以存活探针为例:检测失败后,会杀死容器,然后重启
①exec检测
• 检测正常

k8s之pod_第29张图片

k8s之pod_第30张图片

k8s之pod_第31张图片

• 检测不正常
删除文件:kubectl exec -it centos-6d4764b9df-mpzmf -- rm -rf /opt/1.txt

k8s之pod_第32张图片

②httpGet检测(以存活探针为例)
• 检测正常

k8s之pod_第33张图片

k8s之pod_第34张图片

k8s之pod_第35张图片

• 检测不正常

k8s之pod_第36张图片

k8s之pod_第37张图片

k8s之pod_第38张图片

• 指定path,指定访问的资源
不正常的状态:

k8s之pod_第39张图片

k8s之pod_第40张图片

k8s之pod_第41张图片

正常的状态:

k8s之pod_第42张图片

k8s之pod_第43张图片

k8s之pod_第44张图片

③tcpSocket检测(以存活探针为例)
• 正常状态

k8s之pod_第45张图片

k8s之pod_第46张图片

• 不正常状态

k8s之pod_第47张图片

k8s之pod_第48张图片

5就绪探针(readinessProbe)
①exec检测
• 正常状态

k8s之pod_第49张图片

k8s之pod_第50张图片

k8s之pod_第51张图片

• 不正常状态:kubectl exec -it nginx1 -- rm -rf /etc/passwd

k8s之pod_第52张图片

k8s之pod_第53张图片

②httpGet检测
• 正常状态

k8s之pod_第54张图片

k8s之pod_第55张图片

• 不正常状态:

k8s之pod_第56张图片

k8s之pod_第57张图片

k8s之pod_第58张图片

③tcpSocket检测
• 正常状态

k8s之pod_第59张图片

k8s之pod_第60张图片

• 不正常状态:

k8s之pod_第61张图片

k8s之pod_第62张图片

k8s之pod_第63张图片

k8s之pod_第64张图片

(6)启动探针:startupProbe

k8s之pod_第65张图片

k8s之pod_第66张图片

k8s之pod_第67张图片

①启动探针:如果探测失败,pod的状态是not ready,启动探针探测容器失败会重启容器

k8s之pod_第68张图片

(7)三种方式结合
①启动探针探测失败

k8s之pod_第69张图片

k8s之pod_第70张图片

测试:删除/etc/passwd:kubectl exec -it nginx1 -- rm -rf /etc/passwd
启动探针如果没有成功之前,后续的探针都不会执行

k8s之pod_第71张图片

②启动探针探测成功

k8s之pod_第72张图片

k8s之pod_第73张图片

k8s之pod_第74张图片

测试:删除/etc/passwd文件:kubectl exec -it nginx2 -- rm -rf /etc/passwd

k8s之pod_第75张图片

启动探针成功之后,在pod的生命周期内不会再检测启动探针
重启了pod之后,相当于重新部署了一个初始版的新的容器
测试:删除index.jsp

k8s之pod_第76张图片

k8s之pod_第77张图片

k8s之pod_第78张图片

(8)总结
①在一个yaml文件中可以有多个探针(启动、存活、就绪都针对一个容器)
②启动探针的优先级最高,只有启动探针“成功”,后续的探针才会执行
③启动探针成功之后,后续除非重启pod,否则不会再触发启动探针
④在pod的生命周期当中,一直存在,一致探测的是存活探针和就绪探针
⑤在pod的生命周期当中,后续的条件是满足哪个探针的条件,触发哪个探诊的条件
⑥就绪探针,如果不影响容器运行,status:running,这个时候不会重启,但是,容器退出的话,就绪探针也会重启

14、容器启动和退出时的动作:postStart、preStop

postStart

容器启动钩子,容器启动之后触发的条件

preStop

容器退出钩子,容器退出之后触发的条件

启动和退回动作的作用:

①启动可以自定义配置容器内的环境变量

②通知机制,告诉用户容器启动完毕

③退出时,可以执行自定义命令,删除或者生成一些必要的程序,自定义销毁方式、自定义资源回收的方式以及容器的退出等待时间

(1)实例

k8s之pod_第79张图片

k8s之pod_第80张图片

k8s之pod_第81张图片

①退出容器

k8s之pod_第82张图片

15、在k8s中都是重启pod,pod为什么会重启

(1)always:默认策略。当pod内的容器退出,不论是一个还是两个容器退出,整个pod都会重启
(2)never:当pod内的容器退出时,不论退出几个,pod都不重启
(3)onfailure:当pod内的容器退出时,状态码是0,整个pod都不会重启,只有一个或者n个容器是非正常退出(状态码非0),整个pod才会重启
(4)k8s的核心:集群化管理容器,k8s管理的对象是封装容器的pod

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