K8S 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

pod里面是容器,容器运行的是进程 pid

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

K8S POD_第1张图片

pause容器共享两种资源

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

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

存储

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

vloume可以实现数据的持久化

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

总结:

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

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

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

pod外再设置一个基础镜像:

pod内部有一组容器,挂了一个,就算这个pod失效了么?引入pause禁止,代表整个容器的组的状态

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

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

pod的分类:

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

deployment daemanset

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

pod的生命周期:

1、pending 挂起状态

pod已被创建,但是尚未分配到运行他的node节点 (节点资源不够,需要等待其他pod的调度)

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

3、complete:容器内部的进程已经运行完毕,正常退出,未发生错误

successded:

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

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

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

7、

K8S POD_第2张图片

存活探针和流量探针会伴随整个pod的生命周期,如果容器出了问题,pod将不再是ready状态

创建pod的容器分类:

1、基础容器:pause

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

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

3、业务容器

init容器的作用:

环境变量

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

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

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

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

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

k8s的一种机制,相当于计算器一样,88+88+88 也可以88*3

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

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

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就是用来封装容器的,业务是容器。服务也是容器。端口也是容器

K8S的pod重启策略:

Always deployment的yaml文件只能是Always pod的yaml三种模式都可以

OnFailure:只有状态非0才会重启。正常退出是不重启的

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

容器退出了,pod才会重启

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

docker的重启策略:

docker默认策略是never

on-failure:非正常退出时才会重启容器

always:只要容器退出都会重启

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

单机部署:docker足够了

集群化部署: K8S

yaml文件快速生成

 kubectl create deployment nginx1 --image=nginx:1.22 --replicas=3 --dry-run=client

--dry-run=client :只是调用api的对象不执行命令 

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

imagespullbackoff:正在重试拉取镜像

errimagepull:拉取镜像出现错误 (网速太慢,镜像名字写错了,镜像仓库挂了)

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

POD内的容器使用节点资源的限制:

1、request:需要的资源

2、limit:最高能占用系统多少资源

limit:需要多少,最多也只能占用这么多

两个限制:

cpu

cpu的限制格式:

1 2 0.5 0.2 0.3

1 可以占用1个cpu

2 可以占用两个

0.5 半个

0.2 一个cpu的五分之一

0.1 是最小单位

要么是整数要么是小数点后只能跟一位,最小单位是0.1

m来表示cpu

cpu分片时间原理:

cpu时间分片: 通过周期性的轮流分配cpu时间给各个进程,多个进程可以在cpu上交替执行

在k8s当中就是表示占用的cpu比率

m:milllicores 单位

1

1000m

500m

2000m

100m就是最小单位

内存:

ki

mi

gi

ti

K8S怎么设置拉取镜像的策略:

默认策略:

ifNotpresent:如果本地镜像有,就不在拉取,本地没有才会去镜像仓库拉取

Alway:不论镜像是否存在,创建时(重启)都会重新拉取镜像

Never:仅仅使用本地镜像,本地没有也不会主动拉取

pod的容器健康检查

探针

probe

k8s对容器执行的定期检查,诊断

探针有三种规则:

1、存活探针:

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

2、流量/就绪探针:

探测容器是否进入ready状态,并且做好接受请求的准备

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

3、启动探针:

只是在容器启动之后开始检测,容器内的应用是否启动成功。在启动探测成功之前,所有的其他探针都会处于禁用状态

但是,一旦启动探针结束,后续的操作不再受启动探针的影响。

在一个容器当中的可以有多个探针。

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

存活:

就绪

probe的检查方法:

1、exec探针:在容器内部执行命令,如果命令的返回码是0,表示成功

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

2、httpGet:

对指定ip加端口的容器发送一个httpGet的请求。响应状态码大于或者等于200,但是要小于400 ,在这区间的都是成功

200 正常 300 重定向 400客户端错误 500服务端错误

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

3、tcpsocket:

端口,对指定端口上的容器的ip地址进行tcp检查(三次握手),端口打开,任务探测成功

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

80

999

telnet 192.168.211.10:80

诊断结果:

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

2、失败,只有存活探针会重启,

3、未知状态:诊断失败

livenssprobe

存活探针:

杀死容器,重启

readinessProbe

就绪探针,pod的状态是runing ready状态是notready,容器不可以提供正常的访问

tcpSocket只是监听容器上的业务端口能否正常通信。8081没有,8080还在,也就是正常的端口还是可以访问。

如果更改了容器的启动端口

mysql 3306 33066

tcp--->33066

存活探针和就绪探针,会伴随整个pod的生命周期。

startupProbe:启动探针

如果探测失败,pod的状态是notReady

启动探针探测容器失败,会重启pod

启动探针没有成功之前,那么后续的探针都不会执行。

启动探针成功之后,在pod的生命周期内不会再检测探针

重启了pod之后相当于重新部署了一个初始版的新的容器。

总结:

1、在一个yaml当中可以有多个探针,启动,存活,就绪都针对一个容器

2、启动探针的优先级是最高的 只有启动探针“成功”,后续的探针才会执行

3、启动探针成功之后。后续除非重启pod,不会再触发启动探针了

4、在pod的生命周期当中,伴随pod,一直存在,一直探测的是存活探针,就绪探针

5、在pod的生命周期当中,后续的条件是满足哪个探针的条件,就触发哪个探针的条件

6、就绪探针,如果不影响容器运行,status:runing,这个时候不会重启,但是容器退出的话,就绪探针也会重启

容器启动和退出时的动作

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

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

      volumeMounts:
      - name: test1
        mountPath: /opt
        readOnly: false
声明容器内部的挂载目录 
要给挂载卷取一个名字,不挂载卷的名字不能重复
readOnly: false

  volumes:
  - name: test1
    hostPath:
      Path: /opt/test
      type: DirectoryOrCreate
声明的是Node节点上和容器的/opt的挂载目录
挂载卷的名称和要挂载的容器内挂载卷名称要一一对应
hostPath:指定和容器的挂载目录 
type:DirectoryOrCreate:如果节点上的目录不存在,自动创建该目录
# pod会经常被重启,销毁,一旦容器和node节点做了挂载卷,数据就不会丢失 

启动和退出的作用:
1、启动可以自定义配置容器内的环境
2、通知机制,告诉用户容器启动完毕
3、退出时,也可以执行自定义命令,删除或者生成一些必要的程序,自定义销毁方式,自定义资源回收的方式以及容器的退出等待时间

在这个pod的生命周期事件当中,把启动探针,存活探针,就绪探针加入到yaml文件当中

pod的重启策略:

在k8s当中都是重启pod

Always:默认策略------>当pod内的容器退出,不论是一个还是两个容器退出,整个pod都会重启

never:当pod内的容器退出时,退出一个还是退出N个,pod都不重启

onFailure:当pod内的容器退出时,状态码0,整个pod都不会重启,只有一个或者N个容器非正常退出,状态码非0,整个pod才会重启

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