背景
Kubernetes 1.24新特性
从kubelet中移除dockershim
自1.20版本被弃用之后,dockershim组件终于在1.24的kubelet中被删除。从1.24开始,大家需要使用其他受到支持的运行时选项(例如containerd或CRI-O);如果您选择Docker Engine作为运行时,则需要使用cri-dockerd。
对于kubelet和containerd重要提示
在升级至1.24之前,请确认containerd版本
- #以下容器运行时已经或即将全面兼容Kubernetes 1.24:
containerd v1.6.4及更高,v1.5.11及更高
CRI-O 1.24及更高
若CNI插件尚未升级且/或CNI配置文件中未声明CNI配置版本时,则containerd v1.6.0-v1.6.3版本将导致Pod CNI网络setup及tear down发生问题。containerd团队报告称,这些问题已经在containerd v1.6.4中得到解决。
在containerd v1.6.0-v1.6.3时,如果你未升级CNI插件且/或声明CNI配置版本,则可能遇到CNI版本不兼容或无法为沙箱删除网络等错误
Kubernetes 1.24新特性
-
各beta API默认关闭
在默认情况下,新的各beta API不会在集群内得到启用。但全部原有beta API及其新版本将在1.24中继续默认启用 -
OpenAPI v3
Kubernetes 1.24开始为API的OpenAPI v3发布格式提供beta支持。 -
存储容量与存储卷扩展双双迎来通用版本
存储容量跟踪通过CSIStorageCapacity对象公开当前可用的存储容量,并对使用后续绑定的CSI存储卷的pod进行调度增强。
存储卷扩展则新增对现有持久卷的重新调整功能。 -
NonPreemptingPriority迎来稳定版
此功能为PriorityClasses添加了新的选项,可开启或关闭Pod抢占机制 -
存储插件迁移
目前Kubernetes开发团队正在迁移树内存储插件,希望在实现CSI插件的同时、保持原有API的正常起效。Azure Disk与OpenStack Cinder等插件已经完成了迁移。 -
gRPC探针升级至beta版
在1.24版本中,gRPC探针功能已经进入beta阶段且默认启用。现在,大家可以在Kubernetes中为自己的gRPC应用程序原生配置启动、活动与就绪探测,而且无需公开HTTP商战或者使用额外的可执行文件。 -
Kubelet证书提供程序升级至beta版
最初在Kubernetes 1.20版本中以alpha版亮相的kubelet镜像证书提供程序现已升级至beta版。现在,kubelet将使用exec插件动态检索容器镜像注册表的凭证,而不再将凭证存储在节点文件系统之上。 -
避免为服务分配IP时发生冲突
Kubernetes 1.24引入了一项新的选择性功能,允许用户为服务的静态IP分配地址保留一个软范围。通过手动启用此项功能,集群将从您指定的服务IP池中自动获取地址,从而降低冲突风险。
也就是说,服务的ClusterIP能够以下列方式分配:
动态分配,即集群将在配置的服务IP范围内自动选择一个空闲IP。
静态分配,意味着用户需要在已配置的服务IP范围内指定一个IP。
服务ClusterIP是唯一的;因此若尝试使用已被分配的ClusterIP进行服务创建,则会返回错误结果。
环境准备
本地有kubernetes 1.18环境,(没有就跳过) 接下来对环境进行初始化
卸载集群命令
基础环境配置
IP地址 | 主机名 | 服务 | 配置 |
---|---|---|---|
192.168.31.10 | k8s-01 | k8s-master、containerd、keepalived、nginx 2c8g | |
192.168.31.11 | k8s-02 | k8s-master、containerd、keepalived、nginx 2c8g | |
192.168.31.12 | k8s-03 | k8s-master、containerd、keepalived、nginx 2c8g | |
192.168.31.13 | k8s-04 | k8s-node、containerd 1c4g | |
192.168.31.14 | k8s-05 | k8s-node、containerd 1c4g |
VIP: 192.168.31.111 域名:apiserver.frps.cn
- apiserver.frps.cn:6443 为VIP
- kube-apiserver 三台节点
- kube-schedulet 三台节点
- kube-controller-manager 三台节点
- ETCD 三台节点
服务版本
服务名称 | 版本号 |
---|---|
内核 | 5.14.3-1.el7.elrepo.x86_64 |
containerd | v1.6.4 |
ctr | v1.6.4 |
k8s | 1.24 |
初始化环境
初始化环境需要全部节点都执行
我这里密码为123456,请根据需求自行更改
所有节点关闭Selinux、iptables、swap分区
所有节点配置yum源
新安装的服务器可以安装下面的软件包,可以解决99%的依赖问题
由于开启内核 ipv4 转发需要加载 br_netfilter 模块,所以加载下该模块:
将上面的命令设置成开机启动,因为重启后模块失效,下面是开机自动加载模块的方式。首先新建 /etc/rc.sysinit 文件,内容如下所示:
然后在/etc/sysconfig/modules/目录下新建如下文件:
增加权限
然后重启后,模块就可以自动加载了
优化内核参数
bridge-nf 使得netfilter可以对Linux网桥上的 IPv4/ARP/IPv6 包过滤。比如,设置net.bridge.bridge-nf-call-iptables=1后,二层的网桥在转发包时也会被 iptables的 FORWARD 规则所过滤。常用的选项包括:
net.bridge.bridge-nf-call-arptables:是否在 arptables 的 FORWARD 中过滤网桥的 ARP 包
net.bridge.bridge-nf-call-ip6tables:是否在 ip6tables 链中过滤 IPv6 包
net.bridge.bridge-nf-call-iptables:是否在 iptables 链中过滤 IPv4 包
net.bridge.bridge-nf-filter-vlan-tagged:是否在 iptables/arptables 中过滤打了 vlan 标签的包。
所有节点安装ipvs
为什么要使用IPVS,从k8s的1.8版本开始,kube-proxy引入了IPVS模式,IPVS模式与iptables同样基于Netfilter,但是采用的hash表,因此当service数量达到一定规模时,hash查表的速度优势就会显现出来,从而提高service的服务性能。
ipvs依赖于nf_conntrack_ipv4内核模块,4.19包括之后内核里改名为nf_conntrack,1.13.1之前的kube-proxy的代码里没有加判断一直用的nf_conntrack_ipv4,好像是1.13.1后的kube-proxy代码里增加了判断,我测试了是会去load nf_conntrack使用ipvs正常
所有节点安装ipset
ipset介绍
iptables是Linux服务器上进行网络隔离的核心技术,内核在处理网络请求时会对iptables中的策略进行逐条解析,因此当策略较多时效率较低;而是用IPSet技术可以将策略中的五元组(协议,源地址,源端口,目的地址,目的端口)合并到有限的集合中,可以大大减少iptables策略条目从而提高效率。测试结果显示IPSet方式效率将比iptables提高100倍
- 为了方面ipvs管理,这里安装一下ipvsadm。
所有节点设置系统时区
升级内核 (可选方案)
接下来更新一下软件包版本
Containerd 安装
在安装containerd前,我们需要优先升级libseccomp
在centos7中yum下载libseccomp的版本是2.3的,版本不满足我们最新containerd的需求,需要下载2.4以上的
Containerd需要在所有节点升级安装
下载安装containerd
github地址:https://containerd.io/downloads/
Containerd安装我们使用1.6.4版本号
containerd-1.6.4-linux-amd64.tar.gz 只包含containerd
cri-containerd-cni-1.6.4-linux-amd64.tar.gz 包含containerd以及cri runc等相关工具包,建议下载本包
- 工具包文件如下
上面的文件都是二进制文件,直接移动到对应的目录并配置好环境变量就可以进行使用了。
如果我们机器上通过yum安装docker了,可以用下面的命令进行卸载
接下来我们为每台服务器配置Containerd
替换默认pause镜像地址
- 默认情况下k8s.gcr.io无法访问,所以使用我提供的阿里云镜像仓库地址即可
配置systemd作为容器的cgroup driver
Containerd官方操作手册
默认cri-containerd-cni包中会有containerd启动脚本,我们已经解压到对应的目录,可以直接调用启动
ctr在我们解压包中已经附带了,直接可以使用
设置crictl
api-server 高可用部署 (单master可跳过)
nginx代理后端3台apiserver,所以需要在每台apiserver中安装nginx。keeplived起到vip的作用
需要在master节点安装
安装nginx
为了方便后面扩展插件,我这里使用编译安装nginx
检查服务是否启动
修改nginx配置文件
配置Keeplived
前面我们也说了,高可用方案需要一个VIP,供集群内部访问
修改配置文件
- router_id 节点IP
- mcast_src_ip 节点IP
- virtual_ipaddress VIP
请根据自己IP实际上情况修改
启动keepalived
测试vip是否正常
Kubeadm 安装配置
首先我们需要在k8s-01配置kubeadm源
下面kubeadm操作只需要在k8s-01上即可
国内源
- packages.cloud.google.com这里懂的都懂,下面改成阿里云源
k8s-01节点安装kubeadm和master相关依赖组建
配置kubeadm文件
这里我们在k8s-01上配置打印init默认配置信息
虽然kubeadm作为etcd节点的管理工具,但请注意kubeadm不打算支持此类节点的证书轮换或升级。长期计划是使用etcdadm来工具来进行管理。
因为我这里要做集群,请根据我这里的配置按需修改
检查配置文件是否有错误
正确如下
查看所需镜像列表
预先拉取镜像
接下来开始初始化
初始化完成
记住init后打印的token,复制kubectl的kubeconfig,kubectl的kubeconfig路径默认是~/.kube/config
初始化的配置文件为保存在configmap里面
接下来执行kubectl就可以看到node了
Master节点配置(单节点跳过)
前面我们已经为所有master节点配置了一下服务
- nginx
- keeplived
- containerd
接下来只需要给其它master节点安装k8s组件
安装相关组件
启动kubelet
master执行添加节点
设置kubectl config文件
目前我们3台master节点已经添加完毕
Node节点配置
node节点安装kubeadm
安装相关组件
添加join命令
如果我们后续需要添加node节点时,可以到k8s-01节点执行下面的命令获取token相关信息
如果我们添加某台节点异常了,修改后可以执行下面的命令,然后在重新join加入集群
验证所有服务器是否添加到集群中
网络配置
这个时候其实集群还不能正常使用,因为还没有安装网络插件,接下来安装网络插件,可以在文档 https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/ 中选择我们自己的网络插件。
安装 flannel
根据需求修改网卡配置,我这里以eth0为主
温馨提示: 在kubeadm.yaml文件中设置了podSubnet网段,同时在flannel中网段也要设置相同的。 (我这里默认就是相同的配置)
执行
接下来我们所有的pod都可以正常运行了
安装配置calico网络插件(与flannel只选其一)
下载部署文件:
执行:
验证结果
验证集群
等kube-system命名空间下的Pod都为Running,这里先测试一下dns是否正常
创建Pod后我们进行检查
使用nslookup查看是否能返回地址
测试nginx svc以及Pod内部网络通信是否正常
访问宿主机nodePort端口
Kubernetes kubectl 命令自动补全
评论区