使用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未部署，可以参考这里部署。