共计 18951 个字符,预计需要花费 48 分钟才能阅读完成。
学习 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 相干文章,学习材料都会在外面更新,整顿的材料也会放在外面。
感觉写的还不错的就点个赞,加个关注呗!点关注,不迷路,继续更新!!!