一、K8s 的起源与定位（知其然也知其所以然）

1. 发展背景

• 前身：谷歌内部的 Borg/Omega 系统（管理超百万容器，运行十多年），2014 年谷歌将 Borg 核心思想开源为 K8s；
• 托管：2015 年捐赠给 CNCF（云原生计算基金会），成为 CNCF 首个毕业项目，目前是云原生领域的 “事实标准”；
• 版本：采用语义化版本（如 v1.27.6），每 3 个月发布一个小版本，长期支持版（LTS）支持 1 年以上（如 v1.28 是 LTS）。

2. 核心定位（终极目标）

K8s 是开源的、跨平台的容器编排与管理平台，核心是 “自动化管理容器化应用的全生命周期”，覆盖 “部署→运行→扩缩容→更新→故障恢复→销毁” 全流程，让应用部署从 “手工运维” 走向 “声明式自动化”。

3. 与传统运维 / 纯容器的对比（为什么选 K8s）

 

方式	痛点	K8s 的解决方案
物理机 / 虚拟机部署	资源利用率低、部署慢、扩缩容难	容器化 + K8s 调度，资源利用率提升 50%+
纯 Docker 手动管理	容器故障无自愈、跨机网络混乱、无统一管控	自愈能力 + CNI 网络插件（如 Calico）+ 统一 API 管控
自研脚本运维	脚本复杂、可维护性差、无标准化	声明式配置 + 内置控制器，标准化运维

二、K8s 集群完整架构（比之前更细化）

K8s 集群采用 “主从架构”，分为控制平面（Control Plane） 和节点（Node/Worker） 两层，你之前部署的k8s-master就是控制平面节点，也是集群的 “大脑”。

1. 控制平面（Master）—— 集群的 “决策中枢”

所有集群级别的管理操作都由控制平面完成，核心组件及你之前的实操关联：

组件	核心作用	你之前的实操关联
kube-apiserver	集群唯一入口，所有 kubectl 命令 / 组件通信都通过它，暴露 6443 端口	反复排查 6443 端口、连接拒绝 / 超时问题
etcd	集群的 “分布式数据库”，存储所有集群状态（节点、Pod、配置），强一致性	查看 etcd 容器状态、验证 etcd 健康性
kube-scheduler	调度器，根据 “资源需求、节点负载、亲和性规则” 将 Pod 调度到最优 Node	静态 Pod 由它调度到 Master 节点
kube-controller-manager	一组控制器的集合（节点控制器、Pod 控制器、服务控制器等），保障集群状态符合预期	自动重启故障 Pod、维护节点状态
cloud-controller-manager	对接云厂商 API（如阿里云 ECS、腾讯云 CVM），仅公有云集群需要	本地集群可忽略

2. 节点（Node/Worker）—— 集群的 “执行单元”

真正运行容器的机器（物理机 / 虚拟机），每个 Node 都受控制平面管理，核心组件：

组件	核心作用	你之前的实操关联
kubelet	Master 在 Node 上的 “代理人”，执行 Master 指令（启动 / 停止 Pod），监控 Pod 状态	多次重启 kubelet、查看 kubelet 日志
容器运行时（Containerd）	实际运行容器的底层引擎（替代 Docker Engine），K8s 1.24 + 默认用 Containerd	配置 containerd、启用 CRI、修改 SystemdCgroup
kube-proxy	节点网络代理，维护节点的 iptables/ipvs 规则，实现 Service 的负载均衡	网络插件依赖它转发请求
CNI 网络插件（如 Calico）	实现 Pod 网络互通、跨节点通信，是 Node 必备组件（否则节点 NotReady）	部署 Calico、解决 ImagePullBackOff 问题

3. 组件间通信规则（新手易忽略）

• 所有组件都通过 kube-apiserver 通信，不直接访问 etcd（除 apiserver）；
• 控制平面→Node：apiserver 向 kubelet 下发指令（如启动 Pod）；
• Node→控制平面：kubelet 向 apiserver 上报节点 / Pod 状态；
• 组件通信采用 HTTPS 加密，依赖你部署时生成的证书（/etc/kubernetes/pki）。

三、K8s 核心资源体系（从基础到进阶）

K8s 通过 “资源对象” 描述集群状态（声明式 API），你只需定义 “想要的状态”，K8s 会自动将实际状态调整为目标状态。资源分三层，新手从基础层开始掌握：

1. 基础层资源（最小运行单元）

• Pod：K8s 最小部署单元，是 “一个或多个紧密关联的容器集合”，共享网络 / 存储。
  • 特点：Pod 是临时的（重启 / 重建后 IP 会变）、自愈的（故障自动重启）；
  • 你之前部署的 Calico、apiserver 都是以 Pod 形式运行。
• Namespace：集群的 “资源隔离空间”，默认有default/kube-system/kube-public等。
  • 你查看的 Calico Pod 都在kube-system命名空间下。

2. 控制器层资源（管理 Pod 的 “管家”）

用于批量管理 Pod，实现自愈、扩缩容、滚动更新，新手最常用：

控制器	核心用途	适用场景
Deployment	无状态应用的核心控制器，支持扩缩容、滚动更新、回滚	部署 Web 应用、API 服务
StatefulSet	有状态应用控制器，保证 Pod 名称 / 网络标识 / 存储固定	部署 MySQL、Elasticsearch
DaemonSet	每个 Node 上运行一个 Pod，无扩缩容	部署监控代理、网络插件（Calico）
Job/CronJob	一次性 / 定时任务控制器，任务完成后 Pod 自动终止	数据备份、定时清理日志
ReplicaSet	保障固定数量的 Pod 运行，Deployment 底层依赖它	一般不直接使用

3. 网络 / 存储层资源（支撑应用运行）

• Service：为 Pod 提供 “稳定的访问地址”（Pod IP 动态变化，Service IP 固定），分 3 种类型：
  • ClusterIP：仅集群内访问（默认）；
  • NodePort：暴露到节点端口（如 30080），外网可访问；
  • LoadBalancer：对接云厂商负载均衡器（公有云）。
• Ingress：七层 HTTP/HTTPS 反向代理，实现域名路由、SSL 终止（替代 NodePort 的弊端）。
• Volume：Pod 的存储卷，解决容器数据持久化问题（容器销毁数据丢失）。
• PV/PVC：PV（持久卷）是集群级存储资源，PVC（持久卷声明）是 Pod 对存储的 “申请”，解耦存储供应与使用。
• StorageClass：动态创建 PV，无需手动创建（云厂商 / 本地存储都支持）。

四、K8s 核心工作流程（以部署一个 Nginx 应用为例）

结合你之前的部署经验，理解 K8s 管理应用的完整逻辑：

1. 你执行kubectl create deployment nginx --image=nginx，kubectl 将请求发送到 apiserver；
2. apiserver 验证请求后，将 Deployment 配置写入 etcd；
3. deployment-controller 检测到新的 Deployment，创建 ReplicaSet；
4. replicaSet-controller 检测到 ReplicaSet，创建 Pod；
5. kube-scheduler 检测到未调度的 Pod，根据节点状态将 Pod 调度到某个 Node；
6. 目标 Node 的 kubelet 检测到新的 Pod 配置，调用 containerd 拉取 nginx 镜像、启动容器；
7. kube-proxy 检测到 Pod 创建，更新节点 iptables 规则，为 Pod 分配 Service 访问入口；
8. 所有组件持续监控状态，若 Pod 崩溃，kubelet 自动重启；若 Node 故障，scheduler 将 Pod 调度到其他 Node。

五、K8s 网络模型（核心概念，对应你的 Calico 部署）

K8s 网络遵循 4 个核心原则，也是 Calico 等 CNI 插件要实现的目标：

1. 每个 Pod 有独立的 IP 地址（Pod 间无需端口映射）；
2. 同 Pod 内的容器共享网络命名空间（localhost通信）；
3. 不同 Node 上的 Pod 能直接通信（跨节点网络互通）；
4. Pod 与 Service 之间通过 kube-proxy 实现负载均衡。

核心实现：CNI（容器网络接口）

K8s 通过 CNI 插件标准化网络实现，你部署的 Calico 是最主流的 CNI 插件之一，其他常用插件：

• Flannel：轻量级，适合新手入门；
• Cilium：基于 eBPF，高性能，支持网络策略；
• Weave：无需 etcd，独立部署。

六、K8s 安全机制（新手必知）

K8s 提供多层安全防护，核心包括：

1. 认证（Authentication）：验证访问者身份，支持用户名密码、令牌（Token）、证书（如你用的 admin.conf）、OIDC 等；
2. 授权（Authorization）：验证访问者的权限（如是否允许创建 Pod、查看节点），常用 RBAC（基于角色的访问控制）；
3. 准入控制（Admission Control）：请求执行前的 “拦截器”，可修改 / 拒绝请求（如禁止创建特权容器）；
4. Secret/ConfigMap：Secret 存储敏感数据（密码、Token），ConfigMap 存储非敏感配置（配置文件、环境变量），避免硬编码；
5. Pod 安全策略（PSP）/Pod 安全标准：限制 Pod 的权限（如禁止运行 root 用户容器）。

七、K8s 常用工具与生态（提升运维效率）

除了 kubectl，这些工具是生产环境必备：

工具	核心作用
kubeadm	快速部署 K8s 集群（你之前用它初始化 Master 节点），替代手动部署的复杂步骤
kubectl	K8s 命令行工具，所有集群操作都通过它（你反复用的kubectl get nodes）
Helm	K8s 的 “包管理器”，将多个资源打包为 Chart，一键部署复杂应用（如 MySQL、Prometheus）
kubectl-dashboard	可视化 Web 控制台，适合新手查看集群状态
Prometheus+Grafana	监控 K8s 集群和应用，收集指标、绘制仪表盘
ELK/EFK	日志收集与分析，集中管理 Pod 日志
ArgoCD/Flux	GitOps 工具，实现 “代码即配置”，自动同步 Git 仓库的 K8s 配置到集群

八、K8s 典型应用场景（落地方向）

1. 微服务部署：将大型应用拆分为多个微服务，每个微服务用 Deployment/StatefulSet 部署，通过 Service/Ingress 暴露访问；
2. DevOps 自动化：结合 GitLab CI/Jenkins，实现 “代码提交→构建镜像→推送仓库→自动部署到 K8s” 的流水线；
3. 多环境隔离：用 Namespace 隔离开发 / 测试 / 生产环境，用 ResourceQuota 限制每个环境的资源使用；
4. 混合云 / 多云部署：在私有云、公有云、边缘节点上部署 K8s，实现应用跨环境统一管理；
5. 大数据 / AI 训练：用 K8s 调度 Spark/Flink 任务、AI 训练容器，弹性伸缩资源；
6. 边缘计算：K3s（轻量级 K8s）部署在边缘节点，实现边缘应用的统一管理。

九、新手学习 K8s 的路径（避坑指南）

结合你部署集群时遇到的问题（镜像拉取、网络插件、apiserver 超时），给新手学习建议：

1. 基础阶段：理解容器（Docker/Containerd）→ 安装单节点 K8s（kubeadm）→ 熟悉 kubectl 基本命令；
2. 核心阶段：掌握 Pod/Deployment/Service/Ingress→ 理解网络模型（CNI）→ 掌握存储（PV/PVC）；
3. 进阶阶段：学习 RBAC 安全、Helm 包管理、监控 / 日志、滚动更新 / 回滚、集群扩缩容；
4. 生产阶段：学习高可用集群部署、灾备恢复、性能调优、安全加固、GitOps 自动化。

总结（核心关键点回顾）

1. 核心定位：K8s 是容器编排平台，核心是 “声明式自动化管理容器化应用全生命周期”；
2. 核心架构：控制平面做决策（apiserver/etcd/scheduler），Node 执行（kubelet/containerd/CNI）；
3. 核心思想：你定义 “想要的状态”，K8s 通过控制器自动将 “实际状态” 调整为 “目标状态”；
4. 你之前的实操：完成了单节点控制平面部署，解决了镜像拉取、网络插件、apiserver 就绪等核心问题，是入门 K8s 的关键一步；
5. 核心价值：让容器化应用的部署、运维、扩缩容更高效、更可靠，是云原生的核心基础设施。