首页 > kubernetes(k8s) > RockyLinux二进制部署k8s1.23.3(一)
2022
02-17

RockyLinux二进制部署k8s1.23.3(一)

RockyLinux镜像下载地址,节点系统安装此处省略。自行解决

1、集群规划

1.1 主要组件版本

1.2 主要配置策略

kube-apiserver:

  • 使用节点本地 nginx 4 层透明代理实现高可用;
  • 关闭非安全端口 8080 和匿名访问;
  • 在安全端口 5443 接收 https 请求;
  • 严格的认证和授权策略 (x509、token、RBAC);
  • 开启 bootstrap token 认证,支持 kubelet TLS bootstrapping;
  • 使用 https 访问 kubelet、etcd,加密通信;

kube-controller-manager:

  • 3 节点高可用;
  • 关闭非安全端口,在安全端口 10257 接收 https 请求;
  • 使用 kubeconfig 访问 apiserver 的安全端口;
  • 自动 approve kubelet 证书签名请求 (CSR),证书过期后自动轮转;
  • 各 controller 使用自己的 ServiceAccount 访问 apiserver;

kube-scheduler:

  • 3 节点高可用;
  • 使用 kubeconfig 访问 apiserver 的安全端口;
  • 关闭非安全端口,在安全端口 10259 接收 https 请求;

kubelet:

  • 使用 kubeadm 动态创建 bootstrap token,而不是在 apiserver 中静态配置;
  • 使用 TLS bootstrap 机制自动生成 client 和 server 证书,过期后自动轮转;
  • 在 KubeletConfiguration 类型的 JSON 文件配置主要参数;
  • 关闭只读端口,在安全端口 10250 接收 https 请求,对请求进行认证和授权,拒绝匿名访问和非授权访问;
  • 使用 kubeconfig 访问 apiserver 的安全端口;

kube-proxy:

  • 使用 kubeconfig 访问 apiserver 的安全端口;
  • 使用 ipvs 代理模式;

集群插件:

  • DNS:使用功能、性能更好的 coredns;

2、初始化系统环境和全局变量(所有节点)

2.1 注意:由于资源不足。本文使用12,13,14 这三台机器混合部署本文档的 etcd,master集群和 woker 集群

2.2 kubelet cri-o cgroup

2.3 设置主机名

2.4 添加节点信任关系

2.5 安装依赖包

2.6 关闭防火墙

关闭防火墙,清理防火墙规则,设置默认转发策略:

2.7 关闭 swap 分区

关闭 swap 分区,否则kubelet 会启动失败(可以设置 kubelet 启动参数 –fail-swap-on 为 false 关闭 swap 检查):

2.8 关闭 SELinux

关闭 SELinux,否则 kubelet 挂载目录时可能报错 Permission denied :

2.9 优化内核参数

2.10 系统文件打开数

如果是centos7还需修改

2.11 内核模块配置重启自动加载

加载ipvs内核模块

加载netfilter等模块

内核4版本以下 nf_conntrack 替换 nf_conntrack_ipv4

2.12 设置系统时区

2.13 设置系统时钟同步

查看同步状态:

输出:

  • System clock synchronized: yes,表示时钟已同步;
  • NTP service: active,表示开启了时钟同步服务;

2.14 关闭无关的服务

2.15 创建相关目录

  • master 组件目录(3个主节点可以以此创建)
  • node 节点目录 (3个node点可以以此创建)
  • cri-o 目录结构创建 (3个node点可以以此创建)

2.16 mount目录挂载 (3个node点可以以此创建)把创建目录挂给这些插件的默认存储路径,相当于做了一个软连接。

  • 挂载kubelet 跟cri-o数据目录最大兼容其它依赖组件例如csi插件
  • 验证挂载是否有误

重启机器:

3、创建 CA 根证书和秘钥

3.1 安装 cfssl 工具集

3.2 创建配置文件

CA 配置文件用于配置根证书的使用场景 (profile) 和具体参数 (usage,过期时间、服务端认证、客户端认证、加密等):

创建etcd K8S的 ca 证书目录

全局 配置文件生成

  • signing:表示该证书可用于签名其它证书(生成的 ca.pem 证书中 CA=TRUE);
  • server auth:表示 client 可以用该该证书对 server 提供的证书进行验证;
  • client auth:表示 server 可以用该该证书对 client 提供的证书进行验证;
  • “expiry”: “876000h”:证书有效期设置为 100 年;

3.3 创建证书签名请求文件

  • etcd 证书签名请求文件
  • k8s ca证书签名请求文件(ca-csr.json)
  • CN:Common Name:kube-apiserver 从证书中提取该字段作为请求的用户名 (User Name),浏览器使用该字段验证网站是否合法;
  • O:Organization:kube-apiserver 从证书中提取该字段作为请求用户所属的组 (Group);
  • kube-apiserver 将提取的 User、Group 作为 RBAC 授权的用户标识;

3.4 生成 CA 证书和私钥

生成 etcd CA 证书和私钥

生成 kubernetes CA 证书和私钥

3.5 分发CA证书文件

etcd ca 证书分发

kubernetes ca 证书分发

4、安装和配置 kubectl

本文档介绍安装和配置 kubernetes 命令行管理工具 kubectl 的步骤。

4.1 下载和分发 kubectl 二进制文件

分发到所有使用 kubectl 工具的节点:

4.2 创建 admin 证书和私钥

kubectl 使用 https 协议与 kube-apiserver 进行安全通信,kube-apiserver 对 kubectl 请求包含的证书进行认证和授权。

kubectl 后续用于集群管理,所以这里创建具有最高权限的 admin 证书。

创建证书签名请求:

  • O: system:masters:kube-apiserver 收到使用该证书的客户端请求后,为请求添加组(Group)认证标识 system:masters;
  • 预定义的 ClusterRoleBinding cluster-admin 将 Group system:masters 与 Role cluster-admin 绑定,该 Role 授予操作集群所需的最高权限;
  • 该证书只会被 kubectl 当做 client 证书使用,所以 hosts 字段为空;

生成证书和私钥:

4.3 创建 kubeconfig 文件

  • –certificate-authority:验证 kube-apiserver 证书的根证书;
  • –client-certificate、–client-key:刚生成的 admin 证书和私钥,与 kube-apiserver https 通信时使用;
  • –embed-certs=true:将 ca.pem 和 admin.pem 证书内容嵌入到生成的 kubectl.kubeconfig 文件中(否则,写入的是证书文件路径,后续拷贝 kubeconfig 到其它机器时,还需要单独拷贝证书文件,不方便。);
  • –server:指定 kube-apiserver 的地址,这里指向第一个节点上的服务;

4.4 分发 kubeconfig 文件

分发到所有使用 kubectl 命令的节点:

5、部署 etcd 集群

etcd 是基于 Raft 的分布式 KV 存储系统,由 CoreOS 开发,常用于服务发现、共享配置以及并发控制(如 leader 选举、分布式锁等)。

kubernetes 使用 etcd 集群持久化存储所有 API 对象、运行数据。

本文档介绍部署一个三节点高可用 etcd 集群的步骤:

  • 下载和分发 etcd 二进制文件;
  • 创建 etcd 集群各节点的 x509 证书,用于加密客户端(如 etcdctl) 与 etcd 集群、etcd 集群之间的通信;
  • 创建 etcd 的 systemd unit 文件,配置服务参数;
  • 检查集群工作状态;

etcd 集群节点名称和 IP 如下:

  • k8s-master-1:192.168.0.12
  • k8s-master-2:192.168.0.13
  • k8s-master-3:192.168.0.14

5.1 下载和分发 etcd 二进制文件

到 etcd 的  release 页面 下载最新版本的发布包:

分发二进制文件到集群所有节点:

5.2 创建 etcd 证书和私钥

  • 创建etcd服务证书
  • 创建证书签名请求:

生成证书和私钥:

创建etcd节点证书

192.168.0.12节点

生成证书和私钥:

192.168.0.13节点

生成证书和私钥:

192.168.0.14节点

生成证书和私钥:

  • 创建etcd client 证书
  • 创建证书签名请求:

生成证书和私钥:

分发生成的证书和私钥到各 etcd 节点:

5.3 创建 etcd 启动参数配置文件

192.168.0.12节点,在k8s-master-1 节点上执行

192.168.0.13节点:在k8s-master-2 节点上执行

192.168.0.14节点:在k8s-master-3 节点上执行

5.4 创建 etcd 的 systemd unit 文件

k8s-master-1 k8s-master-2 k8s-master-3 节点上分别执行

  • WorkingDirectory、–data-dir:指定工作目录和数据目录为 ${ETCD_DATA_DIR},需在启动服务前创建这个目录;
  • –wal-dir:指定 wal 目录,为了提高性能,一般使用 SSD 或者和 –data-dir 不同的磁盘;
  • –name:指定节点名称,当 –initial-cluster-state 值为 new 时,–name 的参数值必须位于 –initial-cluster 列表中;
  • –cert-file、–key-file:etcd server 与 client 通信时使用的证书和私钥;
  • –trusted-ca-file:签名 client 证书的 CA 证书,用于验证 client 证书;
  • –peer-cert-file、–peer-key-file:etcd 与 peer 通信使用的证书和私钥;
  • –peer-trusted-ca-file:签名 peer 证书的 CA 证书,用于验证 peer 证书;

5.5 创建etcd 运行用户

在k8s-master-1 k8s-master-2 k8s-master-3 节点上分别执行

创建etcd用户

etcd 目录给用户权限

5.6 启动 etcd 服务

k8s-master-1 k8s-master-2 k8s-master-3 节点上分别执行

  • 必须先创建 etcd 数据目录和工作目录;
  • etcd 进程首次启动时会等待其它节点的 etcd 加入集群,命令 systemctl start etcd 会卡住一段时间,为正常现象;

5.7 检查启动结果

k8s-master-1 k8s-master-2 k8s-master-3 节点上分别执行

确保状态为 active (running),否则查看日志,确认原因:

5.8 验证服务状态

部署完 etcd 集群后,在任一 etcd 节点上执行如下命令:

  • 3.5.2 版本的 etcd/etcdctl 默认启用了 V3 API,所以执行 etcdctl 命令时不需要再指定环境变量 ETCDCTL_API=3;
  • 从 K8S 1.13 开始,不再支持 v2 版本的 etcd;

预期输出:

输出均为 healthy 时表示集群服务正常。

5.9 查看当前的 leader

  • 可见,当前的 leader 为 192.168.0.12

6、下载及分发 kubernetes server 二进制包

从  CHANGELOG 页面 下载二进制 tar 文件并解压:

将二进制文件拷贝到所有 master 节点:

将二进制文件拷贝到所有 node 节点:

7、apiserver 高可用

7.1 高可用选型

  • ipvs+keepalived
  • nginx+keepalived
  • haprxoy+keepalived
  • 每个节点kubelet 启动静态pod nginx haprxoy

本文档选择每个节点kubelet 启动静态pod nginx haprxoy

7.2 构建nginx或者haproxy镜像

  • nginx dockerfile
  • haroxy dockerfile

7.3 生成kubelet 静态启动pod yaml

参数说明:

  • CPU_NUM:nginx 使用cpu 核数
  • BACKEND_PORT:后端kube-apiserver监听端口
  • HOST_PORT:负载均衡器监听端口
  • CP_HOSTS:kube-apiserver服务IP地址列表
  • metrics端口:8404 prometheus 拉取数据使用

已有镜像:

  • nginx 镜像:docker.io/juestnow/nginx-proxy:1.21.0
  • haproxy镜像:docker.io/juestnow/haproxy-proxy:2.4.0

分发kube-ha-proxy.yaml 到所有节点:

8、runtime组件

  • docker
  • containerd
  • cri-o [本文档选择cri-o为runtime组件]

8.1 部署cri-o组件

cri-o 实现了 kubernetes 的 Container Runtime Interface (CRI) 接口,提供容器运行时核心功能,如镜像管理、容器管理等,相比 docker 更加简单、健壮和可移植。

containerd cadvisor接口无pod网络不能很直观的监控pod网络使用所以本文选择cri-o

8.2 下载二进制文件

8.3 修改配置文件

cri-o 配置文件生成:

参数说明:

  • root:容器镜像存放目录;
  • runroot:容器运行目录;
  • log_dir:容器日志默认存放目录 kubelet 指定目录就存放kubelet所指定目录;
  • default_runtime:指定默认运行时;
  • conmon:conmon 二进制文件的路径,用于监控 OCI 运行时;
  • conmon_env:conmon 运行时的环境变量;
  • hooks_dir:OCI hooks 目录;
  • container_exits_dir:conmon 将容器出口文件写入其中的目录的路径;
  • namespaces_dir:管理命名空间状态被跟踪的目录。仅在 manage_ns_lifecycle 为 true 时使用;
  • pinns_path:pinns_path 是查找 pinns 二进制文件的路径,这是管理命名空间生命周期所必需的 ;
  • runtime_path:运行时可执行文件的绝对路径 ;
  • runtime_root:存放容器的根目录;
  • pause_image:pause镜像路径;
  • network_dir: cni 配置文件路径;
  • plugin_dirs:cni 二进制文件存放路径;
  • default runtime:使用crun
  • 运行路径:/apps/crio 请根据自己环境修改
  •  官网文档

cri-o 启动其它所需配置文件生成

8.4 创建 cri-o systemd unit 文件

8.5 分发文件

分发二进制文件及配置文件:

分发其它配置文件:

分发启动文件:

8.6 启动cri-o 服务

8.7 检查启动结果(所有节点执行)

确保状态为 active (running),否则查看日志,确认原因:

8.8 创建和分发 crictl 配置文件

crictl 是兼容 CRI 容器运行时的命令行工具,提供类似于 docker 命令的功能。具体参考 官方文档

分发到所有 节点:

8.9 验证cri-o是否能正常访问

9、cni plugins 部署(容器运行时使用网络需要)

9.1 下载二进制文件

9.2 解压及分发二进制文件

分发文件到所有节点:

创建cni 配置文件目录

10、部署 kube-apiserver 集群

本文档讲解部署一个三实例 kube-apiserver 集群的步骤.

10.1 创建kube-apiserver 证书

创建证书签名请求:

hosts 字段指定授权使用该证书的 IP 和域名列表,这里列出了 master 节点 IP、kubernetes 服务的 IP 和域名

生成 Kubernetes API Server 证书和私钥

10.2 创建加密配置文件

10.3 创建 Kubernetes webhook 证书

创建证书签名请求:

生成 Kubernetes webhook 证书和私钥

10.4 创建 kube-apiserver 配置文件

192.168.0.12节点:在k8s-master-1 节点上执行

192.168.0.13节点:在k8s-master-2 节点上执行

192.168.0.14节点:在k8s-master-3 节点上执行

参数解析:

官方参数详细说明

10.5 分发kube-apiserver 证书及配置

证书分发

配置分发

10.6 创建 kube-apiserver systemd unit 文件

k8s-master-1 k8s-master-2 k8s-master-3 节点上分别执行

10.7 启动 kube-apiserver 服务

k8s-master-1 k8s-master-2 k8s-master-3 节点上分别执行

10.8 检查启动结果

k8s-master-1 k8s-master-2 k8s-master-3 节点上分别执行

确保状态为 active (running),否则查看日志,确认原因:

10.9 验证服务状态

qist 节点上执行( 部署完 kube-apiserver 集群后,在任一 qist 节点上执行如下命令):

scheduler controller-manager 还没部署所以报错

后续请移步至第二篇文章

最后编辑:
作者:shooter
这个作者貌似有点懒,什么都没有留下。

留下一个回复

你的email不会被公开。