【Kubernetes】以LOL的视角打开K8s

前言

对于大部分后端程序员乃至于非后端程序员来说，在当前的云原生时代，Kubernetes（后称K8s）都是绕不开的一项技术；同时，对于这个时代的程序员来说，“英雄联盟”（后称LOL）也是陪伴包括我在内的很多人成长的一款游戏。

在我的工作经历中，常常在组内有小伙伴需要使用到K8s的时候对K8s没有必要的概念，但是我发现和他们聊起LOL却总能找到共同语言，所以我就在想，既然K8s本身的学习曲线不是那么平缓，那么是不是可以借助LOL来帮大家理解什么是K8s呢？

目的

本系列文章的目的是借助LOL，帮大家更好地理解K8s，入门K8s，上手K8s。

设计的内核

每一项产品都有它的一个设计的内核，对于LOL来说，它本质是一款游戏，它的内核就是“通过各种手段，摧毁对方的基地”，不管你是通过兵线运营、击杀对手、控制中立资源，这所有的一切都是围绕最终的目的：摧毁对方的基地，来服务的

那么对于K8s来说，设计的内核就是更好的进行容器的管理（对于什么是容器，不在本文的讨论范围内，可以自行搜索一下），不管是我们创建deployment，service，statefulset，我们最终的目的，都是对容器进行管控，让封装在容器内的应用更好的运行。

LOL的英雄 - K8s的容器

LOL的一局游戏是根据这局游戏中的10位英雄展开的。不同的英雄有不同的定位：有些是AP英雄、有些是AD英雄；有些擅长输出，有些擅长辅助。
在这里插入图片描述

同样，对于K8s来说，一套K8s集群都是围绕着集群中的容器在运转，就像k8s官方描述的那样，它是一个容器编排平台。搭载不同业务的容器有不同的编排方式：有些需要持久化数据，有些只用处理一些无状态的请求；有些需要对外暴露端口，有些则在容器内自己玩就行。

LOL的英雄定位 - K8s的工作负载资源

在LOL中，有了英雄，我们要给它分配不同的定位：上路、中路、下路、打野、辅助，不同场景需要不同定位的英雄，比如作为辅助的风女就是没办法替代盲僧取野区刷野，作为战士的盖伦也没法替代女枪在后期作为射手提供输出。
在这里插入图片描述

K8s也是一样，有了镜像或者说应用，我们要给它配置不同的工作负载资源Workload Resources。K8s中的工作负载资源（Workload Resources）是用于管理应用的部署、扩展和操作的核心概念。这些资源帮助用户定义应用程序的期望状态，并自动处理实际状态与期望状态之间的差异。以下是几种主要的工作负载资源及其适用场景：

🌀 Deployment

功能：管理无状态应用的 Pod 副本集，支持声明式更新、滚动升级和回滚。
核心特性：

滚动更新：通过 maxUnavailable（最大不可用 Pod 数）和 maxSurge（最大额外 Pod 数）控制更新节奏。
自动恢复：Pod 故障时自动替换，确保副本数符合预期。
版本控制：保留历史版本（默认 10 个），支持一键回滚。
适用场景：
Web 服务、API 网关等无需持久化状态的应用。
需频繁更新或动态扩缩容的服务（如微服务后端）。

🧩 StatefulSet

功能：专为有状态应用设计，提供稳定网络标识、持久化存储和有序操作。
核心特性：

稳定标识：Pod 名称固定（如 web-0、web-1），DNS 记录持久化（<pod-name>.<service-name>.svc）。
持久化存储：通过 volumeClaimTemplates 为每个 Pod 动态创建独立 PV，数据与 Pod 生命周期解耦。
有序操作：顺序创建（0→1→2）、逆序删除（2→1→0），滚动更新时按索引反向替换。
适用场景：
数据库集群（MySQL、PostgreSQL）、消息队列（Kafka、RabbitMQ）。
分布式存储系统（Elasticsearch、Cassandra）。
注意事项：
需搭配 Headless Service（ClusterIP: None）实现 DNS 解析。
PV 回收策略建议设为 Retain 防止误删数据。

📡 DaemonSet

功能：确保每个节点（或指定节点）运行一个 Pod 副本，用于节点级守护进程。
核心特性：

节点全覆盖：新节点加入时自动创建 Pod，节点移除时自动删除。
灵活调度：通过 nodeSelector 或污点容忍（Tolerations）控制部署范围。
资源优化：支持资源请求/限制配置，避免占用过多节点资源。
适用场景：
日志收集（Fluentd、Logstash）、监控代理（Prometheus Node Exporter）。
网络插件（Calico、Flannel）、安全扫描工具（Clair）。

⚡ Job

功能：管理一次性任务，确保指定数量的 Pod 成功运行后终止。
核心特性：

任务容错：支持失败重试（backoffLimit 控制重试次数）。
并行控制：通过 parallelism 设置并发 Pod 数。
适用场景：
批处理作业（如数据迁移）、AI 训练任务。

⏱️ CronJob

功能：基于时间调度的 Job 控制器，执行周期性任务。
核心特性：

Cron 表达式：灵活定义任务执行时间（如 0 * * * * 每小时）。
任务继承：继承 Job 的所有特性（如重试、并行控制）。
适用场景：
定时备份、周期报表生成、资源清理任务。

💎 工作负载资源对比表

资源类型	核心作用	关键特性	典型场景
Deployment	无状态应用管理	滚动更新、自动扩缩容、版本回滚	Web 服务、API 网关
StatefulSet	有状态应用管理	稳定网络标识、持久化存储、有序操作	数据库集群、消息队列
DaemonSet	节点级守护进程	全覆盖节点、污点容忍、自动扩缩	日志收集、网络插件
Job	一次性任务	失败重试、并行控制	批处理计算、数据迁移
CronJob	周期性任务	时间调度、继承 Job 特性	定时备份、资源清理

✅ 总结：

无状态服务首选 Deployment，有状态服务必用 StatefulSet + PVC。
节点级任务（如监控）用 DaemonSet，批处理/定时任务用 Job/CronJob。
生产环境需结合资源请求/限制（resources.requests/limits）避免资源争抢。

LOL的装备 - K8s的资源配置

在LOL中，选好了英雄，确定好了定位，还需要在实际应用中出不同的装备才能发挥这个英雄在这个定位中的最大威力。例如射手需要“最后的轻语”来实现处理前排的能力，坦克需要兰顿之兆来实现抵抗暴击的能力。
在这里插入图片描述

在K8s中也是一样，我们有了应用，也配置了工作负载，还需要其它的一些资源配置来发挥应用真正的实力。例如我们有个在线笔记的应用，我们给他配置好了StatefulSet后，还需要进一步给它配置pvc让它实现持久化笔记的能力；还需要进一步给它配置service来实现对集群外暴露接口的能力。那么常见的配置有哪些呢？

🔹 Service

功能：为Pod提供稳定访问入口，实现服务发现与负载均衡。
类型与场景：

ClusterIP：集群内部服务通信（默认）。
NodePort：通过节点IP+端口暴露服务（临时测试）。
LoadBalancer：云环境生产级外部访问（自动创建云LB）。

🔹 ConfigMap

功能：存储非敏感配置（环境变量、配置文件），解耦应用与配置。
场景：

注入环境变量（如调试开关）。
挂载配置文件（如Nginx配置）。
支持热更新（Volume挂载时自动同步）。

🔹 Secret

功能：管理敏感数据（密码、TLS证书），Base64编码存储。
类型与场景：

Opaque：自定义敏感数据（如数据库密码）。
kubernetes.io/tls：HTTPS证书（用于Ingress）。
dockerconfigjson：私有镜像仓库认证。

🔹 Ingress

功能：管理外部HTTP/S流量路由，支持域名/路径规则与SSL终止。
核心组件：

Ingress控制器（如Nginx、Traefik）处理流量。
规则：按域名/路径转发到不同Service（如/api→后端服务）。

🔹 PVC (PersistentVolumeClaim)

功能：声明持久化存储需求，抽象底层存储细节。
场景：

数据库持久化（如MySQL数据卷）。
共享存储（NFS多Pod读写）。
动态供给：通过StorageClass自动创建PV。

💎 核心对比

配置对象	核心作用	典型场景
Service	服务发现+负载均衡	微服务通信、外部流量接入
ConfigMap	非敏感配置管理	应用参数、环境变量注入
Secret	敏感数据存储	密码、TLS证书、API密钥
Ingress	HTTP/S流量路由	多域名管理、HTTPS卸载
PVC	持久化存储声明	数据库存储、日志持久化