POD进阶

2301_79410672

已于 2024-01-05 16:51:55 修改

阅读量1k

点赞数 19

文章标签： linux 运维服务器

于 2024-01-04 17:33:35 首次发布

本文链接：https://blog.csdn.net/2301_79410672/article/details/135383579

版权

Pod的生命周期开始

1	k8s的pod重启策略：Always(默认，deployment的yaml文件只能是Always)pod的yaml文件三种模式都可以，不论正常退出还是非正常退出都重启
2	OnFailure:只有状态码非0才会重启，正常退出是不重启的
3	Never：正常退出和非正常退出都不重启
	这三个状态都是容器退出了pod才会重启或不重启 Pod可以有多个容器，只要有一个容器退出，整个pod都会重启，pod内的所有容器都会重启

docker的重启策略

never	Docker：的默认策略是never
on-Failure	也就是非正常退出才会重启容器
always	只要容器退出都会重启
Unless-stopped	只要容器退出就会重启，docker守护进程已经停止的容器，不再重启

Yaml文件快速生成

[root@master01 ~]# kubectl create deployment nginx1 --image=nginx:1.22 --replicas=1 --dry-run=client
deployment.apps/nginx1 created (dry run)
[root@master01 ~]# kubectl create deployment nginx1 --image=nginx:1.22 --replicas=1 --dry-run=client -o yaml > /opt/test1.yaml
#--dry-run=client 表示只是调用了api的对象，不执行命令 ， -o yaml表示指定为yaml文件

[root@master01 opt]# kubectl expose deployment nginx-chen --port=80 --target-port=80 --type=NodePort --dry-run=client -o yaml > /opt/test1-service.yaml
#生成service模版

Pod状态

常见

Crashloopbackoff：

表示pod当中的容器已经退出，kubelet正在重启

Imagepullbackoff：

表示正在重试拉取镜像

Errimagepull：

拉取镜像出错了，原因：网速太慢，镜像名字写错了，镜像仓库挂了

Evicte：

pod被驱赶，node节点上的资源不够部署pod或者资源不足，kubelet自动选择一个pod驱逐

CrashLoopBackOff：容器退出，kubelet正在将它重启
InvalidImageName：无法解析镜像名称
ImageInspectError：无法校验镜像
ErrImageNeverPull：策略禁止拉取镜像
ImagePullBackOff：正在重试拉取
RegistryUnavailable：连接不到镜像中心
ErrImagePull：通用的拉取镜像出错
CreateContainerConfigError：不能创建kubelet使用的容器配置
CreateContainerError：创建容器失败
m.internalLifecycle.PreStartContainer 执行hook报错
RunContainerError：启动容器失败
PostStartHookError：执行hook报错
ContainersNotInitialized：容器没有初始化完毕
ContainersNotReady：容器没有准备完毕
ContainerCreating：容器创建中
PodInitializing：pod 初始化中
DockerDaemonNotReady： docker还没有完全启动
NetworkPluginNotReady：网络插件还没有完全启动
Evicte: pod被驱赶

Pod内的容器使用节点资源的限制

request

需要的资源

Limit

限制最高能占用系统多少资源

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

两个限制：

Cpu：cpu的限制格式：1，2，0.5,0.2,0.3

1表示可以占用1个cpu

2可以占用2个cpu

0.5可以占用半个

0.2：一个cpu的五分之一

0.1是最小单位

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

m来表示cpu

Cpu时间分片原理：cpu时间分片，通过周期性的轮流分配cpu时间给各个进程，多个进程可以在cpu上交替执行，在k8s中就是表示占用cpu的比率：m：millicores：单位1000m表示1个cpu，其他以此类推

内存

内存：都是大写开头后面小写

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: centos
  name: centos
spec:
  replicas: 1
  selector:
    matchLabels:
      app: centos
  template:
    metadata:
      labels:
        app: centos
    spec:
      containers:
      - image: centos:7
        name: centos
        resources:
          limits:
            memory: "1Gi"
            cpu: "1"
#在创建pod时，一定要给容器做资源限制

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

ifNotPresent	果本地镜像有，就不再拉取，本地没有才会去镜像仓库拉取（默认策略）
Always	不论镜像是否存在，创建时(重启)都会拉取镜像
Never	仅仅使用本地镜像，本地没有也不会主动拉取
	如果都是本地部署，那么用Never 如果涉及到外部部署，默认策略（事前要把docker的镜像导入到目标主机） Always：一般不用

pod的容器健康检查

	探针：Probe k8s对容器执行的定期诊断检查探针有三种规则
存活探针	livenessProbe 探测容器是否正常运行，如果探测失败，会杀掉容器，容器会根据重启策略来决定是否重启，不是杀掉pod，只对容器
流量探针/就绪探针	readinessProbe 探测容器是否进入ready状态，并做好接收请求的准备，如果探测失败 READY 0/1没有进入ready状态，service会把这个资源对象的端点从endpoints中移除，service也不会把请求转发到这个pod
启动探针	startupProbe 只是在容器的启动后开始检测，容器内的应用是否启动成功，在启动探测成功之前，所有的其他的其他探针都会处于禁用状态，一旦启动探针结束，后续的操作不再受启动探针的影响
	结论：在一个容器当中可以有多个探针，启动探针只在容器启动时探测，存活探针，就绪探针

probe的检查方法

exec探针	在容器内部执行命令，如果命令的返回码是0，表示成功，适用于需要容器neutral自定义命令来检查容器的健康状态情况 Exec相当于执行了一个shell命令：容器里面执行 Shell命令执行成功：返回码：0表示成功成功一次就是探测成功
httpGet	对指定ip+端口的容器发送一个httpget的请求，响应状态码大于等于200，小于400都是成功x>=200<400，适用于检查容器能否响应http的请求，web容器(nginx,tomcat) 对web容器发起了一次get请求，可以添加path，指定访问的资源，返回码在大于等于200，小于400的范围内都算成功
tcpSocket	端口，对指定端口上的容器ip地址进行tcp检查(三次握手)，端口打开，认为探测成功，检查特定容器的端口监听状态相当于telnet，指定的容器监听端口是否打开，是否能和指定的容器监听端口进行通信
	诊断的结果 1.成功，容器通过了，正常运行 2.失败，存活探针会重启 3.未知，诊断失败

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: centos
  name: centos
spec:
  replicas: 1
  selector:
    matchLabels:
      app: centos
  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"]
          initiaDelaySeconds: 3
#表示容器启动之后多少秒来进行探测，时间不要设置的太短，可能导致无效探测
          periodSeconds: 2
#表示探针探测的间隔时间，每隔多少秒进行一次检查，应用的延迟敏感度，这个应用非常重要，是核心组件
          failureThreshold: 2
#表示如果探测失败，失败几次之后，把容器标记为不健康
          successThreshold: 1
#只要成功一次就标记位就绪，健康，ready
          timeoutSeconds: 1
#表示每次探测的超时时间，在多少秒内必须完成探测

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

探针重启的方式

存活探针

livenessprobe

它是杀死容器，重启

就绪探针

readinessProbe

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

tcpSocket只是监听容器上的业务端口能否正常通信，添加端口8081，8080正常端口是可以访问的，如果更改了容器的启动端口，监听的端口也要更改

启动探针

startupProbe

如果探测失败，pod的状态是running但是notready，启动探针探测容器失败之后，会直接重启pod

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

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

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

如果重启了pod之后，相当于重新部署(重构)了一个初始版的新的容器，之前删除掉的需要检测文件，又重新生成，故而exec检测成功，但容器内之前的配置都会消失

1	在一个yaml当中可以有多个探针，启动，存活，就绪，都针对一个容器
2	启动探针的优先级最高，只有启动探针成功，后续的探针才会执行
3	启动探针成功之后，后续除非重启pod，不会再触发启动探针
4	在pod的生命周期中，伴随pod的一直存在，一直探测的是存活探针和就绪探针
5	在pod的生命周期当中，后续的条件是满足那个探针的条件，触发哪个探针的条件
6	就绪探针，如果不影响容器运行，status:running ，这个时候不会重启，但是容器退出的话，就绪探针也会重启

容器启动和退出时的动作

Poststart	容器启动钩子，容器启动之后触发的条件
PreStop	容器退出钩子，容器退出之后触发的条件

apiVersion: v1
kind: Pod
metadata:
spec:
  containers:
    - name: nginx1
      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 666 >> /opt/123.text ; sleep 10"]
        preStop:
          exec:
            command: ["/bin/bash","-c","echo 666 >> /opt/123.txt"]
  volumes:
  - name: test1
    hostPath:
      path: /opt/test
      type: DirectoryOrCreate
#声明的是node节点上和容器内的/opt挂载目录
#挂载卷的名称要和挂载的容器内挂载卷名称要一一对应
#hostpath：指定和容器的挂载目录
#type：Directoryorcreate：如果节点上的目录不存在，自动创建该目录
#pod会经常被重启，销毁，一旦容器和node节点欧了挂载卷，数据不会丢失

	启动和退出的作用
1	启动可以自定义配置容器的内部变量环境
2	通知机制，告诉用户容器启动完毕
3	退出时，可以执行自定义命令，删除或者生成一些必要的程序，自定义销毁方式以及自定义资源回收的方式以及容器的退出等待时间

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: tomcat1
  name: tomcat1
spec:
  containers:
  - image: tomcat:8.0.52
    name: tomcat1
    volumeMounts:
    - name: test1
      mountPath: /opt
      readOnly: false
    lifecycle:
      postStart:
        exec:
          command: ["/bin/bash","-c","echo 666 >> /opt/123.text ; sleep 10"]
      preStop:
        exec:
          command: ["/bin/bash","-c","echo 666 >> /opt/123.txt"]
    startupProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 4
      periodSeconds: 2
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 4
      periodSeconds: 2
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 4
      periodSeconds: 2
  volumes:
  - name: test1
    hostPath:
      path: /opt/test
      type: DirectoryOrCreate