云服务器内容精选
-
排查项一：查看端口是否冲突 按照使用kubectl配置好kubectl。 在页面上单击失败的工作负载，进入负载详情界面，查看Pod列表，获取Pod名字。 查看失败的容器的名称。 kubectl describe pod $name -n $namespace | grep "Error syncing pod failed to" 图1 查看失败的容器的名称 查看退出容器的错误日志。 kubectl logs $podName -n $namespace -c $containerName 此种问题有如下解决方法：重新创建工作负载，并配置正确的端口，确保端口不冲突。
-
排查项二：用户自身业务BUG 请检查工作负载启动命令是否正确执行，或工作负载本身bug导致容器不断重启。 按照使用kubectl配置好kubectl。 在页面单击失败的工作负载，进入负载详情界面，查看Pod列表，获取Pod名字。 查看失败的容器的名称。 kubectl describe pod $name -n $namespace | grep "Error syncing pod failed to" 图2 查看失败的容器的名称 查看退出容器的错误日志。 kubectl logs $podName -n $namespace -c $containerName 根据日志提示修复工作负载本身的问题。 图3 容器启动命令配置不正确 此种问题的解决方案是：重新创建工作负载，并配置正确的启动命令。
-
排查项四：命名空间的资源类型错误 请检查创建命名空间时选择的资源类型是否正确，通用计算型和GPU加速型支持X86镜像。 登录控制台，在页面上单击失败的工作负载，进入负载详情界面。 查看Pod列表，单击实例异常Pod所在行“操作”列的“查看日志”。 查看报错信息如下。 ERROR: exec failed: Exec format error ERROR: hyper send process initiated event: error
-
排查项六：检查临时卷使用量 0/7 nodes are available: 7 Insufficient ephemeral-storage. 节点临时存储不足。 检查Pod是否限制了临时卷的大小，如下所示，当应用程序需要使用的量超过节点已有容量时会导致无法调度，修改临时卷限制或扩容节点磁盘可解决此问题。 apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" volumeMounts: - name: ephemeral mountPath: "/tmp" volumes: - name: ephemeral emptyDir: {}
-
检查项九：检查节点上调度的Pod是否过多 0/1 nodes are available: 1 Too many pods.表示节点上调度的Pod过多，超出可调度的最大实例数。 创建节点时，在“高级配置”中可选择设置“最大实例数”参数，设置节点上可以正常运行的容器 Pod 的数目上限。该数值的默认值随节点规格浮动，您也可以手动设置。 图1 最大实例数 您可以在“节点管理”页面，查看节点的“容器组(已分配/总额度)”参数列，检查节点已调度的容器是否达到上限。若已达到上限，可通过添加节点或修改最大实例数的方式解决。 您可通过以下方式修改“最大实例数”参数： 默认节点池中的节点：通过重置节点时修改“最大实例数”。 自定义节点池中的节点：可修改节点池配置参数中的max-pods参数。详情请参见节点池配置管理。 图2 查看容器数
-
排查项二：节点资源（CPU、内存等）是否充足 0/2 nodes are available: 2 Insufficient cpu. CPU不足。 0/2 nodes are available: 2 Insufficient memory. 内存不足。 当“实例资源的申请量”超过了“实例所在节点的可分配资源总量”时，节点无法满足实例所需资源要求导致调度失败。 如果节点可分配资源小于Pod的申请量，则节点无法满足实例所需资源要求导致调度失败。 解决方案： 资源不足的情况主要解决办法是扩容，建议在集群中增加节点数量。
-
排查项三：检查工作负载的亲和性配置 当亲和性配置出现如下互斥情况时，也会导致实例调度失败： 例如： workload1、workload2设置了工作负载间的反亲和，如workload1部署在Node1，workload2部署在Node2。 workload3部署上线时，既希望与workload2亲和，又希望可以部署在不同节点如Node1上，这就造成了工作负载亲和与节点亲和间的互斥，导致最终工作负载部署失败。 0/2 nodes are available: 1 node(s) didn't match node selector, 1 node(s) didn't match pod affinity rules, 1 node(s) didn't match pod affinity/anti-affinity. node selector 表示节点亲和不满足。 pod affinity rules 表示Pod亲和不满足。 pod affinity/anti-affinity 表示Pod亲和/反亲和不满足。 解决方案： 在设置“工作负载间的亲和性”和“工作负载和节点的亲和性”时，需确保不要出现互斥情况，否则工作负载会部署失败。 若工作负载配置了节点亲和性，需确保亲和的节点标签中supportContainer设置为true，否则会导致pod无法调动到节点上，查看事件提示如下错误信息： No nodes are available that match all of the following predicates: MatchNode Selector, NodeNotSupportsContainer 节点标签为false时将会调度失败。
-
排查项四：挂载的存储卷与节点是否处于同一可用区 0/2 nodes are available: 2 node(s) had volume node affinity conflict. 存储卷与节点之间存在亲和性冲突，导致无法调度。 这是因为云硬盘不能跨可用区挂载到节点。例如云硬盘存储卷在可用区1，节点在可用区2，则会导致无法调度。 CCE中创建云硬盘存储卷，默认带有亲和性设置，如下所示： kind: PersistentVolume apiVersion: v1 metadata: name: pvc-c29bfac7-efa3-40e6-b8d6-229d8a5372ac spec: ... nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: failure-domain.beta.kubernetes.io/zone operator: In values: - cn-east-3a 解决方案： 重新创建存储卷，可用区选择与节点同一分区，或重新创建工作负载，存储卷选择自动分配。
-
排查项七：检查everest插件是否工作正常 0/1 nodes are available: 1 everest driver not found at node。集群everest插件的everest-csi-driver 在节点上未正常启动。 检查kube-system命名空间下名为everest-csi-driver的守护进程，查看对应Pod是否正常启动，若未正常启动，删除该Pod，守护进程会重新拉起该Pod。
-
排查思路 根据具体事件信息确定具体问题原因，如表1所示。 表1 实例调度失败 事件信息 问题原因与解决方案 no nodes available to schedule pods. 集群中没有可用的节点。 排查项一：集群内是否无可用节点 0/2 nodes are available: 2 Insufficient cpu. 0/2 nodes are available: 2 Insufficient memory. 节点资源（CPU、内存）不足。 排查项二：节点资源（CPU、内存等）是否充足 0/2 nodes are available: 1 node(s) didn't match node selector, 1 node(s) didn't match pod affinity rules, 1 node(s) didn't match pod affinity/anti-affinity. 节点与Pod亲和性配置互斥，没有满足Pod要求的节点。 排查项三：检查工作负载的亲和性配置 0/2 nodes are available: 2 node(s) had volume node affinity conflict. Pod挂载云硬盘存储卷与节点不在同一个可用区。 排查项四：挂载的存储卷与节点是否处于同一可用区 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate. 节点存在污点Tanits，而Pod不能容忍这些污点，所以不可调度。 排查项五：检查Pod污点容忍情况 0/7 nodes are available: 7 Insufficient ephemeral-storage. 节点临时存储不足。 排查项六：检查临时卷使用量 0/1 nodes are available: 1 everest driver not found at node 节点上everest-csi-driver不在running状态。 排查项七：检查everest插件是否工作正常 Failed to create pod sandbox: ... Create more free space in thin pool or use dm.min_free_space option to change behavior 节点thinpool空间不足。 排查项八：检查节点thinpool空间是否充足 0/1 nodes are available: 1 Too many pods. 该节点调度的Pod超出上限。 检查项九：检查节点上调度的Pod是否过多
-
排查项五：检查Pod污点容忍情况 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate. 是因为节点打上了污点，不允许Pod调度到节点上。 查看节点的上污点的情况。如下则说明节点上存在污点。 $ kubectl describe node 192.168.0.37 Name: 192.168.0.37 ... Taints: key1=value1:NoSchedule ... 在某些情况下，系统会自动给节点添加一个污点。当前内置的污点包括： node.kubernetes.io/not-ready：节点未准备好。 node.kubernetes.io/unreachable：节点控制器访问不到节点。 node.kubernetes.io/memory-pressure：节点存在内存压力。 node.kubernetes.io/disk-pressure：节点存在磁盘压力，此情况下您可通过节点磁盘空间不足的方案进行解决。 node.kubernetes.io/pid-pressure：节点的 PID 压力，此情况下您可通过修改节点进程 ID数量上限kernel.pid_max进行解决。 node.kubernetes.io/network-unavailable：节点网络不可用。 node.kubernetes.io/unschedulable：节点不可调度。 node.cloudprovider.kubernetes.io/uninitialized：如果kubelet启动时指定了一个“外部”云平台驱动， 它将给当前节点添加一个污点将其标志为不可用。在cloud-controller-manager初始化这个节点后，kubelet将删除这个污点。 解决方案： 要想把Pod调度到这个节点上，有两种方法： 若该污点为用户自行添加，可考虑删除节点上的污点。若该污点为系统自动添加，解决相应问题后污点会自动删除。 Pod的定义中容忍这个污点，如下所示。详细内容请参见污点和容忍。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:alpine tolerations: - key: "key1" operator: "Equal" value: "value1" effect: "NoSchedule"
-
排查项八：检查节点thinpool空间是否充足 节点在创建时会绑定一个供kubelet及容器引擎使用的专用数据盘，详情请参见数据盘空间分配说明。若数据盘空间不足，将导致实例无法正常创建。 方案一：清理镜像 您可以执行以下步骤清理未使用的镜像： 使用containerd容器引擎的节点： 查看节点上的本地镜像。 crictl images -v 确认镜像无需使用，并通过镜像ID删除无需使用的镜像。 crictl rmi {镜像ID} 使用docker容器引擎的节点： 查看节点上的本地镜像。 docker images 确认镜像无需使用，并通过镜像ID删除无需使用的镜像。 docker rmi {镜像ID} 请勿删除cce-pause等系统镜像，否则可能导致无法正常创建容器。 方案二：扩容磁盘 扩容磁盘的操作步骤如下： 在EVS界面扩容数据盘。 登录CCE控制台，进入集群，在左侧选择“节点管理”，单击节点后的“同步云服务器”。 登录目标节点。 使用lsblk命令查看节点块设备信息。 这里存在两种情况，根据容器存储Rootfs而不同。 Overlayfs，没有单独划分thinpool，在dockersys空间下统一存储镜像相关数据。 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 8:0 0 50G 0 disk └─vda1 8:1 0 50G 0 part / vdb 8:16 0 200G 0 disk ├─vgpaas-dockersys 253:0 0 90G 0 lvm /var/lib/docker # 容器引擎使用的空间 └─vgpaas-kubernetes 253:1 0 10G 0 lvm /mnt/paas/kubernetes/kubelet # kubernetes使用的空间 在节点上执行如下命令， 将新增的磁盘容量加到dockersys盘上。 pvresize /dev/vdb lvextend -l+100%FREE -n vgpaas/dockersys resize2fs /dev/vgpaas/dockersys Devicemapper，单独划分了thinpool存储镜像相关数据。 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 8:0 0 50G 0 disk └─vda1 8:1 0 50G 0 part / vdb 8:16 0 200G 0 disk ├─vgpaas-dockersys 253:0 0 18G 0 lvm /var/lib/docker ├─vgpaas-thinpool_tmeta 253:1 0 3G 0 lvm │ └─vgpaas-thinpool 253:3 0 67G 0 lvm # thinpool空间 │ ... ├─vgpaas-thinpool_tdata 253:2 0 67G 0 lvm │ └─vgpaas-thinpool 253:3 0 67G 0 lvm │ ... └─vgpaas-kubernetes 253:4 0 10G 0 lvm /mnt/paas/kubernetes/kubelet 在节点上执行如下命令， 将新增的磁盘容量加到thinpool盘上。 pvresize /dev/vdb lvextend -l+100%FREE -n vgpaas/thinpool 在节点上执行如下命令， 将新增的磁盘容量加到dockersys盘上。 pvresize /dev/vdb lvextend -l+100%FREE -n vgpaas/dockersys resize2fs /dev/vgpaas/dockersys
-
排查项二：（退出码：137）健康检查执行失败 工作负载配置的健康检查会定时检查业务，异常情况下pod会报实例不健康的事件且pod一直重启失败。 工作负载若配置liveness型（工作负载存活探针）健康检查，当健康检查失败次数超过阈值时，会重启实例中的容器。在工作负载详情页面查看事件，若K8s事件中出现“Liveness probe failed: Get http…”时，表示健康检查失败。 解决方案： 请在工作负载详情页中，切换至“容器管理”页签，核查容器的“健康检查”配置信息，排查健康检查策略是否合理或业务是否已异常。
-
排查项三：容器所在磁盘空间不足 如下磁盘为创建节点时选择的docker专用盘分出来的thinpool盘，以root用户执行lvs命令可以查看当前磁盘的使用量。 Thin Pool has 15991 free data blocks which is less than minimum required 16383 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior 解决方案： 方案一：清理镜像 您可以执行以下步骤清理未使用的镜像： 使用containerd容器引擎的节点： 查看节点上的本地镜像。 crictl images -v 确认镜像无需使用，并通过镜像ID删除无需使用的镜像。 crictl rmi {镜像ID} 使用docker容器引擎的节点： 查看节点上的本地镜像。 docker images 确认镜像无需使用，并通过镜像ID删除无需使用的镜像。 docker rmi {镜像ID} 请勿删除cce-pause等系统镜像，否则可能导致无法正常创建容器。 方案二：扩容磁盘 扩容磁盘的操作步骤如下： 在EVS界面扩容数据盘。 登录CCE控制台，进入集群，在左侧选择“节点管理”，单击节点后的“同步云服务器”。 登录目标节点。 使用lsblk命令查看节点块设备信息。 这里存在两种情况，根据容器存储Rootfs而不同。 Overlayfs，没有单独划分thinpool，在dockersys空间下统一存储镜像相关数据。 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 8:0 0 50G 0 disk └─vda1 8:1 0 50G 0 part / vdb 8:16 0 200G 0 disk ├─vgpaas-dockersys 253:0 0 90G 0 lvm /var/lib/docker # 容器引擎使用的空间 └─vgpaas-kubernetes 253:1 0 10G 0 lvm /mnt/paas/kubernetes/kubelet # kubernetes使用的空间 在节点上执行如下命令， 将新增的磁盘容量加到dockersys盘上。 pvresize /dev/vdb lvextend -l+100%FREE -n vgpaas/dockersys resize2fs /dev/vgpaas/dockersys Devicemapper，单独划分了thinpool存储镜像相关数据。 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 8:0 0 50G 0 disk └─vda1 8:1 0 50G 0 part / vdb 8:16 0 200G 0 disk ├─vgpaas-dockersys 253:0 0 18G 0 lvm /var/lib/docker ├─vgpaas-thinpool_tmeta 253:1 0 3G 0 lvm │ └─vgpaas-thinpool 253:3 0 67G 0 lvm # thinpool空间 │ ... ├─vgpaas-thinpool_tdata 253:2 0 67G 0 lvm │ └─vgpaas-thinpool 253:3 0 67G 0 lvm │ ... └─vgpaas-kubernetes 253:4 0 10G 0 lvm /mnt/paas/kubernetes/kubelet 在节点上执行如下命令， 将新增的磁盘容量加到thinpool盘上。 pvresize /dev/vdb lvextend -l+100%FREE -n vgpaas/thinpool 在节点上执行如下命令， 将新增的磁盘容量加到dockersys盘上。 pvresize /dev/vdb lvextend -l+100%FREE -n vgpaas/dockersys resize2fs /dev/vgpaas/dockersys
-
排查项七：工作负载挂载的密钥值不符合要求 事件详情中出现以下错误： Error: failed to start container "filebeat": Error response from daemon: OCI runtime create failed: container_linux.go:330: starting container process caused "process_linux.go:381: container init caused \"setenv: invalid argument\"": unknown 出现以上问题的根因是由于工作负载中挂载了Secret，但Secret对应的值没有进行base64加密。 解决方案： 通过控制台创建Secret，Secret对应的值会自动进行base64加密。 如果通过YAML进行创建，需要手动对密钥值进行base64加密： # echo -n "待编码内容" | base64
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
