背景

入职公司将近一个月，逐渐熟悉开发流程基本是：先在本地完成代码开发并 push 到代码仓库，然后再将代码部署到容器中进行测试。由于对后续的一些流程还不够熟悉，常常有些云里雾里的感觉，因此下定决心系统学习一下 Docker 和 Kubernetes，并在这里整理一些学习笔记 (gpt润色过一遍，所以ai味可能有点浓，但也更好理解) ，欢迎各位大佬批评指正～

1. Docker

Docker 镜像

• 是什么：一个只读模板，包含：
  • 应用代码
  • 依赖库
  • 运行环境和配置
• 特点：
  • 不可变性：镜像一旦构建，版本固定不变。
  • 可移植性：同一个镜像可以在任何安装了 Docker 的地方运行。
• 关系：
  • 镜像 → 运行后 → 容器
  • 一个镜像可以启动多个容器，容器之间相互独立。

---

2. Kubernetes (K8s)

核心关系：微服务 → Deployment → Pod → 容器 → 提供指定服务

---

2.1 Pod 与容器

• Pod 是 Kubernetes 的最小调度单元。
• 一个 Pod 内可以包含一个或多个容器：
  • 主容器：运行业务逻辑（核心服务）。
  • Sidecar 容器：负责日志收集、代理、监控等。
• 特点：
  • Pod 内部容器共享网络和存储。
  • Pod 内容器是协作关系，不做负载均衡。

类比：Pod 就像“负责指定服务的一名员工”，Pod 内的容器就是“这名员工的随身工具（电脑、手机）”，帮助员工完成任务。

---

2.2 Deployment

• 作用：
  • 定义 Pod 的模板和副本数。
  • 确保始终有指定数量的 Pod 在运行。
  • 支持滚动更新、回滚。
• 类比：Deployment 就像“公司招聘了多名相同岗位的员工”。

---

2.3 Service

• 作用：
  • 给一组 Pod 提供一个稳定的访问入口（Cluster IP / DNS 名称）。
  • 在多个 Pod 之间做负载均衡。
• 负载均衡算法：
  • 默认是 Round Robin（轮询）。
  • 底层依赖 iptables / IPVS 实现。

类比：Service 就像“公司前台”，客户找前台，前台把客户分配给某位员工。

---

2.4 Ingress / 外部 LB

• 作用：集群外部的访问入口。
• Ingress Controller 或云厂商的负载均衡器会把外部流量引到集群内部的 Service。
• 形成 两层负载均衡：
  1. 外部流量 → Ingress/外部 LB → Service
  2. Service → Pod 副本

---

3. 请求流转全链路

1. 开发者写代码 → 构建成 Docker 镜像 → 推送到镜像仓库。
2. K8s Deployment 使用该镜像启动多个 Pod。
3. Pod 内的容器 协同工作，运行微服务实例。
4. Service 作为统一入口，负责把请求分发给多个 Pod。
5. Ingress/外部 LB 负责把集群外流量引入 Service。
6. 用户请求 → Ingress → Service → Pod（某个副本容器处理请求）。

---

4. 类比一览表

概念	类比	说明
Docker 镜像	工厂的模具	包含制造一件产品所需的一切
容器	产品实例	从模具制造出来的具体产品
Pod	一名员工	运行一个微服务实例，内部容器是工具
Deployment	招聘同岗位的员工队伍	定义 Pod 数量、保证高可用
Service	公司前台	接待客户，请求分配给员工
Ingress	大门/总机	把外部客户带进公司前台

---

总结

• Pod = 微服务实例的一台机器（运行一个镜像副本）。
• Deployment 管理多个 Pod 副本，确保微服务的高可用和伸缩。
• Service 在多个 Pod 副本之间做负载均衡，是集群内访问入口。
• Ingress / LB 把外部请求引入 Service，形成双层负载均衡。
• 用户请求的路径：用户 → Ingress/LB → Service → Pod → 容器。