Kubernetes 是一个由 Google 发起的开源自动化部署，缩放，以及容器化管理应用程序的容器编排系统。

部署 Kubernetes 曾经是一件相当麻烦的事情，早期版本中，Kubelet、Api-Server、Etcd、Controller-Manager 等每一个组件都需要自己单独去部署，还要创建自签名证书来保证各个组件之间的网络访问。但程序员大概是最爱与麻烦做斗争的群体，随着 Kubernetes 的后续版本不断改进（如提供了自动生成证书、Api-Server 等组件改为默认静态 Pod 部署方式），使得部署和管理 Kubernetes 集群正在变得越来越容易起来。目前主流的方式大致有：

以上集中部署方式都有很明显的针对性，个人开发环境以 Minikube 最简单，生产环境以 Rancher 最简单，在云原生环境中，自然是使用环境提供的相应工具。不过笔者推荐首次接触 Kubernetes 的同学最好还是选择 Kubeadm 来部署，毕竟这是官方提供的集群管理工具，是相对更底层、基础的方式，充分熟悉了之后再接触其他简化的方式会快速融会贯通。 以上部署方式无需全部阅读，根据自己环境的情况选择其一即可。

尽管使用 Rancher 或者 KubeSphere 这样更高层次的管理工具，可以更“傻瓜式”地部署和管理 Kubernetes 集群，但 kubeadm 作为官方提供的用于快速安装 Kbuernetes 的命令行工具，仍然是一项应该掌握的基础技能。kubeadm 随着新版的 Kubernetes 同步更新，时效性也会比其他更高层次的管理工具来的更好。现在 kuberadm 无论是部署单控制平面（Single Control Plane，单 Master 节点）集群还是高可用（High Availability，多 Master 节点）集群，都已经有了很优秀的易用性，手工部署 Kubernetes 集群已经不是什么太复杂、困难的事情了。本文以 Debian 系的 Linux 为例，介绍通过 kuberadm 部署集群的全过程。

注意事项

由于 Kubernetes 并不在主流 Debian 系统自带的软件源中，所以要手工注册，然后才能使用apt-get安装。

官方的 GPG Key 地址为：https://packages.cloud.google.com/apt/doc/apt-key.gpg，其中包括的软件源的地址为：https://apt.kubernetes.io/（该地址最终又会被重定向至：https://packages.cloud.google.com/apt/）。如果能访问 google.com 域名的机器，采用以下方法注册 apt 软件源是最佳的方式：

# 添加GPG Key
$ sudo curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
# 添加K8S软件源
$ sudo add-apt-repository "deb https://apt.kubernetes.io/ kubernetes-xenial main"

对于不能访问 google.com 的机器，就要借助国内的镜像源来安装了。虽然在这些镜像源中我已遇到过不止一次同步不及时的问题了——就是官方源中已经发布了软件的更新版本，而镜像源中还是旧版的，除了时效性问题外，还出现过其他的一些一致性问题，但是总归比没有的强。国内常见用的 apt 源有阿里云的、中科大的等，具体为：

它们的使用方式与官方源注册过程是一样的，只需替换里面的 GPG Key 和软件源的 URL 地址即可，譬如阿里云：

# 添加GPG Key
$ curl -fsSL http://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add -
# 添加K8S软件源
$ sudo add-apt-repository "deb http://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial main"

添加源后记得执行一次更新：

$ sudo apt-get update

并不需要在每个节点都装上 kubectl，但都装上也无不可。下面简要列出了这三个工具/组件的作用，现在看不看得懂都没有关系，以后用到它们的机会多得是，要相信日久总会生情的。

$ sudo apt-get install kubelet kubeadm kubectl

在使用 kubeadm 初始化集群之前，还有一些必须的前置工作要妥善处理：

首先，基于安全性（如在官方文档中承诺的 Secret 只会在内存中读写，不会落盘）、利于保证节点同步一致性等原因，从 1.8 版开始，Kubernetes 就在它的文档中明确声明了它默认不支持 Swap 分区，在未关闭 Swap 分区的机器中，集群将直接无法启动。关闭 Swap 的命令为：

$ sudo swapoff -a

上面这个命令是一次性的，只在当前这次启动中生效，要彻底关闭 Swap 分区，需要在文件系统分区表的配置文件中去直接除掉 Swap 分区。你可以使用文本编辑器打开/etc/fstab，注释其中带有“swap”的行即可，或使用以下命令直接完成修改：

# 还是先备份一下
$ yes | sudo cp /etc/fstab /etc/fstab_bak
# 进行修改
$ sudo cat /etc/fstab_bak | grep -v swap > /etc/fstab

其次，由于 Kubernetes 与 Docker 默认的 cgroup（资源控制组）驱动程序并不一致，Kubernetes 默认为systemd，而 Docker 默认为cgroupfs。

更新信息

从 1.18 开始，Kubernetes 默认的 cgroup 驱动已经默认修改成cgroupfs了，这时候再进行改动反而又会不一致

在这里我们要修改 Docker 或者 Kubernetes 其中一个的 cgroup 驱动，以便两者统一。根据官方文档《CRI installation》中的建议，对于使用 systemd 作为引导系统的 Linux 的发行版，使用 systemd 作为 Docker 的 cgroup 驱动程序可以服务器节点在资源紧张的情况表现得更为稳定。

这里选择修改各个节点上 Docker 的 cgroup 驱动为systemd，具体操作为编辑（无则新增）/etc/docker/daemon.json文件，加入以下内容即可：

{
  "exec-opts": ["native.cgroupdriver=systemd"]
}

然后重新启动 Docker 容器：

$ systemctl daemon-reload
$ systemctl restart docker

预拉取镜像并不是必须的，本来初始化集群的时候系统就会自动拉取 Kubernetes 中要使用到的 Docker 镜像组件，也提供了一个kubeadm config images pull命令来一次性的完成拉取，这都是因为如果要手工来进行这项工作，实在非常非常非常地繁琐。

但对于许多人来说这项工作往往又是无可奈何的，Kubernetes 的镜像都存储在 k8s.gcr.io 上，如果您的机器无法直接或通过代理访问到 gcr.io（Google Container Registry。笔者敲黑板：这也是属于谷歌的网址）的话，初始化集群时自动拉取就无法顺利进行，所以就不得不手工预拉取。

预拉取的意思是，由于 Docker 只要查询到本地有相同（名称和 tag 完全相同、哈希相同）的镜像，就不会访问远程仓库，那只要从 GitHub 上拉取到所需的镜像，再将 tag 修改成官方的一致，就可以跳过网络访问阶段。

首先使用以下命令查询当前版本需要哪些镜像：

$ kubeadm config images list --kubernetes-version v1.17.3
k8s.gcr.io/kube-apiserver:v1.17.3
k8s.gcr.io/kube-controller-manager:v1.17.3
k8s.gcr.io/kube-scheduler:v1.17.3
k8s.gcr.io/kube-proxy:v1.17.3
k8s.gcr.io/pause:3.1
k8s.gcr.io/etcd:3.4.3-0
k8s.gcr.io/coredns:1.6.5
……

这里必须使用--kubernetes-version参数指定具体版本，因为尽管每个版本需要的镜像信息在本地是有存储的，但如果不加的话，Kubernetes 将向远程 GCR 仓库查询最新的版本号，会因网络无法访问而导致问题。但加版本号的时候切记不能照抄上面的命令中的“v1.17.3”，应该与你安装的 kubelet 版本保持一致，否则在初始化集群控制平面的时候会提示控制平面版本与 kubectl 版本不符。

得到这些镜像名称和 tag 后，可以从DockerHub上找存有相同镜像的仓库来拉取，至于具体哪些公开仓库有，考虑到以后阅读本文时 Kubernetes 的版本应该会有所差别，所以需要自行到网站上查询一下。笔者比较常用的是一个名为“anjia0532”的仓库，有机器人自动跟官方同步，相对比较及时。

#以k8s.gcr.io/coredns:1.6.5为例，每个镜像都要这样处理一次
$ docker pull anjia0532/google-containers.coredns:1.6.5
#修改tag
$ docker tag anjia0532/google-containers.coredns:1.6.5 k8s.gcr.io/coredns:1.6.5
#修改完tag后就可以删除掉旧镜像了
$ docker rmi anjia0532/google-containers.coredns:1.6.5

到了这里，终于可以开始 Master 节点的部署了，先确保 kubelet 是开机启动的：

$ sudo systemctl start kubelet
$ sudo systemctl enable kubelet

接下来使用 su 直接切换到 root 用户（而不是使用 sudo），然后使用以下命令开始部署：

$ kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --kubernetes-version v1.17.3 \
  --control-plane-endpoint <USE_DOMAIN_NOT_IP>

这里解释一下使用这几个参数的原因：

--kubernetes-version参数（要注意版本号与 kubelet 一致）的目的是与前面预拉取是一样的，避免额外的网络访问去查询版本号；如果能够科学上网，不需要加这个参数。

--pod-network-cidr参数是给Flannel网络做网段划分使用的，着在稍后介绍完 CNI 网络插件时会去说明。

--control-plane-endpoint参数是控制面的地址，强烈建议使用一个域名代替直接的IP地址来建立Kubernetes集群。因为CA证书直接与地址相关，Kubernetes中诸多配置（配置文件、ConfigMap资源）也直接存储了这个地址，一旦更换IP，要想要不重置集群，手工换起来异常麻烦。所以最好使用hostname（仅限单节点实验）或者dns name。

命令执行完毕，当看到下面信息之后，说明集群主节点已经安装完毕了。

这信息先恭喜你已经把控制平面安装成功了，但还有三行“you need……”、“you should……”、“you can……”开头的内容，这是三项后续的“可选”工作，下面继续介绍。

使用 Kubernetes 前需要为当前用户先配置好 admin.conf 文件。切换至需配置的用户后，进行如下操作：

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

CNI 即“容器网络接口”，在 2016 年，CoreOS 发布了 CNI 规范。2017 年 5 月，CNI 被 CNCF 技术监督委员会投票决定接受为托管项目，从此成为不同容器编排工具（Kubernetes、Mesos、OpenShift）可以共同使用的、解决容器之间网络通讯的统一接口规范。

部署 Kubernetes 时，我们可以有两种网络方案使得以后受管理的容器之间进行网络通讯：

第一种方案，尤其不在 GCP 或者 AWS 的云主机上，没有它们的命令行管理工具时，需要大量的手工配置，基本上是反人类的。实际通常都会采用第二种方案，使用 CNI 插件来处理容器之间的网络通讯，所以本节虽然标识了“可选”，但其实也并没什么选择不安装 CNI 插件的余地。

Kubernetes 目前支持的 CNI 插件有：Calico、Cilium、Contiv-VPP、Flannel、Kube-router、Weave Net 等多种，每种网络提供了不同的管理特性（如 MTU 自动检测）、安全特性（如是否支持网络层次的安全通讯）、网络策略（如 Ingress、Egress 规则）、传输性能（甚至对 TCP、UDP、HTTP、FTP、SCP 等不同协议来说也有不同的性能表现）以及主机的性能消耗。如果你还需要阅读本文来部署 Kubernetes 环境的话，那不用纠结了，直接使用 Flannel 是较为合适的，它是最精简的 CNI 插件之一，没有安全特性的支持，主机压力小，安装便捷，效率也不错，使用以下命令安装 Flannel 网络：

$ curl --insecure -sfL https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml | kubectl apply -f -

使用 Flannel 的话，要注意要在创建集群时加入--pod-network-cidr参数，指明网段划分。如果你是跟着本文去部署的话，这个操作之前已经包含了。

污点（Taint）是 Kubernetes Pod 调度中的概念，在这里通俗地理解就是 Kubernetes 决定在集群中的哪一个节点建立新的容器时，要先排除掉带有特定污点的节点，以避免容器在 Kubernetes 不希望运行的节点中创建、运行。默认情况下，集群的 Master 节点是会带有特定污点的，以避免容器分配到 Master 中创建。但对于许多学习 Kubernetes 的同学来说，并没有多么宽裕的机器数量，往往是建立单节点集群或者最多只有两、三个节点，这样 Master 节点不能运行容器就显得十分浪费了。如需移除掉 Master 节点上所有的污点，在 Master 节点上执行以下命令即可：

$ kubectl taint nodes --all node-role.kubernetes.io/master-

做到这步，如果你只有一台机器的话，那 Kubernetes 的安装已经宣告结束了，可以使用此环境来完成后续所有的部署。你还可以通过cluster-info和get nodes子命令来查看一下集群的状态，类似如下所示：

Kubernetes 默认的 NodePort 范围为 30000-32767，如果你是在测试环境，集群前端没有专门布置负载均衡器的话，那就经常需要通过 NodePort 来访问服务，这样限制了只能使用 30000 以上的端口，虽然能避免冲突，但并不够方便。为了方便使用低端口，可能需要修改此范围，这需要调整 Api-Server 的启动参数，具体操作如下（如过是高可用部署，需要对每一个 Master 节点进行修改）：

由于 kubectl 命令在后面十分常用，而且 Kubernetes 许多资源名称都带有随机字符，要手工照着敲很容易出错，强烈推荐启用命令自动补全的功能，这里仅以 bash 和笔者常用的 zsh 为例，如果您使用其他 shell，需自行调整：

在安装 Master 节点时候，输出的最后一部分内容会类似如下所示：

Then you can join any number of worker nodes by running the following on each as root:
  kubeadm join 10.3.7.5:6443 --token ejg4tt.y08moym055dn9i32 \
    --discovery-token-ca-cert-hash sha256:9d2079d2844fa2953d33cc0da57ab15f571e974aa40ccb50edde12c5e906d513

这部分内容是告诉用户，集群的 Master 节点已经建立完毕，其他节点的机器可以使用“kubeadm join”命令加入集群。这些机器只要完成 kubeadm、kubelet、kubectl 的安装即可、其他的所有步骤，如拉取镜像、初始化集群等，都不需要去做，就是可以使用该命令加入集群了。需要注意的是，该 Token 的有效时间为 24 小时，如果超时，使用以下命令重新获取：

$ kubeadm token create --print-join-command

Rancher 是在 Kubernetes 更上层的管理框架，Rancher 是图形化的，有着比较傻瓜式的操作，只有少量一两处地方（如导入集群）需要用到 Kubernetes 命令行。也由于它提供了一系列容器模版、应用商店等的高层功能，使得要在 Kubernetes 上部署一个新应用，简化到甚至只需要点几下鼠标即可，因此用户们都爱使用它。

Rancher 还推出了 RancherOS（极致精简专为容器定制的 Linux，尤其适合边缘计算环境）、K3S（Kubernetes as a Service，5 Less Than K8S，一个大约只有 40MB，可以运行在 x86 和 ARM 架构上的极小型 Kubernetes 发行版）这样的定制产品，用以在用户心中暗示、强化比 K8S 更小、更简单、更易用的主观印象。

不过也由于 Rancher 入门容易，基础性的应用需求解决起来很方便，也导致了不少人一开始使用它之后，就陷入了先入为主的印象，后期再接触 Kubernetes 时，便觉得学习曲线特别陡峭，反而限制了某些用户对底层问题的进一步深入。

在本文中，笔者以截图为主，展示如何使用 Rancher 来导入或者创建 Kubernetes 集群的过程。

前置条件：已经 安装好 Docker 。

使用 Docker 执行 Rancher 镜像，执行以下命令即可：

$ sudo docker run -d --restart=unless-stopped -p 8080:80 -p 8443:443 rancher/rancher

前置条件：已经安装好了 Kubernetes 集群。

使用 Rancher 的导入功能将已部署的 Kubernetes 集群纳入其管理。登陆 Rancher 主界面（首次登陆会要求设置 admin 密码和 Rancher 在集群中可访问的路径，后者尤其不能乱设，否则 Kubernetes 无法访问到 Rancher 会一直处于 Pending 等待状态）之后，点击右上角的 Add Cluster，然后有下面几个添加集群的选择：

这里选择“Import an existing cluster”，然后给集群起个名字以便区分（由于 Rancher 支持多集群管理，所以集群得有个名字以示区别），之后就看见这个界面：

Rancher 自动生成了加入集群的命令，这行命令其实就是部署一个运行在 Kubernetes 中的代理（Agent），在 Kubernetes 的命令行中执行以上自动生成的命令。

最后那条命令意思是怕由于部署的 Rancher 服务没有申请 SSL 证书，导致 HTTPS 域名验证过不去，kubectl 下载不下来 YAML。如果你的 Rancher 部署在已经申请了证书的 HTTPS 地址上那可以用前面的，否则还是直接用 curl --insecure 命令来绕过 HTTPS 证书查验吧，譬如以下命令所示：

$ curl --insecure -sfL https://localhost:8443/v3/import/vgkj5tzphj9vzg6l57krdc9gfc4b4zsfp4l9prrf6sb7z9d2wvbhb5.yaml | kubectl apply -f -

多说一句，用哪条命令安装的 Agent 只决定了 YAML 文件是如何下载获得的，对后续其他事情是毫无影响的，所以怎么简单怎么来，别折腾。

执行结果类似如下所示，一堆 secret、deployment、daementset 创建成功，就代表顺利完成了：

然后回到 Rancher 网页，点击界面上的“Done”按钮。可以看到集群正处于 Pending 状态：

如果 Agent 成功到达 Running 状态的话，这里也会很快就变成 Waiting 状态，然后再变为 Active 状态，导入工作即宣告胜利结束。

而如果一直持续 Pending 状态，说明安装的 Agent 运行失败。典型的原因是无法访问到 Rancher 的服务器，这时可以通过 kubectl logs 命令查看一下 cattle-cluster-agent-xxx 的日志，通常会看见"XXX is not accessible"，其中的 XXX 是 Rancher 第一次进入时跟你确认过的访问地址，假如你乱填了，或者该地址被防火墙挡掉，又或者因为证书限制等其他原因导致 Agent 无法访问，Rancher 就会一直 Pending。

最后再提一句，Rancher 与 Kubernetes 集群之间是被动链接的，即由 Kubernetes 去主动找 Rancher，这意味着部署在外网的 Rancher，可以无障碍地管理处于内网（譬如 NAT 后）的 Kubernetes 集群，这对于大量没有公网 IP 的集群来说是很方便的事情。

也可以直接使用 Rancher 直接在裸金属服务器上创建 Kubernetes 集群，此时在添加集群中选择 From existing nodes (Custom)，在自定义界面中，设置要安装的集群名称、Kubernetes 版本、CNI 网络驱动、私有镜像库以及其他一些集群的参数选项。

下一步确认该主机在 Kubernetes 中扮演的角色，每台主机可以扮演多个角色。但至少要保证每个集群都有一个 Etcd 角色、一个 Control 角色、一个 Worker 角色。

复制生成的命令，在要安装集群的每一台主机的 SSH 中执行。此时 Docker 会下载运行 Rancher 的 Agent 镜像，当执行成功后，Rancher 界面会有提示新主机注册成功。

点击完成，将会在集群列表中看见正在 Provisioning 的新集群，稍后将变为 Active 状态.

安装完成后你就可以在 Rancher 的图形界面管理 Kubernetes 集群了，如果还需要在命令行中工作，kubectl、kubeadm 等工具是没有安装的，可参考“ 使用 Kubeadm 部署 Kubernetes 集群”的内容安装使用。

Minikube 是 Kubernetes 官方提供的专门针对本地单节点集群的 Kubernetes 集群管理工具。针对本地环境对 Kubernetes 使用有一定的简化和针对性的补强。这里简要介绍其安装过程

Minikube 是一个单文件的二进制包，安装十分简单，在已经完成 部署 Docker CE 容器环境 的前提下，使用以下命令可以下载并安装最新版的 Minikube。

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

Minikube 中很多提供了许多子命令以代替 Kubectl 的功能，安装 Minikube 时并不会一并安装 Kubectl。但是 Kubectl 作为集群管理的命令行，要了解 Kubernetes 是无论如何绕不过去的，通过以下命令可以独立安装 Kubectl 工具。

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin/

有了 Minikube，通过 start 子命令就可以一键部署和启动 Kubernetes 集群了，具体命令如下：

$ minikube start --iso-url=https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/iso/minikube-v1.6.0.iso
                 --registry-mirror=https://registry.docker-cn.com
                 --image-mirror-country=cn
                 --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers
                 --vm-driver=none
                 --memory=4096

以上命令中，明确要求 Minikube 从指定的地址下载虚拟机镜像、Kubernetes 各个服务 Pod 的 Docker 镜像，并指定了使用 Docker 官方节点作为国内的镜像加速服务。

“vm-drvier”参数是指 Minikube 所采用的虚拟机，根据不同操作系统，不同的虚拟机可以有以下选项：

特别需要提一下的是如果读者使用的并非物理机器，而是云主机环境——现在流行将其成为“裸金属”（Bare Metal）服务器，那在上面很可能是无法再部署虚拟机环境的，这时候应该将 vm-drvier 参数设为 none。也可以使用以下命令设置虚拟机驱动的默认值：

$ minikube config set vm-driver none

至此，整个 Kubernetes 就一键启动完毕了。其他工作，如命令行的自动补全，可参考使用Kubeadm 安装 Kubernetes 集群中相关内容。