宜春网站建设联系方式/线上营销推广公司

目录

一、docker的重启方式和K8S重启方式

1、Pod的重启方式：

2、docker的重启策略：

二、yaml文件快速生成：

三、pod的状态：

四、Pod的资源限制

1、限制的方式和种类

2、CPU的限制的格式：

五、K8S拉取镜像的策略：

六、pod内的容器的健康检查—探针：

1、探针：probe

2、探针种类：

1.1、存活探针：livenessProbe

1.2、就绪探针

1.3、启动探针

3、probe的检查方法：

3.1、exec：

3.2、httpGet：

3.3、tcpSocket：

4、诊断结果：

5、设置探测条件：

七、livenessProbe存活探针健康监测实例：

1、存活探针的exec检查方式：

2、存活探针的httpGet检查方式：

3、存活探针的tcpSocket检查方式：

---

一、docker的重启方式和K8S重启方式

1、Pod的重启方式：

Always：无论正常退出还是非正常退出都重启

        deployment的yaml文件只能是Always

        pod的yaml三种模式都可以

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

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

容器退出了，pod才会重启

pod可以有多个容器

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

2、docker的重启策略：

Never：docker的默认策略，正常退出和非正常退出都不重启

on-Failure：非正常退出时才会重启容器

Always：只要容器退出都是重启

unless-stoped：只要容器退出就会重启，docker守护进程启动时已经停止的容器，不再重启

意思是docker运行时，退出会重启，docker关闭，一并关闭的容器不会重启

单机部署：docker足够了

集群化部署：K8S

二、yaml文件快速生成：

#快速生成pod创建yaml
kubectl create deployment nginx --image=nginx1.22 --replicas=3 --dry-run=client -o yaml > /opt/demo1.yaml#快速生成service的yaml
kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort --dry-run=client -o yaml > /opt/demo2.yaml--dry-run=client：只调用api命令，不创建

三、pod的状态：

pending挂起状态：pod已被创建，但是尚未分配到运行他的node节点（1、节点上资源不够  2、节点上资源不够）
Running运行中：pod已经被分配到了node节点，pod内部的所用容器都已经启动，运行状态正常
competed/successded：容器内部的进程运行完毕正常退出，没有发生错误
failed：pod中的容器非正常退出。发生了错误，需要通过查看详情或者日志定位问题
UNkown：由于某些原因，K8S集群无法获取pod的状态。apiserver出了问题
terminating：终止中，pod正在被删除，里面的容器正在终止。终止过程中，涉及资源回收、垃圾清理、终止过程中需要执行的命令
crashloopbackoff：pod当中的容器退出，kubelet正在重启
imagepullbackoff：正在重试拉取镜像
errimagepull：拉取镜像出错了（1、网速太慢 2、镜像名写错了 3、镜像仓库挂了）
Evicte：pod被驱赶了（node节点的资源不够部署pod，或者是资源不足，kubelet自动选择一个pod驱逐）
InvalidImageName：无法解析镜像名称
ImageInspectError：无法校验镜像
ErrImageNeverPull：策略禁止拉取镜像
RegistryUnavailable： 连接不到镜像中心
CreateContainerConfigError：不能创建kubelet使用的容器配置
CreateContainerError： 创建容器失败
m.internalLifecycle.PreStartContainer 执行hook报错
RunContainerError：启动容器失败
PostStartHookError：执行hook报错
ContainersNotInitialized： 容器没有初始化完毕
ContainersNotReady：容器没有准备完毕
ContainerCreating：容器创建中
PodInitializing：pod初始化中
DockerDaemonNotReady：docker还没有完全启动
NetworkPluginNotReady： 网络插件还没有完全启动
Evicte: pod被驱赶

四、Pod的资源限制

1、限制的方式和种类

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

1、request：pod内容器需要的资源

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

一般在工作中，只做一个limit，需要多少，最多也只能占这么多

两个限制：CPU和内存限制

2、CPU的限制的格式：

①、数字加小数点：1、2、0.5、0.3、0.2、0.1

要么是整数数，要么小数点后只能跟一位

1：占用一个cpu
2：占两个cpu
0.5：半个cpu
0.2：只能使用一个cpu的1/5
0.1：最小的单位，只占用1/10

②、m来表示cpu：millicores。1000m、2000m、100m

cpu时间分片原理：通过周期性的轮流分配cpu时间给各个进程。多个进程可以在cpu上交替执行。在K8S中就表示占用cpu的比率

2000m：2个cpu
1000m：1个cpu
500m：半个cpu
100m：最小单位1/10个cpu

2、内存的限制：
单位：大写的开头+小写的i

Ki、Mi、Gi、Ti

apiVersion: apps/v1
kind: Deployment
metadata:labels:
app: centosname: centos
spec:replicas: 1selector:
matchLabels:app: centosstrategy:template:
metadata:labels:
app: centos
spec:containers:- image: centos:7
name: centos
command: ["/bin/bash", "-c", "sleep 3600"]
resources:requests:
memory: "256Mi"
cpu: "0.5"limits:
memory: "1Gi"
cpu: "1"
#在创建pod时，一定要给容器做资源限制。可以直接只做limit限制

stress压力测试工具

超过资源限制，进程会被立即杀死

五、K8S拉取镜像的策略：

ifNotPresent：默认策略，如果本地镜像有，就不在拉取，本地没有就去镜像仓库拉取

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

Never：仅仅使用本地镜像

如果没有特殊需求，默认即可，不用配置

都还是本地部署，用Never即可

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

Always：一般不用

六、pod内的容器的健康检查—探针：

1、探针：probe

是K8S对容器执行的定期检查诊断

探针都是对容器进行操作

所有的探针策略伴随整个pod的生命周期。除了启动探针。

2、探针种类：

1.1、存活探针：livenessProbe

探测容器是否正常运行，如果发现探测失败，会杀掉容器，容器会根据重启策略来决定是否重启。不是杀掉pod，只是对容器操作。特点就是杀死容器，重启

1.2、就绪探针

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

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

1.3、启动探针

只是在容器的启动后开始检测，容器内的应用是否启动成功。在启动探测成功之前，所有的其他探针都会处于禁用状态，一旦启动探针结束，后续的操作不再受启动探针的影响

在一个容器中可以有多个探针，也可以只有一个探针

3、probe的检查方法：

以上三种探针都能用下面的检查方式

3.1、exec：

在容器内部执行命令，如果命令的返回码是0，表示成功

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

3.2、httpGet：

对指定ip+端口的容器发送一个httpget的请求。响应状态码在200-400

内都是成功 200<= X <400 之间都算成功

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

3.3、tcpSocket：

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

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

类似于telnet 192.168.233.30 80 检查80端口是否正常

4、诊断结果：

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

2、失败：

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

        就绪探针：Pod状态是Running，ready状态是notready，容器不可以提供正常的业务访问，就绪探针不会重启

        启动探针：Pod的状态是Running，ready状态是notready。启动探针探测容器失败，会重启容器

3、未知：诊断失败

5、设置探测条件：

initialDelaySeconds: 3
#表示容器启动之后多少秒来进行探测，时间不要设置的太短，否则容器没启动就开始探测，无效探测
periodSeconds: 2
#表示探针探测的间隔时间。每隔多少秒进行一次检查。范围是看应用的延迟敏感度。非常重要的核心组件，间隔设置小一点
failureThreshold: 2
#如果探测失败，失败几次之后，把容器标记为不健康。
successThreshold: 1
#只要成功一次就标记为就绪、健康、ready。这里的值只能是1，所以这项可以不加
timeoutSeconds: 1
#表示每次探测的超时时间，这个时间要比间隔时间小，意思是在1秒内要完成探测

delay=3s：启动3s后开始检测
timeout=1s：每次检测时间不能超过1s
period=2s：检测的间隔2s
success=1：只要检测成功1次，视为检测成功
failure=2：连续检测失败两次，视为检测失败

七、livenessProbe存活探针健康监测实例：

1、存活探针的exec检查方式：

apiVersion: apps/v1
kind: Deployment
metadata:labels:
app: centosname: centos
spec:replicas: 1selector:
matchLabels:app: centosstrategy:template:
metadata:labels:
app: centos
spec:containers:- image: centos:7
name: centos
command: ["/bin/bash", "-c", "touch /opt/123.txt ; sleep 3600"]livenessProbe:exec:
command: ["/usr/bin/test" , "-e", "/opt/123.txt"]
#检测/opt/123.txt文件是否存在，存在则检测成功initialDelaySeconds: 3
#表示容器启动之后多少秒来进行探测，时间不要设置的太短，否则容器没启动就开始探测，无效探测periodSeconds: 2
#表示探针探测的间隔时间。每隔多少秒进行一次检查。范围是看应用的延迟敏感度。非常重要的核心组件，间>
隔设置小一点failureThreshold: 2
#如果探测失败，失败几次之后，把容器标记为不健康。successThreshold: 1
#只要成功一次就标记为就绪、健康、ready。这里的值只能是1，所以这项可以不加timeoutSeconds: 1
#表示每次探测的超时时间，这个时间要比间隔时间小，意思是在1秒内要完成探测

删除文件，模拟探针检测失效

kubectl exec -it centos-797bc57596-dcvzh -- rm -rf /opt/123.txt

这里重新拉取容器之后，因为command，/opt/123.txt会自动生成，所以拉取一次，容器又Running了

2、存活探针的httpGet检查方式：

apiVersion: v1
kind: Pod
metadata:name: nginxspec:containers:- image: nginx:1.22
name: nginxlivenessProbe:httpGet:
scheme: HTTP
port: 80initialDelaySeconds: 4periodSeconds: 2

用Tomcat测试：

apiVersion: v1
kind: Pod
metadata:name: tomcatspec:containers:- image: tomcat:8.0.52
name: tomcatlivenessProbe:httpGet:
scheme: HTTP
port: 8080
path: /index.htmlinitialDelaySeconds: 4periodSeconds: 2
#相当于访问http://ip/index.html

将path改成 index.jsp

3、存活探针的tcpSocket检查方式：

kind: Pod
metadata:name: tcp-tomcatspec:containers:- image: tomcat:8.0.52
name: tcp-tomcat
livenessProbe:tcpSocket:
port: 8080initialDelaySeconds: 4periodSeconds: 2

检测端口8080，端口打开表示检测成功：

将端口改成8081：

八、readinessProbe就绪探针健康检测实例：

readinessProbe：就绪探针

探测失败：Pod状态是Running，ready状态是notready，容器不可以提供正常的业务访问

1、exec：

apiVersion: v1

kind: Pod

metadata:

  name: exec

spec:

  containers:

  - image: centos:7

    name: exec

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

    readinessProbe:

      exec:

       command: ["/usr/bin/test", "-e", "/etc/passwd"]

      initialDelaySeconds: 4

      periodSeconds: 2

模拟检测失败：

2、httpGet：

apiVersion: v1

kind: Pod

metadata:

  name: httpget

spec:

  containers:

  - image: tomcat:8.0.52

    name: httpget

    readinessProbe:

      httpGet:

        scheme: HTTP

        port: 8080

        path: /index.jsp

      initialDelaySeconds: 4

      periodSeconds: 2

进入容器将index.jsp删除。模拟检测失败

3、tcpSocket：

apiVersion: v1

kind: Pod

metadata:

  name: tcp

spec:

  containers:

  - image: tomcat:8.0.52

    name: tcp

    readinessProbe:

      tcpSocket:

        port: 8080

      initialDelaySeconds: 4

      periodSeconds: 2

tcpSocket：只是监控容器中的业务端口能否正常通行。

8081端口没有，但是8080还在，正常的端口还是可以访问的

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

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

九、startupProbe启动探针的健康检查实例：

探测失败：Pod的状态是Running，ready状态是notready。启动探针探测容器失败，会重启容器

启动探针如果没有成功之前，后续的探针都不会执行

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

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

apiVersion: v1

kind: Pod

metadata:

  name: tomcat

spec:

  containers:

  - image: tomcat:8.0.52

    name: tomcat

    startupProbe:

      exec:

        command: ["/usr/bin/test", "-e", "/etc/passwd"]

      initialDelaySeconds: 4

      periodSeconds: 2

    livenessProbe:

      exec:

        command: ["/usr/bin/test", "-e", "/etc/passwd"]

      initialDelaySeconds: 4

      periodSeconds: 2

    readinessProbe:

      httpGet:

        scheme: HTTP

        port: 8080

        path: /index.jsp

      initialDelaySeconds: 4

      periodSeconds: 2

总结：

1、在一个yaml文件中，可以有多个探针。启动、存活、就绪都针对一个容器

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

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

4、在pod的生命周期中，一直存在，一直探测的是存活探针和继续探针

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

6、就绪探针，如果不影响容器运行，status:Running，这个时候不会重启，但是，容器退出的话就绪探针也会重启（决定的关键是Always，重启策略）

十、容器启动和退出时的动作—容器钩子：

postStart：容器启动的钩子，容器启动之后触发的条件

preStop：容器退出的钩子，容器退出之后触发的条件

apiVersion: v1

kind: Pod

metadata:

  name: nginx2

spec:

  containers:

    - name: nginx2

      image: centos:7

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

      volumeMounts:

      - name: test1

        mountPath: /opt

        readOnly: false

#声明容器内部的挂载目录，要给这个挂载卷取一个名字，不能重复

#想要读写权限：readOnly: false

      lifecycle:

        postStart:

          exec:

            command: ["/bin/bash", "-c", "echo hello from start >> /opt/123.txt ; sleep 10"]

        prestop:

          exec:

            command: ["/bin/bash", "-c", "echo hello from stop >> /opt/123.txt"]

  volumes:

  - name: test1

    hostPath:

      path: /opt/test11

      type: DirectoryOrCreate

#声明node节点上和容器内/opt的挂载目录

#挂载卷的名称和要挂载的容器内挂载卷名称要一一对应

#hostPath：指定和容器的挂载目录

#type: DirectoryOrCreate表示如果节点上的目录不存在，自动创建该目录

#pod会经常被重启，销毁。一旦容器和node节点做了挂载卷，数据不会丢失

启动和退出的作用：

1、启动可以自定义配置容器的内部环境变量

2、通知机制，告诉用户容器启动完毕

3、退出时，可以执行自定义命令，删除或者生成一些必要的程序，自定义销毁方式以及自定义资源回收的方式，以及容器的退出等待时间

pod的重启策略：

在K8S中都是重启pod

Always：默认策略，当pod内的容器退出，不论一个还是多个，整个pod都会重启

Never：当pod内的容器退出时，退出一个还是退出N个，pod都不重启

OnFailure：当pod内的容器退出时，状态码为0，整个pod都不会重启，只有一个或者N个容器，非正常退出（状态码非0），整个pod才会重启

重启了容器相当于重启了pod

练习：

在这个pod的生命周期时间中，把启动探针、存活探针和就绪探针加入到yaml文件中

apiVersion: v1

kind: Pod

metadata:

  name: tomcat

spec:

  containers:

    - name: tomcat

      image: tomcat:8.0.52

      startupProbe:

        tcpSocket:

          port: 8080

        initialDelaySeconds: 4

        periodSeconds: 2

      livenessProbe:

        exec:

          command: ["/usr/bin/test", "-e", "/usr/local/tomcat/webapps/ROOT/index.jsp"]

        initialDelaySeconds: 4

        periodSeconds: 2

      readinessProbe:

        httpGet:

          scheme: HTTP

          port: 8080

          path: /index.jsp

        initialDelaySeconds: 4

        periodSeconds: 2

      volumeMounts:

      - name: test1

        mountPath: /opt

        readOnly: false

#声明容器内部的挂载目录，要给这个挂载卷取一个名字，不能重复

#想要读写权限：readOnly: false

      lifecycle:

        postStart:

          exec:

            command: ["/bin/bash", "-c", "echo hello from start >> /opt/123.txt ; sleep 10"]

        preStop:

          exec:

            command: ["/bin/bash", "-c", "echo hello from stop >> /opt/123.txt"]

  volumes:

  - name: test1

    hostPath:

      path: /opt/test11

      type: DirectoryOrCreate

#声明node节点上和容器内/opt的挂载目录

#挂载卷的名称和要挂载的容器内挂载卷名称要一一对应

#hostPath：指定和容器的挂载目录

#type: DirectoryOrCreate表示如果节点上的目录不存在，自动创建该目录

#pod会经常被重启，销毁。一旦容器和node节点做了挂载卷，数据不会丢失