底层由物理硬件构建出一个环境，在这个环境上运行一个操作系统，对终端用户而言，当我们需要用到要给操作系统或应用实现特殊功能时，它只需要向CloudOS提出申请而就能立即申请获取一个对应的请求环境，这个环境我们可以随时终止，开启等功能。对用户而言，无需关心它所需要的计算能力从哪里来，有别于传统使用计算机操作系统的状况。云计算是一种资源交付的模式，即打包资源给客户使用。特点：基于网络，按需付费，弹性拓展

工作负载时K8S中对集群内运行的容器化应用及其实例的统称，涵盖Pod、Deployment、StatefulSet等不同形态，用于定义应用的运行状态、副本数量等，是K8S进行调度、管理和运维的核心对象。声明式配置式指在K8S中，用户只需要定义应用“期望达到的最终状态”（如Pod副本数、资源限制）。无需指定实现步骤，由K8S自动将实际状态调整未期望状态的配置方式。服务发现与负载均衡：通过 DNS 或

有状态设计：服务端会保存与客户端交互的历史状态（如用户购物车、游戏角色状态），后续请求处理依赖这些已存信息，扩展时需考虑状态同步，适合需连续上下文的场景（如在线游戏、实时聊天）。无状态设计：服务端不保存请求上下文，每个请求都包含处理所需的全部信息（如通过 JWT 携带用户信息），实例间无关联可轻松水平扩展，适合高弹性、高扩展需求的场景（如 RESTful API、静态资源服务）。

apiVersion：v1 #api版本kind：Pod #创建的资源metadata：namespace：default #Pod所在的命名空间lables：app：tomcat #Pod具有的标签spec：container：- name：tomcat-java #Pod里容器的名字ports：- containerPort:8080 #容器暴露的端口image: docker.io/libr

在K8s管理中，YAML资源清单是定义、创建和管理资源的核心载体。本文将系统梳理YAML编写技巧、Pod管理、命名空间、标签、节点调度（亲和性/污点）等核心能力，结合实操命令与配置示例，帮助高效掌握K8s资源管理。

在K8s的Pod管理体系中，ReplicaSet（简称RS）是承担“副本保障”核心职责的基础控制器，其设计初衷是解决“自主式Pod故障无法自愈”的痛点---通过持续监控与动态调整，确保集群中目标Pod的副本数量始终匹配用户预设值，为业务稳定性提供基础支撑。从核心功能来看，RS的作用可拆解为三点：副本数量管控。

存储方案适用场景优点缺点EmptyDir临时数据、容器间共享临时文件（如缓存）无需配置，随 Pod 自动创建数据不持久，Pod 删除后丢失HostPath单节点测试、节点级日志存储配置简单，数据在节点本地持久化不支持跨节点，存在单点故障NFS中小规模集群、多 Pod 共享数据（如配置文件）跨节点共享，部署简单服务端单点故障（需高可用 NFS 集群）PV/PVC生产环境固定存储需求（如数据库）解耦存

在 Kubernetes 中，Deployment、ReplicaSet 等控制器主要用于管理（如 Web 应用），这类服务的 Pod 实例可随意替换，IP、名称不影响服务可用性。但对于 MySQL 主从、Redis 集群、ZooKeeper 等，Pod 实例需保持固定标识、独立存储和有序启停，StatefulSet 正是为解决这类需求而设计的核心控制器。

DaemonSet控制器的设计理念是“节点伴随式部署”：当集群新增节点时，Daemonset会自动在新节点上创建指定Pod；当节点从集群移除时，对应的Pod也会被自动删除；若删除DaemonSet，其管理的所有Pod会被批量清理。核心特征单节点单副本：每个节点最多运行一个 DaemonSet Pod（避免资源浪费与功能冲突）；节点自动适配：无需手动调度，DaemonSet 自动感知节点变化并同步

kind: Rolemetadata:name: pod-reader # 角色名namespace: default # 仅作用于 default 命名空间rules: # 权限规则列表- apiGroups: [""] # API 组（空字符串表示核心 API 组，如 pods、services）resources: ["pods"] # 资源类型（如 pods、configmaps、depl