SAP ABAP开发避坑：用BAPI_ACC_DOCUMENT_POST创建单行凭证（F-37/F-47场景）必填的sp_gl_ind和bus_act参数
2026/6/8 12:34:40
为什么需要 Kubernetes？
1.1 你已经会了什么？
在前面的学习中，你已经掌握了容器化单机部署的核心技能，具体包括：
使用 Docker 将应用打包成镜像，实现单台机器上的容器运行
使用 Docker Compose 完成单机多容器编排，部署 Nginx、MySQL、Redis 等组合服务
基于 GitLab CI 搭建 CI/CD 流水线，实现代码提交后自动构建镜像、推送至镜像仓库
掌握以上单机容器技能后，我们可以思考几个生产环境中的核心问题：
若仅有一台部署机器，机器宕机后所有服务如何保障可用？
业务流量突发暴涨，单个容器算力不足、无法承载请求时如何处理？
业务版本迭代需要不停机更新，如何标准化、有序完成容器滚动发布，规避人工操作失误？
以上所有单机容器无法解决的生产痛点，都需要专业的容器编排平台解决，而Kubernetes（简称 K8s）是目前业界常用的工具。
1.2 什么是 Kubernetes？
Kubernetes 是一款用于自动化部署、扩缩容和管理容器化应用的开源集群管理平台。
可以将其理解为：容器操作系统、容器调度管家。使用者只需声明最终的服务运行状态，例如“保持3个Nginx容器持续运行”，K8s 即可自动完成容器的创建、监控、重启、扩缩容、滚动更新等全流程操作，无需人工干预。
K8s 核心价值
模式升级：从「手动管控容器」升级为「声明式自动管控容器」
架构升级：从「单机服务可用」升级为「集群高可用」
运维升级：从「人工应对故障」升级为「集群自愈」
1.3 类比生活：从“烧烤摊”到“连锁餐厅”
该类比由AI生成，因为笔者也想不到有什么更合适的类比来描述
通过生活化场景类比，可理解应用部署的技术迭代阶段：
| 阶段 | 技术模式 | 生活类比 |
|---|---|---|
| 第 0 阶段 | 直接在物理机上运行应用 | 自己在家烤串，无标准化流程、无容错能力 |
| 第 1 阶段 | Docker 容器化，单机运行 | 一个烧烤摊，单人负责全部烤串工作，独立完成所有服务 |
| 第 2 阶段 | Docker Compose 单机编排 | 整合烧烤摊、饮料摊、调料台，所有服务集中在同一套设备、同一场地，仅实现单机多服务组合 |
| 第 3 阶段 | Kubernetes 集群调度 | 连锁餐厅总部，统一分配人力、监控物料库存、应对客流高峰、门店故障自动调配资源 |
K8s 就是整个餐饮体系的「总部调度中心」，核心能力体现在：
你声明需求：“需要3个烤串师傅在岗”，总部自动调度匹配人力
出现故障：一名师傅请假，总部自动补派新师傅，保障岗位满编
流量暴涨：客人突发增多，自动扩容至10名师傅承接客流
节点故障：单门店设备损坏，自动将人力调配至正常门店，保障服务不中断
1.4 关键概念：声明式 vs 命令式
声明式与命令式的思维差异，是掌握 K8s 的核心关键，必须优先理解透彻。
| 模式 | 核心说明 | 生活类比 |
|---|---|---|
| 命令式 | 逐步下达操作指令，告诉系统「每一步该做什么」，全程人工主导流程 | 点餐时分步指令：先烧水、再下面、再捞面、最后放酱，全程指定每一个操作步骤 |
| 声明式 | 仅告知系统「最终需要的状态」，系统自动判断、自主完成所有操作，持续维持目标状态 | 直接告知需求：“我要一碗牛肉面”，后厨自主规划制作流程，无需用户干预细节 |
K8s 是严格的声明式系统：用户只需编写 YAML 文件声明“需要持续运行3个Nginx Pod”，K8s 会实时巡检集群当前状态，若副本数量不足、状态异常，会自动调整至声明的目标状态。
新手常见误区与正确操作方式
错误思维（命令式）：逐行执行 create、expose 等指令，手动一步步部署服务
正确思维（声明式）：编写标准化 YAML 资源配置文件 → 执行 apply 生效 → 依托 K8s 调谐机制（Reconcile）自动维持服务状态
1.5 从 Docker 到 K8s
从单机 Docker 过渡到 K8s 集群，核心是技术概念和操作思维的升级，两者核心资源对应关系如下：
| Docker / Compose 概念 | Kubernetes 对应概念 | 功能说明 |
|---|---|---|
| 容器 | Pod | Pod 是 K8s 最小调度单元，常规场景下一个 Pod 内仅运行一个业务容器 |
| 容器网络 | Service | 为一组 Pod 提供固定访问 IP，实现集群内部负载均衡 |
| 数据卷 | Volume / PVC | 实现容器数据持久化存储，避免容器销毁数据丢失 |
| 重启策略（restart） | 控制器（Deployment） | 自动维持容器副本数量，实现故障重启、扩缩容、版本更新 |
| 容器名称 | Label + Selector | 通过标签标记、筛选集群资源，实现资源关联 |
| docker-compose.yml | 多类型 YAML（Pod/Service/Deployment等） | 拆分资源配置，分工更清晰、管控更精准 |
核心思维转变
Docker 阶段：直接操作容器，通过指令创建、运行容器
K8s 阶段：不直接操作容器，仅操作 Pod、Service、Deployment 等资源对象，由 K8s 自动将资源配置转化为容器运行状态
1.6 Kubernetes 集群的两大核心节点：控制平面 + 工作节点
完整的 K8s 集群由两类核心节点组成，分工明确、协同工作，共同完成集群调度和服务运行。
控制平面（Control Plane）—— 集群管理者
核心作用：负责集群调度、资源管控、状态维护，不执行业务计算任务，是集群的“大脑”。
API Server：集群所有操作的统一入口，所有 kubectl 指令、外部访问请求最终均通过该组件处理
etcd：集群核心数据库，存储集群所有配置信息、资源状态数据，是集群的数据核心，数据丢失会导致集群瘫痪
Scheduler：调度器，负责为新创建的 Pod 筛选、分配最优的工作节点运行
Controller Manager：控制器管理器，运行各类资源控制器，持续巡检集群状态，不断将当前状态修正为用户声明的目标状态
工作节点（Worker Node）—— 业务执行者
核心作用：真正运行业务容器、承载业务流量，是集群的“干活主力”。
kubelet：节点监工，负责接收控制平面指令，启动、管理本节点 Pod，实时上报节点和 Pod 运行状态
kube-proxy：网络代理，负责配置节点网络规则，实现 Service 负载均衡、集群网络通信
容器运行时（如 containerd）：底层容器运行引擎，负责拉取镜像、启动容器、管理容器生命周期
1.7 本部分后续内容
本章仅讲解核心理论与思维方式，不执行任何 kubectl 操作、部署命令，后续章节将循序渐进讲解 K8s 全核心知识点，完整顺序如下：
Part 1：Pod —— K8s 最小单元（Pod定义、生命周期、多容器Pod场景）
Part 2：Service —— 为 Pod 提供永久稳定的访问入口
Part 3：Deployment —— 声明式管理Pod副本，实现滚动更新、版本回滚
Part 4：Ingress —— 基于域名实现集群服务外部访问
Part 5：ConfigMap & Secret —— 实现业务配置、密钥与代码解耦
Part 6：K8s 存储详解（Volume / PVC / StorageClass）
Part 7：kubectl 常用命令核心概念解析
Part 8：K8s 网络模型概述（Pod IP、Service IP、NodePort）
Part 9：统一部署验证