From a4d9736bfead80b5b37dda9c42c491016b2d3872 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=9D=A8=E6=99=B4?= Date: Sun, 23 Jun 2019 21:47:54 +0800 Subject: [PATCH] zh-trans: add /content/zh/docs/tasks/administer-cluster/namespaces.md (#14934) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * zh-trans: add /content/zh/docs/tasks/administer-cluster/namespaces.md * 补充缺失文件 --- .../tasks/administer-cluster/namespaces.md | 558 ++++++++++++++++++ content/zh/examples/admin/namespace-dev.json | 10 + content/zh/examples/admin/namespace-prod.json | 10 + 3 files changed, 578 insertions(+) create mode 100644 content/zh/docs/tasks/administer-cluster/namespaces.md create mode 100644 content/zh/examples/admin/namespace-dev.json create mode 100644 content/zh/examples/admin/namespace-prod.json diff --git a/content/zh/docs/tasks/administer-cluster/namespaces.md b/content/zh/docs/tasks/administer-cluster/namespaces.md new file mode 100644 index 0000000000..6866bbbc71 --- /dev/null +++ b/content/zh/docs/tasks/administer-cluster/namespaces.md @@ -0,0 +1,558 @@ +--- +reviewers: +- derekwaynecarr +- janetkuo +title: 通过命名空间共享集群 +content_template: templates/task +--- + + +{{% capture overview %}} + + +本页展示了如何查看、使用和删除{{< glossary_tooltip text="namespaces" term_id="namespace" >}}。本页同时展示了如何使用 Kubernetes 命名空间去细分集群。 + +{{% /capture %}} + +{{% capture prerequisites %}} + + +* 您已拥有一个 [配置好的 Kubernetes 集群](/docs/setup/). +* 您已对 Kubernetes 的 _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, 和 _[Deployments](/docs/concepts/workloads/controllers/deployment/)_ 有基本理解。 + +{{% /capture %}} + +{{% capture steps %}} + + + +## 查看命名空间 + + + +1. 列出集群中现有的命名空间: + +```shell +kubectl get namespaces +``` +``` +NAME STATUS AGE +default Active 11d +kube-system Active 11d +kube-public Active 11d +``` + + + +初始状态下,Kubernetes 具有三个名字空间: + + + + * `default` 无命名空间对象的默认命名空间 + * `kube-system` 由 Kubernetes 系统创建的对象的命名空间 + * `kube-public` 自动创建且被所有用户可读的命名空间(包括未经身份认证的)。此命名空间通常在某些资源在整个集群中可见且可公开读取时被集群使用。此命名空间的公共方面只是一个约定,而不是一个必要条件。 + + + +您还可以通过下列命令获取特定命名空间的摘要: + +```shell +kubectl get namespaces +``` + + + +或获取详细信息: + +```shell +kubectl describe namespaces +``` +``` +Name: default +Labels: +Annotations: +Status: Active + +No resource quota. + +Resource Limits + Type Resource Min Max Default + ---- -------- --- --- --- + Container cpu - - 100m +``` + + + +请注意,这些详情同时显示了资源配额(如果存在)以及资源限制区间。 + + + +资源配额跟踪并聚合 *Namespace* 中资源的使用情况,并允许集群运营者定义 *Namespace* 可能消耗的 *Hard* 资源使用限制。 + + + +限制区间定义了单个实体在一个 *Namespace* 中可使用的最小/最大资源量约束。 + +参阅 [准入控制: 限制区间](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) + + + +命名空间可以处于下列两个阶段中的一个: + + * `Active` 命名空间使用中 + * `Terminating` 命名空间正在被删除,且不能被用于新对象。 + +参见 [设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) 查看更多细节。 + + + +## 创建命名空间 + + + +1. 新建一个名为 `my-namespace.yaml` 的 YAML 文件,并写入下列内容: + +```yaml +apiVersion: v1 +kind: Namespace +metadata: + name: +``` + + + +然后运行: + +```shell +kubectl create -f ./my-namespace.yaml +``` + + + +请注意,命名空间的名称必须是 DNS 兼容的标签。 + + + +可选字段 `finalizers` 允许观察者们在命名空间被删除时清除资源。记住如果指定了一个不存在的终结器,命名空间仍会被创建,但如果用户试图删除它,它将陷入 `Terminating` 状态。 + +更多有关 `finalizers` 的信息请查阅 [设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) 中命名空间部分。 + + + +## 删除命名空间 + + + +1. 删除命名空间使用命令 + +```shell +kubectl delete namespaces +``` + +{{< warning >}} + + +这会删除命名空间下的 _所有内容_ ! + +{{< /warning >}} + + + +删除是异步的,所以有一段时间你会看到命名空间处于 `Terminating` 状态。 + + + +## 使用 Kubernetes 命名空间细分您的集群 + + + +1. 理解默认命名空间 + +默认情况下,Kubernetes 集群会在配置集群时实例化一个默认命名空间,用以存放集群所使用的默认 Pods、Services 和 Deployments 集合。 + + + +假设您有一个新的集群,您可以通过执行以下操作来内省可用的命名空间 + +```shell +kubectl get namespaces +``` +``` +NAME STATUS AGE +default Active 13m +``` + + + +2. 创建新的命名空间 + + + +在本练习中,我们将创建两个额外的 Kubernetes 命名空间来保存我们的内容。 + + + +在某组织使用共享的 Kubernetes 集群进行开发和生产的场景中: + + + +开发团队希望在集群中维护一个空间,以便他们可以查看用于构建和运行其应用程序的 Pods、Services 和 Deployments 列表。在这个空间里,Kubernetes 资源被自由地加入或移除,对谁能够或不能修改资源的限制被放宽,以实现敏捷开发。 + + + +运维团队希望在集群中维护一个空间,以便他们可以强制实施一些严格的规程,对谁可以或不可以操作运行生产站点的 Pods、Services 和 Deployments 集合进行控制。 + + + +该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个命名空间:development 和 production。 + + + +让我们创建两个新的命名空间来保存我们的工作。 + + + +文件 [`namespace-dev.json`](/examples/admin/namespace-dev.json) 描述了 development 命名空间: + +{{< codenew language="json" file="admin/namespace-dev.json" >}} + + + +使用 kubectl 创建 `development` 命名空间。 + +```shell +kubectl create -f https://k8s.io/examples/admin/namespace-dev.json +``` + + + +让我们使用 kubectl 创建 `production` 命名空间。 + +```shell +kubectl create -f https://k8s.io/examples/admin/namespace-prod.json +``` + + + +为了确保一切正常,列出集群中的所有命名空间。 + +```shell +kubectl get namespaces --show-labels +``` +``` +NAME STATUS AGE LABELS +default Active 32m +development Active 29s name=development +production Active 23s name=production +``` + + + +3. 在每个命名空间中创建 pod + + + +Kubernetes 命名空间为集群中的 Pods、Services 和 Deployments 提供了作用域。 + +与一个命名空间交互的用户不会看到另一个命名空间中的内容。 + + + +为了演示这一点,让我们在 `development` 命名空间中启动一个简单的 Deployment 和 Pod。 + + + +我们首先检查一下当前的上下文: + +```shell +kubectl config view +``` +```yaml +apiVersion: v1 +clusters: +- cluster: + certificate-authority-data: REDACTED + server: https://130.211.122.180 + name: lithe-cocoa-92103_kubernetes +contexts: +- context: + cluster: lithe-cocoa-92103_kubernetes + user: lithe-cocoa-92103_kubernetes + name: lithe-cocoa-92103_kubernetes +current-context: lithe-cocoa-92103_kubernetes +kind: Config +preferences: {} +users: +- name: lithe-cocoa-92103_kubernetes + user: + client-certificate-data: REDACTED + client-key-data: REDACTED + token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b +- name: lithe-cocoa-92103_kubernetes-basic-auth + user: + password: h5M0FtUUIflBSdI7 + username: admin +``` + +```shell +kubectl config current-context +``` +``` +lithe-cocoa-92103_kubernetes +``` + + + +下一步是为 kubectl 客户端定义一个上下文,以便在每个命名空间中工作。"cluster" 和 "user" 字段的值将从当前上下文中复制。 + +```shell +kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes +kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes +``` + + + +上述命令提供了两个可以替代的请求上下文,具体取决于您希望使用的命名空间。 + + + +让我们切换到 `development` 命名空间进行操作。 + +```shell +kubectl config use-context dev +``` + + + +您可以使用下列命令验证当前上下文: + +```shell +kubectl config current-context +dev +``` + + + +此时,我们从命令行向 Kubernetes 集群发出的所有请求都限定在 `development` 命名空间中。 + + + +让我们创建一些内容。 + +```shell +kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2 +``` + + +我们刚刚创建了一个副本大小为 2 的 deployment,该 deployment 运行名为 snowflake 的 pod,其中包含一个仅提供主机名服务的基本容器。请注意,`kubectl run` 仅在 Kubernetes 集群版本 >= v1.2 时创建 deployment。如果您运行在旧版本上,则会创建 replication controllers。如果期望执行旧版本的行为,请使用 `--generator=run/v1` 创建 replication controllers。 参见 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) 获取更多细节。 + +```shell +kubectl get deployment +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +snowflake 2 2 2 2 2m +``` +```shell +kubectl get pods -l run=snowflake +``` +``` +NAME READY STATUS RESTARTS AGE +snowflake-3968820950-9dgr8 1/1 Running 0 2m +snowflake-3968820950-vgc4n 1/1 Running 0 2m +``` + + + +这很棒,开发人员可以做他们想要的事情,而不必担心影响 `production` 命名空间中的内容。 + + + +让我们切换到 `production` 命名空间,展示一个命名空间中的资源如何对另一个命名空间不可见。 + +```shell +kubectl config use-context prod +``` + + + +`production` 命名空间应该是空的,下列命令应该返回的内容为空。 + +```shell +kubectl get deployment +kubectl get pods +``` + + + +生产环境需要运行 cattle,让我们创建一些名为 cattle 的 pods。 + +```shell +kubectl run cattle --image=kubernetes/serve_hostname --replicas=5 + +kubectl get deployment +``` +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +cattle 5 5 5 5 10s +``` + +```shell +kubectl get pods -l run=cattle +``` +``` +NAME READY STATUS RESTARTS AGE +cattle-2263376956-41xy6 1/1 Running 0 34s +cattle-2263376956-kw466 1/1 Running 0 34s +cattle-2263376956-n4v97 1/1 Running 0 34s +cattle-2263376956-p5p3i 1/1 Running 0 34s +cattle-2263376956-sxpth 1/1 Running 0 34s +``` + + + +此时,应该很清楚的展示了用户在一个命名空间中创建的资源对另一个命名空间是隐藏的。 + + + +随着 Kubernetes 中的策略支持的发展,我们将扩展此场景,以展示如何为每个命名空间提供不同的授权规则。 + +{{% /capture %}} + +{{% capture discussion %}} + + + +## 理解使用命名空间的动机 + + + +单个集群应该能满足多个用户及用户组的需求(以下称为 “用户社区”)。 + + + +Kubernetes _命名空间_ 帮助不同的项目、团队或客户去共享 Kubernetes 集群。 + + + +名字空间通过以下方式实现这点: + +1. 为[名字](/docs/concepts/overview/working-with-objects/names/)设置作用域. +2. 为集群中的部分资源关联鉴权和策略的机制。 + + + +使用多个命名空间是可选的。 + + + +每个用户社区都希望能够与其他社区隔离开展工作。 + + + +每个用户社区都有: + +1. 资源(pods, services, replication controllers, 等等) +2. 策略(谁能或不能在他们的社区里执行操作) +3. 约束(该社区允许多少配额,等等) + + + +集群运营者可以为每个唯一用户社区创建命名空间。 + + + +命名空间为下列内容提供唯一的作用域: + +1. 命名资源(避免基本的命名冲突) +2. 将管理权限委派给可信用户 +3. 限制社区资源消耗的能力 + + + +用例包括: + +1. 作为集群运营者, 我希望能在单个集群上支持多个用户社区。 +2. 作为集群运营者,我希望将集群分区的权限委派给这些社区中的受信任用户。 +3. 作为集群运营者,我希望能限定每个用户社区可使用的资源量,以限制对使用同一集群的其他用户社区的影响。 +4. 作为群集用户,我希望与我的用户社区相关的资源进行交互,而与其他用户社区在该集群上执行的操作无关。 + + + +## 理解命名空间和 DNS + + + +当您创建 [Service](/docs/concepts/services-networking/service/) 时,它会创建相应的 [DNS 条目](/docs/concepts/services-networking/dns-pod-service/)。此条目的格式为 ` .svc.cluster.local`,这意味着如果容器只使用 ``,它将解析为本地服务到命名空间。 这对于在多个命名空间(如开发,暂存和生产)中使用相同的配置非常有用。 如果要跨命名空间访问,则需要使用完全限定的域名(FQDN)。 + +{{% /capture %}} + +{{% capture whatsnext %}} + + + +* 了解更多 [设置命名空间首选项](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference) 的内容。 +* 了解更多 [设置请求的命名空间](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request) 的内容。 +* 参见 [命名空间设计](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md)。 + +{{% /capture %}} + + diff --git a/content/zh/examples/admin/namespace-dev.json b/content/zh/examples/admin/namespace-dev.json new file mode 100644 index 0000000000..b2b43b0b73 --- /dev/null +++ b/content/zh/examples/admin/namespace-dev.json @@ -0,0 +1,10 @@ +{ + "kind": "Namespace", + "apiVersion": "v1", + "metadata": { + "name": "development", + "labels": { + "name": "development" + } + } +} diff --git a/content/zh/examples/admin/namespace-prod.json b/content/zh/examples/admin/namespace-prod.json new file mode 100644 index 0000000000..d4503f1ac1 --- /dev/null +++ b/content/zh/examples/admin/namespace-prod.json @@ -0,0 +1,10 @@ +{ + "kind": "Namespace", + "apiVersion": "v1", + "metadata": { + "name": "production", + "labels": { + "name": "production" + } + } +}