任务
安装工具
管理集群
管理集群
用 kubeadm 进行管理
管理内存,CPU 和 API 资源
Install a Network Policy Provider
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 数据
配置 Pods 和容器
配置 Pods 和容器
为容器和 Pod 分配内存资源
Assign CPU Resources to Containers and Pods
Configure GMSA for Windows Pods and containers (EN)
为 Windows 的 pod 和容器配置 RunAsUserName
配置 Pod 的服务质量
为容器分派扩展资源
配置 Pod 以使用卷进行存储
配置 Pod 以使用 PersistentVolume 作为存储
配置 Pod 使用投射卷作存储
Configure a Security Context for a Pod or Container (EN)
为 Pod 配置服务账户
从私有仓库拉取镜像
配置存活、就绪和启动探测器
将 Pod 分配给节点
配置 Pod 初始化
为容器的生命周期事件设置处理函数
使用 ConfigMap 配置 Pod
在 Pod 中的容器之间共享进程命名空间
创建静态 Pod
将 Docker Compose 文件转换为 Kubernetes 资源
管理 Kubernetes 对象
给应用注入数据
运行应用
访问集群中的应用程序
监控、日志和排错
扩展 Kubernetes
联邦 - 在多个集群上运行一个应用
用插件扩展 kubectl
管理巨页(HugePages)
调度 GPUs
集群故障排查
本篇文档是介绍集群故障排查的;我们假设对于你碰到的问题,你已经排除了是由应用程序造成的。 对于应用的调试,请参阅应用故障排查指南。 你也可以访问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软件故障
措施:多个独立的集群(并且避免一次性地对所有的集群进行有风险性的修改)
- 缓解:以上列出的所有情况
反馈
此页是否对您有帮助?
感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题,可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题 报告问题 或者 提出改进建议.