任务

任务
管理集群
Debug DNS 方案
Enabling Service Topology (EN)
IP Masquerade Agent 用户指南
Kubernetes 云管理控制器
Safely Drain a Node while Respecting the PodDisruptionBudget (EN)
为 Kubernetes 运行 etcd 集群
为系统守护进程预留计算资源
为节点发布扩展资源
使用 CoreDNS 进行服务发现
使用 KMS 提供商进行数据加密
使用 Kubernetes API 访问集群
关键插件 Pod 的调度保证
启用端点切片
命名空间演练
在 Kubernetes 集群中使用 NodeLocal DNSCache
在 Kubernetes 集群中使用 sysctl
在实时集群上重新配置节点的 Kubelet
声明网络策略
开发云控制器管理器
控制节点上的 CPU 管理策略
控制节点上的拓扑管理策略
搭建高可用的 Kubernetes Masters
改变默认 StorageClass
更改 PersistentVolume 的回收策略
自定义 DNS 服务
访问集群上运行的服务
通过命名空间共享集群
通过配置文件设置 Kubelet 参数
配置 API 对象配额
配置多个调度器
配置资源不足时的处理方式
限制存储消耗
集群 DNS 服务自动伸缩
集群安全
集群管理
静态加密 Secret 数据
用插件扩展 kubectl
管理巨页(HugePages)
调度 GPUs

Edit This Page

集群故障排查

本篇文档是介绍集群故障排查的;我们假设对于你碰到的问题,你已经排除了是由应用程序造成的。 对于应用的调试,请参阅应用故障排查指南。 你也可以访问troubleshooting document来获取更多的信息。

显示出集群的节点列表

调试的第一步是查看所有的节点是否都正确的注册。

运行

kubectl get nodes

接下来,验证你的所有节点都能够显示出来,并且都处于Ready状态。

查看logs

现在,挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关log文件所在的位置。 (注意,对于基于systemd的系统,你可能需要使用journalctl)

Master

  • /var/log/kube-apiserver.log - API Server, 提供API服务
  • /var/log/kube-scheduler.log - Scheduler, 负责调度决策
  • /var/log/kube-controller-manager.log - 管理replication controllers的控制器

Worker Nodes

  • /var/log/kubelet.log - Kubelet, 管控节点上运行的容器
  • /var/log/kube-proxy.log - Kube Proxy, 负责服务的负载均衡

集群故障模式的概述

下面是一个不完整的列表,列举了一些可能出错的场景,以及通过调整集群配置来解决相关问题的方法。

根本原因:

  • VM(s)关机
  • 集群之间,或者集群和用户之间网络分裂
  • Kubernetes软件本身崩溃了
  • 数据丢失或者持久化存储不可用(如:GCE PD 或 AWS EBS卷)
  • 操作错误,如:Kubernetes或者应用程序配置错误

具体情况:

  • Apiserver所在的VM关机或者apiserver崩溃
    • 结果
      • 不能停止,更新,或者启动新的pods,services,replication controller
      • 现有的pods和services在不依赖Kubernetes API的情况下应该能继续正常工作
  • Apiserver 后端存储丢失

    • 结果
      • apiserver应该不能起来
      • kubelets将不能访问它,但是能够继续运行之前的Pods和提供相同的服务代理
      • 在apiserver重启之前,需要手动恢复或者重创apiserver的状态
  • Kubernetes服务组件(节点控制器,副本控制器,调度器等等)所在的VM关机或者崩溃

    • 当前,这些控制器是和apiserver共存的,它们不可用的现象是与apiserver类似的
    • 将来,这些控制器也会复制为多份,并且可能为非共存的
    • 它们没有自己的持久状态
  • 单个节点(VM或者物理机)关机

    • 结果
      • 此节点上的所有Pods都停止运行
  • 网络分裂(Network partition)

    • 结果
      • partition A认为partition B中所有的节点都down掉了;partition B认为apiserver是down掉了(假定master所在的VM位于partition A内)。
  • Kubelet软件故障

    • 结果
      • 崩溃的kubelet就不能在其所在的节点上启动新的pods
      • kubelet可能删掉pods或者不删
      • 节点被标识为非健康态
      • 副本控制器会在其它的节点上启动新的pods
  • 集群操作错误

    • 结果
      • 丢失pods,服务等等
      • 丢失apiserver后端存储
      • 用户无法读取API
      • 等等

缓解措施:

  • 措施:对于IaaS上的VMs,使用IaaS的自动VM重启功能

    • 缓解:Apiserver VM关机或apiserver崩溃
    • 缓解:Kubernetes服务组件所在的VM关机或崩溃
  • 措施: 对于具有apiserver+etcd的VM,使用IaaS提供的可靠的存储(例如GCE PD或者AWS EBS卷)

    • 缓解:Apiserver后端存储的丢失
  • 措施:使用(实验)高可用性的配置

    • 缓解:master VM关机或者master组件(scheduler, API server, controller-managing)崩馈
    • 将容许一个或多个节点或组件同时出现故障
    • 缓解:apiserver后端存储(例如etcd的数据目录)丢失
    • 假定你使用了集群化的etcd。
  • 措施:定期的对apiserver的PDs/EBS卷进行快照

    • 缓解:apiserver后端存储丢失
    • 缓解:一些操作错误的场景
    • 缓解:一些Kubernetes软件本身故障的场景
  • 措施:在pods的前面使用副本控制器或服务

    • 缓解:节点关机
    • 缓解:Kubelet软件故障
  • 措施:应用(容器)设计成容许异常重启

    • 缓解:节点关机
    • 缓解:Kubelet软件故障
  • 措施:多个独立的集群(并且避免一次性地对所有的集群进行有风险性的修改)

    • 缓解:以上列出的所有情况

反馈