Docker和Kubernetes（简称 K8s）
-
目录
要理解 Docker 和 Kubernetes（简称 K8s），首先需要明确它们的核心定位：Docker 解决了“应用如何打包运行”的问题，而 K8s 解决了“大量Docker容器如何高效管理”的问题——二者是“容器技术”与“容器编排平台”的互补关系，共同支撑现代云原生应用的开发与部署。
一、Docker：容器化技术的“基石”
Docker 是 2013 年诞生的开源项目，核心是 “将应用及其依赖打包成标准化容器，实现‘一次构建，到处运行’”，彻底解决了传统开发中“本地能跑、线上跑不通”的环境一致性问题。
1. Docker 解决的核心痛点
传统应用部署面临两大难题：
- 环境依赖冲突：开发环境用 Python 3.8，线上用 Python 3.6，导致代码报错；本地依赖的库版本与服务器不一致，引发功能异常。
- 资源浪费：传统虚拟机（如 VMware）需要模拟完整操作系统（包含内核、系统库），启动慢、占用资源多（一台服务器只能跑几个虚拟机）。
Docker 通过“容器化”解决了这些问题：容器共享宿主机的操作系统内核，仅打包应用本身和必需的依赖（如库、配置文件），启动快（秒级）、资源占用少（一台服务器可跑上百个容器）。
2. Docker 的核心概念
理解 Docker 需掌握 4 个核心组件，它们的关系类似“模板→实例→仓库→网络存储”：
概念 作用描述 类比举例 镜像（Image） 应用的“只读模板”，包含运行应用所需的代码、依赖、配置（如 Python 镜像、Nginx 镜像）。 操作系统安装光盘（只读） 容器（Container） 镜像的“运行实例”，是可读写的独立环境（一个镜像可创建多个容器，容器间相互隔离）。 安装好的操作系统（可操作） 仓库（Repository） 存储镜像的“仓库”，类似代码仓库（如 GitHub），分为公开仓库（Docker Hub）和私有仓库。 应用商店（如苹果 App Store） Dockerfile 构建镜像的“脚本文件”，通过编写指令（如 FROM指定基础镜像、COPY复制代码）定义镜像内容，确保构建过程可复现。菜谱（按步骤做出固定口味的菜） 3. Docker 的典型使用流程
以“部署一个 Python Web 应用”为例：
- 编写 Dockerfile：指定基础镜像为
python:3.9，复制应用代码到容器，安装依赖（pip install），定义启动命令（python app.py）。 - 构建镜像：执行
docker build -t my-python-app:v1 .，生成名为my-python-app、版本为v1的镜像。 - 运行容器：执行
docker run -p 8080:80 my-python-app:v1，将容器内的 80 端口映射到宿主机的 8080 端口，用户可通过http://宿主机IP:8080访问应用。 - 推送镜像：执行
docker push 仓库地址/my-python-app:v1，将镜像上传到私有仓库，供其他环境（如测试、生产）使用。
4. Docker 的局限性
Docker 仅能管理单台服务器上的容器，当应用需要扩展到多台服务器（如：用 10 台服务器跑 100 个容器）时，会面临以下难题：
- 如何自动在多台服务器间分配容器？
- 如何监控所有容器的运行状态（如 CPU、内存占用）？
- 如何实现容器故障时自动重启、新容器自动加入？
- 如何让多台服务器上的容器互联互通？
这些“大规模容器管理”的需求，正是 K8s 要解决的问题。
二、Kubernetes（K8s）：容器编排的“操作系统”
Kubernetes 是 Google 2014 年开源的容器编排平台，核心是“自动化管理多节点集群中的容器，实现容器的部署、扩展、运维全流程自动化”，相当于为容器集群提供了一套“操作系统级”的管理能力。
1. K8s 的核心定位：“集群管理大脑”
K8s 的本质是一个“集群管理系统”，它将多台服务器（物理机或虚拟机）组成一个**“集群（Cluster）”**，然后通过统一的控制平面（Control Plane）管理集群中所有的容器，实现：
- 自动化部署：按需求自动将容器分配到集群的节点上。
- 弹性伸缩：根据流量自动增加/减少容器数量（如：访问量翻倍时，自动把容器从 5 个扩到 10 个）。
- 自愈能力：容器崩溃时自动重启，节点故障时自动将容器迁移到其他健康节点。
- 服务发现与负载均衡：为容器分配统一的访问地址，自动将请求分发到多个容器，避免单点故障。
2. K8s 的核心架构
K8s 集群分为两大角色：控制平面（Control Plane） 和 节点（Node），二者通过网络通信协同工作。
（1）控制平面：集群的“大脑”
控制平面负责集群的决策（如：部署哪些容器、如何扩展），通常部署在单独的节点上（生产环境需高可用，一般部署 3 个副本），包含 4 个核心组件：
组件名称 核心作用 kube-apiserver 集群的“统一入口”，所有操作（如部署容器、查看状态）都通过 API 接口完成，是所有组件的通信中枢。 etcd 集群的“数据库”，存储集群的所有配置信息（如容器部署规则、节点信息），是 K8s 的“唯一事实来源”。 kube-scheduler 集群的“调度器”，负责将容器（Pod）分配到合适的 Node 上（如：根据 Node 的 CPU 剩余量、内存大小筛选节点）。 kube-controller-manager 集群的“控制器集合”，负责维护集群状态（如：容器故障重启、副本数量达标、节点故障迁移）。 （2）节点（Node）：集群的“工作节点”
Node 是实际运行容器的服务器（物理机或虚拟机），每个 Node 上都运行 3 个核心组件，负责执行控制平面的指令：
组件名称 核心作用 kubelet Node 的“管家”，监听 kube-apiserver 的指令，负责在 Node 上启动/停止容器，确保容器按规则运行。 kube-proxy Node 的“网络代理”，负责维护 Node 的网络规则（如：实现容器间的通信、外部请求的负载均衡）。 容器运行时（CRI） 负责实际运行容器的组件，Docker 是最常用的 CRI（此外还有 Containerd、CRI-O 等）。 3. K8s 的核心资源对象
K8s 不直接管理“容器”，而是通过更高层次的“资源对象”来定义容器的运行规则，最常用的有 4 个：
资源对象 作用描述 举例场景 Pod K8s 的“最小部署单元”，是一个或多个紧密关联的容器的集合（如：一个 Web 容器 + 一个日志收集容器），Pod 内的容器共享网络和存储。 部署一个“Web 应用 + 日志容器”的组合。 Deployment 管理 Pod 的“控制器”，负责定义 Pod 的副本数量、更新策略（如滚动更新），实现 Pod 的自愈和弹性伸缩。 定义“运行 5 个 Web 应用 Pod，支持滚动更新”。 Service 为 Pod 提供“固定访问地址”的资源，即使 Pod 重启或迁移（IP 变化），Service 地址不变，同时实现负载均衡（将请求分发到多个 Pod）。 为 5 个 Web Pod 分配一个固定地址 http://web-service:80，外部通过该地址访问。ConfigMap/Secret 存储应用配置的资源：ConfigMap 存明文配置（如数据库地址），Secret 存敏感信息（如数据库密码，会加密存储）。 将“数据库连接地址”存在 ConfigMap，“数据库密码”存在 Secret，Pod 从这两个资源中读取配置。 4. K8s 的典型使用流程
以“部署一个 Web 应用并实现弹性伸缩”为例：
- 编写 Deployment 配置文件（yaml 格式）：定义基础镜像（来自 Docker 仓库）、Pod 副本数（初始 3 个）、资源限制（如 CPU 0.5 核、内存 512MB）。
- 部署应用：执行
kubectl apply -f web-deployment.yaml，K8s 会通过调度器将 3 个 Pod 分配到集群的不同 Node 上。 - 创建 Service 配置文件：定义 Service 类型（如 NodePort，将 Service 端口映射到 Node 的物理端口），执行
kubectl apply -f web-service.yaml，生成固定访问地址。 - 弹性伸缩：执行
kubectl scale deployment web-deployment --replicas=5，K8s 会自动新增 2 个 Pod；或配置“Horizontal Pod Autoscaler（HPA）”，根据 CPU 使用率自动伸缩（如 CPU 超过 70% 时增加副本）。 - 查看状态：执行
kubectl get pods查看 Pod 运行状态，kubectl get services查看 Service 地址，kubectl logs <pod-name>查看 Pod 日志。
三、Docker 与 K8s 的关系：互补而非替代
很多人会误以为 Docker 和 K8s 是竞争关系，实际上二者分工明确、缺一不可：
维度 Docker Kubernetes（K8s） 核心定位 容器化技术（打包、运行单个容器） 容器编排平台（管理多节点的大量容器） 解决问题 环境一致性、轻量级运行 大规模容器的部署、伸缩、运维自动化 依赖关系 K8s 依赖 Docker 作为“容器运行时”（CRI） Docker 需 K8s 实现大规模管理 类比 类似“快递盒”（打包物品） 类似“快递分拣中心”（管理大量快递盒的运输、分发） 四、延伸：容器生态的其他工具
除了 Docker 和 K8s，云原生生态还有一些常用工具，可进一步完善容器化流程：
- Containerd：Docker 生态中的轻量级容器运行时，现在已成为 K8s 推荐的 CRI（比 Docker 更轻量，专注于容器运行）。
- Helm：K8s 的“包管理工具”，将多个 K8s 资源（Deployment、Service 等）打包成一个“Chart”，实现应用的一键部署（类似 Linux 的
apt或yum）。 - Prometheus + Grafana：K8s 监控组合，Prometheus 采集集群和容器的监控数据（CPU、内存、流量），Grafana 可视化展示监控面板。
- ELK Stack（Elasticsearch + Logstash + Kibana）：容器日志收集分析组合，Logstash 收集容器日志，Elasticsearch 存储，Kibana 可视化查询。
总结
- Docker 是“容器化的基石”，解决了应用“如何打包、如何在单节点运行”的问题，是 K8s 管理的“对象”。
- K8s 是“容器编排的大脑”，解决了“多节点、大规模容器如何高效管理”的问题，是 Docker 规模化的“工具”。
- 二者结合是现代云原生应用的标准技术栈，从“开发→打包→部署→运维”实现全流程自动化，也是企业实现“微服务架构”“DevOps”的核心支撑。
