K8S 概念与安装

前言

云原生技术帮助企业在各类云环境中高效运行可弹性扩展的应用，而 Kubernetes（K8s）作为核心工具，凭借容器编排能力成为云原生的重要基石。本文简要介绍云原生的核心概念、K8s 的基础架构、核心组件及部署方案，为入门者提供清晰指引。

1 云原生的概念

1.1 云原生的定义**

云原生技术的核心价值，是帮助企业在公有云、私有云、混合云等动态环境中，高效构建并运行可弹性扩展的应用，适配不同 IT 架构需求。

类型	核心特点	适用场景	典型优势
公有云	由亚马逊云、微软 Azure 、阿里云、华为云、腾讯云等服务商提供，资源共享、按需付费，用户无需管理基础设施	非敏感业务（如普通 APP、测试环境）	成本低、弹性强
私有云	（天翼云）企业自建在自有数据中心，完全可控、定制化高	核心业务 / 敏感数据（如财务、客户信息）	安全性高、合规性强
混合云	整合公有云、私有云及本地 IT 设施，按需分配负载	兼顾安全与成本的场景（如敏感数据存私有云，普通负载用公有云）	灵活性高、资源利用率优

1.2 云原生技术栈

1.2.1 关键核心技术

• 容器化：以 Docker、containerd 为代表，实现应用轻量级封装，保证环境一致性（开发 / 测试 / 生产环境无差异）。
• 服务网格：如 Istio，负责管理服务间通信，解决流量控制、安全加密、监控等问题。
• 微服务架构：将应用拆分为独立小服务，每个服务可单独开发、部署、扩展，降低耦合性。
• 不可变基础设施：服务部署后不再修改，通过版本化镜像（如 Docker 镜像）确保环境稳定，减少变更风险。
• 声明式 API：用户只需定义 "应用要达到的目标状态"（如 "需要 3 个服务实例"），系统自动完成资源调度与管理。

1.2.2 简化理解公式

云原生 = 容器化（Docker+K8s） + 微服务（Microservices） + 无服务（Serverless） + DevOps（开发运维一体化） + 服务网格（Service Mesh） + 云环境（公有 / 私有 / 混合云）

1.3 云原生四大核心要素

1.3.1 微服务

• 核心定位：云原生的基石，几乎所有云原生定义的必备要素，与 "单体应用" 相对。
• 理论支撑
  • 康威定律：核心逻辑为 "组织架构决定产品形态"，指导微服务的拆分方向（如按团队职责划分服务边界），其本质与 "生产关系影响生产力" 逻辑相通，强调组织协作模式对技术架构的直接影响。
  • 拆分技巧 ：除康威定律外，常结合DDD（领域驱动设计） ，按业务领域 / 功能（function）拆分，实现 "高内聚、低耦合"。
• 核心优势：服务解耦，单个服务可独立开发、部署、迭代，降低变更风险，适配高频更新需求。

1.3.2 容器化

• 核心工具
  • Docker：应用最广泛的容器引擎，基于 LXC 技术实现轻量级应用隔离，在思科、谷歌等企业基础设施中大量应用，保障 "开发 - 测试 - 生产" 环境一致性。
  • K8s（Kubernetes）：谷歌主导的容器编排系统，负责容器的部署、管理、负载均衡与故障恢复，与 Docker 均采用 Go 语言开发。
• 核心价值：为微服务提供 "可移植、可隔离" 的运行载体，解决微服务多实例部署与资源调度的核心问题。

1.3.3 DevOps

• 概念定义：由 "Dev（开发）+Ops（运维）" 组合而来，实际还涵盖测试环节，是一套 "敏捷思维 + 沟通文化 + 组织形式" 的集合。
• 核心目标：打破开发与运维的协作壁垒，避免 "开发与产品对立" 式的低效沟通，实现 "开发 - 测试 - 部署" 全流程协同。
• 核心价值：为云原生提供 "持续交付" 的组织与文化支撑，保障高频迭代的可行性。

1.3.4 持续交付

• 核心逻辑：反传统 "瀑布式开发"，采用 "小步快跑、快速迭代" 模式，实现 "不误时开发、不停机更新"。
• 关键要求：需支持 "开发版本与稳定版本并存"，依赖自动化工具（如 CI/CD 流水线）与标准化流程（如版本管理、灰度发布）支撑。
• 核心价值：缩短产品从开发到上线的周期，快速响应业务需求，同时降低更新风险。

1.4 云原生系统的五大特征

云原生系统通过以下特征，适配动态、弹性的云计算环境需求：

1. 符合 12 因素应用：遵循 12 项开发原则（详见下文），确保应用具备高可扩展性、无状态性、易维护性。
2. 面向微服务架构：应用拆解为独立、松耦合的微服务，支持灵活扩展与独立迭代。
3. 自服务敏捷架构：开发人员可自主创建、管理云资源（如通过平台化工具申请服务器、数据库），减少对运维团队的依赖，提升效率。
4. 基于 API 的协作：服务间通过标准化 API 通信，降低服务依赖，便于跨团队、跨系统整合。
5. 抗脆弱性：系统具备 "自愈能力"（如 K8s 自动重启故障容器），能主动应对网络波动、硬件故障等不稳定因素，而非被动承受风险。

1.5 12 因素应用（了解即可）

12 因素应用是云原生应用的 "开发说明书"，通过明确原则确保应用在云环境中高效运行，具体包括：

1. 基准代码：同一应用使用单一代码库（如 Git 仓库）进行版本控制，支持多次部署（开发、测试、生产环境共用代码）。
2. 依赖管理：显式声明依赖（如 Java 的 Maven、Python 的 Pip），隔离不同应用的依赖环境，避免 "本地能跑、线上报错"。
3. 配置管理：配置项（如数据库地址、密钥）存储在环境变量或配置中心，不硬编码到代码中，适配多环境部署。
4. 后端服务：将外部服务（如数据库、缓存、消息队列）视为 "附加资源"，通过配置动态绑定，便于替换与扩展。
5. 构建、发布、运行分离：清晰划分三个阶段 ------"构建"（将代码打包为镜像）、"发布"（绑定配置生成可执行版本）、"运行"（启动应用实例），避免运行中修改代码。
6. 无状态进程：应用进程不存储本地状态（如会话数据），状态统一存储到后端服务（如 Redis），支持水平扩展（增加实例即可提升性能）。
7. 端口绑定：应用通过自身绑定端口提供服务（如 Java 应用绑定 8080 端口），不依赖外部 web 服务器，确保独立性与可移植性。
8. 并发处理：通过 "多进程 / 多线程" 模型扩展并发能力，而非依赖单机硬件升级，适配云环境的弹性伸缩。
9. 快速启动与优雅终止：应用启动时间短（便于快速扩容），终止时能处理完现有请求（避免数据丢失），支持平滑上下线。
10. 开发环境与生产环境一致：尽量统一开发、测试、生产环境的依赖版本（如操作系统、中间件版本），减少 "环境差异导致的问题"。
11. 日志管理：应用将日志以 "标准输出" 形式打印，不自行管理日志文件，由云平台统一收集、存储、分析（如 ELK 日志系统），确保可追溯性。
12. 管理进程：数据备份、数据库迁移等管理性任务，与应用常驻进程使用相同的运行环境（如通过相同镜像执行），确保环境一致性。

2 K8s的概念

2.1 什么是K8s

• K8S 是 Kubernetes 的简写（K + "ubernete" 中的 8 个字母 + S）
• Kubernetes 是一个开源平台，用于自动部署、扩展和管理容器化（containerized）应用程序
• 它可以看作一个负责自动化运维、编排多个容器（如由 containerd 驱动的容器）的集群管理系统
• 源起：Kubernetes 受 Google 的 Borg 系统启发，后使用 Go 语言重写并捐赠给 CNCF
• 名称含义：源自希腊语，意为 "舵手 / 导航者

学习官网：

-- 英文：https://kubernetes.io

-- 中文：https://kubernetes.io/zh-cn/docs

**关键变动：**从 Kubernetes 1.24 起，官方移除对 Docker 的内建支持（即移除 dockershim）

​ 在1.24之后，要使用docker，需要安装第三方插件

节点必须使用符合 CRI（Container Runtime Interface）的运行时（如 containerd、CRI-O 等）

2.2 为什么要用 K8S？

Kubernetes 的设计初衷是解决传统部署方式在扩展、管理、容错等方面的困难。

以下是它主要解决的问题和带来的好处

• 自动化运维：无须人工干预，实现一条命令或声明式方式完成部署、更新、扩容、缩容、删除等
• 弹性伸缩：依据指标（CPU、内存、自定义指标等）自动扩展或缩减 Pod 副本数
• 容灾 / 自愈：当某个节点或容器失败时，K8S 会自动重建或迁移 Pod，保证副本数量和期望状态
• 服务发现与负载均衡：通过 Service 为 Pod 提供稳定的访问入口，并自动分发请求
• 滚动升级与回滚：支持渐进式升级，一旦出错可以回滚到之前版本
• 集中配置与密钥管理：通过 ConfigMap 、 Secret 等资源集中管理配置与敏感数据
• 存储编排：支持将外部存储（NFS、Ceph、云存储等）纳入集群资源管理
• 批处理 / 定时任务：支持 Job 、 CronJob 用于一次性或定时任务

3 Kubernetes 集群架构与组件

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

3.1 控制平面（Master / Control Plane）组件 (主节点)

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

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

组件	主要职责
kubelet	节点上的代理 ，负责接收控制平面下发的 Pod 任务，监控、执行、汇报 节点与 Pod 状态
kube-proxy	在节点上实现 Service 的网络规则 与负载转发，通常通过iptables、ipvs 或其他网络模型
containerd	负责容器镜像拉取 、容器启动/停止 、资源隔离等底层行为（在Kubernetes ≥1.24 中为必选 CRI 运行时）

4 Kubernetes 核心概念与资源对象

概念 / 资源	核心含义与用途
Pod	K8s 最小调度单位，含 1 个或多个容器，共享网络、存储，整体调度管理。
控制器（Controller）	自动化管理 Pod：维持副本数、自动修复 / 扩缩容 / 升级。 常见类型：Deployment（无状态） StatefulSet（有状态） DaemonSet（每节点 1 个） Job/CronJob（批处理 / 定时任务）
Service	给一组 Pod 提供稳定访问入口，做负载均衡，屏蔽 Pod 动态变化（如 IP 变）。
Ingress	集群入口网关，管理 HTTP/HTTPS 外部流量路由，将域名 / URL 映射到内部 Service。
Label/Annotation/Selector	- Label：键值标签（如 app: nginx），用于标识、筛选资源； - Annotation：存非标识元数据（如运维备注）； - Selector：按 Label 筛选资源，建立关联。
Namespace（命名空间）	逻辑隔离集群空间，区分环境（如 dev/prod）、防命名冲突、管控资源权限 / 配额。
资源定义结构	用 YAML/JSON 定义，核心字段：- apiVersion（API 版本）、kind（资源类型）；- metadata（名称、标签等）、spec（期望状态）、status（当前状态，自动维护）。

5. Kubernetes 核心能力与特性

• 自动伸缩（Horizontal Pod Autoscaler, Vertical Pod Autoscaler 等）
• 服务发现 & 负载均衡
• 滚动更新 / 回滚
• 容错 / 自愈
• 集中配置 / 密钥管理（ConfigMap / Secret）
• 存储编排与持久化存储（PV / PVC / StorageClass）
• 批处理 / 定时任务
• 资源隔离 / 配额 / 限制（ResourceQuota, LimitRange 等）
• 安全管理机制：如 RBAC（基于角色的访问控制）、NetworkPolicy（网络策略）、Pod 安全策略 /Pod 安全准入（安全设置）

6 部署方式 / 常见部署方案

部署方式	主要适用场景
Minikube	本地单节点部署，适用于 K8s 学习、功能实验、小型演示（如开发人员本地验证应用兼容性）
kubeadm	官方轻量部署工具，适用于 中小型 K8s 集群搭建（如企业测试环境、中小型业务生产集群）
二进制 / 源码部署	手动控制组件、证书等所有细节，适用于 对集群稳定性、可控性要求极高的生产环境（如核心业务集群）
云托管服务（GKE/EKS/AKS/ 阿里云 ACK 等）	云厂商托管控制平面及基础运维，适用于 企业生产环境（无需投入大量人力维护集群，专注业务部署）

对于你自己搭建 K8S 1.28 的环境，选择 kubeadm + containerd 或者 二进制部署 + containerd 更能兼顾灵活性与稳定性。

总结

• 云原生：以容器化、微服务、DevOps、持续交付为核心，适配动态云环境，通过 12 因素应用等特征保障系统灵活稳定。
• K8s：开源容器编排平台，采用控制平面（apiserver、etcd 等）+ 工作节点（kubelet、containerd 等）架构，实现容器的自动部署、扩缩容、容错等，核心概念包括 Pod、Service、Namespace 等。
• 部署方案：Minikube 适合学习，kubeadm 适用于中小型集群，二进制部署适合高要求生产环境，云托管服务则简化运维，可按需选择。
  通过本文可快速掌握云原生与 K8s 的核心要点，为实践打下基础。