自学Kubernestes（k8s）Day1 -- 核心基础概念

学习路径参考：公司业务上用到了 K8S，但是主包没学过。所以主包是先依靠 AI 和技术社区分享完成了业务后，再返回来学习对应知识的。

学习工具：Gemini（笔记梳理和知识点扩展）+ BiliBili 上的网课-叩丁狼（知识点串联）

### 目录

[@[TOC](目录)](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[一、Kubernetes 的定义](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[二、部署方式演进与对比](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[2.1 传统部署](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[2.2 虚拟化部署](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[2.3 容器化部署](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[2.4 对比简述](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[三、核心概念](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[3.1 有状态服务 vs 无状态服务](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[3.2 对象规约和状态](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[四、资源分类：元数据、集群、命名空间](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[4.1 集群 (Cluster) ------ 整个大酒店](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[4.2 命名空间 (Namespace) ------ 酒店里的房间/包厢](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[4.3 元数据 (Metadata) ------ 客人的身份证](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[4.4 资源作用域 (Scope)](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[五、元数据资源](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[5.1 自动扩缩容（HPA）](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[5.2 定义模具（PodTemplate）](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[5.3 单体边界（LimitRange）](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[六、集群资源](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[七、命名空间资源](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[7.1 工作负载](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[7.1.1 Pod](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[7.1.2 控制器](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[A. Deployment ------ 全能管家（最常用）](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[B. StatefulSet ------ 专属管家](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[C. DaemonSet ------ 守护神](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[D. Job / CronJob ------ 临时工](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[7.2 服务发现](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[7.2.1 Service：集群内部的通信枢纽 (Layer 4)](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7)](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[7.3 存储、配置和角色](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[7.3.1 存储](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[7.3.2 配置](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)
[7.3.3 角色](#目录 @TOC 一、Kubernetes 的定义二、部署方式演进与对比 2.1 传统部署 2.2 虚拟化部署 2.3 容器化部署 2.4 对比简述三、核心概念 3.1 有状态服务 vs 无状态服务 3.2 对象规约和状态四、资源分类：元数据、集群、命名空间 4.1 集群 (Cluster) —— 整个大酒店 4.2 命名空间 (Namespace) —— 酒店里的房间/包厢 4.3 元数据 (Metadata) —— 客人的身份证 4.4 资源作用域 (Scope) 五、元数据资源 5.1 自动扩缩容（HPA） 5.2 定义模具（PodTemplate） 5.3 单体边界（LimitRange）六、集群资源七、命名空间资源 7.1 工作负载 7.1.1 Pod 7.1.2 控制器 A. Deployment —— 全能管家（最常用） B. StatefulSet —— 专属管家 C. DaemonSet —— 守护神 D. Job / CronJob —— 临时工 7.2 服务发现 7.2.1 Service：集群内部的通信枢纽 (Layer 4) 7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7) 7.3 存储、配置和角色 7.3.1 存储 7.3.2 配置 7.3.3 角色)

一、Kubernetes 的定义

Kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化应用。Kubernetes 的目标是让部署容器化的应用简单并且高效。

核心公式 ：Kubernetes = 容器技术 + 自动化管理能力

二、部署方式演进与对比

2.1 传统部署

定义：操作系统直接装在物理裸机上，所有应用（Java, Nginx, MySQL）共享这台机器的资源。

缺点：

资源利用率极低（最痛的点）：为了防止应用互相抢资源，通常一台物理机只跑一个核心应用。但这台机器可能有 64 核 CPU，应用只用了 5%，剩下的 95% 全浪费了。
依赖冲突：如果在同一台机器上跑两个应用，A 应用需要 Python 2.7，B 应用需要 Python 3.0，它们会因为库文件冲突打得不可开交，甚至导致崩溃。
扩展和迁移极慢、成本高昂

2.2 虚拟化部署

定义：在物理机操作系统上加了一层 Hypervisor，把硬件切分成多个虚拟机（VM）。每个 VM 就是一台完整的电脑，有自己独立的操作系统（Guest OS）。

缺点：

太重了（Guest OS 损耗）：每个 VM 都要装一个完整的 Linux/Windows 操作系统。哪怕你只想跑一个 10MB 的小脚本，你也得先启动一个 2GB 大小的操作系统。
启动慢：启动一个虚拟机等于开机，需要几分钟的时间。这在应对突发流量（如秒杀活动）时是致命的。
环境不一致：虽然比物理机好，但 VM 里的环境还是要人工配置。开发环境是 CentOS 7.5，生产环境是 CentOS 7.6，依然可能出现"我本地是好的，上线就报错"的问题。

2.3 容器化部署

定义：容器共享宿主机的操作系统内核，不再需要 Guest OS，只打包应用代码和依赖库。

缺点：

无法跨主机调度：Docker 只能管自己这台机器上的容器。如果你有 100 台服务器，你需要手动决定把容器扔到哪台机器上。
网络通信困难：机器 A 上的容器想访问机器 B 上的容器，在没有 K8s 的情况下，你需要做极其复杂的端口映射（Port Mapping）和网络路由配置。
没有自愈能力：如果容器挂了（Crash），你需要写脚本监控它，然后手动重启它。如果整台机器断电了，上面的容器全死，没人会自动把它们迁移到好的机器上。
很难动态扩缩容：流量来了，你想把 10 个容器变成 100 个，你需要一个个手动去敲命令 docker run，等敲完流量高峰都过了。

2.4 对比简述

部署方式	核心痛点	层面
传统部署	笨重、浪费、冲突	物理层面的痛
虚拟化部署	隔离好了，但还是太重，启动慢	操作系统层面的痛
裸容器部署	轻便快，但没人管，容易乱	管理层面的痛

三、核心概念

3.1 有状态服务 vs 无状态服务

类型	定义	特点
有状态服务	服务实例保存了特定的数据或状态	Pod 挂掉重启后，必须能找回原来的数据（磁盘）和身份（网络 ID）
无状态服务	服务运行实例不保存任何数据	每次请求都是独立的，随便发给哪个实例处理都一样

3.2 对象规约和状态

比喻：空调恒温系统

Spec (规约) = 你的遥控器设置
- 你拿起遥控器，把温度设定为 26℃。这是你的期望状态（你想要它达到的目标）。
Status (状态) = 房间的温度计读数
- 空调上的显示屏显示当前室温是 30℃。这是实际状态（目前真实的情况）。
K8S 的工作（控制器）= 空调压缩机
- 空调发现"设定 26℃"与"当前 30℃"不一致，于是拼命工作（制冷），试图让实际状态（Status）逐渐趋近于期望状态（Spec）。

核心机制 ：这种分离设计是 K8S 自我修复能力的基础。K8S 内部有一个死循环（Loop），不停地对比 Spec 和 Status，并调整 Status，直到 Spec == Status，系统达到平衡。

四、资源分类：元数据、集群、命名空间

4.1 集群 (Cluster) ------ 整个大酒店

定义：K8S 的最高层级物理/逻辑单位。相当于整栋酒店大楼。
包含：所有的节点（服务器）、网络、存储，以及里面运行的所有程序。
作用：它是一个大的资源池。当你安装好 K8S 时，你就拥有了一个集群。

4.2 命名空间 (Namespace) ------ 酒店里的房间/包厢

定义：集群内部的逻辑隔离区。相当于酒店里的不同包厢（比如"VIP厅"、"大堂"、"员工休息室"）。
作用：
1. 隔离：你在"VIP厅"里大喊大叫，不会吵到"大堂"的人。
2. 防冲突：两个不同的包厢里都可以有一个叫"张三"的人（在 K8S 中，不同命名空间可以有同名的 Service 或 Deployment）。
3. 管理：通常我们会划分 dev（开发环境）、test（测试环境）、prod（生产环境）这几个命名空间。
默认空间 ：如果你不指定，K8S 会把你放到 default（大堂）里。

4.3 元数据 (Metadata) ------ 客人的身份证

定义：描述资源对象身份的信息。相当于客人的身份证和房卡。
包含：
- name：你叫什么名字？（例如：my-nginx）
- namespace：你住在哪个房间？（例如：prod）
- labels：你有什么标签？（例如：vip-guest, male）
- uid：全网唯一的身份证号
位置：它是每个 K8S 资源 YAML 文件最开头必填的那一部分。

4.4 资源作用域 (Scope)

作用域	定义	示例
命名空间级资源 (Namespaced)	必须呆在某个 Namespace 里，删除命名空间则资源全部清空	Pod、Deployment、Service、ConfigMap
集群级资源 (Cluster-scoped)	不属于任何房间，属于整个大楼公共区域，全局唯一	Node、Namespace、PersistentVolume (PV)

五、元数据资源

5.1 自动扩缩容（HPA）

定义：监控 Pod 的负载（主要是 CPU 利用率或内存），当负载超过你设定的阈值（比如 CPU > 50%），它就自动修改 Deployment 的副本数（replicas）。
核心配置 ：
- minReplicas：最少保留几个？
- maxReplicas：最多能扩到几个？
- targetCPUUtilizationPercentage：CPU 到了多少百分比就开始扩容？

5.2 定义模具（PodTemplate）

定义：描述一个 Pod 长什么样子的图纸。
特殊之处 ：
- 你几乎永远不会单独创建一个叫 PodTemplate 的资源。
- 它通常是作为一部分（嵌套）写在 Deployment、StatefulSet、DaemonSet、Job 的 YAML 文件里的。
- 在 YAML 里看到 spec.template 字段，那一块内容就是 PodTemplate。它定义了：要用什么镜像？开什么端口？挂载什么盘？

5.3 单体边界（LimitRange）

定义：限制一个命名空间（Namespace）里，单个 Pod 或 Container 能用的最小和最大资源。
意义：防止小白部署一个巨大的 Pod 导致整个 Node 卡死，或是自动填写默认资源值。

六、集群资源

资源	定义
Node（节点）	集群中的一台物理机器或虚拟机，是真正干活的地方，所有 Pod（应用）最终都要跑在 Node 上，是计算资源的提供者
Namespace（命名空间）	集群内部的逻辑隔离，它将资源隔离开
ClusterRole	一组权限的集合（只定义权限，不指定给谁），定义"这个角色能干什么"，权限通常是跨命名空间的，或者是针对集群资源的
ClusterRoleBinding	将一个用户 (Subject) 和一个集群角色 (ClusterRole) 绑在一起。属于正式授权，作用是将上面的"职位说明书"落实到具体的人头上

场景理解：在一个 K8S 集群里，有很多 Node（机器），我们划分了不同的 Namespace（部门）。为了管理安全，我们定义了 ClusterRole（CEO 职位），并通过 ClusterRoleBinding（任命书）把这个职位给了管理员，让他能管理所有的机器和部门。

七、命名空间资源

7.1 工作负载

7.1.1 Pod

核心定义：Pod 是 Kubernetes 中的最小积木，K8S 不直接管理容器，它管理的是 Pod。

为什么不直接管容器？

可以将 Pod 想像成豌豆荚 ，容器想像成豌豆粒。有时候，两个程序（两个豌豆粒）必须紧紧粘在一起才能工作（比如：一个主程序写日志，另一个小助手负责收集日志传到服务器）：

它们需要共享同一个网络 IP（能互相用 localhost 访问）
它们需要共享同一个存储卷（一个写文件，一个读文件）
它们必须同生共死（一起启动，一起销毁）

Docker 容器之间是隔离的，要把它们捆绑在一起很难。所以 K8S 发明了 Pod，作为一个"逻辑主机"，把这些亲密关系的容器包在一起，无论调度到哪台机器，它们都永远在一起，不离不弃。

Pod 的三大核心特征：

特征	说明
最小部署单元	K8S 创建、调度、管理的最小单位是 Pod，而不是 Container。哪怕你只运行一个 Nginx，K8S 也会给它包一个 Pod 的壳
共享网络 (Shared Network)	Pod 里的所有容器，共用同一个 IP 地址。容器 A 想找容器 B，直接访问 `localhost:端口` 就行
共享存储 (Shared Storage)	Pod 可以挂载一个数据卷（Volume），Pod 里的所有容器都能读写这个卷

Pod 的生命周期：

没有自愈能力：如果 Pod 所在的机器挂了，或者 Pod 崩溃了，K8S 不会自动修好它，而是直接把它删了。
IP 不固定：每次 Pod 重启，IP 都会变。

7.1.2 控制器

如果说 Pod 是 K8S 世界里的"打工仔 "（干活的原子单位），那么控制器 (Controller) 就是"包工头"（管理者）。

在 K8S 中，我们几乎从不直接创建一个 Pod。为什么？因为 Pod 很脆弱，它挂了就挂了，不会自己复活。

控制器的核心职责：保证集群内的"打工仔"数量和状态，永远和你要求的（Spec）保持一致。

核心工作原理 - 调谐循环 (Reconcile Loop)：

控制器内部都在跑一个死循环，它的工作逻辑极其简单，就像空调恒温器：

观察 (Observe)：现在的实际情况是什么？（比如：现在只有 2 个 Pod 在跑）
对比 (Diff) ：用户期望的是什么？（比如：用户在 YAML 里写了 replicas: 3）
行动 (Act)：有差距怎么办？（比如：差距是 -1，那就去 API Server 申请创建一个新 Pod）

只要差距（Diff）存在，控制器就不会停下来，直到 现实 = 期望。

A. Deployment ------ 全能管家（最常用）

适用场景：无状态服务（Web Server, API, 微服务）
管理对象：ReplicaSet（它其实是 Deployment 的副手，帮它管 Pod 数目）

核心能力：

维持副本数：说了要 3 个，就死保 3 个
滚动更新 (Rolling Update)：这是 Deployment 的杀手锏。当你升级镜像时，它会"起一个新 Pod，杀一个旧 Pod"，平滑过渡，服务不中断
版本回滚：升级失败了？一条命令就能回退到上个版本

特点：它管理的 Pod 是"牲畜"，名字是乱码，谁死谁活无所谓，能干活就行。

层级关系 ：

Deployment (总监：宏观调控、发布版本、回滚)

└── ReplicaSet (组长：数人头、保证 Pod 数量)

└── Pod (工人：干活)

我们在写 YAML 时只需要写 Deployment，K8S 会自动处理中间这层关系。

B. StatefulSet ------ 专属管家

适用场景：有状态服务（数据库 MySQL, Redis, 消息队列 Kafka）

四大核心能力：

能力	机制	意义
稳定的持久化存储	使用 `volumeClaimTemplates`，K8S 会自动为每个 Pod 创建一个专属的 PVC，名字通常是 `{pvc名}-{pod名}`	确保数据不丢失，且数据与特定的 Pod ID 强绑定
稳定的网络标识	Headless Service，Pod 的 DNS 格式为：`{statefulsetName}-{0..N-1}.{serviceName}.{namespace}.svc.cluster.local`	无论 Pod 重启多少次，IP 怎么变，域名永远不变。集群内的其他节点可以通过域名精准找到它
有序部署和扩容	必须先启动 `web-0`，成功了再启动 `web-1`	适用于有启动依赖的应用
有序的删除和缩容	如果要删除集群，会先删 `mysql-2`，再删 `mysql-1`，最后删 `mysql-0`	保证数据安全，允许集群平滑地将数据迁移或做下线处理

特点：StatefulSet 就像是给每个 Pod 发了身份证（网络域名）和房产证（PVC） ，并且严格规定了长幼尊卑（启动顺序）。

C. DaemonSet ------ 守护神

职责：确保在每一个**符合条件（Matched）**的 Node 上，运行且只运行一个 Pod 的副本
适用场景：节点级系统服务（日志收集 Fluentd, 监控探针 Prometheus Node Exporter, 网络插件 kube-proxy）

核心能力：

筛选器 (Node Selector / Affinity) ：在 DaemonSet 的 YAML 里写了 nodeSelector: type=logs，这意味着："我只去贴了'日志型'标签的机器上干活"
动态感知能力：DaemonSet 的强大之处在于它对节点状态变化的实时响应

特点：它根据你设定的筛选规则（Selector），自动确保每一个符合条件的节点上都运行着一个守护进程。

D. Job / CronJob ------ 临时工

适用场景：批处理任务

类型	说明	特点
Job	一次性任务（如：数据库备份、大数据计算）	Pod 运行完任务退出（状态变成 Completed）后，不会重启。控制器的任务是确保这个任务"成功完成一次"
CronJob	定时任务（如：每天凌晨 2 点清理日志）	基于 Linux Cron 表达式，定时生成一个 Job

7.2 服务发现

7.2.1 Service：集群内部的通信枢纽 (Layer 4)

核心定义：Service 是对一组提供相同功能的 Pod 的抽象，它提供了一个虚拟的 VIP (ClusterIP) 和稳定的 DNS 名称。

A. 核心组件：Selector 与 Endpoints

标签选择 (Selector) ：Service 通过 selector 字段（如 app: nginx）去寻找带有对应 Label 的 Pod
Endpoints 控制器 ：K8S 会自动创建一个同名的 Endpoints 对象，里面实时存储着所有匹配 Pod 的 IP:Port 列表
kube-proxy：每个 Node 上的 kube-proxy 监听到 Service 和 Endpoints 的变化，会在本机配置 iptables 或 IPVS 规则

流量走向 ：

Client -> Service VIP -> (kube-proxy 规则截获) -> 随机转发给某个 Pod IP

B. Service 的四种类型 (Type)

类型	描述	访问范围
ClusterIP（默认）	分配一个集群内部的虚拟 IP。此 IP 只能在集群内部访问，外部 ping 不通	仅集群内
NodePort	在每一台 Node 节点上开放一个静态端口 (30000-32767)	集群外（通过 NodeIP:Port）
LoadBalancer	依赖云厂商 (AWS, 阿里云) 的接口，自动购买并绑定一个外部的硬件/软件负载均衡器	公网/专线（通过公网 IP）
ExternalName	没有任何 VIP 和代理。它在 DNS 层面把 Service 名映射到一个外部域名 (CNAME)	集群内访问外部

C. Service 的 DNS 发现机制

CoreDNS 会为每个 Service 生成一个域名，标准格式：..svc.cluster.local

7.2.2 Ingress：集群的 HTTP/HTTPS 大门 (Layer 7)

核心定义 ：Ingress 不是 Service，它是作用在 Service 之上的反向代理路由规则集合。

Service 是四层的（基于 IP+端口），无法理解 HTTP 协议（比如域名、URL 路径）。Ingress 填补了这一空白，它负责根据 Host（域名） 和 Path（路径） 将流量分发到不同的后端 Service。

A. 架构分离：资源 vs 控制器（关键考点）

组件	说明
Ingress Resource（资源对象）	这就是你写的 YAML 文件，它只是一张"配置单"，写着："a.com 转给 Service A，b.com/api 转给 Service B"。光有 YAML，没有任何用处，流量不会通。
Ingress Controller（控制器）	这是真正干活的程序（如 Nginx Ingress Controller, Traefik, Istio），它是一个特殊的 Pod，监听 K8S API，一旦发现你创建了 Ingress YAML，它会立马解析规则，并动态修改自己的配置文件（如 `nginx.conf`）并重载。注意：K8S 不自带 Ingress Controller，你必须自己安装一个。

B. Ingress 的核心路由能力

Ingress 解决了"一个 IP 对应多个服务"的问题（省钱）：

基于域名的路由 (Host-based Routing) ：
- foo.bar.com -> Service 1
- api.bar.com -> Service 2
基于路径的路由 (Path-based Routing) ：
- bar.com/web -> Service Frontend
- bar.com/api -> Service Backend
TLS/SSL 终结 (TLS Termination)：证书配置在 Ingress 层。HTTPS 流量到了 Ingress 解密，然后变成 HTTP 转发给后端 Service，减轻后端负担。

C. 核心总结

组件	职责	层级
Service	管道，负责打通 Pod 之间的网络，做四层负载均衡	L4
Ingress	分流器，负责解析 HTTP 协议，管理域名和证书，做七层路由	L7

通常生产环境架构 ：

外部 LB -> Ingress -> Service -> Pod

7.3 存储、配置和角色

7.3.1 存储

资源	说明
Volume	数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据
CSI	Container Storage Interface，是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序

7.3.2 配置

资源	说明
ConfigMap	存储明文配置（如配置文件、环境变量），将配置数据与容器镜像解耦，让你不重新打镜像也能修改应用配置
Secret	存储敏感信息（如密码、证书、Token），本质上是加密/编码版的 ConfigMap，专门保护机密数据不被泄露
Downward API	让容器具备"自省"能力，将 Pod 自身的元数据（如"我的 IP 是多少"、"我所在的 Node 叫什么"）通过环境变量或文件暴露给容器内部的应用使用

7.3.3 角色

资源	说明
Role	定义了一组权限规则（Rule），规定了能对哪些资源做什么操作（增删改查）。局限于某个命名空间
RoleBinding	是将"岗位职责"（Role）正式授权给某个"员工"（User/Group），使其在特定"部门"（Namespace）内生效的连接器

RBAC 常用组合公式：

组合	效果
`Role + RoleBinding`	只有这个部门能用的自定义岗位（专用）
`ClusterRole + ClusterRoleBinding`	全公司的超级岗位（大神）
`ClusterRole + RoleBinding`	借用集团的标准岗位定义，但只在这个部门干活（最常用）