安装部署

1. 简介 1.1 GitLab CI/CD 是什么？ GitLab CI/CD 可以理解为：GitLab 内置的持续集成 / 持续交付引擎。代码提交、合并请求、打标签或定时触发后，GitLab 会根据项目里的 .gitlab-ci.yml 生成流水线，再交给 GitLab Runner 去执行构建、测试、扫描、打包、部署等任务。 它的整体架构可以分成三层： 层级 组件 作用 控制层 GitLab Server 解析 .gitlab-ci.yml，生成 Pipeline，分发 Job，展示结果 执行层 GitLab Runner 从 GitLab 拉取任务，执行脚本，回传日志和产物 环境层 Executor 决定 Job 跑在哪里，比如 Docker、Kubernetes、Shell、SSH 等 一个典型的 Gitlab CICD 执行链路如下所示： 开发者 push 代码或创建 MR，触发流水线 ↓ GitLab 读取仓库里的 .gitlab-ci.yml，生成 Pipeline 流水线作业 ↓ Runner 轮询到待执行的任务，领取 Job ↓ Job 的 Tag 会和 Executor 的 Tag 进行匹配，匹配成功后，Executor 去执行 Job ↓ 执行完成后，日志、制品、状态回传到 GitLab，在页面上可以查看结果 1.2 如何定义流水线？ 一个流水线本质上由两个核心概念构成： ...

1. 简介 Kubespray 是 Kubernetes SIGs 官方维护的部署项目，本质是一套经过大量生产环境验证的 Ansible Playbook、Inventory 模板和角色集合。它不发明新的集群模型，而是把 kubeadm 引导、etcd 集群组建、CNI 安装、证书轮换、节点扩缩容与升级这些容易出错的步骤固化为可重复执行的代码。 1.1 Kubespray 解决了什么问题 手动搭一个生产集群的工作量并不仅仅只是简单把 K8s 集群跑起来，而在于： etcd 节点集群的证书、成员管理、快照备份； 多控制平面节点下 apiserver 的负载均衡与前端证书 SAN； kubelet 配置（cgroup 驱动、预留资源、镜像垃圾回收、最大 Pod 数）； CNI 插件与内核网络参数、iptables/nftables 后端的匹配； 证书到期轮换、跨小版本顺序升级、节点下线清理。 这些工作做一次可以靠文档，做十次就得靠自动化。Kubespray 的价值就在于它把这些工程细节沉淀成了一套符合生产环境最佳实践的可重复执行代码，你只需要在默认值的基础上少量改动，而不是自己编写和维护大量的脚本。 1.2 和其他工具对比 工具 Kubespray kubeadm Rancher OpenShift(OKD) kops KubeKey(kk) k3s 核心定位 Ansible驱动，生产级离线部署K8s集群 K8s官方最小化集群引导工具 企业级K8s全生命周期管理平台 红帽出品，基于K8s的企业容器平台 AWS专用K8s集群部署工具 KubeSphere社区开源部署工具，中文友好 Rancher出品轻量K8s发行版 底层引擎 Ansible Go原生二进制 容器+WebUI 容器/Operator Go，调用AWS API Go二进制，封装kubeadm 裁剪K8s单二进制 适用环境 裸金属、VMware、私有云、离线环境 裸金属/虚拟机/云主机，在线为主 公有云、私有云、边缘，多集群统一管理 企业私有/混合云，偏向生产企业 仅限AWS公有云 裸机/虚拟机，私有化离线场景 低配服务器、边缘、开发/小生产 离线部署 ✅ 完美支持，可打包离线介质 ⚠️ 支持但麻烦，需要手动下载镜像/二进制 ✅ 支持离线airgap安装 ✅ 官方提供离线方案 ❌ 依赖AWS云API，不适合离线 ✅原生支持打包离线包 ✅离线包 集群维护 Ansible playbook升级、扩容、替换节点；版本升级稳定 仅引导集群，不负责后续集群运维，升级操作繁琐 Web界面一键升级、扩缩容，多集群统一监控告警 Operator管理集群，自动化运维能力强 集群升级、节点替换由kops命令管理 一键HA、扩容升级，可配套KubeSphere控制台 一行命令运维，嵌入式etcd HA 高可用 ✅ 内置etcd三副本、控制面HA方案 需要手动搭建HA（负载均衡+多master） ✅ 自动支持HA，内置负载均衡方案 ✅ 默认HA架构 ✅ AWS上自动搭建控制面HA ✅一键HA，内置负载均衡 ✅内置HA（嵌入式etcd） 网络插件 内置Calico/Flannel/Cilium等多种CNI可选 仅提供基础CNI对接，需自行部署CNI 内置多种CNI，UI可视化配置 默认OVN-Kubernetes，也可Calico 默认Calico，可自定义CNI Calico等CNI可选 Flannel默认，支持替换CNI 存储支持 对接本地卷、Ceph、Longhorn等，ansible角色集成 仅提供CSI标准，存储需要自己部署 内置存储管理，支持Longhorn等 内置CSI+本地存储方案 对接AWS EBS等云存储 对接Longhorn、Ceph、本地存储 支持本地存储、CSI 版本适配 紧跟K8s社区版本，滞后一小段时间 K8s官方同步发布 支持多K8s版本，统一纳管不同版本集群 OKD版本独立，和上游K8s有差异 紧跟AWS支持的K8s版本 跟随上游kubeadm Rancher维护稳定版本 学习成本 中等，需要懂Ansible 低，上手简单，适合测试集群 低，WebUI友好，运维门槛低 高，体系庞大，有专属概念 中等，熟悉AWS即可快速上手 中等，中文文档友好 很低，上手极快 典型场景 裸金属机房、私有化项目、需要批量部署大量集群、等保离线环境 实验室、POC测试、小规模简单集群 多集群管理、混合云、需要统一权限/审计的企业 大型企业生产环境，需要完整容器安全、合规能力 AWS云上快速搭建销毁K8s集群 中小企业裸机/VM离线部署，可选KubeSphere控制台 资源有限、边缘、小生产集群 缺点 Ansible串行执行，大规模集群部署慢；无WebUI；故障排查需要Ansible基础 没有集群生命周期管理，生产HA搭建工作量大；缺少监控日志等附加组件 资源开销大；底层K8s被封装，深度定制复杂；商业版收费 闭源企业版昂贵；架构重，资源消耗高；学习曲线陡峭 只能跑在AWS，无法裸金属/其他云使用 依赖kubeadm；底层封装，深度排障需要kubeadm知识；KubeSphere额外耗资源 裁剪部分组件，重型大规模生产不推荐；和标准K8s有细微差异 国内中小企业热度 ⭐⭐⭐ 更多集成商使用，中小企业自用偏少 ⭐⭐⭐⭐⭐ 最高，几乎所有运维都学这个 ⭐⭐⭐⭐ 多集群场景热门 ⭐⭐ 大型企业为主，中小企业很少用 ⭐ 国内几乎不用 ⭐⭐⭐⭐ 私有化中小企业热门 ⭐⭐⭐⭐ 小集群/边缘场景热门 2. 底层架构和设计 关键核心设计： ...

kubeadm 安装官方文档 0. 引言 Kubernetes 高可用架构的核心在于保障 API Server 的访问连续性与 etcd 的数据可靠性。通常通过部署多 Master 节点并前置负载均衡来实现，本方案采用 kube-vip 承担此角色。为节省资源，本文将负载均衡与 etcd 集群复用部署于 Master 节点；生产环境请务必将其独立部署，以确保集群稳定性。 本文基于 Ubuntu 24.04 环境编写。若使用其他 Linux 发行版，请根据实际情况自行调整相关命令。 1. 环境架构 1.1 角色划分 主机名 IP 角色 master01 192.168.69.11 master01、Etcd-node01、kube-vip 节点 master02 192.168.69.12 master02、Etcd-node02、kube-vip 节点 master03 192.168.69.13 master03、Etcd-node03、kube-vip 节点 worker01 192.168.69.21 worker01 worker02 192.168.69.22 worker02 worker03 192.168.69.23 worker03 虚拟IP 10.0.0.100 kube-vip 提供 1.2 拓扑图 2. 操作系统初始化 2.1 Linux 基础配置 # 关闭防火墙 ufw disable # 关闭 swap swapoff -a && sysctl -w vm.swappiness=0 sed -ri 's/.*swap.*/#&/' /etc/fstab # 配置主机名和 hosts hostnamectl set-hostname <hostname> cat >> /etc/hosts << EOF 192.168.69.11 master01.wuvikr.top master01 192.168.69.12 master02.wuvikr.top master02 192.168.69.13 master03.wuvikr.top master03 192.168.69.21 worker01.wuvikr.top worker01 192.168.69.22 worker02.wuvikr.top worker02 192.168.69.23 worker03.wuvikr.top worker03 192.168.69.100 kubeapi.wuvikr.top kubeapi EOF # 配置 limit ulimit -SHn 65535 # 持久化 limit 配置（重新登录后生效） cat >> /etc/security/limits.conf << EOF * soft nofile 65536 * hard nofile 131072 * soft nproc 65535 * hard nproc 655350 * soft memlock unlimited * hard memlock unlimited * soft core unlimited * hard core unlimited EOF 2.2 时间同步 # 同步硬件时钟到系统时间（虚拟机环境中可选） hwclock -s # 设置时区（推荐方式，一步完成） timedatectl set-timezone Asia/Shanghai # 确保时间同步服务已启用（Ubuntu 24.04 默认已启用） systemctl enable --now systemd-timesyncd # 查看时间同步状态 timedatectl status Ubuntu 24.04 内置的 systemd-timesyncd 提供轻量级 NTP 客户端功能，支持自动同步、漂移补偿和状态查询。如需更高精度的时间同步（如金融、日志审计场景），建议改用 chrony 替代 systemd-timesyncd。 ...