k8s之Pod及Probe 探针机制(健康检查机制)

文章目录

1、Pod

1.1、定义

  • Pod 是一组(一个或多个) 容器(docker容器)的集合 (就像在豌豆荚中);这些容器共享存储、网络、以及怎样运行这些容器的声明
    -
  • 我们一般不直接创建Pod,而是创建一些工作负载由他们来创建Pod

1.2、Pod的形式

  • Pod对容器有自恢复能力(Pod自动重启失败的容器)
  • Pod自己不能恢复自己,Pod如果被删除就真的没了,还是希望k8s集群能自己在其他地方再启动这个Pod
  • 单容器Pod
  • 多容器协同Pod。我们可以把另外的容器称为 SideCar(为应用赋能)
  • Pod 天生地为其成员容器提供了两种共享资源:网络存储

一个Pod由一个Pause容器设置好整个Pod里面所有容器的网络、名称空间等信息

systemctl status可以观测到,Pod和容器进程关系

kubelet启动一个Pod,准备两个容器,一个是Pod声明的应用容器(nginx),另外一个是

Pause,Pause给当前应用容器设置好网络空间

1.2、Pod的使用

  • 可以编写deploy等各种工作负载的yaml文件,最终创建出pod,也可以直接创建
  • Pod的模板如下
shell 复制代码
#这里是 Pod 模版
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: hello
    image: busybox
    command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
  restartPolicy: OnFailure
#以上为 Pod 模版

1.3、 Pod生命周期

  • Pod启动,会先依次执行所有初始化容器,有一个失败,则Pod不能启动
  • 接下来启动所有的应用容器(每一个应用容器都必须能一直运行起来),Pod开始正式工作,一个启动失败就会尝试重启Pod内的这个容器,Pod只要是NotReady,Pod就不对外提供服务了

1.4、生命周期钩子

shell 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: "pod-life-02"
  namespace: default
  labels:
    app: "pod-life-02"
spec:
  volumes:
  - name: content-vol
    emptyDir: {}
  initContainers:  ## Pod在启动containers之前,先要【运行完】initContainers的所有容器,所以这些容器必须有终结,不能一直运行
  - name: init-c-01
    image: alpine  ### 必须有终结的那个时刻,一般不要用一直启动的镜像
    command: ["/bin/sh","-c","echo 12222222 > /app/index.html;sleep 30;"]
    volumeMounts: 
     - name: content-vol
       mountPath: /app
  # - name: init-c-02
  #   image: alpine  ### 必须有终结的那个时刻,一般不要用一直启动的镜像
  #   command: ["/bin/sh","-c","echo 12222222 > /app/index.html;sleep 30;"]
  #   volumeMounts: 
  #    - name: content-vol
  #      mountPath: /app
  containers:
  ### docker run alpine 没有在后台一直启动的程序
  - name: pod-life-01
    image: "nginx" #默认的启动命令是启动nginx。nginx启动在后台一直有了
    volumeMounts: 
     - name: content-vol
       mountPath: /usr/share/nginx/html
  - name: pod-life-02
    image: "alpine"  #pod里面的containers都必须能启动起来,Pod会不断的重启这个容器
    command: ["/bin/sh","-c","sleep 30"]

1.5、临时容器

1.5.1、定义

临时容器:线上排错

有些容器基础镜像。线上没法排错。使用临时容器进入这个Pod。临时容器共享了Pod的所有。临时容器有Debug的一些命令,拍错完成以后,只要exit退出容器,临时容器自动删除
临时容器需要开启特性门控 --feature-gates="EphemeralContainers=true"

在所有组件,api-server、kubelet、scheduler、controller-manager都得配置

1.5.2、使用临时容器的步骤

shell 复制代码
# 1、声明一个临时容器。准备好json文件
{
	"apiVersion": "v1",
	"kind": "EphemeralContainers",
	"metadata": {
		"name": "my-nginx666" //指定Pod的名字
	},
	"ephemeralContainers": [{
	"command": [
		"sh"
	],
	"image": "busybox", //jre的需要jdk来调试
	"imagePullPolicy": "IfNotPresent",
	"name": "debugger",
	"stdin": true,
	"tty": true,
	"terminationMessagePolicy": "File"
	}]
}

# 2、使用临时容器,应用一下即可
kubectl replace --raw /api/v1/namespaces/default/pods/my-nginx666【pod
名】/ephemeralcontainers -f ec.json

1.6、静态Pod

在 /etc/kubernetes/manifests 位置放的所有Pod.yaml文件,机器启动kubelet自己就把他启动起来,静态Pod一直守护在他的这个机器上

2、Probe 探针机制(健康检查机制)

2.1、探针分类

  • 每个容器三种探针(Probe)
    • 启动探针**(后来才加的)** 一次性成功探针。 只要启动成功了
      • kubelet 使用启动探针,来检测应用是否已经启动。如果启动就可以进行后续的探测检
        查。慢容器一定指定启动探针。一直在等待启动
      • 启动探针 成功以后就不用了,剩下存活探针和就绪探针持续运行
    • 存活探针
      • kubelet 使用存活探针,来检测容器是否正常存活。(有些容器可能产生死锁【应用程序在运行,但是无法继续执行后面的步骤】), 如果检测失败就会**重新启动这个容器 **
      • initialDelaySeconds: 3600(长了导致可能应用一段时间不可用) 5(短了陷入无限启
        动循环)
    • 就绪探针
      • kubelet 使用就绪探针,来检测容器是否准备好了可以接收流量。当一个 Pod 内的所有
        容器都准备好了,才能把这个 Pod 看作就绪了。用途就是:Service后端负载均衡多个
        Pod,如果某个Pod还没就绪,就会从service负载均衡里面剔除
    • 谁利用这些探针探测
      • kubelet会主动按照配置给Pod里面的所有容器发送响应的探测请求

2.2、Probe配置项

shell 复制代码
- initialDelaySeconds :容器启动后要等待多少秒后存活和就绪探测器才被初始化,默认
是 0 秒,最小值是 0。这是针对以前没有
- periodSeconds :执行探测的时间间隔(单位是秒)。默认是 10 秒。最小值是 1。
- successThreshold :探测器在失败后,被视为成功的最小连续成功数。默认值是 1。
    - 存活和启动探针的这个值必须是 1。最小值是 1。
- failureThreshold :当探测失败时,Kubernetes 的重试次数。 存活探测情况下的放弃就
意味着重新启动容器。 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最
小值是 1。
- timeoutSeconds :探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。

2.3、编写yaml测试探针机制

shell 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: "nginx-start-probe02"
  namespace: default
  labels:
    app: "nginx-start-probe02"
spec:
  volumes:
  - name: nginx-vol
    hostPath:
      path: /app
  - name: nginx-html
    hostPath:
      path: /html
containers:
- name: nginx
  image: "nginx"
  ports:
  - containerPort: 80
  startupProbe:
    exec:
      command: ["/bin/sh","-c","cat /app/abc"] ## 返回不是0,那就是探测失败
    # initialDelaySeconds: 20 ## 指定的这个秒以后才执行探测
    periodSeconds: 5 ## 每隔几秒来运行这个
    timeoutSeconds: 5 ##探测超时,到了超时时间探测还没返回结果说明失败
    successThreshold: 1 ## 成功阈值,连续几次成才算成功
    failureThreshold: 3 ## 失败阈值,连续几次失败才算真失败
  volumeMounts:
  - name: nginx-vol
    mountPath: /app
  - name: nginx-html
    mountPath: /usr/share/nginx/html
  livenessProbe: ## nginx容器有没有 /abc.html,就绪探针
    # httpGet:
    # host: 127.0.0.1
    # path: /abc.html
    # port: 80
    # scheme: HTTP
    # periodSeconds: 5 ## 每隔几秒来运行这个
    # successThreshold: 1 ## 成功阈值,连续几次成才算成功
    # failureThreshold: 5 ## 失败阈值,连续几次失败才算真失败
    exec:
      command: ["/bin/sh","-c","cat /usr/share/nginx/html/abc.html"] ## 返回
不是0,那就是探测失败
    # initialDelaySeconds: 20 ## 指定的这个秒以后才执行探测
    periodSeconds: 5 ## 每隔几秒来运行这个
    timeoutSeconds: 5 ##探测超时,到了超时时间探测还没返回结果说明失败
    successThreshold: 1 ## 成功阈值,连续几次成才算成功
    failureThreshold: 3 ## 失败阈值,连续几次失败才算真失败
    readinessProbe: ##就绪检测,都是http
      httpGet:
      # host: 127.0.0.1 ###不行
      path: /abc.html ## 给容器发请求
      port: 80
      scheme: HTTP ## 返回不是0,那就是探测失败
    initialDelaySeconds: 2 ## 指定的这个秒以后才执行探测
    periodSeconds: 5 ## 每隔几秒来运行这个
    timeoutSeconds: 5 ##探测超时,到了超时时间探测还没返回结果说明失败
    successThreshold: 3 ## 成功阈值,连续几次成才算成功
    failureThreshold: 5 ## 失败阈值,连续几次失败才算真失败
  # livenessProbe:
  # exec: ["/bin/sh","-c","sleep 30;abc "] ## 返回不是0,那就是探测失败
  # initialDelaySeconds: 20 ## 指定的这个秒以后才执行探测
  # periodSeconds: 5 ## 每隔几秒来运行这个
  # timeoutSeconds: 5 ##探测超时,到了超时时间探测还没返回结果说明失败
  # successThreshold: 5 ## 成功阈值,连续几次成才算成功
  # failureThreshold: 5 ## 失败阈值,连续几次失败才算真失败

健康检查+优雅停机 = 0宕机

start完成以后,liveness和readness并存。 liveness失败导致重启。readness失败导致不给Service负载均衡网络中加,不接受流量。 kubectl exec -it 就进不去。Kubectl describe 看看咋了。

相关推荐
YCyjs28 分钟前
K8S群集调度二
云原生·容器·kubernetes
Hoxy.R28 分钟前
K8s小白入门
云原生·容器·kubernetes
€☞扫地僧☜€4 小时前
docker 拉取MySQL8.0镜像以及安装
运维·数据库·docker·容器
全能全知者5 小时前
docker快速安装与配置mongoDB
mongodb·docker·容器
为什么这亚子6 小时前
九、Go语言快速入门之map
运维·开发语言·后端·算法·云原生·golang·云计算
ZHOU西口8 小时前
微服务实战系列之玩转Docker(十八)
分布式·docker·云原生·架构·数据安全·etcd·rbac
牛角上的男孩9 小时前
Istio Gateway发布服务
云原生·gateway·istio
JuiceFS10 小时前
好未来:多云环境下基于 JuiceFS 建设低运维模型仓库
运维·云原生
景天科技苑11 小时前
【云原生开发】K8S多集群资源管理平台架构设计
云原生·容器·kubernetes·k8s·云原生开发·k8s管理系统
wclass-zhengge12 小时前
K8S篇(基本介绍)
云原生·容器·kubernetes