使用kubeadm安装Kubernetes 1.12

软件安装 麋鹿 381℃
本文最后更新于 2019年11月12日 16:38 可能会因为没有更新而失效。如已失效或需要修正,请留言!

kubeadm是Kubernetes官方提供的用于快速安装Kubernetes集群的工具,伴随Kubernetes每个版本的发布都会同步更新,kubeadm会对集群配置方面的一些实践做调整,通过实验kubeadm可以学习到Kubernetes官方在集群配置上一些新的最佳实践。

在Kubernetes的文档Creating a single master cluster with kubeadm中已经给出了目前kubeadm的主要特性已经处于beta状态了,在2018年将进入GA状态,说明kubeadm离可以在生产环境中使用的距离越来越近了。

一、准备

1.系统配置

在安装之前,需要先做如下准备。两台CentOS 7.4主机如下:

如果各个主机启用了防火墙,需要开放Kubernetes各个组件所需要的端口,可以查看Installing kubeadm中的”Check required ports”一节。 这里简单起见在各节点禁用防火墙:

禁用selinux

创建/etc/sysctl.d/k8s.conf文件,添加如下内容:

执行命令是修改生效。

2.安装docker

Kubernetes从1.6开始使用CRI(Container Runtime Interface)容器运行时接口。默认的容器运行时仍然是Docker,使用的是kubelet中内置dockershim CRI实现。

安装docker的yum源:

查看最新的Docker版本:

Kubernetes 1.12已经针对Docker的1.11.1, 1.12.1, 1.13.1, 17.03, 17.06, 17.09, 18.06等版本做了验证,需要注意Kubernetes 1.12最低支持的Docker版本是1.11.1。 我们这里在各节点安装docker的18.06.1版本。

确认一下iptables filter表中FOWARD链的默认策略(pllicy)为ACCEPT。

Docker从1.13版本开始调整了默认的防火墙规则,禁用了iptables filter表中FOWARD链,这样会引起Kubernetes集群中跨Node的Pod无法通信。但这里通过安装docker 1806,发现默认策略又改回了ACCEPT,这个不知道是从哪个版本改回的,因为我们线上版本使用的1706还是需要手动调整这个策略的。

二、使用kubeadm 部署 Kubernetes

1.安装kubeadm和kubelet

下面在各节点安装kubeadm和kubelet:

配置kubenetes阿里镜像源
vim /etc/yum.repos.d/kubernetes.repo

↑国内源 不需要翻墙

↓国外源 需要翻墙

测试地址https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64是否可用,如果不可用需要科学上网。

yum源配置结束,开始安装:

• 从安装结果可以看出还安装了cri-tools, kubernetes-cni, socat三个依赖:
• 官方从Kubernetes 1.9开始就将cni依赖升级到了0.6.0版本,在当前1.12中仍然是这个版本
• socat是kubelet的依赖
• cri-tools是CRI(Container Runtime Interface)容器运行时接口的命令行工具

运行kubelet –help可以看到原来kubelet的绝大多数命令行flag参数都被DEPRECATED了,如:

而官方推荐我们使用–config指定配置文件,并在配置文件中指定原来这些flag所配置的内容。具体内容可以查看这里Set Kubelet parameters via a config file。这也是Kubernetes为了支持动态Kubelet配置(Dynamic Kubelet Configuration)才这么做的,参考Reconfigure a Node’s Kubelet in a Live Cluster

kubelet的配置文件必须是json或yaml格式,具体可查看这里

Kubernetes 1.8开始要求关闭系统的Swap,如果不关闭,默认配置下kubelet将无法启动。

关闭系统的Swap方法如下:

修改 /etc/fstab 文件,注释掉 SWAP 的自动挂载,使用free -m确认swap已经关闭。 swappiness参数调整,修改/etc/sysctl.d/k8s.conf添加下面一行:

执行sysctl -p /etc/sysctl.d/k8s.conf使修改生效。

因为这里本次用于测试两台主机上还运行其他服务,关闭swap可能会对其他服务产生影响,所以这里修改kubelet的配置去掉这个限制。 之前的Kubernetes版本我们都是通过kubelet的启动参数–fail-swap-on=false去掉这个限制的。前面已经分析了Kubernetes不再推荐使用启动参数,而推荐使用配置文件。 所以这里我们改成配置文件配置的形式。

查看/etc/systemd/system/kubelet.service.d/10-kubeadm.conf,看到了下面的内容:

上面显示kubeadm部署的kubelet的配置文件-config=/var/lib/kubelet/config.yaml,实际去查看/var/lib/kubelet和这个config.yaml的配置文件都没有被创建。 可以猜想肯定是运行kubeadm初始化集群时会自动生成这个配置文件,而如果我们不关闭Swap的话,第一次初始化集群肯定会失败的。

所以还是老老实实的回到使用kubelet的启动参数–fail-swap-on=false去掉必须关闭Swap的限制。 修改/etc/sysconfig/kubelet,加入:

2.使用kubeadm init初始化集群

在各节点开机启动kubelet服务:

接下来使用kubeadm初始化集群,选择node1作为Master Node,在node1上执行下面的命令:

因为我们选择flannel作为Pod网络插件,所以上面的命令指定–pod-network-cidr=10.244.0.0/16。

执行时如果报下面的错误:

有一个错误信息是running with swap on is not supported. Please disable swap。因为我们决定配置failSwapOn: false,所以重新添加-ignore-preflight-errors=Swap参数忽略这个错误,重新运行。

因国内无法直接访问 k8s.gcr.io  增加步骤:

如果出现以下错误,则就是因为k8s.gcr.io 被墙国内无法直接访问:

解决方案:docker.io仓库对google的容器做了镜像,可以通过下列命令下拉取相关镜像

版本信息需要根据实际情况进行相应的修改。通过docker tag命令来修改镜像的标签:

重新执行初始化命令:

增加步骤到此结束!!!

出现以下内容则表示初始化成功:

上面记录了完成的初始化输出的内容,根据输出的内容基本上可以看出手动初始化安装一个Kubernetes集群所需要的关键步骤。

其中有以下关键内容:

• [kubelet] 生成kubelet的配置文件”/var/lib/kubelet/config.yaml”
• [certificates]生成相关的各种证书
• [kubeconfig]生成相关的kubeconfig文件
• [bootstraptoken]生成token记录下来,后边使用kubeadm join往集群中添加节点时会用到
• 下面的命令是配置常规用户如何使用kubectl访问集群:

• 最后给出了将节点加入集群的命令kubeadm join 192.168.61.11:6443 –token zalj3i.q831ehufqb98d1ic –discovery-token-ca-cert-hash sha256:6ee48b19ba61a2dda77f6b60687c5fd11072ab898cfdfef32a68821d1dbe8efa

查看一下集群状态:

确认个组件都处于healthy状态。

如果报错8080端口

集群初始化如果遇到问题,可以使用下面的命令进行清理:

3.安装Pod Network

接下来安装flannel network add-on:

这里注意kube-flannel.yml这个文件里的flannel的镜像是0.10.0,quay.io/coreos/flannel:v0.10.0-amd64

如果Node有多个网卡的话,参考flannel issues 39701,目前需要在kube-flannel.yml中使用–iface参数指定集群主机内网网卡的名称,否则可能会出现dns无法解析。需要将kube-flannel.yml下载到本地,flanneld启动参数加上–iface=<iface-name>

本次按上面的步骤部署flannel,发现没有效果,查看一下集群中的daemonset:

结合kube-flannel.yml,fannel官方的部署yaml文件是要在集群中创建5个针对不同平台的DaemonSet,通过Node的Label beta.kubernetes.i/oarch,在对应不同平台的Node节点上启动flannel的容器。当前的node1节点是beta.kubernetes.i/oarch=amd64,因此对于kube-flannel-ds-amd64这个DaemonSet来说,它的DESIRED数量应该为1才对。查看kube-flannel.yml中关于kube-flannel-ds-amd64的内容:

kube-flannel.yml中已经为kube-flannel-ds-amd64正确设置了调度相关的nodeSelector和tolerations,即将这个DaemonSet的Pod调度到Label为beta.kubernetes.io/arch: amd64,同时容忍node-role.kubernetes.io/master:NoSchedule污点的节点上。这个按照以前的部署经验来说当前的主节点node1应该是多满足的,可是现在是这样的吗?我们查看一下node1节点的基本信息:

可以看到1.12版本的kubeadm额外给node1节点设置了一个污点(Taint):node.kubernetes.io/not-ready:NoSchedule,很容易理解,即如果节点还没有ready之前,是不接受调度的。可是如果Kubernetes的网络插件还没有部署的话,节点是不会进入ready状态的。因此我们修改以下kube-flannel.yaml的内容,加入对node.kubernetes.io/not-ready:NoSchedule这个污点的容忍:

重新apply一下kubectl apply -f kube-flannel.yml,这次成功完成flannel的部署了。

使用kubectl get pod –all-namespaces -o wide确保所有的Pod都处于Running状态。

后来也在flannel的github中找到了关于node.kubernetes.io/not-ready:NoSchedule这个问题的讨论,相信很快就会将相关配置修改正确,详见https://github.com/coreos/flannel/issues/1044。

4.master node 参与工作负载

使用kubeadm初始化的集群,出于安全考虑Pod不会被调度到Master Node上,也就是说Master Node不参与工作负载。这是因为当前的master节点node1被打上了node-role.kubernetes.io/master:NoSchedule的污点:

因为这里搭建的是测试环境,去掉这个污点使node1参与工作负载:

5.测试DNS

进入后执行nslookup kubernetes.default确认解析正常:

6.向Kubernetes 集群中添加Node 节点

下面我们将node2这个主机添加到Kubernetes集群中,因为我们同样在node2上的kubelet的启动参数中去掉了必须关闭swap的限制,所以同样需要–ignore-preflight-errors=Swap这个参数。 在node2上执行:

node2加入集群很是顺利,下面在master节点上执行命令查看集群中的节点:

如何从集群中移除Node
如果需要从集群中移除node2这个Node执行下面的命令:

在master节点上执行:

在node2上执行:

在node1上执行:

三、Kubernetes常用组件部署

越来越多的公司和团队开始使用Helm这个Kubernetes的包管理器,我们也将使用Helm安装Kubernetes的常用组件。

1.Helm的安装

Helm由客户端命helm令行工具和服务端tiller组成,Helm的安装十分简单。 下载helm命令行工具到master节点node1的/usr/local/bin下,这里下载的2.9.1版本:

wget https://cherryleo-1253732882.cos.ap-chengdu.myqcloud.com/helm-v2.9.1-linux-amd64.tar.gz 国内源

为了安装服务端tiller,还需要在这台机器上配置好kubectl工具和kubeconfig文件,确保kubectl工具可以在这台机器上访问apiserver且正常使用。 这里的node1节点以及配置好了kubectl。

因为Kubernetes APIServer开启了RBAC访问控制,所以需要创建tiller使用的service account: tiller并分配合适的角色给它。 详细内容可以查看helm文档中的Role-based Access Control。 这里简单起见直接分配cluster-admin这个集群内置的ClusterRole给它。创建rbac-config.yaml文件:

接下来使用helm 部署 tiller:

tiller默认被部署在k8s集群中的kube-system这个namespace下:

注意由于某些原因需要网络可以访问gcr.io和kubernetes-charts.storage.googleapis.com,如果无法访问可以通过helm init –service-account tiller –tiller-image <your-docker-registry>/tiller:v2.11.0 –skip-refresh使用私有镜像仓库中的tiller镜像

其中tiller pod的状态为“ImagePullBackOff”,我们可以指定对应的tiller镜像为阿里云地址来解决,如下:

2.使用Helm部署Nginx Ingress

为了便于将集群中的服务暴露到集群外部,从集群外部访问,接下来使用Helm将Nginx Ingress部署到Kubernetes上。 Nginx Ingress Controller被部署在Kubernetes的边缘节点上,关于Kubernetes边缘节点的高可用相关的内容可以查看我前面整理的Bare metal环境下Kubernetes Ingress边缘节点的高可用。 这里简单起见,只有一个edge节点。

我们将node1(192.168.61.11)同时做为边缘节点,打上Label:

stable/nginx-ingress chart的值文件ingress-nginx.yaml:

如果访问http://192.168.61.11返回default backend,则部署完成:

2.将TLS证书配置到Kubernetes中

当使用Ingress将HTTPS的服务暴露到集群外部时,需要HTTPS证书,这里将*.frognew.com的证书和秘钥配置到Kubernetes中。

后边部署在kube-system命名空间中的dashboard要使用这个证书,因此这里先在kube-system中创建证书的secret

3.使用Helm 部署 dashboard

kubernetes-dashboard.yaml:

在dashboard的登录窗口使用上面的token登录。images

4.使用Helm 部署 metrics-server

从Heapster的github https://github.com/kubernetes/heapster中可以看到已经,heapster已经DEPRECATED。这里heapster的deprecation timeline。可以看出heapster从Kubernetes 1.12开始将从Kubernetes各种安装脚本中移除。

Kubernetes推荐使用metrics-server(https://github.com/kubernetes-incubator/metrics-server)。我们这里也使用helm来部署metrics-server。

metrics-server.yaml:

部署后,查看metrics-server的日志,报下面的错误:

可以看到metrics-server在从kubelet的10250端口获取信息时,使用的是hostname,而因为node1和node2是一个独立的演示环境,只是修改了这两个节点系统的/etc/hosts文件,而并没有内网的DNS服务器,所以metrics-server中不认识node1和node2的名字。这里我们可以直接修改Kubernetes集群中的coredns的configmap,修改Corefile加入hostnames插件,将Kubernetes的各个节点的主机名加入到hostnames中,这样Kubernetes集群中的所有Pod都可以从CoreDNS中解析各个节点的名字。

配置修改完毕后重启集群中coredns和metrics-server,确认metrics-server不再有错误日志。使用下面的命令可以获取到关于集群节点基本的指标信息:

遗憾的是,当前Kubernetes Dashboard还不支持metrics-server。因此如果使用metrics-server替代了heapster,将无法在dashboard中以图形展示Pod的内存和CPU情况(实际上这也不是很重要,当前我们是在Prometheus和Grafana中定制的Kubernetes集群中各个Pod的监控,因此在dashboard中查看Pod内存和CPU也不是很重要)。 Dashboard的github上有很多这方面的讨论,如https://github.com/kubernetes/dashboard/issues/3217和https://github.com/kubernetes/dashboard/issues/3270,Dashboard已经准备在将来的某个时间点支持metrics-server。但由于metrics-server和metrics pipeline肯定是Kubernetes在monitor方面未来的方向,所以我们也很果断的在各个环境中切换到了metrics-server。

四、总结

本次安装涉及到的Docker镜像:

参考

原文:https://blog.frognew.com/2018/10/kubeadm-install-kubernetes-1.12.html

 

转载请注明:百分数 » 使用kubeadm安装Kubernetes 1.12
责任声明: 本站一切资源仅用作交流学习,请勿用作商业或违法行为!如造成任何后果,本站概不负责!
喜欢 (0)