kubernetes基础操作(pod生命周期)

news2024/10/3 21:23:36

pod生命周期

一、Pod生命周期

我们一般将pod对象从创建至终的这段时间范围称为pod的生命周期,它主要包含下面的过程:

◎pod创建过程

◎运行初始化容器(init container)过程

◎运行主容器(main container)

£容器启动后钩子(post start)、容器终止前钩子(pre stop)

£容器的存活性探测(liveness probe)、就绪性探测(readiness probe)

◎pod终止过程

1.1创建和终止

*pod的创建过程:

(1)用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer

(2)apiServer开始生成pod对象的信息,并将信息存入etcd,然后返回确认信息至客户端

(3)apiServer开始反映etcd中的pod对象的变化,其它组件使用watch机制来跟踪检查apiServer上的变动

(4)scheduler发现有新的pod对象要创建,开始为Pod分配主机并将结果信息更新至apiServer

(5)node节点上的kubelet发现有pod调度过来,尝试调用docker启动容器,并将结果回送至apiServer

(6)apiServer将接收到的pod状态信息存入etcd中

*pod的终止过程:

(1)用户向apiServer发送删除pod对象的命令

(2)apiServcer中的pod对象信息会随着时间的推移而更新,在宽限期内(默认30s),pod被视为dead

(3)将pod标记为terminating状态

(4)kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程

(5)端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除

(6)如果当前pod对象定义了preStop钩子处理器,则在其标记为terminating后即会以同步的方式启动执行

(7)pod对象中的容器进程收到停止信号

(8)宽限期结束后,若pod中还存在仍在运行的进程,那么pod对象会收到立即终止的信号

(9)kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作,此时pod对于用户已不可见

1.2初始化容器

初始化容器是在pod的主容器启动之前要运行的容器,主要是做一些主容器的前置工作,它具有两大特征:

(1)初始化容器必须运行完成直至结束,若某初始化容器运行失败,那么kubernetes需要重启它直到成功完成

(2)初始化容器必须按照定义的顺序执行,当且仅当前一个成功之后,后面的一个才能运行

初始化容器有很多的应用场景,下面列出的是最常见的几个:

(1)提供主容器镜像中不具备的工具程序或自定义代码

(2)初始化容器要先于应用容器串行启动并运行完成,因此可用于延后应用容器的启动直至其依赖的条件得到满足

案例模拟需求:

主容器运行nginx,但是要求运行nginx之前先要能够连接上MySQL和redis

创建pod-initcontainer.yaml

创建pod并查看状态

[root@master ~]# kubectl create -f pod-initcontainer.yaml

pod/pod-initcontainer created

[root@master ~]# kubectl describe pod pod-initcontainer -n dev

查看动态pod

[root@master ~]# kubectl get pods pod-initcontainer -n dev -w

NAME                             READY   STATUS     RESTARTS   AGE

pod-initcontainer                0/1     Init:0/2   0          15s

pod-initcontainer                0/1     Init:1/2   0          52s

pod-initcontainer                0/1     Init:1/2   0          53s

pod-initcontainer                0/1     PodInitializing   0          89s

pod-initcontainer                1/1     Running           0          90s

为当前服务器新增两个IP,观察pod变化

1.3钩子函数

钩子函数能够感知自身生命周期中的事件,并在相应的时刻到来时运行用户指定的程序代码。

kubernetes在主容器的启动之后和停止之前提供了两个钩子函数:

post start:容器创建之后执行,如果失败了会重启容器

pre stop :容器终止之前执行,执行完成之后容器将成功终止,在其完成之前会阻塞删除容器的操作

钩子处理器支持使用下面三种方式定义动作:

(1)Exec命令:在容器内执行一次命令

……

  lifecycle:

    postStart:

      exec:

        command:

        - cat

        - /tmp/healthy

……

(2)TCPSocket:在当前容器尝试访问指定的socket

……      

  lifecycle:

    postStart:

      tcpSocket:

        port: 8080

……

(3)HTTPGet:在当前容器中向某url发起http请求

……

  lifecycle:

    postStart:

      httpGet:

        path: / #URI地址

        port: 80 #端口号

        host: 192.168.5.3 #主机地址

        scheme: HTTP #支持的协议,http或者https

……

接下来,以exec方式为例,演示下钩子函数的使用,创建pod-hook-exec.yaml文件,内容如下:

[root@master ~]# vi pod-hook-exec.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-hook-exec

  namespace: dev

spec:

  containers:

  - name: main-container

    image: nginx:1.17.1

    ports:

    - name: nginx-port

      containerPort: 80

    lifecycle:

      postStart:

        exec: # 在容器启动的时候执行一个命令,修改掉nginx的默认首页内容

          command: ["/bin/sh", "-c", "echo postStart... > /usr/share/nginx/html/index.html"]

      preStop:

        exec: # 在容器停止之前停止nginx服务

          command: ["/usr/sbin/nginx","-s","quit"]

创建pod:

[root@master ~]# kubectl create -f pod-hook-exec.yaml

pod/pod-hook-exec created

查看并访问pod:

1.4容器探测

容器探测用于检测容器中的应用实例是否正常工作,是保障业务可用性的一种传统机制。如果经过探测,实例的状态不符合预期,那么kubernetes就会把该问题实例" 摘除 ",不承担业务流量。kubernetes提供了两种探针来实现容器探测,分别是:

◎liveness probes:存活性探针,用于检测应用实例当前是否处于正常运行状态,如果不是,k8s会重启容器

◎readiness probes:就绪性探针,用于检测应用实例当前是否可以接收请求,如果不能,k8s不会转发流量

livenessProbe 决定是否重启容器,readinessProbe 决定是否将请求转发给容器。

上面两种探针目前均支持三种探测方式:

(1)Exec命令:在容器内执行一次命令,如果命令执行的退出码为0,则认为程序正常,否则不正常

……

  livenessProbe:

    exec:

      command:

      - cat

      - /tmp/healthy

……

(2)TCPSocket:将会尝试访问一个用户容器的端口,如果能够建立这条连接,则认为程序正常,否则不正常

……      

  livenessProbe:

    tcpSocket:

      port: 8080

……

(3)HTTPGet:调用容器内Web应用的URL,如果返回的状态码在200和399之间,则认为程序正常,否则不正常

……

  livenessProbe:

    httpGet:

      path: / #URI地址

      port: 80 #端口号

      host: 127.0.0.1 #主机地址

      scheme: HTTP #支持的协议,http或者https

……

实例演示:

下面以liveness probes为例,做几个演示:

方式一:Exec

创建pod-liveness-exec.yaml

[root@master ~]# vi pod-liveness-exec.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-liveness-exec

  namespace: dev

spec:

  containers:

  - name: nginx

    image: nginx:1.17.1

    ports:

    - name: nginx-port

      containerPort: 80

    livenessProbe:

      exec:

        command: ["/bin/cat","/tmp/hello.txt"] # 执行一个查看文件的命令

创建pod

[root@master ~]# kubectl create -f pod-liveness-exec.yaml

pod/pod-liveness-exec created

#查看pod详情

[root@master ~]# kubectl describe pods pod-liveness-exec -n dev

.........

Events:

  Type     Reason     Age               From               Message

  ----     ------     ----              ----               -------

  Normal   Scheduled  29s               default-scheduler  Successfully assigned dev/pod-liveness-exec to master

  Normal   Pulled     1s (x2 over 29s)  kubelet, master    Container image "nginx:1.17.1" already present on machine

  Normal   Created    1s (x2 over 29s)  kubelet, master    Created container nginx

  Normal   Started    1s (x2 over 28s)  kubelet, master    Started container nginx

  Warning  Unhealthy  1s (x3 over 21s)  kubelet, master    Liveness probe failed: /bin/cat: /tmp/hello.txt: No such file or directory

  Normal   Killing    1s                kubelet, master    Container nginx failed liveness probe, will be restarted

# 观察上面的信息就会发现nginx容器启动之后就进行了健康检查

# 检查失败之后,容器被kill掉,尝试进行重启(这是重启策略)

# 稍等一会,再观察pod信息,就可以看到RESTARTS不再是0,而是一直增长

方式二:TCPSocket

创建pod-liveness-tcpsocket.yaml

[root@master ~]# vi pod-liveness-tcpsocket.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-liveness-tcpsocket

  namespace: dev

spec:

  containers:

  - name: nginx

    image: nginx:1.17.1

    ports:

    - name: nginx-port

      containerPort: 80

    livenessProbe:

      tcpSocket:

        port: 8080 # 尝试访问8080端口

创建pod,观察效果

# 创建pod

[root@master ~]# kubectl create -f pod-liveness-tcpsocket.yaml

pod/pod-liveness-tcpsocket created

# 查看pod详情

[root@master ~]# kubectl describe pods pod-liveness-tcpsocket -n dev

......

Events:

  Type     Reason     Age               From               Message

  ----     ------     ----              ----               -------

  Normal   Scheduled  26s               default-scheduler  Successfully assigned dev/pod-liveness-tcpsocket to master

  Normal   Pulled     25s               kubelet, master    Container image "nginx:1.17.1" already present on machine

  Normal   Created    25s               kubelet, master    Created container nginx

  Normal   Started    25s               kubelet, master    Started container nginx

  Warning  Unhealthy  7s (x2 over 17s)  kubelet, master    Liveness probe failed: dial tcp 10.244.219.69:8080: connect: connection refused

# 观察上面的信息,发现尝试访问8080端口,但是失败了

# 稍等一会之后,再观察pod信息,就可以看到RESTARTS不再是0,而是一直增长

方式三:HTTPGet

创建pod-liveness-httpget.yaml

[root@master ~]# vi pod-liveness-httpget.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-liveness-httpget

  namespace: dev

spec:

  containers:

  - name: nginx

    image: nginx:1.17.1

    ports:

    - name: nginx-port

      containerPort: 80

    livenessProbe:

      httpGet:  # 其实就是访问http://127.0.0.1:80/hello

        scheme: HTTP #支持的协议,http或者https

        port: 80 #端口号

        path: /hello #URI地址

创建pod,观察效果

# 创建pod

[root@master ~]# kubectl create -f pod-liveness-httpget.yaml

pod/pod-liveness-httpget created

# 查看pod详情

[root@master ~]# kubectl describe pod pod-liveness-httpget -n dev

......

Events:

  Type     Reason     Age               From               Message

  ----     ------     ----              ----               -------

  Normal   Scheduled  33s               default-scheduler  Successfully assigned dev/pod-liveness-httpget to master

  Warning  Unhealthy  6s (x3 over 26s)  kubelet, master    Liveness probe failed: HTTP probe failed with statuscode: 404

  Normal   Killing    6s                kubelet, master    Container nginx failed liveness probe, will be restarted

  Normal   Pulled     5s (x2 over 32s)  kubelet, master    Container image "nginx:1.17.1" already present on machine

  Normal   Created    5s (x2 over 32s)  kubelet, master    Created container nginx

  Normal   Started    5s (x2 over 32s)  kubelet, master    Started container nginx

# 观察上面信息,尝试访问路径,但是未找到,出现404错误

至此,已经使用liveness Probe演示了三种探测方式,但是查看livenessProbe的子属性,会发现除了这三种方式,还有一些其他的配置,在这里一并解释下:

[root@master ~]# kubectl explain pod.spec.containers.livenessProbe

FIELDS:

   exec <Object>  

   tcpSocket    <Object>

   httpGet      <Object>

   initialDelaySeconds  <integer>  # 容器启动后等待多少秒执行第一次探测

   timeoutSeconds       <integer>  # 探测超时时间。默认1秒,最小1秒

   periodSeconds        <integer>  # 执行探测的频率。默认是10秒,最小1秒

   failureThreshold     <integer>  # 连续探测失败多少次才被认定为失败。默认是3。最小值是1

   successThreshold     <integer>  # 连续探测成功多少次才被认定为成功。默认是1

1.5重启策略

在上一节中,一旦容器探测出现了问题,kubernetes就会对容器所在的Pod进行重启,其实这是由pod的重启策略决定的,pod的重启策略有 3 种,分别如下:

◎Always :容器失效时,自动重启该容器,这也是默认值。

◎OnFailure : 容器终止运行且退出码不为0时重启

◎Never : 不论状态为何,都不重启该容器

重启策略适用于pod对象中的所有容器,首次需要重启的容器,将在其需要时立即进行重启,随后再次需要重启的操作将由kubelet延迟一段时间后进行,且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s,300s是最大延迟时长。

创建pod-restartpolicy.yaml:

[root@master ~]# vi pod-restartpolicy.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod-restartpolicy

  namespace: dev

spec:

  containers:

  - name: nginx

    image: nginx:1.17.1

    ports:

    - name: nginx-port

      containerPort: 80

    livenessProbe:

      httpGet:

        scheme: HTTP

        port: 80

        path: /hello

  restartPolicy: Never # 设置重启策略为Never

运行pod测试

# 创建pod

[root@master ~]# kubectl create -f pod-restartpolicy.yaml

pod/pod-restartpolicy created

# 查看pod详情,查看nginx容器失败

[root@master ~]# kubectl describe pods pod-restartpolicy -n dev

......

 Warning  Unhealthy  1s (x3 over 21s)  kubelet, master    Liveness probe failed: HTTP probe failed with statuscode: 404

  Normal   Killing    1s                kubelet, master    Stopping container nginx

# 多等一会,再观察pod重启次数,发现一直是0,并未重启

[root@master ~]# kubectl get pods pod-restartpolicy -n dev

NAME                READY   STATUS      RESTARTS   AGE

pod-restartpolicy   0/1     Running   0          95s

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2186883.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

【Redis入门到精通九】Redis中的主从复制

目录 主从复制 1.配置主从复制 2.主从复制中的拓扑结构 3.主从复制原理 4.主从复制总结 主从复制 在分布式系统中为了解决单点问题&#xff0c;通常会把数据复制多个副本部署到其他服务器&#xff0c;满⾜故障恢复和负载均衡等需求。Redis 也是如此&#xff0c;它为我们提…

kafka基本概念以及用法

kafka基本概念以及用法目录 文章目录 kafka基本概念以及用法目录一、什么是kafka&#xff1f;二、为什么要使用kafka?三、kafka的基本概念四、安装kafka(windows版本)五、命令行控制kafka生产消费数据&#xff0c;创建 删除topic六、java操作kafka消费生产 提示&#xff1a;以…

Ubuntu操作系统版本服务支持时间(更新到24.04)

文章参考链接 以下是解释&#xff1a; 开发代号&#xff1a;Ubuntu的每个版本都有一个开发代号&#xff0c;例如“Mantic Minotaur”。 版本命名&#xff1a;Ubuntu的版本号是根据发布年份和月份来命名的。例如&#xff0c;Ubuntu 23.10是在2023年10月发布的。 LTS版本&…

Windows 11 24H2正式发布

微软最近正式发布了Windows 11 24H2&#xff0c;这是Windows 11的最新功能更新&#xff0c;带来了多项新特性和改进。 主要新功能&#xff1a; 人工智能增强&#xff1a;此次更新特别强调AI能力&#xff0c;推出了如Windows Copilot的增强版本。Copilot的界面得到了改善&#…

【微服务】注册中心 - Eureka(day3)

CAP理论 P是分区容错性。简单来说&#xff0c;分区容错性表示分布式服务中一个节点挂掉了&#xff0c;并不影响其他节点对外提供服务。也就是一台服务器出错了&#xff0c;仍然可以对外进行响应&#xff0c;不会因为某一台服务器出错而导致所有的请求都无法响应。综上所述&…

关于Mybatis框架操作时注意的细节,常见的错误!(博主亲生体会的细节!)

目录 1.在对DB进行CRUD时&#xff0c;除了查&#xff0c;其余的操作都要进行事务的提交否则不成功。 2.用sqlSession原生方法时&#xff0c;第一个参数方法名&#xff0c;是xml文件中定义的id名&#xff0c;底层找的是你这个接口所定义的方法名。 3.以包为单位引入映射文件 …

第三节-类与对象(2)默认成员函数详解

1.类的6个默认成员函数 如果一个类中什么成员都没有&#xff0c;简称为空类&#xff08;空类大小为1&#xff09;。 空类中真的什么都没有吗&#xff1f;并不是&#xff0c;任何类在什么都不写时&#xff0c;编译器会自动生成以下6个默认成员函数。 默认成员函数&#xff1a;…

DOM树(下) -- 第八课

文章目录 前言一、DOM属性操作1. 获取属性值2. 设置属性值3. 移除属性值 二、节点1.什么是节点?2. 节点层级1. 获取父级节点2. 获取兄弟节点3. 获取子节点 3. 节点操作1. 创建节点2. 添加和删除节点 三、事件进阶1. 注册事件1. 传统方式2. 监听方式 2. 删除事件3. 事件流 四、…

第4篇:MSSQL日志分析----应急响应之日志分析篇

常见的数据库攻击包括弱口令、SQL注入、提升权限、窃取备份等。对数据库日志进行分析&#xff0c;可以发现攻击行为&#xff0c;进一步还原攻击场景及追溯攻击源。 0x01 MSSQL日志分析 首先&#xff0c;MSSQL数据库应启用日志记录功能&#xff0c;默认配置仅限失败的登录&…

Veritus netbackup 管理控制台无法连接:未知错误

节假日停电&#xff0c;netbackup服务器意外停机后重新开机&#xff0c;使用netbackup管理控制台无法连接&#xff0c;提示未知错误。 ssh连接到服务器&#xff0c;操作系统正常&#xff0c;那应该是应用有问题&#xff0c;先试一下重启服务器看看。重新正常关机&#xff0c;重…

【Ubuntu】使用阿里云apt源来更新apt源

1.前言 我在京东云买了一个云服务器&#xff0c;但是我第一次使用apt的时候&#xff0c;发现遇到了下面这些情况 后面听老师讲&#xff0c;还需要执行下面这个 但是我再次使用apt下载软件的时候&#xff0c;还是出现了下面这个情况 后面问了老师才知道是apt源的问题&#x…

解决Github打不开或速度慢的问题

一、原因 我们先分析一下Github在国内访问慢或有时候登陆不上去的问题原因&#xff1a;其实这都是因为我们访问github官网时是直接访问域名即github.com&#xff0c;那么中间有个域名通过DNS解析的过程&#xff0c;将域名解析为对应的ip地址&#xff0c;其实主要时间都是花在了…

【寻找one piece的算法之路】——双指针算法!他与她是否会相遇呢?

&#x1f490;个人主页&#xff1a;初晴~ &#x1f4da;相关专栏&#xff1a;寻找one piece的刷题之路 什么是双指针算法 双指针算法是一种常用的编程技巧&#xff0c;尤其在处理数组和字符串问题时非常有效。这种方法的核心思想是使用两个指针来遍历数据结构&#xff0c;这两…

学习记录:js算法(五十二):验证二叉搜索树

文章目录 验证二叉搜索树我的思路网上思路 总结 验证二叉搜索树 给你一个二叉树的根节点 root &#xff0c;判断其是否是一个有效的二叉搜索树。 有效 二叉搜索树定义如下&#xff1a; 节点的 左子树 只包含 小于 当前节点的数。 节点的 右子树 只包含 大于 当前节点的数。 所有…

【Python】AudioLazy:基于 Python 的数字信号处理库详解

AudioLazy 是一个用于 Python 的开源数字信号处理&#xff08;DSP&#xff09;库&#xff0c;设计目的是简化信号处理任务并提供更直观的操作方式。它不仅支持基础的滤波、频谱分析等功能&#xff0c;还包含了滤波器、信号生成、线性预测编码&#xff08;LPC&#xff09;等高级…

Mybatis框架梳理

Mybatis框架梳理 前言1.ORM2.模块划分2.1 ORM的实现2.2 SQL的映射2.3 插件机制2.4 缓存机制2.5 其他 3. 愿景 前言 如果让我聊一聊mybatis&#xff0c;我该怎么说呢&#xff1f;开发中时时刻刻都在用它&#xff0c;此时此刻&#xff0c;脑海中却只浮现ORM框架这几个字&#xff…

Linux --入门学习笔记

文章目录 Linux概述基础篇Linux 的安装教程 ⇒ 太简单了&#xff0c;百度一搜一大堆。此处略……Linux 的目录结构常用的连接 linux 的开源软件vi 和 vim 编辑器Linux 的关机、开机、重启用户登录和注销用户管理添加用户 ⇒ ( useradd 用户名 ) &#xff08; useradd -d 制定目…

【AIGC】内容创作——AI文字、图像、音频和视频的创作流程

我的主页&#xff1a;2的n次方_ 近年来&#xff0c;生成式人工智能&#xff08;AIGC&#xff0c;Artificial Intelligence Generated Content&#xff09;技术迅速发展&#xff0c;彻底改变了内容创作的各个领域。无论是文字、图像、音频&#xff0c;还是视频&#xff0c;A…

SPARK调优:AQE特性(含脑图总结)

学完AQE需要能够回答如下的几个问题&#xff1a; 什么是AQE&#xff1f;AQE的实现原理是什么&#xff1f;AQE的特性有哪些&#xff1f;使用什么参数实现&#xff1f;AQE每个特性可以解决什么问题&#xff1f;什么问题是AQE不能解决的 HL&#xff1a;学习脑图如下 SparkAQE是spa…

MES系统适用于哪些行业?MES系统对于企业的作用和价值

MES系统&#xff08;制造执行系统&#xff09;广泛应用于多个行业&#xff0c;并在这些行业中发挥着重要作用&#xff0c;为企业带来了显著的价值。以下是对MES系统适用行业及其对企业作用和价值的详细分析&#xff1a; 一、MES系统适用的行业 电子信息行业&#xff1a; 随着市…