Joohwan

Pod 在节点落地通信流程目标这篇文档只回答一个核心问题：kubelet 如何把“期望运行”的 Pod 变成“真实运行”的容器？ 重点放在 kubelet 内部各组件之间的协作与 CRI 通信边界，而不是每一个 gRPC 字段的含义。 一句话摘要kubelet 收到 Pod 更新后，把期望态交给 podWorkers；podWorkers 驱动单 Pod 生命周期状态机，再由 kubeGenericRuntimeManager 通过 CRI 调用容器运行时完成 sandbox、镜像与容器操作。 1. 流程总览从通信视角看，这条链路可以拆成 3 个阶段： 更新接入阶段：kubelet 从 Pod source 收到属于本节点的 Pod 更新，并交给内部子系统。 状态机驱动阶段：podWorkers 根据当前状态决定执行同步、终止还是清理。 运行时执行阶段：runtime manager 通过 CRI 把操作翻译给容器运行时，完成 sandbox 和容器的创建/销毁。 Mermaid：总览图flowchart LR A[Pod update from sour...

Pod 生命周期与终止流程概述Pod 的生命周期从 Pending 开始，经过 Running，最终到达 Succeeded 或 Failed。理解 Pod 生命周期对于正确管理应用至关重要。 Pod 生命周期阶段1234567891011121314151617181920// staging/src/k8s.io/api/core/v1/types.gotype PodPhase stringconst ( // PodPending: Pod 已被接受，但容器尚未启动 PodPending PodPhase = "Pending" // PodRunning: Pod 已绑定到节点，所有容器已创建，至少一个容器正在运行 PodRunning PodPhase = "Running" // PodSucceeded: Pod 中所有容器已成功终止，不会重启 PodSucceeded PodPhase = "Succeeded" // PodFailed: Pod 中所有容器已...

Pod 调度与绑定通信流程目标这篇文档只回答一个核心问题：一个 Pod 是怎么从“等待调度”变成“被某个节点上的 kubelet 感知到”的？ 重点放在组件之间的通信与职责边界，而不是调度器内部打分算法细节。 一句话摘要kube-scheduler 负责为 Pod 选节点，kube-apiserver 负责持久化绑定结果，kubelet 通过监听 API Server 中属于本节点的 Pod 更新来感知这次分配。 1. 流程总览从通信视角看，这条链路可以拆成 3 个阶段： 调度决策阶段：scheduler 为 Pod 选择目标节点。 绑定落盘阶段：scheduler 通过 API Server 把绑定结果写回集群状态。 节点感知阶段：目标节点上的 kubelet 观察到这个 Pod 已经分配给自己，开始进入节点侧处理。 Mermaid：总览图flowchart LR A[Pending Pod] --> B[kube-scheduler] B --> C[select target node] C --> D[kube-apiser...

RBAC 权限控制流程概述RBAC (Role-Based Access Control) 是 Kubernetes 默认的授权模式，通过 Role 和 RoleBinding 来控制用户对资源的访问权限。 核心概念1234567891011121314151617181920212223242526┌─────────────────────────────────────────────────────────────────────────────┐│ Role (角色) ││ 定义一组权限规则 (PolicyRules)，包含 verbs、resources、apiGroups ││ pkg/apis/rbac/types.go │└───────────────────────────────────────────────────...

StatefulSet 控制器流程概述StatefulSet 用于管理有状态应用，提供有序部署、稳定网络标识和持久化存储。与 Deployment 不同，StatefulSet 保证 Pod 的顺序性和唯一性。 核心架构1234567891011121314151617181920212223242526272829┌──────────────────────────────────────────────────────────────────────────────┐│ StatefulSetController ││ pkg/controller/statefulset/stateful_set.go ││ ││ ┌─────────────┐ ┌...

kube-apiserver 请求处理流程概述kube-apiserver 是 Kubernetes 控制平面的核心组件，负责处理所有 API 请求。每个请求都需要经过认证(Authentication)、授权(Authorization)、准入控制(Admission Control) 才能被持久化到 etcd。 核心处理流程1234567891011121314151617181920212223242526272829303132┌──────────────────────────────────────────────────────────────────────────────┐│ API 请求入口 ││ http.Handler -> DefaultBuildHandler │└───────────────────────────────────────...

kube-proxy 服务代理通信流程目标这篇文档只回答一个核心问题：kube-proxy 如何实现 Service 的负载均衡和网络代理？ 重点放在 kube-proxy 与 API Server 的交互、规则同步机制以及 iptables/IPVS 模式的差异。 一句话摘要kube-proxy 通过 watch API Server 中的 Service 和 EndpointSlice 对象，在本地维护 iptables/IPVS 规则，将到达 Service ClusterIP 的流量转发到后端 Pod。 1. 流程总览从通信视角看，这条链路可以拆成 3 个阶段： 配置获取阶段：kube-proxy watch Service 和 EndpointSlice 对象。 规则计算阶段：根据 Service 类型计算需要生成的代理规则。 规则同步阶段：将规则写入 iptables/IPVS，实现流量转发。 架构总览图flowchart TB subgraph 控制面["控制面"] API[kube-a...

Kubelet 状态与事件回传流程目标这篇文档只回答一个核心问题：kubelet 如何把节点侧观察到的 Pod 运行结果回传给控制面？ 重点放在状态回传与事件上报两条通信链路的区别，以及控制器真正依赖的观察面是什么。 一句话摘要kubelet 通过 statusManager 异步批量把 PodStatus 同步到 API Server，并通过事件记录器上报诊断性 Event；控制器主要观察的是 API Server 中资源对象的状态变化，而不是 kubelet 内部事件流本身。 1. 流程总览从通信视角看，这条链路包含两条并行但职责不同的子链路： 状态回传链路：kubelet 把 Pod 运行状态写回 API Server，成为控制面的共享事实。 事件上报链路：kubelet 把诊断性 Event 写入 API Server，用于排障与审计。 这两条链路共享 API Server 作为存储，但消费方和语义完全不同。 Mermaid：总览图flowchart LR A[Kubelet subsystems] --> B[statusManager] A...

Kubelet 认证授权通信流程目标这篇文档只回答一个核心问题：kubelet 如何验证和授权对 kubelet API 的访问请求？ 重点放在 kubelet 的认证模块、授权模块以及与 API Server 的交互流程。 一句话摘要kubelet 通过 webhook 认证和授权，将客户端请求转发给 API Server 进行验证，支持匿名访问、证书认证和 bootstrap token 认证等多种方式。 1. 流程总览从通信视角看，这条链路包含三个层次： **认证层 (Authentication)**：验证客户端身份。 **授权层 (Authorization)**：验证客户端是否有权限执行操作。 **准入层 (Admission)**：对请求进行额外检查和修改（仅部分操作）。 架构总览图flowchart TB subgraph 客户端["请求来源"] direction LR API[kube-apiserver<br/>proxy/attach/exec] KUBECTL[...

Kubelet 资源驱逐 (Eviction) 通信流程目标这篇文档只回答一个核心问题：kubelet 如何在节点资源不足时决定并执行 Pod 驱逐？ 重点放在 EvictionManager 的监控机制、驱逐决策逻辑以及驱逐执行流程。 一句话摘要kubelet 的 EvictionManager 定期监控节点资源使用，当资源超过阈值时，根据 QoS 和优先级选择 Pod 进行驱逐，以保护节点稳定性。 1. 流程总览从通信视角看，这条链路可以拆成 3 个阶段： 资源监控阶段：EvictionManager 定期采集节点资源使用情况。 决策判断阶段：根据阈值和策略决定是否需要驱逐以及驱逐哪些 Pod。 执行驱逐阶段：通过 API Server 删除选中的 Pod。 架构总览图flowchart TB subgraph 资源采集["资源采集层"] direction TB CAD[cAdvisor<br/>容器资源监控] SYS[系统信息<br/>节点资源] SI...