嗨 ! 海洋-CSDN博客

原创 K8S 调度 - 总览

本文概述了Kubernetes调度器在不同资源条件下的调度策略。在资源充足时，调度器通过绑定CPU核和GPU（借助DevicePlugin）来分配资源；资源不足时，基于预定义的资源模型进行资源回收（Eviction）和优先级抢占；当资源恢复充足时，MoveAllToActiveQueue插件会刷新调度队列，Pod更新也会触发关联Pod的迁移。这些机制共同保障了集群资源的高效利用和任务调度的合理性。

2026-01-29 09:25:46 393

原创 Kubernetes GPU 管理与 Device Plugin 机制

本文探讨了Kubernetes对GPU资源管理的实现机制。主要内容包括：1）GPU在AI计算中的核心作用，其并行计算特性与CPU形成互补；2）Kubernetes通过ExtendedResource机制支持GPU资源声明和调度，利用DevicePlugin插件自动发现和管理GPU设备；3）DevicePlugin通过gRPC与kubelet交互，完成设备分配和驱动挂载；4）当前设计存在局限性，如无法支持复杂设备属性和高级调度策略；5）该架构遵循最小化接口原则，权衡了功能扩展性与系统稳定性。整体展现了Kube

2026-01-29 09:24:03 611

原创调度器-Pod更新触发关联Pod迁移

摘要：Kubernetes调度器在已调度Pod更新时，会将unschedulableQ中与之存在Affinity/Anti-affinity关系的Pod迁移至activeQ。这一机制通过主动响应Pod间动态约束关系的变化，保障了调度公平性、资源利用率和业务连续性。核心价值体现在：1）及时重置关联Pod的调度约束条件；2）避免高优先级Pod因等待定期检查而错失调度机会；3）释放因约束变化而解锁的集群资源潜力。该设计特别适用于需要保障拓扑约束的分布式应用场景，如数据库主从同步和Web服务高可用部署。

2026-01-29 09:23:36 641

原创 K8S- 调度器-MoveAllToActiveQueue插件刷新调度机会

Kubernetes调度器通过activeQ和unscheduableQ双队列机制管理Pod调度。当集群资源变化（如Node/PV更新）可能影响调度结果时，调度器会触发MoveAllToActiveQueue操作，将所有unscheduableQ中的Pod移回activeQ重新评估。这一设计解决了三个核心问题：1）避免因定期检查延迟导致的调度滞后；2）确保新释放资源被及时利用；3）简化状态管理复杂度。虽然可能带来少量无效调度尝试，但显著提升了系统的实时性和资源利用率，体现了Kubernetes在工程实践中的

2026-01-28 09:21:16 598

原创 K8S- 调度器的DefaultPreemption插件实现抢占

本文详细解析了Kubernetes集群中Pod抢占机制的工作原理和实现流程。主要内容包括：抢占的核心概念（抢占者、受害者、优先级等）、触发条件、整体架构以及分阶段流程（从候选节点筛选到受害者删除重建）。重点阐述了控制器在抢占过程中的关键作用，包括Deployment、StatefulSet和DaemonSet等不同类型控制器的重建特点。同时提出了优化建议，如合理设置优先级、配置抢占容忍度等，以平衡集群稳定性与资源利用率。通过典型场景示例展示了抢占机制的实际应用，帮助用户理解如何在高优先级Pod调度时确保集群

2026-01-28 09:19:24 519

原创调度器的调度策略

调度器在具体执行的时候，当开始调度一个 Pod 时，K8S 调度器会同时启动 16 个 Goroutine，并发地为集群的所有 Node 计算 Predicates，最后返回可以运行这个 Pod 的所有宿主机列表。(5) 如果该 Pod 的 PVC 还没有跟具体的 PV 绑定的话，调度器还要负责检查所有待绑定PV，当有可用的 PV 存在并且该 PV 的 nodeAffinity 与待考察节点一致时规则才会。需要注意的是，在为每个 Node 执行 Predicates 时，调度器会按照固定的顺序来进行检查。

2026-01-28 09:13:26 544

原创 K8S - 资源调度（Container绑定CPU核）

摘要：通过设置cpuset将容器绑定到特定CPU核上，相比cpushare共享方式能显著提升性能，减少上下文切换。在生产环境中，需满足三个条件：Pod为Guaranteed QoS类型、节点开启static CPU管理策略、CPU请求为整数值且requests等于limits。满足条件后，kubelet会自动将容器放入cpuset子系统，实现CPU独占绑定。绑定的CPU核将从全局调度器中移除，其他容器无法使用，确保资源独占性。这种绑定方式无需手动配置cpuset，由kubelet自动完成分配。

2026-01-28 09:12:40 76

原创 K8S - 默认调度器

在 Kubernetes 项目中，默认调度器的主要职责，就是为一个新创建出来的 Pod，寻找一个最合适的节点（Node）。而这里“”的含义，包括两层：（1）从集群所有的节点中，根据调度算法挑选出所有可以运行该 Pod 的节点；（2）从第一步的结果中，再根据调度算法挑选一个最符合条件的节点作为最终结果。所以在具体的调度流程中，默认调度器会首先调用一组叫作的调度算法来检查每个 Node。然后，再调用一组叫作的调度算法来给上一步得到的结果里的每个 Node 打分。

2026-01-28 09:10:57 536

原创 K8S调度-依据资源模型实行资源回收-Eviction

QoS 划分的主要应用场景，是当宿主机资源紧张的时候，kubelet 对 Pod 进行 Eviction（即资源回收）时需要用到的。当 Kubernetes 所管理的宿主机上不可压缩资源短缺时，就有可能触发 Eviction。

2026-01-27 09:06:43 363

原创 K8S调度- 资源模型

（1）对于上述K8S 对资源的限制，是参考了 Borg 论文中“动态资源边界”的概念：容器化作业在提交时所设置的资源边界，并不一定是调度系统所必须严格遵守的，因为在实际场景中，大多数作业使用到的资源其实远小于它所请求的资源限额。（2）用户在提交 Pod 时，可以声明一个相对较小的 requests 值供调度器使用；Kubernetes 真正设置给容器 cgroups 的，则是相对较大的 limits 值。

2026-01-27 09:06:04 609

原创 K8S控制器-Ingress Controller

ingress-nginx-controller-admission Service type=ClusterIP：只暴露 443，让 API Server 在校验钩子时能寻址到控制器里的 webhook 服务器。业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为 Kubernetes 专门维护了对应的 Ingress Controller。用户写错 Ingress（路径冲突、非法正则等）如果直接写进 etcd，可能把整个集群的 nginx 配置搞崩。

2026-01-26 09:17:59 641

原创官方Ingress 控制器YAML解析

(1) Namespace ingress-nginx 被创建，后续所有对象都落在它里面。(2) 两个 ServiceAccount 被创建：ingress-nginx —— 给主控制器 Pod 用。ingress-nginx-admission —— 给两个证书 Job 用。此时 SA 只是 etcd 里的空壳，还没有任何 Token/Secret；

2026-01-26 09:16:45 556

原创 K8S集群 - 四大组件工作原理

kube-controller-manager 不是“一个”控制器，而是 N 个控制循环的集合体，打包在一个进程里跑– DeploymentController / ReplicaSetController：维护期望副本数，创建/删除 Pod。– NodeController：定期检查节点心跳，把 Down 节点标记为 Unknown 并驱逐其 Pod。

2026-01-23 10:16:49 451

原创 K8S对象API - Service总结

Service筛选被选中的Pod主要依据Pod的readinessProbe状态，是因为readinessProbe专门用于判断Pod是否已经准备好接收流量。若未通过，则Pod会被从Service的端点列表中移除，避免接收到流量。而livenessProbe主要用于判断Pod是否需要重启，与Service的流量分发逻辑无直接关联。： Service 筛选被选中的POD，主要还是依据pod的readniessProbe状态。这种机制确保流量只被分发到能够正常提供服务的Pod，从而保障服务的稳定性和可靠性。

2026-01-23 10:16:40 48

原创外部访问Service- LoadBalancer/ExternalName

Service 是 kube-proxy转发+Iptables/ipvs 规则从主机集群角度考虑：集群内部可以通过转发和防火墙规则实现服务的网络互通,但是集群外部无法访问到集群的内部。所以，常规service无法作为外部访问K8S集群服务的桥梁。

2026-01-23 10:16:24 61

原创 Service 配置公有IP

2 然后由该节点上的kube-proxy或iptables进行处理，将流量转发到后端Pod。如果externalIPs无法路由到任何节点，外部流量就无法进入集群，进而无法到达目标Pod。1 当外部流量通过externalIPs发送到集群时，流量首先到达某个节点.此外，这种设计也有助于保证流量的可控性和安全性，避免Pod直接暴露在互联网中。通过访问公有IP的80端口，实现访问被代理的pod:9376。externallPs : 是外部数据包进入K8S集群的入口。

2026-01-23 10:16:13 28

原创外部访问Service-NodePort无VIP

Service 是 kube-proxy转发+Iptables/ipvs 规则从主机集群角度考虑：集群内部可以通过转发和防火墙规则实现服务的网络互通,但是集群外部无法访问到集群的内部。所以，常规service无法作为外部访问K8S集群服务的桥梁。

2026-01-23 10:16:04 495

原创 K8S对象-Service(ipvs rules)

Kubernetes的kube-proxy组件会根据Service的配置，利用iptables或ipvs规则（经过DNAT转换），将请求流量分发到后端的Pod上。kube-proxy 监听到 Service 变化后，通过调用 iptables 的 API，在宿主机上为该 Service 设置一系列转发规则。当客户端请求到达 Service 的虚拟 IP 时，IPVS 根据配置的负载均衡算法，将请求分发到后端合适的 Pod，实现高效的服务负载均衡。Service稳定提供VIP）

2026-01-22 09:22:21 563

原创 K8S对象-Service(iptables rules)

•kube-proxy 监听到 Service 变化后，通过调用 iptables 的 API，在宿主机上为该 Service 设置一系列转发规则。•当客户端请求到达 Service 的虚拟 IP 时，IPVS 根据配置的负载均衡算法，将请求分发到后端合适的 Pod，实现高效的服务负载均衡。•这些规则会将发送到 Service 虚拟 IP 的流量，随机重定向到后端某个 Pod 的 IP 和端口上，实现负载均衡。•负载均衡策略：默认情况下，Service 采用随机选择的方式将流量分发到各个后端 Pod。

2026-01-22 09:21:46 532

原创 K8S 网络限制的实现原理（NetworkPolicy api对象）

K8S的 Pod 默认网络 "允许所有"Pod 被 NetworkPolicy 对象选中，就会进入黑洞，无法对外访问无法接收请求。： K8S的CNI插件支持NetworkPolicy对象，才可在集群中使用黑洞开窗：设置白名单 policyTypes字段。

2026-01-21 09:11:44 292

原创依据Flannel和Calico项目，总结差异

flannel触发CNI插件生成 flannel0 TUN 设备[IP层]CNI插件生成的veth pair作为容器和宿主机之间的网线网线连接的：容器eth0 路由到docker0网桥路由到flannel0 flannel0 依据路由转发到docker0。

2026-01-21 09:10:24 507

原创跨主机的网络实现-Calico IPIP模式 (类似flannel host-gw)

BGP mesh，即 IBGP 全互联，是指在一个 AS（自治系统）内部，所有 BGP 路由器之间两两建立 IBGP 对等体关系。根据 BGP 协议规则，从 IBGP 对等体学到的路由不会再传递给其他 IBGP 对等体（即“IBGP 水平分割”规则）。每个路由器都直接与其他所有路由器交换路由信息。

2026-01-20 09:21:57 637

原创跨主机的网络实现-Calico node-to-node模式 (类似flannel host-gw)

Calico 项目使用了BGP（边界网关协议）BGP ：是linux内核原生支持的专门用于在大规模数据中心维护不同"自制系统"之间路由信息无中心的路由协议。BGP在大规模网络中实现节点路由信息共享的协议简述BGP原理：每个边界网关上运行一个程序，将程序内的路由表信息通过TCP方式传输到其他的边界网关。其他的边界网关分析接收到的数据，增加路由到自身的路由表。并共享到其他的边界网关自治系统：相当于一整个公司的所有主机路由器交换机默认下，自治系统间不通。

2026-01-20 09:21:31 639

原创跨主机的网络实现-Flannel host-gw模式

host-gw模式是Flannel的一种网络后端实现，核心原理是通过在每个节点上维护静态路由表，将容器网络（10.244.0.0/16）的不同子网直接映射到目标节点的物理IP地址。当跨节点容器通信时，数据包通过宿主机的物理网卡直接转发，无需额外封装（如vxlan隧道），因此具有较高的网络性能。

2026-01-19 09:16:00 640

原创 K8S创建pod，CNI插件的网络配置过程

（5.2.2）在Calico项目中，CNI插件生成的veth pair设备一端连接容器的eth0，另一端连接宿主机的以cali开头的虚拟网卡。第一个创建的一定是 Infra 容器。host-local：从预定义的IP池（如`10.244.0.0/16`）中分配IP，并在本地文件（如`/var/lib/cni/networks/`）记录IP使用状态，避免冲突。CRI读取`/etc/cni/net.d/`目录下的配置文件，解析插件类型（如`calico`、`flannel`）和参数。

2026-01-19 09:13:42 545

原创 K8S容器网络插件 - CNI

Flannel 的 CNI 配置文件（/etc/cni/net.d/10-flannel.conflist）里有一个字段，叫作 delegate：

2026-01-16 09:24:52 617

原创跨主机的网络实现-Flannel-Vxlan模式

vxlan：虚拟可扩展局域网。vxlan本身就是linux内核的模块（vlan模式下解决内核态和用户态的转换）vxlan 涉及思路：在三层的网络上覆盖一层虚拟的二层网络（隧道）所有在vxlan二层网络的主机虚拟机容器之间像是在一个局域网内部vxlan 的网络设备： VTEP 虚拟隧道端点（IP地址 MAC地址都有）

2026-01-16 09:24:39 532

原创跨主机的网络实现-Flannel DUP模式

不同的主机间容器仅仅通过IP是无法连通的，连通的关键在于主机间建立一个无形的网络隧道。flannel是CoreOS公司主推的容器网络方案（flannel0 有子网ip地址）flannel项目本身仅仅是一个框架，真正提供容器网络功能的是后端实现： VXLAN host-gw UDP(已经被弃用)

2026-01-15 13:42:35 275

原创跨节点的容器间网络通信

本文分析了跨节点容器通信中flannel网络的工作流程。数据包从源容器eth0发出后，依次经过docker网桥、宿主机路由表到达flannel0网卡，由flanneld程序进行UDP封装后发送至目标节点。目标节点的flanneld接收并解封装数据包，最终通过路由表将数据包传递至目标容器。整个过程实现了容器间跨主机的网络通信，flanneld动态维护路由规则确保了通信的可靠性。

2026-01-14 09:07:43 26

原创同宿主机下同命名空间的容器间网络通信

解决方案：合理安排容器的启动顺序，可以通过编写脚本或使用容器编排工具（如 Docker Compose）来管理容器的启动依赖关系，确保被依赖的容器先启动。由于共享网络命名空间，数据会直接在该命名空间内的网络协议栈中进行处理，无需经过宿主机的网络协议栈转发，然后被接收方容器的进程接收。：对于一些简单的应用组合，将相关容器部署在同一网络命名空间内，可以快速实现它们之间的通信，简化了应用的部署和维护流程。：在微服务架构中，一些紧密耦合的微服务组件可以部署在同一网络命名空间内，实现高效的通信，提高整个系统的性能。

2026-01-14 09:07:08 592

K8S-容器的网络简单介绍

空空如也