乐趣区

关于docker:必收藏干货Kubernetes集群搭建超详细总结CentOS版

jiezi

学习 Kubernetes 的要害一步就是要学会搭建一套 k8s 集群。在明天的文章中作者将最近新总结的搭建技巧，无偿分享给大家！废话不多说，间接上干货！

01、零碎环境筹备

要装置部署 Kubernetes 集群，首先须要筹备机器，最间接的方法能够到私有云（如阿里云等）申请几台虚拟机。而如果条件容许，拿几台本地物理服务器来组建集群天然是最好不过了。然而这些机器须要满足以下几个条件：

  • 要求 64 位 Linux 操作系统，且内核版本要求 3.10 及以上，能满足装置 Docker 我的项目所需的要求；
  • 机器之间要放弃网络互通，这是将来容器之间网络互通的前提条件；
  • 要有外网拜访权限，因为部署的过程中须要拉取相应的镜像，要求可能拜访到 gcr.io、quay.io 这两个 docker registry, 因为有小局部镜像须要从这里拉取；
  • 单机可用资源倡议 2 核 CPU、8G 内存或以上，如果小一点也能够然而能调度的 Pod 数量就比拟无限了；
  • 磁盘空间要求在 30GB 以上，次要用于存储 Docker 镜像及相干日志文件；

在本次试验中咱们筹备了两台虚拟机，其具体配置如下：

  • 2 核 CPU、2GB 内存，30GB 的磁盘空间；
  • Unbantu 20.04 LTS 的 Sever 版本，其 Linux 内核为 5.4.0；
  • 内网互通，外网拜访权限不受管制；

02、Kubernetes 集群部署工具 Kubeadm 介绍

作为典型的分布式系统，Kubernetes 的部署始终是困扰初学者进入 Kubernetes 世界的一大阻碍。在公布晚期 Kubernetes 的部署次要依赖于社区保护的各种脚本，但这其中会波及二进制编译、配置文件以及 kube-apiserver 受权配置文件等诸多运维工作。目前各大云服务厂商罕用的 Kubernetes 部署形式是应用 SaltStack、Ansible 等运维工具自动化地执行这些繁琐的步骤，但即便这样，这个部署的过程对于初学者来说仍然是十分繁琐的。

正是基于这样的痛点，在志愿者的推动下 Kubernetes 社区终于发动了 kubeadm 这一独立的一键部署工具，应用 kubeadm 咱们能够通过几条简略的指令来疾速地部署一个 kubernetes 集群。在接下来的内容中，就将具体演示如何应用 kubeadm 来部署一个简略构造的 Kubernetes 集群。

03、装置 kubeadm 及 Docker 环境

正是基于这样的痛点，在志愿者的推动下 Kubernetes 社区终于发动了 kubeadm 这一独立的一键部署工具，应用 kubeadm 咱们能够通过几条简略的指令来疾速地部署一个 kubernetes 集群。在接下来的内容中，就将具体演示如何应用 kubeadm 来部署一个简略构造的 Kubernetes 集群。

后面简略介绍了 Kubernetes 官网公布一键部署工具 kubeadm，只须要增加 kubeadm 的源，而后间接用 yum 装置即可，具体操作如下：

1)、编辑操作系统装置源配置文件，增加 kubernetes 镜像源，命令如下：

# 增加 Docker 阿里镜像源

[root@centos-linux ~]# wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo

#装置 Docker

[root@centos-linux ~]# yum -y install docker-ce-18.09.9-3.el7

#启动 Docker 并设置开机启动

[root@centos-linux ~]# systemctl enable docker

增加 Kubernetes yum 镜像源，因为网络起因，也能够换成国内 Ubantu 镜像源，如阿里云镜像源地址：增加阿里云 Kubernetes yum 镜像源

# cat > /etc/yum.repos.d/kubernetes.repo << EOF

[kubernetes]

name=Kubernetes

baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64

enabled=1

gpgcheck=0

repo_gpgcheck=0

gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg

EOF

  2)、实现上述步骤后就能够通过 yum 命令装置 kubeadm 了，如下：

[root@centos-linux ~]# yum install -y kubelet-1.20.0 kubeadm-1.20.0 kubectl-1.20.0

以后版本是最新版本 1.21，这里装置 1.20。#查看装置的 kubelet 版本信息

[root@centos-linux ~]# kubectl version

Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0", GitCommit:"af46c47ce925f4c4ad5cc8d1fca46c7b77d13b38", GitTreeState:"clean", BuildDate:"2020-12-08T17:59:43Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

The connection to the server localhost:8080 was refused - did you specify the right host or port?

在上述装置 kubeadm 的过程中，kubeadm 和 kubelet、kubectl、kubernetes-cni 这几个 kubernetes 外围组件的二进制文件也都会被主动装置好。

3)、Docker 服务启动及限度批改

在具体运行 kubernetes 部署之前须要对 Docker 的配置信息进行一些调整。首先，编辑零碎 /etc/default/grub 文件，在配置项 GRUB_CMDLINE_LINUX 中增加如下参数：

GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

实现编辑后保留执行如下命令，并重启服务器，命令如下：

root@kubernetesnode01:/opt/kubernetes-config# reboot

上述批改次要解决的是可能呈现的“docker 正告 WARNING: No swap limit support”问题。其次，编辑创立 /etc/docker/daemon.json 文件，增加如下内容：

# cat > /etc/docker/daemon.json <<EOF

{"registry-mirrors": ["https://6ze43vnb.mirror.aliyuncs.com"],

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

 "log-driver": "json-file",

 "log-opts": {"max-size": "100m"},

 "storage-driver": "overlay2"

}

EOF

实现保留后执行重启 Docker 命令，如下：# systemctl restart docker

此时能够查看 Docker 的 Cgroup 信息，如下：# docker info | grep Cgroup

Cgroup Driver: systemd

上述批改次要解决的是“Docker cgroup driver. The recommended driver is “systemd””的问题。须要强调的是以上批改只是作者在具体安装操作是遇到的具体问题的解决整顿，如在实际过程中遇到其余问题还须要自行查阅相干材料！最初，须要留神因为 kubernetes 禁用虚拟内存，所以要先敞开掉 swap 否则就会在 kubeadm 初始化 kubernetes 的时候报错，具体如下：

# swapoff -a

该命令只是长期禁用 swap，如要保证系统重启后依然失效则须要“vim /etc/fstab”文件，并正文掉 swap 那一行。

04、部署 Kubernetes 的 Master 节点

在 Kubernetes 中 Master 节点是集群的管制节点，它是由三个严密合作的独立组件组合而成，别离是 负责 API 服务的 kube-apiserver、负责调度的 kube-scheduler以及 负责容器编排的 kube-controller-manager，其中整个集群的长久化数据由 kube-apiserver 解决后保留在 Etcd 中。要部署 Master 节点能够间接通过 kubeadm 进行一键部署，但这里咱们心愿可能部署一个绝对残缺的 Kubernetes 集群，能够通过配置文件来开启一些实验性的性能。具体在零碎中新建 /opt/kubernetes-config/ 目录，并创立一个给 kubeadm 用的 YAML 文件（kubeadm.yaml），具体内容如下：

apiVersion: kubeadm.k8s.io/v1beta2

kind: ClusterConfiguration

controllerManager:

extraArgs:

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

    horizontal-pod-autoscaler-sync-period: "10s"

    node-monitor-grace-period: "10s"

apiServer:

 extraArgs:

    runtime-config: "api/all=true"

kubernetesVersion: "v1.20.0"

在上述 yaml 配置文件中“horizontal-pod-autoscaler-use-rest-clients: “true””这个配置，示意未来部署的 kuber-controller-manager 可能应用自定义资源（Custom Metrics）进行主动程度扩大，感兴趣的读者能够自行查阅相干材料！而“v1.20.0”就是要 kubeadm 帮咱们部署的 Kubernetes 版本号。

须要留神的是，如果执行过程中因为国内网络限度问题导致无奈下载相应的 Docker 镜像，能够依据报错信息在国内网站（如阿里云）上找到相干镜像，而后再将这些镜像从新 tag 之后再进行装置。具体如下：

# 从阿里云 Docker 仓库拉取 Kubernetes 组件镜像

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver-amd64:v1.20.0

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager-amd64:v1.20.0

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler-amd64:v1.20.0

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.20.0

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.4.13-0

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.7.0

下载实现后再将这些 Docker 镜像从新 tag 下，具体命令如下：

# 从新 tag 镜像

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler-amd64:v1.20.0 k8s.gcr.io/kube-scheduler:v1.20.0

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager-amd64:v1.20.0 k8s.gcr.io/kube-controller-manager:v1.20.0

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver-amd64:v1.20.0 k8s.gcr.io/kube-apiserver:v1.20.0

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.20.0 k8s.gcr.io/kube-proxy:v1.20.0

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2 k8s.gcr.io/pause:3.2

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.4.13-0 k8s.gcr.io/etcd:3.4.13-0

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.7.0 k8s.gcr.io/coredns:1.7.0

此时通过 Docker 命令就能够查看到这些 Docker 镜像信息了，命令如下：root@kubernetesnode01:/opt/kubernetes-config# docker images

REPOSITORY                                                                          TAG                 IMAGE ID            CREATED             SIZE

k8s.gcr.io/kube-proxy                                                               v1.18.1             4e68534e24f6        2 months ago        117MB

registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64                v1.18.1             4e68534e24f6        2 months ago        117MB

k8s.gcr.io/kube-controller-manager                                                  v1.18.1             d1ccdd18e6ed        2 months ago        162MB

registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager-amd64   v1.18.1             d1ccdd18e6ed        2 months ago        162MB

k8s.gcr.io/kube-apiserver                                                           v1.18.1             a595af0107f9        2 months ago        173MB

registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver-amd64            v1.18.1             a595af0107f9        2 months ago        173MB

k8s.gcr.io/kube-scheduler                                                           v1.18.1             6c9320041a7b        2 months ago        95.3MB

registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler-amd64            v1.18.1             6c9320041a7b        2 months ago        95.3MB

k8s.gcr.io/pause                                                                    3.2                 80d28bedfe5d        4 months ago        683kB

registry.cn-hangzhou.aliyuncs.com/google_containers/pause                           3.2                 80d28bedfe5d        4 months ago        683kB

k8s.gcr.io/coredns                                                                  1.6.7               67da37a9a360        4 months ago        43.8MB

registry.cn-hangzhou.aliyuncs.com/google_containers/coredns                         1.6.7               67da37a9a360        4 months ago        43.8MB

k8s.gcr.io/etcd                                                                     3.4.3-0             303ce5db0e90        8 months ago        288MB

registry.cn-hangzhou.aliyuncs.com/google_containers/etcd-amd64                      3.4.3-0             303ce5db0e90        8 months ago        288MB

解决镜像拉取问题后再次执行 kubeadm 部署命令就能够实现 Kubernetes Master 管制节点的部署了，具体命令及执行后果如下：

root@kubernetesnode01:/opt/kubernetes-config# kubeadm init --config kubeadm.yaml --v=5

...

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

 mkdir -p $HOME/.kube

 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

 sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

 export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.

Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:

 https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 10.211.55.13:6443 --token yi9lua.icl2umh9yifn6z9k \

   --discovery-token-ca-cert-hash sha256:074460292aa167de2ae9785f912001776b936cec79af68cec597bd4a06d5998d

从下面部署执行后果中能够看到，部署胜利后 kubeadm 会生成如下指令：

kubeadm join 10.211.55.13:6443 --token yi9lua.icl2umh9yifn6z9k \

   --discovery-token-ca-cert-hash sha256:074460292aa167de2ae9785f912001776b936cec79af68cec597bd4a06d5998d

这个 kubeadm join 命令就是用来给该 Master 节点增加更多 Worker(工作节点)的命令，前面具体部署 Worker 节点的时候将会应用到它。此外，kubeadm 还会提醒咱们第一次应用 Kubernetes 集群所须要配置的命令：

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

而须要这些配置命令的起因在于 Kubernetes 集群默认是须要加密形式拜访的，所以这几条命令就是将方才部署生成的 Kubernetes 集群的平安配置文件保留到以后用户的.kube 目录, 之后 kubectl 会默认应用该目录下的受权信息拜访 Kubernetes 集群。如果不这么做的化，那么每次通过集群就都须要设置“export KUBECONFIG 环境变量”来通知 kubectl 这个平安文件的地位。

执行完上述命令后，当初咱们就能够应用 kubectl get 命令来查看以后 Kubernetes 集群节点的状态了，执行成果如下：

#  kubectl get nodes

NAME                  STATUS     ROLES                  AGE     VERSION

centos-linux.shared   NotReady   control-plane,master   6m55s   v1.20.0

在以上命令输入的后果中能够看到 Master 节点的状态为“NotReady”，为了查找具体起因能够通过“kuberctl describe”命令来查看下该节点（Node）对象的详细信息，命令如下：

# kubectl describe node centos-linux.shared

该命令能够十分具体地获取节点对象的状态、事件等详情，这种形式也是调试 Kubernetes 集群时最重要的排查伎俩。依据显示的如下信息：

...

Conditions

...

Ready False... KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

...

能够看到节点处于“NodeNotReady”的起因在于尚未部署任何网络插件，为了进一步验证这一点还能够通过 kubectl 查看这个节点上各个 Kubernetes 零碎 Pod 的状态，命令及执行成果如下：

# kubectl get pods -n kube-system

NAME                                       READY   STATUS    RESTARTS   AGE

coredns-66bff467f8-l4wt6                   0/1     Pending   0          64m

coredns-66bff467f8-rcqx6                   0/1     Pending   0          64m

etcd-kubernetesnode01                      1/1     Running   0          64m

kube-apiserver-kubernetesnode01            1/1     Running   0          64m

kube-controller-manager-kubernetesnode01   1/1     Running   0          64m

kube-proxy-wjct7                           1/1     Running   0          64m

kube-scheduler-kubernetesnode01            1/1     Running   0          64m

命令中“kube-system”示意的是 Kubernetes 我的项目预留的零碎 Pod 空间（Namespace），须要留神它并不是 Linux Namespace，而是 Kuebernetes 划分的不同工作空间单位。回到命令输入后果，能够看到 coredns 等依赖于网络的 Pod 都处于 Pending（调度失败）的状态，这样阐明了该 Master 节点的网络尚未部署就绪。

05、部署 Kubernetes 网络插件

后面部署 Master 节点中因为没有部署网络插件，所以节点状态显示“NodeNotReady”状态。接下来的内容咱们就来具体部署下网络插件。在 Kubernetes“所有皆容器”的设计理念领导下，网络插件也会以独立 Pod 的形式运行在零碎中，所以部署起来也很简略只须要执行“kubectl apply”指令即可，例如以 Weave 网络插件为例：

# kubectl apply -f https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')

serviceaccount/weave-net created

clusterrole.rbac.authorization.k8s.io/weave-net created

clusterrolebinding.rbac.authorization.k8s.io/weave-net created

role.rbac.authorization.k8s.io/weave-net created

rolebinding.rbac.authorization.k8s.io/weave-net created

daemonset.apps/weave-net created

部署实现后通过“kubectl get”命令从新查看 Pod 的状态：

# kubectl get pods -n kube-system

NAME                                       READY   STATUS    RESTARTS   AGE

coredns-66bff467f8-l4wt6                   1/1     Running   0          116m

coredns-66bff467f8-rcqx6                   1/1     Running   0          116m

etcd-kubernetesnode01                      1/1     Running   0          116m

kube-apiserver-kubernetesnode01            1/1     Running   0          116m

kube-controller-manager-kubernetesnode01   1/1     Running   0          116m

kube-proxy-wjct7                           1/1     Running   0          116m

kube-scheduler-kubernetesnode01            1/1     Running   0          116m

weave-net-746qj                            2/2     Running   0          14m

能够看到，此时所有的零碎 Pod 都胜利启动了，而方才部署的 Weave 网络插件则在 kube-system 上面新建了一个名叫“weave-net-746qj”的 Pod，而这个 Pod 就是容器网络插件在每个节点上的管制组件。

到这里，Kubernetes 的 Master 节点就部署实现了，如果你只须要一个单节点的 Kubernetes，那么当初就能够应用了。然而在默认状况下，Kubernetes 的 Master 节点是不能运行用户 Pod 的，须要通过额定的操作进行调整，在本文的最初将会介绍到它。

06、部署 Worker 节点

为了构建一个残缺的 Kubernetes 集群，这里还须要持续介绍如何部署 Worker 节点。实际上 Kubernetes 的 Worker 节点和 Master 节点简直是雷同的，它们都运行着一个 kubelet 组件，次要的区别在于“kubeadm init”的过程中，kubelet 启动后，Master 节点还会主动启动 kube-apiserver、kube-scheduler 及 kube-controller-manager 这三个零碎 Pod。

在具体部署之前与 Master 节点一样，也须要在所有 Worker 节点上执行后面“装置 kubeadm 及 Decker 环境”大节中的所有步骤。之后在 Worker 节点执行部署 Master 节点时生成的“kubeadm join”指令即可，具体如下：

root@kubenetesnode02:~# kubeadm join 10.211.55.6:6443 --token jfulwi.so2rj5lukgsej2o6     --discovery-token-ca-cert-hash sha256:d895d512f0df6cb7f010204193a9b240e8a394606090608daee11b988fc7fea6 --v=5


...

This node has joined the cluster:

* Certificate signing request was sent to apiserver and a response was received.

* The Kubelet was informed of the new secure connection details.


Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

实现集群退出后为了便于在 Worker 节点执行 kubectl 相干命令，须要进行如下配置：

# 创立配置目录

root@kubenetesnode02:~# mkdir -p $HOME/.kube

#将 Master 节点中 $/HOME/.kube/ 目录中的 config 文件拷贝至 Worker 节点对应目录

root@kubenetesnode02:~# scp root@10.211.55.6:$HOME/.kube/config $HOME/.kube/

#权限配置

root@kubenetesnode02:~# sudo chown $(id -u):$(id -g) $HOME/.kube/config

之后能够在 Worker 或 Master 节点执行节点状态查看命令“kubectl get nodes”，具体如下：

root@kubernetesnode02:~# kubectl get nodes

NAME               STATUS     ROLES    AGE   VERSION

kubenetesnode02    NotReady   <none>   33m   v1.18.4

kubernetesnode01   Ready      master   29h   v1.18.4

通过节点状态显示此时 Work 节点还处于 NotReady 状态，具体查看节点形容信息如下：

root@kubernetesnode02:~# kubectl describe node kubenetesnode02

...

Conditions:

...

Ready False ... KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

...

依据形容信息，发现 Worker 节点 NotReady 的起因也在于网络插件没有部署，继续执行“部署 Kubernetes 网络插件”大节中的步骤即可。然而要留神部署网络插件时会同时部署 kube-proxy，其中会波及从 k8s.gcr.io 仓库获取镜像的动作，如果无法访问外网可能会导致网络部署异样，这里能够参考后面装置 Master 节点时的做法，通过国内镜像仓库下载后通过 tag 的形式进行标记，具体如下：

# 从阿里云拉取必要镜像

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.20.0

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2

#将镜像从新打 tag

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.20.0 k8s.gcr.io/kube-proxy:v1.20.0

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2 k8s.gcr.io/pause:3.2

如若一切正常，则持续查看节点状态，命令如下：root@kubenetesnode02:~# kubectl get node

NAME               STATUS   ROLES    AGE     VERSION

kubenetesnode02    Ready    <none>   7h52m   v1.20.0

kubernetesnode01   Ready    master   37h     v1.20.0

能够看到此时 Worker 节点的状态曾经变成“Ready”，不过仔细的读者可能会发现 Worker 节点的 ROLES 并不像 Master 节点那样显示“master”而是显示了 <none>，这是因为新装置的 Kubernetes 环境 Node 节点有时候会失落 ROLES 信息，遇到这种状况能够手工进行增加，具体命令如下：

root@kubenetesnode02:~# kubectl label node kubenetesnode02 node-role.kubernetes.io/worker=worker

再次运行节点状态命令就能看到失常的显示了，命令成果如下：

root@kubenetesnode02:~# kubectl get node

NAME               STATUS   ROLES    AGE   VERSION

kubenetesnode02    Ready    worker   8h    v1.18.4

kubernetesnode01   Ready    master   37h   v1.18.4

到这里就部署实现了具备一个 Master 节点和一个 Worker 节点的 Kubernetes 集群了，作为试验环境它曾经具备了根本的 Kubernetes 集群性能！

07、部署 Dashboard 可视化插件

在 Kubernetes 社区中，有一个很受欢迎的 Dashboard 我的项目，它能够给用户一个可视化的 Web 界面来查看以后集群中的各种信息。该插件也是以容器化形式进行部署，操作也非常简单，具体可在 Master、Worker 节点或其余可能平安拜访 Kubernetes 集群的 Node 上进行部署，命令如下：

root@kubenetesnode02:~# kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.3/aio/deploy/recommended.yaml

部署实现后就能够查看 Dashboard 对应的 Pod 运行状态，执行成果如下：

root@kubenetesnode02:~# kubectl get pods -n kubernetes-dashboard

NAME                                         READY   STATUS    RESTARTS   AGE

dashboard-metrics-scraper-6b4884c9d5-xfb8b   1/1     Running   0          12h

kubernetes-dashboard-7f99b75bf4-9lxk8        1/1     Running   0          12h

除此之外还能够查看 Dashboard 的服务（Service）信息，命令如下：

root@kubenetesnode02:~# kubectl get svc -n kubernetes-dashboard

NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE

dashboard-metrics-scraper   ClusterIP   10.97.69.158    <none>        8000/TCP   13h

kubernetes-dashboard        ClusterIP   10.111.30.214   <none>        443/TCP    13h

须要留神的是，因为 Dashboard 是一个 Web 服务，从平安角度登程 Dashboard 默认只能通过 Proxy 的形式在本地拜访。具体形式为在本地机器装置 kubectl 管理工具，并将 Master 节点 $HOME/.kube/ 目录中的 config 文件拷贝至本地主机雷同目录，之后运行“kubectl proxy”命令，如下:

qiaodeMacBook-Pro-2:.kube qiaojiang$ kubectl proxy

Starting to serve on 127.0.0.1:8001

本地 proxy 代理启动后，拜访 Kubernetes Dashboard 地址，具体如下：

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

如果拜访失常，就会看到如下图所示界面：

如上图所示 Dashboard 拜访须要进行身份认证，次要有 Token 及 Kubeconfig 两种形式，这里咱们抉择 Token 的形式，而 Token 的生成步骤如下：

1)、创立一个服务账号

首先在命名空间 kubernetes-dashboard 中创立名为 admin-user 的服务账户，具体步骤为在本地目录创立相似“dashboard-adminuser.yaml”文件，具体内容如下：

apiVersion: v1

kind: ServiceAccount

metadata:

 name: admin-user

 namespace: kubernetes-dashboard

编写文件后具体执行创立命令：

qiaodeMacBook-Pro-2:.kube qiaojiang$ kubectl apply -f dashboard-adminuser.yaml

Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply

serviceaccount/admin-user configured

2)、创立 ClusterRoleBinding

在应用 kubeadm 工具配置完 Kubernetes 集群后，集群中曾经存在 ClusterRole 集群治理，能够应用它为上一步创立的 ServiceAccount 创立 ClusterRoleBinding。具体步骤为在本地目录创立相似“dashboard-clusterRoleBingding.yaml”的文件，具体内容如下：

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

 name: admin-user

roleRef:

 apiGroup: rbac.authorization.k8s.io

 kind: ClusterRole

 name: cluster-admin

subjects:

- kind: ServiceAccount

 name: admin-user

 namespace: kubernetes-dashboard

执行创立命令：

qiaodeMacBook-Pro-2:.kube qiaojiang$ kubectl apply -f dashboard-clusterRoleBingding.yaml

clusterrolebinding.rbac.authorization.k8s.io/admin-user created

3)、获取 Bearer Token

接下来执行获取 Bearer Token 的命令，具体如下：

qiaodeMacBook-Pro-2:.kube qiaojiang$ kubectl -n kubernetes-dashboard describe secret $(kubectl -n kubernetes-dashboard get secret | grep admin-user | awk '{print $1}')

Name:         admin-user-token-xxq2b

Namespace:    kubernetes-dashboard

Labels:       <none>

Annotations:  kubernetes.io/service-account.name: admin-user

             kubernetes.io/service-account.uid: 213dce75-4063-4555-842a-904cf4e88ed1


Type:  kubernetes.io/service-account-token


Data

====

ca.crt:     1025 bytes

namespace:  20 bytes

token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IlplSHRwcXhNREs0SUJPcTZIYU1kT0pidlFuOFJaVXYzLWx0c1BOZzZZY28ifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJhZG1pbi11c2VyLXRva2VuLXh4cTJiIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImFkbWluLXVzZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiIyMTNkY2U3NS00MDYzLTQ1NTUtODQyYS05MDRjZjRlODhlZDEiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZXJuZXRlcy1kYXNoYm9hcmQ6YWRtaW4tdXNlciJ9.MIjSewAk4aVgVCU6fnBBLtIH7PJzcDUozaUoVGJPUu-TZSbRZHotugvrvd8Ek_f5urfyYhj14y1BSe1EXw3nINmo4J7bMI94T_f4HvSFW1RUznfWZ_uq24qKjNgqy4HrSfmickav2PmGv4TtumjhbziMreQ3jfmaPZvPqOa6Xmv1uhytLw3G6m5tRS97kl0i8A1lqnOWu7COJX0TtPkDrXiPPX9IzaGrp3Hd0pKHWrI_-orxsI5mmFj0cQZt1ncHarCssVnyHkWQqtle4ljV2HAO-bgY1j0E1pOPTlzpmSSbmAmedXZym77N10YNaIqtWvFjxMzhFqeTPNo539V1Gg

获取 Token 后回到后面的认证形式抉择界面，将获取的 Token 信息填入就能够正式进入 Dashboard 的零碎界面，看到 Kubernetes 集群的具体可视化信息了，如图所示：

到这里就实现了 Kubernetes 可视化插件的部署并通过本地 Proxy 的形式进行了登录。在理论的生产环境中如果感觉每次通过本地 Proxy 的形式进行拜访不够不便，也能够应用 Ingress 形式配置集群外拜访 Dashboard，感兴趣的读者能够自行尝试下。也能够先通过通过裸露端口，设置 dashboard 的拜访，例如：

# 查看 svc 名称

# kubectl get sc -n kubernetes-dashboard


# kubectl edit services -n kubernetes-dashboard kubernetes-dashboard

而后批改配置文件，如下：

ports:

 - nodePort: 30000

   port: 443

   protocol: TCP

   targetPort: 8443

 selector:

   k8s-app: kubernetes-dashboard

 sessionAffinity: None

 type: NodePort

之后就能够通过 IP+nodePort 端口拜访了！例如：

https://47.98.33.48:30000/

08、Master调整 Taint/Toleration 策略 **

在后面咱们提到过，Kubernetes 集群的 Master 节点默认状况下是不能运行用户 Pod 的。而之所以可能达到这样的成果，Kubernetes 依附的正是Taint/Toleration 机制；而该机制的原理是一旦某个节点被加上“Taint”就示意该节点被“打上了污点”，那么所有的 Pod 就不能再在这个节点上运行。

而 Master 节点之所以不能运行用户 Pod，就在于其运行胜利后会为本身节点打上“Taint”从而达到禁止其余用户 Pod 运行在 Master 节点上的成果（不影响曾经运行的 Pod），具体能够通过命令查看 Master 节点上的相干信息，命令执行成果如下：

root@kubenetesnode02:~# kubectl describe node kubernetesnode01

Name:               kubernetesnode01

Roles:              master

...

Taints:             node-role.kubernetes.io/master:NoSchedule

...

能够看到 Master 节点默认被加上了“node-role.kubernetes.io/master:NoSchedule”这样的“污点”，其中的值“NoSchedule”意味着这个 Taint 只会在调度新的 Pod 时产生作用，而不会影响在该节点上曾经运行的 Pod。如果在试验中只想要一个单节点的 Kubernetes，那么能够在删除 Master 节点上的这个 Taint，具体命令如下：

root@kubernetesnode01:~# kubectl taint nodes --all node-role.kubernetes.io/master-

上述命令通过在“nodes –all node-role.kubernetes.io/master”这个键前面加一个短横线“-”示意移除所有以该键为键的 Taint。

到这一步，一个根本的 Kubernetes 集群就部署实现了, 通过 kubeadm 这样的原生管理工具，Kubernetes 的部署被大大简化了，其中像证书、受权及各个组件配置等最麻烦的操作，kubeadm 都帮咱们实现了。

09、Kubernetes 集群重启命令

如果服务器断电，或者重启，可通过如下命令重启集群：

# 重启 docker

systemctl daemon-reload

systemctl restart docker


#重启 kubelet

systemctl restart kubelet.service

以上就是在 CentOS 7 零碎环境下搭建一组 Kubernetes 学习集群的具体步骤，其它 Linux 发行版本的部署办法也相似，大家能够依据本人的需要抉择！

写在最初

欢送大家关注我的公众号【惊涛骇浪如码】，海量 Java 相干文章，学习材料都会在外面更新，整顿的材料也会放在外面。

感觉写的还不错的就点个赞，加个关注呗！点关注，不迷路，继续更新！！！

退出移动版