通过名字空间共享集群

    查看名字空间

    1. 列出集群中现有的名字空间：
    2. default       Active    11d
    3. kube-system   Active    11d
    4. kube-public   Active    11d

    初始状态下，Kubernetes 具有三个名字空间：

    • default 无名字空间对象的默认名字空间
    • kube-system 由 Kubernetes 系统创建的对象的名字空间
    • kube-public 自动创建且被所有用户可读的名字空间（包括未经身份认证的）。此名字空间通常在某些资源在整个集群中可见且可公开读取时被集群使用。此名字空间的公共方面只是一个约定，而不是一个必要条件。

    你还可以通过下列命令获取特定名字空间的摘要：

    1. kubectl get namespaces <name>

    或用下面的命令获取详细信息：

    1. kubectl describe namespaces <name>
    1. Name:           default
    2. Labels:         <none>
    3. Annotations:    <none>
    4. Status:         Active
    6. No resource quota.
    8. Resource Limits
    9.  ----               --------    --- --- ---
    10.  Container          cpu         -   -   100m

    请注意，这些详情同时显示了资源配额（如果存在）以及资源限制区间。

    资源配额跟踪并聚合 Namespace 中资源的使用情况，并允许集群运营者定义 Namespace 可能消耗的 Hard 资源使用限制。

    限制区间定义了单个实体在一个 Namespace 中可使用的最小/最大资源量约束。

    参阅

    名字空间可以处于下列两个阶段中的一个:

    • Active 名字空间正在被使用中
    • Terminating 名字空间正在被删除，且不能被用于新对象。

    更多细节，参阅 API 参考中的命名空间。

    说明： 避免使用前缀 kube- 创建名字空间，因为它是为 Kubernetes 系统名字空间保留的。

    1. 新建一个名为 的 YAML 文件，并写入下列内容：

      1. apiVersion: v1
      2. kind: Namespace
      3. metadata:
      4.   name: <insert-namespace-name-here>

      然后运行：

      1. kubectl create -f ./my-namespace.yaml

    2. 或者，你可以使用下面的命令创建名字空间：

      1. kubectl create namespace <insert-namespace-name-here>

    请注意，名字空间的名称必须是一个合法的 。

    可选字段 finalizers 允许观察者们在名字空间被删除时清除资源。记住如果指定了一个不存在的终结器，名字空间仍会被创建，但如果用户试图删除它，它将陷入 Terminating 状态。

    更多有关 finalizers 的信息请查阅 设计文档 中名字空间部分。

    删除名字空间

    删除名字空间使用命令：

    删除是异步的，所以有一段时间你会看到名字空间处于 Terminating 状态。

    1. 理解 default 名字空间

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

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

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

    2. 创建新的名字空间

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

      在某组织使用共享的 Kubernetes 集群进行开发和生产的场景中：

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

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

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

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

      使用 kubectl 创建 development 名字空间。

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

      让我们使用 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

    3. 在每个名字空间中创建 pod

      Kubernetes 名字空间为集群中的 Pods、Services 和 Deployments 提供了作用域。

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

      1. kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development
      2. kubectl scale deployment snowflake --replicas=2 -n=development

      我们创建了一个副本个数为 2 的 Deployment，运行名为 snowflake 的 Pod，其中包含一个负责提供主机名的基本容器。

      1. NAME         READY   UP-TO-DATE   AVAILABLE   AGE
      1. kubectl get pods -l app=snowflake -n=development
      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 名字空间，展示一下一个名字空间中的资源是如何对 另一个名字空间隐藏的。

      名字空间 production 应该是空的，下面的命令应该不会返回任何东西。

      1. kubectl get deployment -n=production
      2. kubectl get pods -n=production

      生产环境下一般以养牛的方式运行负载，所以让我们创建一些 Cattle（牛）Pod。

      1. kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production
      2. kubectl scale deployment cattle --replicas=5 -n=production
      4. kubectl get deployment -n=production
      1. NAME         READY   UP-TO-DATE   AVAILABLE   AGE
      2. cattle       5/5     5            5           10s
      1. kubectl get pods -l app=cattle -n=production

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

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

    理解使用名字空间的动机

    单个集群应该能满足多个用户及用户组的需求（以下称为 “用户社区”）。

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

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

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

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

    每个用户社区都希望能够与其他社区隔离开展工作。

    每个用户社区都有自己的：

    1. 资源（pods、服务、 副本控制器等等）
    2. 策略（谁能或不能在他们的社区里执行操作）
    3. 约束（该社区允许多少配额，等等）

    集群运营者可以为每个唯一用户社区创建名字空间。

    名字空间为下列内容提供唯一的作用域：

    1. 命名资源（避免基本的命名冲突）
    2. 将管理权限委派给可信用户
    3. 限制社区资源消耗的能力

    用例包括:

    1. 作为集群运营者, 我希望能在单个集群上支持多个用户社区。
    2. 作为集群运营者，我希望将集群分区的权限委派给这些社区中的受信任用户。
    3. 作为集群运营者，我希望能限定每个用户社区可使用的资源量，以限制对使用同一集群的其他用户社区的影响。
    4. 作为集群用户，我希望与我的用户社区相关的资源进行交互，而与其他用户社区在该集群上执行的操作无关。

    当你创建服务时，Kubernetes 会创建相应的 。 此条目的格式为 <服务名称>.<名字空间名称>.svc.cluster.local。 这意味着如果容器使用 ，它将解析为名字空间本地的服务。 这对于在多个名字空间（如开发、暂存和生产）中使用相同的配置非常有用。 如果要跨名字空间访问，则需要使用完全限定的域名（FQDN）。

    接下来