一文让你搞懂 K8s 与 K3s

最新推荐文章于 2026-06-17 16:32:59 发布

原创最新推荐文章于 2026-06-17 16:32:59 发布 · 187 阅读

6 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#kubernetes #容器 #云原生 #后端 #docker

话题

#IT疑难杂症诊疗室

后端专栏收录该内容

10 篇文章

订阅专栏

一文让你搞懂 K8s 与 K3s

大家好，我是HLAIA光子。

这篇文章带你搞清楚 Kubernetes 和 K3s 到底是什么、怎么运作、什么场景该选哪个。看完之后，你会有一个完整的容器编排认知框架，而不只是停留在"K8s 是管容器的"这个层面。

网络上流传着这样的一种解释： K3s 就是 K8s 的缩小版，装一下就行。但如果你不理解 K8s 的架构设计，你连 K3s 在替换什么都不知道。所以我先从 K8s 讲起，搞清楚大的，再看小的怎么精简的。

容器编排是个什么问题

在一个容器里跑一个应用，很简单，docker run 就完事了。

但当你的应用拆成了十几个微服务，每个要跑 3 个副本，还要做负载均衡、滚动更新、自动扩缩容、故障自愈，手动管理就不现实了，毕竟人脑。

Kubernetes 就是来解决这个问题的。Google 基于十几年内部容器管理经验做出了这个开源项目，后来捐给了 CNCF。它给你提供了一套声明式的 API：你告诉它"我要 3 个 nginx"，它负责确保任何时候都有 3 个健康的 nginx 在跑。一个挂了它自动拉起来，要扩容改个数字就行。

截至 2026 年 5 月，Kubernetes 最新稳定版是 v1.36，代号 “Haru”，包含 70 项增强特性。

K8s 架构

理解 K8s 架构是理解一切的基础。它采用经典的 Control Plane - Worker Node 模式：Control Plane 是大脑做决策，Worker Node 是四肢干活。

K8s 集群架构图

Control Plane

Control Plane 里有四个核心组件，搞清楚它们各自干什么，K8s 的运行机制就明白了一大半。

kube-apiserver 是整个集群的通信中枢。所有组件之间的交互都通过它，它是唯一跟 etcd 直接通信的组件。可以把它理解成集群的"前台"，所有请求都要经过它认证、授权、准入控制之后才会被处理。

etcd 是集群的数据库，一个分布式的高可用键值存储，用 Raft 算法保证一致性。K8s 所有的状态数据都存在这里：有哪些 Pod、运行在哪个 Node 上、配置是什么。etcd 出问题整个集群就废了，所以生产环境通常部署 3 或 5 个节点，必须有备份策略。

kube-scheduler 是调度器。创建了一个 Pod，它负责决定这个 Pod 跑在哪个 Node 上。决策依据包括资源需求、亲和性规则、污点和容忍等。

kube-controller-manager 运行着各种控制器。控制器的工作模式就是"不断把当前状态向期望状态收敛"。你说要 3 个副本，实际只有 2 个，ReplicaSet Controller 就会自动创建一个新的。

Worker Node

每个 Worker Node 上有三个关键组件。

kubelet 是每个节点上的代理人。它接收 Pod 的定义，然后调用容器运行时去拉镜像、启动容器，并且持续监控容器的健康状态，定期向 API Server 汇报。

kube-proxy 负责网络规则。它实现了 Service 的负载均衡，把流量正确地转发到后端 Pod。工作模式有 iptables、IPVS 和较新的 nftables，推荐用 IPVS。

容器运行时 是真正跑容器的软件，通过 CRI 接口和 K8s 通信。目前最主流的是 containerd，轻量一点的选择是 CRI-O。从 v1.24 开始 K8s 已经移除了对 Docker Engine 的直接支持，但 Docker 构建的镜像照样能跑。

核心概念

K8s 的概念很比较多，这几个比较重要的概念建议深入理解，其它的其实用的不多。

Pod

Pod 是 K8s 中最小的部署单元。一个 Pod 里可以跑一个或多个容器，它们共享网络命名空间（同一个 IP，通过 localhost 互相访问）、共享存储卷、共享生命周期。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80

一般情况下一 Pod 一容器是最常见的用法。多容器 Pod 通常用于 sidecar 模式，主容器跑业务，sidecar 跑日志收集或者代理。

Service

Pod 的 IP 是不固定的，每次重建都可能变。Service 就是给一组 Pod 提供一个稳定的访问入口，固定 IP 和 DNS 名称。

Service 有四种类型。ClusterIP 是默认的，只在集群内部可达。NodePort 在每个 Node 上开一个端口让外部访问。LoadBalancer 会调用云厂商的负载均衡器。ExternalName 做的是 DNS 映射，把集群内的服务名指向一个外部域名。实际使用中最常见的是 ClusterIP 配合 Ingress。

Deployment

Deployment 是管理无状态应用的核心资源。你声明要几个副本、用什么镜像，K8s 帮你维持这个状态。

层级关系是 Deployment -> ReplicaSet -> Pod。当你做滚动更新的时候，Deployment 会创建一个新的 ReplicaSet，逐步把流量切过去，同时缩容旧的。回滚就是反向操作。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

StatefulSet

有状态应用比如数据库、消息队列，要用 StatefulSet。它提供稳定的网络标识，Pod 命名有序且固定，比如 mysql-0、mysql-1。每个 Pod 绑定独立的持久化存储，创建和删除都按顺序来。

ConfigMap 和 Secret

ConfigMap 存非敏感配置，Secret 存敏感信息，比如密码和证书。它们把配置和镜像解耦，让同一个镜像在不同环境跑不同的配置。

开发中最常见的用法是 ConfigMap 管理环境变量和配置文件，Secret 管理数据库密码和 API Key。千万别把密码硬编码到镜像里，这是新手犯得最多的错之一。

一个 Deployment 的诞生

理解了组件和概念，来看一个完整流程。当你执行 kubectl apply -f nginx.yaml 之后，K8s 内部发生了什么：

一个 Deployment 从提交到容器启动的完整流程

12 个步骤，涉及 7 个组件。核心机制是 watch：每个组件都在盯着 etcd 里的变化，一旦有新东西匹配自己的职责就立刻行动。这就是声明式 API 的精髓，你声明期望状态，各个控制器自动向那个状态收敛。

网络和存储

K8s 的网络和存储是两个大话题，这里各挑重点讲。

网络

K8s 网络有一个基本原则：每个 Pod 有独立 IP，Pod 之间直接通信，不需要 NAT。

网络分三层。最底层是 Node 网络，连接所有机器。中间是 Pod 网络，由 CNI 插件实现，给每个 Pod 分配独立 IP。最上面是 Service 网络，虚拟 IP，由 kube-proxy 实现负载均衡。

CNI 插件是实现 Pod 网络的关键。几个主流选择：Calico 性能好、支持 NetworkPolicy，适合生产环境；Cilium 基于 eBPF、可观测性很强，是现在最热门的选择；Flannel 简单轻量，适合入门和小集群。

存储

存储模型的核心是一个绑定流程：Pod → PVC → PV ← StorageClass。

PV 是集群里的一块存储资源。PVC 是用户对存储的申请，相当于说"我要一块 10G 的 SSD"。StorageClass 定义存储类型，PVC 引用它时会自动创建 PV 并绑定。

建议在 StorageClass 里设置 volumeBindingMode: WaitForFirstConsumer，这样 PV 会延迟到 Pod 调度时才创建，避免 Pod 和 PV 分布在不同可用区的尴尬。

K3s

铺垫了这么久，终于到 K3s 了。

K3s 是 Rancher Labs（现属 SUSE）开发的轻量级 Kubernetes 发行版。它是 CNCF 认证的，API 完全兼容 K8s，但打包成了一个不到 100MB 的单一二进制文件，最低 512MB 内存就能跑。

名字的由来很有意思。K8s 的含义是 Kubernetes 里 K 和 s 之间有 8 个字母。K3s 被定位为 K8s 的"一半大小"，所以 K 和 s 之间只有 3 个字母。

K3s 架构总览图

K3s 做了什么

K3s 做了几个关键替换。etcd 换成了内嵌的 SQLite，默认够用，可选 MySQL/PostgreSQL/etcd。Docker 换成了内嵌的 containerd。Ingress Controller 内嵌了 Traefik，开箱即用。CNI 内嵌了 Flannel，DNS 内嵌了 CoreDNS，存储供应内嵌了 Local Path Provisioner。

同时移除了 in-tree 云提供商代码、in-tree 存储驱动、alpha 功能和过时代码。

说白了，K3s 把 K8s 需要你手动安装和配置的一大堆组件，全部打包进了一个二进制文件。安装从几分钟甚至几小时，变成了一个命令：

curl -sfL https://get.k3s.io | sh -

就这一行，一个完整的 K8s 兼容集群就起来了。

部署模式

K3s 有几种部署模式。单节点用内嵌 SQLite，适合开发和测试。HA 模式用内嵌 etcd，至少 3 节点，适合轻量级生产。也可以接外部 MySQL/PostgreSQL 做数据存储。

高可用集群搭建也不复杂：

# 第一台 Server
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --cluster-init" sh -

# 后续 Server
curl -sfL https://get.k3s.io | \
  K3S_URL=https://<Server-IP>:6443 \
  K3S_TOKEN=<node-token> \
  INSTALL_K3S_EXEC="server" sh -

# Agent 工作节点
curl -sfL https://get.k3s.io | \
  K3S_URL=https://<Server-IP>:6443 \
  K3S_TOKEN=<node-token> sh -

K3s 还有几个贴心的特性。原生支持 ARM，在树莓派上直接跑。支持离线安装，预下载二进制和镜像就行。内置了 Helm 控制器，可以通过 CRD 直接管理 Helm Chart：

apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: nginx-ingress
  namespace: kube-system
spec:
  repo: https://kubernetes.github.io/ingress-nginx
  chart: ingress-nginx
  targetNamespace: ingress-nginx

K3d

再介绍一个相关工具。K3d 是在 Docker 里跑 K3s 的工具。如果你本地有 Docker，用 K3d 可以秒级创建一个 K8s 集群，比 Minikube 还快。

k3d cluster create demo -p "8080:80@loadbalancer" --agents 2

一条命令，一个带负载均衡器的多节点集群就起来了。做本地开发和 CI/CD 特别好用。

怎么选

K8s 适合大规模生产环境，K3s 适合量级生产。其实个人的小项目，没有用 k8s 的必要。

有一个点，K3s 是 CNCF 认证的 Kubernetes。这意味着你在 K3s 上学到的东西、写的 YAML 文件，在标准 K8s 上完全通用。学习用 K3s，生产用 K8s，迁移成本几乎为零。

写在最后

K8s 的设计哲学其实很简单，就是声明式 API 加控制器模式。你告诉系统期望状态，系统负责达到并维持那个状态。

K3s 就是把 K8s 散落的组件打包成一个文件，把重型依赖替换成轻量方案，删掉非核心代码。它没有重新发明轮子，只是让轮子更好装。

如果你觉得这篇文章有帮助，点赞关注，点点赞~