云服务器内容精选

  • 排查项一:kubectl创建工作负载时未指定imagePullSecret 以创建一个名为nginx的deployment为例,请排查yaml文件中是否存在imagePullSecrets字段(如下yaml示例中的加粗字段),表示pull镜像时的secret名称。 需要使用 容器镜像服务 的镜像时,参数值固定为imagepull-secret。 apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 1 selector: matchLabels: app: nginx strategy: type: RollingUpdate template: metadata: labels: app: nginx spec: containers: - image: nginx:alpine imagePullPolicy: Always name: nginx imagePullSecrets: - name: imagepull-secret
  • 排查项三: IAM 用户没有镜像下载权限 如果您开通了企业管理,您需要在账号下的容器 镜像服务 中给IAM用户添加权限,IAM用户才能使用账号下的私有镜像。 给IAM用户添加权限有如下两种方法: 在镜像详情中为IAM用户添加授权,授权完成后,IAM用户享有读取/编辑/管理该镜像的权限,具体请参见在镜像详情中添加授权。 在组织中为IAM用户添加授权,使IAM用户对组织内所有镜像享有读取/编辑/管理的权限,具体请参见在组织中添加授权。
  • 排查项三:检查工作负载的亲和性配置 当亲和性配置出现如下互斥情况时,也会导致实例调度失败: 例如: 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。
  • 排查项二:节点资源(CPU、内存等)是否充足 0/2 nodes are available: 2 Insufficient cpu. CPU不足。 0/2 nodes are available: 2 Insufficient memory. 内存不足。 当“实例资源的申请量”超过了“实例所在节点的可分配资源总量”时,节点无法满足实例所需资源要求导致调度失败。 如果节点可分配资源小于Pod的申请量,则节点无法满足实例所需资源要求导致调度失败。 解决方案: 资源不足的情况主要解决办法是扩容,建议在集群中增加节点数量。
  • 排查项六:检查临时卷使用量 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 查看容器数
  • 排查思路 根据具体事件信息确定具体问题原因,如表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
  • 排查项六:同一pod中container端口冲突导致 登录异常工作负载所在的节点。 查看工作负载实例非正常退出的容器ID。 docker ps -a | grep $podName 查看退出容器的错误日志。 docker logs $containerID 根据日志提示修复工作负载本身的问题。如下图所示,即同一Pod中的container端口冲突导致容器启动失败。 图2 container冲突导致容器启动失败 解决方案: 重新创建工作负载,并配置正确的端口,确保端口不冲突。
  • 排查项九:JAVA探针的版本选择latest导致 K8s事件为Created container init-pinpoint 解决方案: 在创建工作负载时,在“高级设置”步骤下的“性能管理配置”项目下,JAVA探针版本请选择最新的版本(例如:1.0.36),不要选择latest版本。 如果工作负载创建时的JAVA探针版本已经选择了latest版本,可以更新工作负载配置,将JAVA探针版本请选择为最新的版本(例如:1.0.36)。
  • 排查项七:工作负载挂载的密钥值不符合要求 事件详情中出现以下错误: 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
  • 排查项二:(退出码:137)健康检查执行失败 工作负载配置的健康检查会定时检查业务,异常情况下pod会报实例不健康的事件且pod一直重启失败。 工作负载若配置liveness型(工作负载存活探针)健康检查,当健康检查失败次数超过阈值时,会重启实例中的容器。在工作负载详情页面查看事件,若K8s事件中出现“Liveness probe failed: Get http…”时,表示健康检查失败。 解决方案: 请在工作负载详情页中,切换至“容器管理”页签,核查容器的“健康检查”配置信息,排查健康检查策略是否合理或业务是否已异常。