• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Docker 常用docker versiondocker infodocker imagesdocker ps -adocker pull nginx:1.27docker run -d --name web -p 8080:80 nginx:1.27docker logs -f webdocker exec -it web shdocker statsdocker rm -f webDocker 构建docker build -t registry.example.com/shop/app:1.2.0 .docker push registry.example.com/shop/app:1.2.0docker system dfdocker builder pruneDocker Composedocker compose up -ddocker compose psdocker compose logs -f appdocker compose exec app shdocker compose downkubectl 查看kubectl get nodes -o widekubectl get pods -Akubectl get deploy,rs,svc,ing -n shopkubectl describe pod app -n shopkubectl logs app -n shop --previouskubectl exec -it app -n shop -- shkubectl 操作kubectl apply -f deploy.yamlkubectl delete -f deploy.yamlkubectl scale deployment/app --replicas=3 -n shopkubectl rollout status deployment/app -n shopkubectl rollout history deployment/app -n shopkubectl rollout undo deployment/app -n shopkubectl port-forward svc/app 8080:80 -n shop排障kubectl get events -A --sort-by=.lastTimestampkubectl top nodeskubectl top pods -Akubectl get endpoints app -n shopkubectl auth can-i list pods -n shop常见状态 状态 方向 Pending 调度、资源、PVC ImagePullBackOff 镜像、凭据 CrashLoopBackOff 应用、配置、探针 OOMKilled 内存 limit Evicted 节点压力 Completed 正常结束 健康 YAMLlivenessProbe: httpGet: path: /actuator/health/liveness port: 8080readinessProbe: httpGet: path: /actuator/health/readiness port: 8080startupProbe: httpGet: path: /actuator/health/liveness port: 8080 failureThreshold: 30 periodSeconds: 2本章小结本速查手册汇总容器、镜像、Compose、kubectl、发布回滚和排障常用命令。生产使用时以当前工具版本和平台文档为准。
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。云原生大师不仅会写 YAML，还要理解内核隔离、分布式控制面、交付流程、安全边界和成本治理。33.1 能力阶梯 阶段 能力 入门 Docker 命令、镜像、容器 进阶 Dockerfile、Compose、网络存储 熟练 Kubernetes 核心对象和排障 高级 调度、发布、安全、可观测 专家 多集群、Operator、平台工程 33.2 学习路径1. 容器原理2. 镜像构建与供应链3. Docker 网络 / 存储4. Kubernetes API 和对象5. 调度与资源治理6. 发布回滚和 CI/CD7. 安全与网络策略8. 可观测性9. 有状态工作负载10. 多集群与平台治理33.3 实验清单 观察容器 Namespace 和 Cgroup； 构建并优化多阶段镜像； 搭建单机 Kubernetes； 模拟 Pending、CrashLoop、OOM； 测试 Service 和 Ingress； 验证滚动发布和回滚； 练习 RBAC 和 NetworkPolicy； 部署监控日志链路； 演练节点故障； 编写一个简单 Operator。33.4 生产判断力上线前问： 故障时如何自愈？ 如何知道它不健康？ 能否优雅停机？ 如何发布和回滚？ 数据是否持久化？ 权限是否最小？ 成本归属给谁？ 依赖故障是否可控？33.5 平台工程成熟团队需要： 统一模板； 环境管理； 权限审批； 配额和成本； 发布策略； 可观测标准； 安全基线； 值班 runbook； 故障演练。33.6 持续学习关注： Kubernetes release notes； Gateway API 演进； CNI / CSI 生态； 安全策略； WebAssembly 和新运行时； 平台工程实践； 成本优化。新特性必须结合稳定性、升级路径和团队能力评估。本章小结从容器到 Kubernetes，再到平台工程，核心是把交付、运行、安全、观测和成本纳入同一套体系。多做实验、多做演练、多复盘，才是云原生大师之路。思考题 你的平台最缺哪一层能力？ 如何设计统一服务模板？ 哪些安全基线必须强制？ 如何验证一次节点故障演练？ 如何降低平台复杂度？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。本章整理容器与 Kubernetes 高频面试题，并给出体现工程判断的回答。32.1 容器和虚拟机区别？容器共享宿主机内核，通过 Namespace 隔离视图、Cgroup 限制资源、UnionFS 提供镜像层；虚拟机通过 Hypervisor 虚拟硬件并运行独立内核。容器启动快、密度高，安全边界弱于 VM。32.2 Pod 状态排查？先 kubectl describe pod 看 Events，再看 logs。Pending 看调度，ImagePullBackOff 看镜像，CrashLoopBackOff 看应用和配置，OOMKilled 看内存 limit。32.3 Service 和 Ingress 区别？Service 提供稳定虚拟 IP 和四层负载均衡；Ingress / Gateway API 提供 HTTP 路由、TLS 和路径域名分流。Ingress 还需要控制器实现。32.4 Deployment 和 StatefulSet 区别？Deployment 适合无状态可任意替换副本；StatefulSet 提供稳定名称、DNS 和存储，适合数据库和主从系统。StatefulSet 不自动完成数据库复制和切换。32.5 requests 和 limits 区别？requests 影响调度和资源保障；limits 限制运行时上限。CPU 超限会节流，内存超限可能 OOM Kill。32.6 HPA 为什么不生效？检查： 指标是否为 unknown； 是否设置 requests； 副本是否达到 min / max； Metrics Server 是否正常； 稳定窗口和容忍度； Pod 是否 Pending。32.7 Service 后端不通？检查 Endpoints、selector、readiness、targetPort、DNS、NetworkPolicy、应用监听地址和 kube-proxy。32.8 如何做优雅停机？容器 PID 1接收 SIGTERM，应用停止接新请求、处理存量请求、关闭连接和线程池；配合 preStop 和 terminationGracePeriodSeconds。32.9 镜像安全如何治理？固定基础镜像和版本、多阶段构建、非 root、扫描、签名、准入校验、Secret 不入镜像、CI 最小权限。32.10 etcd 重要性？etcd 保存集群状态。etcd 不可用时无法创建和更新对象，已有容器通常继续运行，但集群丧失控制能力。需要备份、低延迟磁盘和多数派健康。32.11 系统设计题：部署高并发服务回答框架：镜像交付Deployment + HPArequests / limitsService / Ingress配置和 Secret探针和优雅停机监控告警灰度和回滚容量和依赖保护本章小结面试重点通常覆盖容器原理、Pod 排查、网络、存储、控制器、调度、发布和安全。回答要结合生产影响和验证方法。思考题 如何完整解释一次 Pod 创建？ Endpoints 为空的排查顺序？ HPA 和 VPA 如何配合？ Operator 引入的收益和风险？ 如何设计生产发布回滚？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。本章将一个电商微服务部署到 Kubernetes，覆盖镜像、Deployment、Service、Ingress、配置、探针、发布和监控。31.1 服务拓扑Internet -> Ingress -> gateway -> order-service -> product-service -> PostgreSQL -> Redis非核心依赖：PrometheusGrafanaFluent Bit31.2 镜像FROM maven:3.9-eclipse-temurin-17 AS buildWORKDIR /srcCOPY pom.xml .RUN mvn dependency:go-offlineCOPY src ./srcRUN mvn package -DskipTestsFROM eclipse-temurin:17-jre-alpineWORKDIR /appCOPY --from=build /src/target/order-service.jar app.jarUSER appENTRYPOINT ["java", "-XX:MaxRAMPercentage=70", "-jar", "/app/app.jar"]31.3 DeploymentapiVersion: apps/v1kind: Deploymentmetadata: name: order-service labels: app: orderspec: replicas: 3 selector: matchLabels: app: order template: metadata: labels: app: order spec: containers: - name: app image: registry.example.com/shop/order-service:1.2.0 ports: - containerPort: 8080 envFrom: - configMapRef: name: order-config resources: requests: cpu: 250m memory: 512Mi limits: cpu: "1" memory: 1Gi31.4 Service 与 IngressapiVersion: v1kind: Servicemetadata: name: order-servicespec: selector: app: order ports: - port: 80 targetPort: 8080apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: shopspec: ingressClassName: nginx rules: - host: shop.example.com http: paths: - path: /api/orders pathType: Prefix backend: service: name: order-service port: number: 8031.5 配置与 SecretConfigMap 放普通参数，Secret 放数据库凭据：env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password生产可接外部密钥管理系统，并记录轮转流程。31.6 发布kubectl apply -f deployment.yamlkubectl rollout status deployment/order-service核心链路采用：1. 预发环境验证2. 镜像扫描3. 生产小比例灰度4. 观察错误率和延迟5. 逐步放大流量6. 异常自动回滚31.7 监控 指标 目标 HTTP 5xx 立即告警 P99 延迟 SLO Pod restarts 异常告警 CPU throttling 容量评估 OOMKilled 高危 数据库连接池 保护依赖 31.8 上线清单1. requests / limits2. liveness / readiness / startup3. 日志和 trace4. Service / Ingress 测试5. NetworkPolicy6. RBAC7. HPA8. 备份和回滚9. 混沌演练本章小结项目上线不只是 apply YAML，而是镜像安全、资源边界、流量入口、配置注入、健康检查、发布策略和可观测性的组合。思考题 为什么镜像要固定版本？ ConfigMap 和 Secret 如何划分？ 灰度发布观察哪些指标？ OOMKilled 如何处理？ 上线前为什么做混沌演练？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。多集群用于隔离故障域、满足合规、降低爆炸半径、靠近用户和分离环境。它也带来分发、网络、身份和运维复杂度。30.1 常见拓扑环境多集群：dev / staging / prodregion 多集群：cn-north / cn-south业务多集群：交易 / 数据 / 内部容灾多集群：active / standby30.2 分发方式 方式 工具 GitOps Argo CD ApplicationSet、Flux 控制面同步 Karmada、Clusternet Helm pipeline CI 逐环境部署 镜像同步 Registry 复制 30.3 需要治理的内容 集群清单和版本； 命名规范； 权限和身份； 网络互联； DNS 与证书； 配置差异； 镜像同步； 监控聚合； 成本归属； 应急切换。30.4 跨集群服务方式： 方案 特点 全局负载均衡 用户流量就近 Service Mesh 多集群 服务发现和 mTLS API Gateway 路由 显式集成 消息异步同步 松耦合 不要为了技术炫技默认全互联，应按故障域和业务依赖设计。30.5 容灾目标 指标 含义 RTO 恢复服务时间 RPO 可容忍数据丢失 跨集群数据库、消息和状态同步是难点，Kubernetes 本身只调度容器，不自动复制业务数据。本章小结多集群提升隔离性和可控性，但必须治理配置分发、网络、身份、数据和观测。先明确容灾与合规目标，再决定拓扑和工具。思考题 为什么需要多集群？ GitOps 如何分发多集群配置？ 跨集群数据同步为什么困难？ 多集群监控如何聚合？ 如何验证容灾切换？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。服务网格把重试、超时、熔断、TLS、鉴权、流量拆分和遥测下沉到基础设施层，常见形态是 sidecar 代理或透明节点代理。29.1 架构App Pod App container Sidecar proxy控制面：Policy / configuration -> proxy29.2 能力 能力 说明 mTLS 服务间加密 重试 网络层重试 超时 请求级控制 熔断 故障隔离 流量切分 金丝雀发布 遥测 统一指标和追踪 授权 服务访问控制 29.3 代价 sidecar 资源； 延迟； 运维复杂度； 排障链路变长； 应用仍需处理业务幂等； 升级风险。不是所有团队都需要服务网格。中小系统可以先在 SDK、网关和 Kubernetes 原生对象中实现关键能力。29.4 流量切分VirtualService 示例：apiVersion: networking.istio.io/v1kind: VirtualServicemetadata: name: order-servicespec: hosts: - order-service http: - route: - destination: host: order-service subset: stable weight: 90 - destination: host: order-service subset: canary weight: 1029.5 可观测性网格可以统一输出： 请求 QPS； 错误率； 延迟分布；4.上下游关系； 连接错误； 重试次数。业务语义错误仍需应用日志和业务指标判断。本章小结服务网格适合多语言、多团队、统一流量治理和安全策略的规模场景。引入前要评估延迟、资源、运维和排障成本。思考题 sidecar 模式的优点和代价是什么？ mTLS 解决什么问题？ 网络重试为什么要求业务幂等？ 流量切分如何支持金丝雀？ 什么时候不引入服务网格？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Kubernetes 上的 CI/CD 通常包括构建镜像、测试扫描、生成清单、GitOps 同步和发布验证。28.1 流程Git commit -> CI build -> unit test -> image build -> security scan -> push registry -> update manifest / GitOps repo -> CD sync -> health check28.2 镜像构建docker build \ -t registry.example.com/shop/order-service:1.2.0 .docker push registry.example.com/shop/order-service:1.2.0CI 建议： 版号来自 Git tag 或 commit； 构建缓存； 测试通过才推送； 扫描阻断高危； 生成 SBOM； 记录来源。28.3 Manifest 管理原始清单：kubectl apply -f deploy.yaml多环境管理： 工具 特点 Helm 包模板和版本化 Kustomize 原生叠加 Argo CD GitOps 同步 Flux GitOps Helm values：image: repository: registry.example.com/shop/order-service tag: 1.2.0replicas: 3resources: limits: cpu: "1" memory: 1Gi28.4 GitOpsApplication repo：业务代码Deployment repo：环境期望状态Cluster controller：同步期望状态原则： Git 是唯一入口； 环境分支或目录清晰； 状态漂移可发现； 审批流程可追溯； 回滚就是回退 Git 状态。28.5 发布验证自动检查： rollout 状态； Pod ready； HTTP 5xx； 核心指标； 日志错误； 合约测试； 冒烟测试。失败动作可以是暂停、缩回或通知人工确认。本章小结CI/CD 的关键是不可变镜像、可追溯清单、环境隔离、自动验证和可回滚发布。GitOps 让集群状态有唯一可信来源。思考题 为什么应用代码和部署仓库可以分离？ Helm 和 Kustomize 如何选择？ GitOps 回滚如何执行？ 发布验证应包含哪些指标？ 镜像扫描失败如何处理？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Operator 用自定义资源和控制器把领域专家的运维知识自动化，例如部署、扩容、备份、故障切换和升级。27.1 核心组成Custom Resource Definition -> Custom Resource -> Controller / Operator -> Reconcile desired state例如数据库 Operator 可以管理： 集群拓扑； 主从复制； 备份； 故障切换； 版本升级； 监控规则。27.2 CRD 示例apiVersion: apiextensions.k8s.io/v1kind: CustomResourceDefinitionmetadata: name: postgresclusters.example.comspec: group: example.com names: kind: PostgresCluster plural: postgresclusters singular: postgrescluster scope: Namespaced versions: - name: v1 served: true storage: true自定义资源：apiVersion: example.com/v1kind: PostgresClustermetadata: name: shop-dbspec: replicas: 3 version: "16" storage: 200Gi backup: schedule: "0 1 * * *"27.3 Reconcile 原则控制器会被反复调用，必须： 幂等； 不假设每次都成功； 处理最终一致； 依赖 status 而不是内存状态； 避免长时间阻塞； 正确处理删除和 finalizer。27.4 开发方式常用框架： 工具 特点 Kubebuilder Go 常用脚手架 Operator SDK 上游项目与生态集成 Metacontroller Webhook 模式扩展 Helm / Kustomize 只是模板，不是控制器 27.5 使用 Operator 的风险 复杂度转移而非消失； Operator 自身故障影响业务； CRD 版本演进复杂； 备份和升级路径要验证； 权限往往较大； 社区项目维护性不确定。本章小结Operator 把运维流程编码为控制循环，适合复杂有状态系统。使用前要评估成熟度、备份、升级、权限和故障场景。思考题 CRD 和 CR 的关系是什么？ Reconcile 为什么必须幂等？ Operator 适合哪些工作负载？ Operator 权限为什么要最小化？ 如何验证 Operator 升级方案？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。排查 Kubernetes 问题要先定位层级：对象状态、Pod 内应用、节点、网络、存储还是控制面。26.1 通用流程1. 确认影响面2. 查看 Pod 状态3. describe 获取事件4. logs 查看应用5. exec 检查进程和网络6. 检查 Service / Ingress7. 检查节点和事件8. 止血后定位根因26.2 常用命令kubectl get pods -A -o widekubectl get events -A --sort-by=.lastTimestampkubectl describe pod app -n shopkubectl logs app -n shop --previouskubectl exec -it app -n shop -- shkubectl top pods -n shopkubectl top nodes26.3 Pod 状态 状态 方向 Pending 调度、资源、PVC ContainerCreating 镜像、CNI、存储 ImagePullBackOff 镜像、凭据 CrashLoopBackOff 应用、配置、探针 OOMKilled 内存 limit Evicted 节点压力 Completed 正常结束 26.4 Service 不通kubectl get svc,endpoints order-service -n shopkubectl run debug --rm -it --image=busybox:1.36 --restart=Never -- sh排查： Service selector； Pod readiness； targetPort； DNS； NetworkPolicy； 应用监听地址； 防火墙或安全组。26.5 节点 NotReadykubectl describe node node-01systemctl status kubeletjournalctl -u kubelet -n 200常见原因： kubelet 停止； 证书过期； 容器运行时故障； 磁盘压力； 内存不足； 网络 CNI 异常。26.6 存储挂载失败kubectl describe pvc pg-datakubectl get volumeattachment方向： StorageClass； CSI 插件； 节点拓扑； 云平台配额； 文件系统格式； 权限； PV 绑定状态。26.7 控制面异常指标： API server P99； etcd 延迟； controller workqueue； scheduler pending； leader 选举。避免在控制面异常时执行大规模变更。本章小结Kubernetes 排查以状态和事件为入口，再进入容器、网络、存储、节点或控制面。先止血保护业务，再保留现场做根因分析。思考题 logs --previous 有什么作用？ Endpoints 为空如何排查？ 节点 NotReady 的常见原因？ FailedMount 如何定位？ 什么时候应暂停发布和变更？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。云原生系统故障传播快、动态性强，必须同时具备指标、日志、追踪和事件观测。25.1 三支柱 类型 回答 Metrics 系统是否异常，趋势如何 Logs 具体错误是什么 Traces 请求经过哪些服务，耗时在哪 Events Kubernetes 为什么操作对象 25.2 指标常用监控栈：Prometheus / VictoriaMetrics -> kube-state-metrics -> node-exporter -> application metrics -> Alertmanager核心指标： 层 指标 Node CPU、内存、磁盘、网络 Pod restarts、CPU、内存、网络 Workload replicas、ready、unavailable 控制面 API 延迟、etcd、leader 业务 QPS、错误率、延迟、成功率 25.3 日志推荐 stdout/stderr，由采集器集中处理：container stdout -> Fluent Bit -> Kafka/Loki/ES规范： JSON 日志； 统一时间； 带 trace_id； 不打印密码； 设置日志级别； 控制体量； 保留告警上下文。25.4 追踪Client -> Gateway -> Order -> Payment -> DBOpenTelemetry 统一采集： context propagation； service name； span attributes； 采样策略； 敏感信息脱敏。25.5 Kubernetes 事件kubectl get events -A --sort-by=.lastTimestamp关注： FailedScheduling； Unhealthy； BackOff； FailedMount； Evicted； ScalingReplicaSet。25.6 黄金指标 指标 说明 Latency 延迟 Traffic 流量 Errors 错误 Saturation 饱和度 服务 SLO 应围绕黄金指标和业务成功率建立。本章小结可观测性要能把告警定位到对象、事件、日志和调用链。指标发现异常，事件解释集群动作，日志给出错误细节，追踪还原请求路径。思考题 指标、日志、追踪分别解决什么问题？ 应用日志为什么推荐 stdout？ trace_id 有什么作用？ Kubernetes Events 能解释什么？ 如何设计服务 SLO？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Kubernetes NetworkPolicy 控制 Pod 之间以及 Pod 与外部的通信，是东西向流量零信任治理的基础。24.1 默认行为没有 NetworkPolicy 时，Pod 通常可以互相访问。可以先加默认拒绝：apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: default-deny namespace: shopspec: podSelector: {} policyTypes: - Ingress24.2 放行入口apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: allow-web-to-order namespace: shopspec: podSelector: matchLabels: app: order policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: shop podSelector: matchLabels: app: web ports: - protocol: TCP port: 808024.3 出口策略policyTypes: - Egressegress: - to: - namespaceSelector: {} ports: - protocol: UDP port: 53出口策略会影响 DNS、镜像拉取、外部 API 和数据库连接，上线必须逐步验证。24.4 依赖 CNINetworkPolicy 由 CNI 插件实现。Flannel 基础模式等实现不支持或不能完整支持 NetworkPolicy，Calico、Cilium 等更常用。24.5 排查kubectl get networkpolicy -Akubectl describe networkpolicy allow-web-to-order -n shopkubectl exec -it debug -- nc -vz order-service 8080 问题 排查 全部不通 默认拒绝 DNS 不通 egress 未放行 UDP/TCP 53 外部 API 不通 出口策略 跨命名空间不通 namespaceSelector 策略不生效 CNI 支持 本章小结NetworkPolicy 用于缩小攻击面。生产可以从关键命名空间默认拒绝开始，逐步放行白名单，并验证 CNI 支持、DNS、出口和审计。思考题 没有 NetworkPolicy 时 Pod 能否互访？ Ingress 和 Egress 策略分别管什么？ 为什么 DNS 常被误伤？ NetworkPolicy 是否由 kube-proxy 实现？ 如何渐进式落地默认拒绝？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Kubernetes 安全包括控制面访问、工作负载权限、网络边界、镜像供应链、Secret 和节点安全。RBAC 是权限治理的入口。23.1 RBAC 对象 对象 说明 Role 命名空间权限 ClusterRole 集群权限 RoleBinding 绑定到命名空间主体 ClusterRoleBinding 绑定集群主体 apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: name: developer namespace: shoprules: - apiGroups: [""] resources: ["pods", "pods/log", "services"] verbs: ["get", "list", "watch"]绑定：apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: developer-binding namespace: shopsubjects: - kind: User name: aliceroleRef: kind: Role name: developer apiGroup: rbac.authorization.k8s.io23.2 权限检查kubectl auth can-i list pods -n shopkubectl auth can-i delete deployments -n shop --as alicekubectl get role,rolebinding -n shop23.3 ServiceAccountPod 默认使用命名空间 ServiceAccount。应用访问 Kubernetes API 时： 只授予必要资源； 不给 cluster-admin； 明确 namespace； 审计 token 使用； 使用短周期凭据或投影卷。23.4 Pod Security避免：securityContext: privileged: true推荐：securityContext: runAsNonRoot: true runAsUser: 1000 allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: ["ALL"]可用 Pod Security Standards 或准入策略限制。23.5 API Server 安全 不暴露公网； 启用认证授权； 审计日志； TLS 证书管理； 禁止匿名访问； 限制 dashboard 权限； 定期审查 RBAC。23.6 供应链安全 镜像扫描； 签名验证； 私有仓库凭据控制； CI 最小权限； 准入策略阻断高危配置； 基础镜像更新流程。本章小结Kubernetes 安全要分层：控制面只暴露给可信网络，RBAC 最小授权，Pod 降低权限，镜像可追溯，Secret 有审计，节点和运行时持续加固。思考题 Role 和 ClusterRole 有什么区别？ 为什么 Pod 不应挂载高权限 ServiceAccount？ privileged 容器有什么风险？ API Server 为什么不应暴露公网？ 如何审计 Kubernetes 权限？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。StatefulSet 提供稳定网络标识、稳定存储和有序部署语义，适合数据库、消息队列和主从系统。22.1 稳定性 能力 含义 稳定 Pod 名 postgres-0、postgres-1 稳定 DNS pod-name.service-name.namespace 稳定存储 Pod 重建后绑定同一 PVC 有序部署 按序号创建和更新 22.2 示例apiVersion: apps/v1kind: StatefulSetmetadata: name: postgresspec: serviceName: postgres replicas: 3 selector: matchLabels: app: postgres template: metadata: labels: app: postgres spec: containers: - name: postgres image: postgres:16 volumeMounts: - name: data mountPath: /var/lib/postgresql/data volumeClaimTemplates: - metadata: name: data spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 200Gi22.3 Headless ServiceapiVersion: v1kind: Servicemetadata: name: postgresspec: clusterIP: None selector: app: postgres ports: - port: 5432每个 Pod 可以有稳定 DNS，用于主从发现。22.4 有序性默认按 0 -> n 创建，逆序更新。可用并行策略调整：spec: podManagementPolicy: Parallel updateStrategy: type: RollingUpdate业务是否能并行取决于复制协议和选举逻辑。22.5 扩缩容与更新扩容：kubectl scale statefulset/postgres --replicas=4缩容会删除最高序号 Pod，且 PVC 可能保留。数据类系统缩容前必须先确认副本迁出和一致性。22.6 StatefulSet 不是数据库高可用StatefulSet 只提供运行语义，不自动处理： 主从复制； 故障切换； 数据备份； 版本升级策略； 磁盘扩容； 主从发现。这些通常由 Operator 或专门运维平台实现。本章小结StatefulSet 为有状态应用提供稳定身份和存储，但业务高可用仍需复制、选举、备份和恢复逻辑。能自动重拉容器不等于数据服务已具备自愈能力。思考题 StatefulSet 的三个稳定性是什么？ Headless Service 有什么作用？ 缩容为什么危险？ podManagementPolicy 何时用 Parallel？ 为什么数据库常配合 Operator？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。HPA 根据指标自动调整 Pod 副本数，适合无状态、可水平扩展的服务。它不能替代容量规划和资源限制。21.1 HPA 对象apiVersion: autoscaling/v2kind: HorizontalPodAutoscalermetadata: name: order-servicespec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-service minReplicas: 3 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 6021.2 扩缩容算法简化公式：desired = currentReplicas * currentMetric / targetMetric结果会受 min / max、容忍度、稳定窗口和指标质量影响。21.3 指标来源常见指标： 指标 场景 CPU 通用基线 内存 缓存类需谨慎 QPS 入口流量 队列长度 消费者 自定义延迟 核心体验 自定义指标依赖 Metrics Server、Prometheus Adapter 或自定义指标 API。21.4 行为控制behavior: scaleDown: stabilizationWindowSeconds: 300 scaleUp: stabilizationWindowSeconds: 30扩容可以更快，缩容应更保守，避免流量震荡。21.5 前提条件 Deployment 设置资源 requests； 应用无状态； Pod 可安全加入和退出； 下游依赖可承受并发； 指标可靠； 命名空间配额足够； 节点资源可扩容。21.6 排查kubectl get hpa order-service -wkubectl describe hpa order-service常见问题： 现象 原因 unknown 缺 requests 或指标 不扩容 指标未达阈值 达到 max 容量或配额上限 震荡 稳定窗口太短 Pod Pending 节点资源不足 本章小结HPA 通过指标维护副本数。CPU 是基础，QPS 和队列长度更能反映业务压力。稳定扩缩容依赖 requests、健康检查、下游容量和节点弹性。思考题 HPA 为什么依赖 requests？ 队列长度指标适合什么服务？ 扩容和缩容窗口为什么不同？ HPA 能否解决节点资源不足？ 如何避免 HPA 震荡？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Kubernetes 支持声明式发布，但稳定发布依赖镜像不可变、探针合理、策略清晰和回滚预案。20.1 Deployment 更新kubectl set image deployment/order-service \ app=registry.example.com/shop/order-service:1.3.0kubectl rollout status deployment/order-service历史：kubectl rollout history deployment/order-service回滚：kubectl rollout undo deployment/order-servicekubectl rollout undo deployment/order-service --to-revision=320.2 滚动策略spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 参数 含义 maxUnavailable 更新时最多不可用副本数 maxSurge 最多临时超出期望副本数 0 / 1 更稳但速度较慢；1 / 0 快但可能短暂降容量。20.3 发布前检查1. 镜像 tag 不可变2. 数据库迁移兼容新旧版本3. 配置和 Secret 就绪4. 资源 requests / limits 足够5. 探针正确6. 日志指标可见7. 服务依赖可用8. 回滚预案明确20.4 数据库变更推荐 expand / migrate / contract：第一阶段：新增兼容字段和表第二阶段：双写或迁移数据第三阶段：应用切换新逻辑第四阶段：确认稳定后删除旧结构不要让新旧应用依赖不兼容的表结构。20.5 流量发布策略 策略 特点 Rolling 默认，逐批替换 Blue/Green 双环境切换 Canary 小流量验证 A/B 按用户特征分流 Feature Flag 业务逻辑开关 简单服务用 Deployment 滚动；核心链路可叠加网关灰度和监控自动回滚。20.6 发布失败判断观察： rollout 状态； Pod ready 数； HTTP 5xx； P95/P99 延迟； 核心业务成功率； 日志错误； 依赖资源指标。本章小结发布是版本、配置、数据、流量和观测的组合动作。Kubernetes 提供滚动和回滚能力，业务稳定性还需要兼容性设计、灰度和自动判断。思考题 maxSurge 和 maxUnavailable 如何权衡？ 为什么镜像 tag 要不可变？ 数据库兼容发布如何设计？ 金丝雀发布观察哪些指标？ 回滚是否总是能解决数据结构问题？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。健康检查决定容器何时可接流、何时重启、何时从 Service 摘除。配置过松会放大故障，过紧会造成误杀。19.1 探针类型 探针 作用 livenessProbe 失败后重启容器 readinessProbe 失败后摘除 Service 流量 startupProbe 启动成功前暂停其他探针 19.2 示例containers: - name: app image: shop/order-service:1.2.0 startupProbe: httpGet: path: /actuator/health/liveness port: 8080 failureThreshold: 30 periodSeconds: 2 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 periodSeconds: 10 timeoutSeconds: 2 failureThreshold: 3 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 periodSeconds: 5 timeoutSeconds: 2 failureThreshold: 319.3 探针方法httpGet: path: /healthz port: 8080tcpSocket: port: 5432exec: command: ["pg_isready", "-U", "app"]HTTP 最常用；TCP 只能证明端口监听；exec 可表达复杂检查但开销更高。19.4 liveness 与 readiness 场景 建议 依赖数据库不可用 readiness 失败，不随便 liveness 重启 死锁 liveness 重启 冷启动慢 startupProbe 队列消费暂停 readiness 摘除消费者 只读依赖慢 readiness 可返回失败 不要让 liveness 检查所有外部依赖，否则依赖故障会引发全量重启风暴。19.5 常见配置错误 错误 后果 无 readiness 未就绪 Pod 接流量 liveness 检查依赖 连锁重启 timeout 太短 高峰误杀 failureThreshold 太小 瞬时抖动重启 健康接口无超时 探针挂起 健康接口有副作用 高频调用影响业务 19.6 优雅停机terminationGracePeriodSeconds: 30应用应： 处理 SIGTERM； 停止接收新请求； 等待存量请求完成； 关闭连接和线程池； 必要时释放锁。本章小结startup 解决慢启动，readiness 控制接流，liveness 处理不可恢复进程状态。健康检查应与应用生命周期和优雅停机一起设计。思考题 为什么依赖故障通常不触发 liveness？ readiness 如何影响 Endpoints？ startupProbe 适合什么应用？ 健康接口应该检查哪些内容？ 优雅停机流程是什么？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。资源治理的目标是让节点稳定、应用性能可预期、成本可解释，而不是简单追求高利用率。18.1 QoS QoS 条件 Guaranteed requests = limits Burstable requests < limits BestEffort 无 requests / limits 节点压力驱逐时，BestEffort 通常最先被回收，Guaranteed 更稳定。18.2 LimitRangeapiVersion: v1kind: LimitRangemetadata: name: app-limitsspec: limits: - type: Container defaultRequest: cpu: 100m memory: 128Mi default: cpu: 500m memory: 512Mi为未声明资源的对象提供默认值。18.3 ResourceQuotaapiVersion: v1kind: ResourceQuotametadata: name: team-quotaspec: hard: requests.cpu: "20" requests.memory: 40Gi limits.cpu: "40" limits.memory: 80Gi pods: "200"限制命名空间总资源，防止团队之间相互影响。18.4 CPU 行为CPU limit 通过周期配额实现，超过后会节流：100m = 每 100ms 周期使用 10ms CPUCPU 节流表现为延迟上升，不一定是 CPU 使用率持续 100%。18.5 内存行为内存 limit 超过后可能 OOM Kill：OOMKilledJava 等运行时要感知容器内存限制，例如：-XX:MaxRAMPercentage=7018.6 成本治理 按命名空间和标签归属成本； 治理超规格 requests； 清理闲置服务； 使用 HPA 缩容； 评估 Spot / 抢占式实例； 审查日志和监控成本。本章小结资源治理通过 QoS、LimitRange、ResourceQuota、监控和成本归属实现稳定共享。关键服务建议 Guaranteed 或明确 requests / limits，避免无边界资源使用。思考题 三种 QoS 的驱逐顺序如何理解？ CPU 节流和 OOM 有什么差异？ LimitRange 和 ResourceQuota 如何配合？ Java 应用如何设置容器内存参数？ 如何按团队核算 Kubernetes 成本？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Scheduler 根据资源、亲和性、拓扑约束、污点和优先级为 Pod 选择节点。理解调度过程才能解释 Pending 和负载不均。17.1 调度流程过滤可用节点 -> 节点打分 -> 选择最高分节点 -> 绑定 Pod17.2 资源请求resources: requests: cpu: 500m memory: 1Gi limits: cpu: "1" memory: 2Gi调度使用 requests，运行时限制使用 limits。没有 requests 的 Pod 可能挤占节点资源并影响调度判断。17.3 Node Selector 与 Affinity节点选择：nodeSelector: disktype: ssd节点亲和：affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-type operator: In values: [worker]Pod 反亲和：affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: order topologyKey: kubernetes.io/hostname17.4 Taint 与 Toleration添加污点：kubectl taint nodes node-01 dedicated=database:NoSchedule容忍：tolerations: - key: dedicated operator: Equal value: database effect: NoSchedule常见 effect： Effect 含义 NoSchedule 不调度新 Pod PreferNoSchedule 尽量不调度 NoExecute 驱逐不容忍的 Pod 17.5 Priority 与 Preemption高优先级 Pod 资源不足时可能驱逐低优先级 Pod。必须谨慎设置，避免关键系统组件被业务任务抢占。17.6 Pod Topology SpreadtopologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: order用于控制节点、机架或可用区分布。17.7 Pending 排查kubectl describe pod app常见原因： CPU / 内存不足； GPU 或设备不可用； 节点选择器无匹配； 污点未容忍； PVC 拓扑等待； 端口冲突； 反亲和过严。本章小结调度由 requests、亲和性、污点容忍、拓扑约束和优先级共同决定。生产应为所有容器设置资源请求，并用拓扑分布降低故障域集中风险。思考题 requests 和 limits 在调度中的作用有何不同？ 什么场景使用 Pod 反亲和？ 污点和容忍解决什么问题？ maxSkew 如何影响分布？ Pending 应如何定位？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Kubernetes 通过 StorageClass、PersistentVolume 和 PersistentVolumeClaim 解耦应用存储需求与底层存储实现。16.1 核心对象 对象 职责 PV 集群存储资源 PVC 用户存储申请 StorageClass 动态供给模板 CSI 存储驱动接口 Pod -> PVC -> PV -> Storage Backend16.2 PVCapiVersion: v1kind: PersistentVolumeClaimmetadata: name: pg-dataspec: accessModes: - ReadWriteOnce storageClassName: fast-ssd resources: requests: storage: 100Gi访问模式： 模式 含义 ReadWriteOnce 单节点读写 ReadOnlyMany 多节点只读 ReadWriteMany 多节点读写 ReadWriteOncePod 单 Pod 读写 实际支持取决于存储插件。16.3 Pod 挂载spec: containers: - name: postgres image: postgres:16 volumeMounts: - name: data mountPath: /var/lib/postgresql/data volumes: - name: data persistentVolumeClaim: claimName: pg-data16.4 StorageClassapiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: fast-ssdprovisioner: ebs.csi.aws.comparameters: type: gp3reclaimPolicy: DeletevolumeBindingMode: WaitForFirstConsumerreclaimPolicy: Delete 表示删除 PVC 后释放存储。数据安全要求高的场景应评估 Retain 或快照策略。16.5 扩容与快照在线扩容依赖 CSI 与 StorageClass 支持。扩容前要确认文件系统和云平台限制。快照：kubectl get volumesnapshot快照不等于完整备份，仍要验证恢复和一致性。16.6 常见问题 问题 排查 Pending StorageClass、容量、拓扑 VolumeAttachment 失败 CSI、节点、权限 Mount 失败 文件系统、路径、权限 多写损坏 访问模式误用 删除 PVC 数据丢失 reclaimPolicy 查看：kubectl describe pvc pg-datakubectl get pvkubectl get sckubectl get events --sort-by=.lastTimestamp本章小结Kubernetes 存储以 PVC 声明需求，由 StorageClass 和 CSI 动态供给。生产要确认访问模式、回收策略、扩容、快照、备份和恢复演练。思考题 PV 和 PVC 的关系是什么？ RWO 为什么不能随便多节点挂载？ WaitForFirstConsumer 有什么优点？ reclaimPolicy 如何选择？ 快照和备份有什么差异？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Ingress 提供 HTTP/HTTPS 路由，Gateway API 是更通用的新一代路由模型。两者都依赖具体控制器实现。15.1 Ingress 架构Client -> LoadBalancer -> Ingress Controller Pod -> Service -> PodsIngress 本身只是规则，控制器负责真正执行。15.2 Ingress 示例apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: shop-ingress annotations: nginx.ingress.kubernetes.io/ssl-redirect: "true"spec: ingressClassName: nginx tls: - hosts: - shop.example.com secretName: shop-tls rules: - host: shop.example.com http: paths: - path: /api/orders pathType: Prefix backend: service: name: order-service port: number: 80 - path: / pathType: Prefix backend: service: name: web port: number: 8015.3 Gateway APIGateway API 将角色拆分为 GatewayClass、Gateway、HTTPRoute 等对象，提供更强的扩展性和权限边界：apiVersion: gateway.networking.k8s.io/v1kind: HTTPRoutemetadata: name: order-routespec: parentRefs: - name: shop-gateway hostnames: - shop.example.com rules: - matches: - path: type: PathPrefix value: /api/orders backendRefs: - name: order-service port: 8015.4 控制器选择 场景 方案 HTTP 路由 NGINX Ingress、Gateway API API 管理 APISIX、Kong 等 服务网格网关 Istio Gateway TCP/UDP LoadBalancer 或专用控制器 15.5 常见排查kubectl get ingresskubectl describe ingress shop-ingresskubectl get gateway,httproute -A 问题 排查 404 host/path/backend 匹配 502 后端 Service 或应用 证书错误 TLS Secret 不生效 controller、class 延迟高 controller 资源 本章小结Ingress 和 Gateway API 管理南北向 HTTP 流量。路由规则只是声明，控制器实现、TLS、后端健康和资源容量决定最终效果。思考题 Ingress 和 Ingress Controller 的关系是什么？ pathType 有什么影响？ Gateway API 相比 Ingress 有哪些改进？ 502 如何排查？ TLS Secret 应如何管理？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Pod IP 是易变的，Service 提供稳定虚拟 IP、名称和负载均衡能力，是 Kubernetes 内部服务发现的核心。14.1 Service 类型 类型 说明 ClusterIP 集群内虚拟 IP NodePort 每节点开放端口 LoadBalancer 云负载均衡器 ExternalName DNS CNAME Headless 不分配 ClusterIP 14.2 ClusterIPapiVersion: v1kind: Servicemetadata: name: order-servicespec: type: ClusterIP selector: app: order ports: - name: http port: 80 targetPort: 8080集群内访问：http://order-service.default.svc.cluster.local14.3 Headlessspec: clusterIP: NoneDNS 会返回后端 Pod IP 列表，常用于 StatefulSet、数据库主从和客户端负载均衡。14.4 NodePort 与 LoadBalancerNodePort：spec: type: NodePort ports: - port: 80 targetPort: 8080 nodePort: 30080LoadBalancer 适合直接暴露 TCP/UDP 服务，云厂商负责创建外部负载均衡器。14.5 Endpointskubectl get endpoints order-serviceService 通过 selector 找到 Pod，并把符合 readiness 的 Pod 加入 Endpoints。常见问题： 现象 原因 Endpoints 为空 selector 错、readiness 失败 访问不通 网络策略、kube-proxy 流量不均 长连接、客户端缓存 502 应用未监听 targetPort 14.6 服务发现CoreDNS 提供：service-name.namespace.svc.cluster.local跨命名空间必须使用完整域名。同命名空间可简化为服务名。本章小结Service 屏蔽 Pod IP 变化，实现稳定服务发现和四层负载均衡。ClusterIP 服务内部通信，Headless 服务有状态发现，LoadBalancer 暴露外部流量。思考题 Service 如何选择后端 Pod？ Endpoints 为空如何排查？ Headless Service 适合什么场景？ targetPort 和 port 有什么区别？ 跨命名空间如何访问服务？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。ConfigMap 管理普通配置，Secret 管理敏感数据。它们把镜像和配置解耦，但都不是完整的密钥管理系统。13.1 ConfigMapapiVersion: v1kind: ConfigMapmetadata: name: order-configdata: application.yaml: | server: port: 8080 logging: level: root: INFO APP_ENV: prod使用环境变量：env: - name: APP_ENV valueFrom: configMapKeyRef: name: order-config key: APP_ENV挂载文件：volumeMounts: - name: config mountPath: /etc/appvolumes: - name: config configMap: name: order-config13.2 Secretkubectl create secret generic db-secret \ --from-literal=username=app \ --from-literal=password='strong-password'使用：env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: passwordSecret 默认只是 base64 编码，必须配合 RBAC、etcd 加密、磁盘权限和网络隔离。13.3 配置更新 注入方式 更新行为 env Pod 启动后通常不更新 volume kubelet 周期同步 subPath 通常不会自动更新 配置变更是否生效还取决于应用是否支持热加载。常见策略是滚动重启：kubectl rollout restart deployment/order-service13.4 immutableapiVersion: v1kind: ConfigMapmetadata: name: app-configimmutable: truedata: APP_MODE: readonly不可变配置可以降低 kubelet 监控成本，修改需替换对象。13.5 管理kubectl get configmapkubectl get secretkubectl describe configmap order-config生产建议： Secret 独立权限； 大配置拆分； 变更走 GitOps； 不把 Secret 提交 Git； 使用外部密钥系统或 CSI Secret Store； 审计访问。本章小结ConfigMap 和 Secret 把配置从镜像中拆出来。环境变量适合简单配置，卷挂载适合文件；敏感数据要结合加密、RBAC、审计和外部密钥管理。思考题 ConfigMap 和 Secret 的边界是什么？ 环境变量注入后能否热更新？ subPath 挂载为什么更新异常？ Secret 默认安全吗？ 如何设计配置变更流程？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。控制器负责维护工作负载期望状态。不同控制器对应不同生命周期语义，不能只按“能启动”选择。12.1 DeploymentapiVersion: apps/v1kind: Deploymentmetadata: name: order-servicespec: replicas: 3 selector: matchLabels: app: order template: metadata: labels: app: order spec: containers: - name: app image: registry.example.com/shop/order-service:1.2.0查看：kubectl get deployment order-servicekubectl rollout status deployment/order-servicekubectl rollout history deployment/order-service12.2 ReplicaSetDeployment 管理 ReplicaSet，ReplicaSet 管理 Pod 副本。滚动发布时会同时存在新旧 ReplicaSet。12.3 StatefulSetapiVersion: apps/v1kind: StatefulSetmetadata: name: postgresspec: serviceName: postgres-headless replicas: 3 selector: matchLabels: app: postgres template: metadata: labels: app: postgres spec: containers: - name: postgres image: postgres:16 volumeMounts: - name: data mountPath: /var/lib/postgresql/data volumeClaimTemplates: - metadata: name: data spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 100Gi适合数据库、消息系统等有稳定网络标识和存储的工作负载。12.4 DaemonSetapiVersion: apps/v1kind: DaemonSetmetadata: name: node-exporter每个满足条件的节点运行一个 Pod，适合日志采集、监控 Agent 和网络组件。12.5 Job 与 CronJobJob：apiVersion: batch/v1kind: Jobmetadata: name: data-migratespec: backoffLimit: 3 template: spec: restartPolicy: Never containers: - name: migrate image: shop/migration:1.0.0CronJob：apiVersion: batch/v1kind: CronJobmetadata: name: daily-reportspec: schedule: "5 1 * * *" concurrencyPolicy: Forbid jobTemplate: spec: ...12.6 控制器选择 需求 控制器 无状态服务 Deployment 稳定标识和存储 StatefulSet 每节点一个 DaemonSet 一次性任务 Job 定时任务 CronJob 特殊自定义控制 Operator 本章小结控制器是声明式模型的大脑。Deployment 管发布，StatefulSet 管有状态语义，DaemonSet 覆盖节点级任务，Job 与 CronJob 处理批处理。选择控制器就是选择生命周期。思考题 Deployment 和 ReplicaSet 的关系是什么？ StatefulSet 的稳定标识有哪些用途？ DaemonSet 适合什么场景？ Job 重试策略如何设计？ 哪些应用不适合 Deployment？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Pod 是 Kubernetes 最小调度单元，包含一个或多个共享网络和存储的容器。应用设计应尽量无状态、可重启、可替换。11.1 Pod 示例apiVersion: v1kind: Podmetadata: name: order-app labels: app: orderspec: restartPolicy: Always containers: - name: app image: registry.example.com/shop/order-service:1.2.0 ports: - containerPort: 8080 resources: requests: cpu: 250m memory: 512Mi limits: cpu: "1" memory: 1Gi env: - name: APP_ENV value: prod11.2 Pod 内容器同一 Pod 内： 共享网络命名空间； 可通过 localhost 通信； 可共享 Volume； 共享 IPC 和 UTS； 生命周期绑定。多容器模式： 模式 用途 sidecar 代理、日志收集 adapter 输出格式转换 ambassador 外部访问代理 init 初始化任务 11.3 Pod 阶段 阶段 含义 Pending 已创建，未运行 Running 至少一个容器运行 Succeeded 成功退出 Failed 失败退出 Unknown 状态未知 查看：kubectl get pod order-app -o widekubectl describe pod order-appkubectl logs order-app -c appkubectl get events --field-selector involvedObject.name=order-app11.4 Init ContainerinitContainers: - name: wait-db image: busybox:1.36 command: ['sh', '-c', 'until nc -z postgres 5432; do sleep 2; done']Init 容器按顺序执行，全部成功后主容器才启动。11.5 静态 Pod静态 Pod 由节点上的 kubelet 直接管理，常用于控制面组件：/etc/kubernetes/manifests/kube-apiserver.yaml不要把业务应用配置成静态 Pod。11.6 Pod 排查kubectl exec -it order-app -- shkubectl port-forward pod/order-app 8080:8080kubectl get pod order-app -o yaml 状态 常见原因 Pending 资源不足、亲和性、污点 ContainerCreating CNI、镜像、存储 ImagePullBackOff 凭据、镜像不存在 CrashLoopBackOff 应用错误、配置错误 OOMKilled 内存 limit 过低 Evicted 节点压力 本章小结Pod 封装共享环境的容器组。生产应设置 requests / limits、健康探针、优雅停机和日志策略，并通过 describe、logs 和 events 快速定位阶段问题。思考题 为什么 Pod 而不是容器作为调度单元？ 同 Pod 容器如何通信？ Init Container 适合什么任务？ OOMKilled 和 CrashLoopBackOff 有什么区别？ 静态 Pod 适合哪些组件？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。生产集群通常使用托管 Kubernetes、kubeadm 或企业发行版。本章覆盖 kubeadm 学习环境、验证命令和容量规划。10.1 集群规划最小测试集群：1 control-plane node2 worker nodes生产建议：3 或更多 control-plane 节点worker 按业务隔离etcd 使用低延迟 SSD控制面与工作负载分离必须规划： 节点规格； Pod CIDR 与 Service CIDR； 网络插件； DNS； 存储； 镜像仓库； 证书有效期； 升级窗口。10.2 kubeadm 初始化准备主机后安装 kubelet、kubeadm、kubectl 和 containerd。控制面：sudo kubeadm init \ --pod-network-cidr 10.244.0.0/16 \ --service-cidr 10.96.0.0/12 \ --upload-certs配置 kubectl：mkdir -p $HOME/.kubesudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/configsudo chown $(id -u):$(id -g) $HOME/.kube/config节点加入：sudo kubeadm join control-plane:6443 \ --token <token> \ --discovery-token-ca-cert-hash sha256:<hash>10.3 安装 CNI以 Calico 或 Flannel 为例，安装前确认版本兼容性：kubectl apply -f cni-manifest.yaml没有 CNI 时 Pod 会停留 ContainerCreating 或 Pending。10.4 验证集群kubectl get nodes -o widekubectl get pods -Akubectl cluster-infokubectl get componentstatuses运行测试：kubectl run nginx --image=nginx:1.27 --restart=Neverkubectl get pod nginx -w10.5 常见问题 问题 排查 NotReady kubelet、CNI、证书 Pending 调度器、资源、污点 ImagePullBackOff 镜像仓库、网络 CrashLoopBackOff 应用、配置、探针 join 失败 token、端口、时间 10.6 生产选择 方案 特点 云托管 控制面托管，Node 管理 kubeadm 自管常见方案 发行版 企业集成 轻量发行版 边缘或实验 生产自建要额外承担证书、etcd 备份、升级、网络、存储、监控和灾备。本章小结搭建集群前先规划网络、存储、规格和升级路径。kubeadm 适合理解集群组成，生产应优先评估托管或成熟发行版，并验证节点、CNI、DNS 和工作负载健康。思考题 为什么 etcd 要用低延迟磁盘？ Pod CIDR 和 Service CIDR 冲突会怎样？ 没有 CNI 时 Pod 会怎样？ 节点 NotReady 如何排查？ 自建和托管集群的运维边界是什么？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Kubernetes 将集群资源抽象成 API 对象，由控制面声明式驱动，让工作负载自愈、可调度、可扩展。9.1 控制面组件 组件 职责 kube-apiserver API 入口、认证授权、etcd 读写 etcd 分布式键值存储 kube-scheduler 为待调度 Pod 选择节点 kube-controller-manager 控制器循环 cloud-controller-manager 云厂商集成 9.2 节点组件 组件 职责 kubelet 管理节点上容器生命周期 kube-proxy Service 转发规则 container runtime 运行容器，如 containerd CNI Pod 网络 CSI 存储接入 9.3 声明式模型apiVersion: apps/v1kind: Deploymentmetadata: name: order-servicespec: replicas: 3 selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: containers: - name: app image: registry.example.com/shop/order-service:1.2.0控制器不断比较期望状态和实际状态：Desired: 3 replicasActual: 2 replicasAction: create 1 Pod9.4 常见对象 对象 作用 Pod 最小调度单元 Deployment 无状态发布 StatefulSet 有状态工作负载 DaemonSet 每节点一个 Job / CronJob 任务 Service 稳定访问入口 Ingress HTTP 路由 ConfigMap 配置 Secret 敏感配置 PVC 存储声明 HPA 自动扩缩容 9.5 控制循环Watch API objects -> Compare desired and observed state -> Reconcile -> Update status这种模型适合最终一致系统，但要求应用支持幂等、健康检查和优雅停机。9.6 API 请求流程kubectl -> authentication -> authorization -> admission controllers -> validation -> etcd -> controllers / scheduler / kubelet9.7 Pod 创建流程提交 Deployment -> ReplicaSet 创建 Pod -> Scheduler 绑定 node -> kubelet 调用 containerd -> CNI 分配 IP -> 探针通过后接流本章小结Kubernetes 的核心是 API、etcd、控制器、调度器和 kubelet 组成的声明式闭环。理解对象职责和控制循环，是后面排查调度、发布、网络和存储问题的基础。思考题 etcd 挂了会有什么影响？ Scheduler 和 kubelet 分别负责什么？ 声明式和命令式有什么差异？ API 请求经过哪些控制点？ Pod 是什么级别的调度单元？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。镜像仓库是软件供应链的核心节点。生产要控制镜像来源、版本、签名、扫描、账号和同步策略。8.1 常见仓库 类型 示例 公共仓库 Docker Hub 云厂商仓库 各云容器镜像服务 私有仓库 Harbor、Registry CI 内部缓存 构建缓存仓库 私有 Harbor 常提供项目管理、复制、扫描、签名和审计能力。8.2 镜像命名registry.example.com/team/service:versionregistry.example.com/team/service@sha256:digest建议： 使用团队 / 服务层级； tag 包含版本或 Git SHA； 生产部署引用摘要或不可变 tag； 不复用已推送 tag； 禁止生产使用 latest。8.3 登录与推送docker login registry.example.comdocker build -t registry.example.com/shop/order-service:1.2.0 .docker push registry.example.com/shop/order-service:1.2.0凭据应从 CI Secret 或密钥管理系统注入，不写入脚本。8.4 漏洞扫描trivy image registry.example.com/shop/order-service:1.2.0治理策略： 构建时扫描； 阻断高危漏洞； 定期重扫存量镜像； 跟踪基础镜像更新； 记录豁免原因和期限。8.5 内容信任与签名镜像签名用于确认镜像来源和内容未被篡改。常见能力包括 Notary、Cosign 和仓库策略。落地时要与 Kubernetes 准入策略配合，未签名镜像不允许部署。8.6 仓库运维必须规划： 存储容量和增长； GC 策略； 多机房同步； 备份恢复； 拉取限流； 审计日志； 账号权限； 证书和域名。8.7 供应链安全流程代码提交 -> CI 构建不可变镜像 -> 单元测试和安全扫描 -> 镜像签名 -> 推送私有仓库 -> 准入校验 -> 部署生产本章小结镜像仓库不只是存储镜像。生产需要不可变版本、漏洞扫描、签名校验、权限控制和容量治理，把供应链安全嵌入构建和发布流程。思考题 为什么生产要使用不可变 tag 或摘要？ 漏洞扫描为什么需要定期重扫？ 镜像签名解决什么问题？ 私有仓库如何做高可用？ 如何阻断未签名镜像部署？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Docker Compose 用一个 YAML 定义多容器应用的镜像、网络、卷、依赖和环境，适合本地开发、测试和小规模部署。7.1 示例services: app: image: shop/order-service:1.2.0 build: context: . dockerfile: Dockerfile ports: - "8080:8080" environment: SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/shop SPRING_PROFILES_ACTIVE: local depends_on: postgres: condition: service_healthy networks: - shop postgres: image: postgres:16 environment: POSTGRES_DB: shop POSTGRES_USER: app POSTGRES_PASSWORD: local-password volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U app -d shop"] interval: 5s timeout: 3s retries: 10 networks: - shopnetworks: shop:volumes: pgdata:7.2 常用命令docker compose up -ddocker compose psdocker compose logs -f appdocker compose exec app shdocker compose builddocker compose pulldocker compose downdocker compose down -vdown -v 会删除 Compose 声明的匿名卷和命名卷，慎用。7.3 配置拆分docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d基础文件放通用定义，环境文件覆盖差异：services: app: environment: SPRING_PROFILES_ACTIVE: prod deploy: resources: limits: cpus: "1" memory: 1G7.4 健康检查与依赖depends_on: postgres: condition: service_healthy注意健康只表示依赖服务就绪，不代表业务数据初始化完成。7.5 开发与生产边界 场景 建议 本地开发 Compose 模拟依赖 CI Compose 起测试环境 单机部署 Compose 可用，但要有备份升级方案 多机生产 使用 Kubernetes 或其他编排系统 本章小结Compose 把多容器应用声明成可重复启动的拓扑。重点管理网络、卷、健康检查、环境差异和清理行为；它不是完整的生产编排系统。思考题 depends_on 是否保证数据库初始化完成？ 如何拆分多环境 Compose 配置？ down -v 有什么风险？ Compose 和 Kubernetes 的边界是什么？ 如何为 Compose 应用设计备份？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。容器层随容器删除而消失。持久化数据必须明确使用 Volume 或 Bind Mount，并理解它们的生命周期与备份方式。6.1 三种挂载 类型 说明 volume Docker 管理卷 bind mount 挂载宿主机路径 tmpfs 内存文件系统 docker run -d \ --name postgres \ -e POSTGRES_PASSWORD=postgres \ -v pgdata:/var/lib/postgresql/data \ postgres:166.2 Volumedocker volume create pgdatadocker volume lsdocker volume inspect pgdata特点： 由 Docker 管理； 与容器生命周期解耦； 删除容器不会删除卷； 便于备份和迁移； 可由驱动接入远端存储。6.3 Bind Mountdocker run --rm \ -v "$PWD/app.conf:/etc/app/app.conf:ro" \ my-app适合开发热更新配置和代码，但路径依赖宿主机布局，生产更推荐 Volume 或配置管理。6.4 tmpfsdocker run --rm \ --tmpfs /tmp:size=100m,mode=1777 \ my-app适合临时文件和敏感临时数据，容器停止后消失。6.5 数据备份备份 PostgreSQL 卷：docker run --rm \ -v pgdata:/source:ro \ -v "$PWD/backup:/backup" \ alpine tar czf /backup/pgdata-$(date +%F).tar.gz -C /source .恢复：docker run --rm \ -v pgdata:/target \ -v "$PWD/backup:/backup" \ alpine sh -c 'rm -rf /target/* && tar xzf /backup/pgdata-2026-08-25.tar.gz -C /target'数据库应优先使用数据库原生备份工具，而不是只备份文件。6.6 清理与风险查看占用：docker system df -v删除：docker volume rm pgdatadocker volume prunedocker volume prune 会删除未被容器引用的卷，执行前必须确认业务影响。本章小结Volume 适合持久数据，Bind Mount 适合开发配置，tmpfs 适合临时数据。备份要考虑应用一致性，清理卷前必须确认引用关系。思考题 容器可写层和 Volume 有什么区别？ Bind Mount 有哪些生产风险？ 什么时候使用 tmpfs？ 如何备份数据库容器？ volume prune 为什么危险？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。容器网络让不同容器、宿主机和外部系统通信。本章讲端口映射、bridge 网络、容器 DNS、host 与 none 模式，以及跨主机网络的基本原理。5.1 网络模式docker network ls 模式 说明 bridge 默认虚拟网桥 host 共享宿主机网络栈 none 无网络 container 复用另一容器网络栈 overlay 跨主机虚拟网络 5.2 bridgedocker network create app-netdocker run -d --name redis --network app-net redis:7.2docker run -d --name app --network app-net -p 8080:8080 my-app同网络容器可通过内置 DNS 名称访问：docker exec app ping -c 2 redis5.3 端口映射docker run -d -p 8080:80 -p 9090:9090/udp nginx:1.27格式：-p hostPort:containerPort/protocol-p hostIp:hostPort:containerPort查看：docker port webss -lntp | grep 80805.4 容器间通信docker network inspect app-net要点： 同 bridge 网络默认可通信； 不同 bridge 网络默认隔离； 使用服务名而不是动态 IP； 容器重启后 IP 可能变化； 内置 DNS 只在自定义网络中方便使用。5.5 host 与 nonehost：docker run --network host nginx:1.27性能较好，但缺少网络隔离，端口冲突由宿主机承担。none：docker run --network none busybox sleep 100适合完全离线的批处理或安全敏感任务。5.6 overlayDocker Swarm 或集群环境使用 overlay：docker network create -d overlay app-overlay跨主机容器通信需要控制面和数据面配合，Kubernetes 中由 CNI 插件实现。5.7 常见排查容器内 DNS：docker exec app cat /etc/resolv.confdocker exec app getent hosts redis连通性：docker exec app sh -c 'nc -vz redis 6379'宿主机转发：sudo iptables -t nat -L -n 问题 排查 端口不通 端口映射、监听地址、防火墙 名称不通 是否同网络、DNS 随机断连 MTU、网络策略 性能差 NAT、代理、DNS 本章小结单机 Docker 常用自定义 bridge 提供稳定 DNS 和隔离；host 模式性能好但隔离弱；跨主机网络依赖 overlay 或 Kubernetes CNI。排查网络先确认网络域、DNS、端口和防火墙。思考题 为什么应用要连接服务名而不是容器 IP？ bridge 和 host 网络有什么差异？ 不同 bridge 网络之间默认能否通信？ 端口映射后如何定位不通？ overlay 网络解决什么问题？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。Dockerfile 决定镜像是否可复现、是否安全、是否够小、是否能稳定运行。生产镜像从 Dockerfile 设计开始。4.1 基础示例FROM eclipse-temurin:17-jre-alpineWORKDIR /appCOPY target/order-service.jar app.jarRUN addgroup -S app && adduser -S app -G appUSER appENV JAVA_OPTS="-XX:MaxRAMPercentage=70" \ TZ=Asia/ShanghaiEXPOSE 8080HEALTHCHECK --interval=30s --timeout=3s --retries=3 \ CMD wget -qO- http://127.0.0.1:8080/actuator/health || exit 1ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app/app.jar"]4.2 指令解析 指令 作用 FROM 基础镜像 RUN 构建期执行命令 COPY 复制上下文文件 ADD 复制并支持自动解压，慎用 ENV 环境变量 ARG 构建参数 WORKDIR 工作目录 USER 运行用户 EXPOSE 声明端口 HEALTHCHECK 容器健康检查 ENTRYPOINT 主命令 CMD 默认参数 4.3 层缓存低频变化放前，高频变化放后：COPY pom.xml .RUN mvn dependency:go-offlineCOPY src ./srcRUN mvn package -DskipTests多阶段构建：FROM maven:3.9-eclipse-temurin-17 AS buildWORKDIR /srcCOPY pom.xml .RUN mvn dependency:go-offlineCOPY src ./srcRUN mvn package -DskipTestsFROM eclipse-temurin:17-jre-alpineWORKDIR /appCOPY --from=build /src/target/app.jar app.jarUSER appENTRYPOINT ["java", "-jar", "/app/app.jar"]4.4 ENTRYPOINT 与 CMDENTRYPOINT ["java", "-jar", "app.jar"]CMD ["--spring.profiles.active=prod"]区别： 指令 覆盖方式 ENTRYPOINT 需要 --entrypoint 覆盖 CMD docker run image args 直接覆盖 应用容器应保证 PID 1 能转发 SIGTERM。Shell 形式可能不会转发信号，exec 形式更常用。4.5 镜像安全原则： 固定基础镜像版本； 使用官方或可信镜像； 非 root 运行； 不把 Secret 写入镜像； 清理包缓存和测试文件； 使用镜像扫描； 启用内容信任； 最小化安装包。扫描：trivy image shop/order-service:v1.2.04.6 构建变量与 Secret普通构建参数：ARG APP_VERSION=devENV APP_VERSION=${APP_VERSION}构建命令：docker build --build-arg APP_VERSION=1.2.0 -t order-service:1.2.0 .不要用 ARG 传密码。敏感值应通过运行时 Secret、构建挂载或 CI 密钥管理注入。4.7 常见反模式 反模式 问题 使用 latest 不可复现 root 运行 安全风险 一个镜像包含多个服务 边界混乱 日志写容器层 数据丢失 只写 CMD 不处理信号 优雅停机失败 ADD url 下载依赖 不可控 把数据库密码写入 ENV 泄露 依赖交互式初始化 容器无法自愈 本章小结好的 Dockerfile 应固定版本、多阶段构建、非 root 运行、按缓存优化层顺序、处理信号和健康检查，并把 Secret 留在运行时注入。思考题 为什么依赖文件先 COPY？ ENTRYPOINT 和 CMD 如何配合？ 多阶段构建解决什么问题？ 为什么 Shell 形式可能影响优雅停机？ 镜像漏洞治理流程是什么？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。镜像是只读模板，容器是镜像的运行实例。理解分层结构、写时复制和容器生命周期，才能做安全、快速、可复现的交付。3.1 分层镜像Layer 1: base osLayer 2: runtimeLayer 3: dependenciesLayer 4: applicationContainer writable layer特点： 镜像层只读； 多镜像共享层； 构建缓存依赖指令顺序； 删除容器会删除可写层； Volume 挂载的数据不随容器层删除。查看镜像：docker imagesdocker image inspect nginx:1.27docker history nginx:1.273.2 拉取与运行docker pull nginx:1.27docker run -d --name web -p 8080:80 nginx:1.27docker psdocker logs -f webdocker exec -it web sh镜像 tag：registry.example.com/shop/order-service:v1.2.0生产不要只使用 latest，应使用不可变版本 tag 或镜像摘要。3.3 容器生命周期Created -> Running -> Paused -> Stopped -> Deleted常用命令：docker create --name web nginx:1.27docker start webdocker restart webdocker stop webdocker rm webdocker rm -f web退出容器：docker ps -adocker logs exited-containerdocker inspect exited-container --format '{{.State.ExitCode}}'3.4 前台进程与退出码容器生命周期由 PID 1 进程决定：docker run --name bad -d ubuntu sleep 300PID 1 退出后容器退出。常见退出码： 退出码 含义 0 正常退出 1 应用错误 125 Docker 命令错误 126 命令不可执行 127 命令不存在 137 SIGKILL，常见 OOM 139 段错误 143 SIGTERM 正常终止 3.5 资源限制docker run -d \ --name app \ --cpus="1.0" \ --memory="512m" \ --memory-swap="512m" \ --pids-limit=200 \ nginx:1.27查看：docker statsdocker inspect app --format '{{.HostConfig.Memory}}'内存超限可能触发 OOM Kill；CPU 限制更多表现为节流和变慢。3.6 容器与宿主机交互环境变量：docker run --rm -e APP_ENV=prod alpine printenv APP_ENV文件挂载：docker run --rm -v "$PWD/app.conf:/etc/app/app.conf" alpine cat /etc/app/app.conf端口：docker run -d -p 8080:80 -p 9090:9090/udp nginx:1.273.7 导出与导入保存镜像：docker save -o order.tar order-service:v1docker load -i order.tar导出容器文件系统：docker export web | gzip > web-rootfs.tar.gzdocker import web-rootfs.tar.gz web:manualsave/load 保留镜像层和历史，适合分发镜像；export/import 丢失部分元数据，适合调试文件系统。3.8 清理docker container prunedocker image prunedocker volume prunedocker builder prunedocker system dfdocker system prune生产慎用自动清理，尤其 volume prune 可能删除仍需使用但未挂载的数据卷。本章小结镜像是静态模板，容器是受限进程。生产应固定版本、限制资源、正确处理 PID 1、区分容器层和持久化卷，并谨慎清理镜像与卷。思考题 容器为什么共享宿主机内核？ 镜像层和容器可写层有什么区别？ 退出码 137 通常说明什么？ save/load 和 export/import 有何差异？ 为什么生产不用 latest 标签？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。本章安装 Docker Desktop、Docker Engine，并梳理生产环境的目录规划、权限、代理、镜像加速和验证方法。2.1 安装前检查Linux 检查：uname -acat /etc/os-releasedf -hdocker --version确认： 操作系统版本受支持； 内核版本满足当前 Docker 版本要求； 数据盘空间充足； 不与 Podman、containerd 旧配置冲突； 企业网络代理和证书策略明确。2.2 Linux 安装以 Ubuntu 官方仓库为例：sudo apt-get updatesudo apt-get install -y ca-certificates curlsudo install -m 0755 -d /etc/apt/keyringssudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \ -o /etc/apt/keyrings/docker.ascsudo apt-get updatesudo apt-get install -y docker-ce docker-ce-cli containerd.io \ docker-buildx-plugin docker-compose-plugin启动：sudo systemctl enable --now dockerdocker versiondocker compose version2.3 Windows 与 macOS安装 Docker Desktop 后检查：docker versiondocker infodocker run --rm hello-world桌面版适合学习开发，不建议作为生产服务端。Windows 还要确认 WSL2 或 Hyper-V 后端正常。2.4 权限配置把用户加入 docker 组：sudo usermod -aG docker $USER重新登录后生效。注意：能访问 /var/run/docker.sock 约等于拥有宿主机高权限。生产构建机不应随意授予普通用户 docker 组权限，可选 rootless Docker 或受控 CI。2.5 数据目录默认 Docker 数据目录常在 /var/lib/docker。生产建议独立数据盘：{ "data-root": "/data/docker"}配置文件：/etc/docker/daemon.json重启：sudo systemctl restart docker查看：docker info --format '{{.DockerRootDir}}'2.6 镜像加速与代理daemon.json 示例：{ "registry-mirrors": [ "https://mirror.example.com" ]}构建代理：sudo systemctl edit docker[Service]Environment="HTTP_PROXY=http://proxy.internal:7890"Environment="HTTPS_PROXY=http://proxy.internal:7890"Environment="NO_PROXY=localhost,127.0.0.1,.internal"2.7 日志限制避免容器日志无限增长：{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "5" }}已有容器需要重建后生效。2.8 验证安装docker infodocker run --rm hello-worlddocker run -d --name nginx-test -p 8080:80 nginx:1.27curl -I http://127.0.0.1:8080docker rm -f nginx-test常见问题： 问题 排查 permission denied docker 组或 sudo cannot connect to daemon 服务、socket、WSL pull timeout 网络、镜像源、代理 no space left data-root 磁盘 certificate error 企业 CA 配置 本章小结安装 Docker 的关键是规划数据目录、日志上限、网络代理和权限边界。开发环境追求方便，生产环境必须控制 Docker Socket 和镜像来源。思考题 为什么生产要独立规划 data-root？ docker 组权限有什么风险？ 如何限制容器日志增长？ 拉取镜像超时如何排查？ Rootless Docker 适合什么场景？
• 这是《Docker 与 Kubernetes 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。容器的本质是被隔离和受限制的进程。Docker 让镜像构建、分发和运行变得简单，Kubernetes 则让成千上万个容器可以被调度、扩缩容、发布和治理。本章建立容器技术全景：容器解决什么问题、和虚拟机的区别、核心依赖的内核能力、镜像与容器的生命周期、容器编排要解决什么问题。1.1 环境不一致问题传统部署：开发本机 -> 测试服务器 -> 生产服务器常见问题： 操作系统版本不同； Python / Java / Node 版本不同； 依赖库缺失； 配置文件差异； 端口占用冲突； 启动命令不同； 磁盘路径不同。于是出现经典对话： 在我机器上是好的。容器把应用运行所需的内容打包成镜像：Application CodeRuntimeDependenciesConfig TemplateEntrypoint镜像构建一次，可以在开发、测试、生产中运行同一个版本。1.2 容器不是虚拟机 维度 虚拟机 容器 隔离级别 硬件级虚拟化 进程级隔离 内核 每个 VM 独立内核 共享宿主机内核 启动速度 分钟级 秒级 镜像大小 GB 级 MB 到数百 MB 密度 较低 较高 安全边界 强 相对弱 典型软件 KVM、VMware Docker、containerd 虚拟机：Host OS -> Hypervisor -> Guest OS -> App容器：Host OS -> Container Runtime -> App Process容器共享内核，因此不能把容器视为绝对安全边界。强隔离需求应考虑虚拟机、Kata Containers、gVisor 等方案。1.3 容器核心依赖的内核能力NamespaceNamespace 让进程看不到全局系统资源，实现视图隔离。 Namespace 隔离内容 PID 进程编号 NET 网络栈、网卡、路由、端口 MNT 文件系统挂载点 UTS 主机名和域名 IPC 进程间通信 USER 用户和组映射 Cgroup Cgroup 视图 Time 系统时间视图 查看进程 namespace：ls -l /proc/$$/nsCgroupCgroup 限制和统计资源，例如： CPU； 内存； IO 带宽； PID 数量； 设备访问。示例限制：docker run --cpus=1 --memory=512m nginx内存限制不是“建议值”。超过限制的容器可能被 OOM Kill。UnionFS容器镜像采用分层文件系统。Image Layer 1: Base OSImage Layer 2: RuntimeImage Layer 3: DependenciesImage Layer 4: App CodeContainer Layer: Writable特点： 镜像层只读； 容器层可写； 层可以被复用； 构建缓存可以加速； 删除容器会丢失容器层。1.4 Docker 的核心对象 对象 说明 Image 只读分层模板 Container 镜像的运行实例 Dockerfile 镜像构建脚本 Registry 镜像仓库 Volume 持久化数据卷 Network 容器网络 Compose 多容器编排工具 基本命令：docker versiondocker infodocker imagesdocker psdocker pull nginx:1.27docker run -d --name web -p 8080:80 nginx:1.27docker logs -f webdocker exec -it web shdocker stop webdocker rm web1.5 镜像与容器生命周期Dockerfile -> docker build -> Image -> docker push -> Registry -> docker pull -> docker run -> Container -> start / stop / restart -> rm一个简单 Dockerfile：FROM eclipse-temurin:17-jreWORKDIR /appCOPY target/order-service.jar app.jarENV JAVA_OPTS="-XX:MaxRAMPercentage=70"EXPOSE 8080ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app/app.jar"]生产镜像要求： 使用固定基础镜像版本； 不把密码打进镜像； 使用非 root 用户运行； 镜像尽量小； 构建可复现； 按变更频率分层； 扫描漏洞； 有清晰健康检查。1.6 为什么需要 Kubernetes单机 Docker 可以运行几个容器，但生产系统需要： 问题 Kubernetes 能力 容器挂了怎么办 自愈、重启、重建 多机如何调度 Scheduler 流量如何接入 Service、Ingress 如何滚动发布 Deployment 如何扩缩容 HPA、VPA 配置如何管理 ConfigMap、Secret 存储如何挂载 PV、PVC 秘密如何保护 Secret、RBAC 多服务如何治理 网络策略、服务网格 Kubernetes 集群组成：Control Plane |-- API Server |-- etcd |-- Scheduler +-- Controller ManagerWorker Node |-- kubelet |-- kube-proxy +-- Container Runtime 组件 职责 API Server 集群入口和 REST API etcd 保存集群状态 Scheduler 选择 Pod 运行节点 Controller Manager 维护期望状态 kubelet 管理节点上的 Pod kube-proxy Service 流量转发 1.7 声明式模型传统运维是命令式：启动 3 个容器Kubernetes 是声明式：apiVersion: apps/v1kind: Deploymentmetadata: name: order-servicespec: replicas: 3 selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: containers: - name: order-service image: registry.example.com/order-service:1.0.0含义是：我希望始终有 3 个健康副本如果 Pod 异常，控制器会创建新 Pod；如果节点故障，Pod 会被重新调度。1.8 云原生部署观念云原生应用应尽量满足： 配置外置； 无状态优先； 健康检查完善； 优雅启动和退出； 日志输出标准流； 指标暴露； 水平扩展； 故障可自愈； 发布可回滚； 依赖下游可降级。容器只是起点。真正改变系统稳定性的是围绕容器的配置、观测、发布和治理体系。本章小结容器是依赖 Namespace、Cgroup 和分层文件系统运行的隔离进程，它解决了环境一致性和快速交付问题。Docker 负责单机镜像与容器，Kubernetes 负责多节点调度、自愈、流量、配置、存储和发布。理解容器的隔离边界和声明式模型，是学习云原生的基础。思考题 容器和虚拟机的隔离边界有什么区别？ Namespace 和 Cgroup 分别解决什么问题？ 镜像层和容器可写层有什么关系？ 为什么容器内数据需要 Volume？ Kubernetes 的声明式模型带来哪些运维方式变化？