第二阶段：Docker（容器引擎入门）·容器生命周期管理

生命周期状态

已创建、运行中、已暂停、已停止、已删除。

实现机制

• 创建：准备 rootfs、配置 Namespace 和 Cgroups，但不启动进程。
• 启动：通过 runc 执行容器进程（通常是 init 进程），设置网络和挂载点。
• 运行：容器进程在隔离环境中运行，守护进程通过 wait 或 ptrace 监控状态。
• 停止：发送 SIGTERM 信号，等待进程退出，若超时则 SIGKILL。然后清理 Namespace 和 Cgroups。
• 资源限制：通过 Cgroups 在容器启动前或运行时动态设置 CPU、内存、IO 配额。

🔗 相关文档

第二阶段：Docker（容器引擎入门）·数据持久化

Volume

• 概念：Docker 管理的宿主机目录（默认位于 /var/lib/docker/volumes/），独立于容器生命周期。
• 实现：Volume 以目录形式存在，可通过 docker volume 命令创建和管理。挂载到容器时，实际上是 bind mount 到该目录。Volume 支持驱动程序（如本地、NFS、云存储）实现不同后端。

Bind Mount

• 概念：将宿主机任意路径直接挂载到容器目录。
• 实现：通过 Linux 的 mount 系统调用将源路径（宿主机）绑定到目标路径（容器内 mount namespace）。依赖宿主机目录结构，不提供跨主机可移植性。

区别本质

Volume 是 Docker 对 Bind Mount 的封装，增加了命名管理、驱动扩展和备份恢复接口；Bind Mount 是直接利用内核特性。

🔗 相关文档

第二阶段：Docker（容器引擎入门）·Docker 架构解析

Docker 架构

• 概念：Docker 采用 C/S 架构，各组件相互协作。
• 组件作用与实现：
  • 客户端（CLI）：接收用户指令，通过 REST API 与守护进程通信。
  • 守护进程：核心后台进程，管理镜像、容器、网络、卷。监听 REST API，处理请求并调用 containerd。
  • containerd：容器运行时管理器，负责镜像传输、存储、容器执行及生命周期管理，通过 gRPC 与 dockerd 交互。
  • runc：OCI 底层运行时，实际创建 Namespace 和 Cgroups 并启动容器进程。
  • 镜像（Image）：只读模板，采用分层 UnionFS 存储。
  • 容器（Container）：镜像的运行实例，在镜像层之上增加可写层（容器层）。
  • 仓库（Registry）：存储和分发镜像的服务端（如 Docker Hub）。

🔗 相关文档

第二阶段：Docker（容器引擎入门）·容器网络模型

Bridge（默认）

• 概念：每个容器连接到虚拟桥接设备（docker0），通过 NAT 实现与外网通信。
• 实现：Docker 创建名为 docker0 的虚拟以太网桥，为每个容器创建 veth pair（一端在容器 netns，另一端挂到 docker0）。容器间通过桥转发通信。出站流量通过 iptables 的 MASQUERADE 规则做源地址转换。

Host

• 概念：容器直接使用宿主机网络栈，不创建 netns。
• 实现：容器启动时不设置独立 netns，而是加入宿主机 netns，因此容器端口直接监听宿主机网络。

None

• 概念：容器拥有独立 netns 但无任何网络接口，完全隔离。
• 实现：仅创建 netns 但不分配 veth，用于需要自定义网络配置的场景。

Container

• 概念：新容器与已有容器共享 netns。
• 实现：设置 net namespace 为指定容器的 PID 对应的 netns。

端口映射

• 实现：通过 iptables 的 DNAT（目标地址转换）规则，将访问宿主机特定端口的流量重定向到容器的 IP 和端口（容器 IP 是 bridge 网络内的地址）。

🔗 相关文档

第二阶段：Docker（容器引擎入门）·镜像管理

镜像分层构建

• 概念：每个 Dockerfile 指令产生一个只读层，层之间通过 UnionFS 叠加形成统一文件系统。
• 实现：
  • UnionFS 类型：OverlayFS（最常用）、AUFS、btrfs、devicemapper。
  • OverlayFS 原理：使用 lowerdir（只读下层）、upperdir（可写上层）、merged（统一视图）。容器启动时镜像层作为 lowerdir，容器可写层作为 upperdir。
• 写时复制：修改文件时，将文件从下层复制到上层再修改，下层保持不变。

多阶段构建

• 概念：在一个 Dockerfile 中使用多个 FROM 指令，前阶段用于编译或构建，后阶段仅复制产物，避免将构建工具和中间文件带入最终镜像。
• 实现：每个阶段独立构建，最终镜像只包含最后阶段的层。Docker 构建器在阶段间传递文件（通过 COPY --from=）。

镜像内容寻址

每个镜像层由哈希（SHA256）标识，相同内容（例如基础层）可跨镜像共享，节省存储和传输。

🔗 相关文档

第四阶段：Kubernetes（容器编排）·可观测性

Metrics Server

• 概念：采集节点和 Pod 的 CPU、内存等资源指标。
• 实现：通过 kubelet 的 cAdvisor 接口（汇总 cgroups 数据）获取指标，暴露给 HPA、kubectl top 等。

日志收集

• 概念：采集容器 stdout/stderr 日志和容器内文件日志。
• 常见实现（EFK/ELK）：Fluentd 或 Filebeat 作为 DaemonSet 运行，读取容器日志文件（位于 /var/log/containers/），转发到 Elasticsearch 集群，并由 Kibana 可视化。

常见排查机制

• 事件：Kubernetes 资源状态变化时生成 Event 对象，存储在 API Server 中，可通过 kubectl describe 查看。
• 日志：kubelet 将容器标准输出日志轮转存储，默认保留近期文件。
• exec 调试：通过 API Server 与 kubelet 的 /exec 子资源建立流式连接，在容器内执行命令（基于容器运行时 exec API）。

🔗 相关文档

第四阶段：Kubernetes（容器编排）·存储抽象

PV（PersistentVolume）

• 概念：集群级别的存储资源抽象，由管理员预先提供或通过 StorageClass 动态创建。
• 实现：PV 代表某种后端存储（NFS、Ceph、云盘），包含容量、访问模式和回收策略。

PVC（PersistentVolumeClaim）

• 概念：用户对存储资源的请求，Pod 通过 PVC 使用存储。
• 实现：PVC 指定所需容量和访问模式，PV 控制器会寻找匹配的 PV 并绑定。绑定后 PVC 成为 PV 的唯一所有者。

StorageClass

• 概念：动态供应存储的模板，定义卷插件类型及参数。
• 实现：当 Pod 引用的 PVC 未绑定到现有 PV 且 StorageClass 有 provisioner（如 kubernetes.io/aws-ebs），provisioner 会自动创建新存储资源并生成 PV。

🔗 相关文档

第四阶段：Kubernetes（容器编排）·安全机制

RBAC（基于角色的访问控制）

• 概念：通过 Role（namespace 范围）或 ClusterRole（集群范围）定义权限（verbs + resources），再通过 RoleBinding/ClusterRoleBinding 将角色授予用户、Group 或 ServiceAccount。
• 实现：API Server 在请求处理前检查访问者的身份（认证阶段）和授权（RBAC 鉴权模块），查看是否有匹配的 RoleBinding。

ServiceAccount

• 概念：Pod 使用的身份标识，对应一个 Secret（Token）挂载到 Pod 内。
• 实现：Pod 在创建时自动挂载 ServiceAccount 的 JWT Token，Pod 内应用可使用该 Token 访问 API Server。

PodSecurityPolicy（已废弃）及其替代 Pod Security Admission

• 概念：Pod 运行时安全策略，如禁止特权容器、限制 root 权限、只读根文件系统等。
• 实现：PSA 利用命名空间标签（pod-security.kubernetes.io/enforce）设置三个级别，API Server 在 Pod 创建或更新时根据策略校验 Pod Spec。

NetworkPolicy

• 概念：Pod 之间或 Pod 与外部的网络访问控制规则。
• 实现：需要网络插件支持（Calico、Cilium、Weave 等）。插件根据 NetworkPolicy 资源生成 iptables 规则或 eBPF 程序，在节点上根据 Pod 标签和 ipBlock 过滤流量。

🔗 相关文档

第四阶段：Kubernetes（容器编排）·核心概念全景

Pod

• 概念：一组共享存储和网络资源的容器，是 Kubernetes 的最小部署单元。
• 实现：Pod 内的容器共享同一个 netns（localhost 通信）、IPC namespace 和 volume。Pod 由 kubelet 通过调用容器运行时（如 containerd）创建，并设置 pause 容器（基础架构容器）持有 netns。

控制器

Deployment

• 概念：管理无状态应用的期望副本数、滚动更新和回滚。
• 实现：Deployment 控制器在控制循环中管理 ReplicaSet（下一级控制器），每个 ReplicaSet 记录一个版本的 Pod 模板。滚动更新时创建新 ReplicaSet，逐步提升其副本数并缩减旧 ReplicaSet。

StatefulSet

• 概念：管理有状态应用，提供稳定的网络标识（Pod 名称固定）和有序部署/伸缩。
• 实现：StatefulSet 控制器为每个 Pod 分配序号（0..N-1），并按顺序启停。PVC（持久卷声明）模板自动为每个 Pod 创建对应存储。

DaemonSet

• 概念：确保每个节点（或符合条件的节点）运行一个 Pod 副本。
• 实现：DaemonSet 控制器监听节点添加/删除事件，使用 NodeAffinity 和 Pod 的 spec.nodeName 调度，由节点上的 kubelet 启动 Pod。

Service

• 概念：为一组 Pod 提供稳定的虚拟 IP 和负载均衡。
• 实现：
  • ClusterIP：集群内部虚拟 IP，通过 kube-proxy（iptables 或 IPVS 模式）实现转发。kube-proxy 在每个节点上监听 API Server，创建 iptables 规则，将 Service IP 的访问随机或轮询地指向后端 Pod IP。
  • NodePort：在 ClusterIP 基础上，在每个节点打开一个固定端口（30000-32767），流量经 NodePort 转发到 Service。
  • LoadBalancer：对接云厂商负载均衡器，自动创建外部负载均衡并将流量指向 NodePort。

Ingress

• 概念：七层（HTTP/HTTPS）路由规则，将外部请求转发到集群内 Service。
• 实现：需要部署 Ingress Controller（如 Nginx Ingress Controller）。Controller 监听 Ingress 资源变化，动态更新自身配置文件（如 Nginx 的 server 块），并通过 Pod 的服务地址进行路由。

🔗 相关文档

第四阶段：Kubernetes（容器编排）·网络模型与实现

CNI 插件

• 概念：容器网络接口，Kubernetes 通过 CNI 配置 Pod 网络。
• 实现：kubelet 在创建 Pod 时调用 CNI 可执行文件（如 Calico、Flannel），传递 JSON 配置。插件负责分配 IP、创建 veth 对、设置路由及网络策略。
  • Flannel：提供简单 Overlay 网络（VXLAN/host-gw），节点间通过隧道或直接路由转发 Pod 网络。
  • Calico：基于 BGP 的三层路由方案，同时支持 NetworkPolicy 以 iptables 或 eBPF 实现。

Service 网络实现

• iptables 模式：Service 的每个端口生成若干 iptables 规则（PREROUTING、OUTPUT 等），随机或轮询选后端 Pod IP。
• IPVS 模式：使用 Linux 内核 IPVS 模块，支持更多负载均衡算法（rr、wrr、lc、sh 等），性能优于 iptables。

Ingress Controller 实现

以 Pod 形式运行，监听 Ingress 资源，生成负载均衡器配置（如 Nginx 的 nginx.conf），并将外部流量代理到对应 Service。通常作为 NodePort 或 LoadBalancer 类型暴露。

🔗 相关文档