名字空间演练

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

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

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

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

    你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程，且这些节点不作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：

    要获知版本信息，请输入 .

    此示例作如下假设：

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

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

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

    1. NAME      STATUS    AGE
    2. default   Active    13m

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

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

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

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

    该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个名字空间：development 和 production。

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

    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 名字空间的描述：

    名字空间演练 - 图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. NAME          STATUS    AGE       LABELS
      2. default       Active    32m       <none>
      3. development   Active    29s       name=development
      4. production    Active    23s       name=production

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

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

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

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

      1. kubectl config view
      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
      5. kubectl config set-context prod --namespace=production \
      6.   --cluster=lithe-cocoa-92103_kubernetes \
      7.   --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. current-context: lithe-cocoa-92103_kubernetes
      22. kind: Config
      23. preferences: {}
      24. users:
      25. - name: lithe-cocoa-92103_kubernetes
      27.     client-certificate-data: REDACTED
      28.     client-key-data: REDACTED
      29.     token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
      30. - name: lithe-cocoa-92103_kubernetes-basic-auth
      31.   user:
      32.     password: h5M0FtUUIflBSdI7
      33.     username: admin

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

      1. kubectl config use-context dev

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

      1. kubectl config current-context
      1. dev

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

      让我们创建一些内容。

      应用清单文件来创建 Deployment。

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

      1. kubectl get deployment
      1. NAME         READY   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         READY   UP-TO-DATE   AVAILABLE   AGE
      2. cattle       5/5     5            5           10s
      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

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

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