pod进阶

探针（核心内容）

poststart

prestop

容器钩子

pod的生命周期开始：

k8s的pod的重启策略：

Always（默认策略）

deployment的yaml文件只能是Always。Always：不论正常还是非正常退出都会重启。

pod的yaml三种模式都可以。

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

Never：正常退出和非正常退出都不重启。

容器退出了，pod才会重启。

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

k8s的重启策略与docker的重启策略对比（重点）

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 -o yaml

>/opt/test1.yaml

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

vim test1.yaml

vim test1-pod.yaml

vim test1-service.yaml

crashloopbackoff：pod当中的容器退出，kubelet正在重启

imagepullbackoff：正在重试拉取镜像

errimagepull：拉取镜像出错了（1、网速太慢，2、镜像名字写错了，3、镜像仓库挂了）

Evicte：Pod被驱赶了（node节点的资源不够部署pod。或者是资源不足，kubelet自动选择一个pod驱逐）

对pod内的容器使用节点资源的限制：

1、request：需要的资源

2、limit：限制--->最高能占用系统多少资源

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

两个限制：

cpu

cpu的限制格式：

1  2   0.5    0.2    0.1

1 可以占用1个cpu

2 可以占用两个

0.5 半个

0.2 一个cpu的五分之一

0.1是最小单位。

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

m来表示cpu

cpu的时间分片原理：

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

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

m：millicores 单位

1

2000m

1000m 也表示一个cpu

500m

100m就是最小的单位

内存：

单位

Ki（大小写）

Mi

Gi

Ti

以test1.yaml为例

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: centos
  name: centos
spec:
  replicas: 3
  selector:
    matchLabels:
      app: centos
  template:
    metadata:
      labels:
        app: centos
    spec:
      containers:
      - image: centos:7
        name: centos
        resources: 
          requests:
            memory: "256Mi"
            cpu: "0.5"
          limits:
            memory: "1Gi"
            cpu: "1"

查看状态

containers：

-  image: centos:7

   name: centos

   command: ["/bin/bash","-c","sleep 3600"]

9:56 需要指定后台进程，否则运行一次即退出了

   resources:

      requests:

      limits:

      memory: "256Mi"

      cpu："1"

在创建pod时，一定要给容器做资源限制。防止它把整个系统资源全部占满

k8s怎么设置拉取镜像的策略：

镜像默认策略：

ifNotPresent：如果本地镜像有，就不再拉取，本地没有才会去镜像仓库去拉取。（默认策略）

Always：不论镜像是否存在，创建时（包括重启时）都会重新拉取镜像。

Never：仅仅使用本地镜像，本地没有也不会主动拉取。

注：

都是本地部署，never

如果涉及到外部部署，默认策略（事前要把docker的镜像导入到目标主机）

Always：一般不用

imagePullPolicy：Never

10:13

Always策略例：

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都是成功。

x>=200 <400

适用于检查容器能否响应http的请求，web容器（nginx，tomcat）

3、tcpSocket：

        端口，对指定端口上的容器的ip地址进行tcp检查（三次握手），端口打开，认为探测成功。

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

80

999

telnet  192.168.233.30  80

诊断结果：

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

2、失败，存活探针就会重启

3、未知状态：诊断失败。

exec方式：

command [""]

livenessProbe：

  exec：

      command  ["/usr/bin/test", "-e", "/opt/123.txt"]

  initialDelaySeconds:  3   （核心指标，必须要有）

#表示容器启动之后多少秒来进行检测，时间不要设置的太短，可能导致无效探测

  periodSeconds：2   （必加）

#表示探针探测的间隔时间。每隔多少秒进行一次检查。应用的延迟敏感度。这个应用非常重要，是核心组件。(探测周期，必须要有)

  failureThreshold：2 （必加）

#表示如果探测失败，失败几次之后，把容器标记为不健康。

  successThreshold：1（可选加）

只要成功一次就标记为就绪，健康，ready，默认就是一次

  timeoutSeconds：1（可不加）

#表示每次探测的超时时间，在多少秒内必须完成检测。

成功次数可以不加，失败次数不加，默认是3次。

liveness  杀死容器重启。所有的探针策略伴随整个pod的生命周期，除了启动探针。

httpGet的方式

例：

livenessProbe

  httpGet：

     scheme：HTTP

     port：80

initialDelaySeconds:4

periodSeconds：2

指定path路径

path：/index.html

get http:ip:8080/index.html

200 400

11:48

tcpSocket：

  port:8080

  per

删除

kubectl apply -f

会把所有资源回收

telnet 检测端口是否正常

总结：

探针：

存活探针：检测失败之后，会杀死容器，然后重启。

探针将伴随整个容器的生命周期

exec 相当于执行了一个shell命令，容器里面执行

shell命令执行成功：

返回码：为0表示成功。

成功一次就是探测成功。

httpGet：对web容器发起了一次get请求，可以添加path，指定访问的资源。返回码在大于等于200，小于400的范围之内都算成功。

tcpSocket：相当于telnet，指定的容器监听端口是否打开，是否能和指定的容器监听端口进行通信。