kubeadm搭建kubernetes集群

一、环境准备
首先我的三个ubuntu云主机的配置如下

cpu数量 内存 磁盘 Ubuntu
2 8G 20G 18.04LTS

而且能保证三台机器都能连接外网
这里的所有命令都是在root用户下操作的
二、安装

1.在所有的节点上安装Docker和kubeadm

[email protected]:~# apt-get install curl -y 
[email protected]:~# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
[email protected]:~#  cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF
[email protected]:~# apt-get update
[email protected]:~# apt-get install -y docker.io kubeadm
上述安装过程中,kubeadm,kubectl,kubelet,kubernetes-cni这几个二进制文件都会被自动安装好。
直接使用+Ubuntu+的+docker.io+的安装源,原因是+Docker+公司每次发布的最新的+Docker+CE(社区版)产品往往还没有经过+Kubernetes+项目的验证,可能会有兼容性方面的问题。

2.部署kubernetes的Master节点

[email protected]:~# vim kubeadm.yaml
apiVersion: kubeadm v1.11
kind: MasterConfiguration
controllerManagerExtraArgs:
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"

[email protected]:~# kubeadm init --config kubeadm.yaml

如果有报错

your configuration file uses an old API spec: "kubeadm.k8s.io/v1alpha1". Please use kubeadm v1.11 instead and run 'kubeadm config migrate --old-config old.yaml --new-config new.yaml', which will write the new, similar spec using a newer API version.

把apiServer改成你对应的版本

再次运行kubeadm init --config kubeadm.yaml

这样就可以完成Master的部署了,稍等片刻,部署完成后,kubeadm会生成一条指令

kubeadm join 10.168.0.6:6443 --token k0jhnn.a7l33i18ehbl1aze \
--discovery-token-ca-cert-hash sha256:064420e731f201b1601bb0bb39ccfef0e581a83449a043b60036cfb4537e5c67

kubeadm join 命令是用来给Master节点添加更多的Work节点的,记住此命令,下面会用到。

此外,kubeadm会提示提示第一次使用集群所需要的配置命令。

[email protected]:~# mkdir -p $HOME/.kube
[email protected]:~# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[email protected]:~# chown $(id -u):$(id -g) $HOME/.kube/config

需要这些配置命令的原因是:Kubernetes 集群默认需要加密方式访问。所以,这几条命令,就是将刚刚部署生成的 Kubernetes 集群的安全配置文件,保存到当前用户的.kube 目录下,kubectl 默认会使用这个目录下的授权信息访问 Kubernetes 集群。如果不这么做的话,我们每次都需要通过 export KUBECONFIG 环境变量告诉 kubectl 这个安全配置文件的位置。
现在,我们就可以使用 kubectl get命令来查看当前唯一一个节点的状态了

[email protected]:~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
instance-ubuntu-1 NotReady master 3h52m v1.14.1

主节点的状态为什么会是NotReady,我们查看一下master节点的详细信息
[email protected]:~# kubectl describe node master

会显示
Ready False ... KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
这是因为我们还没有部署任何网络插件

3.部署网络插件

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

[email protected]:~# kubectl apply -f https://git.io/weave-kube-1.6

部署完成后检查一下

[email protected]:~# kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-fb8b8dccf-lc69z 1/1 Running 0 3h57m
coredns-fb8b8dccf-p2p4k 1/1 Running 0 3h57m
etcd-instance-ubuntu-1 1/1 Running 0 3h56m
kube-apiserver-instance-ubuntu-1 1/1 Running 0 3h56m
kube-controller-manager-instance-ubuntu-1 1/1 Running 0 3h56m
kube-proxy-pksmg 1/1 Running 0 3h47m
kube-proxy-qb2cl 1/1 Running 0 3h57m
kube-proxy-z6q42 1/1 Running 0 3h47m
kube-scheduler-instance-ubuntu-1 1/1 Running 0 3h56m
kubernetes-dashboard-5f7b999d65-rkkqq 1/1 Running 0 3h29m
weave-net-f5kgb 2/2 Running 1 3h47m
weave-net-fxxq2 2/2 Running 0 3h47m
weave-net-nplfj 2/2 Running 0 3h50m

可以看到所有pod都运行起来了 而刚刚部署的 Weave 网络插件则在 kube-system 下面新建了一个名叫 weave-net-cmk27 的 Pod,一般来说,这些 Pod 就是容器网络插件在每个节点上的控制组件。 Kubernetes 支持容器网络插件,使用的是一个名叫 CNI 的通用接口,它也是当前容器网络的事实标准,市面上的所有容器网络开源项目都可以通过 CNI 接入 Kubernetes,比如 Flannel、Calico、Canal、Romana 等等,它们的部署方式也都是类似的“一键部署”。关于这些开源项目的实现细节和差异,我会在后续的网络部分详细介绍。 至此,Kubernetes 的 Master 节点就部署完成了。如果你只需要一个单节点的 Kubernetes,现在你就可以使用了。不过,在默认情况下,Kubernetes 的 Master 节点是不能运行用户 Pod 的,所以还需要额外做一个小操作。

4.部署 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.6:6443 --token k0jhnn.a7l33i18ehbl1aze \
--discovery-token-ca-cert-hash sha256:064420e731f201b1601bb0bb39ccfef0e581a83449a043b60036cfb4537e5c67

通过 Taint/Toleration 调整 Master 执行 Pod 的策略 我在前面提到过,默认情况下 Master 节点是不允许运行用户 Pod 的。而 Kubernetes 做到这一点,依靠的是 Kubernetes 的 Taint/Toleration 机制。 它的原理非常简单:一旦某个节点被加上了一个 Taint,即被“打上了污点”,那么所有 Pod 就都不能在这个节点上运行,因为 Kubernetes 的 Pod 都有“洁癖”。 除非,有个别的 Pod 声明自己能“容忍”这个“污点”,即声明了 Toleration,它才可以在这个节点上运行。 其中,为节点打上“污点”(Taint)的命令是:

[email protected]:~# kubectl taint nodes instance-ubuntu-1 foo=bar:NoSchedule

这时,该 node1 节点上就会增加一个键值对格式的 Taint,即:foo=bar:NoSchedule
。其中值里面的 NoSchedule,意味着这个 Taint 只会在调度新 Pod 时产生作用,而不会影响已经在 node1 上运行的 Pod,哪怕它们没有 Toleration。

现在回到我们已经搭建的集群上来。这时,如果你通过 kubectl describe 检查一下 Master 节点的 Taint 字段,就会有所发现了:

[email protected]:~# kubectl describe node master

5.部署Dashboard可视化插件
在 Kubernetes 社区中,有一个很受欢迎的 Dashboard 项目,它可以给用户提供一个可视化的 Web 界面来查看当前集群的各种信息。毫不意外,它的部署也相当简单

kubectl create -f
https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

部署完成之后,我们就可以查看+Dashboard+对应的+Pod+的状态了

[email protected]:~# kubectl get pods -n kube-system

kubernetes-dashboard-6948bdb78-f67xk 1/1 Running 0 1m

需要注意的是,由于 Dashboard 是一个 Web Server,很多人经常会在自己的公有云上无意地暴露+Dashboard 的端口,从而造成安全隐患。所以,1.7 版本之后的 Dashboard 项目部署完成后,默认只能通过 Proxy 的方式在本地访问。具体的操作,你可以查看 Dashboard+项目的官方文档。 而如果你想从集群外访问这个 Dashboard 的话,就需要用到 Ingress

猜你喜欢

转载自blog.51cto.com/13670314/2395312
0条评论
添加一条新回复
  
今日推荐