关于kubernetes:Kubeadm快速部署Kubernetes集群

4次阅读

共计 5597 个字符,预计需要花费 14 分钟才能阅读完成。

通过后面的架构概述,能够看出,若想手动部署一套高可用的 Kubernetes 集群,还是相当麻烦的。所以官网推出了疾速建设 Kubernetes 集群的工具:Kubeadm。

Kubeadm 是一个提供 Kubeadm init 和 Kubeadm join 命令,用于创立 Kubernetes 集群的最佳实际“疾速门路”工具。

Kubeadm 的指标是在不装置其余性能插件的根底上,建设一个通过 Kubernetes 一致性测试 Kubernetes Conformance tests 的最小可行集群。它在设计上并不会装置网络解决方案,而是须要用户自行装置第三方合乎 CNI 的网络解决方案(如:flannel,calico,weave network 等)。

筹备工作

机器

这个太难了,好不容易从生产环境坑蒙拐骗挪进去 3 台能用的,总算能弄个一主两从的集群,零碎都是 CentOS:

机器角色 IP
master 10.128.2.53
node 10.128.1.187
node 10.11.7.94

配置 host

三台机器均配置 host,/etc/hosts文件增加以下配置:

10.128.2.53 kubernetes-master01
10.128.1.187 kubernetes-node01
10.11.7.94 kubernetes-node02
hostnamectl
hostnamectl set-hostname kubernetes-master01

敞开防火墙

systemctl stop firewalld
systemctl disable firewalld
systemctl status firewalld

敞开 selinux

sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config  # 永恒 需重启
setenforce 0   # 长期

敞开 swap

swapoff -a
sed -i 's/^[^#].*swap/#&/' /etc/fstab
systemctl daemon-reload

若要启用 swap 设施,则须要在集群初始化时增加 –ignore-preflight-errors=swap, 意义为疏忽因 swap 设施导致的报错

敞开 ipv6

echo net.ipv6.conf.all.disable_ipv6=1 >> /etc/sysctl.conf
echo NETWORKING_IPV6=no >> /etc/sysconfig/network
sed -i 's/IPV6INIT=yes/IPV6INIT=no/g' /etc/sysconfig/network-scripts/ifcfg-ens33
sysctl -p
ip a             # 查看 ipv6 是否敞开

将桥接的 IPv4 流量传递到 iptables

cat >/etc/sysctl.d/kubernetes.conf << EOF
net.bridge.bridge-nf-call-ip6tables =1
net.bridge.bridge-nf-call-iptables =1
EOF

sysctl --system  # 失效

这个不晓得什么意思然而通过 Kubeadm 装置 Kubenetes 集群时会校验。这里也搜到一篇文章阐明 net.bridge.bridge-nf-call-iptables 的作用 参数作用,然而我示意看不懂。

装置容器运行时

三台机器必须都装置容器运行时,这里我应用 Dokcer,并且须要配置 Docker 的 Cgroup Driver 为systemd

vi /etc/docker/daemon.json

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

systemctl restart docker
  • 什么是 cgroups?

    首先说下容器是什么?容器是一个视图隔离、资源可限度、独立文件系统的过程汇合。cgroups(Control Groups) 是 linux 内核提供的一种机制,作用就是能够对资源进行限度。此外,视图隔离是通过 namespace 实现,而文件系统是通过 chroot 实现。

  • 为什么要批改 Cgroup Driver

    Docker 默认的 Cgroup Driver 是 cgroupfs,而 Kubernetes 举荐应用 systemd 来代替 cgroupfs。如果不批改,那么同时运行有两个 cgroup 管制管理器,当资源有压力的状况时,有可能呈现不稳固的状况。并且在 kubeadm init 时也会呈现正告。

master 机器设置免登录 node

ssh-keygen -t rsa # 一路默认回车即可
ssh-copy-id kubernetes-master01   # 过程中须要输出明码
ssh-copy-id kubernetes-node01
ssh-copy-id kubernetes-node02

ssh root@kubernetes-node01   # 测试是否胜利,切记测试完 exit,不然就像我一样捣鼓一下午不胜利才发现问题。。

集群部署

装置 kubeadm、kubelet、kubectl

以下操作在所有节点进行

  • 增加阿里云 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
  • 指定版本装置软件,这里我装置的是 1.19.8 版本,1.20 不再把 Docker 作为默认的容器运行时了,所以临时抉择 1.19 版本。
yum install -y kubelet-1.19.8 kubeadm-1.19.8 kubectl-1.19.8
systemctl enable kubelet

Master 节点装置

kubeadm init --kubernetes-version=1.19.8 --image-repository=registry.aliyuncs.com/google_containers 

依照提醒执行下列命令:

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

此处要记住打印出的下列命令,在增加 Node 节点时须要用到:

kubeadm join 10.128.2.53:6443 --token dvt5z4.sdf2rfwprp7byv62 \
    --discovery-token-ca-cert-hash sha256:c2262789b43f4fae6a6ed42740abcf077e9f8da379713a0dee6c8d3a2de98fdb 

若没留神,可通过 kubeadm token list 查看以后的 token,默认有效期为 24 小时,若遗记 token 或 token 过期,可应用命令 kubeadm token create --print-join-command 从新生成,若初始有问题可通过命令 kubeadm reset 重置。

启动 kubelet 并查看状态:

systemctl start kubelet
systemctl status kubelet

查看此时节点信息:

kubectl get nodes

能够看到 master 节点是 NotReady 状态。

部署 CNI 网络

在应用 Docker 时咱们就发现,除非网络模式设为 host,否则会产生很多网络上的问题,过后也调研了一些容器跨主机网络通信的解决方案,最终还是抉择了--net=host 共享宿主机网络。

在 Kubernetes 集群中或者说云原生中,网络同样存在容器跨主机网络通信的问题,始终以来,Kubernetes 并没有专门的网络模块负责网络配置,它须要用户在主机上曾经配置好网络。kubernetes 对网络的要求是:

  • 容器之间(包含同一台主机上的容器,和不同主机的容器)能够相互通信
  • 容器和集群中所有的节点也能间接通信

Kubernetes 网络的倒退方向是心愿通过插件的形式来集成不同的网络计划,于是便呈现了 CNI 的概念:

CNI(Container Network Interface)是 CNCF 旗下的一个我的项目,由一组用于配置 Linux 容器的网络接口的标准和库组成,同时还蕴含了一些插件。CNI 仅关怀容器创立时的网络调配,和当容器被删除时开释网络资源。

CNI 自身是一种规范的设计和概念,它只专一解决容器网络连接和容器销毁时的资源开释,提供一套框架,所以 CNI 能够反对大量不同的网络模式。更深刻的在后续深入研究局部再具体学习。

网络插件抉择,calico vs fannel

fannel 和 calico 算是目前网络实现最热门的 2 个插件,通过简略的比照,calico 在性能更好以外,还能够与服务网格 Istio 集成,所以毫不犹豫的抉择 calico。

装置 calico

curl https://docs.projectcalico.org/manifests/calico.yaml -o calico.yaml
kubectl apply -f calico.yaml 

这时 kubectl get nodes 命令查看节点状态变为Ready

查看组件状态

下列文字于 2021 年 3 月 16 日批改废除

# 都可
kubectl get cs
kubectl get componentstatus

能够看到 scheduler 与 controller-manager 是 Unhealthy 的,按端口提醒查看 10251 及 10252 是否有监听

ss -ant|grep 10251
ss -ant|grep 10252

发现均未有监听,查看配置文件 /etc/kubernetes/manifests/kube-scheduler.yaml/etc/kubernetes/manifests/kube-controller-manager.yaml并将两个配置文件的配置项 - --port=0 均正文掉,并重启 kubelet,从新查看组件状态

2021 年 3 月 16 日批改如下:

Kubectl get cs 命令因为平安起因在 1.19+ 版本已废除,查看组件状态应用以下命令

kubectl get po -n kube-system

Node 节点装置

systemctl start kubelet

kubeadm join 10.128.2.53:6443 --token dvt5z4.sdf2rfwprp7byv62 \
    --discovery-token-ca-cert-hash sha256:c2262789b43f4fae6a6ed42740abcf077e9f8da379713a0dee6c8d3a2de98fdb 

查看节点:

集群查看

  • 查看节点

    [root@promote ~]# kubectl get cs
    Warning: v1 ComponentStatus is deprecated in v1.19+
    NAME                 STATUS    MESSAGE             ERROR
    scheduler            Healthy   ok                  
    controller-manager   Healthy   ok                  
    etcd-0               Healthy   {"health":"true"}   
  • 查看根底利用

    [root@promote ~]# kubectl get po -A
    NAMESPACE     NAME                                          READY   STATUS    RESTARTS   AGE
    kube-system   calico-kube-controllers-6949477b58-mzpbf      1/1     Running   0          16m
    kube-system   calico-node-4jlnb                             1/1     Running   0          12m
    kube-system   calico-node-mbxvg                             1/1     Running   0          16m
    kube-system   calico-node-r75dk                             1/1     Running   0          3m28s
    kube-system   coredns-6d56c8448f-sx9nk                      1/1     Running   0          24m
    kube-system   coredns-6d56c8448f-vkf9x                      1/1     Running   0          24m
    kube-system   etcd-kubernetes-master01                      1/1     Running   0          24m
    kube-system   kube-apiserver-kubernetes-master01            1/1     Running   0          24m
    kube-system   kube-controller-manager-kubernetes-master01   1/1     Running   0          14m
    kube-system   kube-proxy-b2jdp                              1/1     Running   0          24m
    kube-system   kube-proxy-fjvvs                              1/1     Running   0          3m28s
    kube-system   kube-proxy-gpwcn                              1/1     Running   0          12m
    kube-system   kube-scheduler-kubernetes-master01            1/1     Running   0          14m

至此集群就搭建结束了。

集群测试

还记得后面文章本机 mac 搭建 minikube 的过程吗,集群测试我就照着前文来试了一遍,一切正常。附上上文链接。

上面的文章会对集群节点的操作以及多主多从的高可用集群做一些操作尝试。

参考资料

  • https://kubernetes.io/zh/docs…
  • https://kubernetes.io/zh/docs…
正文完
 0