100个常用命令-Kubernetes-提升集群管理和故障排除效率 (100个常用的关联词)
本指南提供了全面的命令清单,用于诊断 Kubernetes 集群以及在其中运行的应用程序。请在使用这些命令时务必将占位符(如
<namespace>
和
<pod-name>
)替换为特定值。
集群信息
-
kubectl cluster-info
:获取有关集群的摘要信息。 -
kubectl get nodes
:列出集群中的节点。 -
kubectl describe nodes <node-name>
:获取特定节点的详细描述。
Pod 诊断
-
kubectl get pods
:列出集群中的所有 Pod。 -
kubectl describe pods <pod-name>
:获取特定 Pod 的详细描述,包括事件。 -
kubectl logs <pod-name>
:查看 Pod 的日志。 -
kubectl exec -it <pod-name> -- /bin/sh
:进入 Pod 的容器并执行命令。
Pod 健康检查
-
kubectl get pods --field-selector=status.phase==Pending
:列出处于“Pending”状态的 Pod。 -
kubectl get pods --field-selector=status.phase==Failed
:列出处于“Failed”状态的 Pod。 -
kubectl get pods --field-selector=status.reason
:列出具有指定原因的 Pod。
Service 诊断
-
kubectl get services
:列出集群中的所有服务。 -
kubectl describe services <service-name>
:获取特定服务的详细描述。 -
kubectl get endpoints <service-name>
:列出与服务关联的端点。
Deployment 诊断
-
kubectl get deployments
:列出集群中的所有 Deployment。 -
kubectl describe deployments <deployment-name>
:获取特定 Deployment 的详细描述。 -
kubectl rollout status deployments <deployment-name>
:检查 Deployment 的滚动状态。
StatefulSet 诊断
-
kubectl get statefulsets
:列出集群中的所有 StatefulSet。 -
kubectl describe statefulsets <statefulset-name>
:获取特定 StatefulSet 的详细描述。 -
kubectl rollout status statefulsets <statefulset-name>
:检查 StatefulSet 的滚动状态。
ConfigMap 和 Secret 诊断
-
kubectl get configmaps
:列出集群中的所有 ConfigMap。 -
kubectl get secrets
:列出集群中的所有 Secret。 -
kubectl describe configmaps <configmap-name>
:获取特定 ConfigMap 的详细描述。 -
kubectl describe secrets <secret-name>
:获取特定 Secret 的详细描述。
命名空间诊断
-
kubectl get namespaces
:列出集群中的所有命名空间。 -
kubectl describe namespaces <namespace-name>
:获取特定命名空间的详细描述。 -
kubectl get quota <namespace-name>
:查看命名空间中的资源配额。
资源使用情况
-
kubectl top nodes
:显示集群中节点的资源使用情况。 -
kubectl top pods <namespace-name>
:显示特定命名空间中 Pod 的资源使用情况。 -
kubectl get hpa
:列出集群中的所有水平 Pod 自动伸缩(HPA)。
网络诊断
-
kubectl get pods -o wide
:查看 Pod 的网络信息,包括 IP 地址和端口。 -
kubectl get services -o wide
:查看服务的网络信息,包括端口和外部 IP 地址。 -
kubectl get networkpolicies -o yaml
:列出集群中的所有网络策略。
![提升集群管理和故障排除效率](https://tyye.cn/zb_users/theme/tpure/style/images/lazyload.png)
持久卷(PV)和持久卷声明(PVC)诊断
-
kubectl get pv
:列出集群中的所有 PV。 -
kubectl get pvc
:列出集群中的所有 PVC。 -
kubectl describe pods <pod-name>
:检查 Pod 的存储卷状态。
节点诊断
-
kubectl get events --field-selector=involvedObject.kind=Node
:查看与节点相关的事件。 -
kubectl describe node <node-name>
:获取特定节点的详细描述。 -
kubectl cordon <node-name>
:将节点标记为不可调度。 -
kubectl uncordon <node-name>
:解除节点标记。
资源配额和限制
-
kubectl get quota
:列出集群中的所有资源配额。 -
kubectl get limits <namespace-name>
:查看命名空间中的资源限制。 -
kubectl describe resourcequotas <quota-name>
:获取特定资源配额的详细描述。
自定义资源定义(CRD)诊断
-
kubectl get crd
:列出集群中的所有 CRD。 -
kubectl describe crd <crd-name>
:获取特定 CRD 的详细描述。 -
kubectl get <custom-resource-name> -o yaml
:获取特定自定义资源的详细信息。
使用这些命令时,请记住
-
将
<namespace>
替换为命名空间。 -
将
<pod-name>
替换为 Pod 名称。 -
将
<service-name>
替换为服务名称。 -
将
<deployment-name>
替换为 Deployment 名称。 -
将
<statefulset-name>
替换为 Stateful
使用Kubernetes管理Kubernetes集群
Kubernetes 1.0版本发布已经过去了4年,繁荣的社区和广泛用户群体使得Kubernetes的成熟度超出了预期,大部分用户常用的功能性需求都得到了满足。 但是,根据CNCF的调查,很多非功能性的需求尚待完善,比如,用户所面临的最困难的挑战之一仍然是管理多个Kubernetes集群的生命周期,包括集群部署、升级和变更等。 Kubernetes社区未来的一个阶段的重点就是帮助用户更好的部署和维护Kubernetes,使其无缝的融入和对接现有的企业环境。 Kubernetes现在已经可以支持超大规模的集群,单集群可以支撑5000个节点,15万个POD。 但是由于大规模集群的维护和调度过于复杂,比如,有些企业应用需要分级,不同级别的应用需要使用不同的资源池,有些业务应用需要带有GPU支持的集群,有些应用需要Windows container的支持,甚至不同应用依赖不同版本的Kubernetes,所以在企业环境中通过多集群的方式实现多租户和资源调度已经成为了最佳实践。 当你需要管理多个集群,每个集群都有不同的规模、版本、升级计划、硬件资源池,自动化的管理工具和理念就必不可少了。 我们知道,Kubernetes的很多原则和理念改变了传统资源管理和交付的模式,其中声明式API和自愈机制的引入提升了用户部署和管理应用的效率。 它允许用户通过yaml文件描述对象部署的期望状态(比如部署3个POD实例),并持续观测当前状态,如果和预期不一致(只剩2个POD实例),就通过控制器使其达到期望状态(添加1个POD实例,使总数为预期的3个)。 既然这种模式如此的成功,能不能把它适用到更多的场景中呢?比如,能不能用Kubernetes的思想来管理Kubernetes的集群呢? 实际上社区中已经有人这么做了,Cluster API 就是在这个背景下,由google,vmware等公司共同发起的项目。 Cluster API是一个Kubernetes项目,它将声明式的、Kubernetes风格的API用于集群创建、配置和管理。 通过利用Kubernetes API的结构化和可扩展的特性,构建更高级别的云环境无关的工具,声明式的、自动化的改善用户体验。 当前,Cluster API已经可以支持AWS, Azure, GCP, Openstack, VMware, Bare metal等绝大多数基础设施环境。 在目前的版本中,该API包含五个customresourcedefinition(CRD):Cluster、Machine、MachineSet、MachineDeployment和MachineClass。 将这几个CRD和大家熟悉的Kubernetes的对象类比一下, 说明:以下的几个CRD yaml文件都可以自动生成模板,在创建cluster的时候,并不都是必须的。 Cluster这个CRD是全新的Kubernetes集群的抽象。 它可以定义Kubernetes集群配置,例如POD网络CIDR和service网络CIDR,以及集群是运行在何种云平台之上。 Machine类似于POD,它负责描述单个Kubernetes节点(虚拟机)。 只需很少的配置(主要是Kubernetes版本信息),其他配置通过嵌入云环境相关的ProviderSpec。 MachineDeloyment 类似于Deployment。 它允许对节点配置进行更新,定义工作节点的升级方式(rolling,recreate),它还允许回滚到以前的某个版本的配置。 用户可以修改yaml文件来动态调整集群节点的数量。 MachineSet类似于ReplicaSet,管理一组Machine的扩缩容。 与ReplicaSet类似,实践中尽量使用MachineDeloyment来管理一组资源的部署而不应该直接操作ReplicaSet。 MachineClass和StorageClass很像,定义Machine的规格。 所有节点都会从指定规格的虚拟机模板中clone出来。 Cluster API的工作原理非常简单,用户通过以上的几个CRD定义需要的Kubernetes集群的规格。 通过熟悉的kubectlapply命令把yaml传递给management cluster,managerment cluster会根据需要驱动不同的云平台创建虚拟机安装部署Kubernetes binary,并交付集群给用户。 那么management cluster是怎么来的?是否后续的运维工作也需要依赖它呢?实际上,初始的management cluster一般是一个单机版的Kubernetes,比如minikube或者Kind。 当置备出第一个workload cluster以后,可以将management cluster的功能转移到任何一个workload cluster,这样后续的工作就不在依赖单机版的Kubernetes。 一个有意思的地方是,你会发现,某一个workload cluster同时也是management cluster,在管理和监控着它自己。 下面是一个在vsphere环境使用Cluster API的例子。 首先,使用Cluster API项目提供的工具生成一组部署的yaml模板。 根据需求调整yaml文件中的内容,比如虚拟机模板的名称、集群节点的数量等。 然后依次创建这些资源对象, 这时可以在vcenter中看到Kubernetes集群的虚拟机陆续被创建出来。 大约几分钟后,workload cluster就可以交付给用户使用了。 我们可以关闭或者删除一个workload cluster的节点的虚拟机来模拟故障场景。 Cluster API会自动检测所有节点的状态,并且驱动vsphere重新生成一个虚拟机进行替代,使得Kubernetes集群的状态与预期描述的一致。 像不像Kubernetes管理POD的功能? 以上实验的具体的细节可参考官方文档,解决多集群生命周期的管理只是企业环境使用Kubernetes的第一步,后续还有什么问题是需要考虑的?
Kubernetes 集群状态异常排错
本章介绍集群状态异常的排错方法,包括 Kubernetes 主要组件以及必备扩展(如 kube-dns)等,而有关网络的异常排错请参考 网络异常排错方法 。 排查集群状态异常问题通常从 Node 和 Kubernetes 服务 的状态出发,定位出具体的异常服务,再进而寻找解决方法。 集群状态异常可能的原因比较多,常见的有 按照不同的组件来说,具体的原因可能包括 为了维持集群的健康状态,推荐在部署集群时就考虑以下 一般来说,可以首先查看 Node 的状态,确认 Node 本身是不是 Ready 状态 如果是 NotReady 状态,则可以执行kubectl describe node <node-name>命令来查看当前 Node 的事件。 这些事件通常都会有助于排查 Node 发生的问题。 在排查 Kubernetes 问题时,通常需要 SSH 登录到具体的 Node 上面查看 kubelet、docker、iptables 等的状态和日志。 在使用云平台时,可以给相应的 VM 绑定一个公网 IP;而在物理机部署时,可以通过路由器上的端口映射来访问。 但更简单的方法是使用 SSH Pod (不要忘记替换成你自己的 nodeName): 接着,就可以通过 ssh 服务的外网 IP 来登录 Node,如ssh user@52.52.52.52 。 在使用完后, 不要忘记删除 SSH 服务kubectl delete -f 。 一般来说,Kubernetes 的主要组件有两种部署方法 使用 systemd 等管理控制节点服务时,查看日志必须要首先 SSH 登录到机器上,然后查看具体的日志文件。 如 或者直接查看日志文件 而对于使用 Static Pod 部署集群控制平面服务的场景,可以参考下面这些查看日志的方法。 查看 Kubelet 日志需要首先 SSH 登录到 Node 上。 Kube-proxy 通常以 DaemonSet 的方式部署 由于 Dashboard 依赖于 kube-dns,所以这个问题一般是由于 kube-dns 无法正常启动导致的。 查看 kube-dns 的日志 可以发现如下的错误日志 这说明 kube-dns pod 无法转发 DNS 请求到上游 DNS 服务器。 解决方法为 如果错误日志中不是转发 DNS 请求超时,而是访问 kube-apiserver 超时,比如 这说明 Pod 网络(一般是多主机之间)访问异常,包括 Pod->Node、Node->Pod 以及 Node-Node 等之间的往来通信异常。 可能的原因比较多,具体的排错方法可以参考 网络异常排错指南 。 重启 kubelet 时报错Failed to start ContainerManager failed to initialise top level QOS containers (参考# ),临时解决方法是: 该问题已于2017年4月27日修复(v1.7.0+,# )。 更新集群到新版本即可解决这个问题。 当 NodeAllocatable 特性未开启时(即 kubelet 设置了--cgroups-per-qos=false),查看 node 的事件会发现每分钟都会有Failed to update Node Allocatable Limits的警告信息: 如果 NodeAllocatable 特性确实不需要,那么该警告事件可以忽略。 但根据 Kubernetes 文档Reserve Compute Resources for System Daemons ,最好开启该特性: 开启方法为: kube-proxy 报错,并且 service 的 DNS 解析异常 解决方式是安装conntrack-tools包后重启 kube-proxy 即可。 正常情况下,Dashboard 首页应该会显示资源使用情况的图表,如 如果没有这些图表,则需要首先检查 Heapster 是否正在运行(因为Dashboard 需要访问 Heapster 来查询资源使用情况): 如果查询结果为空,说明 Heapster 还未部署,可以参考来部署。 但如果 Heapster 处于正常状态,那么需要查看 dashboard 的日志,确认是否还有其他问题 查看 HPA 的事件,发现 这说明metrics-server未部署,可以参考这里部署。
免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。