温馨提示×

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 等),防止租户/团队之间资源抢占。
    • 使用 LimitRangePod/容器 设置默认 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,实现命名空间内互通、跨命名空间隔离、默认拒绝等策略;结合 ServiceDNS 全域名 ..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),隔离更强、边界更清晰,适合对外服务或多客户场景,代价是控制面开销与运维复杂度上升。
    • 多集群:隔离性最强、运维边界清晰,但资源与运维成本更高;适合强合规/强安全诉求或客户完全隔离的场景。

0