K8s vs K3s：从核心原理到生产实战与面试通关指南

摘要： Kubernetes（K8s）是云原生容器编排标准，而K3s是其轻量级发行版，适用于边缘计算和开发测试。K8s采用模块化架构，资源消耗较高，适合大规模生产环境；K3s通过单一二进制集成组件，默认使用SQLite存储，资源需求更低。两者在架构、部署复杂度、功能完整性等方面存在差异。文章详细解析了核心概念（如Pod、Deployment、Service）及K3s特有组件（如嵌入式Traefik

冷小鱼

441人浏览 · 2026-05-08 15:33:00

冷小鱼 · 2026-05-08 15:33:00 发布

在这里插入图片描述

一、写在前面：为什么需要同时掌握 K8s 和 K3s？

在云原生技术栈中，Kubernetes（K8s）已成为容器编排的事实标准，而 K3s 作为其轻量级发行版，正在边缘计算、IoT 和开发测试场景中快速崛起。对于运维工程师、云原生架构师和 DevOps 从业者而言，理解两者的架构差异、适用场景和运维要点，是面试和实际工作中的核心能力要求。

本文将从架构原理、核心组件、部署实践、生产环境最佳实践到高频面试题，构建完整的知识体系。

二、核心架构深度解析

2.1 Kubernetes（K8s）标准架构

K8s 采用经典的控制平面（Control Plane）+ 工作节点（Worker Node）架构：

控制平面组件：

kube-apiserver：集群的统一入口，所有资源操作的 REST API 端点
etcd：分布式键值存储，保存集群所有配置和状态数据
kube-scheduler：负责 Pod 的调度决策，选择最优节点
kube-controller-manager：运行各种控制器（Node、Replication、Endpoint 等），维持期望状态

工作节点组件：

kubelet：节点代理，管理 Pod 生命周期
kube-proxy：维护网络规则，实现 Service 的负载均衡
容器运行时（Container Runtime）：如 containerd、CRI-O

特点：模块化设计，组件分离，适合大规模生产环境，但安装配置复杂，资源消耗较高（通常需要 2GB+ 内存和 2 核 CPU）。

2.2 K3s 轻量级架构

K3s 由 Rancher Labs 开发，是一个通过 CNCF 一致性认证的轻量级 Kubernetes 发行版。其核心创新在于将所有控制平面组件打包为单一二进制文件：

架构特点：

单一二进制文件：API Server、Scheduler、Controller Manager 等全部集成在一个进程中
存储后端优化：默认使用 SQLite 替代 etcd，同时支持 etcd、MySQL、PostgreSQL
内置常用组件：默认包含 Flannel（CNI）、CoreDNS、Traefik Ingress Controller、本地存储提供程序、服务负载均衡器
轻量级网络：减少对 kube-proxy 的依赖，简化网络配置

资源需求：最低 512MB 内存即可运行，CPU 和内存消耗比 K8s 低 30%-50%。

2.3 架构对比总结

特性/方面	K3s	K8s（标准 Kubernetes）
资源消耗	极低（512MB 内存起）	较高（2GB+ 内存）
安装复杂度	一条命令，极简配置	多组件手动配置，学习曲线陡峭
架构模式	单体架构，单一二进制	模块化架构，组件分离
存储后端	默认 SQLite，可选 etcd/MySQL	默认 etcd
启动速度	秒级启动	分钟级（大型集群）
网络模型	轻量级，内置 Flannel	需单独部署 CNI 插件
功能完整性	核心功能完整，部分高级特性简化	全套功能，生态丰富
目标场景	边缘计算、IoT、开发测试	数据中心、大规模生产、复杂多租户
高可用支持	需额外配置	原生多主节点 HA

三、核心概念与组件详解（面试重点）

3.1 必须掌握的 K8s 核心概念

Pod：K8s 中最小的部署单元，一个 Pod 可包含一个或多个容器，共享网络和存储命名空间。面试常问：为什么 K8s 不直接调度容器而是 Pod？ 答案：Pod 作为原子调度单位，可以确保紧密耦合的容器始终运行在同一节点，共享生命周期。

Deployment：管理无状态应用的声明式更新控制器，支持滚动更新、回滚、扩缩容。核心字段：replicas、strategy（RollingUpdate/Recreate）、selector。

Service：抽象一组 Pod 的访问策略，提供稳定的 ClusterIP。类型包括：

ClusterIP（集群内部访问）
NodePort（节点端口暴露）
LoadBalancer（云厂商负载均衡）
ExternalName（DNS CNAME 映射）

ConfigMap / Secret：配置分离机制。Secret 用于敏感数据（base64 编码，非加密，需配合 RBAC 和 etcd 加密使用）。

PersistentVolume (PV) / PersistentVolumeClaim (PVC)：存储抽象，支持静态和动态供给（StorageClass）。

Namespace：资源隔离和配额管理的基础单位。

RBAC（基于角色的访问控制）：通过 Role/ClusterRole 和 RoleBinding/ClusterRoleBinding 实现细粒度权限控制。

3.2 K3s 特有的核心概念

SQLite 后端：K3s 默认使用 SQLite 作为数据存储，单节点场景下性能优异且资源占用极低。但在多节点高可用场景中，必须切换到 etcd 或外部数据库（MySQL/PostgreSQL）。

嵌入式组件：K3s 将 Traefik 作为默认 Ingress Controller，将服务负载均衡器（Service LB）直接嵌入，无需额外部署 MetalLB 等组件。

K3s Server / Agent 模式：

Server：运行控制平面组件的节点，相当于 K8s 的 Master
Agent：运行工作负载的节点，相当于 K8s 的 Worker，通过 k3s agent 命令加入集群

四、部署实践：从零搭建生产级集群

4.1 标准 K8s 生产部署（kubeadm 方式）

环境准备（所有节点）：

# 关闭 Swap
swapoff -a && sed -i '/swap/d' /etc/fstab

# 配置内核参数
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

modprobe overlay
modprobe br_netfilter

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 --system

# 安装 containerd
apt-get update && apt-get install -y containerd
mkdir -p /etc/containerd && containerd config default > /etc/containerd/config.toml
systemctl restart containerd

# 安装 kubeadm, kubelet, kubectl
apt-get install -y apt-transport-https ca-certificates curl
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | tee /etc/apt/sources.list.d/kubernetes.list
apt-get update
apt-get install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl

初始化控制平面：

# 主节点初始化
kubeadm init --pod-network-cidr=10.244.0.0/16 --control-plane-endpoint="lb.k8s.local:6443"

# 配置 kubectl
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

# 部署 CNI（以 Flannel 为例）
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

# 工作节点加入
kubeadm join lb.k8s.local:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

高可用配置：需要部署多个 Master 节点，使用外部负载均衡器或 keepalived + haproxy 实现 API Server 的高可用。

4.2 K3s 快速部署（边缘/开发场景）

单节点快速安装：

# 安装 Server（自带 kubectl）
curl -sfL https://get.k3s.io | sh -

# 验证
kubectl get nodes
kubectl get pods -A

# 查看配置
cat /etc/rancher/k3s/k3s.yaml  # kubeconfig 文件

高可用模式（嵌入式 etcd）：

# 第一个 Server 节点
curl -sfL https://get.k3s.io | sh -s - server --cluster-init --tls-san <LB_IP>

# 后续 Server 节点加入
curl -sfL https://get.k3s.io | sh -s - server --server https://<first-server>:6443 --token <token>

# Agent 节点加入
curl -sfL https://get.k3s.io | sh -s - agent --server https://<server-ip>:6443 --token <token>

使用外部数据库（MySQL/PostgreSQL）：

curl -sfL https://get.k3s.io | sh -s - server --datastore-endpoint="mysql://user:password@tcp(hostname:3306)/database"

4.3 部署方式选择指南

部署方式	适用场景	优缺点
Minikube / kind / k3s	个人学习、开发测试	一键启动，资源占用少，但不适合生产
kubeadm	中小型企业、自建集群	官方推荐，灵活可控，但升级运维成本高
K3s	边缘计算、IoT、小型业务	占用少、安装快，但功能简化，不适合复杂企业级场景
托管版（ACK/GKE/EKS）	企业生产环境、核心业务	免运维、弹性扩展，但厂商绑定、费用较高
企业级平台（OpenShift/Rancher）	大型金融、电信、制造业	功能全面、安全合规，但复杂度高、成本高

五、生产环境最佳实践（面试高频考点）

5.1 集群安全加固

认证与授权：

集成外部身份认证：LDAP、OpenID Connect (OIDC)、AWS IAM
必须启用 RBAC，配置最小权限原则
使用 Pod Security Standards（替代已废弃的 PSP）限制容器权限

网络安全：

默认拒绝所有流量，然后按需开放：创建默认 deny-all NetworkPolicy，再为特定 Pod 配置 Ingress/Egress 规则
使用 OPA Gatekeeper 或 Kyverno 强制执行策略（如强制设置资源限制、镜像必须来自私有仓库）

etcd 安全：

启用 etcd 加密（--encryption-provider-config）
定期备份 etcd 数据：etcdctl snapshot save
限制 etcd 仅允许控制平面节点访问

5.2 高可用与灾备

控制平面高可用：

至少 3 个 Master 节点（奇数个，避免脑裂）
使用负载均衡器分发 API Server 流量
etcd 集群独立部署或采用高可用拓扑（Stacked vs External etcd）

应用高可用：

Deployment 设置 replicas >= 2
使用 Pod Anti-Affinity 确保副本分布在不同节点/可用区
配置 PodDisruptionBudget (PDB) 防止升级时全部中断

备份策略：

Velero：集群资源和持久卷备份
etcd 定期快照：集群状态恢复的基础
多地域部署，减少延迟接近用户

5.3 监控与可观测性

核心监控栈：

Metrics Server：资源指标（CPU/内存）
Prometheus + Grafana：深度监控和告警，遵循 RED（Rate, Errors, Duration）和 USE（Utilization, Saturation, Errors）方法
ELK / EFK / Loki：日志聚合和分析
Jaeger / Zipkin：分布式链路追踪

关键告警项：

节点磁盘压力、内存压力、PID 压力
Pod 重启频率、OOMKilled 事件
API Server 延迟、etcd leader 变化
Certificate 过期时间

5.4 资源管理与优化

QoS 等级：

Guaranteed：requests = limits（所有资源），最高优先级，适合核心服务
Burstable：requests < limits，中等优先级
BestEffort：未设置 requests/limits，最低优先级，最先被驱逐

必须设置资源限制：

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "200m"

HPA（水平 Pod 自动伸缩）：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

5.5 发布策略

策略	描述	适用场景
滚动更新 (RollingUpdate)	逐步替换旧 Pod，默认策略	常规发布，零停机
重建 (Recreate)	先删除所有旧 Pod，再创建新 Pod	允许短暂停机，资源受限
蓝绿部署	并行部署两套环境，瞬时切换	需要快速回滚，资源充足
金丝雀 (Canary)	先发布少量流量验证，再逐步扩大	高风险变更，需要 A/B 测试
灰度发布	基于用户/请求特征分流	微服务架构，精细化控制

六、K8s vs K3s 场景化选择决策树

是否需要管理 >100 节点或复杂多租户？
├── 是 → 选择标准 K8s（kubeadm / 托管版 / OpenShift）
│       └── 是否需要极致资源优化？
│           └── 是 → 考虑 K3s 作为边缘节点接入（K3s + Rancher 统一管理）
└── 否 → 资源是否受限（<2GB 内存 / 边缘设备 / IoT）？
        ├── 是 → 选择 K3s（单节点 SQLite 或多节点 etcd HA）
        └── 否 → 是否需要快速验证 / 开发测试？
                ├── 是 → K3s（秒级启动，一键安装）
                └── 否 → 标准 K8s（生态丰富，长期维护）

七、高频面试题精讲与通关攻略

7.1 基础概念类

Q1：Pod 和 Container 的区别是什么？为什么 K8s 要引入 Pod？

答：Container 是应用运行的实际载体，而 Pod 是 K8s 的最小调度单元。引入 Pod 的原因：

紧密耦合：同一 Pod 内的容器共享网络命名空间（localhost 互通）和存储卷，适合 Sidecar 模式（如日志收集、代理）

原子调度：确保辅助容器和业务容器始终同节点运行

生命周期管理：统一创建、销毁，共享上下文

Q2：Service 的 ClusterIP 是如何实现的？kube-proxy 的三种模式有什么区别？

答：ClusterIP 通过虚拟 IP 实现，后端机制依赖 kube-proxy：

userspace：早期模式，用户态转发，性能差，已废弃

iptables：默认模式，通过 iptables 规则直接 DNAT 到 Pod IP，性能较好但规则量大时更新慢

ipvs：内核态负载均衡，支持更多后端算法（rr/wlc/lc 等），大规模集群性能更优

K3s 中简化了 kube-proxy 依赖，部分场景直接使用更轻量的网络方案。

7.2 架构设计类

Q3：etcd 在 K8s 中的作用是什么？如果 etcd 数据丢失会怎样？

答：etcd 是 K8s 的"大脑"，存储所有集群状态（Pod 信息、配置、Secret 等）。数据丢失会导致：

集群完全不可恢复（无备份情况下）

所有资源定义丢失，应用状态无法重建

保护措施：定期快照、启用 etcd 加密、限制网络访问、3 节点以上 HA 部署。

Q4：K3s 为什么能用 SQLite 替代 etcd？什么情况下必须切回 etcd？

答：SQLite 是嵌入式数据库，单节点场景下性能足够且资源占用极低。K3s 将控制平面组件作为单一进程，SQLite 的并发访问模式可以满足需求。

必须切换场景：

多节点高可用（HA）部署：SQLite 不支持多节点并发写入

大规模集群（>100 节点）：SQLite 的写入性能瓶颈

需要强一致性分布式事务的场景。

7.3 实战操作类

Q5：如何排查一个 Pod 一直处于 Pending 状态的问题？

答：排查链路：

kubectl describe pod <name> → 查看 Events 字段

常见原因：

资源不足：节点 CPU/内存不足，需扩容或调整 requests

节点亲和性/污点不匹配：检查 nodeSelector、taints/tolerations

PVC 未绑定：检查 StorageClass 和 PV 供给状态

镜像拉取失败：检查 imagePullSecrets、镜像地址、网络连通性

kubectl get nodes -o yaml 查看节点资源使用情况

查看 scheduler 日志：kubectl logs -n kube-system kube-scheduler-xxx

Q6：如何实现零停机发布？Deployment 的滚动更新策略如何配置？

答：

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%        # 更新时可超出的 Pod 比例
      maxUnavailable: 25%  # 更新时可不可用的 Pod 比例

配合 readinessProbe 确保新 Pod 接收流量前已就绪，配合 PDB 防止驱逐过多副本。

7.4 场景选择类（K8s vs K3s 核心考点）

Q7：公司要在工厂部署 500 个边缘网关，每个网关 2 核 4GB 内存，需要运行容器化应用，你会选择 K8s 还是 K3s？为什么？

答：选择 K3s，原因：

资源匹配：K3s 最低 512MB 内存即可运行，4GB 内存下可承载更多业务 Pod

部署效率：单二进制文件，一条命令安装，适合现场无人值守部署

运维简化：内置 Flannel、CoreDNS、Traefik，减少组件维护成本

架构支持：K3s 对 ARM 架构优化更好，适合工业网关硬件

统一管理：可通过 Rancher 等工具将 500 个 K3s 集群纳入统一管控平面

Q8：K3s 能否完全替代 K8s？在企业核心生产环境中使用 K3s 有什么风险？

答：不能完全替代。K3s 移除了部分非核心组件和高级特性：

默认不包含 Dashboard（需手动安装）

部分高级网络插件支持有限

生态工具兼容性虽高，但大规模集群性能不如标准 K8s

社区相对较小，复杂问题排查资料较少

风险：在需要复杂多租户隔离、高级调度策略、大规模自动扩缩容（HPA/VPA 全功能）、深度自定义 CNI/CSI 的场景下，K3s 可能无法满足需求。

7.5 高级进阶类

Q9：如何设计一个跨地域的 K8s 多集群方案？

答：

集群联邦（Karmada / Federation v2）：统一管理多集群资源分发

服务网格（Istio / Linkerd）：跨集群服务发现和流量治理

全局负载均衡：GSLB（Global Server Load Balancing）分发用户流量到最近集群

数据同步：使用 Velero 跨集群备份恢复，或数据库级主从同步

监控统一：Thanos / Cortex 聚合多集群 Prometheus 数据

Q10：K8s 集群升级的最佳实践是什么？

答：

升级前：备份 etcd、验证应用兼容性、阅读 Release Notes

控制平面：先升级 Master 节点（kubeadm upgrade apply），遵循 1 个小版本原则（如 1.28 → 1.29）

工作节点：逐个节点 drain → 升级 kubelet → uncordon

CNI/CSI：确认插件版本兼容

验证：Sonobuoy 运行一致性测试，检查核心功能