Code 片段

作者：Bert

2023-07-21
广东
本文字数：3367 字
阅读完需：约 11 分钟

目标：搭建一个完整的 Kubernetes 集群

1、在所有节点上安装 Docker 和 kubeadm；

2、部署 Kubernetes Master；

3、部署容器网络插件；

4、部署 Kubernetes Worker；

5、部署 Dashboard 可视化插件；

6、部署容器存储插件。

一、安装 kubeadm 和 Docker

$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -$ cat <<EOF > /etc/apt/sources.list.d/kubernetes.listdeb http://apt.kubernetes.io/ kubernetes-xenial mainEOF$ apt-get update$ apt-get install -y docker.io kubeadm

复制代码

提示：如果 apt.kubernetes.io 因为网络问题访问不到，可以换成中科大的 Ubuntu 镜像源 deb http://mirrors.ustc.edu.cn/kubernetes/apt kubernetes-xenial main。

复制代码

在上述安装 kubeadm 的过程中，kubeadm 和 kubelet、kubectl、kubernetes-cni 这几个二进制文件都会被自动安装好。

另外，这里我直接使用 Ubuntu 的 docker.io 的安装源，原因是 Docker 公司每次发布的最新的 Docker CE（社区版）产品往往还没有经过 Kubernetes 项目的验证，可能会有兼容性方面的问题。

二、部署 Kubernetes 的 Master 节点

在上一篇文章中，我已经介绍过 kubeadm 可以一键部署 Master 节点。不过，在本篇文章中既然要部署一个“完整”的 Kubernetes 集群，那我们不妨稍微提高一下难度：通过配置文件来开启一些实验性功能。

所以，这里我编写了一个给 kubeadm 用的 YAML 文件（名叫：kubeadm.yaml）：

apiVersion: kubeadm.k8s.io/v1alpha1kind: MasterConfigurationcontrollerManagerExtraArgs:  horizontal-pod-autoscaler-use-rest-clients: "true"  horizontal-pod-autoscaler-sync-period: "10s"  node-monitor-grace-period: "10s"apiServerExtraArgs:  runtime-config: "api/all=true"kubernetesVersion: "stable-1.11"

复制代码

这个配置中，我给 kube-controller-manager 设置了：

horizontal-pod-autoscaler-use-rest-clients: "true"

复制代码

这意味着，将来部署的 kube-controller-manager 能够使用自定义资源（Custom Metrics）进行自动水平扩展。这是我后面文章中会重点介绍的一个内容。

其中，“stable-1.11”就是 kubeadm 帮我们部署的 Kubernetes 版本号，即：Kubernetes release 1.11 最新的稳定版，在我的环境下，它是 v1.11.1。你也可以直接指定这个版本，比如：kubernetesVersion: “v1.11.1”。

然后，我们只需要执行一句指令：

$ kubeadm init --config kubeadm.yaml

复制代码

就可以完成 Kubernetes Master 的部署了，这个过程只需要几分钟。部署完成后，kubeadm 会生成一行指令：

kubeadm join 10.168.0.2:6443 --token 00bwbx.uvnaa2ewjflwu1ry --discovery-token-ca-cert-hash sha256:00eb62a2a6020f94132e3fe1ab721349bbcd3e9b94da9654cfe15f2985ebd711

复制代码

这个 kubeadm join 命令，就是用来给这个 Master 节点添加更多工作节点（Worker）的命令。我们在后面部署 Worker 节点的时候马上会用到它，所以找一个地方把这条命令记录下来。

此外，kubeadm 还会提示我们第一次使用 Kubernetes 集群所需要的配置命令：

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

复制代码

而需要这些配置命令的原因是：Kubernetes 集群默认需要加密方式访问。所以，这几条命令，就是将刚刚部署生成的 Kubernetes 集群的安全配置文件，保存到当前用户的.kube 目录下，kubectl 默认会使用这个目录下的授权信息访问 Kubernetes 集群。

如果不这么做的话，我们每次都需要通过 export KUBECONFIG 环境变量告诉 kubectl 这个安全配置文件的位置。

现在，我们就可以使用 kubectl get 命令来查看当前唯一一个节点的状态了：

$ kubectl get nodes
NAME      STATUS     ROLES     AGE       VERSIONmaster    NotReady   master    1d        v1.11.1

复制代码

可以看到，这个 get 指令输出的结果里，Master 节点的状态是 NotReady，这是为什么呢？

在调试 Kubernetes 集群时，最重要的手段就是用 kubectl describe 来查看这个节点（Node）对象的详细信息、状态和事件（Event），我们来试一下：

$ kubectl describe node master
...Conditions:...
Ready   False ... KubeletNotReady  runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

复制代码

通过 kubectl describe 指令的输出，我们可以看到 NodeNotReady 的原因在于，我们尚未部署任何网络插件。

另外，我们还可以通过 kubectl 检查这个节点上各个系统 Pod 的状态，其中，kube-system 是 Kubernetes 项目预留的系统 Pod 的工作空间（Namepsace，注意它并不是 Linux Namespace，它只是 Kubernetes 划分不同工作空间的单位）：

$ kubectl get pods -n kube-system
NAME               READY   STATUS   RESTARTS  AGEcoredns-78fcdf6894-j9s52     0/1    Pending  0     1hcoredns-78fcdf6894-jm4wf     0/1    Pending  0     1hetcd-master           1/1    Running  0     2skube-apiserver-master      1/1    Running  0     1skube-controller-manager-master  0/1    Pending  0     1skube-proxy-xbd47         1/1    NodeLost  0     1hkube-scheduler-master      1/1    Running  0     1s

复制代码

可以看到，CoreDNS、kube-controller-manager 等依赖于网络的 Pod 都处于 Pending 状态，即调度失败。这当然是符合预期的：因为这个 Master 节点的网络尚未就绪。

三、部署网络插件

在 Kubernetes 项目“一切皆容器”的设计理念指导下，部署网络插件非常简单，只需要执行一句 kubectl apply 指令，以 Weave 为例：

$ kubectl apply -f https://git.io/weave-kube-1.6

复制代码

部署完成后，我们可以通过 kubectl get 重新检查 Pod 的状态：

$ kubectl get pods -n kube-system
NAME                             READY     STATUS    RESTARTS   AGEcoredns-78fcdf6894-j9s52         1/1       Running   0          1dcoredns-78fcdf6894-jm4wf         1/1       Running   0          1detcd-master                      1/1       Running   0          9skube-apiserver-master            1/1       Running   0          9skube-controller-manager-master   1/1       Running   0          9skube-proxy-xbd47                 1/1       Running   0          1dkube-scheduler-master            1/1       Running   0          9sweave-net-cmk27                  2/2       Running   0          19s

复制代码

可以看到，所有的系统 Pod 都成功启动了，而刚刚部署的 Weave 网络插件则在 kube-system 下面新建了一个名叫 weave-net-cmk27 的 Pod，一般来说，这些 Pod 就是容器网络插件在每个节点上的控制组件。

Kubernetes 支持容器网络插件，使用的是一个名叫 CNI 的通用接口，它也是当前容器网络的事实标准，市面上的所有容器网络开源项目都可以通过 CNI 接入 Kubernetes，比如 Flannel、Calico、Canal、Romana 等等，它们的部署方式也都是类似的“一键部署”。关于这些开源项目的实现细节和差异，我会在后续的网络部分详细介绍。

至此，Kubernetes 的 Master 节点就部署完成了。如果你只需要一个单节点的 Kubernetes，现在你就可以使用了。不过，在默认情况下，Kubernetes 的 Master 节点是不能运行用户 Pod 的，所以还需要额外做一个小操作。在本篇的最后部分，我会介绍到它。

四、部署 Kubernetes 的 Worker 节点

Kubernetes 的 Worker 节点跟 Master 节点几乎是相同的，它们运行着的都是一个 kubelet 组件。唯一的区别在于，在 kubeadm init 的过程中，kubelet 启动后，Master 节点上还会自动运行 kube-apiserver、kube-scheduler、kube-controller-manger 这三个系统 Pod。

所以，相比之下，部署 Worker 节点反而是最简单的，只需要两步即可完成。

第一步，在所有 Worker 节点上执行“安装 kubeadm 和 Docker”一节的所有步骤。

第二步，执行部署 Master 节点时生成的 kubeadm join 指令：


$ kubeadm join 10.168.0.2:6443 --token 00bwbx.uvnaa2ewjflwu1ry --discovery-token-ca-cert-hash sha256:00eb62a2a6020f94132e3fe1ab721349bbcd3e9b94da9654cfe15f2985ebd711

复制代码

发布于: 刚刚阅读数: 4

Bert

关注

还未添加个人签名 2019-09-22 加入

还未添加个人简介

发布

暂无评论

创作场景

Code 片段

Bert

评论