第1章 Kubernetes 介绍

本课程对应Marko Lukša著《Kubernetes in Action中文版》第1版，七牛容器云团队译，电子工业出版社2018年12月出版，592页，ISBN 9787121349959；英文原版由Manning于2017年12月出版。作者第1版源码第8章明确下载Kubernetes 1.8.0客户端，课程据此固定行为边界。

全书正式分母为18章与附录A至D，共22个正式单元、404个唯一章/附录/节节点；另设学习地图和总复习，共24页。第2版、现代apps/v1写法、EndpointSlice、Gateway API、Pod Security Admission或后来的多集群方案只能作为差异材料，不能替代第1版。本页逐项覆盖15个目录节点，最终交付需求比较、容器边界、集群组件图、首个应用轨迹和收益验收。

从一次声明式变更开始

先预测：kubectl提交对象后，API服务器完成哪些认证、授权、准入和持久化步骤，哪个控制器watch到变化，调度器如何选择节点，kubelet怎样创建容器，Service、卷与探针何时就绪。观察前先写预测，再按resourceVersion、UID、ownerReference和事件时间线修正模型。

Kubernetes 1.8的完成不是命令返回created。对象进入etcd、控制器观察、创建下级对象、Pod被调度、镜像启动、探针通过、Endpoint接入流量和业务结果稳定是不同检查点。控制循环允许中间状态，验收必须明确等待条件和超时后的诊断路径。

核心词汇与版本边界

容器、控制面、工作节点、期望状态、自愈

这些词构成本页词汇。每个词都要回答：对象由谁声明，谁拥有，谁调谐，期望与实际状态保存在哪里，失败后会重试还是终止，怎样观测，以及Kubernetes 1.8之后哪些变化不属于本书。

原书目录逐节点重构

1.1 Kubernetes 系统的需求

目录节点 1/15。 “Kubernetes 系统的需求”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“本章输入与版本契约”进入“Kubernetes 系统的需求”，再到“从单体应用到微服务”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.1.1 从单体应用到微服务

目录节点 2/15。 “从单体应用到微服务”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“Kubernetes 系统的需求”进入“从单体应用到微服务”，再到“为应用程序提供一个一致的环境”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.1.2 为应用程序提供一个一致的环境

目录节点 3/15。 “为应用程序提供一个一致的环境”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“从单体应用到微服务”进入“为应用程序提供一个一致的环境”，再到“迈向持续交付 ：DevOps 和无运维”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.1.3 迈向持续交付 ：DevOps 和无运维

目录节点 4/15。 “迈向持续交付 ：DevOps 和无运维”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“为应用程序提供一个一致的环境”进入“迈向持续交付 ：DevOps 和无运维”，再到“介绍容器技术”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.2 介绍容器技术

目录节点 5/15。 “介绍容器技术”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“迈向持续交付 ：DevOps 和无运维”进入“介绍容器技术”，再到“什么是容器”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.2.1 什么是容器

目录节点 6/15。 “什么是容器”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“介绍容器技术”进入“什么是容器”，再到“Docker 容器平台介绍”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.2.2 Docker 容器平台介绍

目录节点 7/15。 “Docker 容器平台介绍”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“什么是容器”进入“Docker 容器平台介绍”，再到“rkt——一个 Docker 的替代方案”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.2.3 rkt——一个 Docker 的替代方案

目录节点 8/15。 “rkt——一个 Docker 的替代方案”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“Docker 容器平台介绍”进入“rkt——一个 Docker 的替代方案”，再到“Kubernetes 介绍”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.3 Kubernetes 介绍

目录节点 9/15。 “Kubernetes 介绍”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“rkt——一个 Docker 的替代方案”进入“Kubernetes 介绍”，再到“初衷”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.3.1 初衷

目录节点 10/15。 “初衷”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“Kubernetes 介绍”进入“初衷”，再到“深入浅出地了解 Kubernetes”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.3.2 深入浅出地了解 Kubernetes

目录节点 11/15。 “深入浅出地了解 Kubernetes”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“初衷”进入“深入浅出地了解 Kubernetes”，再到“Kubernetes 集群架构”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.3.3 Kubernetes 集群架构

目录节点 12/15。 “Kubernetes 集群架构”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“深入浅出地了解 Kubernetes”进入“Kubernetes 集群架构”，再到“在 Kubernetes 中运行应用”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.3.4 在 Kubernetes 中运行应用

目录节点 13/15。 “在 Kubernetes 中运行应用”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“Kubernetes 集群架构”进入“在 Kubernetes 中运行应用”，再到“使用 Kubernetes 的好处”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.3.5 使用 Kubernetes 的好处

目录节点 14/15。 “使用 Kubernetes 的好处”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“在 Kubernetes 中运行应用”进入“使用 Kubernetes 的好处”，再到“本章小结”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

1.4 本章小结

目录节点 15/15。 “本章小结”服务于“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”。先识别它在Kubernetes 1.8中对应API对象、期望状态、实际状态、所有者引用和执行组件，再标出创建、观察、调谐、删除与垃圾回收边界。结论必须从清单、API响应、事件、控制器日志、节点状态和应用结果复核。

状态轨迹从“使用 Kubernetes 的好处”进入“本章小结”，再到“本章证据门与回退”。沿kubectl请求、API认证授权、etcd持久化、watch、控制器调谐、调度、kubelet执行、网络与存储准备记录resourceVersion和时间线。Pod重建、节点故障、网络分区或控制面重启必须有独立分支，不能只画正常箭头。

实验固定Kubernetes 1.8、集群拓扑、镜像摘要、命名空间和对象清单，只改变副本、探针、资源、标签选择、节点、网络或存储条件之一。比较期望/当前/就绪副本、Pending原因、重启、事件、吞吐、P95/P99和最终业务集合，用“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”验收。

独立证据与生产交接

目录证据保存18章4附录与404个唯一节点映射；环境证据保存客户端、API服务器、etcd、容器运行时、网络与存储插件版本；对象证据保存清单、UID、resourceVersion、ownerReference、spec和status；运行证据保存事件、控制器、调度、kubelet、探针、流量和最终业务结果。

验收记录按一次变更一个编号：记录上下文、命名空间、操作者、开始结束时间、对象前后状态、请求样本、预期与实际结果、日志和指标窗口。失败时保留原始事件、Pending或终止原因、影响范围、停止条件和回退验证；成功时也须由另一位读者按同一材料重放。

性能判断固定镜像、请求分布、副本、资源、探针、Service、节点和存储语义。扩大limit或关闭探针换来的吞吐不是等价优化。平均值会隐藏调度等待、镜像拉取、CPU节流、OOM、控制器重试、Endpoint切换和卷挂载，必须保留P95/P99与状态时间线。

恢复判断从业务状态结束。Pod Running、节点Ready、Deployment Available、PVC Bound或API可访问都只是阶段；还要核对客户端请求、数据集合、身份权限、对象版本和旧实例是否停止提供错误结果。

本章回顾

重新完成“从单体到微服务、容器隔离和集群架构解释为什么需要Kubernetes”：固定Kubernetes 1.8和第1版目录，从声明式对象与控制循环推导边界，通过基线、压力与故障实验测量，最后交付需求比较、容器边界、集群组件图、首个应用轨迹和收益验收。只有“应用声明进入API服务器后由控制面收敛，在节点或容器失败时恢复到期望状态”与反例都能独立重放，本页才算完成。

复习与运行验收

← 上一页：第1版权威学习地图 · 下一页：第2章 开始使用 Kubernetes 和 Docker →