你好，陌生人。

Kubernetes（简称K8s）是Google于2014年开源的容器编排平台，现由云原生计算基金会（CNCF）管理，其名称源自希腊语“舵手”，寓意对容器化应用的精准调度。它基于Google内部Borg系统的十余年生产经验，通过声明式配置和自动化管理，解决了容器化应用在部署、扩展、运维中的核心问题。 截至2025年，Kubernetes已成为容器编排的事实标准，支撑从微服务到AI训练等多样化场景，其设计理念和分层架构（核心层、应用层、管理层等）持续推动云计算领域的创新。未来，随着安全特性（如RBAC、审计日志）和跨集群联邦能力的增强，Kubernetes将进一步巩固其在云原生生态中的核心地位。 架构 Control plane Kubernetes控制面板（Control Plane）是整个Kubernetes集群的核心组件，负责管理和协调各个节点和资源。它包含多个关键组件，各组件协同工作来管理容器的调度、资源分配、集群状态维护、以及提供API供客户端与集群交互。 工作流程概览 用户通过kubectl命令与kube-apiserver通信，发出API请求。 kube-apiserver接收请求，验证后将所需数据存入etcd。 kube-scheduler根据调度策略选择合适的Node节点运行Pod。 kube-controller-manager监控集群状态，根据定义的策略调整资源以保证期望状态。 cloud-controller-manager则用于与云环境通信，管理云上的资源。 控制平面确保了集群的自愈能力、弹性扩展以及安全访问。 kube-apiserver kube-apiserver是控制平面的核心组件，提供Kubernetes集群的REST API接口。它是唯一允许与etcd直接交互的组件。 主要负责接收、验证和处理来自用户、管理员和其他组件的请求，并将这些请求存储到etcd。 客户端通过kube-apiserver查询集群状态、获取资源信息、发送指令等。可以通过kubectl命令行工具与其交互。 etcd etcd是Kubernetes的分布式键值存储系统，用来保存所有集群的数据和状态信息。 它在数据一致性方面表现优异，确保在多节点环境中，所有节点的数据是同步的。 主要用于存储集群的配置信息、状态信息和对象定义，作为集群的“数据库”。 kube-scheduler kube-scheduler负责将Pod调度到合适的Node节点上。 在接收到新的Pod请求后，它会根据预定义的调度策略（如节点资源利用率、负载均衡）选择最佳的Node节点。 经过调度后，Pod会被分配到一个具体的Node上，并由kubelet启动并运行。 kube-controller-manager kube-controller-manager包含多个控制器（Controller），每个控制器负责不同的控制逻辑。 常见的控制器包括： Node Controller：监控节点的状态，在节点失联时做出相应处理。 Replication Controller：确保指定数量的Pod副本在集群中始终处于运行状态。 Endpoint Controller：为Service对象管理Endpoints。 Service Account & Token Controller：创建默认的ServiceAccount并管理其关联的token。 kube-controller-manager通过不断地“检测-校正”的过程来维持集群的所需状态。 cloud-controller-manager （仅在使用云提供商时需要） cloud-controller-manager是用于在Kubernetes上管理与云服务提供商相关资源的组件。 它提供对云资源的访问和管理功能，例如负载均衡器、存储卷和网络设置。 这个组件通常包含多个控制器（例如Node、Route、Service等），以适应云平台的特性和需求。 Node kubelet kubelet 是Kubernetes架构中负责管理和维护每个 Node 上容器生命周期的核心组件。它在每个 Node 上运行，负责与 Control plane（如kube-apiserver）进行通信，确保 Pod 在 Node 上正确创建、运行和报告状态。 Pod生命周期管理 kubelet的主要任务是管理节点上Pod的生命周期。具体职责包括： 创建和销毁Pod：根据控制平面的调度决定拉取容器镜像并启动Pod，同时在不需要时销毁Pod。 容器健康检查：定期检查容器的健康状况，根据定义的探针（如Liveness Probe和Readiness Probe）判断是否重启或重新启动不健康的容器。 自动重启：当容器崩溃或不健康时，根据定义的重启策略自动重启容器。 节点资源管理 kubelet监控节点的资源使用情况，包括CPU、内存、存储等资源。它确保节点上的容器不会超过资源限制，并在资源不足时及时通知控制平面。 ...

Kubernetes网络是容器编排平台的核心基础设施，它通过独特的"IP-per-Pod"模型构建了一个扁平化的虚拟网络空间。在这个体系中，每个Pod都拥有独立IP地址（Pod内容器共享网络命名空间），所有Pod可以直接通信而无需NAT转换，这种设计显著简化了分布式应用的网络架构。当前主流云厂商的Kubernetes服务均基于此模型构建，使其成为云原生时代容器网络的事实标准。 网络模型 Underlay Network 底层网络，指物理网络基础设施，包括路由器、交换机、光纤、电缆等硬件设备，以及这些设备之间的连接和协议（如 IP、BGP、OSPF 等）。它是网络的底层基础，负责实际的数据传输。 特点： 物理性：由硬件设备和物理连接组成。 直接性：数据包在 Underlay Network 中直接通过物理设备传输，没有额外的封装或解封装过程。 性能：高性能、低延迟。 Overlay Network 覆盖网络，指在 Underlay Network 之上构建的 虚拟网络，它利用 Underlay Network 的物理基础设施，通过封装技术实现虚拟化的网络通信，是虚拟网络，与物理网络解耦。 特点： 虚拟性：通过软件定义的方式构建。 封装性：数据包在 Overlay Network 中被封装在 Underlay Network 的数据包中传输，到达目的地后再解封装。 性能：有一定的性能开销。 Kubernetes 网络模型 Kubernetes 集群内的网络模型定义了以下几点： 每个 Pod 都有一个唯一的 IP 地址：Pod 内的所有容器共享同一个网络命名空间，因此它们共享同一个 IP 地址和网络配置。 容器之间可以通过 localhost 访问， 集群内的 Pod 处于一个扁平网络中：所有 Pod 可以直接互相通信，无论它们是否在同一个节点上，无需通过 NAT。 Service 和 Cluster IP：Kubernetes 提供了 Service 和 Cluster IP 的概念，使得服务可以在集群内部被发现和访问。 外部访问：外部请求可以通过 NodePort、LoadBalancer 或 Ingress 等方式访问集群内的服务。 详见 Kubenetes 网络模型官方解释。 ...

Kubernetes中的kube-proxy是集群网络架构的核心组件，作为运行在每个节点上的守护进程，它通过动态管理网络规则实现了服务发现与负载均衡的关键功能。kube-proxy持续监听API Server中Service和Endpoint的变化，利用Linux内核的iptables或IPVS机制，将访问Service虚拟IP（ClusterIP）的流量智能路由到后端Pod。其核心价值在于：当Pod发生扩缩容或重启时，能自动更新转发规则，确保服务始终通过固定IP可达；支持轮询、最小连接数等负载均衡算法，并可通过NodePort/LoadBalancer类型服务暴露集群应用。当前主流代理模式中，iptables适合中小规模集群，而IPVS凭借O(1)时间复杂度更适合超千服务的生产环境。作为Kubernetes服务抽象的实现基石，kube-proxy使开发者无需关注PodIP变化，只需通过Service名称即可访问分布式应用。 工作原理 以下是客户端、Service 以及 Pod 之间流量转发路径： 代理模式 userspace Kubernetes v1.1 之前的默认代理模型。 kube-proxy 跟踪 API Server 上的 Service 和 Endpoints 的创建和移除，对于每个 Service 对象，它会随机打开一个本地端口（运行于用户空间的 kube-proxy 进程负责监听），任何到达此代理端口的连接请求都将被代理至当前 Service 资源后端的各 Pod 对象，至于哪个Pod 对象会被选中则取决于当前 Service 资源的调度方式，默认调度算法是轮询（round-robin）。另外，此类Service对象还会创建iptables 规则以捕获任何到达 ClusterIP 和端口的流量。 kube-proxy 在 userspace 模式下有两个功能： 监听 API Server 的 Service 对象，修改防本地的火墙规则（iptables），实现负载均衡的分发。 代理来自当前节点 Pod 的请求。 iptables Kubernetes v1.2 以后的默认代理模型。 创建Service对象的操作会触发集群中的每个 kube-proxy 并将其转换为定义在所属节点上的 iptables 规则（添加到 KUBE-SERVICES 链中），用于转发工作接口接收到的、与此 Service 资源 ClusterIP 和端口相关的流量。客户端发来请求将直接由相关的 iptables 规则进行目标地址转换（DNAT）后根据算法调度并转发至集群内的 Pod 对象之上，而无须再经由 kube-proxy 进程进行处理。 ...

Kubernetes 中的 Service 是一种抽象层，用于将一组 Pod 暴露为稳定的网络服务，其底层原理涉及 网络代理、负载均衡和 DNS 解析 等多个组件的协同工作。 服务发现：通过 DNS 或环境变量暴露服务名称（如 my-service.default.svc.cluster.local）。 负载均衡：将请求均匀分发到后端 Pod。 稳定访问：屏蔽 Pod IP 的动态变化（如扩缩容、重启）。 两种服务发现方式 （早）基于环境变量 每当 Pod 启动时，Kubernetes 会自动为集群中的 Service 设置环境变量，这样 Pod 内部的应用可以使用这些环境变量来发现 Service。 变量格式： 1 2 <SERVICE_NAME>_SERVICE_HOST=<service-ip> <SERVICE_NAME>_SERVICE_PORT=<port> 限制 Pod 必须在 Service 创建后启动，否则不会获取环境变量！ 只适用于简单的服务发现，不支持负载均衡。 无法解析 Pod 级别的 DNS，只能解析 Service。 （现）基于 DNS（CoreDNS） Kubernetes 主要使用 CoreDNS 进行服务发现，解析 Service 或 Pod 的域名。 Service DNS 格式： 1 <service-name>.<namespace>.svc.cluster.local Pod DNS 格式（可选）: 1 <pod-ip>.<pod-name>.<namespace>.pod.cluster.local 一般访问一个 Service，CoreDNS 会返回一个 ClusterIP： ...

Kubernetes存储系统是容器化应用数据持久化的核心架构，通过抽象层将分布式存储资源转化为可动态调配的云原生服务。当前主流云厂商的托管Kubernetes服务已深度集成存储自动化管理能力，使开发者只需关注存储容量和性能需求，无需介入底层存储系统的运维细节。 ConfigMap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 apiVersion: v1 kind: ConfigMap metadata: name: my-config labels: app: my-app data: # 类属性键；每一个键都映射到一个简单的值 log-level: "info" app-name: "my-app" # 类文件键 app.properties: | server.port=8080 app.name=my-app log.level=info data 字段中所有键值对，如果不在 Pod 中用 items 进行 key-values 映射，默认会将 ConfigMap 中的所有 key 全部转化为一个个同名的文件进行挂载。 ...