（一）K8S 核心认知全维度指南：云原生基础、架构特性与部署选型

一、云原生基础概述

1.1 云原生发展历程

时间	关键事件
2004 年	Google 开始内部大规模使用容器技术
2008 年	Google 将 Cgroups 技术合并进 Linux 内核，奠定容器化技术基础
2013 年	Docker 项目正式发布，推动容器技术进入开源领域
2014 年	Kubernetes 项目正式发布，成为容器编排行业标准
2015 年	Google、Redhat、微软等共同发起成立 CNCF（云原生计算基金会），推进云原生开源生态
2017 年	CNCF 成员达 170 个，基金项目 14 个
2018 年	CNCF 成立三周年，成员数 195 个，基金项目 19 个
2020 年	Kubernetes 宣布废弃 dockershim，Mirantis 和 Docker 宣布维护 dockershim
2022 年	Kubernetes v1.24 正式发布，移除对 Docker 的内建支持

1.2 云原生定义与部署模式

1.2.1 核心定义

云原生技术帮助企业在公有云、私有云和混合云等动态环境中构建和运行可弹性扩展的应用，核心是通过标准化技术栈实现应用的高效部署、运维和扩展。

1.2.2 三大部署模式对比

部署模式	定义与特点	适用场景
公有云	云服务提供商公开提供的共享基础设施，按需使用、按量付费，无需管理底层资源	非敏感应用、弹性需求高的业务、成本敏感型场景
私有云	企业在自有数据中心搭建的专属云平台，完全自主控制，安全性高、可定制	核心业务系统、敏感数据存储、合规监管要求高的场景
混合云	集成公有云、私有云、本地 IT 基础设施的混合环境，灵活分配负载	兼顾安全性与成本优化的场景（敏感数据存私有云，普通负载跑公有云）

1.3 云原生技术栈

核心技术构成

云原生 = 容器化（Docker+K8S） + 微服务（Microservices） + 无服务（Serverless） + DevOps + 服务网格（Service Mesh） + 云（Cloud）

技术组件	核心作用
容器化（Docker/containerd）	应用轻量级封装，保障环境一致性
服务网格（Istio）	管理服务间通信、安全性和流量控制
微服务架构	应用拆解为独立服务，支持灵活扩展和独立部署
不可变基础设施	服务部署后不修改，通过版本化镜像保持一致性
声明式 API	定义期望状态，系统自动管理资源
DevOps	开发运维协同，实现 CI/CD 自动化发布
Serverless	开发者无需关注底层基础设施，专注业务逻辑

云原生四要素

微服务：遵循康威定律和 DDD 设计思想，按功能拆分应用，实现解耦和内聚，支持独立部署更新
容器化：Docker 为主流容器引擎，K8S 为容器编排系统，二者均基于 Go 语言开发
DevOps：融合开发、测试、运维的敏捷思维与文化，提供持续交付能力
持续交付：小步快跑、不停机更新，支持开发版本与稳定版本并存

1.4 云原生核心特征

符合 12 因素应用原则
面向微服务架构，松耦合设计
自服务敏捷架构，减少运维依赖
基于 API 的服务间协作
抗脆弱性，具备自愈能力

12 因素应用具体原则

基准代码：同一代码库版本控制，支持多次部署
依赖管理：显式声明和隔离依赖项，保障环境一致
配置管理：配置项存储在环境中，避免硬编码
后端服务：外部服务作为附加资源使用
构建、发布、运行分离：清晰区分三个阶段
无状态进程：便于水平扩展
端口绑定：通过端口提供服务，保障应用独立性
并发处理：通过进程模型扩展
快速启动与优雅终止：确保数据一致性
开发与生产环境一致
日志管理：统一收集展示，保障可追溯性
管理进程：与常驻进程使用相同运行环境

二、K8S 核心介绍

2.1 什么是 K8S

定义：Kubernetes（简称 K8S）是开源的容器编排平台，用于自动部署、扩展和管理容器化应用程序
名称含义：源自希腊语，意为 "舵手 / 导航者"
起源：受 Google 的 Borg 系统启发，采用 Go 语言重写并捐赠给 CNCF
官网：英文 https://kubernetes.io，中文 https://kubernetes.io/zh-cn/docs
版本节奏：每年约 4 个发布版本（如 1.12→1.34 等）
关键变动：1.24 版本起移除 dockershim，需使用符合 CRI（Container Runtime Interface）的运行时（如 containerd、CRI-O）

2.2 为什么使用 K8S

核心优势	具体说明
自动化运维	一条命令或声明式配置完成部署、更新、扩容、缩容、删除等操作
弹性伸缩	基于 CPU、内存或自定义指标自动调整 Pod 副本数
容灾自愈	节点或容器故障时，自动重建或迁移 Pod，保障服务可用性
服务发现与负载均衡	通过 Service 提供稳定访问入口，自动分发请求
滚动升级与回滚	支持渐进式升级，出错可快速回滚至历史版本
集中配置与密钥管理	通过 ConfigMap、Secret 集中管理配置和敏感数据
存储编排	支持 NFS、Ceph、云存储等外部存储纳入集群管理
批处理 / 定时任务	支持 Job（一次性任务）、CronJob（定时任务）

三、K8S 集群架构与组件

K8S 采用 "控制平面 + 工作节点" 的主从架构，控制平面负责调度管理，工作节点运行实际应用负载。

3.1 控制平面（Master/Control Plane）组件

组件	主要职责
kube-apiserver	集群 API 接口入口，接收所有资源操作请求（增删改查、Watch）
kube-controller-manager	运行多种控制器（Node、ReplicaSet、Service 等），确保资源状态符合期望
kube-scheduler	为未调度的 Pod 选择合适节点，基于预选（predicates）与优选（priorities/scoring）策略
etcd	分布式键值存储，持久化保存集群所有资源状态数据

高可用建议：生产环境控制平面需部署多实例，避免单点故障

3.2 工作节点（Node/Worker）组件

组件	主要职责
kubelet	节点代理，接收控制平面任务，监控、执行并汇报节点与 Pod 状态
kube-proxy	实现 Service 的网络规则与负载转发（支持 iptables、ipvs 等网络模型）
container runtime	负责容器镜像拉取、启动 / 停止、资源隔离（K8S≥1.24 必选 CRI 兼容运行时，如 containerd）

3.3 容器运行时变动说明

Docker 引擎不再作为 K8S 的 CRI 运行时，但 Docker 构建的镜像因符合 OCI 标准仍可兼容
containerd 是当前主流轻量级 CRI 运行时，性能稳定、社区活跃
K8S 1.28 推荐运行时：containerd 或 CRI-O

四、K8S 核心概念与资源对象

概念 / 资源	含义与用途
Pod	最小可调度单位，可包含一个或多个容器，共享网络、存储等资源
控制器（Controller）	确保 Pod 运行状态：- Deployment：管理无状态应用- ReplicaSet：维持 Pod 副本数- StatefulSet：管理有状态服务- DaemonSet：每节点运行一个 Pod- Job/CronJob：批处理 / 定时任务
Service	为一组 Pod 提供稳定访问入口，具备负载均衡功能，通过标签选择器关联 Pod
Ingress	在 HTTP/HTTPS 层面管理外部访问路由，将外部流量导入集群内 Service
Label/Annotation/Selector	- Label：资源键值对标签，用于标识、筛选资源- Annotation：存储非标识性元数据- Selector：根据 Label 选择资源
Namespace	将集群逻辑划分为多个隔离空间，实现资源隔离和权限管理
资源定义结构	以 YAML/JSON 格式定义，包含 apiVersion、kind、metadata、spec、status 等字段

五、K8S 核心能力与特性

自动伸缩（Horizontal/Vertical Pod Autoscaler）
服务发现与负载均衡
滚动更新 / 回滚
容错 / 自愈机制
集中配置 / 密钥管理（ConfigMap/Secret）
存储编排与持久化存储（PV/PVC/StorageClass）
批处理 / 定时任务支持
资源隔离 / 配额 / 限制（ResourceQuota、LimitRange）
安全管理（RBAC、NetworkPolicy、Pod 安全准入）

六、K8S 部署方案对比

部署方式	适用场景	特点
Minikube	实验、学习、演示	本地单节点部署，简单易用
kubeadm	中小型集群	官方推荐，快速部署，兼顾灵活性
二进制 / 源码部署	高可控生产环境	手动控制所有组件和 TLS 证书，复杂度高
云托管服务（GKE/EKS/AKS/ 阿里 ACK）	企业生产环境	云厂商管理控制平面和节点，运维成本低

推荐方案：搭建 K8S 1.28 环境时，优先选择 kubeadm+containerd 或二进制部署 + containerd，兼顾灵活性与稳定性。