#云原生征文#二进制安装多master节点的k8s集群-1.20.7 原创 精华
二进制部署k8s高可用集群-v1.20.7
二进制安装多master节点k8s(k8s1.20.7版本)高可用集群-keeplive+nginx实现k8s apiserver高可用。
一、部署规划:
- Pod网段:10.0.0.0/16
- Service网段:10.255.0.1/16
- 操作系统:Centos7.6
- 配置:4G/6C/100G
- 网络模式:静态IP
角色 | IP地址 | 安装组件 |
---|---|---|
master01 | 172.27.11.223 | apiserver、controller-manager、scheduler、etcd、docker、keeplived、nginx |
master02 | 172.27.11.145 | apiserver、controller-manager、scheduler、etcd、docker、keeplived、nginx |
master03 | 172.27.11.217 | apiserver、controller-manager、scheduler、etcd、docker、keeplived、nginx |
work01 | 172.27.11.106 | kubelet、kube-proxy、docker、calico、coredns |
work02 | 172.27.11.128 | kubelet、kube-proxy、docker、calico |
work03 | 172.27.11.147 | kubelet、kube-proxy、docker、calico |
VIP | 172.27.11.2 | / |
二、高可用架构:
- 主备模式高可用架构说明:
核心组件 | 高可用模式 | 高可用实现方式 |
---|---|---|
apiserver | 主备 | keeplived |
controller-manager | 主备 | leader election |
scheduler | 主备 | leader election |
etcd | 集群 | / |
- apiserver 通过haproxy+keepalived实现高可用,当某个节点故障时触发keepalived vip 转移;
- controller-manager k8s内部通过选举方式产生领导者(由–leader-elect 选型控制,默认为true),同一时刻集群内只有一个controller-manager组件运行;
- scheduler k8s内部通过选举方式产生领导者(由–leader-elect 选型控制,默认为true),同一时刻集群内只有一个scheduler组件运行;
- etcd 自动创建集群来实现高可用,部署的节点数为奇数。如果剩余可用节点数量超过半数,集群可以几乎没有影响的正常工作(3节点方式最多容忍一台机器宕机);
三、kubeadm和二进制安装k8s适用场景分析:
-
kubeadm:kubeadm是官方提供的开源工具,是一个开源项目,用于快速搭建kubernetes集群,目前是比较方便和推荐使用的。kubeadm init 以及 kubeadm join 这两个命令可以快速创建 kubernetes 集群。Kubeadm初始化k8s,所有的组件都是以pod形式运行的,具备故障自恢复能力。kubeadm是工具,可以快速搭建集群,也就是相当于用程序脚本帮我们装好了集群,属于自动部署,简化部署操作,自动部署屏蔽了很多细节,使得对各个模块感知很少,如果对k8s架构组件理解不深的话,遇到问题比较难排查。kubeadm适合需要经常部署k8s,或者对自动化要求比较高的场景下使用。
-
二进制:在官网下载相关组件的二进制包,如果手动安装,对kubernetes理解也会更全面。
Kubeadm和二进制都适合生产环境,在生产环境运行都很稳定,具体如何选择,可以根据实际项目进行评估。
四、初始化集群:
4.1 安装规划配置静态IP、主机名
4.2 配置hosts文件:
- 该操作需要在集群中所有节点(master和work)全部执行,添加如下内容:
4.3 配置主机之间无密码登录:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.4 关闭firewalld:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.5 关闭selinux:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.6 关闭swap交换分区:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.7 修改内核参数:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.8 配置部署集群所需要的yum源:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.9 配置时间同步:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.10 安装iptables:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.11 安装ipvs:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.12 安装docker-ce:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.13 配置docker镜像加速器:
- 该操作需要在集群中所有节点(master和work)全部执行:
4.14 配置nginx和keepalived
- 该操作需要在集群中所有节点(maste)全部执行:
4.15 将集群搭建需要的安装包拷贝到集群中
- 该操作需要在集群中所有节点(master和work)全部执行:
五、搭建etcd集群:
5.1 配置etcd工作目录:
- 该操作需要在集群中所有节点(master)全部执行:
5.2 安装签发证书工具cfssl:
- 该操作需要在集群节点(master01)执行:
5.3 生成ca根证书(用于后续给集群etcd、apiserver等签发证书):
- 生成ca证书请求文件,该操作仅需要在集群节点(master01)执行:
5.4 生成ca证书配置文件:
- 生成ca证书配置文件,该操作需要在master01执行:
5.5 生成etcd证书
- 生成etcd证书请求文件,hosts的ip变成自己etcd所在节点的ip,该操作在集群节点(master01)执行:
- 生成etcd证书:
5.6 部署etcd集群:
- 该操作需要在集群中所有节点(master)全部执行:
5.6.1 master01部署etcd:
- 解压etcd文件,移动至对应目录中:
- 创建配置文件:
- 创建启动服务文件:
- 移动刚才创建的证书、配置文件、启动文件至相应目录中,同时需要将证书拷贝到master02和master03上面:
- 创建etcd数据目录:
5.6.2 master02部署etcd:
- 解压etcd文件,移动至对应目录中:
- 从master01拷贝证书、etcd启动文件、etcd配置文件
- 创建etcd数据目录:
- 根据实际情况修改配置文件中的参数:
5.6.3 master03部署etcd:
- 解压etcd文件,移动至对应目录中:
- 从master01拷贝证书、etcd启动文件、etcd配置文件
- 创建etcd数据目录:
- 根据实际情况修改配置文件中的参数:
5.6.4 依次启动3个节点的etcd服务:
启动etcd的时候,先启动master01的etcd服务,会一直卡住在启动的状态,然后接着再启动master02的etcd,这样master01这个节点etcd才会正常起来,最后启动master03的etcd服务。
5.6.5 查看etcd集群:
六、安装kubernetes组件:
master节点
- apiserver
- controller manager
- scheduler
work节点
- kubelet
- kube-proxy
6.1 解压移动安装包:
- 在之前我们已经将kubernetes安装包上传到了集群各个节点上面(1.4.15章节中),如果有需要部署其他版本的同学,可以在下面的链接进行下载:二进制安装包所在的github下载地址如下:
6.2 部署apiserver组件:
6.2.1 TLS Bootstrapping机制原理详解:
- 启动TLS Bootstrapping机制:
Master apiserver启用TLS认证后,每个节点的 kubelet 组件都要使用由 apiserver 使用的 CA 签发的有效证书才能与 apiserver 通讯,当Node节点很多时,这种客户端证书颁发需要大量工作,同样也会增加集群扩展复杂度。
为了简化流程,Kubernetes引入了TLS bootstraping机制来自动颁发kubelet客户端证书,kubelet会以一个低权限用户自动向apiserver申请证书,kubelet的证书由apiserver动态签署。
Bootstrap 是很多系统中都存在的程序,比如 Linux 的bootstrap,bootstrap 一般都是作为预先配置在开启或者系统启动的时候加载,这可以用来生成一个指定环境。Kubernetes 的 kubelet 在启动时同样可以加载一个这样的配置文件,这个文件的内容类似如下形式:
-
TLS Bootstrapping具体引导过程:
- TLS的作用:TLS 的作用就是对通讯加密,防止中间人窃听;同时如果证书不信任的话根本就无法与 apiserver 建立连接,更不用提有没有权限向apiserver请求指定内容。
- RBAC:当 TLS 解决了通讯问题后,那么权限问题就应由 RBAC 解决(可以使用其他权限模型,如 ABAC);RBAC 中规定了一个用户或者用户组(subject)具有请求哪些 api 的权限;在配合 TLS 加密的时候,实际上 apiserver 读取客户端证书的 CN 字段作为用户名,读取 O字段作为用户组。
- 以上说明:第一,想要与 apiserver 通讯就必须采用由 apiserver CA 签发的证书,这样才能形成信任关系,建立 TLS 连接;第二,可以通过证书的 CN、O 字段来提供 RBAC 所需的用户与用户组。不直接给用户授权,而且给角色去授权,将用户绑定给角色。
-
kubelet首次启动流程:
TLS bootstrapping 功能是让 kubelet 组件去 apiserver 申请证书,然后用于连接 apiserver;那么第一次启动时没有证书如何连接 apiserver ?
在apiserver 配置中指定了一个 token.csv 文件,该文件中是一个预设的用户配置;同时该用户的Token 和 由apiserver 的 CA签发的用户被写入了 kubelet 所使用的 bootstrap.kubeconfig 配置文件中;这样在首次请求时,kubelet 使用 bootstrap.kubeconfig 中被 apiserver CA 签发证书时信任的用户来与 apiserver 建立 TLS 通讯,使用 bootstrap.kubeconfig 中的用户 Token 来向 apiserver 声明自己的 RBAC 授权身份。
token.csv格式:3940fd7fbb391d1b4d861ad17a1f0613,kubelet-bootstrap,10001,“system:kubelet-bootstrap”首次启动时,可能与遇到 kubelet 报 401 无权访问 apiserver 的错误;这是因为在默认情况下,kubelet 通过 bootstrap.kubeconfig 中的预设用户 Token 声明了自己的身份,然后创建 CSR 请求;但是不要忘记这个用户在我们不处理的情况下他没任何权限的,包括创建 CSR 请求;所以需要创建一个 ClusterRoleBinding,将预设用户 kubelet-bootstrap 与内置的 ClusterRole system:node-bootstrapper 绑定到一起,使其能够发起 CSR 请求。稍后安装kubelet的时候演示。
6.2.2 master01部署kube-apiserver
- 创建token.csv文件:
- 创建csr请求文件,替换为自己机器的IP地址:
- 生成kube-apiserver证书:
- 创建apiserver配置文件,并替换为自己的IP:
- 创建apiserver启动配置文件:
- 移动刚才创建的证书、配置文件、启动配置文件:
- 启动kube-apiserver服务:
6.2.3 master02部署kube-apiserver:
- 从master01拷贝证书、kube-apiserver启动文件、kube-apiserver配置文件和token文件:
- 修改配置kube-apiserver.conf配置文件:
- 启动kube-apiserver服务:
6.2.4 master03部署kube-apiserver:
- 从master01拷贝证书、kube-apiserver启动文件、kube-apiserver配置文件和token文件:
- 修改配置kube-apiserver.conf配置文件:
- 启动kube-apiserver服务:
6.2.4 测试kube-apiserver节点状态:
- 登录到任何一个节点进行测试:
七、部署kubectl组件:
Kubectl是客户端工具,操作k8s资源的,如增删改查等。
Kubectl操作资源的时候,怎么知道连接到哪个集群,需要一个文件/etc/kubernetes/admin.conf,kubectl会根据这个文件的配置,去访问k8s资源。/etc/kubernetes/admin.con文件记录了访问的k8s集群,和用到的证书。
- 可以设置一个环境变量KUBECONFIG:
- 也可以按照下面方法,这个是在kubeadm初始化k8s的时候会告诉我们要用的一个方法:
如果设置了KUBECONFIG,那就会先找到KUBECONFIG去操作k8s,如果没有KUBECONFIG变量,那就会使用/root/.kube/config文件决定管理哪个k8s集群的资源。
7.1 创建csr请求文件:
说明:后续 kube-apiserver 使用 RBAC 对客户端(如 kubelet、kube-proxy、Pod)请求进行授权; kube-apiserver 预定义了一些 RBAC 使用的 RoleBindings,如 cluster-admin 将 Group system:masters 与 Role cluster-admin 绑定,该 Role 授予了调用kube-apiserver 的所有 API的权限; O指定该证书的 Group 为 system:masters,kubelet 使用该证书访问 kube-apiserver 时 ,由于证书被 CA 签名,所以认证通过,同时由于证书用户组为经过预授权的 system:masters,所以被授予访问所有 API 的权限。
这个admin 证书,是将来生成管理员用的kube config 配置文件用的,现在我们一般建议使用RBAC 来对kubernetes 进行角色权限控制, kubernetes 将证书中的CN 字段 作为User, O 字段作为 Group; “O”: “system:masters”, 必须是system:masters,否则后面kubectl create clusterrolebinding报错。
证书O配置为system:masters 在集群内部cluster-admin的clusterrolebinding将system:masters组和cluster-admin clusterrole绑定在一起。
7.2 生成证书:
7.3 配置安全上下文:
创建kubeconfig配置文件,比较重要:kubeconfig 为 kubectl 的配置文件,包含访问 apiserver 的所有信息,如 apiserver 地址、CA 证书和自身使用的证书(这里如果报错找不到kubeconfig路径,请手动复制到相应路径下,没有则忽略)
- 设置集群参数:
- 设置客户端认证参数:
- 设置上下文参数:
- 设置当前上下文:
- 授权kubernetes证书访问kubelet api权限:
7.4 查看集群组件状态:
7.5 将kubectl用到的config文件同步到其他2的master上面:
7.6 配置kubectl子命令补全:
八、部署kube-controller-manager组件:
8.1 创建crs请求文件:
8.2 生成证书:
8.3 创建kube-controller-manager的kubeconfig:
- 设置集群参数:
- 设置客户端认证参数:
- 设置上下文参数:
- 设置当前上下文:
8.4 创建配置文件:
8.5 创建启动文件:
8.6 拷贝刚才创建的证书、启动文件和配置文件:
8.7 启动服务,查看状态:
8.8 master02和master03部署controller-manager:
- 拷贝启动文件、配置文件、kubeconfig文件、证书至对应目录:
- 启动服务,查看状态:
九、部署kube-scheduler组件:
9.1 创建csr请求文件:
9.2 生成证书:
9.3 创建kube-scheduler的kubeconfig:
- 设置集群参数:
- 设置客户端认证参数:
- 设置上下文参数:
- 设置当前上下文:
9.4 创建配置文件:
9.5 创建启动文件:
9.6 拷贝刚才创建的证书、启动文件和配置文件:
9.7 启动服务,查看状态:
9.8 master02和master03部署scheduler:
- 拷贝启动文件、配置文件、kubeconfig文件、证书至对应目录:
- 启动服务,查看状态:
十、上传解压后面部署服务需要的镜像:
- 需要在work01-work03节点上传即可;
十一、部署kubelet组件:
每个Node节点上的kubelet定期就会调用API Server的REST接口报告自身状态,API Server接收这些信息后,将节点状态信息更新到etcd中。kubelet也通过API Server监听Pod信息,从而对Node机器上的POD进行管理,如创建、删除、更新Pod。
11.1 创建kubelet-bootstrap.kubeconfig:
- 以下操作在master01上操作:
- 设置集群参数:
- 设置客户端认证参数:
- 设置上下文参数:
- 设置当前上下文:
- 创建集群角色绑定kubelet用户:
11.2 创建配置文件kubelet.json:
“cgroupDriver”: "systemd"要和docker的驱动一致。address替换为自己work1的IP地址。
11.3 创建启动文件:
11.4 将对应的启动文件,配置文件,kubeconfig、证书复制到work1-work3:
11.5 修改3个work节点的kubelet.json文件
11.6 work启动kubelet服务:
11.7 master01批准节点CSR请求:
十二、部署kube-proxy组件:
12.1 创建csr请求:
12.2 生成证书:
12.3 创建kube-proxy的kubeconfig:
- 设置集群参数:
- 设置客户端认证参数:
- 设置上下文参数:
- 设置当前上下文:
- 移动kubeconfig文件到3个work节点:
12.4 创建kube-proxy配置文件:
12.5 创建服务启动文件:
12.5 将对应的配置文件和服务配置文件复制到work1-work3:
12.6 work启动kube-proxy服务:
十三、部署calico网络组件:
十四、部署coredns组件:
十五、测试k8s集群部署tomcat服务
- 在3个work节点上面解压tomcat.tar.gz和busybox-1-28.tar.gz
十六、验证coredns服务是否正常
本文正在参加云原生有奖征文活动】,活动链接: https://ost.51cto.com/posts/12598
大佬说的文末 ,配置文件 在哪呢 ?一个也米找到啊