K8S on 维克的博客

Kaniko 从入门到实践

Sat, 24 Oct 2026 11:28:31 +0800

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 集群）里，仍然能安全、快速地构建镜像。

ArgoCD 入门和生产实践指南

Sat, 10 Oct 2026 09:33:28 +0800

1. 什么是 ArgoCD

ArgoCD 是 CNCF 毕业级项目，面向 Kubernetes 的声明式 GitOps 持续交付工具。

GitOps 核心思想：Git 仓库作为应用配置的唯一可信源。ArgoCD 持续监听 Git 仓库内定义的应用目标状态，对比集群内资源的实际运行状态，自动完成应用部署、版本更新与故障回滚。

ArgoCD 原生支持多种配置编排方式：Helm Chart、Kustomize、Jsonnet、Ksonnet，以及原生 YAML/JSON Kubernetes 资源清单。

2. 架构原理

ArgoCD 以 Kubernetes 控制器形态运行，持续对应用做状态巡检：

拉取 Git 仓库中声明的期望状态（Target State）
采集集群内资源实际运行状态（Live State）
对比两者差异，不一致时标记为 OutOfSync（不同步）
可视化展示资源差异，支持手动同步 / 自动同步，将集群状态收敛到 Git 定义的目标状态

Git 仓库中修改清单后，ArgoCD 会感知变更并同步至目标集群，实现“改 Git 即发布”。

具体工作流程参见下面的图片：

核心组件:

组件	核心作用
`argocd-server`	ArgoCD API 服务，提供 REST API、Web UI，处理认证鉴权
`argocd-repo-server`	Git 仓库管理服务，缓存仓库代码、渲染 Helm/Kustomize 生成K8s清单
`argocd-application-controller`	应用控制器，持续做状态比对，执行同步、健康检查
`argocd-applicationset-controller`	ApplicationSet控制器，批量、模板化管理多环境/多集群 Application
`argocd-redis`	缓存组件，存储仓库缓存、应用状态信息
`argocd-dex-server`	可选，Dex 身份代理，对接OIDC、LDAP等外部身份源
`argocd-notifications-controller`	可选，通知控制器，同步状态变更推送至邮件、Slack、Webhook等

3. 部署

部署前建议查阅官方版本兼容矩阵，选择与K8s集群匹配的ArgoCD版本。

Kubespray 部署和维护 K8s 集群指南

Fri, 09 Oct 2026 11:34:13 +0800

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. 底层架构和设计

关键核心设计：

K8s MetaLB 详解

Wed, 16 Sep 2026 13:59:57 +0800

在 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部署），核心职责：

Pod 网络故障排查

Sat, 12 Sep 2026 15:51:54 +0800

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。此时需要检查：

K8s 集群升级

Wed, 09 Sep 2026 14:26:14 +0800

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 部署高可用 K8s 集群

Wed, 09 Sep 2026 10:54:51 +0800

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。