正文

Kubernetes多租户隔离实战从Namespace到ResourceQuota解决资源争抢与安全风险让6岁小孩也能懂集群管理

/0 浏览量
0626

想象一下，你有一个超级大的乐高城堡，里面住着很多小朋友。有的小朋友喜欢搭高楼，有的喜欢挖地道，还有的喜欢摆弄小汽车。如果所有小朋友都在同一个房间里，没有规则，会发生什么？

那个想搭高楼的小朋友可能会不小心踩坏别人的作品，或者把所有积木都抢到自己手里，导致其他人没得玩。更糟糕的是，如果有个调皮的小朋友想往城堡里放一个会爆炸的小烟花（这在电脑世界里叫“恶意软件”或“病毒”），整个城堡可能都会塌掉！

Kubernetes（简称 K8s）就是这样一个巨大的乐高城堡，而我们要做的，就是给每个小朋友分配独立的房间、限定的积木数量，以及安全的围墙。这就是多租户隔离。今天，我们就用最简单的话，聊聊怎么把这个大城堡管理得井井有条。

第一层保护：给每个孩子分房间（Namespace）

首先，我们得把大城堡分成几个小房间。在 Kubernetes 里，这个“房间”叫做 Namespace（命名空间）。

为什么需要房间？

假设公司里有“财务部”和“游戏开发部”。财务部的数据不能随便让游戏开发人员看到，对吧？通过 Namespace，我们可以把这两个部门的数据完全分开。即使两个部门都创建一个叫 app-db 的数据库，因为它们在不同的房间（Namespace）里，所以互不干扰。

怎么分房间？

这就像是在城堡墙上画线。你可以告诉 Kubernetes：“这里是财务部的房间，那里是游戏部的房间。”

# 创建财务部的房间
apiVersion: v1
kind: Namespace
metadata:
  name: finance-team
  labels:
    team: finance

# 创建游戏开发部的房间
apiVersion: v1
kind: Namespace
metadata:
  name: game-dev
  labels:
    team: game

看，是不是很简单？现在，财务部的小朋友只能在 finance-team 房间里玩，游戏部的小朋友只能在 game-dev 房间里玩。他们看不见对方在干什么，这就解决了隐私安全的第一大问题。

第二层保护：限制积木的数量（ResourceQuota）

分好房间后，新问题来了：如果财务部的小朋友特别贪心，他想用所有的积木来搭一座巨大的金字塔，把游戏部小朋友的积木都用光了怎么办？这时候，我们需要一个“积木管理员”，这个角色就是 ResourceQuota（资源配额）。

ResourceQuota 是什么？

它就像一个智能盒子，放在每个房间里。盒子外面写着：“这个房间最多只能有 100 块红色积木，50 块蓝色积木。” 如果小朋友想拿第 101 块红色积木，盒子就会说：“不行哦，积木用完了！”

如何设置积木数量？

在 Kubernetes 里，积木不是红色的，而是 CPU 和内存。CPU 就像是小朋友的大脑速度，内存就像是小朋友的短期记忆大小。

# 在财务部的房间里设置积木配额
apiVersion: v1
kind: ResourceQuota
metadata:
  name: finance-quota
  namespace: finance-team
spec:
  hard:
    # 总共只能用 4 核 CPU
    requests.cpu: "4"
    # 总共只能用 8GB 内存
    requests.memory: 8Gi
    # 总共只能运行 10 个应用（Pod）
    count/pods: "10"
    # 限制存储卷的大小
    requests.storage: 50Gi

现在，即使财务部的小朋友想跑 20 个应用，Kubernetes 也会阻止他，因为配额只允许 10 个。这样，游戏部的资源就不会被抢走了。资源争抢问题，就这样被轻松解决了。

第三层保护：检查每个人的作业（LimitRange）

有了总配额还不够，万一财务部只有一个小朋友，但他想一个人用掉所有的 4 核 CPU 和 8GB 内存呢？那其他小朋友就没法玩了。所以，我们还需要更细致的规则：LimitRange（限制范围）。

LimitRange 的作用

它规定：“每个小朋友每次最多只能用 1 核 CPU 和 2GB 内存。” 这样，即使只有一个人，他也无法独占所有资源。

# 设置每个 Pod 的最大和最小资源
apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: finance-team
spec:
  limits:
    # 默认限制
    - type: Container
      max:
        cpu: "2"
        memory: 4Gi
      min:
        cpu: "100m"
        memory: 64Mi
      default:
        cpu: "500m"
        memory: 1Gi
      defaultRequest:
        cpu: "200m"
        memory: 256Mi

这样，每个小朋友的作业都会被限制在一个合理的范围内，既不会太小浪费资源，也不会太大抢走别人的东西。

第四层保护：安装监控摄像头（NetworkPolicy）

房间分好了，积木也限制了，但还有一个风险：如果一个小朋友想偷偷溜进隔壁房间偷看怎么办？或者，如果财务部的小朋友被黑客控制了，他想攻击游戏部的服务器呢？

这时候，我们需要网络策略，也就是 NetworkPolicy。它就像是城堡里的保安和监控摄像头，只允许特定的小朋友互相交流。

如何设置保安规则？

我们可以规定：“财务部的小朋友只能和财务部的数据库说话，不能和游戏部的小朋友说话。”

# 在财务部房间安装保安规则
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: finance-deny-all
  namespace: finance-team
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
---
# 允许财务部内部的 Pod 互相通信
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: finance-allow-internal
  namespace: finance-team
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}
  policyTypes:
  - Ingress

这段代码的意思是：首先，默认拒绝所有入站流量（保安不让陌生人进来）；然后，允许财务部内部的所有 Pod 互相通信（同事之间可以聊天）。这样就防止了跨部门的恶意攻击。

第五层保护：身份验证与授权（RBAC）

最后，我们还得确保只有真正的小朋友才能进入城堡，而且只能做他们该做的事。这就是 RBAC（基于角色的访问控制）。

RBAC 是什么？

想象一下，财务部的小朋友有“查看账本”的权限，但没有“修改账本”的权限；而游戏部的小朋友有“搭建积木”的权限，但没有“查看账本”的权限。

# 创建一个角色，允许查看财务部的 Pod
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: finance-reader
  namespace: finance-team
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]
---
# 把这个角色授予财务部的小明
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-finance-reader-to-xiaoming
  namespace: finance-team
subjects:
- kind: User
  name: xiaoming
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-reader
  apiGroup: rbac.authorization.k8s.io

现在，小明只能查看财务部的 Pod 和服务，不能删除它们，也不能访问游戏部的任何东西。这样，即使小明是个调皮的孩子，他也破坏不了整个城堡。

总结：给6岁小孩听的城堡故事

好了，让我们回顾一下这个乐高城堡的故事：

  1. Namespace（房间）：我们给每个部门分了不同的房间，大家互不干扰，隐私得到保护。
  2. ResourceQuota（总积木盒）：我们给每个房间设定了积木总数，防止有人贪心用光所有资源。
  3. LimitRange（单个积木限制）：我们规定每个人每次能用多少积木，防止单人独占。
  4. NetworkPolicy（保安）：我们设置了保安，只允许特定的人交流，防止外人入侵。
  5. RBAC（权限卡）：我们给每个人发了不同的权限卡，只能做他们该做的事。

通过这些步骤，我们的 Kubernetes 城堡就变得既安全又高效。每个小朋友都能在自己的房间里开心地玩耍，不用担心资源被抢，也不用害怕别人捣乱。

实际场景：一家电商公司的实践

让我们看看一家真实的电商公司是怎么用这些技术的。

背景

这家公司有三个团队：

  • 前端团队：负责网站页面。
  • 后端团队：负责订单处理。
  • 数据团队：负责分析用户行为。

挑战

  1. 数据团队在进行大规模数据分析时，占用了大量 CPU 和内存，导致前端网站变慢。
  2. 后端团队的订单服务突然崩溃，影响了整个系统的稳定性。
  3. 有一次，前端团队的一个测试账号泄露，被黑客利用，尝试访问后端数据库。

解决方案

  1. 分房间：为每个团队创建独立的 Namespace：frontend, backend, data-analytics。
  2. 设配额：
    • frontend：限制 2 核 CPU，4GB 内存，最多 5 个 Pod。
    • backend：限制 4 核 CPU，8GB 内存，最多 10 个 Pod。
    • data-analytics：限制 8 核 CPU，16GB 内存，最多 3 个 Pod（因为分析任务少但重）。
  3. 设网络策略：
    • frontend 只能访问 backend 的 API 服务。
    • data-analytics 只能访问 backend 的只读数据库副本。
    • backend 不能直接访问 data-analytics 的内部数据。
  4. 设 RBAC：
    • 前端工程师只能查看和管理 frontend 命名空间的资源。
    • 数据科学家只能查看和管理 data-analytics 命名空间的资源。
    • 运维人员拥有所有命名空间的只读权限，用于监控。

结果

  • 当数据团队进行大规模分析时，他们的资源使用被限制在 8 核 CPU 以内，不会影响前端的响应速度。
  • 后端服务的崩溃被隔离在 backend 命名空间内，前端网站依然正常运行。
  • 即使前端账号泄露，黑客也无法访问后端数据库，因为网络策略阻止了跨命名空间的访问。

给家长的建议：如何教孩子理解 Kubernetes

如果你家里有小朋友对电脑感兴趣，你可以这样教他们：

  1. 用玩具比喻：用乐高积木演示 Namespace 和 ResourceQuota。给孩子一堆积木，告诉他：“这是你的房间，你只能用这么多积木。”
  2. 玩游戏：玩“警察和小偷”的游戏，演示 NetworkPolicy。警察（安全规则）只能抓小偷（恶意流量），不能抓好人（正常流量）。
  3. 讲故事：编一个关于城堡的故事，每个角色代表一个 Kubernetes 组件。让孩子扮演角色，体验隔离和安全的重要性。

记住，Kubernetes 并不是什么高深莫测的黑科技，它只是帮助我们更好地管理资源、提高安全性和效率的工具。就像我们管理自己的房间一样，只要规则清晰，每个人都能玩得开心。

希望这个故事能让你对 Kubernetes 多租户隔离有更深的理解。如果你有任何问题，欢迎随时问我！

-- 展开阅读全文 --