k8sLearn
起源
AI的下半场开启, vibe coding现在已经进化到按照你的规划可以完整的写出对应代码, 有些感叹.
学习方法
很早以前就开始自己使用docker, 从观望到企业也开始使用docker-compose, 对于容器化也是有一定自己的理解, 那我们现在用docker去学习k8s, 由浅入深去进行学习.
由浅
我们可以从网络、命令和配置文件这三个核心维度，对比 Docker（单机容器引擎）与 Kubernetes（集群编排系统）的差异。
一、 网络 (Networking)
| 维度 | Docker (单机网络) | Kubernetes (集群网络) |
|---|---|---|
| 核心架构 | 基于单机，依赖本地网桥（如 docker0）或自定义网络驱动（Bridge、Host、Overlay、Macvlan）。 | 基于 CNI（容器网络接口） 插件（如 Flannel、Calico），实现跨主机集群网络。 |
| IP 分配 | 容器 IP 通常只在当前宿主机内可见，跨主机通信需要配置复杂的 Overlay 或手动做端口映射。 | Pod 拥有独立 IP。集群内所有 Pod 处于同一个扁平大二层网络中，Pod 与 Pod 之间无需 NAT 映射即可直接通信。 |
| 服务发现与负载均衡 | 依靠 --link（已弃用）或依赖外部代理/Docker Swarm 的内置 DNS。 | 内置 CoreDNS 和 Service 抽象。通过 Service 提供稳定的虚拟 IP 和负载均衡，自动把流量分发到对应的 Pod。 |
| 安全控制 | 较基础，主要依靠 Docker Network 隔离。 | 支持 NetworkPolicy（网络策略），可以像防火墙一样精确控制 Pod 之间、Namespace 之间的访问权限。 |
二、 命令 (Commands)
两者的命令行哲学完全不同：
- Docker 偏向 命令式（Imperative）：直接对容器下达特定动作指令。
- Kubernetes 偏向 声明式（Declarative）：通过控制器维护期望的集群状态。
| 操作场景 | Docker CLI (docker) | Kubernetes (kubectl) |
|---|---|---|
| 核心操作对象 | 容器 (Container)、镜像 (Image)、数据卷 (Volume) | Pod、Deployment、Service、ConfigMap 等抽象对象 |
| 查看运行实例 | docker ps | kubectl get pods |
| 查看详细信息 | docker inspect <container> | kubectl describe pod <pod> |
| 查看实时日志 | docker logs -f <container> | kubectl logs -f <pod> |
| 进入容器交互 | docker exec -it <container> sh | kubectl exec -it <pod> -- sh |
| 生命周期管理 | docker run / docker stop / docker rm | kubectl apply -f file.yaml / kubectl delete |
三、 配置文件 (Configuration Files)
| 维度 | Docker (Compose / Dockerfile) | Kubernetes (YAML 声明式清单) |
|---|---|---|
| 主要用途 | Dockerfile 用于定义单个镜像的构建步骤； Docker Compose 用于定义和运行多容器的单机应用。 | 用于定义 Kubernetes 集群中的各种资源对象（如 Deployment、Service、Ingress、ConfigMap 等）。 |
| 设计理念 | 过程式/组合式：侧重于“怎么构建”和“启动哪些关联容器”。 | 声明式（Declarative）：只需描述“期望达到什么最终状态”（如：保持 3 个副本），K8s 控制平面会自动调谐去匹配它。 |
| 配置内容示例 | Compose 文件里包含 build、image、ports、environment 等。 | YAML 文件必须包含 apiVersion、kind（资源类型）、metadata（元数据）和 spec（规格期望）。 |
| 配置与代码分离 | 通过 .env 文件或 Compose 的 environment 注入环境变量。 | 拥有专门的 ConfigMap 和 Secret 资源对象，用于管理配置和敏感信息，与业务代码彻底解耦。 |