京公网安备11010502063487号在 kind 集群里实测 TokenRequest:kubectl create token 默认 1 小时、最短 10 分钟(5 分钟被拒)、本集群接受 10 年;audience 不是 API Server 的令牌调用 API 得到 401,但可用带 audiences 的 TokenReview 验证;令牌可绑定到 Pod,Pod 或 ServiceAccount 删除后令牌再过约 10 秒才开始返回 401;TokenReview 返回 username、uid、groups 与 credential-id。
在 kind 集群里走完 kubectl 用户证书的签发:openssl 生成密钥和 CSR(CN=jane,O=devs),CertificateSigningRequest 在批准前一直 Pending;approve 后签名者几乎立刻签出证书(issuer=CN=kubernetes,有效期 = 请求的 3600 秒 + 回拨 300 秒);用它建 kubeconfig,whoami 得到 jane 与组 devs,没有 RBAC 时 Forbidden,绑定 view 后可以 get pods;deny、陌生的 signerName 与用途不符(SignerValidationFailure)都得不到证书。
用两个手写的 kubeconfig 和两个本地假 apiserver(只记录请求)实测 kubectl 如何解析 kubeconfig:KUBECONFIG=a:b 时同名的 cluster/user/context 先出现的文件胜出、不同名的合并、current-context 取第一个设了它的文件,顺序反过来结果就不同;--context 整套替换,--cluster/--user/--namespace/--token 各换一项,--kubeconfig 完全忽略环境变量;相对路径以 kubeconfig 所在目录为基准,config view 默认遮掉令牌。
在 kind 集群里实测 Pod 的三层状态:phase、conditions、容器 state。就绪探针未通过时 phase=Running 而 Ready=False;未调度的 Pod phase=Pending 且 PodScheduled=False(Unschedulable);restartPolicy=Never 的一次性 Pod 成功是 Succeeded、失败是 Failed;删除时 phase 仍是 Running,Terminating 来自 deletionTimestamp,不处理 SIGTERM 的进程要等满宽限期(21 秒)才被杀;OnFailure 下反复崩溃的 Pod phase 一直是 Running,崩溃记录在 restartCount 与 lastState 里。
在 kind 集群里实测三种探针各自改变了什么:readiness 失败 4.0 秒后 Pod 变 NotReady、EndpointSlice 端点 ready=false 但容器不重启,恢复后 1.6 秒重新 Ready;liveness 失败 7.9 秒后容器被 SIGKILL 重启(exitCode 137);startupProbe 在程序启动的 22.7 秒内挡住 liveness 使 restartCount=0,而没有它的对照 Pod 26 秒内被重启 3 次;httpGet 返回 404 与 exec 超时都算失败,tcpSocket 只看端口。
在 kind 集群里实测 init 容器:三个各睡 2 秒的 init 容器顺序执行(每个之间约 1 秒启动间隔),应用容器在 8.75 秒才启动,STATUS 依次 Init:0/3 → Init:1/3 → Init:2/3 → Running;失败的 init 容器按 restartPolicy 重试并经过 Init:Error 与 Init:CrashLoopBackOff,restartPolicy=Never 时 Pod 直接 Failed;init 容器的资源请求参与调度(请求 100 核导致 Unschedulable);应用容器重启不会重新运行 init 容器。
在 kind 集群里解开 Pod 里的 ServiceAccount 令牌:绑定 Pod 与节点的 JWT,卷里声明 expirationSeconds=3607 而令牌 exp 是 365 天(apiserver 默认延长);新 SA 不再自动生成 Secret 令牌,手工建的旧式令牌没有 exp、不绑定 Pod,删除 Secret 后 11 秒才 401;automountServiceAccountToken 在 SA 与 Pod 上冲突时 Pod 优先;自定义 600 秒受众的令牌在年龄约 83% 时被 kubelet 刷新,..data 符号链接原子切换。
在 kind 集群里实测原生 sidecar(initContainers 里 restartPolicy: Always):启动后不需要退出,startupProbe 通过后应用容器才在 +4.65 秒启动;Job 里写在 initContainers 的 sidecar 在 main 结束后被自动终止、Job 25 秒内 Complete,而写在 containers 里的 sidecar 让 Job 一直不完成;删除 Pod 时应用容器先收到 SIGTERM,退出后 0.04 秒 sidecar 才收到;sidecar 的 readinessProbe 参与 Pod 的 Ready,sidecar 崩溃只重启它自己。
在 kind 集群里量出删除 Pod 的时间线:preStop 睡 5 秒时 SIGTERM 在 +5.15 秒才到、应用 +6.15 秒退出,而 EndpointSlice 里端点在 +0.15 秒就变成 terminating(ready=false);没有 preStop 时 SIGTERM 在 +0.07 秒到;preStop 比宽限期还长时钩子被截断,SIGTERM 在 +6.07 秒送达、SIGKILL 约在 +8.1 秒,Pod 8.5 秒后消失;preStop 失败只产生 FailedPreStopHook 事件,终止照常进行。
在 kind 集群里量出 SIGTERM 与 SIGKILL 之间发生了什么:1 号进程没有 SIGTERM 处理函数时 Pod 要等满宽限期(3 秒 → 3.9 秒、8 秒 → 8.8 秒、默认 30 秒 → 30.3 秒);有 trap 时 0.8~1.2 秒退出;kubectl delete --grace-period=2 覆盖为 2.8 秒,--grace-period=0 --force 与 spec 里写 0 都是 0.1 秒;sh -c 包一层时子进程收不到 SIGTERM 要等 5.6 秒,用 trap 转发只要 0.5 秒。
在 kind 集群里让一个容器每次运行 1 秒就崩溃,实测 CrashLoopBackOff 的退避时间序列:第 1 次重启几乎立刻,之后等待 14、26、45、83、161 秒(约 10 秒起步每次翻倍,含开销);STATUS 大部分时间是 Error,CrashLoopBackOff 只偶尔出现;多容器 Pod 中崩溃的容器各自退避,好容器不受影响;restartPolicy=Never 不重启因此没有退避;删除重建同名 Pod 后退避从头开始。
在 kind 节点(cgroup v2,systemd 驱动)里实测 QoS 等级:七个 Pod 的 requests/limits 组合分别得到 Guaranteed、Burstable、BestEffort;三类 Pod 的 cgroup 位置不同;Guaranteed 的 oom_score_adj 是 -997,Burstable 按 1000 − 1000×内存请求÷节点内存(32Mi → 996),BestEffort 是 1000;在线调整资源若会改变 QoS 等级则被拒绝(Pod QOS Class may not change as a result of resizing)。