K8S Pod状态为“被驱逐(evicted)”的解决方法

2024-03-30 00:04

本文主要是介绍K8S Pod状态为“被驱逐(evicted)”的解决方法,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

  • 驱逐原因
  • 问题复现
  • 解决方案

在Kubernetes中,pod是最小的调度单元。当Pod无法在所分配的节点上正常运行时,它可能会被驱逐(evicted)。这种情况可能是由多种原因引起,比如节点资源不足、Pod超出了所分配的资源限制、镜像拉取失败等。

驱逐原因

  • 节点资源不足:节点资源包括CPU、内存、存储空间等。当节点资源不足以满足Pod的资源需求时,调度器会选择其中一个或多个Pod驱逐出节点。
  • 超出资源限制:Pod可以指定资源上线,例如CPU和内存的限制。如果Pod使用的资源超过指定的限制,该Pod可能会被驱逐。
  • 镜像拉取失败:如果Pod所需的镜像无法拉取或拉取失败,K8S可能会重试一定次数后将其标记为“evicted”状态。

问题复现

(1)查看K8S中Pod的状态,发现部分pod的STATUS显示“evicted”状态:
在这里插入图片描述

(2)使用 kubectl describe 命令查看Pod的状态和事件。

kubectl describe pod <pod-name> -n <namespace-name>
kubectl describe pod knowledge-base-5799896986-zl55n -n asrank
[root@node-1 ~]# kubectl describe pod knowledge-base-5799896986-zl55n -n asrank
Name:           knowledge-base-5799896986-zl55n
Namespace:      asrank
Priority:       0
Node:           node-1/
Start Time:     Fri, 29 Mar 2024 11:12:16 +0800
Labels:         app=knowledge-baseistio.io/rev=defaultpod-template-hash=5799896986security.istio.io/tlsMode=istioservice.istio.io/canonical-name=knowledge-baseservice.istio.io/canonical-revision=latest
Annotations:    kubectl.kubernetes.io/default-container: knowledge-basekubectl.kubernetes.io/default-logs-container: knowledge-baseprometheus.io/path: /stats/prometheusprometheus.io/port: 15020prometheus.io/scrape: truesidecar.istio.io/status:{"initContainers":["istio-init"],"containers":["istio-proxy"],"volumes":["istio-envoy","istio-data","istio-podinfo","istiod-ca-cert"],"ima...
Status:         Failed
Reason:         Evicted
Message:        The node was low on resource: memory. Container knowledge-base was using 43775192Ki, which exceeds its request of 5000Mi. 
IP:             
IPs:            <none>
Controlled By:  ReplicaSet/knowledge-base-5799896986
Init Containers:istio-init:Image:      hub.pmlabs.com.cn/sail/istio/proxyv2:1.10.6Port:       <none>Host Port:  <none>Args:istio-iptables-p15001-z15006-u1337-mREDIRECT-i*-x-b*-d15090,15021,15020Limits:cpu:     2memory:  1GiRequests:cpu:        100mmemory:     128MiEnvironment:  <none>Mounts:/var/run/secrets/kubernetes.io/serviceaccount from default-token-cfzc5 (ro)
Containers:knowledge-base:Image:      hub.pmlabs.com.cn/asrank/knowledge-base:1.01.201Port:       9303/TCPHost Port:  0/TCPLimits:cpu:     24memory:  48GiRequests:cpu:     1memory:  5000MiEnvironment:PROFILE:         prodMYSQL_PASSWORD:  <set to the key 'MYSQL_ROOT_PASSWORD' in secret 'mysql-root-password'>  Optional: falseMounts:/data/ from datasets (rw)/etc/localtime from date-config (rw)/log/ from app-log (rw)/var/run/secrets/kubernetes.io/serviceaccount from default-token-cfzc5 (ro)istio-proxy:Image:      hub.pmlabs.com.cn/sail/istio/proxyv2:1.10.6Port:       15090/TCPHost Port:  0/TCPArgs:proxysidecar--domain$(POD_NAMESPACE).svc.cluster.local--serviceClusterknowledge-base.$(POD_NAMESPACE)--proxyLogLevel=warning--proxyComponentLogLevel=misc:error--log_output_level=default:info--concurrency2Limits:cpu:     2memory:  1GiRequests:cpu:      100mmemory:   128MiReadiness:  http-get http://:15021/healthz/ready delay=1s timeout=3s period=2s #success=1 #failure=30Environment:JWT_POLICY:                    first-party-jwtPILOT_CERT_PROVIDER:           istiodCA_ADDR:                       istiod.istio-system.svc:15012POD_NAME:                      knowledge-base-5799896986-zl55n (v1:metadata.name)POD_NAMESPACE:                 asrank (v1:metadata.namespace)INSTANCE_IP:                    (v1:status.podIP)SERVICE_ACCOUNT:                (v1:spec.serviceAccountName)HOST_IP:                        (v1:status.hostIP)CANONICAL_SERVICE:              (v1:metadata.labels['service.istio.io/canonical-name'])CANONICAL_REVISION:             (v1:metadata.labels['service.istio.io/canonical-revision'])PROXY_CONFIG:                  {}ISTIO_META_POD_PORTS:          [{"containerPort":9303,"protocol":"TCP"}]ISTIO_META_APP_CONTAINERS:     knowledge-baseISTIO_META_CLUSTER_ID:         KubernetesISTIO_META_INTERCEPTION_MODE:  REDIRECTISTIO_META_WORKLOAD_NAME:      knowledge-baseISTIO_META_OWNER:              kubernetes://apis/apps/v1/namespaces/asrank/deployments/knowledge-baseISTIO_META_MESH_ID:            cluster.localTRUST_DOMAIN:                  cluster.localMounts:/etc/istio/pod from istio-podinfo (rw)/etc/istio/proxy from istio-envoy (rw)/var/lib/istio/data from istio-data (rw)/var/run/secrets/istio from istiod-ca-cert (rw)/var/run/secrets/kubernetes.io/serviceaccount from default-token-cfzc5 (ro)
Volumes:istio-envoy:Type:       EmptyDir (a temporary directory that shares a pod's lifetime)Medium:     MemorySizeLimit:  <unset>istio-data:Type:       EmptyDir (a temporary directory that shares a pod's lifetime)Medium:     SizeLimit:  <unset>istio-podinfo:Type:  DownwardAPI (a volume populated by information about the pod)Items:metadata.labels -> labelsmetadata.annotations -> annotationslimits.cpu -> cpu-limitrequests.cpu -> cpu-requestistiod-ca-cert:Type:      ConfigMap (a volume populated by a ConfigMap)Name:      istio-ca-root-certOptional:  falsedate-config:Type:          HostPath (bare host directory volume)Path:          /etc/localtimeHostPathType:  datasets:Type:          HostPath (bare host directory volume)Path:          /var/asrank/knowledge-base/dataHostPathType:  app-log:Type:          HostPath (bare host directory volume)Path:          /var/log/app/asrank/knowledge-baseHostPathType:  default-token-cfzc5:Type:        Secret (a volume populated by a Secret)SecretName:  default-token-cfzc5Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 2snode.kubernetes.io/unreachable:NoExecute op=Exists for 2s
Events:Type     Reason   Age   From     Message----     ------   ----  ----     -------Warning  Evicted  59m   kubelet  The node was low on resource: memory. Container knowledge-base was using 43775192Ki, which exceeds its request of 5000Mi.Normal   Killing  59m   kubelet  Stopping container knowledge-baseNormal   Killing  59m   kubelet  Stopping container istio-proxy

在Events事件中可以看到,由于该Pod在运行中所需内存超出deployments中request的内存,导致该Pod的container被killed,Pod变为被驱逐(evicted)状态。

Events:Type     Reason   Age   From     Message----     ------   ----  ----     -------Warning  Evicted  59m   kubelet  The node was low on resource: memory. Container knowledge-base was using 43775192Ki, which exceeds its request of 5000Mi.Normal   Killing  59m   kubelet  Stopping container knowledge-baseNormal   Killing  59m   kubelet  Stopping container istio-proxy

解决方案

  1. 分析Pod资源使用情况:检查被驱逐的Pod的资源使用情况,如内存、CPU和磁盘使用率。可以使用kubectl describe pod <pod_name>命令查看Pod的状态和事件。
  2. 调整资源限制:根据实际需求调整Pod的资源限制,如增加内存限制或CPU限制。可以在Pod YAML文件中修改资源限制,然后使用kubectl apply -f <pod_yaml_file>命令更新Pod。
  3. 扩容节点:如果集群中的所有节点都面临资源不足的情况,可以考虑扩容节点以提供更多资源。可以使用云服务提供商的管理控制台或API扩容节点。
  4. 优化应用:优化应用程序以减少资源使用,如减少内存泄漏、优化CPU使用等。
  5. 使用优先级和抢占:为Pod设置优先级,以便在资源紧张时根据优先级驱逐Pod。可以在Pod的YAML文件中设置priorityClassName字段。
  6. 批量清理

根据上述分析,本次事件是由于资源不足导致的。可以根据实际需求调整Pod的资源限制,在Pod的YAML文件中修改资源限制,然后使用kubectl apply -f <pod_yaml_file>命令更新Pod。

有k9s界面的情况下,也可进行如下操作:
(1)基于k9s,输入 :deployments
(2)选择对应的Pod,按 e 键进入编辑模式
(3)修改 resource 资源信息,使得满足程序运行所需资源大小。如:

	requests:cpu: 10memory: 5Gilimits:cpu: 24memory: 48Gi

(4)清理Pod

确认没问题后再做删除被驱逐(evicted)的Pod。

# 查看被驱逐(evicted)的Pod
kubectl get pods -n <namespace-name> |grep  Evicted

在这里插入图片描述

# 执行批量删除
kubectl get pods -n <namespace-name> | grep Evicted | awk '{print $1}' | xargs kubectl delete pod -n <namespace-name>

在这里插入图片描述

这篇关于K8S Pod状态为“被驱逐(evicted)”的解决方法的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/860005

相关文章

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

hdu1565(状态压缩)

本人第一道ac的状态压缩dp,这题的数据非常水,很容易过 题意:在n*n的矩阵中选数字使得不存在任意两个数字相邻,求最大值 解题思路: 一、因为在1<<20中有很多状态是无效的,所以第一步是选择有效状态,存到cnt[]数组中 二、dp[i][j]表示到第i行的状态cnt[j]所能得到的最大值,状态转移方程dp[i][j] = max(dp[i][j],dp[i-1][k]) ,其中k满足c

【C++】_list常用方法解析及模拟实现

相信自己的力量,只要对自己始终保持信心,尽自己最大努力去完成任何事,就算事情最终结果是失败了,努力了也不留遗憾。💓💓💓 目录   ✨说在前面 🍋知识点一:什么是list? •🌰1.list的定义 •🌰2.list的基本特性 •🌰3.常用接口介绍 🍋知识点二:list常用接口 •🌰1.默认成员函数 🔥构造函数(⭐) 🔥析构函数 •🌰2.list对象

如何解决线上平台抽佣高 线下门店客流少的痛点!

目前,许多传统零售店铺正遭遇客源下降的难题。尽管广告推广能带来一定的客流,但其费用昂贵。鉴于此,众多零售商纷纷选择加入像美团、饿了么和抖音这样的大型在线平台,但这些平台的高佣金率导致了利润的大幅缩水。在这样的市场环境下,商家之间的合作网络逐渐成为一种有效的解决方案,通过资源和客户基础的共享,实现共同的利益增长。 以最近在上海兴起的一个跨行业合作平台为例,该平台融合了环保消费积分系统,在短

浅谈主机加固,六种有效的主机加固方法

在数字化时代,数据的价值不言而喻,但随之而来的安全威胁也日益严峻。从勒索病毒到内部泄露,企业的数据安全面临着前所未有的挑战。为了应对这些挑战,一种全新的主机加固解决方案应运而生。 MCK主机加固解决方案,采用先进的安全容器中间件技术,构建起一套内核级的纵深立体防护体系。这一体系突破了传统安全防护的局限,即使在管理员权限被恶意利用的情况下,也能确保服务器的安全稳定运行。 普适主机加固措施:

webm怎么转换成mp4?这几种方法超多人在用!

webm怎么转换成mp4?WebM作为一种新兴的视频编码格式,近年来逐渐进入大众视野,其背后承载着诸多优势,但同时也伴随着不容忽视的局限性,首要挑战在于其兼容性边界,尽管WebM已广泛适应于众多网站与软件平台,但在特定应用环境或老旧设备上,其兼容难题依旧凸显,为用户体验带来不便,再者,WebM格式的非普适性也体现在编辑流程上,由于它并非行业内的通用标准,编辑过程中可能会遭遇格式不兼容的障碍,导致操

透彻!驯服大型语言模型(LLMs)的五种方法,及具体方法选择思路

引言 随着时间的发展,大型语言模型不再停留在演示阶段而是逐步面向生产系统的应用,随着人们期望的不断增加,目标也发生了巨大的变化。在短短的几个月的时间里,人们对大模型的认识已经从对其zero-shot能力感到惊讶,转变为考虑改进模型质量、提高模型可用性。 「大语言模型(LLMs)其实就是利用高容量的模型架构(例如Transformer)对海量的、多种多样的数据分布进行建模得到,它包含了大量的先验

90、k8s之secret+configMap

一、secret配置管理 配置管理: 加密配置:保存密码,token,其他敏感信息的k8s资源 应用配置:我们需要定制化的给应用进行配置,我们需要把定制好的配置文件同步到pod当中容器 1.1、加密配置: secret: [root@master01 ~]# kubectl get secrets ##查看加密配置[root@master01 ~]# kubectl get se

【北交大信息所AI-Max2】使用方法

BJTU信息所集群AI_MAX2使用方法 使用的前提是预约到相应的算力卡,拥有登录权限的账号密码,一般为导师组共用一个。 有浏览器、ssh工具就可以。 1.新建集群Terminal 浏览器登陆10.126.62.75 (如果是1集群把75改成66) 交互式开发 执行器选Terminal 密码随便设一个(需记住) 工作空间:私有数据、全部文件 加速器选GeForce_RTX_2080_Ti

K8S(Kubernetes)开源的容器编排平台安装步骤详解

K8S(Kubernetes)是一个开源的容器编排平台,用于自动化部署、扩展和管理容器化应用程序。以下是K8S容器编排平台的安装步骤、使用方式及特点的概述: 安装步骤: 安装Docker:K8S需要基于Docker来运行容器化应用程序。首先要在所有节点上安装Docker引擎。 安装Kubernetes Master:在集群中选择一台主机作为Master节点,安装K8S的控制平面组件,如AP