Kubernetes

1. Kaniko 是什么 Kaniko 是一个由 Google 开源的，在容器或 Kubernetes 集群内部，直接根据 Dockerfile 构建容器镜像的工具。 它最核心的特点只有一个：不依赖 Docker daemon（守护进程），所有构建动作都在用户态（userspace）完成。这意味着你不需要在集群里跑一个 Docker 服务，也不需要挂载 /var/run/docker.sock，就可以构建出标准镜像。 2. Kaniko 解决了什么问题 在 Kaniko 出现之前，CI 里构建镜像的主流做法是 Docker-in-Docker（DinD）。即在 CI Job 里再起一个 Docker 守护进程，用它去 build。这套方案在 Kubernetes 集群里有两个致命痛点： 需要 privileged 特权模式：dind 服务容器要操控内核特性，必须给 Pod 开 privileged: true。这是很严重的安全隐患——容器可能逃逸到宿主机，很多安全策略严格的集群直接禁止。 性能差：每个 Job 都额外拉起一个完整 Docker daemon，启动慢、占用高，多任务并发时更是灾难。 Kaniko 就是为了解决这个问题而生的：不用特权、不用 daemon，在标准 K8s 集群里就能安全构建镜像。 问题 DinD（旧方案） Kaniko 需要 privileged 特权 ✅ 必须 ❌ 不需要 依赖 Docker daemon ✅ 必须 ❌ 完全不需要 挂载 docker.sock ✅ 需要 ❌ 不需要 安全性 有容器逃逸风险 纯用户态，安全 性能开销 每个 Job 起 daemon，慢 轻量，快 Kaniko 的核心价值用一句话来说就是：在不安全、不方便跑 Docker daemon 的环境（尤其是 K8s 集群）里，仍然能安全、快速地构建镜像。 ...

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. 底层架构和设计 关键核心设计： ...

在 Kubernetes 集群中，Service 是核心资源之一，其中 LoadBalancer 类型服务是业务对外暴露的核心方式。但原生 K8s 仅为公有云集群（AWS、阿里云、腾讯云等）提供 LoadBalancer 实现，裸金属、本地机房、私有部署的 K8s 集群默认不支持 LoadBalancer 类型 Service，只能依赖 NodePort、Ingress 实现流量暴露，存在端口散乱、运维复杂、无统一入口、负载均衡能力薄弱等问题。 MetalLB 正是这样一款专为私有/裸金属K8s集群设计的开源负载均衡组件，完全开源免费、轻量无侵入，完美补齐了私有 K8s 集群无原生 LoadBalancer 的短板，是本地机房 K8s 生产集群的标配组件。 1. 项目介绍 1.1 项目定位与核心作用 MetalLB 是 Kubernetes官方认可的负载均衡解决方案，专为非云环境（裸金属服务器、虚拟机、本地私有集群）设计。其核心作用是：为集群内 LoadBalancer 类型的 Service 自动分配外部静态 IP，实现四层流量负载均衡，替代原生 NodePort 的低效暴露方式，让私有集群拥有与公有云一致的 Service 负载均衡能力。 核心价值： 统一业务暴露方式：与公有云 K8s 开发规范对齐，无需适配 NodePort 特殊逻辑。 稳定四层负载均衡：支持 TCP/UDP 协议，适配后端服务、数据库、中间件等各类业务。 简化运维：固定服务外部 IP，无需节点端口映射，流量入口统一可控。 轻量高性能：无复杂依赖，资源占用极低，不侵入 K8s 核心组件。 1.2 架构原理 MetalLB 采用控制器 + 转发节点的分布式架构，整体由两大核心组件组成，全部运行在集群内部，以 Pod 形式部署。 1.2.1 Controller（控制器组件） 全局唯一的调度组件，默认单副本部署，核心职责： 监听集群内所有 LoadBalancer 类型的 Service 资源变更。 维护 IP 地址池，为新的 LoadBalancer Service 自动分配可用外部 IP。 回收废弃 Service 的 IP 资源，避免 IP 泄露与占用。 校验 IP 分配合法性，保证全局唯一性。 1.2.2 Speaker（转发组件） 集群节点级组件，默认每个集群节点部署一个Pod（DaemonSet部署），核心职责： ...

Kubernetes 的网络是一个多层虚拟网络体系，流量从客户端到后端 Pod 的路径涉及多个组件。排查网络问题时，如果"东戳一下西戳一下"没有章法，可能需要耗费大量时间。如何最快的定位网络问题的根源？记住常见的具体现象和应对办法，遵循从内到外的原则（先确认"自己没问题"，再确认"中间没问题"，最后确认"外面没问题"）或许能够帮你节约大量的时间，。 下面按照从具体访问现象出发的思路，由浅入深展开。 1. 第一层：Pod 自身状态确认 现象：Pod 完全无法访问，任何请求都无响应 这是最基础的一层。在排查任何网络问题之前，先确认 Pod 本身是否健康运行。 1.1 检查 Pod 状态 kubectl get pods -o wide 关注以下状态： 状态 含义 可能原因 Running 正常运行 正常 Pending 等待调度 资源不足、节点亲和性不匹配 CrashLoopBackOff 反复崩溃重启 应用启动失败、配置错误 OOMKilled 内存超限被杀 resources.limits.memory 设置过低 ImagePullBackOff 镜像拉取失败 镜像名错误、仓库认证失败 ContainerCreating 容器创建中 CNI 插件分配 IP 失败、存储卷挂载失败 如果 Pod 不在 Running 状态，网络问题只是表象，根因在 Pod 本身： # 查看 Pod 详细事件 kubectl describe pod <pod-name> -n <namespace> # 查看容器日志（如果容器曾启动过） kubectl logs <pod-name> -n <namespace> # 查看前一个崩溃容器的日志 kubectl logs <pod-name> -n <namespace> --previous 1.2 确认 Pod 有 IP 地址 kubectl get pods -o wide 如果 Pod 状态是 Running 但 IP 为空，说明 CNI 插件没有成功分配 IP。此时需要检查： ...

Kubernetes 集群的大版本（跨次要版本）升级是一项复杂且高风险的运维操作。为了确保业务连续性，必须遵循严格的规范。以下是升级的核心原则、标准流程以及可能遇到的关键问题。 1. 大版本升级的核心原则 逐级递进，严禁跨版本：Kubernetes 不支持跨多个次要版本直接升级（例如不能从 1.24 直接升级到 1.26），必须按照1.24 → 1.25 → 1.26的顺序逐版本进行。每一跳都需要完成控制面和节点的升级与验证。 组件版本兼容策略： 控制面：kube-apiserver 版本最高且需最先升级，controller-manager 和 scheduler 版本应小于或等于 apiserver。 kubelet：节点上的 kubelet 版本必须小于或等于 apiserver，且不能低于 apiserver 的前一个次要版本（例如 apiserver 为 v1.28 时，kubelet 可以是 v1.28 或 v1.27）。 先升级控制面，再升级节点：必须先完成 Master 节点（控制平面）的升级，确认稳定后再分批升级 Worker 节点。 第三方组件兼容性检查：升级前必须确认 CNI 插件（如 Calico/Cilium）、CoreDNS、kube-proxy 以及 Ingress 控制器等是否支持目标版本。通常建议先升级 CNI，CoreDNS 则与 K8s 版本强绑定，需查阅官方对应表。 2. 标准升级流程 升级前准备： 检查集群健康状态，确保所有节点为 Ready，无 CrashLoopBackOff 的 Pod。 备份关键数据：必须备份 etcd 数据、证书文件及核心配置文件，以防升级失败导致数据丢失。 检查并处理废弃 API（Deprecated APIs），高版本可能会移除旧版 API，导致 HPA 或 Ingress 等资源失效。 升级控制面：升级 kubeadm，执行 kubeadm upgrade apply，依次更新 kube-apiserver、kube-controller-manager 和 kube-scheduler。 升级工作节点： 腾空节点（Cordon & Drain），将 Pod 驱逐到其他节点。 升级节点的 kubeadm、kubelet 和 kubectl。 解除节点保护（Uncordon），使其重新加入调度。 建议在生产环境中逐个节点离线升级后再上线，避免全部同时升级。 3. 升级过程中可能遇到的问题 废弃 API 导致业务失效：高版本 K8s 会废弃旧版 API。例如升级到 1.22+ 时，networking.k8s.io/v1beta1 的 Ingress 将不再可用；升级到 1.18+ 后，HPA 的 apiVersion 必须切换为 apps/v1，否则功能会失效。 容器运行时变更：从 Kubernetes 1.24 开始，不再支持将 Docker 作为内置容器运行时。若从 1.22/1.23 升级，必须提前将节点运行时从 Docker 迁移到 containerd，否则升级会失败。 节点排水（Drain）失败与 PDB 冲突：在驱逐 Pod 时，如果配置了 Pod Disruption Budget (PDB) 且当前可用副本数达到下限，Pod 将无法被驱逐，导致节点升级超时或失败。 网络连通性中断：如果 Pod 通过 LoadBalancer 类型的 Service 访问同节点上的另一个 Pod，且 Service 的 externalTrafficPolicy 设置为 Local，在节点轮转升级后，两个 Pod 可能不再位于同一节点，导致网络不通。 自定义配置被覆盖：如果曾通过非产品化方式（如直接登录节点修改 kubelet 配置、打开 SWAP 分区等）更改过节点配置，升级过程中这些自定义配置可能会被重置或覆盖，甚至导致升级失败。 磁盘空间不足：升级过程需要下载软件包并可能产生临时文件。如果节点磁盘水位过高（建议预留至少 20% 空间），可能导致 Pod 被驱逐或升级失败。 Cgroup v1 兼容性问题：在较新的版本（如 1.36）中，kubelet 默认仅支持 Cgroup v2。如果节点操作系统仍在使用 Cgroup v1，可能会导致 kubelet 启动失败或节点 NotReady。

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。 ...