2.2 部署Kubernetes集群
Kubernetes系统可运行于多种平台之上，包括虚拟机、裸服务器或PC等，例如本地主机或托管的云端虚拟机。若仅用于快速了解或开发的目的，那么读者可直接于单个主机之上部署“伪”分布式的Kubernetes集群，将集群的所有组件均部署运行于单台主机上，著名的minukube项目可帮助用户快速构建此类环境。如果要学习使用Kubernetes集群的完整功能，则应该构建真正的分布式集群环境，将Master和Node等部署于多台主机之上，主机的具体数量要按实际需求而定。另外，集群部署的方式也有多种选择，简单的可以基于kubeadm一类的部署工具运行几条命令即可实现，而复杂的则可以是从零开始手动构建集群环境。
2.2.1 kubeadm部署工具
kubeadm是Kubernetes项目自带的集群构建工具，它负责执行构建一个最小化的可用集群以及将其启动等的必要基本步骤，简单来讲，kubeadm是Kubernetes集群全生命周期的管理工具，可用于实现集群的部署、升级/降级及拆除，如图2-6所示。不过，在部署操作中，kubeadm仅关心如何初始化并启动集群，余下的其他操作，例如安装Kubernetes Dashboard、监控系统、日志系统等必要的附加组件则不在其考虑范围之内，需要管理员按需自行部署。
图2-6 kubeadm功能示意图
kubeadm集成了kubeadm init和kubeadm join等工具程序，其中kubeadm init用于集群的快速初始化，其核心功能是部署Master节点的各个组件，而kubeadm join则用于将节点快速加入到指定集群中，它们是创建Kubernetes集群最佳实践的“快速路径”。另外，kubeadm token可于集群构建后管理用于加入集群时使用的认证令牌（token），而kubeadm reset命令的功能则是删除集群构建过程中生成的文件以重置回初始状态。
kubeadm还支持管理初始引导认证令牌（Bootstrap Token），完成待加入的新节点首次联系API Server时的身份认证（基于共享密钥）。另外，它们还支持管理集群版本的升级和降级操作。Kubernetes 1.8版本之前，kubeadm一直处于beta级别，并警告不能用于生产环境。不过，自1.9版本开始，其虽仍处于beta版本，但已经不再输出警告信息，而随着1.11版本发布的kubeadm又得到了进一步的增强，它支持动态配置kubelet，通过增强的CRI集成支持动态探测以判定所用的容器引擎，并引入了几个新的命令行工具，包括kubeadm config print-default、kubeadm config migrate、kubeadm config images pull和kubeadm upgrade node config等。总体来说，使用kubeadm部署Kubernetes集群具有如下几个方面的优势。
□简单易用：kubeadm可完成集群的部署、升级和拆除操作，并且对新手用户非常友好。
□适用领域广泛：支持将集群部署于裸机、VMware、AWS、Azure、GCE及更多环境的主机上，且部署过程基本一致。
□富有弹性：1.11版中的kubeadm支持阶段式部署，管理员可分为多个独立步骤完成部署操作。
□生产环境可用：kubeadm遵循以最佳实践的方式部署Kubernetes集群，它强制启用RBAC，设定Master的各组件间以及API Server与kublet之间进行认证及安全通信，并锁定了kubelet API等。
由此可见，kubeadm并非一键安装类的解决方案，相反，它有着更宏大的目标，旨在成为一个更大解决方案的一部分，试图为集群创建和运营构建一个声明式的API驱动模型，它将集群本身视为不可变组件，而升级操作等同于全新部署或就地更新。目前，使用kubeadm部署集群已经成为越来越多的Kubernetes工程师的选择。
2.2.2 集群运行模式
Kubernetes集群支持三种运行模式：一是“独立组件”模式，系统各组件直接以守护进程的方式运行于节点之上，各组件之间相互协作构成集群，如图2-7b所示；第二种是“静态Pod模式”，除kubelet和Docker之外的其他组件（如etcd、kube-apiserver、kube-controller-manager和kube-scheduler等）都是以静态Pod对象运行于Master主机之上的，如图2-7a所示；第三种是Kubernetes的“自托管”（self-hosted）模式，它类似于第二种方式，将除了kubelet和Docker之外的其他组件运行为集群之上的Pod对象，但不同的是，这些Pod对象托管运行在集群自身之上受控于DaemonSet类型的控制器，而非静态的Pod对象。
图2-7 Kubernetes集群的运行模式（图2-7a为静态Pod模式）
使用kubeadm部署的Kubernetes集群可运行为第二种或第三种模式，默认为静态Pod对象模式，需要使用自托管模式时，kubeadm init命令使用“--features-gates=selfHosting”选项即可。第一种模式集群的构建需要将各组件运行于系统之上的独立守护进程中，其间需要用到的证书及Token等认证信息也都需要手动生成，过程烦琐且极易出错；若有必要用到，则建议使用GitHub上合用的项目辅助进行，例如，通过ansible playbook进行自动部署等。
2.2.3 准备用于实践操作的集群环境
本书后面的篇幅中用到的测试集群如图2-8所示，该集群由一个Master主机和三个Node主机组成，它基于kubeadm部署，除了kubelet和Docker之外其他的集群组件都运行于Pod对象中。多数情况下，两个或以上的独立运行的Node主机即可测试分布式集群的核心功能，因此其数量可按需定义，但两个主机是模拟分布式环境的最低需求。生产实践中，应该至少部署三个协同工作的Master节点以确保控制平面的服务可用性，不过，在测试环境中仅部署一个Master节点也是常见的选择。
图2-8 Kubernetes集群部署目标示意图
各Node上采用的容器运行时环境为docker，后续的众多容器的运行任务都将依赖于Docker Registry服务，包括DockerHub、GCR（Google Container Registry）和Quay等，甚至是私有的Registry服务，本书假设读者对Docker容器技术有熟练的使用基础。另外，本部署示例中使用的用于为Pod对象提供网络功能的插件是flannel，其同样以Pod对象的形式托管运行于Kubernetes系统之上。
具体的部署过程以及本书用到的集群环境请参考附录A，本章后续的操作都将依赖于根据其步骤部署完成的集群环境，读者需要根据其内容成功搭建出Kubernetes测试集群后才能进行后面章节的学习。
2.2.4 获取集群环境相关的信息
Kubernetes系统目前仍处于快速迭代阶段，版本演进频繁，读者所部署的版本与本书中使用的版本或将有所不同，其功能特性也将存在一定程度的变动。因此，事先查看系统版本，以及对比了解不同版本间的功能特性变动也将是不可或缺的步骤。当然，用户也可选择安装与本书相同的系统版本。下面的命令显示的是当前使用的客户端及服务端程序版本信息：
[root@master～]# kubectl version --short=true
Client Version: v1.12.1
Server Version: v1.12.1
提示
Kubernetes系统版本变动时的ChangeLog可参考github.com站点上相关版本中的介绍。
Kubernetes集群以及部署的附件CoreDNS等提供了多种不同的服务，客户端访问这些服务时需要事先了解其访问接口，管理员可使用“kubectl cluster-info”命令获取相关的信息。
[root@master～]# kubectl cluster-info
Kubernetes master is running at https://172.16.0.70:6443
CoreDNS is running at https://172.16.0.70:6443/api/v1/namespaces/kube-system/
services/kube-dns:dns/proxy
一个功能完整的Kubernetes集群应当具备的附加组件还包括Dashboard、Ingress Controller和Heapster（或Prometheus）等，后续章节中的某些概念将会依赖到这些组件，读者可选择在将要用到时再进行部署。