前言前面十九篇基本围绕 Kubernetes 自带对象展开：Pod、Deployment、Service、ConfigMap、Secret、PVC、Ingress、NetworkPolicy 等。 如果只是部署一个简单服务，写几份 YAML 还能接受...

前言这个系列前面大多数示例都围绕 Deployment，因为它最适合长期运行的无状态服务。 但 Kubernetes 不只有 Deployment。不同类型的任务，需要不同的控制器： 1234567891011121314Deployment 长期...

前言前面写 Service 时，我把它理解成“给一组 Pod 提供稳定入口”。默认情况下，很多集群里的 Pod 之间是可以互相访问的。 这在学习时很方便，但在真实环境里会带来一个问题： 1234frontend 能访问 demo-apidemo-ap...

前言上一篇写 ServiceAccount 和 RBAC 时，我把它们理解成 API 层面的权限控制：这个 Pod 里的程序能不能访问 Kubernetes API，能读什么、改什么。 但这还不够。即使一个应用不访问 API Server，它在节点上...

前言前面整理到这里，应用已经能运行、能暴露、能读取配置，也能做基本排障。接下来我想把视角切到安全上。 第一个问题是：Pod 里的程序能不能访问 Kubernetes API？ 比如一个应用想读取同 namespace 下的 ConfigMap，或者一...

前言Service 解决了一个很重要的问题：给一组不断变化的 Pod 提供稳定入口。 但 Service 本身更像是集群内部的稳定地址。到了外部访问场景，问题会变复杂： 123api.example.com/users -> user-ser...

前言前面已经整理了不少对象：Pod、Deployment、Service、ConfigMap、Secret、Volume、Namespace、Ingress。对象多了之后，另一个问题会变得很现实： 出问题时，我到底先看哪里？ 刚开始很容易看到一个...

前言第四篇写 Deployment 时，我已经提到过滚动发布：新版本 Pod 逐步增加，旧版本 Pod 逐步减少。 那一篇更偏概念，这一篇我想把发布过程再摊开一点，看看它到底在替换什么、怎么判断新 Pod 能不能接流量、回滚又到底回到哪里。 先把主线...

前言前面写 Service 时，我提到过一个点：Pod 显示 Running，不代表应用已经可以接收流量。 这句话其实很关键。容器进程启动了，只说明进程还在，不代表它真的健康。 比如一个 Java 服务： 12345678910容器进程已启动 ...

前言前面写到 Deployment 时，我一直在说“调度器会把 Pod 放到合适的节点”。但这里有个很自然的问题：调度器怎么知道哪个节点合适？ 如果一个 Pod 不说明自己大概要用多少 CPU、多少内存，调度器就只能很粗略地安排。结果可能是：某个节点...