文档中心

容器服务

最佳实践

VCI 故障处理最佳实践

本文面向在 VCI 上部署业务的技术与运维团队，系统性地梳理从故障定位、常见问题排查到监控告警与架构优化的实战最佳实践，帮助您在生产环境中更稳定地使用 VCI。

一、快速理解 VCI

了解 VCI 故障处理最佳实践前，您需要快速了解 VCI 产品相关常见误区。更多关于 VCI 的基础概念、适用场景及产品定位，请参见 VCI 产品简介。

误区一：VCI 不需要 Kubernetes 知识？

答：并非如此。VCI 虽然免去了节点运维，但其依然运行在 Kubernetes 的编排体系下。用户仍需熟悉 Kubernetes 的核心概念（如 Pod、Deployment、Service、Annotation 等），以更好地定义和管理应用。VCI 仅对数据面的节点管理进行了托管。

误区二：所有应用都适合 VCI？

答：不一定。VCI 是免节点运维（Nodeless）架构的产品，因此与 Node 相关的特性（如 DaemonSet、NodePort 等）无法在 VCI 中运行。

误区三：长期稳态场景不适合 VCI？

答：并非如此。部分用户误认为长期稳定运行、资源需求固定且利用率高的常驻应用使用传统 ECS 节点池更具成本效益，实际上 VCI 支持“预留实例券”功能，使用成本可对齐 ECS 节点池。VCI 不仅能提供极致弹性以应对波动需求，还能通过包年包月的成本方案解决稳态场景下的业务需求。

误区四：vci-profile 是强制调度策略？

答：这是软性调度，非强制。vci-profile 提供了一种便捷、无侵入的全局配置方式，用于影响 Pod 的调度倾向。最终调度结果仍受 Pod 自身的 Annotation、集群的资源优先级策略（Resource Policy）等多种因素共同影响。因此，Pod 仍有未被调度到 VCI 的可能性。

二、定位故障：分层与判定

排查 VCI 故障时，建立一个清晰的分层模型至关重要。这能帮助您快速缩小问题范围，避免在无关的层面浪费时间。推荐的排查顺序是“自上而下、由内而外”：从业务表现到应用自身，再到 VCI 实例，最后延伸至网络和外部依赖。

以下是各层级的核心关注点：

业务应用层

这是排查的起点，关注业务层面的可观测性指标。

核心问题：观测业务是否存在异常？应用日志是否有错误？

关键指标：应用 SLI/SLO（成功率/延迟）、错误码、业务自定义监控。

排查工具：APMPlus、业务日志平台、自定义监控大盘。

Kubernetes & VCI 资源层

如果业务异常，立即下钻到 Kubernetes 资源层，检查 Pod 的生命周期和配置。

核心问题：Pod 是否正常运行？配置是否正确？

关键信号：kubectl describe pod 中的 Events、kubectl logs 中的容器日志、Pod Annotations。

常见状态：Pending、Terminating、CrashLoopBackOff、ImagePullBackOff、FailedCreate。

VCI 数据面层

Pod 运行在 VCI 实例上，实例自身的健康状况直接影响 Pod。

核心问题：VCI 实例所在虚拟节点是否健康？资源是否充足？

关键指标：虚拟节点状态、Kubelet/Containerd 健康状况、GPU 相关指标 (DCGM)。

排查工具：kubectl get node、云监控。

网络路径层

网络是分布式系统的生命线，VCI 也不例外。

核心问题：网络是否通畅？DNS 解析是否正常？安全策略是否放通？

关键组件：VPC 路由、安全组、网络 ACL、CoreDNS。

排查工具：ping、curl、nslookup、tcpdump、VPC/CLB 控制台。

控制面 & 依赖服务层

当大量 VCI 实例出现共性问题时，可能指向了上游的控制面或依赖服务。

核心问题：VCI 控制面是否稳定？依赖的监控、存储服务是否正常？

关键指标：VCI 核心 API 成功率、Virtual Kubelet 接口成功率。

排查工具：云监控、托管 Prometheus (VMP)、告警平台。

资源与配额层

创建失败或 Pending 问题，很多时候与资源供给有关。

核心问题：账号配额是否足够？目标可用区库存是否充足？

关键信号：FailedScheduling 事件、配额中心告警；quota 类异常通常提示账号配额不足，sold out 类异常意味着资源库存不足。

排查工具：配额中心控制台、工单咨询。

三、处理高频故障：实战 SOP

本小节内容汇集了真实案例中的高频故障，并以“现象→可能原因→如何定位→建议修复”的标准化操作程序 (SOP) 格式呈现。

排查核心：遇到问题时，请先冷静。kubectl describe pod <pod-name>是您的第一大神器，90% 的问题线索都藏在 Events 部分。

3.1 Pod 状态异常

故障现象	可能原因	定位方法	建议修复
Pod 卡在 Pending 状态	资源配额/库存不足：账号下 VCI 实例的 vCPU/内存/GPU 配额耗尽，或当前可用区资源库存不足。调度条件无法满足：Pod 请求的资源规格（如特定 CPU / GPU 型号）、可用区、子网等条件无法被满足。 vci-profile 配置问题：vci-profile 中的选择器或配置项有误，导致 Pod 无法正确匹配 VCI 调度规则。控制面组件异常：VCI 调度器或 Virtual Kubelet 出现异常。	执行kubectl describe pod <pod-name>查看 Events，关注 FailedScheduling 事件，通常会明确指出原因（例如：Insufficient quota、No nodes available to schedule pods）。登录配额中心，检查 VCI 相关资源的配额使用情况。检查 Pod YAML 中annotations和nodeSelector等调度相关配置是否正确。检查kube-system命名空间下的vci-profile对应的 ConfigMap 配置是否符合预期。	提升配额：在配额中心申请提升相应资源的配额。详情请参见配额查看和申请。调整调度策略：放宽 Pod 的调度限制，例如尝试在其他可用区部署 VCI Pod 或更新 VCI 实例规格。检查库存：联系客户经理或技术支持确认目标可用区的资源库存情况。修复配置：根据故障/事件的 Message 等信息，修正 Pod YAML 或 vci-profile 中的错误配置。
Pod 卡在 Terminating 状态	业务进程状态：容器内的业务进程阻塞在内核态（Disk Sleep），无法响应 SIGTERM 信号。常见于 JuiceFS 等存储客户端未正常卸载，导致业务 I/O 阻塞。存储卷卸载失败：底层的 EBS 云盘或 NAS 等网络文件系统卸载操作长时间挂起。网络资源回收慢：ENI（弹性网卡）等网络资源的解绑或回收过程异常。 VCI 数据面节点异常：底层物理机或 MicroVM 出现故障，无法完成清理工作。	登录 VCI 实例（即 VCI 实例对应的 Pod），执行ps aux \| grep 'D'命令检查是否有处于 D 状态的进程。登录 Pod 方法，请参见管理容器组。查看 VCI 数据面节点的 containerd 或 kubelet 组件日志，寻找与 Pod 清理相关的错误信息。查看/var/log/bytedrive下的日志，排查存储问题。如果怀疑是业务进程问题，可在删除 Pod 前进入容器，检查进程状态和资源句柄占用情况。详情请参见查看容器组信息。	修复业务逻辑：确保应用能正确处理 SIGTERM 信号，并在退出前完成所有资源的清理，特别是存储客户端的umount操作。强制删除：执行kubectl delete pod <pod-name> --grace-period=0 --force命令，强制删除 Pod。注意强制删除 Pod 可能导致数据不一致或资源泄露，请谨慎操作。发起售后工单：如果无法自行解决，请提供 Pod 名称、命名空间和出现问题的时间点，联系售后支持团队介入。
Pod 状态为 CrashLoopBackOff	应用启动失败：程序本身存在 Bug、配置错误、依赖服务未就绪。资源不足：Pod 的requests或limits设置过低，应用启动时因 OOM (Out of Memory) 或 CPU 资源不足而被终止。健康检查失败：livenessProbe或readinessProbe配置不当，例如端口、路径错误，超时时间过短等，导致 Kubelet 误判应用异常并不断重启。权限问题：容器内进程没有权限读写所需的文件或目录。	执行kubectl logs <pod-name>命令，查看当前容器的日志，通常能直接找到启动失败的错误信息。执行kubectl logs <pod-name> --previous命令，查看上一次被终止的容器日志，对于排查 OOM 等问题非常关键。执行kubectl describe pod <pod-name>命令，查看 Events，关注Back-off restarting failed container等信息，并检查 State 部分的 Last State，查看退出原因（例如Exit Code: 137表示 OOMKilled）。	修复应用代码/配置。增加资源：适当调高 Pod Spec 中的resources.requests和 resources.limits。调整健康检查：检查并修正livenessProbe和readinessProbe的配置。修复权限：调整容器的 securityContext 或镜像中的文件权限。详情请参见配置安全上下文。

3.2 镜像与存储问题

故障现象	可能原因	定位方法	建议修复
镜像拉取慢或失败 (ImagePullBackOff)	网络不通：VCI 实例无法访问目标镜像仓库（公网或私有仓库）。凭证错误 (ImagePullSecrets)：配置的imagePullSecrets不正确或凭证已过期，导致认证失败。镜像不存在/权限不足：镜像地址、Tag 错误，或当前账号无权拉取该镜像。镜像缓存问题：使用了自动镜像缓存，但系统盘容量 (vci.vke.volcengine.com/desired-system-storage) 指定过小，不足以容纳缓存。镜像缓存本身已损坏或过期。远端代理仓配置错误：通过vci.volcengine.com/registry-mirror-config配置的镜像代理，其地址或认证信息有误。	执行kubectl describe pod <pod-name>命令查看 Events，通常有详细的错误信息，例如Failed to pull image ... rpc error: code = Unknown desc = ...。登录到一台可访问目标仓库的机器上，尝试执行docker pull <image-name>:<tag>，验证镜像和凭证是否有效。检查 Pod YAML 中imagePullSecrets的配置，并确认对应的 Secret 内容是否正确。如果使用镜像缓存，请根据官网文档检查系统盘大小的 Annotation 是否按要求配置（例如，不小于镜像大小的 2~2.5 倍）。详情请参见 VCI 镜像缓存。	网络排查：确保 VCI 所在子网有正确的公网出口（NAT 网关）或到私有仓库的网络路径。更新凭证：创建或更新正确的 imagePullSecrets。修正镜像地址：使用正确的镜像仓库地址和 Tag。调整系统盘大小：为使用镜像缓存的 Pod 添加或调整vci.vke.volcengine.com/desired-system-storage Annotation。说明【邀测·申请试用】：vci.vke.volcengine.com/desired-system-storage Annotation 对应的功能，目前处于邀测阶段，如需使用，请提交申请。 P2P 加速：对于大镜像，可考虑使用 P2P 镜像加速方案。详情请参见 P2P 镜像加速方案。
创建 Pod 报 ProviderFailed / FailedCreateSystemDisk	系统盘容量不足：VCI 实例的系统盘（默认为 40GiB）不足以容纳操作系统、系统组件及容器镜像。特别是使用大镜像时容易触发。底层资源分配失败：数据面在分配计算、存储（EBS 卷）或网络资源时失败。账号欠费：账号余额不足，无法创建新的计费资源。	执行kubectl describe pod <pod-name>命令查看 Events，错误信息通常会包含"ProviderFailed"或"FailedCreateSystemDisk"等关键词。检查 Pod 使用的镜像大小。如果镜像较大，例如超过 15 GiB，则很可能是系统盘容量问题。登录费用中心，确认账号状态是否正常，余额是否充足。	增加系统盘容量：在 Pod 的metadata.annotations中添加vci.vke.volcengine.com/desired-system-storage: "80"（单位 GiB，邀测功能），明确指定更大的系统盘。您也可以指定其他合适的值，增加系统盘容量。确认账号余额：确保火山引擎账户余额（含代金券）不低于 100 元，且除去代金券后账户余额不为零。详细操作，请参见费用中心。重试：若底层偶发资源分配失败，可以简单地删除 Pod 并重建，可成功创建。如果持续创建失败，请联系您的火山引擎客户经理或提交工单获取技术支持。
卷挂载失败 (FailedMount)	EBS 云盘跨可用区挂载：尝试将一个可用区 A 的 EBS 卷挂载到位于可用区 B 的 VCI 实例上。 NAS/文件存储网络不通：VCI 实例与 NAS 文件系统的挂载点之间网络不通，或被安全组/ACL 阻止。 PV/PVC 配置错误：PersistentVolume（PV）或 PersistentVolumeClaim（PVC）的定义有误，例如storageClassName不匹配、容量不满足等。卷状态异常：云盘本身处于异常、已挂载或其他非可用状态。	执行kubectl describe pod <pod-name>命令查看 Events 中的FailedMount错误详情。检查 PV 的定义，确认其spec.csi.volumeHandle对应的云盘 ID，并到云服务器-云盘控制台查询该云盘的状态和所在可用区。执行kubectl get pod <pod-name> -o wide命令检查 Pod 的调度结果，确认其被调度的节点和可用区是否与云盘一致。如果卷的存储类型是 NAS，请检查 VCI 子网与 NAS 挂载点之间的路由和安全策略。	确保同可用区：使用nodeSelector或vci.vke.volcengine.com/preferred-availability-zones Annotation 将 Pod 调度到与 EBS 卷相同的可用区。打通网络：为 NAS 存储配置正确的网络访问策略。详情请参见文件存储（NAS）。修正 PV/PVC：检查并修复存储声明的配置。

3.3 网络与服务发现问题

故障现象	可能原因	定位方法	建议修复
DNS 解析失败	CoreDNS 故障或资源不足：集群的 CoreDNS Pod 异常，或因请求量过大导致其 CPU/内存资源不足，无法及时响应。网络策略（NetworkPolicy）：配置了网络策略，阻止了业务 Pod 到 kube-system 命名空间下 CoreDNS Pod 的 53/UDP 端口的访问。 Pod dnsPolicy 配置错误：Pod 的 dnsPolicy 被错误地设置为 Default 或 None，导致未使用集群内 DNS 服务。上游 DNS 问题：如果解析的是公网域名，可能是 CoreDNS 的上游 DNS 服务器出现问题。	进入业务 Pod：kubectl exec -it <pod-name> -- /bin/sh。在 Pod 内执行cat /etc/resolv.conf，确认nameserver是否指向集群 CoreDNS 的 Service IP。使用nslookup <service-name>或dig <external-domain.com>测试解析。如果超时或失败，尝试直接向 CoreDNS IP 请求：dig @<coredns-pod-ip> <domain-name>。检查 CoreDNS Pod 的日志和资源使用情况。	扩容 CoreDNS：增加 CoreDNS 的副本数或资源limits值。详细操作，请参见 FAQ。使用 NodeLocal DNSCache：为集群启用 NodeLocal DNSCache，减少对 CoreDNS 的直接请求压力，提升解析性能。详情请参见使用 NodeLocal DNSCache 缓存代理。检查网络策略：确保有策略允许业务 Pod 访问 CoreDNS。修正dnsPolicy：确保dnsPolicy值为ClusterFirst（默认）或ClusterFirstWithHostNet。
跨网段 / 跨服务访问不通	安全组未放通：源或目的 VCI/ECS 实例所属的安全组出入向规则未放通相应的协议和端口。 VPC 路由表冲突或缺失：使用 CEN（云企业网）打通多 VPC 时，自定义路由与系统路由冲突（例如100.64.0.0/11公共服务网段冲突）。缺少指向对端的明确路由。网络 ACL 限制：子网关联的网络 ACL 阻止了流量。 CLB 后端健康检查失败：作为 CLB 后端的 VCI 实例，因业务进程未监听或健康检查失败而被摘除。	VPC 流量路径分析：在私有网络控制台，使用“路径分析”工具，输入源和目的 IP，可视化地检查路由、安全组和 ACL 的连通性。详情请参见路径分析。检查安全组：分别检查源和目的实例关联的所有安全组，确认出站和入站规则是否都正确配置。详情请参见安全组设置。审查路由表：查看 VCI 所在子网关联的路由表，重点关注自定义路由是否覆盖了系统路由或与系统路由冲突。详情请参见路由（Ingress）。检查 CLB 的后端服务器组：在负载均衡控制台确认 VCI 实例是否处于健康状态。	精确放通安全组：遵循最小权限原则，修改安全组规则，仅放通必要的源/目的 IP 段和端口。详情请参见安全组设置、集群访问规则。修复路由：调整或删除冲突的路由条目。调整网络 ACL：修改 ACL 规则以允许所需流量。修复业务或进行健康检查：确保 CLB 后端的业务进程正常监听，且健康检查配置正确。

四、配置监控与告警：防患于未然

被动排障不如主动预防。建立一套完善的监控与告警体系，是保障 VCI 服务稳定性的关键。本章节将提供一份可落地的监控告警清单和实践建议。

4.1 监控与告警订阅建议

本小节表格整合了火山引擎云监控、VMP、APMPlus 及自建告警平台的关键指标和事件，为您构建 VCI 的全景监控视图提供参考。

告警配置核心：告警宁缺毋滥。优先配置能直接反映用户体验受损或预示重大风险的告警（如 SLI 下降、Pod 大量 Pending），并为此类告警设置明确的 SOP。对于“噪音”较多的指标（如瞬时 CPU 高负载），可以设置更高的触发阈值或更长的持续时间，避免告警疲劳。

分类	指标 / 事件名称	建议阈值 / 条件	归属平台	说明与适用场景
VCI 实例与 Pod 基础	pod_cpu_usage_seconds_total (Counter) container_cpu_usage_seconds_total (Counter)	rate(...) > 85%，且持续 5 分钟	VMP	VCI 实例（Pod 维度）或单个容器的 CPU 使用率。持续高位可能意味着资源瓶颈或应用逻辑问题。
		pod_memory_working_set_bytes (Gauge) container_memory_working_set_bytes (Gauge)	Pod/Container Limit > 90%	VMP	物理内存使用量。接近 Limit 时 Pod 面临被 OOMKilled 风险。
		container_network_receive_bytes_total (Counter) container_network_transmit_bytes_total (Counter)	rate(...)出现异常突增或骤降	VMP	网络吞吐量。监控流量的剧烈变化，预示可能发生攻击、业务异常或网络问题。
Kubernetes 核心事件	事件：Pod Pending	同命名空间下 Pending Pod 数量 > 5，且持续 3 分钟	自建告警平台 / 云监控	大量 Pod 无法被调度，通常指向资源不足或调度器问题，是严重故障的前兆。
		事件：Pod Terminating	同命名空间下 Terminating Pod 数量 > 3，且持续 10 分钟	自建告警平台 / 云监控	Pod 无法正常退出，影响发布和伸缩。
		事件：Node NotReady	虚拟节点状态变为 NotReady	自建告警平台 / 云监控	表示 VCI 数据面或 Virtual Kubelet 与控制面的通信出现严重问题。
GPU 监控	DCGM_FI_DEV_GPU_TEMP (Gauge)	> 85（摄氏度）	VMP (DCGM Exporter)	GPU 温度过高会触发降频，甚至硬件损坏。
		DCGM_FI_DEV_POWER_USAGE (Gauge)	rate(...)持续低于预期值	VMP (DCGM Exporter)	训练任务中 GPU 功率持续过低，表示任务可能未正确利用 GPU。
		DCGM_FI_DEV_GPU_UTIL (Gauge) DCGM_FI_DEV_MEM_COPY_UTIL (Gauge)	avg_over_time(...) < 10%，且持续 10 分钟	VMP (DCGM Exporter)	GPU 利用率或显存带宽利用率长期过低，说明 GPU 资源闲置，需排查应用配置。
		DCGM_FI_DEV_XID_ERRORS (Gauge)	> 0	VMP (DCGM Exporter)	NVIDIA XID 错误是 GPU 硬件或驱动严重错误的信号，需立即关注。
存储与磁盘	kubelet_volume_stats_used_byteskubelet_volume_stats_capacity_bytes	磁盘使用率 > 90%	VMP	数据盘或系统盘容量即将耗尽，会导致数据无法写入、应用崩溃。
		kubelet_volume_stats_inodes_usedkubelet_volume_stats_inodes	Inode 使用率 > 90%	VMP	Inode 耗尽会导致无法创建新文件。适用于存储大量小文件的场景。
		EBS IO 指标（如 DiskReadBandwidth、DiskWriteBandwidth）	达到云盘规格上限的 95%	云监控	存储 IO 达到瓶颈，会导致应用读写延迟飙高。
控制面与依赖	VCI 核心 API SLI（如 CreateContainerInstance）	成功率 < 99% 持续 5 分钟	自建告警平台	VCI 控制面核心接口出现异常，会大面积影响 Pod 的创建和管理。
控制面与依赖		配额中心相关事件	Quota utilization exceeds 80%	配额中心 / 云监控	VCI 资源配额即将用尽，需提前申请扩容，避免影响业务弹性。
亚健康与故障机	pod Condition / pod Label 中筛选出故障关键字 InstanceReady	kubectl get po -A-l vci.vke.volcengine.com/instance-fault=NodeNotReady	自建告警平台	宕机节点，发生了物理机故障，实例已经不能正常运行。
亚健康与故障机		pod Condition / pod Label 中筛选出故障关键字 VciOps	kubectl get po -A-l vci.vke.volcengine.com/VciOps=PreVciNodeOffline	自建告警平台	亚健康节点，预下线，VCI 后续会进行的运维运营动作，会影响 VCI 实例的运行。

4.2 告警订阅与管理实践建议

利用预置模板：

VMP：利用 VMP 为容器服务提供的告警模板，可快速创建针对 VCI 实例的监控告警规则。

告警降噪与聚合：

毛刺过滤：配置“N 分钟内触发 M 次后发送”的策略，过滤无效告警。

发送降频：开启“发送降频”功能，避免被告警轰炸。

告警聚合：设置合理的批次聚合间隔，让告警信息更清晰。

分级与通知：

告警分级：明确定义告警级别（如 P0 / Fatal, P1 / Warning, P2 / Notice），提升告警处理效率。

告警即工单与 SOP：

自动化：搭建告警到工单的自动化流程，确保每个重要告警均有闭环跟进。

关联 SOP：在告警信息中附上对应故障场景的排查手册，帮助响应人员快速定位和解决问题。

五、预防与优化设计：优雅地使用 VCI

优秀的系统设计能从源头上规避大量故障。以下是在使用 VCI 时，产品和研发同学应该在设计阶段就考虑的最佳实践。

镜像：轻量化与预热

保持镜像轻量：镜像是 Pod 启动速度的关键影响因素之一。遵循 VCI 验证规的最佳实践，构建多阶段 Dockerfile，只将必要的运行时和二进制文件打包到最终镜像中，避免包含编译工具、源码、文档等非运行必须的内容。

利用镜像缓存：对于需要大规模、快速拉起的应用，务必使用“自动镜像缓存”或“手动镜像缓存”功能。通过 Annotation 开启后，VCI 会提前将镜像数据缓存到目标可用区的云盘上。详情请参见 VCI 镜像缓存。

预热镜像缓存：新镜像或长期未使用的镜像，其缓存在首次使用时可能拉取较慢或已过期无法拉取。因此建议在大规模使用前，先创建少量 Pod 来触发和预热镜像缓存，待缓存状态变为 Ready.Ok 后再进行大规模部署。

容量：合理估算与配置

系统盘容量估算：VCI 默认系统盘为 40 GiB。对于使用大镜像、镜像缓存或在容器内写入大量临时文件的场景，系统盘用量可能不够。请务必使用vci.vke.volcengine.com/desired-system-storage Annotation（邀测功能）为 Pod 指定一个合理的、更大的系统盘容量，避免因 FailedCreateSystemDisk 而创建失败。更多信息，请参见 VCI 镜像缓存。

vci-profile 统一配置：强烈建议使用 vci-profile 来统一管理命名空间或集群级别的 VCI 配置，而不是在每个工作负载的 YAML 中单独指定。vci-profile 能确保配置的一致性（如子网、日志采集、安全上下文），降低因个体配置遗漏或错误导致的故障。详情请参见通过配置 vci-profile 使用 VCI。

GPU：驱动版本匹配

驱动与 CUDA 匹配：创建 GPU 类型的 VCI 实例时，可以通过vci.vke.volcengine.com/gpu-driver-version Annotation 指定 NVIDIA 驱动版本。请务必确保您应用镜像中使用的 CUDA Toolkit 版本与所选的驱动版本兼容。版本不匹配可能导致 GPU 无法正常工作或性能下降。具体匹配关系，请参见支持的 GPU 驱动版本。

默认即最优：如果您不确定如何选择，通常不设置该 Annotation，VCI 会自动为您选择与 GPU 型号最匹配的默认驱动版本。默认驱动版本，请参见支持的 GPU 驱动版本。

网络：规划先行，治理同步

清晰的网络规划：在业务设计阶段就应有清晰的网络拓扑规划。避免在生产环境中使用重叠或冲突的网段，特别是在使用 CEN 打通多 VPC 时，避免自定义路由与火山引擎公共服务网段（如 100.XX.XX.XX/11）的冲突。容器网端配置说明，请参见网络概述。

安全组最小权限：建议为 VCI 配置专门的安全组，并遵循最小权限原则，仅放通业务必要的协议和端口，避免使用0.0.0.0/0全放通。更多信息，请参见安全组设置、集群访问规则。

DNS 治理：对于高并发或对 DNS 解析延迟敏感的应用，建议在集群中启用 NodeLocal DNSCache，有效降低对 CoreDNS 的集中请求压力，提升服务发现的稳定性和性能。更多信息，请参见使用 NodeLocal DNSCache 缓存代理。

六、执行落地检查 (Checklist)

在您的产品/项目上线前，或进行故障排查后，可以对照以下清单进行检查，确保关键实践已落地：

序号	检查项	检查内容
1	核心告警已订阅	是否已为 Pod 的 Pending/Terminating 状态、内存/磁盘使用率、核心业务 SLI 配置了告警？
2	系统盘容量已评估	是否通过 Annotation，为使用大镜像或镜像缓存的 Pod 指定了足够的系统盘容量？
3	资源 limits 已设置	是否为所有容器（尤其在生产环境）设置了合理的 CPU 和内存 limits，以免出现资源争抢和 OOM？
4	健康检查已配置	是否为所有长期运行的服务配置了准确的 livenessProbe 和 readinessProbe？
5	vci-profile 已使用	是否通过 vci-profile 对 VCI 配置进行了统一管理？
6	安全组规则已收敛	安全组是否仅开放了必要的端口，避免了对0.0.0.0/0的过度暴露？
7	DNS 缓存已考虑	对于 DNS 解析敏感型应用，是否评估或开启了 NodeLocal DNSCache？

最近更新时间：2026.10.30 15:20:47

这个页面对您有帮助吗？

有用

无用

故障现象	可能原因	定位方法	建议修复
Pod 卡在 Pending 状态	资源配额/库存不足：账号下 VCI 实例的 vCPU/内存/GPU 配额耗尽，或当前可用区资源库存不足。调度条件无法满足：Pod 请求的资源规格（如特定 CPU / GPU 型号）、可用区、子网等条件无法被满足。 vci-profile 配置问题：vci-profile 中的选择器或配置项有误，导致 Pod 无法正确匹配 VCI 调度规则。控制面组件异常：VCI 调度器或 Virtual Kubelet 出现异常。	执行kubectl describe pod <pod-name>查看 Events，关注 FailedScheduling 事件，通常会明确指出原因（例如：Insufficient quota、No nodes available to schedule pods）。登录配额中心，检查 VCI 相关资源的配额使用情况。检查 Pod YAML 中annotations和nodeSelector等调度相关配置是否正确。检查kube-system命名空间下的vci-profile对应的 ConfigMap 配置是否符合预期。	提升配额：在配额中心申请提升相应资源的配额。详情请参见配额查看和申请。调整调度策略：放宽 Pod 的调度限制，例如尝试在其他可用区部署 VCI Pod 或更新 VCI 实例规格。检查库存：联系客户经理或技术支持确认目标可用区的资源库存情况。修复配置：根据故障/事件的 Message 等信息，修正 Pod YAML 或 vci-profile 中的错误配置。
Pod 卡在 Terminating 状态	业务进程状态：容器内的业务进程阻塞在内核态（Disk Sleep），无法响应 SIGTERM 信号。常见于 JuiceFS 等存储客户端未正常卸载，导致业务 I/O 阻塞。存储卷卸载失败：底层的 EBS 云盘或 NAS 等网络文件系统卸载操作长时间挂起。网络资源回收慢：ENI（弹性网卡）等网络资源的解绑或回收过程异常。 VCI 数据面节点异常：底层物理机或 MicroVM 出现故障，无法完成清理工作。	登录 VCI 实例（即 VCI 实例对应的 Pod），执行ps aux \| grep 'D'命令检查是否有处于 D 状态的进程。登录 Pod 方法，请参见管理容器组。查看 VCI 数据面节点的 containerd 或 kubelet 组件日志，寻找与 Pod 清理相关的错误信息。查看/var/log/bytedrive下的日志，排查存储问题。如果怀疑是业务进程问题，可在删除 Pod 前进入容器，检查进程状态和资源句柄占用情况。详情请参见查看容器组信息。	修复业务逻辑：确保应用能正确处理 SIGTERM 信号，并在退出前完成所有资源的清理，特别是存储客户端的umount操作。强制删除：执行kubectl delete pod <pod-name> --grace-period=0 --force命令，强制删除 Pod。注意强制删除 Pod 可能导致数据不一致或资源泄露，请谨慎操作。发起售后工单：如果无法自行解决，请提供 Pod 名称、命名空间和出现问题的时间点，联系售后支持团队介入。
Pod 状态为 CrashLoopBackOff	应用启动失败：程序本身存在 Bug、配置错误、依赖服务未就绪。资源不足：Pod 的requests或limits设置过低，应用启动时因 OOM (Out of Memory) 或 CPU 资源不足而被终止。健康检查失败：livenessProbe或readinessProbe配置不当，例如端口、路径错误，超时时间过短等，导致 Kubelet 误判应用异常并不断重启。权限问题：容器内进程没有权限读写所需的文件或目录。	执行kubectl logs <pod-name>命令，查看当前容器的日志，通常能直接找到启动失败的错误信息。执行kubectl logs <pod-name> --previous命令，查看上一次被终止的容器日志，对于排查 OOM 等问题非常关键。执行kubectl describe pod <pod-name>命令，查看 Events，关注Back-off restarting failed container等信息，并检查 State 部分的 Last State，查看退出原因（例如Exit Code: 137表示 OOMKilled）。	修复应用代码/配置。增加资源：适当调高 Pod Spec 中的resources.requests和 resources.limits。调整健康检查：检查并修正livenessProbe和readinessProbe的配置。修复权限：调整容器的 securityContext 或镜像中的文件权限。详情请参见配置安全上下文。

故障现象	可能原因	定位方法	建议修复
镜像拉取慢或失败 (ImagePullBackOff)	网络不通：VCI 实例无法访问目标镜像仓库（公网或私有仓库）。凭证错误 (ImagePullSecrets)：配置的imagePullSecrets不正确或凭证已过期，导致认证失败。镜像不存在/权限不足：镜像地址、Tag 错误，或当前账号无权拉取该镜像。镜像缓存问题：使用了自动镜像缓存，但系统盘容量 (vci.vke.volcengine.com/desired-system-storage) 指定过小，不足以容纳缓存。镜像缓存本身已损坏或过期。远端代理仓配置错误：通过vci.volcengine.com/registry-mirror-config配置的镜像代理，其地址或认证信息有误。	执行kubectl describe pod <pod-name>命令查看 Events，通常有详细的错误信息，例如Failed to pull image ... rpc error: code = Unknown desc = ...。登录到一台可访问目标仓库的机器上，尝试执行docker pull <image-name>:<tag>，验证镜像和凭证是否有效。检查 Pod YAML 中imagePullSecrets的配置，并确认对应的 Secret 内容是否正确。如果使用镜像缓存，请根据官网文档检查系统盘大小的 Annotation 是否按要求配置（例如，不小于镜像大小的 2~2.5 倍）。详情请参见 VCI 镜像缓存。	网络排查：确保 VCI 所在子网有正确的公网出口（NAT 网关）或到私有仓库的网络路径。更新凭证：创建或更新正确的 imagePullSecrets。修正镜像地址：使用正确的镜像仓库地址和 Tag。调整系统盘大小：为使用镜像缓存的 Pod 添加或调整vci.vke.volcengine.com/desired-system-storage Annotation。说明【邀测·申请试用】：vci.vke.volcengine.com/desired-system-storage Annotation 对应的功能，目前处于邀测阶段，如需使用，请提交申请。 P2P 加速：对于大镜像，可考虑使用 P2P 镜像加速方案。详情请参见 P2P 镜像加速方案。
创建 Pod 报 ProviderFailed / FailedCreateSystemDisk	系统盘容量不足：VCI 实例的系统盘（默认为 40GiB）不足以容纳操作系统、系统组件及容器镜像。特别是使用大镜像时容易触发。底层资源分配失败：数据面在分配计算、存储（EBS 卷）或网络资源时失败。账号欠费：账号余额不足，无法创建新的计费资源。	执行kubectl describe pod <pod-name>命令查看 Events，错误信息通常会包含"ProviderFailed"或"FailedCreateSystemDisk"等关键词。检查 Pod 使用的镜像大小。如果镜像较大，例如超过 15 GiB，则很可能是系统盘容量问题。登录费用中心，确认账号状态是否正常，余额是否充足。	增加系统盘容量：在 Pod 的metadata.annotations中添加vci.vke.volcengine.com/desired-system-storage: "80"（单位 GiB，邀测功能），明确指定更大的系统盘。您也可以指定其他合适的值，增加系统盘容量。确认账号余额：确保火山引擎账户余额（含代金券）不低于 100 元，且除去代金券后账户余额不为零。详细操作，请参见费用中心。重试：若底层偶发资源分配失败，可以简单地删除 Pod 并重建，可成功创建。如果持续创建失败，请联系您的火山引擎客户经理或提交工单获取技术支持。
卷挂载失败 (FailedMount)	EBS 云盘跨可用区挂载：尝试将一个可用区 A 的 EBS 卷挂载到位于可用区 B 的 VCI 实例上。 NAS/文件存储网络不通：VCI 实例与 NAS 文件系统的挂载点之间网络不通，或被安全组/ACL 阻止。 PV/PVC 配置错误：PersistentVolume（PV）或 PersistentVolumeClaim（PVC）的定义有误，例如storageClassName不匹配、容量不满足等。卷状态异常：云盘本身处于异常、已挂载或其他非可用状态。	执行kubectl describe pod <pod-name>命令查看 Events 中的FailedMount错误详情。检查 PV 的定义，确认其spec.csi.volumeHandle对应的云盘 ID，并到云服务器-云盘控制台查询该云盘的状态和所在可用区。执行kubectl get pod <pod-name> -o wide命令检查 Pod 的调度结果，确认其被调度的节点和可用区是否与云盘一致。如果卷的存储类型是 NAS，请检查 VCI 子网与 NAS 挂载点之间的路由和安全策略。	确保同可用区：使用nodeSelector或vci.vke.volcengine.com/preferred-availability-zones Annotation 将 Pod 调度到与 EBS 卷相同的可用区。打通网络：为 NAS 存储配置正确的网络访问策略。详情请参见文件存储（NAS）。修正 PV/PVC：检查并修复存储声明的配置。