云原生容器：Docker、Compose、K8s 基础学习

第一章 Docker 容器核心基础（生产完整版）

1.1 容器核心概念（零基础通俗讲解）

1.1.1 什么是 Docker？底层运行逻辑

Docker 是一款轻量化容器运行与打包工具，核心价值是实现项目环境标准化、一次打包随处运行，彻底解决传统部署中「本地能跑、服务器报错、环境依赖混乱」的核心痛点，是云原生技术体系的底层基石。

它依托 Linux 内核两个核心能力实现资源隔离与资源管控，是容器运行的底层核心：

• Namespace（命名空间）：资源隔离核心，为每个容器独立隔离进程、网络、文件系统、用户、主机名、IPC通信资源，容器之间相互无感、互不干扰。

• Cgroup（控制组）：资源限制核心，精准约束容器的 CPU、内存、磁盘IO、网络带宽，杜绝单容器占用整机资源，防止服务器雪崩。

重点补充：容器核心本质（新手必懂、面试必考）

容器不是虚拟机！容器本质就是一个被 Namespace 隔离、被 Cgroup 限制的普通 Linux 进程。

因此容器具备秒级启动、极低资源占用、轻量化销毁的特性，所有容器共用宿主机系统内核，这是容器与虚拟机最本质的区别，也是所有容器特性的根源。

容器 VS 虚拟机（本质区别、生产选型依据）

虚拟机：完整虚拟化操作系统，自带独立内核，硬件资源完全模拟，隔离性极强，启动分钟级，资源占用高，适合系统级隔离、异构环境部署。

容器：共享宿主机内核，仅打包应用与依赖，进程级隔离，启动秒级，资源占用极低，隔离性弱于虚拟机，专为应用部署、微服务架构设计。

1.1.2 Docker 三大核心组件

镜像、容器、仓库是 Docker 核心三要素，构成「镜像打包-容器运行-仓库分发」的标准化流程，所有 Docker 操作均围绕三者展开。

1. 镜像（Image）：容器静态只读模板，等同于应用安装包。采用**分层存储、写时复制（COW）**机制，底层为系统基础层，上层为依赖、代码、配置层，多镜像可复用底层公共层，大幅节省磁盘空间。镜像永久只读，无法修改，仅可用于创建容器。

2. 容器（Container）：镜像的动态运行实例，本质是宿主机独立进程。基于只读镜像，容器会生成一层可读写临时层，运行过程中产生的日志、文件修改、缓存均存储在该层级。默认删除容器后，临时层数据全部丢失，仅数据卷挂载数据可持久化保留。

3. 仓库（Registry）：镜像存储与分发平台。公共仓库（Docker Hub）提供开源官方镜像，适合测试、开源项目；私有仓库（Harbor）为企业自研搭建，支持镜像版本管理、安全扫描、权限管控、内网高速分发，是生产环境唯一选择。

1.1.3 新手必背：Docker 核心隐性规则（高频踩坑点）

• 容器默认前台进程托管机制：Docker 核心设计规则，容器前台运行进程退出，容器直接停止，这是容器启动秒退的根本原因，所有服务必须前台启动常驻。

• 镜像分层永久只读：任何运行修改仅作用于容器读写层，不会改动原镜像，镜像修改需重新构建。

• 端口独占机制：宿主机端口同一时间仅能被一个进程/容器占用，端口冲突直接导致容器启动失败。

• 默认网络隔离机制：不同自定义网桥、不同项目容器默认无法互通，同网络容器可内网互通。

1.1.4 Docker 四大网络模式（生产必备、面试高频）

Docker 内置四种网络模式，适配不同生产场景，核心解决容器通信、外网访问、网络隔离问题：

• bridge 桥接模式（默认）：Docker 默认网桥，同一网桥容器内网互通，自动分配内网IP，支持端口映射对外暴露服务，适配绝大多数单机部署场景。

• host 主机模式：容器直接复用宿主机网络、IP、端口、网卡，无端口映射，网络性能最强，端口与宿主机完全共享，适合高性能服务、监控采集、网关服务。缺点是端口易冲突，隔离性差。

• none 无网络模式：关闭容器所有网络功能，无IP、无通信权限，仅可本地运行，适合纯离线计算、安全隔离类服务。

• 自定义 bridge 网络：企业生产首选，支持自定义网段、网络隔离、服务名域名互通、独立网络策略，不同项目网络完全隔离，安全性、可控性远高于默认bridge。

1.1.5 分层存储与写时复制 COW 原理（进阶核心）

Docker 镜像采用分层构建、分层存储，每一条 Dockerfile 指令生成一个镜像层，层级可缓存、可复用。

写时复制（COW）核心规则：当容器需要修改镜像已有文件时，不会直接修改只读镜像层，而是自动将文件复制到容器可读写层再进行修改，既保证镜像全局复用，又满足容器个性化修改需求，是 Docker 高效存储的核心原理。

1.2 Docker 常用命令（带注释+避坑说明+生产运维命令）

使用前务必保证 Docker 正常运行： 开机自启：systemctl enable docker 启动服务：systemctl start docker 查看状态：systemctl status docker

1.2.1 镜像操作命令

# 拉取官方镜像（不写版本默认 latest 最新版，生产环境禁止使用，版本不稳定）
docker pull nginx:1.24

# 查看本地所有镜像（名称、版本、大小、创建时间）
docker images

# 删除本地镜像（被容器占用的镜像无法直接删除，需先删容器）
docker rmi 镜像ID/镜像名

# 搜索官方公共镜像（优先选 OFFICIAL 官方镜像，安全无后门）
docker search nginx

# 打包镜像为压缩文件（用于服务器迁移、离线部署）
docker save -o nginx.tar nginx:1.24

# 导入离线镜像包（新服务器快速恢复镜像）
docker load -i nginx.tar

新手避坑：镜像 ID 只需输入前3-4位即可识别；镜像迁移只能同步镜像，不会保留容器运行数据。

1.2.2 容器操作命令

# 启动容器核心命令
# -d 后台运行（退出终端不关闭容器，生产必备）
# -p 宿主机端口:容器端口 端口映射（外部通过服务器端口访问容器服务）
# --name 自定义容器名称，方便后续管理
docker run -d -p 80:80 --name nginx-demo nginx:1.24

# 查看正在运行的容器
docker ps

# 查看所有容器（包含已停止、异常退出的容器，排查问题常用）
docker ps -a

# 启动/停止/重启已有容器
docker start 容器ID/容器名
docker stop 容器ID/容器名
docker restart 容器ID/容器名

# 删除停止的容器；加 -f 强制删除正在运行的容器
docker rm 容器ID/容器名
docker rm -f 运行中容器名

# 实时查看容器日志（排查服务启动失败、接口报错核心命令）
docker logs -f 容器名

# 进入容器内部终端，手动操作文件、执行命令
docker exec -it 容器名 /bin/bash

重点区分：docker run 是新建并启动容器；docker start 是启动已经存在、处于停止状态的容器，二者不能混用。推荐用 exec 进入容器，安全不影响服务运行。

1.2.3 必补运维清理命令（工作刚需，解决磁盘爆满）

# 清理停止的容器、无用网络、悬空镜像、构建缓存
docker system prune

# 彻底清理所有未使用的资源（含未挂载数据卷，测试可用、生产慎用）
docker system prune -a

# 查看 Docker 整体磁盘占用详情（镜像、容器、数据卷、缓存）
docker system df

说明：长期运行 Docker 会堆积大量废弃镜像、停止容器、缓存文件，是服务器磁盘爆满的高频原因，需定期执行清理。

1.2.4 生产级容器管控命令（资源限制+安全运维）

# 启动容器限制最大内存512M、最大CPU0.5核（防止资源抢占）
docker run -d -p 80:80 --memory=512m --cpus=0.5 --name nginx-limit nginx:1.24

# 查看容器详细资源占用、运行状态
docker stats

# 查看容器详细配置、网络、挂载、环境变量
docker inspect 容器名/容器ID

1.3 Dockerfile 镜像打包脚本（企业生产级完整版）

Dockerfile 是自定义标准化镜像的唯一配置脚本，实现环境构建、代码部署、配置初始化全自动化，杜绝手动构建环境的差异化问题，是生产镜像标准化的核心依托。文件名称必须为Dockerfile，无后缀。

1.3.1 常用指令详解（全覆盖）

• FROM：首行必写，指定基础镜像，生产优先选用 alpine 精简镜像，体积小、漏洞少。

• WORKDIR：设定容器默认工作目录，自动创建，替代手动 cd 切换目录。

• COPY：本地文件/目录复制到容器内部，支持批量复制。

• RUN：构建阶段执行命令，用于安装依赖、配置环境，每执行一次生成一个镜像层。

• EXPOSE：声明服务端口，仅用于备注说明，不生效端口映射。

• CMD：容器启动默认执行命令，仅最后一条生效，支持被 run 命令覆盖。

• ENTRYPOINT：容器固定启动入口，优先级高于 CMD，无法被 run 覆盖，生产启动服务专用。

• ENV：设置容器环境变量，构建、运行阶段均可生效。

• USER：指定容器运行用户，禁止 root 运行，提升容器安全性。

• VOLUME：声明容器匿名数据卷，用于持久化存储兜底。

1.3.2 生产级编写规范（企业强制标准）

1. 优先使用 alpine 精简镜像，相比完整版镜像体积缩小80%，传输快、漏洞少、启动更快。

2. 合并多个 RUN 命令，用 && 拼接、换行统一格式化，减少镜像分层，压缩镜像体积。

3. 禁止在 Dockerfile、镜像、配置中写入密码、密钥、Token 等敏感信息，防止镜像泄露引发安全事故。

4. 必须固定镜像具体版本，绝不使用 latest 最新版，避免版本迭代导致环境不一致、部署异常。

5. 新建 .dockerignore 文件，排除日志、缓存、node_modules、git 文件、本地配置等无用文件，避免镜像臃肿、携带冗余数据。

6. 遵循多阶段构建原则，分离构建环境与运行环境，彻底剥离编译依赖，产出极简生产镜像。

7. 禁止容器以 root 超级用户运行，通过 USER 指定普通用户，降低容器逃逸风险。

1.3.3 重点补充：CMD 与 RUN、ENTRYPOINT 核心区别（面试高频）

• RUN：镜像构建阶段执行，仅执行一次，用于安装软件、配置环境、编译代码，生成新镜像层。

• CMD：容器启动阶段执行，可被 docker run 命令参数覆盖，适合默认启动配置。

• ENTRYPOINT：容器固定启动入口，优先级最高，无法被启动命令覆盖，生产环境固定服务启动脚本、保证服务常驻必备。

1.3.4 镜像多阶段构建（生产核心瘦身方案）

多阶段构建是企业生产镜像优化的核心手段，核心逻辑：**第一阶段用完整镜像完成代码编译、依赖安装，第二阶段仅拷贝编译后的可执行文件，舍弃所有编译工具与冗余依赖**，最终产出极小、无漏洞、高性能的生产镜像。彻底解决传统单阶段镜像体积庞大、漏洞多的问题。

1.4 实战：自定义 Nginx 镜像完整部署流程

本案例从零完成「写页面→写打包脚本→构建镜像→启动容器→访问服务→排错优化」全流程，适配所有自定义 Web 项目打包逻辑，贴合生产规范。

步骤1：创建独立工作目录

单独建文件夹隔离项目文件，避免缓存冲突、文件混乱。

mkdir -p /docker/nginx-demo && cd /docker/nginx-demo

步骤2：编写自定义网页

echo "<h1>Hello Docker 零基础入门！自定义 Nginx 镜像部署成功</h1>" > index.html

步骤3：编写 Dockerfile 打包脚本

# 基于官方稳定版 Nginx 镜像
FROM nginx:1.24
# 用本地自定义页面覆盖容器默认首页
COPY index.html /usr/share/nginx/html/index.html
# 声明服务端口
EXPOSE 80
# 前台启动 Nginx，保证容器持续运行（后台启动会导致容器直接退出）
CMD ["nginx", "-g", "daemon off;"]

步骤4：构建自定义镜像

# -t 自定义镜像名和版本  . 代表以当前目录为构建上下文
docker build -t my-nginx:v1.0 .

构建原理：Docker 会逐层执行脚本指令，成功的层级会缓存，重复构建速度更快；修改对应文件后，对应层级缓存失效，自动重新构建。

步骤5：启动自定义镜像容器（带资源限制生产规范）

docker run -d -p 8080:80 --memory=256m --cpus=0.2 --name my-nginx-container my-nginx:v1.0

步骤6：验证与排错

浏览器访问 服务器IP:8080 即可看到自定义页面。 访问失败标准排查顺序：查看容器运行状态 → 查看容器日志报错 → 检查防火墙/安全组端口 → 核对宿主机端口占用 → 检查容器网络与挂载配置。

1.5 Docker 生产运维核心规范与故障处理

1.5.1 容器日志规范

Docker 容器默认日志为 stdout/stderr 标准输出，无日志轮转会导致日志无限膨胀、占满磁盘。生产必须配置日志轮转策略，限制单容器日志大小、日志保留份数，避免磁盘爆满。

1.5.2 容器环境统一规范

线上所有容器必须统一时区、编码，默认容器时区为UTC，与国内时区不符，会导致日志时间错乱、业务时间异常，生产启动容器需强制挂载时区文件或配置环境变量统一时区。

1.5.3 容器安全规范

禁止 root 运行容器、禁止特权容器、限制容器资源、敏感配置脱离镜像存储、镜像定期安全扫描，杜绝容器逃逸、权限泄露、资源雪崩风险。

第二章 Docker Compose 单机多服务编排（生产完整版）

2.1 Compose 核心作用与适用场景

单纯使用原生 Docker 命令部署多服务项目，存在部署繁琐、启动顺序混乱、服务无法联动、配置不可复用、运维成本极高的问题。Docker Compose 专为单机多服务编排设计，通过 YAML 配置文件统一管理所有服务的镜像、端口、网络、存储、启动策略、依赖关系，实现「一份配置、一键启停、环境统一」。

Docker Compose 是单机多服务批量管理工具，核心解决开发、测试、小型生产环境的微服务部署与运维难题。

核心优势

• 配置文件化：所有部署规则固化，可复用、可版本控制、可团队共享

• 自动协同：自动创建专属网络、实现服务内网互通，简化多服务联动配置

• 环境隔离：不同项目 Compose 环境独立隔离，配置、网络、资源互不干扰

• 极简运维：单命令完成整套服务启动、停止、重建、更新，大幅提升运维效率

适用场景：本地开发、项目测试、小型单机生产环境；绝对不适用：多服务器集群、高可用扩容、大规模微服务生产场景（必须使用 K8s）。

2.2 Compose 配置文件核心参数详解（生产全参数）

配置文件名为 docker-compose.yml，采用 YAML 语法，必须用2个空格缩进，禁止 Tab 制表符，大小写敏感，语法错误会直接导致部署失败。

2.2.1 全局核心配置

• version：配置文件版本，3.8 为通用稳定版，兼容所有主流 Docker 版本，生产统一固定使用。

• services：核心模块，所有业务服务均定义于此，单个子配置对应一个独立容器服务。

• networks：自定义专属网络，实现项目内服务内网互通、外网隔离，提升安全性。

• volumes：全局数据卷定义，用于数据库、持久化业务数据存储，保障数据不随容器删除丢失。

2.2.2 服务常用配置参数（生产全覆盖）

• image：指定服务镜像名称与版本，优先使用官方稳定镜像，部署高效稳定。

• build：指定 Dockerfile 路径与构建参数，支持本地自动构建自定义镜像。

• ports：端口映射，格式宿主机端口:容器端口，宿主机端口全局唯一不可重复。

• environment：环境变量配置，用于注入账号密码、接口地址、业务参数，实现配置与镜像分离。

• depends_on：服务依赖，控制服务启动顺序，仅保证启动先后，不等待服务就绪。

• restart: always：永久重启策略，容器崩溃、服务器重启自动恢复，生产必备。

• volumes：文件/数据挂载，实现代码热更新、业务数据持久化。

• healthcheck：服务健康检查，探测服务是否真正就绪，解决 depends_on 启动短板。

• deploy.resources：容器资源限制，约束 CPU、内存占用，生产资源管控必备。

• env_file：加载外部环境变量文件，实现多环境配置隔离，避免配置写入YAML。

2.2.3 三种挂载方式核心区别（生产选型必懂）

• 绑定挂载（Bind Mount）：宿主机指定目录与容器目录双向绑定，文件实时同步，适合开发环境代码热更新，缺点是依赖宿主机目录，可移植性差。

• 命名数据卷（Named Volume）：Docker 统一管理的持久化卷，不依赖宿主机固定目录，稳定性极强、权限可控，生产数据库、核心数据持久化唯一选型。

• 匿名卷（Anonymous Volume）：自动随机生成数据卷，无固定名称、不易管理、易堆积垃圾数据，生产环境禁止使用。

2.3 Compose 常用命令与生产避坑指南

所有命令必须在 docker-compose.yml 所在目录执行，否则无法识别配置文件。

# 后台启动整套服务（创建网络、容器、数据卷，生产默认）
docker-compose up -d

# 查看当前项目所有服务运行状态、端口、重启次数
docker-compose ps

# 实时查看所有服务聚合日志，排查多服务联动报错
docker-compose logs -f

# 停止服务，保留容器、网络、数据卷，可快速重启
docker-compose stop

# 销毁服务，删除容器、网络，保留数据卷（防止数据误删，生产首选）
docker-compose down

# 修改 Dockerfile/配置后，重新构建镜像并重启服务
docker-compose up -d --build

# 查看所有服务配置详情、运行参数
docker-compose config

核心避坑：docker-compose down 不会删除数据卷；测试环境如需清空所有资源，可执行 docker-compose down -v，生产环境绝对禁止，会清空持久化数据。

2.4 Compose 生产短板解决方案（面试+工作核心）

短板1：depends_on 仅控制启动顺序，不等待服务就绪

解决方案：配置 healthcheck 健康检查，通过心跳探测判断数据库、缓存等依赖服务是否完全启动，再启动业务服务，彻底解决服务启动报错、连接失败问题。

短板2：无原生多环境支持

解决方案：通过 .env 环境文件 + 多配置文件拆分，区分 dev/test/prod 环境，实现不同环境端口、配置、资源隔离。

短板3：单机无扩容、无高可用

最终解决方案：开发测试沿用 Compose，线上生产统一迁移 K8s，这是企业标准化技术选型规范。

2.5 实战：Nginx+MySQL 多服务项目生产级部署

搭建经典「静态页面+数据库」多服务架构，融入健康检查、数据持久化、自动重启、专属网络等生产配置，复刻企业单机部署规范。

步骤1：创建项目目录

mkdir -p /docker/compose-demo && cd /docker/compose-demo

步骤2：编写生产级 docker-compose.yml 配置文件

version: '3.8'

services:
  # 前端静态服务
  nginx-web:
    image: nginx:1.24
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/share/nginx/html
    networks:
      - web-net
    restart: always
    # 资源限制
    deploy:
      resources:
        limits:
          cpus: '0.2'
          memory: 256M

  # MySQL 数据库服务（带健康检查、数据持久化）
  mysql-db:
    image: mysql:8.0
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: 123456
      MYSQL_DATABASE: test_db
    volumes:
      - mysql-data:/var/lib/mysql
    networks:
      - web-net
    restart: always
    # 数据库健康检查，确保服务就绪
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 3

# 自定义内网网络
networks:
  web-net:
    driver: bridge

# 全局持久化数据卷
volumes:
  mysql-data:

步骤3：初始化前端页面

mkdir html && echo "<h1>Compose 生产级多服务部署成功！Nginx+MySQL 运行正常</h1>" > html/index.html

步骤4：一键部署整套服务

docker-compose up -d

步骤5：验证与原理复盘

1. 执行 docker-compose ps，所有服务状态为 Up 且健康检查通过即为正常；

2. 浏览器访问服务器 IP，正常展示自定义页面，本地代码修改实时热更新；

3. 数据库工具可正常连接 3306 端口，test_db 数据库创建成功，删除容器数据不丢失。

核心原理：同网络服务可通过服务名作为内网域名互通，无需固定IP；命名数据卷保障数据库数据持久化；健康检查规避服务启动时序问题；资源限制杜绝资源抢占，完全贴合小型生产规范。

2.6 Compose 核心短板总结（面试必考、技术选型核心）

Docker Compose 仅支持单机部署，无跨机器调度、无故障自愈、无自动扩缩容、无零停机发布、无集群负载均衡，仅适用于开发测试与小型单机生产，企业核心生产集群必须使用 K8s。

第三章 Kubernetes（K8s）集群运维入门（生产完整版）

3.1 K8s 定位与集群架构（企业生产标准）

Docker、Docker Compose 仅能实现单服务器容器管理，完全无法满足企业生产高可用、高并发、容灾自愈、弹性扩容、滚动更新的核心需求。Kubernetes（简称 K8s）是开源的生产级容器集群编排平台，可将多台服务器整合为统一资源池，全自动管控集群内所有容器服务，是目前云原生生产环境的唯一工业标准。

K8s 核心价值：屏蔽底层服务器差异，实现服务自动化运维，彻底解放人工运维，保障业务7*24小时高可用。

K8s 五大核心生产能力

• 故障自愈：容器、节点故障自动重建、迁移服务，业务零中断

• 弹性扩缩容：根据 CPU、内存、流量指标自动增减服务实例

• 零停机滚动更新：分批更新服务，发布、回滚用户无感知

• 智能调度：合理分配集群资源，提升服务器整体利用率

• 自动负载均衡：集群内流量自动分发，规避单实例压力过载

3.1.1 集群架构：控制节点 + 工作节点（组件全解析）

标准 K8s 集群分为控制节点（Master）和工作节点（Node），分工明确、各司其职，生产环境采用多Master高可用架构，避免单点故障。

• 控制节点（Master）：集群管理大脑，仅负责调度管控，不运行业务容器。核心组件：

1. apiserver：集群统一入口，所有增删改查操作、资源请求必经入口，支持鉴权、限流；

2. etcd：集群分布式数据库，加密存储所有集群配置、资源状态、密钥数据，集群唯一数据源；

3. 控制器管理器：维持资源期望状态与实际状态一致，实现自愈、扩容逻辑；

4. 调度器：根据资源负载、调度策略，自动将Pod分配到最优工作节点。

• 工作节点（Node）：业务运行载体，真正运行业务容器。核心组件：

1. kubelet：节点代理，接收Master指令，管理本机Pod生命周期、状态上报；

2. kube-proxy：集群网络核心，实现Service负载均衡、流量转发、网络规则；

3. 容器运行时：默认Docker，负责容器启停、运行、资源管控。

3.2 K8s 四大核心资源（通俗生产级解读）

K8s 采用声明式资源管理：用户定义资源期望状态，K8s 控制器持续巡检、自动调谐，始终保证实际状态匹配期望状态，新手掌握四大核心资源即可完成90%生产部署场景。

3.2.1 Pod（最小运行单元）

Pod 是 K8s 最小调度、最小运行单元，K8s 不直接管理容器，所有业务容器必须运行在Pod内部。一个Pod支持单主容器、多辅助容器架构。

核心生产特性：同一Pod内所有容器共享网络栈、端口、存储卷、进程空间，互通零成本；Pod为临时弹性资源，重建、迁移后IP会动态变化，绝对不能作为固定访问入口。

生产铁律：生产环境禁止直接手动创建、管理Pod，必须通过控制器（Deployment/StatefulSet）托管，否则无自愈、无扩容、无生命周期管理。

3.2.2 Deployment（无状态应用控制器）

企业生产最常用、最核心的工作负载，专门管控所有无状态应用。无状态应用：实例完全一致、无本地固定数据、可任意扩容删除、无实例依赖。

核心生产能力：自定义副本数量、实时监控Pod状态、故障自动重建、支持滚动更新/版本回滚、支持弹性扩缩容、资源版本管理。

3.2.3 Service（稳定服务入口）

解决Pod动态IP不稳定的核心组件，为一组同源Pod提供永久固定的集群访问域名与IP，内置负载均衡能力，自动分发流量至正常Pod。

三大生产类型：

1. ClusterIP（默认）：仅集群内部访问，用于服务之间内网调用，安全隔离；

2. NodePort：节点端口暴露，外网可通过节点IP+端口访问，适用于测试环境；

3. LoadBalancer：云厂商负载均衡，生产外网访问标准方案，支持高可用流量分发。

3.2.4 Namespace（命名空间）

集群资源隔离单元，相当于集群内的「独立文件夹」，用于隔离不同环境、不同业务的所有资源（Pod/Deployment/Service/配置等）。

生产规范：严格划分 dev/test/prod 命名空间，实现环境完全隔离，避免配置冲突、资源误删、环境混淆；集群默认default、kube-system命名空间，禁止随意修改、删除。

3.3 三大工作负载生产场景精准区分

• Deployment：无状态应用专属，实例无差异、无固定数据、可随意扩缩容。适用：前端页面、后端接口、网关、微服务业务。

• StatefulSet：有状态应用专属，保证实例唯一性、稳定网络域名、有序部署/删除、持久化数据绑定。适用：MySQL、Redis、MQ、ES 等中间件、数据库。

• DaemonSet：节点守护进程，集群每个工作节点仅运行一个Pod，跟随节点启停。适用：日志收集、监控采集、节点代理、安全审计工具。

3.4 配置管理：ConfigMap 与 Secret（生产配置分离核心）

K8s 核心设计理念：镜像固化代码、配置动态分离。业务代码、依赖打包进镜像固定不变，所有可变配置、敏感数据通过独立组件挂载，改配置无需重新构建镜像、无需重新部署服务，实现配置动态更新。

3.4.1 ConfigMap（普通明文配置）

存储非敏感、可公开的明文配置数据，支持键值对、完整配置文件两种格式。适用：接口地址、超时时间、日志级别、业务参数、公共配置，支持多Pod、多服务共享。

3.4.2 Secret（敏感加密配置）

专门存储隐私核心数据，数据自动加密存储，权限严格管控。适用：数据库账号密码、接口密钥、Token、SSL证书、鉴权凭证。生产所有敏感配置必须使用Secret，禁止明文写入YAML或镜像。

3.5 Pod 生命周期与健康探针（生产排错核心）

Pod 拥有完整生命周期：创建→初始化→容器启动→就绪运行→终止退出，新手80%的线上报错均与生命周期、健康探针配置异常相关。

3.5.1 三大健康探针（生产必备）

• 存活探针 livenessProbe：探测容器是否正常运行，探测失败直接重启容器，解决服务卡死、假死问题。

• 就绪探针 readinessProbe：探测服务是否完成初始化、可正常接收流量，探测失败停止流量分发，不重启容器，解决启动加载阶段流量报错问题。

• 启动探针 startupProbe：适配启动缓慢的服务，延长初始化探测时间，避免服务未启动完成被误杀重启。

3.5.2 常见Pod异常状态与排错方案（线上高频）

• CrashLoopBackOff：容器反复启动崩溃，常见原因：启动命令错误、配置缺失、端口冲突、权限不足、资源不足、依赖未就绪。

• ImagePullBackOff：镜像拉取失败，常见原因：镜像版本错误、镜像仓库无法访问、私有镜像无密钥、网络不通。

• Pending：Pod调度失败，常见原因：节点资源不足、节点污点不匹配、调度策略限制、端口占用。

• NotReady：节点未就绪、网络组件异常、探针探测失败。

3.6 K8s 生产核心进阶组件

3.6.1 Ingress 网关（生产唯一外网入口）

NodePort仅适用于测试环境，生产绝对不用。Ingress 是 K8s 生产级流量网关，统一承接所有外网流量，支持域名路由、反向代理、SSL证书加密、限流、黑白名单、权重分发，是生产服务对外暴露的标准方案。

3.6.2 PV/PVC 持久化存储（生产数据核心）

普通挂载仅适用于测试，生产有状态服务必须使用 PV（持久化存储卷）、PVC（存储声明），实现存储与Pod解耦，Pod重建、迁移、删除数据不丢失，支持存储配额、权限管控、多存储类型适配。

3.6.3 HPA 自动扩缩容

生产核心自动化能力，可根据 CPU 使用率、内存占用、自定义流量指标，自动增减 Deployment 副本数量，业务高峰自动扩容、低谷自动缩容，节省资源、保障高可用。

3.6.4 节点调度与亲和性、污点容忍

企业生产精细化调度核心，通过节点亲和性、Pod亲和性实现服务聚合部署；通过节点污点与容忍实现核心节点隔离、专属服务节点，避免业务抢占核心资源。

3.6.5 RBAC 权限管控

K8s 权限安全核心，基于角色分配集群操作权限，区分管理员、运维、开发权限，杜绝越权操作、资源误删，保障集群安全。

3.7 实战：K8s 完整生产级应用部署流程

标准生产上线流程：环境隔离→资源部署→健康探测→流量暴露→容错测试→状态巡检。

步骤1：创建独立开发命名空间（环境隔离）

# 创建 dev 开发环境命名空间
kubectl create namespace dev

# 查看所有命名空间
kubectl get ns

步骤2：部署多副本高可用 Nginx 应用

# 部署3副本高可用服务，保障单Pod故障不影响业务
kubectl create deployment nginx-demo --image=nginx:1.24 --replicas=3 -n dev

# 查看部署就绪状态
kubectl get deploy -n dev

# 查看运行Pod实例与状态
kubectl get pods -n dev

生产原理：3副本Pod分散调度至集群不同节点，实现节点级容灾，单Pod、单节点故障不影响整体服务。

步骤3：暴露服务（测试环境NodePort）

# 对外暴露服务，生成固定访问端口
kubectl expose deployment nginx-demo --port=80 --type=NodePort -n dev

# 查看服务详情，获取外网访问端口
kubectl get svc -n dev

步骤4：故障自愈容错测试

手动删除任意运行Pod，即刻执行 kubectl get pods -n dev 查看状态，K8s 会瞬间新建Pod，始终维持3个副本数量，实现全自动故障自愈，保障业务不间断。

3.8 新手常用 K8s 运维命令（生产排错全覆盖）

# 查看集群所有节点运行状态，判断集群整体健康度
kubectl get nodes

# 查看指定命名空间下所有Pod资源
kubectl get pods -n 命名空间

# 查看资源详细配置、事件、报错信息（核心排错命令）
kubectl describe deploy 部署名 -n 命名空间
kubectl describe pod pod名 -n 命名空间

# 实时查看Pod日志，排查业务报错
kubectl logs -f pod名 -n 命名空间

# 手动扩缩容Pod副本数量
kubectl scale deploy 部署名 --replicas=5 -n 命名空间

# 滚动重启服务（零停机重启，生产必备）
kubectl rollout restart deploy 部署名 -n 命名空间

# 查看服务发布历史、执行版本回滚
kubectl rollout history deploy 部署名 -n 命名空间
kubectl rollout undo deploy 部署名 -n 命名空间

# 删除业务资源
kubectl delete deploy 部署名 -n 命名空间

3.9 K8s 生产核心思想与新手误区纠正

• 禁止手动操作容器/Pod：所有资源变更、配置修改通过YAML声明式配置完成，保证环境可追溯、可复用、可版本管控。

• 禁止固定PodIP访问服务：Pod动态变化，必须通过Service固定域名/IP内网访问。

• 生产禁止单副本部署：单副本无容灾、无高可用，实例故障直接导致业务中断，核心业务必须3副本及以上。

• 优先使用YAML部署：命令行仅用于临时测试、排错，生产全部使用YAML文件管理资源。

• 资源必须配置限制：所有业务容器配置CPU、内存资源限额，防止资源抢占导致集群雪崩。

第四章 生产规范、故障排错与进阶学习体系

4.1 通用生产部署规范（Docker/Compose/K8s）

本章整理企业落地级运维标准，统一线上操作规范，规避绝大多数常规线上故障，可直接落地执行。

4.1.1 镜像管理规范

• 生产镜像必须指定具体版本，禁止使用 latest、stable 等动态标签，杜绝环境版本不一致问题。

• 优先选用官方稳定镜像、alpine 精简镜像，缩减体积、减少系统漏洞。

• 自定义镜像采用多阶段构建，剥离编译工具、冗余依赖与缓存文件，实现镜像轻量化。

• 禁止在镜像内写入账号、密钥、证书等敏感数据，统一通过环境变量、Secret、外部配置挂载注入。

• 生产镜像统一存入私有Harbor仓库，关闭公网直接拉取，开启版本权限管控与漏洞扫描。

• 定期清理废弃镜像、历史版本镜像，避免仓库磁盘堆积与版本混乱。

4.1.2 容器运行规范

• 所有线上容器配置CPU、内存资源限制，防止单容器抢占整机资源，引发集群雪崩。

• 禁止容器以root特权模式运行，通过普通用户权限启动，降低容器逃逸风险。

• 统一挂载宿主机时区与编码配置，解决日志时间错乱、中文乱码问题。

• 生产容器开启自动重启策略，保障宕机、崩溃后自动恢复服务。

• 禁止进入容器手动修改配置与代码，所有变更通过镜像重建、配置挂载实现，保证可追溯、可复用。

4.1.3 环境隔离规范

• 严格隔离开发、测试、生产环境，Compose 通过.env文件区分配置，K8s 通过Namespace实现环境隔离。

• 各环境端口、存储、网络、密钥完全独立，禁止跨环境资源混用。

• 生产配置独立管理，不直接复用测试、开发环境配置。

4.2 标准化日志运维规范

容器默认标准输出日志无轮转、无清理机制，长期运行易造成磁盘爆满、日志丢失，线上环境必须标准化管控。

4.2.1 Docker 日志规范

• 全局配置日志轮转规则，限制单日志文件大小与保留份数，自动清理过期日志。

• 业务日志统一挂载至宿主机固定目录，集中归档清理，不依赖容器内部日志。

• 剔除镜像与容器内冗余调试日志，减少资源占用。

4.2.2 K8s 日志规范

• 采用「标准输出+持久化日志卷」双模式记录日志。

• 通过DaemonSet部署节点日志采集组件，统一收集全集群Pod日志。

• 日志按命名空间、服务、时间分类存储，支持故障检索与链路追踪。

4.3 线上故障标准化排查流程

线上服务异常时，遵循固定排查流程，避免盲目操作、扩大故障范围。

4.3.1 通用排查步骤

1. 核查容器、Pod运行状态，确认是否存在重启、崩溃、异常退出。

2. 查看实时报错日志，定位业务层核心异常。

3. 校验端口占用、网络互通、防火墙、域名解析等网络配置。

4. 检查服务器CPU、内存、磁盘、inode资源占用，排查资源耗尽问题。

5. 核对挂载配置、环境变量及数据库、缓存等依赖服务状态。

6. 通过describe查看集群事件，定位调度、镜像、探针异常问题。

4.3.2 高频故障解决方案

• 容器秒退：前台常驻进程缺失、启动命令错误、端口或配置异常，优先核查启动脚本。

• 镜像拉取失败：镜像版本错误、仓库网络不通、私有镜像密钥缺失。

• 服务访问超时：端口未放行、网络隔离、服务未就绪、探针探测失败。

• 磁盘爆满：日志未轮转、废弃容器镜像、缓存与数据文件堆积。

• K8s Pod Pending：节点资源不足、污点不匹配、端口占用、调度策略限制。

• K8s CrashLoopBackOff：配置错误、权限不足、依赖未就绪、内存溢出。

4.4 高可用落地核心准则

• 核心业务采用多副本部署，分散至不同节点，规避单点故障。

• 有状态服务使用专属持久化存储，禁止临时本地挂载，保障数据不丢失。

• 线上更新统一使用滚动更新，实现零停机发布与回滚。

• 所有服务配置健康探针，自动剔除异常实例，实现业务自愈。

• 核心服务开启HPA自动扩缩容，适配流量波动，避免服务瘫痪。

4.5 技术选型落地标准

• 开发、测试单机环境：Docker + Docker Compose，轻量化、部署高效。

• 单机小型生产服务：Compose + 日志轮转 + 资源限制 + 自动重启。

• 集群高可用生产环境：全线使用K8s，启用Ingress、PV/PVC、HPA、RBAC等核心能力。

• 无状态微服务：采用Deployment管控。

• 数据库、中间件等有状态服务：采用StatefulSet管控。

• 日志、监控等节点级组件：采用DaemonSet管控。

4.6 运维进阶学习路线

4.6.1 基础夯实阶段

掌握Linux常用运维、排错命令，吃透Docker底层原理、镜像构建、网络与存储机制，可独立完成镜像打包、容器运维与基础故障排查。

4.6.2 单机编排阶段

精通Compose多环境配置、健康检查、资源管控与多服务联动，解决单机部署冲突、启动异常、数据持久化问题。

4.6.3 K8s实操阶段

熟练编写各类资源YAML，掌握集群调度、污点亲和、存储网络、权限体系，精通滚动更新、版本回滚、自动扩缩容与各类Pod、节点故障排查。

4.6.4 云原生进阶阶段

掌握Harbor私有仓库、CI/CD流水线、监控告警、日志收集、服务网格与容器安全加固，具备企业集群搭建、运维、优化与容灾能力。

4.7 新手常见认知误区

• 误区：容器是小型虚拟机｜纠正：容器是宿主机独立Linux进程，共享系统内核，无独立操作系统。

• 误区：latest镜像可用于生产｜纠正：版本不固定、不可追溯，易引发环境不一致故障。

• 误区：可手动修改容器配置｜纠正：容器重建后配置失效，生产必须挂载固化配置。

• 误区：Compose可用于集群生产｜纠正：无调度、自愈、扩容能力，仅适配单机场景。

• 误区：K8s单副本可跑生产｜纠正：无容灾能力，节点或实例故障会直接中断业务。

第五章 面试高频核心考点

5.1 Docker 核心考点

• 容器与虚拟机的本质区别、优缺点及适用场景

• Namespace、Cgroup的核心作用与底层隔离、限流原理

• 镜像分层存储、写时复制机制的原理与优势

• CMD与ENTRYPOINT的区别及生产选型场景

• 多阶段构建的价值与镜像瘦身、漏洞优化方案

• Docker四大网络模式差异与生产选型标准

• 三类数据挂载方式的优劣与生产适用场景

• 容器启动秒退的核心原因与完整排查思路

• Docker生产安全规范与权限加固方案

5.2 Docker Compose 核心考点

• depends_on的局限性及健康检查解决方案

• Compose多环境隔离配置方案

• Compose生产短板及无法适配集群场景的原因

• 数据卷与绑定挂载的生产选型依据

• Compose服务故障自愈与开机自启实现方式

5.3 K8s 核心考点

• K8s Master、Node节点各组件功能与集群运行原理

• Pod不可直接用于生产、必须控制器托管的原因

• Deployment、StatefulSet、DaemonSet的场景差异

• 三大探针的功能、适用场景与配置要点

• CrashLoopBackOff、ImagePullBackOff、Pending等Pod异常排查方案

• Service三类模式差异、生产弃用NodePort的原因

• PV、PVC的核心作用与持久化存储实现原理

• 滚动更新流程、零停机发布与版本回滚机制

• HPA自动扩缩容原理与适用业务场景

• 节点污点、Pod容忍度与亲和性调度应用场景

• ConfigMap与Secret的区别及敏感配置规范

• K8s集群高可用生产落地核心方案

结语

本文完整覆盖Docker、Docker Compose、K8s零基础入门、实操部署、生产规范、故障排查与面试核心内容，全程贴合企业生产标准，聚焦实操落地与问题解决。熟练掌握后，可独立完成容器环境搭建、服务部署、日常运维、故障排错，满足初中级云原生运维岗位工作及面试需求。