k8s之资源限制以及探针检查

已于 2024-05-27 08:24:19 修改
阅读量974 收藏 16
点赞数 26
文章标签： kubernetes java 容器
于 2024-05-27 08:19:05 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2301_81272194/article/details/139224061
版权

文章目录

k8s之资源限制以及探针检查

一、资源限制

1、资源限制的使用

  • 当定义Pod时可以选择性地为每个容器设定所需要的资源数量。最常见的可设定资源是CPU和内存大小，以及其他类型的资源。

2、reuqest资源（请求）和limit资源（约束）

  • 当为Pod中的容器指定了request资源时，调度器就使用该信息来决定将Pod调度到哪个节点上。当还为容器指定了limit资源时，kubelet就会确保运行的容器不会使用超出所设的limit资源量。kubelet还会为容器预留所设的request资源量，供该容器使用。
  • 如果Pod所在的节点具有足够的可用资源，容器可以使用超过所设置的request资源量。不过，容器不可以使用超出所设置的limit资源量。
  • 如果给容器设置了内存的limit值，但未设置内存的request值，Kubernetes会自动为其设置与内存limit相匹配的request值。类似的，如果给容器设置了CPU的limit值但未设置CPU的request值，则Kubernetes自动为其设置CPU的request值，并使之与CPU的limit值匹配。

3、官网示例

https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/

image-20240524094106637

4、Pod和容器的资源请求和限制

spec.containers[].resources.requests.cpu
#定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory
#定义创建容器时预分配的内存资源
spec.containers[].resources.requests.hugepages-<size>
#定义创建容器时预分配的巨页资源
spec.containers[].resources.limits.cpu
#定义cpu的资源上限
spec.containers[].resources.limits.memory
#定义内存的资源上限
spec.containers[].resources.limits.hugepages-<size>
#定义巨页的资源上限

5、资源类型

  • CPU 和内存都是资源类型。每种资源类型具有其基本单位。 CPU 表达的是计算处理能力，其单位是 Kubernetes CPUs。 内存的单位是字节。 如果你使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页（Huge Page）资源。 巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。
  • 例如，在默认页面大小为 4KiB 的系统上，你可以指定约束 hugepages-2Mi: 80Mi。 如果容器尝试分配 40 个 2MiB 大小的巨页（总共 80 MiB ），则分配请求会失败。
  • 说明：不能过量使用 hugepages- * 资源。 这与 memory 和 cpu 资源不同。

6、CPU资源单位

  • CPU资源的request和limit以cpu为单位。kubernetes中的一个cpu相当于1个vCPU（1个超线程）。
  • Kubernetes也支持带小数CPU的请求。spec.containers[].resources.requests.cpu为0.5的容器能够获得一个cpu的一半CPU资源（类似于cgroup对CPU资源的时间分片）。表达式0.1等价于表达式100m（毫核），表示每1000毫秒内容器可以使用的CPU时间总量为0.1*1000毫秒。

7、内存资源单位

  • 内存的request和limit以字节为单位。可以用证书表示，

  • 也可以用以10为底数的指数的单位（E、P、T、G、M、K）来表示，或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。

  • 如1KB=103=1000，1MB=106=1000000=1000KB，1GB=10^9=1000000000=1000MB

  • 1KiB=210=1024，1MiB=220=1048576=1024KiB

8、官方文档

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
    #定义容器的资源请求和限制
      requests:
      #定义容器的资源请求
        memory: "64Mi"
        #容器启动时请求的内存量为64MiB
        cpu: "250m"
        #容器启动时请求的CPU为250m（即0.25个CPU核心）
      limits:
      #定义容器的资源限制
        memory: "128Mi"
        #容器可以使用的最大内存量为128MiB
        cpu: "500m"
        #容器可以使用的最大CPU为500m（即0.5个CPU核心）
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
        
#此例子中 Pod 有两个 Container。每个 Container 的请求为 0.25 cpu 和 64MiB（226 字节）内存， 每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 你可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。

image-20240525013438869

9、资源限制

9.1 编写yaml资源配置清单
cd /opt/test
#切换目录

#编辑资源配置清单
vim test01.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test1
spec:
  containers:
  - name: web
    image: nginx:1.18
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "123456"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

image-20240524215759722

9.2 释放内存（node节点，以node01为例）
  • 由于mysql对于内存的使用要求比较高，因此需要先检查内存的可用空间是否能够满足mysql的正常运行，若剩余内存不够，可对其进行释放操作。
9.2.1 查看内存
free -mh
#查看内存

#内存总量为3.7G，实际使用554M，因此可有内存应该为3.1G左右。但是由于有2.5G的内存被用于缓存，导致了free仅为647M。

image-20240524212204487

9.2.2 手动释放缓存
echo [1\2\3] > /proc/sys/vm/drop_caches

cat /proc/sys/vm/drop_caches
#查看清理页面缓存、目录项缓存和 inode 缓存的特殊文件

echo 3 > /proc/sys/vm/drop_caches
#释放页面缓存、目录项缓存和 inode 缓存。

free -mh
#查看内存

0：0是系统默认值，默认情况下表示不释放内存，由操作系统自动管理
1：释放页面缓存（pagecache）。
2：释放目录项缓存（dentries）和 inode 缓存。
3：释放页面缓存、目录项缓存和 inode 缓存。

image-20240524212613937

注意：

  • 如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比较难查看。相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？所以说，既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它。
  • 一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。当发生内存不足、应用获取不到可用内存、OOM错误等问题时，还是更应该去分析应用方面的原因，如用户量太大导致内存不足、发生应用内存溢出等情况，否则，清空buffer，强制腾出free的大小，可能只是把问题给暂时屏蔽了。
9.3 创建资源
kubectl apply -f tets01.yaml
#创建配置资源

image-20240524221501166

9.4 查看pod状态
kubectl get pod
#查看pod状态

#OOM（OverOfMemory：表示服务的运行超过了我们所设定的约束值。

kubectl describe pod test1
#查看详细信息

image-20240524221739524

image-20240524222134036

image-20240525013255777

image-20240524222324293

9.5 查看容器日志
kubectl logs test1 -c web
#查看nginx日志信息（nginx启动正常）

kubectl logs test1 -c db
#查看mysql日志信息（锁定问题容器为mysql）

image-20240524222620427

9.6 删除pod
kubectl delete -f test1
#删除pod资源

image-20240524222637799

9.7 修改yaml配置资源清单，提高mysql资源限制
#修改yaml配置资源清单
vim test1.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: test1
spec:
  containers:
  - name: web
    image: nginx:1.18
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "123456"
    resources:
      requests:
        memory: "512Mi"
        cpu: "0.5"
      limits:
        memory: "1024Mi"
        cpu: "1"

image-20240524221134175

9.8 再次创建资源
kubectl apply -f test1.yaml
#重新创建资源

image-20240524222731007

9.9 跟踪查看pod状态
kubectl get pod -owide -w
#跟踪查看pod状态

image-20240524222808236

9.10 查看pod详细信息
kubectl describe pod test1
#查看pod详细信息

image-20240524223016174

image-20240524223124939

image-20240524223157196

9.11 查看node资源使用
kubectl describe node node01
#查看node资源使用

------------------------------------------------------------------------------------------------------
说明：node01的配置为2C4G。

CPU Requests分析：
nginx的requests为250m，mysql的requests为500m，因此node01的CPU Requests为750m，在node01的两个核中使用占比为37%。

CPU Limits分析：
nginx到的limit为500m，mysql的limit为1，因此node01到的CPU Limits为1500m，在node01的两个核中使用占比为75%。

Memory Requests分析：
nginx的requests为64Mi，mysql的requests为512Mi，因此node01的内存Requests为576Mi，在node01的2G内存中使用占比为15%。

Memory Limits分析：
nginx的limits为128Mi，mysql的limit为1Gi，因此node01的1152Mi，在node01的2G内存中使用占比为31%。
------------------------------------------------------------------------------------------------------

image-20240524223731884

二、健康检查

1、健康检查的定义

  • 健康检查又称为探针（Probe），是由kubelet对容器执行的定期诊断。

2、探针的三种规则

2.1 livenessProbe存活探针
  • 判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据restartPolicy来设置Pod状态，如果容器不提供存活探针，则默认状态为Success。
2.2 readinessProbe就绪探针
  • 判断容器是否准备好接受请求。如果探测失败，端点控制器将从与Pod匹配的所有service endpoints中剔除删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。
2.3 startupProbe启动探针（1.17版本新增）
  • 判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果匹配了startupProbe探测，则在startupProbe状态为Success之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。如果startupProbe失败，kubelet将杀死容器，容器将根据restartPolicy来重启。如果容器没有配置startupProbe，则默认状态为Success。
2.4 同时定义
  • 以上三种规则可同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。

3、Probe支持的三种检测方法

3.1 exec
  • 在容器内执行执行命令，如果容器退出时返回码为0则认为诊断成功。
3.2 tcpSocket
  • 对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。
3.3 httpGet
  • 对指定的端口和路径上的容器的IP地址执行httpGet请求。如果响应的状态码大于等于200且小于400（2xx和3xx），则诊断被认为是成功的。

4、探测结果

每次探测都将获得以下三种结果之一：

  • 成功：容器通过了诊断
  • 失败：容器未通过诊断
  • 未知：诊断失败，因此不会采取任何行动

5、官方文档

https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
#官方文档链接

image-20240524224140114

6、exec方式

6.1 官方示例
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
    #定义存活探针
      exec:
      #执行exec探针命令
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

#initalDeploySeconds：指定kubelet在执行第一次探测前应该等待5秒，即第一次探测是在容器启动后的第6秒才开始执行。默认是0秒，最小值是0。
#periodSeconds：指定了kubelet应该每5秒执行一次存活探测。默认是10秒，最小值是1

在这个配置文件中，可以看到 Pod 中只有一个容器。 periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。

------------------------------------------------------------------------------------------------------
补充：
#failureThreshold：当探测失败时，Kubernetes将在放弃之前重试的次数。存活探测情况下的放弃就意味着重新启动容器，就绪探测情况下的放弃Pod会被打上未就绪的标签。默认值是3，最小值是1。
#timeoutSeconds：探测的超时后等待多少秒。默认值是1秒，最小值是1。（在Kubernetes 1.20版本之前，exec探针会忽略timeoutSeconds，探针会无限期地持续运行，甚至可能超过所配置的限期，直到返回结果为止。）
------------------------------------------------------------------------------------------------------

image-20240524234633453

6.2 编写yaml资源配置清单
#编辑资源配置清单
vim exec.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    #先拉取本地镜像，若是没有就拉取仓库镜像
    command: ["/bin/sh","-c","touch /tmp/live; sleep 30; rm -rf /tmp/live; sleep 3600"]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/live"]
        #检查/tmp/live文件是否存在。如果存在，探针会成功；如果不存在，探针会失败
      initialDelaySeconds: 1
      periodSeconds: 3

------------------------------------------------------------------------------------------------------
说明：
在这个配置文件中，可以看到Pod只有一个容器。
容器中的command字段表示创建一个/tmp/live文件后休眠30秒，休眠结束后删除该文件，并休眠10分钟。
仅使用livenessProbe存活探针，并使用exec检查方式，对/tmp/live文件进行存活检测。
initialDelaySeconds字段表示kubelet在执行第一次探测前应该等待1秒。
periodSeconds字段表示kubelet每隔3秒执行一次存活探测。
------------------------------------------------------------------------------------------------------

image-20240524224430810

6.3 创建资源
kubectl create -f exec.yaml
#创建资源

image-20240524224908847

6.4 跟踪查看pod状态
kubectl get pod -o wide -w
#跟踪查看pod状态，发现71秒时容器重启

image-20240524225055935

6.5 查看pod事件描述
kubectl describe pod liveness-exec
#查看pod资源详细信息

在容器启动37秒时，健康检查三次失败（倒推第一次检查在31秒），kubelet启动了killing程序并在70秒时拉取镜像创建新的容器，在71秒时完成第一次容器重启

image-20240524225756974

7、httpGet方式

7.1 官网示例
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
      #指定使用HTTP GET请求进行探测
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

------------------------------------------------------------------------------------------------------
在这个配置文件中，可以看到Pod只有一个容器。initialDealySeconds字段告诉kubelet再执行第一次探测前应该等待3秒。preiodSeconds字段指定了kubelet每隔3秒执行一次存活探测。kubelet会向容器内运行的服务（服务会监听8080端口）发送一个认为容器是健康存活的。如果处理程序返回失败代码，则kubelet会杀死这个容器并且重新启动它。
任何大于或等于200并且小于400的返回代码标示成功，其他返回代码都标示失败。
------------------------------------------------------------------------------------------------------

image-20240524234853881

7.2 编写yaml资源配置清单
#编辑资源配置清单
vim httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: nginx
    #定义端口名称，下面探测时使用
      containerPort: 80
      #定义端口
    livenessProbe:
    #定义存活探针
      httpGet:
      #指定使用HTTP GET请求进行探测
        port: nginx
        #指定了要访问的容器的端口，为上面的nginx端口名称
        path: /index.html
        #这是要访问的nginx路径。表示站点目录下的index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

image-20240524235335667

7.3 创建资源
kubectl apply -f httpget.yaml
#创建资源

kubectl get pod
#查看pod资源信息

kubectl describe pod liveness-httpget
#查看详细信息

image-20240524235715378

image-20240524235753723

7.4 删除Pod的index.html文件
kubectl exec -it liveness-httpget -- rm -f /usr/share/nginx/html/index.html
#删除index.html文件

image-20240525000207204

7.5 查看pod状态
kubectl get pod -w
#追踪查看pod状态，容器发生重启

image-20240525000259528

7.6 查看容器事件
kubectl describe pod liveness-httpget
#查看详细信息

#重启原因是HTTP探测得到的状态返回码是404，HTTP probe failed with statuscode: 404。
#重启完成后，不会再次重启，因为重新拉取的镜像中包含了index.html文件。

image-20240525000633280

8、tcpSocket方式

8.1 官方示例
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: registry.k8s.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
    livenessProbe:
    #定义了存活探针的配置
      tcpSocket:
      #定义了使用 TCP 套接字进行探针检查
        port: 8080
        #探针将尝试连接容器的8080端口
      initialDelaySeconds: 15
      #在容器启动后，等待15秒才开始进行存活检查
      periodSeconds: 20
      #每隔20秒执行一次存活检查
  
------------------------------------------------------------------------------------------------------
这个例子同时使用readinessProbe和livenessProbe探测。kubelet会在容器启动15秒后发送第一个readiness就绪探测。这会尝试连接goproxy容器的8080端口。如果探测成功，kubelet将继续每隔10秒运行一次检测。
除了readinessProbe探测，这个配置包括了一个livenessProbe探测。kubelet会在容器启动15秒后进行第一次livenessProbe探测。就像readinessProbe探测一样，会尝试连接goproxy容器的8080端口。如果livenessProbe探测失败，这个容器会被重新启动。
------------------------------------------------------------------------------------------------------

image-20240525000728086

8.2 编写yaml资源配置清单
#编辑资源配置清单
vim tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcpsocket
spec:
  containers:
  - name: liveness-tcpsocket-container
    image: nginx
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 8080
      periodSeconds: 3

image-20240525001111610

8.3 创建资源
kubectl apply -f tcpsocket.yaml
#创建资源

kubectl get pod -w
#追踪查看pod信息，pod异常重启

image-20240525001853342

8.4 查看pod事件
kubectl describe pod liveness-tcpsocket
#查看详细信息
#重启原因是nginx使用的默认端口为80，8080端口的健康检查被拒绝访问

image-20240525002051149

8.5 删除pod资源
kubectl delete -f tcpsocket.yaml
#删除pod资源

image-20240525002117539

8.6 修改tcpSocket端口
#修改资源配置清单
vim tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcpsocket
spec:
  containers:
  - name: liveness-tcpsocket-container
    image: nginx
    livenessProbe:
    #定义了存活探针的配置
      initialDelaySeconds: 5
      #在容器启动后，等待5秒才开始进行存活检查
      timeoutSeconds: 1
      #每次存活探针尝试的超时时间设置为 1 秒
      tcpSocket:
      #定义了使用 TCP 套接字进行探针检查
        port: 80
        #修改端口为80
      periodSeconds: 3
      #每隔10秒执行一次存活检查

image-20240525001533435

8.7 重新创建资源
kubectl apply -f tcpsocket.yaml
#重新创建资源

kubectl get pod -o wide -w
#跟踪查看pod状态，启动正常，并未出现重启

image-20240525002315104

8.8 查看pod事件
kubectl describe pod liveness-tcpsocket
#查看详细信息，启动正常

image-20240525002410223

9、readinessProbe就绪探针1

9.1 编写yaml资源配置清单
#编辑资源配置清单
vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget
  namespace: default
spec:
  containers:
  - name: readiness-httpget-container
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
    #定义就绪探针的配置，用于确定容器是否准备好接受流量
      httpGet:
      #使用 HTTP GET 请求进行探针检查
        port: 80
        path: /index1.html
        #注意，这里设置个错误地址，#探针将尝试访问/index1.html路径
      initialDelaySeconds: 1
      #在容器启动后，等待1秒才开始进行就绪检查
      periodSeconds: 3
      #每隔 3 秒执行一次就绪检查
    livenessProbe:
    #定义存活探针的配置
      httpGet:
      #同样使用HTTP GET请求方式
        port: http
        #探针将尝试访问名为http的端口
        path: /index.html
        #探针将尝试访问/index.html 路径，Nginx的默认路径
      initialDelaySeconds: 1
      #等待1秒才开始进行存活检查
      periodSeconds: 3
      #每隔3秒执行一次存活检查
      timeoutSeconds: 10
      #每次存活探针尝试的超时时间设置为10秒

image-20240525003801794

9.2 创建资源
kubectl apply -f readiness-httpget.yaml
#创建资源

kubectl get pod
#查看pod状态
#STATUS为Running，但无法进入READY状态

image-20240525004216354

9.3 查看pod事件
kubectl describe pod readiness-httpget
#查看详细信息
#异常原因为readinessProbe检测的状态返回值为404，kubelet阻止pod进入READY状态

image-20240525004407339

9.4 查看日志
kubectl logs readiness-httpget
#查看日志信息

image-20240525004607171

9.5 为容器创建index1.html
kubectl exec -it readiness-httpget -- touch /usr/share/nginx/html/index1.html
#为容器新建文件

kubectl get pod
#查看pod状态

image-20240525004712805

10、readinessProbe就绪探针2

10.1 编写yaml资源配置清单
  • service探测
  • 如果探测失败，端点控制器将从与 Pod 匹配的所有service地址址endpoints中剔除删除该Pod的IP地。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success
#编辑资源配置清单
vim readiness-multi-nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx1
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx2
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx3
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
  #service通过selector绑定到nginx集群中
    app: nginx
  type: ClusterIP
  ports:
  - name: http
    port: 80
    targetPort: 80

image-20240525005036993

image-20240525005206980

10.2 创建资源
kubectl apply -f readiness-multi-nginx.yaml
#创建资源

kubectl get pod,svc -owide
#查看pod,service状态，运行成功

image-20240525005615227

10.3 删除nginx1中的index.html，查看pod状态
kubectl exec -it nginx1 -- rm -f /usr/share/nginx/html/index.html
#删除nginx1中的index.html文件

kubectl get pod -owide -w
#追踪查看pod状态详细信息，nginx1的READY状态变为0/1

image-20240525005925631

10.4 查看pod事件
kubectl describe pod nginx1
#查看详细信息

#由于httpGet检测到的状态返回码为404，所以readinessProbe失败，kubelet将其设定为noready状态。

image-20240525010043238

10.5 查看service详情
kubectl describe svc nginx-svc
#查看service详细信息，nginx1被剔除出了service的终端列表

image-20240525010220516

10.6 查看终端
kubectl get endpoints
#查看关联的后端地址，终端中无nginx1的ip

image-20240525010320821

三、启动、退出动作

  • 启动探针会在容器启动后立即开始探测，并在探测成功前阻止其他探针（如存活探针和就绪探针）的探测。这有助于确保容器在完全启动并准备好之前不会被错误地终止或加入到服务负载均衡中。

1、编写yaml资源配置清单

#编辑资源配置清单
vim post.yaml
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-test
spec:
  containers:
  - name: lifecycle-test-container
    image: nginx
    lifecycle:
    #定义容器的生命周期钩子
      postStart:
      #容器启动后立即执行的命令（启动钩子）
        exec:
        #使用exec的方式进入容器执行命令
          command: ["/bin/sh","-c","echo Hello from the postStart handler >> /var/log/nginx/message"]
          #表示在容器启动后，立即输出Hello from the postStart handler到 /var/log/nginx/message文件中
      preStop:
      #容器停止前执行的命令
        exec:
        #使用exec的方式进入容器执行命令
          command: ["/bin/sh","-c","echo Hello from the postStop handler >> /var/log/nginx/message"]
          #表示在容器停止前，立即输出Hello from the postStop handler到 /var/log/nginx/message文件中
    volumeMounts:
    #定义容器内的卷挂载点
    - name: message-log
    #挂载的卷的名字
      mountPath: /var/log/nginx/
      #容器内的挂载路径
      readOnly: false
      #卷是否以只读方式挂载。false表示否
  initContainers:
  #定义Pod启动前运行的初始化容器列表
  - name: init-nginx
    image: nginx
    command: ["/bin/sh","-c","echo 'Hello initContainers' >> /var/log/nginx/message"]
    volumeMounts: 
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  volumes:
  - name: message-log
    hostPath:
    #将宿主机上的一个目录或文件挂载到Pod中
      path: /data/volumes/nginx/log/
      #宿主机上的文件或目录路径
      type: DirectoryOrCreate
      #如果指定的路径不存在，则会创建这个目录

image-20240525011501910

2、创建资源

kubectl apply -f post.yaml
#创建资源

kubectl get pod -owide -w
#跟踪查看pod状态

image-20240525011632256

3、查看pod事件

kubectl describe pod lifecycle-test
#查看详细信息

image-20240525011831044

4、查看容器日志

kubectl exec -it lifecycle-test -- cat /var/log/nginx/message
#查看容器日志

#init容器先执行，然后当一个主容器启动后，kubernetes将立即发送postStart事件。

image-20240525011957777

5、关闭容器后查看节点挂载文件

kubectl delete -f post.yaml
#删除，关闭容器

node01节点操作：

cat /data/volumes/nginx/log/message 
#查看节点挂载的文件

#当在容器被终结之前，kubernetes将发送一个postStop事件。

image-20240525012336461

6、重新创建资源，查看容器日志

kubectl apply -f post.yaml
#重新创建资源

kubectl exec -it lifecycle-test -- cat /var/log/nginx/message
#查看容器日志，再次发送postStart事务

image-20240525012850164

四、总结

1、探针

探针分为3种

  • livenessProbe（存活探针）∶判断容器是否正常运行，如果失败则杀掉容器（不是pod），再根据重启策略是否重启容器
  • readinessProbe（就绪探针）∶判断容器是否能够进入ready状态，探针失败则进入noready状态，并从service的endpoints中剔除此容器
  • startupProbe∶判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态

2、检查方式

检查方式分为3种

  • exec∶使用 command 字段设置命令，在容器中执行此命令，如果命令返回状态码为0，则认为探测成功
  • httpget∶通过访问指定端口和url路径执行http get访问。如果返回的http状态码为大于等于200且小于400则认为成功
  • tcpsocket∶通过tcp连接pod（IP）和指定端口，如果端口无误且tcp连接成功，则认为探测成功

3、常用的探针可选参数

常用的探针可选参数有4个

  • initialDelaySeconds∶ 容器启动多少秒后开始执行探测
  • periodSeconds∶探测的周期频率，每多少秒执行一次探测
  • failureThreshold∶探测失败后，允许再试几次
  • timeoutSeconds ∶ 探测等待超时的时间
刘艳芬_
关注
  • 26
    点赞
  • 踩
  • 16
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
k8s之安装资源ddddddd
05-12
k8s之安装中用于配置cni
k8s之lens使用方式
06-30
k8s之lens使用方式
k8s 之资源限制以及探针检查
shenyuanhaojie的博客
12-20 219
文章目录 https://www.cnblogs.com/dingcong1201/p/15522556.html
kubernetes学习记录（三）命令
qq_49723222的博客
05-08 330
1.kubectl get pod -o wide 查看pod信息，在哪个节点运行。 然后转到对应节点，可以使用docker ps -a |grep pod名字 查看进程信息 curl 可访问pod的ip（因为是扁平网络，但是我的master不能，只能用node，弹幕也很多人有类似情况） ip/hostname.html 可返回pod名称 2. 扩容（运行多个相同pod） kubectl run pod名 --image=镜像名 --replicas=1（使用这个参数，deployment才能被
Kubernetes - 实战：k8s之资源限制
最新发布
qq_33240556的博客
04-16 321
在Kubernetes实战中，资源限制是用于管理Pod资源使用的核心功能之一。通过对CPU和内存等资源设置限制，您可以确保集群中的Pod不会过度消耗资源，从而导致节点不稳定或者影响其他Pod的运行。
k8s-资源限制
weixin_61269220的博客
10-10 2919
健康检查又称为探针（Probe），是由kubelet对容器执行的定期诊断。以上三种规则可同时定义。在 rbeadinessProbe 检测成功之前，Pod 的 running 状态是不会变成 ready 状态的探针分为3种：livenessProbe（存活探针）∶判断容器是否正常运行，如果失败则杀掉容器（不是pod），再根据重启策略是否重启容器。
k8s中CPU和内存的资源限制解释
wowenlong的博客
10-26 2万+
在K8s中定义Pod中运行容器有两个维度的限制： 资源需求：即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。如 Pod运行至少需要2G内存，1核CPU。（硬限制） 资源限额：即运行Pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。（软限制） Limits：最大限制，也叫硬限制 Requests: 就是需求限制，也叫软限制 通常来说：Limits >= Requests 并且requests 和 limits 通常要一起配置，若只配置了request
k8s实战之资源和命令
06-17
介绍主要的k8s资源的使用配置和命令。包括configmap，pod，service，replicaset，namespace，deployment，daemonset，ingress，pv，pvc，sc，role，rolebinding，clusterrole，clusterrolebinding，secret，service...
K8S之 metrics-server 组件
06-17
K8S之 metrics-server 组件
K8S1.20.6集群监控资源镜像清单及镜像合集
01-11
说明：资源列表如下 drwxr-xr-x. 7 root root 83 12月 30 11:33 alertmanager drwxr-xr-x. 3 root root 99 1月 11 14:19 grafana drwxr-xr-x 2 root root 216 1月 14 11:06 grafana-dashborard drwxr-xr-x. 5 root ...
【hcie-cloud】【20】容器详解【容器介绍，容器工作机制、容器常用命令说明】【上】
崔崇鑫的博客，你linux/云运维工作中的百科全书。
01-08 1139
注：关于容器，其实我有docker和k8s的分栏，里面的介绍更为详细，有需要的可以去前面博客中了解。这里单独放是因为hcie课程里面有。所以这就跟着课程简单做了笔记。容器作为云原生的关键技术之一，是云原生应用实现的主要基石，本章将从容器的定义开始，并以Docker为例，介绍容器的基本操作及容器镜像的制作方法。学完本课程后，您将能够：了解容器是什么掌握容器的基本操作掌握容器镜像的制作容器的精髓在于镜像，而docker是容器镜像标准的制定者，因此，学习容器是绕不开docker的。
kubectl基本操作
不知名的研发小码农
01-28 4496
kubectl基本操作kubectl基本操作查看所有 pod 列表, -n 后跟 namespace, 查看指定的命名空间查看 RC 和 service 列表， -o wide 查看详细信息显示 Node 的详细信息显示 Pod 的详细信息, 特别是查看 pod 无法创建的时候的日志根据 yaml 创建资源, apply 可以重复执行，create 不行基于 pod.yaml 定义的名称删除 pod删除所有包含某个 label 的pod 和 service删除所有 Pod查看 endpoint 列表执行
Mongodb 学习笔记 （11）启动时WiredTiger 错误解决
大O的博客
08-16 1万+
数据库版本：3.4.15 错误描述： 无法启动，错误日志显示： [initandlisten] WiredTiger error (-31802) [1565933984:78859][31235:0x7f4ace0cad00], txn-recover: unsupported WiredTiger file version: this build only supports majo...
Kubectl基本操作命令
热门推荐
互联网的修罗场
10-30 3万+
创建对象 通过yaml文件创建： kubectl create -f xxx.yaml （不建议使用，无法更新，必须先delete） kubectl apply -f xxx.yaml （创建+更新，可以重复使用） 删除对象 通过yaml文件删除： kubectl delete -f xxx.yaml 查看kube-system namespace下面的pod/svc/deployment 等等 ...
Kubernetes学习笔记---常用命令
B.I.T
06-09 1万+
1 查看类命令 --- # 查看集群信息 kubectl cluster-info # 查看各组件信息 kubectl -s http://localhost:8080 get componentstatuses # 查看pods所在的运行节点 kubectl get pods -o wide # 查看pods定义的详细信息 kubectl get pods -o
容器编排技术 -- Kubernetes kubectl get 命令详解
YunWisdom
08-29 1358
容器编排技术 -- Kubernetes kubectl get 命令详解 1kubectl get 2语法 3示例 4Flags kubectl get 获取列出一个或多个资源的信息。 可以使用的资源包括： all certificatesigningrequests (aka 'csr') clusterrolebindings clusterroles c...
解决 输入kubectl get pods -o wide后没有显示ip
qq_21277357的博客
08-17 8768
# 部署calico 重新执行这两句就好了/etc/kubernetes/addons 是你自己的目录 不要用我的目录 kubectl apply -f /etc/kubernetes/addons/calico-rbac-kdd.yaml kubectl apply -f /etc/kubernetes/addons/calico.yaml ...
【项目实战25】k8s(11)—k8s容器资源限制（内存，cpu限制）
weixin_48819467的博客
05-16 6902
k8s容器资源限制一、基础知识(1)、资源限制(2)、资源类型二、内存限制三、cpu限制四、namespace设置资源限制(1)、设置namespace资源限制(2)、为namespace设置资源配额(3)、为namespace配置Pod配额 一、基础知识 (1)、资源限制 在K8s中定义Pod中运行容器有两个维度的限制： 资源需求：即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。如： Pod运行至少需要2G内存，1核CPU 资源限额：即运行Pod期间，可能内存使用量会增加，那最多能使用多少
k8s探针检测php,k8s探针实现grpc健康检查
07-28
至于使用gRPC实现k8s探针的健康检查，你可以按照以下步骤进行操作： 1. 在你的PHP应用程序中，使用gRPC框架创建一个gRPC服务。 2. 在该gRPC服务中实现一个健康检查方法，该方法可以返回一个表示应用程序健康状态的...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值