k8s探针

k8s的pod重启策略

1,Deploy 的yaml文件只能是always。Pod的 yaml三种模式都可以。

2,OnFailure:只有状态码非0才会重启。正常状态不重启的。

3,Never:正常退出和非正常退出都不重启。容器退出了,pod才会重启。

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

Docker的重启策略:

  1. docker的默认策略是never。
  2. on-failure:非正常退出。才会重启容器
  3. Always:只要容器退出都会重启
  4. Unless-stopped:只要容器退出就会重启,docker守护进程时已经停止的容器,不再重启。

单机部署:docker足够了

集群化部署k8s

Yaml文件快速生成模版:

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

生成pod 的yaml模版

生成service的yaml模版

pod的状态:

Crashloopbackoff:pod当中的容器退出。Kubelet正在重启。

Imagepullbackoff:正在重试拉取镜像。

Errimagepull:拉取镜像出错了(1网速太慢,2镜像名称写错,3镜像仓库挂了)

Evicte:pod被驱赶(node节点的资源不够部署pod,或者是资源不足,kubelet自动选择一个pod驱逐)

InvalidImageName:    无法解析镜像名称

ImageInspectError:   无法校验镜像

ErrImageNeverPull:   策略禁止拉取镜像

ImagePullBackOff:    正在重试拉取

RegistryUnavailable: 连接不到镜像中心

ErrImagePull:        通用的拉取镜像出错

CreateContainerConfigError: 不能创建kubelet使用的容器配置

CreateContainerError: 创建容器失败

m.internalLifecycle.PreStartContainer 执行hook报错

RunContainerError:   启动容器失败

PostStartHookError:   执行hook报错

ContainersNotInitialized: 容器没有初始化完毕

ContainersNotReady:   容器没有准备完毕

ContainerCreating:    容器创建中

PodInitializing:pod   初始化中

DockerDaemonNotReady:  docker还没有完全启动

NetworkPluginNotReady: 网络插件还没有完全启动

如何对pod内的容器使用节点资源的限制:

  1. request:需要的资源
  2. Limit:最高能占用系统多少资源。 limit:需要多少,最多也只能这么多。

对pod的两个限制:

cpu    内存

Cpu:在k8s集群中限制格式:

  1. 数字加小数点   1可以占用一个CPU   2可以占用两个   0.5占半个CPU  0.2一个CPU的五分之一   要么是整数,要么就是小数点后只能跟一位,最小单位0.1

   m来表示CPU

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

   M:millicores单位。 100m就是最小单位。

内存:

Ki   Mi    Gi    Ti   注意大写的。  

在创建pod时一定要给容器资源做限制。

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

默认策略:

IFNotPresent:如果本地镜像有,就不再拉取,本没有才会去镜像仓库拉取。

Always:不论镜像是否存在,创建时(重启)都会重新拉取镜像。

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

Pod的容器健康检查:

探针  

Probe

K8s对容器执行的定期检查,诊断。

探针有三种规则:
     1,存活探针:livenessProbe,探测容器是否正常运行,如果发现探测失败,会杀容器,容器会根据重启策略来决定是否重启,不是杀掉pod。

      2,就绪探针:探测容器是否进入ready状态,并做好接受请求的准备。

             探测失败  READY 0/1 容器当前没有进入ready状态,service会把这个资源对象的端点从当中剔除2,service也不会把请求转发到pod。

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

在一个容器当中可以有多个探针。

启动探针:只在容器启动时探测

Probe的检测方法:

  1. exec探针:在容器内部执行命令,如果命令的返回码是0,表示成功。适用于需要在容器内自定义命令来检查容器的健康状况。
  2. httpGet:指定ip+端口的容器发送一个httpget的请求。响应状态码大于等于200,小于400都是成功。200-400     x >=200<400  适用于检测容器能否响应http的请求,web容器(nginx tomcat)
  3. tcpSocket: 端口,对指定端口上的容器的ip地址进行tcp检查(三次握手)端口打开,认为探测成功。  检查特定容器的端口监听状态。

诊断结果:

  1. 成功 容器通过了,正常运行。
  2. 失败 存活探针会重启。
  3. 未知状态 诊断失败。

总结:

探针的三个方法:

存活探针:检查失败之后,会杀死容器,然后重启。探针将伴随整个容器的生命周期。

Exec 相当于执行了一个shell命令:容器里面执行

Shell命令执行成功。

返回码:0表示成功。

成功一次就是探测 成功

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

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

  • 16
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
k8s探针可以用于检测应用程序的健康状态,并根据结果决定是否将流量转发到该容器。对于PHP应用程序,可以使用以下方法实现k8s探针的健康检查: 1. HTTP 探针:通过向应用程序的某个HTTP端点发送请求,来检查应用程序的健康状态。你可以在应用程序中创建一个特定的路径或端点,用于检查PHP应用程序的健康状况。例如,可以使用`/health`路径作为探针路径。当k8s探针发送HTTP请求到该路径时,应用程序可以返回一个合适的HTTP状态码来指示其健康状态。 2. TCP 探针:通过尝试与应用程序的特定TCP端口建立连接来检查应用程序的健康状态。对于PHP应用程序,你可以使用应用程序监听的端口作为探针目标端口,并通过尝试与该端口建立连接来检查应用程序的健康状况。 至于使用gRPC实现k8s探针的健康检查,你可以按照以下步骤进行操作: 1. 在你的PHP应用程序中,使用gRPC框架创建一个gRPC服务。 2. 在该gRPC服务中实现一个健康检查方法,该方法可以返回一个表示应用程序健康状态的gRPC响应。 3. 在k8s的Pod配置中,配置一个gRPC探针,指定要调用的gRPC服务和健康检查方法。 4. k8s将定期调用该gRPC探针,并根据返回的状态决定容器的健康状况。 需要注意的是,实现gRPC探针需要你的PHP应用程序具备gRPC支持,并且在k8s集群中使用的镜像中已经安装了gRPC扩展。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值