一、写在前面为什么需要同时掌握 K8s 和 K3s在云原生技术栈中KubernetesK8s已成为容器编排的事实标准而 K3s 作为其轻量级发行版正在边缘计算、IoT 和开发测试场景中快速崛起。对于运维工程师、云原生架构师和 DevOps 从业者而言理解两者的架构差异、适用场景和运维要点是面试和实际工作中的核心能力要求。本文将从架构原理、核心组件、部署实践、生产环境最佳实践到高频面试题构建完整的知识体系。二、核心架构深度解析2.1 KubernetesK8s标准架构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内置常用组件默认包含 FlannelCNI、CoreDNS、Traefik Ingress Controller、本地存储提供程序、服务负载均衡器轻量级网络减少对 kube-proxy 的依赖简化网络配置资源需求最低 512MB 内存即可运行CPU 和内存消耗比 K8s 低 30%-50%。2.3 架构对比总结特性/方面K3sK8s标准 Kubernetes资源消耗极低512MB 内存起较高2GB 内存安装复杂度一条命令极简配置多组件手动配置学习曲线陡峭架构模式单体架构单一二进制模块化架构组件分离存储后端默认 SQLite可选 etcd/MySQL默认 etcd启动速度秒级启动分钟级大型集群网络模型轻量级内置 Flannel需单独部署 CNI 插件功能完整性核心功能完整部分高级特性简化全套功能生态丰富目标场景边缘计算、IoT、开发测试数据中心、大规模生产、复杂多租户高可用支持需额外配置原生多主节点 HA三、核心概念与组件详解面试重点3.1 必须掌握的 K8s 核心概念PodK8s 中最小的部署单元一个 Pod 可包含一个或多个容器共享网络和存储命名空间。面试常问为什么 K8s 不直接调度容器而是 Pod答案Pod 作为原子调度单位可以确保紧密耦合的容器始终运行在同一节点共享生命周期。Deployment管理无状态应用的声明式更新控制器支持滚动更新、回滚、扩缩容。核心字段replicas、strategyRollingUpdate/Recreate、selector。Service抽象一组 Pod 的访问策略提供稳定的 ClusterIP。类型包括ClusterIP集群内部访问NodePort节点端口暴露LoadBalancer云厂商负载均衡ExternalNameDNS 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 的 MasterAgent运行工作负载的节点相当于 K8s 的 Worker通过k3s agent命令加入集群四、部署实践从零搭建生产级集群4.1 标准 K8s 生产部署kubeadm 方式环境准备所有节点# 关闭 Swapswapoff-ased-i/swap/d/etc/fstab# 配置内核参数catEOF|sudotee/etc/modules-load.d/k8s.confoverlay br_netfilter EOFmodprobe overlay modprobe br_netfiltercatEOF|sudotee/etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOFsysctl--system# 安装 containerdapt-getupdateapt-getinstall-ycontainerdmkdir-p/etc/containerdcontainerd config default/etc/containerd/config.toml systemctl restart containerd# 安装 kubeadm, kubelet, kubectlapt-getinstall-yapt-transport-https ca-certificatescurlcurl-fsSLhttps://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key|gpg--dearmor-o/etc/apt/keyrings/kubernetes-apt-keyring.gpgechodeb [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.listapt-getupdateapt-getinstall-ykubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl初始化控制平面# 主节点初始化kubeadm init --pod-network-cidr10.244.0.0/16 --control-plane-endpointlb.k8s.local:6443# 配置 kubectlmkdir-p$HOME/.kubecp-i/etc/kubernetes/admin.conf$HOME/.kube/configchown$(id-u):$(id-g)$HOME/.kube/config# 部署 CNI以 Flannel 为例kubectl apply-fhttps://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml# 工作节点加入kubeadmjoinlb.k8s.local:6443--tokentoken--discovery-token-ca-cert-hash sha256:hash高可用配置需要部署多个 Master 节点使用外部负载均衡器或 keepalived haproxy 实现 API Server 的高可用。4.2 K3s 快速部署边缘/开发场景单节点快速安装# 安装 Server自带 kubectlcurl-sfLhttps://get.k3s.io|sh-# 验证kubectl get nodes kubectl get pods-A# 查看配置cat/etc/rancher/k3s/k3s.yaml# kubeconfig 文件高可用模式嵌入式 etcd# 第一个 Server 节点curl-sfLhttps://get.k3s.io|sh-s- server --cluster-init --tls-sanLB_IP# 后续 Server 节点加入curl-sfLhttps://get.k3s.io|sh-s- server--serverhttps://first-server:6443--tokentoken# Agent 节点加入curl-sfLhttps://get.k3s.io|sh-s- agent--serverhttps://server-ip:6443--tokentoken使用外部数据库MySQL/PostgreSQLcurl-sfLhttps://get.k3s.io|sh-s- server --datastore-endpointmysql://user:passwordtcp(hostname:3306)/database4.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-allNetworkPolicy再为特定 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深度监控和告警遵循 REDRate, Errors, Duration和 USEUtilization, Saturation, Errors方法ELK / EFK / Loki日志聚合和分析Jaeger / Zipkin分布式链路追踪关键告警项节点磁盘压力、内存压力、PID 压力Pod 重启频率、OOMKilled 事件API Server 延迟、etcd leader 变化Certificate 过期时间5.4 资源管理与优化QoS 等级Guaranteedrequests limits所有资源最高优先级适合核心服务Burstablerequests limits中等优先级BestEffort未设置 requests/limits最低优先级最先被驱逐必须设置资源限制resources:requests:memory:128Micpu:100mlimits:memory:256Micpu:200mHPA水平 Pod 自动伸缩apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:my-app-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:my-appminReplicas:2maxReplicas:10metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:705.5 发布策略策略描述适用场景滚动更新 (RollingUpdate)逐步替换旧 Pod默认策略常规发布零停机重建 (Recreate)先删除所有旧 Pod再创建新 Pod允许短暂停机资源受限蓝绿部署并行部署两套环境瞬时切换需要快速回滚资源充足金丝雀 (Canary)先发布少量流量验证再逐步扩大高风险变更需要 A/B 测试灰度发布基于用户/请求特征分流微服务架构精细化控制六、K8s vs K3s 场景化选择决策树是否需要管理 100 节点或复杂多租户 ├── 是 → 选择标准 K8skubeadm / 托管版 / OpenShift │ └── 是否需要极致资源优化 │ └── 是 → 考虑 K3s 作为边缘节点接入K3s Rancher 统一管理 └── 否 → 资源是否受限2GB 内存 / 边缘设备 / IoT ├── 是 → 选择 K3s单节点 SQLite 或多节点 etcd HA └── 否 → 是否需要快速验证 / 开发测试 ├── 是 → K3s秒级启动一键安装 └── 否 → 标准 K8s生态丰富长期维护七、高频面试题精讲与通关攻略7.1 基础概念类Q1Pod 和 Container 的区别是什么为什么 K8s 要引入 Pod答Container 是应用运行的实际载体而 Pod 是 K8s 的最小调度单元。引入 Pod 的原因紧密耦合同一 Pod 内的容器共享网络命名空间localhost 互通和存储卷适合 Sidecar 模式如日志收集、代理原子调度确保辅助容器和业务容器始终同节点运行生命周期管理统一创建、销毁共享上下文Q2Service 的 ClusterIP 是如何实现的kube-proxy 的三种模式有什么区别答ClusterIP 通过虚拟 IP 实现后端机制依赖 kube-proxyuserspace早期模式用户态转发性能差已废弃iptables默认模式通过 iptables 规则直接 DNAT 到 Pod IP性能较好但规则量大时更新慢ipvs内核态负载均衡支持更多后端算法rr/wlc/lc 等大规模集群性能更优K3s 中简化了 kube-proxy 依赖部分场景直接使用更轻量的网络方案。7.2 架构设计类Q3etcd 在 K8s 中的作用是什么如果 etcd 数据丢失会怎样答etcd 是 K8s 的大脑存储所有集群状态Pod 信息、配置、Secret 等。数据丢失会导致集群完全不可恢复无备份情况下所有资源定义丢失应用状态无法重建保护措施定期快照、启用 etcd 加密、限制网络访问、3 节点以上 HA 部署。Q4K3s 为什么能用 SQLite 替代 etcd什么情况下必须切回 etcd答SQLite 是嵌入式数据库单节点场景下性能足够且资源占用极低。K3s 将控制平面组件作为单一进程SQLite 的并发访问模式可以满足需求。必须切换场景多节点高可用HA部署SQLite 不支持多节点并发写入大规模集群100 节点SQLite 的写入性能瓶颈需要强一致性分布式事务的场景。7.3 实战操作类Q5如何排查一个 Pod 一直处于 Pending 状态的问题答排查链路kubectl describe pod name→ 查看 Events 字段常见原因资源不足节点 CPU/内存不足需扩容或调整 requests节点亲和性/污点不匹配检查 nodeSelector、taints/tolerationsPVC 未绑定检查 StorageClass 和 PV 供给状态镜像拉取失败检查 imagePullSecrets、镜像地址、网络连通性kubectl get nodes -o yaml查看节点资源使用情况查看 scheduler 日志kubectl logs -n kube-system kube-scheduler-xxxQ6如何实现零停机发布Deployment 的滚动更新策略如何配置答spec:strategy:type:RollingUpdaterollingUpdate: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 集群纳入统一管控平面Q8K3s 能否完全替代 K8s在企业核心生产环境中使用 K3s 有什么风险答不能完全替代。K3s 移除了部分非核心组件和高级特性默认不包含 Dashboard需手动安装部分高级网络插件支持有限生态工具兼容性虽高但大规模集群性能不如标准 K8s社区相对较小复杂问题排查资料较少风险在需要复杂多租户隔离、高级调度策略、大规模自动扩缩容HPA/VPA 全功能、深度自定义 CNI/CSI 的场景下K3s 可能无法满足需求。7.5 高级进阶类Q9如何设计一个跨地域的 K8s 多集群方案答集群联邦Karmada / Federation v2统一管理多集群资源分发服务网格Istio / Linkerd跨集群服务发现和流量治理全局负载均衡GSLBGlobal Server Load Balancing分发用户流量到最近集群数据同步使用 Velero 跨集群备份恢复或数据库级主从同步监控统一Thanos / Cortex 聚合多集群 Prometheus 数据Q10K8s 集群升级的最佳实践是什么答升级前备份 etcd、验证应用兼容性、阅读 Release Notes控制平面先升级 Master 节点kubeadm upgrade apply遵循 1 个小版本原则如 1.28 → 1.29工作节点逐个节点 drain → 升级 kubelet → uncordonCNI/CSI确认插件版本兼容验证Sonobuoy 运行一致性测试检查核心功能八、学习路径与技能图谱8.1 初学者路径1-3 个月容器基础Docker 镜像构建、容器运行时原理、OCI 规范本地体验Minikube / k3s 单机部署熟悉 kubectl 基本操作核心资源深入理解 Pod、Deployment、Service、ConfigMap、Secret网络基础CNI 原理、Service DNS 解析、Ingress 配置存储基础EmptyDir、HostPath、PV/PVC/StorageClass8.2 进阶路径3-6 个月集群部署使用 kubeadm 搭建高可用 K8s 集群调度深度亲和性/反亲和性、污点/容忍、资源配额安全加固RBAC、NetworkPolicy、PodSecurity、Secret 加密可观测性Prometheus Grafana 监控体系搭建EFK 日志收集CI/CD 集成Jenkins / GitLab CI / ArgoCD 与 K8s 结合8.3 专家路径6 个月以上二次开发Operator 开发、CRD 定义、Controller 编写性能调优API Server 调优、etcd 优化、大规模集群架构多集群管理Karmada、Rancher、OpenShift 多集群方案云原生生态Istio 服务网格、Knative Serverless、Dapr 应用运行时边缘场景K3s 大规模部署、边缘节点自治、弱网环境优化九、总结面试通关的核心思维掌握 K8s 和 K3s 不仅仅是记住命令和配置更重要的是建立**“场景-架构-决策”**的思维框架资源受限场景→ 想到 K3s 的轻量和快速大规模高可用场景→ 想到标准 K8s 的模块化和生态安全问题→ 从认证、授权、准入、网络隔离四层思考故障排查→ 从 Pod → Node → Control Plane → Network 逐层定位架构设计→ 始终围绕 CAP 理论、高可用、可观测性、可恢复性展开