Linux K8s如何实现资源隔离
小樊
36
2025-12-14 10:32:27
Linux K8s资源隔离的实现路径
一 核心机制总览
- 在 Linux 内核层面,容器隔离依赖 Namespace(隔离进程视图:网络、挂载、PID、IPC 等)与 cgroups(限制与计量 CPU、内存、IO 等资源)。Kubernetes 在此基础上提供面向集群的租户与资源治理抽象:Namespace、RBAC、ResourceQuota、LimitRange、Pod QoS、节点亲和/污点与容忍、NetworkPolicy、安全上下文 等,从而实现工作负载之间在资源、权限与网络层面的隔离与可控共享。
二 计算资源隔离
- 请求与限额
- 在 Pod/容器 上设置 requests/limits,调度器基于 requests 选择节点,运行时通过 cgroups 强制 limits,从而实现可压缩资源(如 CPU)与不可压缩资源(如 内存)的用量上限与调度保障。示例:
- resources.requests.cpu: 250m;resources.limits.cpu: 500m
- resources.requests.memory: 300Mi;resources.limits.memory: 400Mi
- 单位要点:CPU 的 m 表示千分之一核(1000m=1 核);内存可用 Mi/Gi。
- 命名空间级配额与默认限额
- 使用 ResourceQuota 限制命名空间总量(如 pods、requests/limits.cpu、requests/limits.memory、requests.storage 等),防止租户/团队之间资源抢占。
- 使用 LimitRange 为 Pod/容器 设置默认 requests/limits、最小/最大值及 limit/request 比例,避免“无限制”与配置不一致。
- Pod 的 QoS 类别
- 依据 requests/limits 的组合,K8s 将 Pod 划分为 Guaranteed/Burstable/BestEffort,在节点资源紧张与驱逐时具有不同的优先级与保护策略,进一步保障关键负载的稳定性。
三 节点与拓扑隔离
- 节点资源预留与可分配量
- kubelet 通过 KubeReserved、SystemReserved、EvictionThreshold 等参数从节点 Capacity 中切分出 Allocatable,调度与分配均以 Allocatable 为边界,避免系统组件与业务互相挤占。
- 亲和/反亲和与污点/容忍
- 通过 nodeSelector/nodeAffinity 将负载约束到具备特定标签/拓扑(如 disk=ssd)的节点,实现性能/硬件隔离。
- 通过 taint/toleration 为专用节点(如监控/管理)打污点,仅允许带相应容忍的 Pod 调度其上,形成物理或逻辑专池。
- 拓扑分散与干扰隔离
- 使用 podAntiAffinity 将关键负载分散到不同节点,降低单点故障与“吵闹邻居”影响。
四 网络与存储隔离
- 网络隔离
- Namespace 之间网络默认互通,使用 NetworkPolicy 可按 Pod/Namespace 标签精细控制 Ingress/Egress,实现命名空间内互通、跨命名空间隔离、默认拒绝等策略;结合 Service 的 DNS 全域名 ..svc.cluster.local 进行跨命名空间访问治理。
- 存储隔离
- 通过 PV/PVC/StorageClass 将存储供给与租户解耦;在 ResourceQuota 中限制 requests.storage 与 .storageclass.storage.k8s.io/requests.storage,避免某租户耗尽共享存储。
- 多租户场景下建议禁用 hostPath 等本地卷,降低跨租户数据泄露与节点本地资源滥用风险;对共享存储启用合适的 ReclaimPolicy 与访问控制。
五 权限边界与多租户实践
- 权限边界
- 以 Namespace 为边界,结合 RBAC(Role/RoleBinding/ClusterRole/ClusterRoleBinding) 控制“谁能对哪些资源在哪些命名空间执行哪些操作”,实现管理面隔离与最小权限。
- 多租户方案选择
- 按 Namespace 划分租户:轻量、灵活,适合多团队共享集群;需配合 Quota/LimitRange/NetworkPolicy 等策略形成“软多租”。
- 虚拟控制平面:为每个租户提供独立 apiserver(如 vcluster),隔离更强、边界更清晰,适合对外服务或多客户场景,代价是控制面开销与运维复杂度上升。
- 多集群:隔离性最强、运维边界清晰,但资源与运维成本更高;适合强合规/强安全诉求或客户完全隔离的场景。