京公网安备11010502063487号在 kind 集群里复现命名空间一直 Terminating 的两种原因并读出 status.conditions:里面有带 finalizer 的对象时 NamespaceContentRemaining 与 NamespaceFinalizersRemaining 为 True,摘掉 finalizer 后 4.2 秒内自行删除;某个 APIService 后端找不到时 NamespaceDeletionDiscoveryFailure 为 True,删掉 APIService 后 0.6 秒内消失;用 /finalize 强行摘掉命名空间 finalizer 会让里面的对象留在 etcd 里,重建同名命名空间时它们又出现。
在 kind 集群里实测 Kubernetes 的 Lease 选主:kube-controller-manager 与 kube-scheduler 的 Lease 每 2.0 秒续约、leaseDurationSeconds=15;自己跑三个 kube-scheduler 候选者争同一个 Lease,只有一个 Successfully acquired lease;kill -9 leader 要 16.6 秒才换人,而 SIGTERM 或 force delete 会先释放租约,1.1~2.5 秒就换人;Lease 被改写后原 leader 报 Leaderelection lost 并退出,新 leader 在 19.1 秒后接手。
在 kind 集群里让一个 Pod 反复崩溃重启,实测 Event 的行为:重复的事件不产生新对象,同一个 Event 的 count 增加(Created 3→5、BackOff 2→4);同一个事件在 core/v1 与 events.k8s.io/v1 里的字段差别;etcd 里每个事件 key 绑着 TTL 3660 秒的 lease,Pod 的 key 没有;Pod 删除之后事件仍然保留,kubectl events --for 还能查看。
在 kind 集群里实测 APF(API 优先级与公平):默认 8 个优先级、11 个 FlowSchema,并发席位 = 600 × 份额 ÷ 总份额(workload-low 245 席、catch-all 13 席);kubeadm 管理员证书与匿名访问都归 global-default,ServiceAccount 归 workload-low,无效令牌在进入 APF 之前就被 401;自建份额为 1(3 个席位)的 Reject 级别,80 线程压 5 秒 6041 个请求中有 312 个 429(Retry-After: 3);改成 Queue 后 6071 个请求全部成功、没有 429。
在单独起的 kind 集群(apiserver 带 --audit-policy-file 与 --audit-log-path)里实测审计日志:一次 kubectl create configmap 留下 RequestReceived 与 ResponseComplete 两条记录,用响应头 Audit-Id 对上,含用户、userAgent、objectRef、授权决定;ConfigMap 在 RequestResponse 级别下口令明文进入日志,Secret 只记元数据;Metadata、Request、RequestResponse 三个级别记录的内容各不相同;冷缓存的 kubectl get pods 留下 3 条请求、热缓存 1 条;被拒绝请求的 decision=forbid,--as 模拟的用户记在 impersonatedUser。
在 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 符号链接原子切换。