前言前面写 Deployment 和 Pod 时，我一直在 YAML 里写类似这样的字段： 123containers: - name: demo-api image: example/demo-api:1.0.0 一开始我只把它理解成“指...

前言前面写 Service 时，我已经碰到过 Label 和 Selector： 1234Service selector: app=demo-api | v匹配 Pod labels: app=demo-api 写 D...

前言前面几篇写到现在，Kubernetes 对象已经不少了： 1234567PodDeploymentReplicaSetServiceConfigMapSecretPVC 如果所有对象都堆在一起，很快就会乱。尤其是同一个应用可能有开发、测试、生产...

前言前面整理 Pod 时，我反复提醒自己：Pod 是可以被删除和替换的。 这句话放到应用进程上还好理解，Pod 没了再拉一个。但如果应用在容器里写了数据，问题就来了：Pod 重建后，数据还在吗？ 如果数据只写在容器自己的可写层里，大概率会跟着容器一起...

前言前面几篇已经把 Pod、Deployment、Service 串起来了：应用能运行，也有了稳定入口。 但应用真正跑起来时，还会遇到一个很现实的问题：配置怎么办？ 例如一个后端服务，代码和镜像可能是同一份，但在不同环境里配置不同： 123开发环境：...

前言上一篇整理 Deployment 时，我把它理解成“长期维护一组 Pod 的声明”。Deployment 能让 Pod 少了就补，版本变了就逐步替换。 但这里马上会出现另一个问题：Pod 会不断变化，那别人到底该访问谁？ 假设 demo-api ...

前言上一篇整理 Pod 时，我留下了一个问题：Pod 本身是短暂的，被删除后不会自己回来，那长期运行的服务到底靠什么稳定住？ 刚开始看 Kubernetes 时，我总觉得 Deployment、ReplicaSet、Pod 这三层有点绕。明明最终跑起...

前言刚接触 Kubernetes 时，我一直把 Pod 当成“换了个名字的容器”。毕竟大多数示例里，一个 Pod 只有一个容器，看起来只是外面多包了一层。 继续往下看后，我发现这个理解会留下不少问题：既然一个容器就能运行应用，为什么 Kubernet...

前言上一篇整理 Kubernetes 基本概念时，我把集群简单分成了两部分：控制面负责“管”，工作节点负责“跑”。 这个说法比较容易记，但继续往下看时，我又遇到了新的问题：控制面到底怎么管？调度器选完节点后，是谁真正启动容器？Pod 挂掉以后，又是谁...

前言刚开始接触 Kubernetes 时，我最先看到的是一堆 kubectl 命令，但真正让我困惑的其实是：这些命令背后的 Kubernetes 到底在解决什么问题？ 我试着从一个更熟悉的场景来理解它。 如果把应用部署比作开餐馆，最开始可能只有一个小...