网站打开不了怎样做,营销策划好的网站,seo关键字优化,中企动力和东莞朝阳做的网站对比本文档主要根据k8s官网文档和其插件的官网文档#xff0c;参考部分他人优秀经验#xff0c;在实际操作中逐渐完成#xff0c;比较详尽#xff0c;适合在境内学习者和实践者参考。 实操环境基于VMware Workstation 17 pro#xff0c;采用ubuntu22.04操作系统#xff08;有…本文档主要根据k8s官网文档和其插件的官网文档参考部分他人优秀经验在实际操作中逐渐完成比较详尽适合在境内学习者和实践者参考。 实操环境基于VMware Workstation 17 pro采用ubuntu22.04操作系统有时也提到rhel系列系统采用kubeadm1.27.4部分地方提到了1.28部署和初始化集群采用IPVS做为负载均衡和网络转发采用containerd1.7.3做为容器运行时选择calico作为k8s的Pod网络组件采用插件Dashboard做为Web控制台界面采用PrometheusGrafana做为监控组件。 文档涉及面广虽反复斟酌也难免疏漏甚至错误欢迎指正。
[基于Ubuntu22.04部署生产级K8S集群v1.27]系列文档(陆续发布中…) 基于Ubuntu22.04部署生产级K8S集群v1.27(规划和核心组件部署篇) 基于Ubuntu22.04部署生产级K8S集群v1.27(包管理器Helm3) 基于Ubuntu22.04部署生产级K8S集群v1.27(网络模型和Calico) 基于Ubuntu22.04部署生产级K8S集群v1.27(集群管理kubectl) 基于Ubuntu22.04部署生产级K8S集群v1.27(日志架构) 基于Ubuntu22.04部署生产级K8S集群v1.27(集群弹性-Master高可用和etcd集群) 基于Ubuntu22.04部署生产级K8S集群v1.27(服务发现CoreDNS) 基于Ubuntu22.04部署生产级K8S集群v1.27(仪表板和Dashboard) 基于Ubuntu22.04部署生产级K8S集群v1.27(持久卷) 基于Ubuntu22.04部署生产级K8S集群v1.27(集群监控PrometheusGrafana) 文章目录 Kubernetes生产级集群规划和核心组件部署参考文档在哪里使用k8s生产环境考量大规模集群的注意事项集群资源规划和网络规划 安装集群核心组件宿主机系统必要的初始配置宿主机配置ubuntu安装过程更换国内镜像源常用软件包安装暂时关闭防火墙禁用SELINUX时区设置和时间同步设备主机名k8s集群master和worker节点主机名修改修改master 节点的主机名修改节点名称修改主机名总结 安装kubeadm准备工作准备工作的具体指令参考配置服务器支持开启ipvs的前提条件 安装容器运行时转发 IPv4 并让 iptables 看到桥接流量cgroup 驱动CRI 版本支持安装containerd做为容器运行时containerd的配置镜像加速配置加载containerd的内核模块测验containerdcrictl手动操作容器运行时containerd使用 containerd 作为 CRI 运行时的必要步骤 安装kubeadm、kubelet、kubectl 使用 kubeadm 创建集群主机准备准备所需的容器镜像可选初始化控制平面节点 开始使用集群前的操作添加节点 重新配置 kubeadm 集群应用集群配置更改应用 kubelet 配置更改应用 kube-proxy 配置更改应用 CoreDNS 配置更改 卸载集群删除节点清理控制平面如何安全地清空一个节点扩展 有关 kubeadm init 参数的更多信息 Kubernetes生产级集群规划和核心组件部署
一些k8s概念未在本文阐述官方文档比较详尽但初学者仍然可能比较迷茫第三方文档也比较多主要就靠积累了将来也准备单独整理一篇通俗易懂的文档。 如果k8s各组件、概念还不清建议先花上20~40小时以上来熟悉否则直接部署可能更加云里雾里徒增烦恼。 本文提到的“生产级”是相对于开发环境来讲的可以直接应用于生产环境考虑到信息安全规划虽基于生产环境实操部分则参照模拟环境的部署写作。
参考文档
重点参考官方文档https://kubernetes.io/zh-cn/docs/home/ 也参考了一些其它文档在本文中均有出处体现。 可以说网上每三方任何文档都无法超越官方文档本文也只能朝着“尽快规划和部署生产级集群”的目标大量引用官方文档的内容或地址做一些更简易直接的说明官方的部分阐述实在精要缺之恐误事就尽量引用稍加整理同时提供部署的实践经验。
在哪里使用k8s
你可以下载 Kubernetes在本地机器、云或你自己的数据中心上部署 Kubernetes 集群。 诸如 kube-apiserver 或 kube-proxy 等某些 Kubernetes 组件可以在集群中以容器镜像部署。 建议尽可能将 Kubernetes 组件作为容器镜像运行并且让 Kubernetes 管理这些组件。 但是运行容器的相关组件 —— 尤其是 kubelet不在此列。
如果你不想自己管理 Kubernetes 集群则可以选择托管服务包括经过认证的平台。
对于你自己管理的集群官方支持的用于部署 Kubernetes 的工具是 kubeadm。 安装kubeadm参考https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
本文部署基于ubuntu22.04尽可能将 Kubernetes 组件作为容器镜像运行。
生产环境考量
官文https://kubernetes.io/zh-cn/docs/setup/production-environment/ 官文中提到了以下这里略 可用性 规模 安全性与访问管理
大规模集群的注意事项
官文https://kubernetes.io/zh-cn/docs/setup/best-practices/cluster-large/ 部分关键信息如下 Kubernetes v1.28 单个集群支持的最大节点数为 5,000。 更具体地说Kubernetes 旨在适应满足以下所有标准的配置 每个节点的 Pod 数量不超过 110 节点数不超过 5,000 Pod 总数不超过 150,000 容器总数不超过 300,000
其它 增加云资源的配额。 应该在每个故障区域至少应运行一个控制平面实例以提供容错能力。 Kubernetes 节点不会自动将流量引向相同故障区域中的控制平面端点。 但是你的云供应商可能有自己的机制来执行此操作。 为了提高大规模集群的性能你可以将事件对象存储在单独的专用 etcd 实例中。 对插件资源设置CPU和内存等限制。插件的默认限制通常基于从中小规模 Kubernetes 集群上运行每个插件的经验收集的数据。 插件在大规模集群上运行时某些资源消耗常常比其默认限制更多。 如果在不调整这些值的情况下部署了大规模集群则插件可能会不断被杀死因为它们不断达到内存限制。 或者插件可能会运行但由于 CPU 时间片的限制而导致性能不佳。
集群资源规划和网络规划
参考https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/plan-cidr-blocks-for-an-ack-cluster-1 阿里云ACK Kubernetes集群网络规划 一般性业务小于100个节点 Terway Pod独占模式或IPVlan模式的IP分配示例 专有网络网段 192.168.0.0/16 虚拟交换机网段 192.168.0.0/19 Pod虚拟交换机网段 192.168.32.0/19 最大可分配Pod地址数 8192 Service CIDR网段 172.21.0.0/20 最大可分配Service地址数4094
可以看出Service的地址数一般是小于Pod地址数的而kubeadm.yaml中serviceSubnet默认prefixlen是/121048576个百万多对一般性业务来讲这个数字太大了。
参考https://blog.csdn.net/QW_sunny/article/details/122495071 关于PodSubnet在kubeadm初始化时的配置 podSubnet至少要包含14个IP地址。
实践中参考官文“大规模集群的注意事项”、“阿里云ACK Kubernetes集群网络规划”以及默认配置考虑到pod数量应当做好规划大部分场景下单个集群的node数量可规划在100个左右pod数量1万个但为了便于记忆可以直接规划为65536个prefixlen为/16。 配置可像下面这样 networking: podSubnet: 172.28.0.0/16 serviceSubnet: 172.29.0.0/16
Calico插件在初始化时注意calico.yaml中的CALICO_IPV4POOL_CIDR配置应该和kubeadm.yaml中podSubnet配置一样
安装集群核心组件
宿主机系统必要的初始配置
这里讲的宿主机是运行k8s集群的操作系统主机即可以是vmware虚拟机、物理机或云主机我们这里是vmware虚拟机ubuntu22.04。
宿主机配置
官文中提到了安装kubeadm最低配置是2核2G。 控制平面2核4G至少1台 每台节点2核2G共2台 每台宿主机磁盘推荐40G以上。
ubuntu安装过程
省略 安装过程建议不要分配swap它会造成kubelet不能正常工作即使分配了也必须删除或关闭。 做好必要的初始配置和安全基线加固未来将准备一篇专门的文档来做这部分工作
更换国内镜像源
vi /etc/apt/sources.list
# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://mirrors.aliyun.com/ubuntu jammy main restricted
# deb-src http://mirrors.aliyun.com/ubuntu jammy main restricted## Major bug fix updates produced after the final release of the
## distribution.
deb http://mirrors.aliyun.com/ubuntu jammy-updates main restricted
# deb-src http://mirrors.aliyun.com/ubuntu jammy-updates main restricted## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://mirrors.aliyun.com/ubuntu jammy universe
# deb-src http://mirrors.aliyun.com/ubuntu jammy universe
deb http://mirrors.aliyun.com/ubuntu jammy-updates universe
# deb-src http://mirrors.aliyun.com/ubuntu jammy-updates universe## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://mirrors.aliyun.com/ubuntu jammy multiverse
# deb-src http://mirrors.aliyun.com/ubuntu jammy multiverse
deb http://mirrors.aliyun.com/ubuntu jammy-updates multiverse
# deb-src http://mirrors.aliyun.com/ubuntu jammy-updates multiverse## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://mirrors.aliyun.com/ubuntu jammy-backports main restricted universe multiverse
# deb-src http://mirrors.aliyun.com/ubuntu jammy-backports main restricted universe multiversedeb http://mirrors.aliyun.com/ubuntu jammy-security main restricted
# deb-src http://mirrors.aliyun.com/ubuntu jammy-security main restricted
deb http://mirrors.aliyun.com/ubuntu jammy-security universe
# deb-src http://mirrors.aliyun.com/ubuntu jammy-security universe
deb http://mirrors.aliyun.com/ubuntu jammy-security multiverse
# deb-src http://mirrors.aliyun.com/ubuntu jammy-security multiversesudo apt update
常用软件包安装
sudo apt-get install vim wget netstat curl inetutils-ping telnet lrzsz
暂时关闭防火墙
sudo ufw status # ufw如果安装了查看当前的防火墙状态inactive状态是防火墙关闭状态 active是开启状态。 sudo ufw enable | disable # 启动、关闭防火墙
禁用SELINUX
sudo setenforce 0 sudo vim /etc/selinux/config 修改如下 SELINUXdisabled
时区设置和时间同步
sudo cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 配置好时间同步vmware虚拟机建议安装好VMwareTools可设置好时间和宿主机同步即使宿主机休眠也不影响虚拟机的时间。 其它场景可配置好NTP时间同步 时间不同步会出error
设备主机名
在/etc/hosts中添加下列解析例 192.168.130.88 k8smaster.loadbalancer.local 192.168.130.88 k8smaster01 192.168.130.89 k8snode001 192.168.130.90 k8snode002 部署集群前配置好主机名是必要的部署好之后再来改就很麻烦了。 修改系统主机名执行下面的命令包括会自动修改/etc/hostname中的内容以控制平面的为例 hostnamek8smaster01 sudo hostnamectl set-hostname $hostname sudo hostnamectl set-hostname $hostname --pretty sudo hostnamectl set-hostname $hostname --static sudo hostnamectl set-hostname $hostname --transient
简要关系图
k8s集群master和worker节点主机名修改
修改master 节点的主机名
不建议修改 master 节点的主机名因为 Kubernetes 集群中的许多组件都会使用主机名来进行通信和识别。 如果您修改了 master 节点的主机名可能会导致某些组件无法正常工作从而影响整个集群的健康状态。 如果您确实需要修改主机名建议在修改前备份好相关配置文件并且在修改后进行全面的测试和验证。
证书签发也跟主机名有关。 在 Kubernetes 集群中每个节点都需要使用 TLS 证书来进行安全通信。 这些证书通常会包含节点的主机名信息用于验证通信的身份。 如果您修改了节点的主机名可能会导致证书无法正常验证从而影响节点间的安全通信。 因此在修改节点主机名时还需要相应地更新证书信息以确保节点间的安全通信能够正常工作。 openssl x509 -noout -text -in /etc/kubernetes/pki/apiserver.crt
修改节点名称
参考https://blog.csdn.net/weixin_33858485/article/details/92386452 k8s集群修改节点和master的hostname之后需要如何调整 修改节点名称还要修改calico服务中的主机名
修改主机名总结
从以上分享的经验来看无论是修改master还是worker节点主机名都是非常麻烦的如果是生产环境不建议修改如果是初始部署的实验环境或者不必保留数据的集群最直接的办法就是按照“清理节点”的步骤清理后再重新初始化节点重建集群。
综上鉴于修改主机名的困难应该在创建集群时就把主机名规划好配置好。
安装kubeadm
准备工作
参考https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm/ 一台兼容的 Linux 主机。Kubernetes 项目为基于 Debian 和 Red Hat 的 Linux 发行版以及一些不提供包管理器的发行版提供通用的指令。 每台机器 2 GB 或更多的 RAM如果少于这个数字将会影响你应用的运行内存。 CPU 2 核心及以上。 集群中的所有机器的网络彼此均能相互连接公网和内网都可以。 节点之中不可以有重复的主机名、MAC 地址或 product_uuid。 开启机器上的某些端口。 禁用交换分区。为了保证 kubelet 正常工作你必须禁用交换分区。例如sudo swapoff -a 将暂时禁用交换分区。要使此更改在重启后保持不变请确保在如 /etc/fstab、systemd.swap 等配置文件中禁用交换分区具体取决于你的系统如何配置。
准备工作的具体指令参考
确保每个节点上 MAC 地址和 product_uuid 的唯一性 你可以使用命令 ip link 或 ifconfig -a 来获取网络接口的 MAC 地址 可以使用 sudo cat /sys/class/dmi/id/product_uuid 命令对 product_uuid 校验 一般来讲硬件设备会拥有唯一的地址但是有些虚拟机的地址可能会重复。 Kubernetes 使用这些值来唯一确定集群中的节点。 如果这些值在每个节点上不唯一可能会导致安装失败。
禁用所有swap交换分区 sudo swapoff -a
了解端口和协议 当你在一个有严格网络边界的环境里运行 Kubernetes例如拥有物理网络防火墙或者拥有公有云中虚拟网络的自有数据中心 了解 Kubernetes 组件使用了哪些端口和协议是非常有用的。 官文https://kubernetes.io/zh-cn/docs/reference/networking/ports-and-protocols/ 控制面Master 协议 方向 端口范围 目的 使用者 TCP 入站 6443 Kubernetes API server 所有 TCP 入站 2379-2380 etcd server client API kube-apiserver, etcd TCP 入站 10250 Kubelet API 自身, 控制面 TCP 入站 10259 kube-scheduler 自身 TCP 入站 10257 kube-controller-manager 自身
工作节点Worker node 协议 方向 端口范围 目的 使用者 TCP 入站 10250 Kubelet API 自身, 控制面 TCP 入站 30000-32767 NodePort Services默认端口范围 所有
可以使用 netcat 之类的工具来检查端口是否启用例如 nc 127.0.0.1 6443
配置服务器支持开启ipvs的前提条件
kube-proxy开启ipvs的前提需要加载以下的内核模块: ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntrack
sudo vi /etc/modules-load.d/ipvs.conf 添加上述模块 sudo modprobe – ip_vs sudo modprobe – ip_vs_rr sudo modprobe – ip_vs_wrr sudo modprobe – ip_vs_sh sudo modprobe – nf_conntrack lsmod | grep -e ip_vs -e nf_conntrack 接下来还需要确保各个节点上已经安装了ipset软件包为了便于查看ipvs的代理规则最好安装一下管理工具ipvsadm。 如果没有安装好ipvs相关模块则即使kube-proxy的配置开启了ipvs模式也会退回到iptables模式。
安装容器运行时
官文https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/ https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime
说明为什么要安装容器运行时 “容器运行时”Container Runtime是负责运行容器的软件以使 Pod 可以运行在上面。 默认情况下Kubernetes 使用 容器运行时接口Container Runtime InterfaceCRI 来与你所选择的容器运行时交互。 如果你不指定运行时kubeadm 会自动尝试通过扫描已知的端点列表来检测已安装的容器运行时。 如果检测到有多个或者没有容器运行时kubeadm 将抛出一个错误并要求你指定一个想要使用的运行时。 Docker Engine 没有实现 CRI 而这是容器运行时在 Kubernetes 中工作所需要的。 为此必须安装一个额外的服务 cri-dockerd。 cri-dockerd 是一个基于传统的内置 Docker 引擎支持的项目 它在 1.24 版本从 kubelet 中移除。 v1.24 之前的 Kubernetes 版本直接集成了 Docker Engine 的一个组件名为 dockershim。 这种特殊的直接整合不再是 Kubernetes 的一部分 这次删除被作为 v1.20 发行版本的一部分宣布。
容器运行时有下列 containerd 推荐 Dockershim 不推荐且k8s1.24开始弃用 CRI-O 推荐 cri-dockerd 不推荐 Mirantis
来了解一下Kubernetes、Docker、Dockershim、Containerd、runC、CRI、OCI的关系 参考https://zhuanlan.zhihu.com/p/630976577 CRI可以实现kubelet对containerd、CRI-O的统一管理。同时Kubernetes 1.24将dockershim 组件从 kubelet 中删除后也建议用户使用更加轻量的容器运行时 containerd 或 CRI-O。 虽然 dockershim 组件在 Kubernetes v1.24 发行版本中已被移除。不过来自第三方的替代品 cri-dockerd 可以适配器允许你通过 容器运行时接口Container Runtime InterfaceCRI 来使用 Docker Engine并不建议使用除非有特殊的需求。 对于Docker生成的镜像也并不受任何影响Docker 对镜像的构建是符合 OCI 标准的 (runC 也是 Docker 独立出去的)镜像适用于所有 CRI 容器运行时。
参考https://cloud.tencent.com/developer/article/1791730 有评论从我个人角度考虑的话我个人的选择是containerd他速度快配置方便相当可靠和安全不过 cri-o 已经支持 cgroupsv2 了所以如果我使用 fedora 或者 centos8 的话我会优先选择 cri-o。
本文档考虑containerd做为CRI。
转发 IPv4 并让 iptables 看到桥接流量
这是安装和配置容器运行时的先决条件
cat EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOFsudo modprobe overlay
sudo modprobe br_netfilter# 设置所需的 sysctl 参数参数在重新启动后保持不变
cat EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables 1
net.bridge.bridge-nf-call-ip6tables 1
net.ipv4.ip_forward 1
EOF# 应用 sysctl 参数而不重新启动
sudo sysctl --system通过运行以下指令确认 br_netfilter 和 overlay 模块被加载 lsmod | grep br_netfilter lsmod | grep overlay
通过运行以下指令确认 net.bridge.bridge-nf-call-iptables、net.bridge.bridge-nf-call-ip6tables 和 net.ipv4.ip_forward 系统变量在你的 sysctl 配置中被设置为 1
cgroup 驱动
容器运行时的驱动位于最底层 在 Linux 上控制组CGroup用于限制分配给进程的资源。 kubelet 和底层容器运行时都需要对接控制组来强制执行 为 Pod 和容器管理资源 并为诸如 CPU、内存这类资源设置请求和限制。若要对接控制组kubelet 和容器运行时需要使用一个 cgroup 驱动。 关键的一点是 kubelet 和容器运行时需使用相同的 cgroup 驱动并且采用相同的配置。 可用的 cgroup 驱动有两个 cgroupfs systemd 当 systemd 是初始化系统时 不 推荐使用 cgroupfs 驱动因为 systemd 期望系统上只有一个 cgroup 管理器。 使用 cgroup v2 则应用 systemd cgroup 驱动取代 cgroupfs 要将 systemd 设置为 cgroup 驱动需编辑 KubeletConfiguration 的 cgroupDriver 选项并将其设置为 systemd。例如
apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration … cgroupDriver: systemd
说明从 v1.22 开始在使用 kubeadm 创建集群时如果用户没有在 KubeletConfiguration 下设置 cgroupDriver 字段kubeadm 默认使用 systemd。
如果你将 systemd 配置为 kubelet 的 cgroup 驱动你也必须将 systemd 配置为容器运行时的 cgroup 驱动。
CRI 版本支持
你的容器运行时必须至少支持 v1alpha2 版本的容器运行时接口。
Kubernetes 从 1.26 版本开始仅适用于 v1 版本的容器运行时CRIAPI。早期版本默认为 v1 版本 但是如果容器运行时不支持 v1 版本的 API 则 kubelet 会回退到使用已弃用的v1alpha2 版本的 API。
安装containerd做为容器运行时
containerd官网地址https://github.com/containerd/containerd/blob/main/docs/getting-started.md containerd官网提供了多种安装方式
选项一二进制包安装 ubuntu和rhel系可以用二进制包安装其它系统可用源码包安装下面是二进制安装
Step 1: Installing containerd 下载地址https://github.com/containerd/containerd/releases wget https://github.com/containerd/containerd/releases/download/v1.7.3/containerd-1.7.3-linux-amd64.tar.gz sudo tar Cxzvf /usr/local containerd-1.7.3-linux-amd64.tar.gz
If you intend to start containerd via systemd, you should also download the containerd.service unit file from https://raw.githubusercontent.com/containerd/containerd/main/containerd.service into /usr/local/lib/systemd/system/containerd.service, and run the following commands: wget https://raw.githubusercontent.com/containerd/containerd/main/containerd.service sudo mv containerd.service /usr/lib/systemd/system/ # ubuntu是这个路径rhel系是官文中提到的路径 sudo systemctl daemon-reload sudo systemctl enable --now containerd systemctl status containerd
Step 2: Installing runc curl -LO https://github.com/opencontainers/runc/releases/download/v1.1.8/runc.amd64 sudo install -m 755 runc.amd64 /usr/local/sbin/runc The binary is built statically and should work on any Linux distribution.
Step 3: Installing CNI plugins wget https://github.com/containernetworking/plugins/releases/download/v1.3.0/cni-plugins-linux-amd64-v1.3.0.tgz sudo tar Cxzvf /opt/cni/bin cni-plugins-linux-amd64-v1.3.0.tgz The binaries are built statically and should work on any Linux distribution.
选项二deb或dnl安装 The containerd.io packages in DEB and RPM formats are distributed by Docker (not by the containerd project). See the Docker documentation https://docs.docker.com/engine/install/ubuntu/ https://docs.docker.com/engine/install/centos/ 就是deb或rpm包安装docker环境的过程中就可以顺便装上了containerd.io很快例如 先有一些卸载老包的步骤然后
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod ar /etc/apt/keyrings/docker.gpg
echo \deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \$(. /etc/os-release echo $VERSION_CODENAME) stable | \
sudo tee /etc/apt/sources.list.d/docker.list /dev/null
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world经验如果按二进制包安装了再通过dnl或yum安装会有提示容器运行时保持当前配置/etc/containerd/config.toml还是安装配置为了稳定一般选择之前的配置即当前配置。
containerd的配置
修改containerd的配置其中containerd默认从k8s官网拉取镜像几乎不会成功需变更为境内源。
sudo mkdir -p /etc/containerd #创建一个目录用于存放containerd的配置文件 containerd config default | sudo tee /etc/containerd/config.toml #把containerd配置导出到文件 sudo vim /etc/containerd/config.toml #修改配置文件 [plugins.“io.containerd.grpc.v1.cri”] … sandbox_image “registry.aliyuncs.com/google_containers/pause:3.9” #搜索sandbox_image把原来的registry.k8s.io/pause:3.8改为registry.aliyuncs.com/google_containers/pause:3.9 [plugins.“io.containerd.grpc.v1.cri”.containerd.runtimes.runc.options] … SystemdCgroup true #搜索SystemdCgroup把这个false改为true
[plugins.“io.containerd.grpc.v1.cri”.registry] config_path “/etc/containerd/certs.d” #搜索config_path配置镜像加速地址这是一个目录下面创建
镜像加速配置
创建镜像加速的目录 sudo mkdir /etc/containerd/certs.d/docker.io -pv
#配置加速 sudo cat /etc/containerd/certs.d/docker.io/hosts.toml \EOF server “https://docker.io” [host.“https://xxx.mirror.aliyuncs.com”] capabilities [“pull”, “resolve”] EOF 最好检查一下hosts.toml的实际内容其中xxx.mirror.aliyuncs.com在aliyun.com上面申请。
加载containerd的内核模块
如果/etc/modules-load.d/k8s.conf中配置了不必再重复配置 cat EOF | sudo tee /etc/modules-load.d/containerd.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter
#重启containerd sudo systemctl restart containerd systemctl status containerd
测验containerd
拉取镜像测试containerd是否能创建和启动成功 说明ctr命令是containerd CLI类似于docker命令但又不是docker的命令。containerd和cri-docker是不同的容器运行时。 sudo ctr i pull docker.io/library/nginx:alpine # 能正常拉取镜像说明没啥问题 sudo ctr images ls # 查看镜像 sudo ctr c create --net-host docker.io/library/nginx:alpine nginx # 创建容器 sudo ctr task start -d nginx # 启动容器正常说明containerd没啥问题 sudo ctr containers ls # 查看容器 sudo ctr tasks kill -s SIGKILL nginx # 终止容器 sudo ctr containers rm nginx # 删除容器
crictl手动操作容器运行时containerd
containerd 也有类似 docker 的 CLI 工具改为 crictl pull 也可以拉镜像参数比ctr更多。如果能操作节点是可以在每个节点上都提前拉取镜像然后配置 imagePullPolicy为IfNotPresent。 官文https://kubernetes.io/zh-cn/docs/concepts/containers/images/#using-a-private-registry
如果系统中存在多个容器运行时需要先配置 vi /etc/crictl.yaml 内容如下
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: false使用 containerd 作为 CRI 运行时的必要步骤
如果你从软件包例如RPM 或者 .deb中安装 containerd你可能会发现其中默认禁止了 CRI 集成插件。 你需要启用 CRI 支持才能在 Kubernetes 集群中使用 containerd。 要确保 cri 没有出现在 /etc/containerd/config.toml 文件中 disabled_plugins 列表内。如果你更改了这个文件也请记得要重启 containerd。 如果你在初次安装集群后或安装 CNI 后遇到容器崩溃循环则随软件包提供的 containerd 配置可能包含不兼容的配置参数。考虑按照 getting-started.md 中指定的 containerd config default /etc/containerd/config.toml 重置 containerd 配置然后相应地设置上述配置参数。 如果你应用此更改请确保重新启动 containerd sudo systemctl restart containerd
安装kubeadm、kubelet、kubectl
你需要在每台机器上安装以下的软件包 kubeadm用来初始化集群的指令。 kubelet在集群中的每个节点上用来启动 Pod 和容器等。 kubectl用来与集群通信的命令行工具。 kubeadm 不能帮你安装或者管理 kubelet 或 kubectl 所以你需要确保它们与通过 kubeadm 安装的控制平面的版本相匹配。 如果不这样做则存在发生版本偏差的风险可能会导致一些预料之外的错误和问题。 然而控制平面与 kubelet 之间可以存在一个次要版本的偏差但 kubelet 的版本不可以超过 API 服务器的版本。 例如1.7.0 版本的 kubelet 可以完全兼容 1.8.0 版本的 API 服务器反之则不可以。
更新 apt 包索引并安装使用 Kubernetes apt 仓库所需要的包 sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl
下载 Google Cloud 公开签名秘钥 curl -fsSL https://dl.k8s.io/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg 或 curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add
添加 Kubernetes apt 仓库
echo deb [signed-by/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main | sudo tee /etc/apt/sources.list.d/kubernetes.list或
echo deb [signed-by/etc/apt/keyrings/kubernetes-archive-keyring.gpg] http://mirrors.ustc.edu.cn/kubernetes/apt kubernetes-xenial main | sudo tee /etc/apt/sources.list.d/kubernetes.list或
echo deb [signed-by/etc/apt/keyrings/kubernetes-archive-keyring.gpg] http://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial main | sudo tee /etc/apt/sources.list.d/kubernetes.listsudo apt-get update sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl # 锁定版本 kubectl kubectl version --short
输出 Client Version: v1.27.4 Kustomize Version: v5.0.1
kubeadm token list
sudo systemctl enable kubelet.service # 如果开启了swap就会报错
使用 kubeadm 创建集群
https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/ 使用 kubeadm你能创建一个符合最佳实践的最小化 Kubernetes 集群。 事实上你可以使用 kubeadm 配置一个通过 Kubernetes 一致性测试的集群。 kubeadm 还支持其他集群生命周期功能 例如启动引导令牌和集群升级。
你可以在各种机器上安装和使用 kubeadm笔记本电脑 一组云服务器
本节目标
安装单个控制平面的 Kubernetes 集群在集群上安装 Pod 网络以便你的 Pod 可以相互连通
主机准备
在所有主机上安装 容器运行时 和 kubeadm
准备所需的容器镜像可选
这个步骤是可选的只适用于你希望 kubeadm init 和 kubeadm join 不去下载存放在 registry.k8s.io 上的默认的容器镜像的情况。 当你在离线的节点上创建一个集群的时候Kubeadm 有一些命令可以帮助你预拉取所需的镜像。 阅读离线运行 kubeadm 获取更多的详情。 Kubeadm 允许你给所需要的镜像指定一个自定义的镜像仓库。 阅读使用自定义镜像 获取更多的详情。
初始化控制平面节点
控制平面节点是运行控制平面组件的机器 包括 etcd集群数据库 和 API 服务器 命令行工具 kubectl 与之通信。
推荐如果计划将单个控制平面 kubeadm 集群升级成高可用 你应该指定 --control-plane-endpoint 为所有控制平面节点设置共享端点。 端点可以是负载均衡器的 DNS 名称或 IP 地址。kubeadm 不支持将没有 --control-plane-endpoint 参数的单个控制平面集群转换为高可用性集群。选择一个 Pod 网络插件并验证是否需要为 kubeadm init 传递参数。 根据你选择的第三方网络插件你可能需要设置 --pod-network-cidr 的值。 请参阅安装 Pod 网络附加组件。可选kubeadm 试图通过使用已知的端点列表来检测容器运行时。 使用不同的容器运行时或在预配置的节点上安装了多个容器运行时请为 kubeadm init 指定 --cri-socket 参数。 请参阅安装运行时。可选除非另有说明否则 kubeadm 使用与默认网关关联的网络接口来设置此控制平面节点 API server 的广播地址。 要使用其他网络接口请为 kubeadm init 设置 --apiserver-advertise-address 参数。 要部署使用 IPv6 地址的 Kubernetes 集群 必须指定一个 IPv6 地址例如 --apiserver-advertise-address2001:db8::101。
结合一份配置文件来使用 kubeadm init 官文https://kubernetes.io/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file 通过一份配置文件而不是使用命令行参数来配置 kubeadm init 命令是可能的 但是一些更加高级的功能只能够通过配置文件设定。 先打印集群初始化默认的使用的配置在此基础上定制新的kubeadm.yaml kubeadm config print init-defaults --component-configs KubeletConfiguration ~/kubeadm.yaml
其中 name 需要变更为master的名称例如k8smaster01 advertiseAddress需要替换master节点IP criSocket是cri的套接字containerd是unix:///var/run/containerd/containerd.sock imageRepository是镜像源registry.k8s.io这个源要可换成阿里的registry.aliyuncs.com/google_containers cgroupDriver设置kubelet的cgroupDriver为systemd clusterDNS的IP以0.10结尾为佳不然初始化过程中也会有提示指定另一个IP也未尝不可但未实践过还是尽量听程序的建议吧。 networking的podSubnet: 172.28.0.0/16serviceSubnet: 172.29.0.0/16。 controlPlaneEndpoint就是创建多个控制面板所必要的参数设为k8smaster.loadbalancer.local:6443
设置kube-proxy代理模式为ipvs追加如下
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs关于kubeadm配置的更多帮助见官文https://kubernetes.io/zh-cn/docs/reference/config-api/kubeadm-config.v1beta3/
k8s1.27.4一次完整的kubeadm.yaml内容
apiVersion: kubeadm.k8s.io/v1beta3
bootstrapTokens:
- groups:- system:bootstrappers:kubeadm:default-node-tokentoken: abcdef.0123456789abcdefttl: 24h0m0susages:- signing- authentication
kind: InitConfiguration
localAPIEndpoint:advertiseAddress: 192.168.130.88bindPort: 6443
nodeRegistration:criSocket: unix:///var/run/containerd/containerd.sockimagePullPolicy: IfNotPresentname: k8smaster01taints: null
---
apiServer:timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta3
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controllerManager: {}
dns: {}
etcd:local:dataDir: /var/lib/etcd
imageRepository: registry.aliyuncs.com/google_containers
kind: ClusterConfiguration
kubernetesVersion: 1.27.0
networking:dnsDomain: cluster.localpodSubnet: 172.28.0.0/16serviceSubnet: 172.29.0.0/16
controlPlaneEndpoint: k8smaster.loadbalancer.local:6443
scheduler: {}
---
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:anonymous:enabled: falsewebhook:cacheTTL: 0senabled: truex509:clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:mode: Webhookwebhook:cacheAuthorizedTTL: 0scacheUnauthorizedTTL: 0s
cgroupDriver: systemd
clusterDNS:
- 172.29.0.10
clusterDomain: cluster.local
containerRuntimeEndpoint:
cpuManagerReconcilePeriod: 0s
evictionPressureTransitionPeriod: 0s
fileCheckFrequency: 0s
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 0s
imageMinimumGCAge: 0s
kind: KubeletConfiguration
logging:flushFrequency: 0options:json:infoBufferSize: 0verbosity: 0
memorySwap: {}
nodeStatusReportFrequency: 0s
nodeStatusUpdateFrequency: 0s
resolvConf: /run/systemd/resolve/resolv.conf
rotateCertificates: true
runtimeRequestTimeout: 0s
shutdownGracePeriod: 0s
shutdownGracePeriodCriticalPods: 0s
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs这里定制了imageRepository为阿里云的registry避免因gcr被墙无法直接拉取镜像。criSocket设置了容器运行时为containerd。 同时设置kubelet的cgroupDriver为systemd设置kube-proxy代理模式为ipvs。
集群初始化完成后可查看到kube-proxy代理模式 参考https://blog.csdn.net/wy_hhxx/article/details/119858961 kubectl get pod -n kube-system # 查看kube-proxy的Name kubectl logs kube-proxy-6vfqw -n kube-system # 根据刚才查到的kube-proxy的Name查询其日志 在日志中可以看到用的ipvs还是iptables。
在开始初始化集群之前可以使用kubeadm config images pull --config kubeadm.yaml预先在各个服务器节点上拉取所k8s需要的容器镜像。 sudo kubeadm config images pull --config kubeadm.yaml
接下来使用kubeadm初始化集群执行下面的命令 sudo kubeadm init --config kubeadm.yaml --control-plane-endpoint“k8smaster.loadbalancer.local:6443” --upload-certs 这里使用了–control-plane-endpoint是为了将来可以升级为高可用集群即多个控制平面如果在配置文件中配置了这里就不必使用了如下 sudo kubeadm init --config kubeadm.yaml --upload-certs 创建高可用集群参考官文https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/high-availability/ 将会整理文档[基于Ubuntu22.04部署生产级K8S集群v1.27(集群弹性-Master高可用和etcd集群)]
根据输出的内容基本上可以看出手动初始化安装一个Kubernetes集群所需要的关键步骤。 其中有以下关键内容
[certs]生成相关的各种证书 [kubeconfig]生成相关的kubeconfig文件 [kubelet-start] 生成kubelet的配置文件/var/lib/kubelet/config.yaml [control-plane]使用/etc/kubernetes/manifests目录中的yaml文件创建apiserver、controller-manager、scheduler的静态pod [bootstraptoken]生成token记录下来后边使用kubeadm join往集群中添加节点时会用到 [addons]安装基本插件:CoreDNS, kube-proxy
成功后有下列提示
Your Kubernetes control-plane has initialized successfully!To start using your cluster, you need to run the following as a regular user:mkdir -p $HOME/.kubesudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/configsudo chown $(id -u):$(id -g) $HOME/.kube/configAlternatively, if you are the root user, you can run:export KUBECONFIG/etc/kubernetes/admin.confYou should now deploy a pod network to the cluster.
Run kubectl apply -f [podnetwork].yaml with one of the options listed at:https://kubernetes.io/docs/concepts/cluster-administration/addons/You can now join any number of the control-plane node running the following command on each as root:kubeadm join k8smaster.loadbalancer.local:6443 --token [token] \--discovery-token-ca-cert-hash sha256:[sha256] \--control-plane --certificate-key [key]Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
kubeadm init phase upload-certs --upload-certs to reload certs afterward.Then you can join any number of worker nodes by running the following on each as root:kubeadm join k8smaster.loadbalancer.local:6443 --token [token] \--discovery-token-ca-cert-hash sha256:[sha256] 可以看到有加入另一个控制平面的命令其中token和sha256被我替换掉了请注意你实际环境中的值。
开始使用集群前的操作
mkdir -p $HOME/.kube #复制上面提示照着做即可
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config #复制上面提示照着做即可
sudo chown $(id -u):$(id -g) $HOME/.kube/config #复制上面提示照着做即可
export KUBECONFIG/etc/kubernetes/admin.conf查看一下集群状态确认个组件都处于healthy状态 kubectl get cs # 默认不要用sudo
报错 E0812 15:44:43.823568 28146 memcache.go:265] could not get current server API group list: Get “http://localhost:8080/api?timeout32s”: dial tcp 127.0.0.1:8080: connect: connection refused 处理在/etc/systemd/system/kubelet.service.d/10-kubeadm.conf中添加 Environment“KUBELET_SYSTEM_PODS_ARGS–pod-manifest-path/etc/kubernetes/manifests --allow-privilegedtrue --fail-swap-onfalse” 重启kubelet sudo systemctl restart kubelet 未成功 重启系统再运行kubectl get cs成功该现象可复现原因暂未知
初始化完成后有下列提示
接下来可以部署网络插件
Run kubectl apply -f [podnetwork].yaml with one of the options listed at:/docs/concepts/cluster-administration/addons/添加节点
You can now join any number of machines by running the following on each node
as root:kubeadm join control-plane-host:control-plane-port --token token --discovery-token-ca-cert-hash sha256:hash其中token和sha256被我替换掉了请注意你实际环境中的值。
添加节点
先总结一下 2023年的模拟环境中是在后续插件包管理器helm3、网络、CoreDNS等安装完成后再克隆出的node然后添加节点节点是不需要初始化控制平面的kubeadm init。 节点有两个部署思路
控制平面节点master完成必要安装和配置后包括网络插件克隆出节点确保UUID、MAC、IP、HOSTNAME的不同在节点上执行kubeadm reset等重置操作详见卸载集群笔记再做为节点加入集群节点单独部署参照控制平面节点的部署安装好容器运行时和kubeadm、kubelet、kubectlkubeadm也是要安装的官文中提到过所有主机上安装kubeadm但节点系统不执行初始化控制平面再部署好必要插件比如网络和存储插件最后加入集群该方法暂未实践网络插件和DNS插件均是以POD方式运行的
2023年实际操作 克隆出2台k8snode, 添加到Kubernetes集群中分别做为k8snode002, k8snode003在上面执行初始化时产生的“kubeadm join”指令默认24小时内超时后需要重新生成token。
加入节点时报错 error execution phase preflight: [preflight] Some fatal errors occurred: [ERROR FileAvailable–etc-kubernetes-kubelet.conf]: /etc/kubernetes/kubelet.conf already exists [ERROR Port-10250]: Port 10250 is in use [ERROR FileAvailable–etc-kubernetes-pki-ca.crt]: /etc/kubernetes/pki/ca.crt already exists 参考https://www.cnblogs.com/wangzy-Zj/p/13130877.html 重置后重新加入 sudo kubeadm reset 以及清理网络规则和config配置参照卸载集群但不要删除节点 由此可知节点是只需要部署好节点的组件即可。
再报错could not find a JWS signature in the cluster-info ConfigMap for token ID “abcdef” 参考https://www.cnblogs.com/dream397/p/14922802.html 原因token 默认有效时间为24小时 处理重新生成且可设置ttl0表示生成的 token 永不失效 kubeadm token create --print-join-command --ttl0 sudo kubeadm join 192.168.130.88:6443 --token [token] --discovery-token-ca-cert-hash sha256:xxx --v5
可在master节点上执行命令查看集群中的节点 kubectl get node
重新配置 kubeadm 集群
官文https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/ 要修改组件配置你必须手动编辑磁盘上关联的集群对象和文件。 kubeadm 在 ConfigMap 和其他对象中写入了一组集群范围的组件配置选项。 这些对象必须手动编辑可以使用命令 kubectl edit kubectl edit 命令将打开一个文本编辑器你可以在其中直接编辑和保存对象。 你可以使用环境变量 KUBECONFIG 和 KUBE_EDITOR 来指定 kubectl 使用的 kubeconfig 文件和首选文本编辑器的位置。 例如 KUBECONFIG/etc/kubernetes/admin.conf KUBE_EDITORnano kubectl edit 保存对这些集群对象的任何更改后节点上运行的组件可能不会自动更新。 以下步骤将指导你如何手动执行该操作。 警告 ConfigMaps 中的组件配置存储为非结构化数据YAML 字符串。 这意味着在更新 ConfigMap 的内容时不会执行验证。 你必须小心遵循特定组件配置的文档化 API 格式 并避免引入拼写错误和 YAML 缩进错误。
应用集群配置更改
更新 ClusterConfiguration 官文https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/#%E6%9B%B4%E6%96%B0-clusterconfiguration 在集群创建和升级期间kubeadm 将其 ClusterConfiguration 写入 kube-system 命名空间中名为 kubeadm-config 的 ConfigMap。 要更改 ClusterConfiguration 中的特定选项你可以使用以下命令编辑 ConfigMap kubectl edit cm -n kube-system kubeadm-config 说明 ClusterConfiguration 包括各种影响单个组件配置的选项 例如 kube-apiserver、kube-scheduler、kube-controller-manager、 CoreDNS、etcd 和 kube-proxy。 对配置的更改必须手动反映在节点组件上。 在控制平面节点上反映 ClusterConfiguration 更改 kubeadm 将控制平面组件作为位于 /etc/kubernetes/manifests 目录中的静态 Pod 清单进行管理。 对 apiServer、controllerManager、scheduler 或 etcd键下的 ClusterConfiguration 的任何更改都必须反映在控制平面节点上清单目录中的关联文件中。 在继续进行这些更改之前请确保你已备份目录 /etc/kubernetes/。 要编写新证书你可以使用 kubeadm init phase certs --config 要在 /etc/kubernetes/manifests 中编写新的清单文件你可以使用 kubeadm init phase control-plane --config 内容必须与更新后的 ClusterConfiguration 匹配。 值必须是组件的名称。 说明 更新 /etc/kubernetes/manifests 中的文件将告诉 kubelet 重新启动相应组件的静态 Pod。 尝试一次对一个节点进行这些更改以在不停机的情况下离开集群。
应用 kubelet 配置更改
kubectl edit cm -n kube-system kubelet-config 反映 kubelet 的更改 登录到 kubeadm 节点 运行 kubeadm upgrade node phase kubelet-config 下载最新的 kubelet-config ConfigMap 内容到本地文件 /var/lib/kubelet/config.conf 编辑文件 /var/lib/kubelet/kubeadm-flags.env 以使用标志来应用额外的配置pause镜像和–container-runtime-endpoint便在这里面。 使用 systemctl restart kubelet 重启 kubelet 服务 说明 一次执行一个节点的这些更改以允许正确地重新安排工作负载。
应用 kube-proxy 配置更改
sudo kubectl edit cm -n kube-system kube-proxy 反映 kube-proxy 的更改 更新 kube-proxy ConfigMap 后你可以重新启动所有 kube-proxy Pod 获取 Pod 名称 kubectl get po -n kube-system | grep kube-proxy 使用以下命令删除 Pod kubectl delete po -n kube-system 将创建使用更新的 ConfigMap 的新 Pod。 说明 由于 kubeadm 将 kube-proxy 部署为 DaemonSet因此不支持特定于节点的配置。
应用 CoreDNS 配置更改
kubeadm 将 CoreDNS 部署为名为 coredns 的 Deployment并使用 Service kube-dns 两者都在 kube-system 命名空间中。 要更新任何 CoreDNS 设置你可以编辑 Deployment 和 Service kubectl edit deployment -n kube-system coredns kubectl edit service -n kube-system kube-dns 反映 CoreDNS 的更改 应用 CoreDNS 更改后你可以删除 CoreDNS Pod。 获取 Pod 名称 kubectl get po -n kube-system | grep coredns 使用以下命令删除 Pod kubectl delete po -n kube-system 将创建具有更新的 CoreDNS 配置的新 Pod。
卸载集群
官文https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#tear-down
技术同行初始化失败 运行sudo kubeadm reset rm -rf $HOME/.kube/config rm -rf $HOME/.kube; 再执行初始化命令。 实践没有清理iptables 规则或 IPVS 表可能留下问题。
如果你在集群中使用了一次性服务器进行测试则可以关闭这些服务器而无需进一步清理。 你可以使用 kubectl config delete-cluster 删除对集群的本地引用。 但是如果要更干净地取消配置集群 则应首先清空节点并确保该节点为空 然后取消配置该节点。
删除节点
使用适当的凭证与控制平面节点通信驱逐pod控制平面节点上运行 kubectl drain --delete-emptydir-data --force --ignore-daemonsets
在删除节点之前请重置 kubeadm 安装的状态在要删除的节点上操作 sudo kubeadm reset
重置过程不会重置或清除 iptables 规则或 IPVS 表。如果你希望重置 iptables则必须手动进行root用户 sudo iptables -F sudo iptables -t nat -F sudo iptables -t mangle -F sudo iptables -X sudo iptables -vnL
如果要重置 IPVS 表则必须运行以下命令 sudo ipvsadm -C sudo ipvsadm -ln # 查看结果
清理CNI配置 sudo rm -rf /etc/cni/net.d
现在删除节点控制平面节点上运行 kubectl delete node 节点名称
如果是删除worker节点此时可重新加入集群了。
清理控制平面
你可以在控制平面主机上使用 kubeadm reset 来触发尽力而为的清理。 sudo kubeadm reset rm -rf $HOME/.kube/config rm -rf $HOME/.kube 有关此子命令及其选项的更多信息请参见 kubeadm reset 参考文档。 清除 iptables 规则或 IPVS 表同删除节点的操作一样 sudo iptables -F sudo iptables -t nat -F sudo iptables -t mangle -F sudo iptables -X sudo iptables -vnL sudo ipvsadm -C sudo ipvsadm -ln # 查看结果
如何安全地清空一个节点扩展
官文https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/safely-drain-node/ 使用 kubectl drain 从服务中删除一个节点操作后一般要多等一会儿
kubectl drain 的成功返回表明所有的 Pod除了上一段中描述的被排除的那些 已经被安全地逐出考虑到期望的终止宽限期和你定义的 PodDisruptionBudget。 然后就可以安全地关闭节点 比如关闭物理机器的电源如果它运行在云平台上则删除它的虚拟机。
说明 如果存在新的、能够容忍 node.kubernetes.io/unschedulable 污点的 Pod 那么这些 Pod 可能会被调度到你已经清空的节点上。 除了 DaemonSet 之外请避免容忍此污点。 如果你或另一个 API 用户绕过调度器直接为 Pod 设置了 nodeName字段 则即使你已将该节点清空并标记为不可调度Pod 仍将被绑定到这个指定的节点并在该节点上运行。
首先确定想要清空的节点的名称。可以用以下命令列出集群中的所有节点: kubectl get nodes 接下来告诉 Kubernetes 清空节点 kubectl drain --ignore-daemonsets 节点名称
如果存在 DaemonSet 管理的 Pod你将需要为 kubectl 设置 --ignore-daemonsets 以成功地清空节点。 kubectl drain 子命令自身实际上不清空节点上的 DaemonSet Pod 集合 DaemonSet 控制器作为控制平面的一部分会立即用新的等效 Pod 替换缺少的 Pod。 DaemonSet 控制器还会创建忽略不可调度污点的 Pod这种污点允许在你正在清空的节点上启动新的 Pod。 一旦它返回没有报错 你就可以下线此节点或者等价地如果在云平台上删除支持该节点的虚拟机。 如果要在维护操作期间将节点留在集群中则需要运行 kubectl uncordon
然后告诉 Kubernetes它可以继续在此节点上调度新的 Pod。
并行清空多个节点 官文https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/safely-drain-node/#draining-multiple-nodes-in-parallel 状态的副本数量低于指定预算的清空操作都将被阻止。
有关 kubeadm init 参数的更多信息
请参见 kubeadm 参考指南。https://kubernetes.io/zh-cn/docs/reference/setup-tools/kubeadm/ Kubeadm 是一个提供了 kubeadm init 和 kubeadm join 的工具 作为创建 Kubernetes 集群的 “快捷途径” 的最佳实践。 kubeadm 通过执行必要的操作来启动和运行最小可用集群。 按照设计它只关注启动引导而非配置机器。同样的 安装各种 “锦上添花” 的扩展例如 Kubernetes Dashboard、 监控方案、以及特定云平台的扩展都不在讨论范围内。 相反我们希望在 kubeadm 之上构建更高级别以及更加合规的工具 理想情况下使用 kubeadm 作为所有部署工作的基准将会更加易于创建一致性集群。 kubeadm init 用于搭建控制平面节点 kubeadm join 用于搭建工作节点并将其加入到集群中 kubeadm upgrade 用于升级 Kubernetes 集群到新版本 kubeadm config 如果你使用了 v1.7.x 或更低版本的 kubeadm 版本初始化你的集群则使用 kubeadm upgrade 来配置你的集群 kubeadm token 用于管理 kubeadm join 使用的令牌 kubeadm reset 用于恢复通过 kubeadm init 或者 kubeadm join 命令对节点进行的任何变更 kubeadm certs 用于管理 Kubernetes 证书 kubeadm kubeconfig 用于管理 kubeconfig 文件 kubeadm version 用于打印 kubeadm 的版本信息 kubeadm alpha 用于预览一组可用于收集社区反馈的特性
