名字空间演练

Kubernetes 名字空间 有助于不同的项目、团队或客户去共享 Kubernetes 集群。

名字空间通过以下方式实现这点:

  1. 名字设置作用域.
  2. 为集群中的部分资源关联鉴权和策略的机制。

使用多个名字空间是可选的。

此示例演示了如何使用 Kubernetes 名字空间细分群集。

准备开始

你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 如果你还没有集群,你可以通过 Minikube 构建一 个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:

要获知版本信息,请输入 kubectl version.

环境准备

此示例作如下假设:

  1. 你已拥有一个配置好的 Kubernetes 集群
  2. 你已对 Kubernetes 的 PodsServicesDeployments 有基本理解。

  3. 理解默认名字空间

默认情况下,Kubernetes 集群会在配置集群时实例化一个默认名字空间,用以存放集群所使用的默认 Pod、Service 和 Deployment 集合。

假设你有一个新的集群,你可以通过执行以下操作来检查可用的名字空间:

  1. kubectl get namespaces
  1. NAME STATUS AGE
  2. default Active 13m

创建新的名字空间

在本练习中,我们将创建两个额外的 Kubernetes 名字空间来保存我们的内容。

我们假设一个场景,某组织正在使用共享的 Kubernetes 集群来支持开发和生产:

开发团队希望在集群中维护一个空间,以便他们可以查看用于构建和运行其应用程序的 Pod、Service 和 Deployment 列表。在这个空间里,Kubernetes 资源被自由地加入或移除, 对谁能够或不能修改资源的限制被放宽,以实现敏捷开发。

运维团队希望在集群中维护一个空间,以便他们可以强制实施一些严格的规程, 对谁可以或谁不可以操作运行生产站点的 Pod、Service 和 Deployment 集合进行控制。

该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个名字空间:developmentproduction

让我们创建两个新的名字空间来保存我们的工作。

文件 namespace-dev.json 描述了 development 名字空间:

admin/namespace-dev.json 名字空间演练 - 图1

  1. {
  2. "apiVersion": "v1",
  3. "kind": "Namespace",
  4. "metadata": {
  5. "name": "development",
  6. "labels": {
  7. "name": "development"
  8. }
  9. }
  10. }

使用 kubectl 创建 development 名字空间。

  1. kubectl create -f https://k8s.io/examples/admin/namespace-dev.json

将下列的内容保存到文件 namespace-prod.json 中, 这些内容是对 production 名字空间的描述:

admin/namespace-prod.json 名字空间演练 - 图2

  1. {
  2. "apiVersion": "v1",
  3. "kind": "Namespace",
  4. "metadata": {
  5. "name": "production",
  6. "labels": {
  7. "name": "production"
  8. }
  9. }
  10. }

让我们使用 kubectl 创建 production 名字空间。

  1. kubectl create -f https://k8s.io/examples/admin/namespace-prod.json

为了确保一切正常,我们列出集群中的所有名字空间。

  1. kubectl get namespaces --show-labels
  1. NAME STATUS AGE LABELS
  2. default Active 32m <none>
  3. development Active 29s name=development
  4. production Active 23s name=production

在每个名字空间中创建 pod

Kubernetes 名字空间为集群中的 Pod、Service 和 Deployment 提供了作用域。

与一个名字空间交互的用户不会看到另一个名字空间中的内容。

为了演示这一点,让我们在 development 名字空间中启动一个简单的 Deployment 和 Pod。

我们首先检查一下当前的上下文:

  1. kubectl config view
  1. apiVersion: v1
  2. clusters:
  3. - cluster:
  4. certificate-authority-data: REDACTED
  5. server: https://130.211.122.180
  6. name: lithe-cocoa-92103_kubernetes
  7. contexts:
  8. - context:
  9. cluster: lithe-cocoa-92103_kubernetes
  10. user: lithe-cocoa-92103_kubernetes
  11. name: lithe-cocoa-92103_kubernetes
  12. current-context: lithe-cocoa-92103_kubernetes
  13. kind: Config
  14. preferences: {}
  15. users:
  16. - name: lithe-cocoa-92103_kubernetes
  17. user:
  18. client-certificate-data: REDACTED
  19. client-key-data: REDACTED
  20. token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
  21. - name: lithe-cocoa-92103_kubernetes-basic-auth
  22. user:
  23. password: h5M0FtUUIflBSdI7
  24. username: admin
  1. kubectl config current-context
  1. lithe-cocoa-92103_kubernetes

下一步是为 kubectl 客户端定义一个上下文,以便在每个名字空间中工作。 “cluster” 和 “user” 字段的值将从当前上下文中复制。

  1. kubectl config set-context dev --namespace=development \
  2. --cluster=lithe-cocoa-92103_kubernetes \
  3. --user=lithe-cocoa-92103_kubernetes
  4. kubectl config set-context prod --namespace=production \
  5. --cluster=lithe-cocoa-92103_kubernetes \
  6. --user=lithe-cocoa-92103_kubernetes

默认情况下,上述命令会添加两个上下文到 .kube/config 文件中。 你现在可以查看上下文并根据你希望使用的名字空间并在这两个新的请求上下文之间切换。

查看新的上下文:

  1. kubectl config view
  1. apiVersion: v1
  2. clusters:
  3. - cluster:
  4. certificate-authority-data: REDACTED
  5. server: https://130.211.122.180
  6. name: lithe-cocoa-92103_kubernetes
  7. contexts:
  8. - context:
  9. cluster: lithe-cocoa-92103_kubernetes
  10. user: lithe-cocoa-92103_kubernetes
  11. name: lithe-cocoa-92103_kubernetes
  12. - context:
  13. cluster: lithe-cocoa-92103_kubernetes
  14. namespace: development
  15. user: lithe-cocoa-92103_kubernetes
  16. name: dev
  17. - context:
  18. cluster: lithe-cocoa-92103_kubernetes
  19. namespace: production
  20. user: lithe-cocoa-92103_kubernetes
  21. name: prod
  22. current-context: lithe-cocoa-92103_kubernetes
  23. kind: Config
  24. preferences: {}
  25. users:
  26. - name: lithe-cocoa-92103_kubernetes
  27. user:
  28. client-certificate-data: REDACTED
  29. client-key-data: REDACTED
  30. token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
  31. - name: lithe-cocoa-92103_kubernetes-basic-auth
  32. user:
  33. password: h5M0FtUUIflBSdI7
  34. username: admin

让我们切换到 development 名字空间进行操作。

  1. kubectl config use-context dev

你可以使用下列命令验证当前上下文:

  1. kubectl config current-context
  1. dev

此时,我们从命令行向 Kubernetes 集群发出的所有请求都限定在 development 名字空间中。

让我们创建一些内容。

admin/snowflake-deployment.yaml 名字空间演练 - 图3

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. labels:
  5. app: snowflake
  6. name: snowflake
  7. spec:
  8. replicas: 2
  9. selector:
  10. matchLabels:
  11. app: snowflake
  12. template:
  13. metadata:
  14. labels:
  15. app: snowflake
  16. spec:
  17. containers:
  18. - image: k8s.gcr.io/serve_hostname
  19. imagePullPolicy: Always
  20. name: snowflake

应用清单文件来创建 Deployment。

我们刚刚创建了一个副本大小为 2 的 Deployment,该 Deployment 运行名为 snowflake 的 Pod, 其中包含一个仅提供主机名服务的基本容器。

  1. kubectl get deployment
  1. NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
  2. snowflake 2 2 2 2 2m
  1. kubectl get pods -l app=snowflake
  1. NAME READY STATUS RESTARTS AGE
  2. snowflake-3968820950-9dgr8 1/1 Running 0 2m
  3. snowflake-3968820950-vgc4n 1/1 Running 0 2m

这很棒,开发人员可以做他们想要的事情,而不必担心影响 production 名字空间中的内容。

让我们切换到 production 名字空间,展示一个名字空间中的资源如何对另一个名字空间不可见。

  1. kubectl config use-context prod

production 名字空间应该是空的,下列命令应该返回的内容为空。

  1. kubectl get deployment
  2. kubectl get pods

生产环境需要以放牛的方式运维,让我们创建一些名为 cattle 的 Pod。

  1. kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname --replicas=5
  2. kubectl get deployment
  1. NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
  2. cattle 5 5 5 5 10s
  1. kubectl get pods -l run=cattle
  1. NAME READY STATUS RESTARTS AGE
  2. cattle-2263376956-41xy6 1/1 Running 0 34s
  3. cattle-2263376956-kw466 1/1 Running 0 34s
  4. cattle-2263376956-n4v97 1/1 Running 0 34s
  5. cattle-2263376956-p5p3i 1/1 Running 0 34s
  6. cattle-2263376956-sxpth 1/1 Running 0 34s

此时,应该很清楚的展示了用户在一个名字空间中创建的资源对另一个名字空间是不可见的。

随着 Kubernetes 中的策略支持的发展,我们将扩展此场景,以展示如何为每个名字空间提供不同的授权规则。