[zh] Fix links in concepts section (6)
This commit is contained in:
Qiming Teng
parent
dab8047c85
commit
d38315f27b
|
|
@ -3,6 +3,14 @@ title: 容器环境
|
|||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Container Environment
|
||||
content_type: concept
|
||||
weight: 20
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
|
|
@ -11,9 +19,6 @@ This page describes the resources available to Containers in the Container envir
|
|||
-->
|
||||
本页描述了在容器环境里容器可用的资源。
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
|
|
@ -25,13 +30,14 @@ The Kubernetes Container environment provides several important resources to Con
|
|||
* Information about the Container itself.
|
||||
* Information about other objects in the cluster.
|
||||
-->
|
||||
## 容器环境
|
||||
## 容器环境 {#container-environment}
|
||||
|
||||
Kubernetes 的容器环境给容器提供了几个重要的资源：
|
||||
|
||||
* 文件系统，其中包含一个[镜像](/docs/concepts/containers/images/) 和一个或多个的[卷](/docs/concepts/storage/volumes/)。
|
||||
* 容器自身的信息。
|
||||
* 集群中其他对象的信息。
|
||||
* 文件系统，其中包含一个[镜像](/zh/docs/concepts/containers/images/)
|
||||
和一个或多个的[卷](/zh/docs/concepts/storage/volumes/)
|
||||
* 容器自身的信息
|
||||
* 集群中其他对象的信息
|
||||
|
||||
<!--
|
||||
### Container information
|
||||
|
|
@ -49,9 +55,12 @@ as are any environment variables specified statically in the Docker image.
|
|||
-->
|
||||
### 容器信息
|
||||
|
||||
容器的 *hostname* 是它所运行在的 pod 的名称。它可以通过 `hostname` 命令或者调用 libc 中的 [`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) 函数来获取。
|
||||
容器的 *hostname* 是它所运行在的 pod 的名称。它可以通过 `hostname` 命令或者调用 libc 中的
|
||||
[`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) 函数来获取。
|
||||
|
||||
Pod 名称和命名空间可以通过 [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 使用环境变量。
|
||||
Pod 名称和命名空间可以通过
|
||||
[下行 API](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)
|
||||
转换为环境变量。
|
||||
|
||||
Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 Docker 镜像中静态指定的任何环境变量一样。
|
||||
|
||||
|
|
@ -79,19 +88,18 @@ FOO_SERVICE_PORT=<the port the service is running on>
|
|||
Services have dedicated IP addresses and are available to the Container via DNS,
|
||||
if [DNS addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled.
|
||||
-->
|
||||
Service 具有专用的 IP 地址。如果启用了 [DNS插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)，就可以在容器中通过 DNS 来访问。
|
||||
|
||||
|
||||
服务具有专用的 IP 地址。如果启用了
|
||||
[DNS插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)，
|
||||
可以在容器中通过 DNS 来访问服务。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!--
|
||||
* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
|
||||
* Get hands-on experience
|
||||
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
-->
|
||||
* 学习更多有关[容器生命周期钩子](/docs/concepts/containers/container-lifecycle-hooks/)的知识。
|
||||
* 动手获得经验[将处理程序附加到容器生命周期事件](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
|
||||
* 学习更多有关[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)的知识
|
||||
* 动手[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,8 @@
|
|||
---
|
||||
reviewers:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: 容器生命周期钩子
|
||||
title: 容器生命周期回调
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- mikedanese
|
||||
|
|
@ -16,45 +12,38 @@ content_type: concept
|
|||
weight: 30
|
||||
-->
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page describes how kubelet managed Containers can use the Container lifecycle hook framework
|
||||
to run code triggered by events during their management lifecycle.
|
||||
-->
|
||||
这个页面描述了 kubelet 管理的容器如何使用容器生命周期钩子框架来运行在其管理生命周期中由事件触发的代码。
|
||||
|
||||
|
||||
|
||||
这个页面描述了 kubelet 管理的容器如何使用容器生命周期回调框架，
|
||||
藉由其管理生命周期中的事件触发，运行指定代码。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Overview
|
||||
-->
|
||||
|
||||
## 概述
|
||||
|
||||
<!--
|
||||
Analogous to many programming language frameworks that have component lifecycle hooks, such as Angular,
|
||||
Kubernetes provides Containers with lifecycle hooks.
|
||||
The hooks enable Containers to be aware of events in their management lifecycle
|
||||
and run code implemented in a handler when the corresponding lifecycle hook is executed.
|
||||
-->
|
||||
类似于许多具有生命周期钩子组件的编程语言框架，例如 Angular、Kubernetes 为容器提供了生命周期钩子。
|
||||
钩子使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期钩子时运行在处理程序中实现的代码。
|
||||
## 概述
|
||||
|
||||
类似于许多具有生命周期回调组件的编程语言框架，例如 Angular、Kubernetes 为容器提供了生命周期回调。
|
||||
回调使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期回调时运行在处理程序中实现的代码。
|
||||
|
||||
<!--
|
||||
## Container hooks
|
||||
-->
|
||||
|
||||
## 容器钩子
|
||||
|
||||
<!--
|
||||
There are two hooks that are exposed to Containers:
|
||||
-->
|
||||
有两个钩子暴露在容器中:
|
||||
## 容器回调
|
||||
|
||||
有两个回调暴露给容器：
|
||||
|
||||
`PostStart`
|
||||
|
||||
|
|
@ -63,8 +52,8 @@ This hook executes immediately after a container is created.
|
|||
However, there is no guarantee that the hook will execute before the container ENTRYPOINT.
|
||||
No parameters are passed to the handler.
|
||||
-->
|
||||
这个钩子在创建容器之后立即执行。
|
||||
但是，不能保证钩子会在容器入口点之前执行。
|
||||
这个回调在创建容器之后立即执行。
|
||||
但是，不能保证回调会在容器入口点（ENTRYPOINT）之前执行。
|
||||
没有参数传递给处理程序。
|
||||
|
||||
`PreStop`
|
||||
|
|
@ -75,29 +64,29 @@ It is blocking, meaning it is synchronous,
|
|||
so it must complete before the call to delete the container can be sent.
|
||||
No parameters are passed to the handler.
|
||||
-->
|
||||
|
||||
在容器终止之前是否立即调用此钩子，取决于 API 的请求或者管理事件，类似活动探针故障、资源抢占、资源竞争等等。 如果容器已经完全处于终止或者完成状态，则对 preStop 钩子的调用将失败。
|
||||
它是阻塞的，同时也是同步的，因此它必须在删除容器的调用之前完成。
|
||||
在容器因 API 请求或者管理事件（诸如存活态探针失败、资源抢占、资源竞争等）而被终止之前，
|
||||
此回调会被调用。
|
||||
如果容器已经处于终止或者完成状态，则对 preStop 回调的调用将失败。
|
||||
此调用是阻塞的，也是同步调用，因此必须在删除容器的调用之前完成。
|
||||
没有参数传递给处理程序。
|
||||
|
||||
<!--
|
||||
A more detailed description of the termination behavior can be found in
|
||||
[Termination of Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
|
||||
[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
|
||||
-->
|
||||
有关终止行为的更详细描述，请参见[终止 Pod](/docs/concepts/workloads/pods/pod/#termination-of-pods)。
|
||||
有关终止行为的更详细描述，请参见
|
||||
[终止 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)。
|
||||
|
||||
<!--
|
||||
### Hook handler implementations
|
||||
-->
|
||||
|
||||
### 钩子处理程序的实现
|
||||
|
||||
<!--
|
||||
Containers can access a hook by implementing and registering a handler for that hook.
|
||||
There are two types of hook handlers that can be implemented for Containers:
|
||||
-->
|
||||
容器可以通过实现和注册该钩子的处理程序来访问该钩子。
|
||||
针对容器，有两种类型的钩子处理程序可供实现：
|
||||
### 回调处理程序的实现
|
||||
|
||||
容器可以通过实现和注册该回调的处理程序来访问该回调。
|
||||
针对容器，有两种类型的回调处理程序可供实现：
|
||||
|
||||
<!--
|
||||
* Exec - Executes a specific command, such as `pre-stop.sh`, inside the cgroups and namespaces of the Container.
|
||||
|
|
@ -105,21 +94,19 @@ Resources consumed by the command are counted against the Container.
|
|||
* HTTP - Executes an HTTP request against a specific endpoint on the Container.
|
||||
-->
|
||||
|
||||
* Exec - 执行一个特定的命令，例如 `pre-stop.sh`，在容器的 cgroups 和名称空间中。
|
||||
命令所消耗的资源根据容器进行计算。
|
||||
* Exec - 在容器的 cgroups 和名称空间中执行特定的命令（例如 `pre-stop.sh`）。
|
||||
命令所消耗的资源计入容器的资源消耗。
|
||||
* HTTP - 对容器上的特定端点执行 HTTP 请求。
|
||||
|
||||
<!--
|
||||
### Hook handler execution
|
||||
-->
|
||||
|
||||
### 钩子处理程序执行
|
||||
|
||||
<!--
|
||||
When a Container lifecycle management hook is called,
|
||||
the Kubernetes management system executes the handler in the Container registered for that hook.
|
||||
-->
|
||||
当调用容器生命周期管理钩子时，Kubernetes 管理系统在为该钩子注册的容器中执行处理程序。
|
||||
### 回调处理程序执行
|
||||
|
||||
当调用容器生命周期管理回调时，Kubernetes 管理系统在注册了回调的容器中执行处理程序。
|
||||
|
||||
<!--
|
||||
Hook handler calls are synchronous within the context of the Pod containing the Container.
|
||||
|
|
@ -128,9 +115,9 @@ the Container ENTRYPOINT and hook fire asynchronously.
|
|||
However, if the hook takes too long to run or hangs,
|
||||
the Container cannot reach a `running` state.
|
||||
-->
|
||||
钩子处理程序调用在包含容器的 Pod 上下文中是同步的。
|
||||
这意味着对于 `PostStart` 钩子，容器入口点和钩子异步触发。
|
||||
但是，如果钩子运行或挂起的时间太长，则容器无法达到 `running` 状态。
|
||||
回调处理程序调用在包含容器的 Pod 上下文中是同步的。
|
||||
这意味着对于 `PostStart` 回调，容器入口点和回调异步触发。
|
||||
但是，如果回调运行或挂起的时间太长，则容器无法达到 `running` 状态。
|
||||
|
||||
<!--
|
||||
The behavior is similar for a `PreStop` hook.
|
||||
|
|
@ -139,32 +126,31 @@ the Pod phase stays in a `Terminating` state and is killed after `terminationGra
|
|||
If a `PostStart` or `PreStop` hook fails,
|
||||
it kills the Container.
|
||||
-->
|
||||
行为与 `PreStop` 钩子的行为类似。
|
||||
如果钩子在执行过程中挂起，Pod 阶段将保持在 `Terminating` 状态，并在 Pod 结束的 `terminationGracePeriodSeconds` 之后被杀死。
|
||||
如果 `PostStart` 或 `PreStop` 钩子失败，它会杀死容器。
|
||||
行为与 `PreStop` 回调的行为类似。
|
||||
如果回调在执行过程中挂起，Pod 阶段将保持在 `Terminating` 状态，
|
||||
并在 Pod 结束的 `terminationGracePeriodSeconds` 之后被杀死。
|
||||
如果 `PostStart` 或 `PreStop` 回调失败，它会杀死容器。
|
||||
|
||||
<!--
|
||||
Users should make their hook handlers as lightweight as possible.
|
||||
There are cases, however, when long running commands make sense,
|
||||
such as when saving state prior to stopping a Container.
|
||||
-->
|
||||
用户应该使他们的钩子处理程序尽可能的轻量级。
|
||||
用户应该使他们的回调处理程序尽可能的轻量级。
|
||||
但也需要考虑长时间运行的命令也很有用的情况，比如在停止容器之前保存状态。
|
||||
|
||||
<!--
|
||||
### Hook delivery guarantees
|
||||
-->
|
||||
|
||||
### 钩子寄送保证
|
||||
|
||||
<!--
|
||||
Hook delivery is intended to be *at least once*,
|
||||
which means that a hook may be called multiple times for any given event,
|
||||
such as for `PostStart` or `PreStop`.
|
||||
It is up to the hook implementation to handle this correctly.
|
||||
-->
|
||||
钩子的寄送应该是 *至少一次*，这意味着对于任何给定的事件，例如 `PostStart` 或 `PreStop`，钩子可以被调用多次。
|
||||
如何正确处理，是钩子实现所要考虑的问题。
|
||||
### 回调寄送保证
|
||||
|
||||
回调的寄送应该是 *至少一次*，这意味着对于任何给定的事件，例如 `PostStart` 或 `PreStop`，回调可以被调用多次。
|
||||
如何正确处理，是回调实现所要考虑的问题。
|
||||
|
||||
<!--
|
||||
Generally, only single deliveries are made.
|
||||
|
|
@ -175,17 +161,13 @@ For instance, if a kubelet restarts in the middle of sending a hook,
|
|||
the hook might be resent after the kubelet comes back up.
|
||||
-->
|
||||
通常情况下，只会进行单次寄送。
|
||||
例如，如果 HTTP 钩子接收器宕机，无法接收流量，则不会尝试重新发送。
|
||||
例如，如果 HTTP 回调接收器宕机，无法接收流量，则不会尝试重新发送。
|
||||
然而，偶尔也会发生重复寄送的可能。
|
||||
例如，如果 kubelet 在发送钩子的过程中重新启动，钩子可能会在 kubelet 恢复后重新发送。
|
||||
例如，如果 kubelet 在发送回调的过程中重新启动，回调可能会在 kubelet 恢复后重新发送。
|
||||
|
||||
<!--
|
||||
### Debugging Hook handlers
|
||||
-->
|
||||
|
||||
### 调试钩子处理程序
|
||||
|
||||
<!--
|
||||
The logs for a Hook handler are not exposed in Pod events.
|
||||
If a handler fails for some reason, it broadcasts an event.
|
||||
For `PostStart`, this is the `FailedPostStartHook` event,
|
||||
|
|
@ -193,7 +175,9 @@ and for `PreStop`, this is the `FailedPreStopHook` event.
|
|||
You can see these events by running `kubectl describe pod <pod_name>`.
|
||||
Here is some example output of events from running this command:
|
||||
-->
|
||||
钩子处理程序的日志不会在 Pod 事件中公开。
|
||||
### 调试回调处理程序
|
||||
|
||||
回调处理程序的日志不会在 Pod 事件中公开。
|
||||
如果处理程序由于某种原因失败，它将播放一个事件。
|
||||
对于 `PostStart`，这是 `FailedPostStartHook` 事件，对于 `PreStop`，这是 `FailedPreStopHook` 事件。
|
||||
您可以通过运行 `kubectl describe pod <pod_name>` 命令来查看这些事件。
|
||||
|
|
@ -214,18 +198,14 @@ Events:
|
|||
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!--
|
||||
* Learn more about the [Container environment](/docs/concepts/containers/container-environment-variables/).
|
||||
* Learn more about the [Container environment](/docs/concepts/containers/container-environment/).
|
||||
* Get hands-on experience
|
||||
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
-->
|
||||
|
||||
* 了解更多关于[容器环境](/docs/concepts/containers/container-environment-variables/)。
|
||||
* 获取实践经验[将处理程序附加到容器生命周期事件](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
|
||||
|
||||
* 进一步了解[容器环境](/zh/docs/concepts/containers/container-environment/)
|
||||
* 动手实践，[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,16 @@
|
|||
---
|
||||
reviewers:
|
||||
- tallclair
|
||||
- dchen1107
|
||||
title: 容器运行时类(Runtime Class)
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- tallclair
|
||||
- dchen1107
|
||||
title: Runtime Class
|
||||
content_type: concept
|
||||
weight: 20
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
|
|
@ -13,26 +18,19 @@ weight: 20
|
|||
|
||||
<!--
|
||||
This page describes the RuntimeClass resource and runtime selection mechanism.
|
||||
-->
|
||||
本页面描述了 RuntimeClass 资源和运行时的选择机制。
|
||||
|
||||
<!--
|
||||
RuntimeClass is a feature for selecting the container runtime configuration. The container runtime
|
||||
configuration is used to run a Pod's containers.
|
||||
-->
|
||||
本页面描述了 RuntimeClass 资源和运行时的选择机制。
|
||||
|
||||
RuntimeClass 是一个用于选择容器运行时配置的特性，容器运行时配置用于运行 Pod 中的容器。
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Motivation
|
||||
-->
|
||||
## 动机
|
||||
|
||||
<!--
|
||||
You can set a different RuntimeClass between different Pods to provide a balance of
|
||||
performance versus security. For example, if part of your workload deserves a high
|
||||
level of information security assurance, you might choose to schedule those Pods so
|
||||
|
|
@ -40,37 +38,37 @@ that they run in a container runtime that uses hardware virtualization. You'd th
|
|||
benefit from the extra isolation of the alternative runtime, at the expense of some
|
||||
additional overhead.
|
||||
-->
|
||||
您可以在不同的 pod 之间设置不同的 RuntimeClass，以提供性能与安全性之间的平衡。
|
||||
例如，如果您的部分工作负载需要高级别的信息安全保证，那么您可以选择性地调度这些 pod，
|
||||
使它们在使用硬件虚拟化的容器运行时中运行。
|
||||
然后，您将从可选运行时的额外隔离中获益，代价是一些额外的开销。
|
||||
## 动机 {#motivation}
|
||||
|
||||
你可以在不同的 Pod 设置不同的 RuntimeClass，以提供性能与安全性之间的平衡。
|
||||
例如，如果你的部分工作负载需要高级别的信息安全保证，你可以决定在调度这些 Pod
|
||||
时尽量使它们在使用硬件虚拟化的容器运行时中运行。
|
||||
这样，你将从这些不同运行时所提供的额外隔离中获益，代价是一些额外的开销。
|
||||
|
||||
<!--
|
||||
You can also use RuntimeClass to run different Pods with the same container runtime
|
||||
but with different settings.
|
||||
-->
|
||||
您还可以使用 RuntimeClass 运行具有相同容器运行时但具有不同设置的pod。
|
||||
你还可以使用 RuntimeClass 运行具有相同容器运行时但具有不同设置的 Pod。
|
||||
|
||||
<!--
|
||||
## Setup
|
||||
-->
|
||||
## 设置
|
||||
|
||||
<!--
|
||||
Ensure the RuntimeClass feature gate is enabled (it is by default). See [Feature
|
||||
Gates](/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling
|
||||
feature gates. The `RuntimeClass` feature gate must be enabled on apiservers _and_ kubelets.
|
||||
-->
|
||||
## 设置 {#setup}
|
||||
|
||||
确保 RuntimeClass 特性开关处于开启状态（默认为开启状态）。
|
||||
关于特性开关的详细介绍，请查阅
|
||||
[Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
`RuntimeClass` 特性开关必须在 apiserver 和 kubelet 同时开启。
|
||||
关于特性开关的详细介绍，请参阅
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
`RuntimeClass` 特性开关必须在 API 服务器和 kubelet 端同时开启。
|
||||
|
||||
<!--
|
||||
1. Configure the CRI implementation on nodes (runtime dependent)
|
||||
2. Create the corresponding RuntimeClass resources
|
||||
-->
|
||||
|
||||
1. 在节点上配置 CRI 的实现（取决于所选用的运行时）
|
||||
2. 创建相应的 RuntimeClass 资源
|
||||
|
||||
|
|
@ -87,11 +85,12 @@ CRI implementation for how to configure.
|
|||
RuntimeClass 的配置依赖于 运行时接口（CRI）的实现。
|
||||
根据你使用的 CRI 实现，查阅相关的文档（[下方](#cri-configuration)）来了解如何配置。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
RuntimeClass assumes a homogeneous node configuration across the cluster by default (which means
|
||||
that all nodes are configured the same way with respect to container runtimes). To support
|
||||
heterogenous node configurations, see [Scheduling](#scheduling) below.-->
|
||||
heterogenous node configurations, see [Scheduling](#scheduling) below.
|
||||
-->
|
||||
{{< note >}}
|
||||
RuntimeClass 假设集群中的节点配置是同构的（换言之，所有的节点在容器运行时方面的配置是相同的）。
|
||||
如果需要支持异构节点，配置方法请参阅下面的 [调度](#scheduling)。
|
||||
{{< /note >}}
|
||||
|
|
@ -105,13 +104,12 @@ handler 必须符合 DNS-1123 命名规范（字母、数字、或 `-`）。
|
|||
|
||||
<!--
|
||||
### 2. Create the corresponding RuntimeClass resources
|
||||
-->
|
||||
### 2. 创建相应的 RuntimeClass 资源
|
||||
|
||||
<!--
|
||||
The configurations setup in step 1 should each have an associated `handler` name, which identifies
|
||||
the configuration. For each handler, create a corresponding RuntimeClass object.
|
||||
-->
|
||||
### 2. 创建相应的 RuntimeClass 资源
|
||||
|
||||
在上面步骤 1 中，每个配置都需要有一个用于标识配置的 `handler`。
|
||||
针对每个 handler 需要创建一个 RuntimeClass 对象。
|
||||
|
||||
|
|
@ -123,31 +121,32 @@ RuntimeClass 资源当前只有两个重要的字段：RuntimeClass 名 (`metada
|
|||
对象定义如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1beta1 # RuntimeClass is defined in the node.k8s.io API group
|
||||
apiVersion: node.k8s.io/v1beta1 # RuntimeClass 定义于 node.k8s.io API 组
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: myclass # The name the RuntimeClass will be referenced by
|
||||
# RuntimeClass is a non-namespaced resource
|
||||
handler: myconfiguration # The name of the corresponding CRI configuration
|
||||
name: myclass # 用来引用 RuntimeClass 的名字
|
||||
# RuntimeClass 是一个集群层面的资源
|
||||
handler: myconfiguration # 对应的 CRI 配置的名称
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
It is recommended that RuntimeClass write operations (create/update/patch/delete) be
|
||||
restricted to the cluster administrator. This is typically the default. See [Authorization
|
||||
Overview](/docs/reference/access-authn-authz/authorization/) for more details.-->建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。
|
||||
通常这是默认配置。参阅[授权概述](/docs/reference/access-authn-authz/authorization/)了解更多信息。
|
||||
Overview](/docs/reference/access-authn-authz/authorization/) for more details.
|
||||
-->
|
||||
{{< note >}}
|
||||
建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。
|
||||
通常这是默认配置。参阅[授权概述](/zh/docs/reference/access-authn-authz/authorization/)了解更多信息。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Usage
|
||||
-->
|
||||
## 使用说明
|
||||
|
||||
<!--
|
||||
Once RuntimeClasses are configured for the cluster, using them is very simple. Specify a
|
||||
`runtimeClassName` in the Pod spec. For example:
|
||||
-->
|
||||
## 使用说明 {#usage}
|
||||
|
||||
一旦完成集群中 RuntimeClasses 的配置，使用起来非常方便。
|
||||
在 Pod spec 中指定 `runtimeClassName` 即可。例如:
|
||||
|
||||
|
|
@ -168,9 +167,11 @@ RuntimeClass does not exist, or the CRI cannot run the corresponding handler, th
|
|||
corresponding [event](/docs/tasks/debug-application-cluster/debug-application-introspection/) for an
|
||||
error message.
|
||||
-->
|
||||
这一设置会告诉 Kubelet 使用所指的 RuntimeClass 来运行该 pod。
|
||||
如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler，那么 pod 将会进入 `Failed` 终止[阶段](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。
|
||||
你可以查看相应的[事件](/docs/tasks/debug-application-cluster/debug-application-introspection/)，获取出错信息。
|
||||
这一设置会告诉 kubelet 使用所指的 RuntimeClass 来运行该 pod。
|
||||
如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler，
|
||||
那么 pod 将会进入 `Failed` 终止[阶段](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。
|
||||
你可以查看相应的[事件](/zh/docs/tasks/debug-application-cluster/debug-application-introspection/)，
|
||||
获取出错信息。
|
||||
|
||||
<!--
|
||||
If no `runtimeClassName` is specified, the default RuntimeHandler will be used, which is equivalent
|
||||
|
|
@ -180,20 +181,20 @@ to the behavior when the RuntimeClass feature is disabled.
|
|||
|
||||
<!--
|
||||
### CRI Configuration
|
||||
-->
|
||||
### CRI 配置
|
||||
|
||||
<!--
|
||||
For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/production-environment/container-runtimes/).
|
||||
-->
|
||||
关于如何安装 CRI 运行时，请查阅 [CRI 安装](/docs/setup/production-environment/container-runtimes/)。
|
||||
### CRI 配置 {#cri-configuration}
|
||||
|
||||
关于如何安装 CRI 运行时，请查阅
|
||||
[CRI 安装](/zh/docs/setup/production-environment/container-runtimes/)。
|
||||
|
||||
#### dockershim
|
||||
|
||||
<!--
|
||||
Kubernetes built-in dockershim CRI does not support runtime handlers.
|
||||
-->
|
||||
Kubernetes 内置 dockershim CRI 不支持配置运行时 handler。
|
||||
Kubernetes 内置的 dockershim CRI 不支持配置运行时 handler。
|
||||
|
||||
#### [containerd](https://containerd.io/)
|
||||
|
||||
|
|
@ -223,8 +224,9 @@ handlers are configured under the [crio.runtime
|
|||
table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table):
|
||||
-->
|
||||
通过 cri-o 的 `/etc/crio/crio.conf` 配置文件来配置运行时 handler。
|
||||
handler 需要配置在 [crio.runtime 表](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)
|
||||
下方：
|
||||
handler 需要配置在
|
||||
[crio.runtime 表](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)
|
||||
下面：
|
||||
|
||||
```
|
||||
[crio.runtime.runtimes.${HANDLER_NAME}]
|
||||
|
|
@ -232,16 +234,14 @@ handler 需要配置在 [crio.runtime 表](https://github.com/kubernetes-sigs/cr
|
|||
```
|
||||
|
||||
<!--
|
||||
See cri-o's config documentation for more details:
|
||||
https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
|
||||
See CRI-O's [config documentation](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md) for more details.
|
||||
-->
|
||||
更详细信息，请查阅 containerd 配置文档：
|
||||
https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
|
||||
更详细信息，请查阅 CRI-O [配置文档](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)。
|
||||
|
||||
<!--
|
||||
## Scheduling
|
||||
-->
|
||||
## 调度
|
||||
## 调度 {#scheduling}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
|
|
@ -253,7 +253,9 @@ the [RuntimeClass admission controller][] enabled (the default, as of 1.16).
|
|||
-->
|
||||
在 Kubernetes v1.16 版本里，RuntimeClass 特性引入了 `scheduling` 字段来支持异构集群。
|
||||
通过该字段，可以确保 pod 被调度到支持指定运行时的节点上。
|
||||
该调度支持，需要确保 [RuntimeClass admission controller][] 处于开启状态（1.16 版本默认开启）。
|
||||
该调度支持，需要确保
|
||||
[RuntimeClass 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)
|
||||
处于开启状态（1.16 版本默认开启）。
|
||||
|
||||
<!--
|
||||
To ensure pods land on nodes supporting a specific RuntimeClass, that set of nodes should have a
|
||||
|
|
@ -280,14 +282,12 @@ To learn more about configuring the node selector and tolerations, see [Assignin
|
|||
Nodes](/docs/concepts/configuration/assign-pod-node/).
|
||||
-->
|
||||
更多有关 node selector 和 tolerations 的配置信息，请查阅
|
||||
[Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/)。
|
||||
|
||||
[RuntimeClass admission controller]: /docs/reference/access-authn-authz/admission-controllers/
|
||||
[将 Pod 分派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)。
|
||||
|
||||
<!--
|
||||
### Pod Overhead
|
||||
-->
|
||||
### Pod 开销
|
||||
### Pod 开销 {#pod-overhead}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
|
|
@ -298,19 +298,20 @@ To use Pod overhead, you must have the PodOverhead [feature gate](/docs/referenc
|
|||
enabled (it is on by default).
|
||||
-->
|
||||
你可以指定与运行 Pod 相关的 _开销_ 资源。声明开销即允许集群（包括调度器）在决策 Pod 和资源时将其考虑在内。
|
||||
若要使用 Pod 开销特性，你必须确保 PodOverhead [特性开关](/docs/reference/command-line-tools-reference/feature-gates/) 处于开启状态（默认为启用状态）。
|
||||
若要使用 Pod 开销特性，你必须确保 PodOverhead
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
处于启用状态（默认为启用状态）。
|
||||
|
||||
<!--
|
||||
Pod overhead is defined in RuntimeClass through the `Overhead` fields. Through the use of these fields,
|
||||
you can specify the overhead of running pods utilizing this RuntimeClass and ensure these overheads
|
||||
are accounted for in Kubernetes.
|
||||
-->
|
||||
Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。通过使用这些字段，你可以指定使用该 RuntimeClass 运行 Pod 时的开销并确保 Kubernetes 将这些开销计算在内。
|
||||
|
||||
Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。
|
||||
通过使用这些字段，你可以指定使用该 RuntimeClass 运行 Pod 时的开销并确保 Kubernetes 将这些开销计算在内。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!--
|
||||
- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
|
||||
- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
|
||||
|
|
@ -319,7 +320,7 @@ Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。通过使用这些
|
|||
-->
|
||||
- [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
|
||||
- [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
|
||||
- 阅读关于 [Pod 开销](/docs/concepts/configuration/pod-overhead/) 的概念
|
||||
- 阅读关于 [Pod 开销](/zh/docs/concepts/configuration/pod-overhead/) 的概念
|
||||
- [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ card:
|
|||
weight: 20
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- lavalamp
|
||||
title: Kubernetes Components
|
||||
|
|
@ -21,7 +20,6 @@ weight: 20
|
|||
card:
|
||||
name: concepts
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
|
|
@ -43,19 +41,17 @@ Here's the diagram of a Kubernetes cluster with all the components tied together
|
|||
|
||||
这张图表展示了包含所有相互关联组件的 Kubernetes 集群。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
<!--
|
||||
## Control Plane Components
|
||||
-->
|
||||
## 控制平面组件（Control Plane Components）
|
||||
|
||||
<!--
|
||||
## Control Plane Components
|
||||
|
||||
The Control Plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
|
||||
-->
|
||||
## 控制平面组件（Control Plane Components）
|
||||
|
||||
控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 `replicas` 字段时，启动新的 {{< glossary_tooltip text="pod" term_id="pod">}}）。
|
||||
|
||||
<!--
|
||||
|
|
@ -64,7 +60,10 @@ for simplicity, set up scripts typically start all Control Plane components on
|
|||
the same machine, and do not run user containers on this machine. See
|
||||
[Building High-Availability Clusters](/docs/admin/high-availability/) for an example multi-master-VM setup.
|
||||
-->
|
||||
控制平面组件可以在集群中的任何节点上运行。然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。请参阅[构建高可用性集群](/docs/admin/high-availability/)中对于多主机 VM 的设置示例。
|
||||
控制平面组件可以在集群中的任何节点上运行。
|
||||
然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。
|
||||
请参阅[构建高可用性集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)
|
||||
中对于多主机 VM 的设置示例。
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
|
|
@ -100,47 +99,46 @@ These controllers include:
|
|||
|
||||
<!--
|
||||
### cloud-controller-manager
|
||||
|
||||
{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
|
||||
|
||||
The cloud-controller-manager only runs controllers that are specific to your cloud provider.
|
||||
If you are running Kubernetes on your own premises, or in a learning environment inside your
|
||||
own PC, the cluster does not have a cloud controller manager.
|
||||
|
||||
As with the kube-controller-manager, the cloud-controller-manager combines several logically
|
||||
independent control loops into a single binary that you run as a single process. You can
|
||||
scale horizontally (run more than one copy) to improve performance or to help tolerate failures.
|
||||
|
||||
The following controllers can have cloud provider dependencies:
|
||||
|
||||
* Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
|
||||
* Route controller: For setting up routes in the underlying cloud infrastructure
|
||||
* Service controller: For creating, updating and deleting cloud provider load balancers
|
||||
-->
|
||||
### 云控制器管理器-(cloud-controller-manager)
|
||||
### cloud-controller-manager
|
||||
|
||||
<!--
|
||||
[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) runs controllers that interact with the underlying cloud providers. The cloud-controller-manager binary is an alpha feature introduced in Kubernetes release 1.6.
|
||||
-->
|
||||
[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) 运行与基础云提供商交互的控制器。cloud-controller-manager 二进制文件是 Kubernetes 1.6 版本中引入的 alpha 功能。
|
||||
`cloud-controller-manager` 进运行特定于云平台的控制回路。
|
||||
如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境，
|
||||
所部属的环境中不需要云控制器管理器。
|
||||
|
||||
<!--
|
||||
cloud-controller-manager runs cloud-provider-specific controller loops only. You must disable these controller loops in the kube-controller-manager. You can disable the controller loops by setting the `--cloud-provider` flag to `external` when starting the kube-controller-manager.
|
||||
-->
|
||||
cloud-controller-manager 仅运行云提供商特定的控制器循环。您必须在 kube-controller-manager 中禁用这些控制器循环，您可以通过在启动 kube-controller-manager 时将 `--cloud-provider` 参数设置为 `external` 来禁用控制器循环。
|
||||
与 `kube-controller-manager` 类似，`cloud-controller-manager` 将若干逻辑上独立的
|
||||
控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。
|
||||
你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。
|
||||
|
||||
<!--
|
||||
cloud-controller-manager allows the cloud vendor's code and the Kubernetes code to evolve independently of each other. In prior releases, the core Kubernetes code was dependent upon cloud-provider-specific code for functionality. In future releases, code specific to cloud vendors should be maintained by the cloud vendor themselves, and linked to cloud-controller-manager while running Kubernetes.
|
||||
-->
|
||||
cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展。在以前的版本中，核心的 Kubernetes 代码依赖于特定云提供商的代码来实现功能。在将来的版本中，云供应商专有的代码应由云供应商自己维护，并与运行 Kubernetes 的云控制器管理器相关联。
|
||||
下面的控制器都包含对云平台驱动的依赖：
|
||||
|
||||
<!--
|
||||
The following controllers have cloud provider dependencies:
|
||||
|
||||
* Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
|
||||
* Route Controller: For setting up routes in the underlying cloud infrastructure
|
||||
* Service Controller: For creating, updating and deleting cloud provider load balancers
|
||||
* Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes
|
||||
-->
|
||||
以下控制器具有云提供商依赖性:
|
||||
|
||||
* 节点控制器（Node Controller）: 用于检查云提供商以确定节点是否在云中停止响应后被删除
|
||||
* 节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
|
||||
* 路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
|
||||
* 服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器
|
||||
* 数据卷控制器（Volume Controller）: 用于创建、附加和装载卷、并与云提供商进行交互以编排卷
|
||||
|
||||
<!--
|
||||
## Node Components
|
||||
-->
|
||||
## Node 组件
|
||||
|
||||
<!--
|
||||
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
|
||||
-->
|
||||
## Node 组件 {#node-components}
|
||||
|
||||
节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。
|
||||
|
||||
### kubelet
|
||||
|
|
@ -154,87 +152,93 @@ Node components run on every node, maintaining running pods and providing the Ku
|
|||
<!--
|
||||
### Container Runtime
|
||||
-->
|
||||
### 容器运行环境(Container Runtime)
|
||||
### 容器运行时（Container Runtime） {#container-runtime}
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
<!--
|
||||
## Addons
|
||||
-->
|
||||
## 插件(Addons)
|
||||
|
||||
<!--
|
||||
Addons use Kubernetes resources ({{< glossary_tooltip term_id="daemonset" >}},
|
||||
{{< glossary_tooltip term_id="deployment" >}}, etc)
|
||||
to implement cluster features. Because these are providing cluster-level features, namespaced resources
|
||||
for addons belong within the `kube-system` namespace.
|
||||
-->
|
||||
插件使用 Kubernetes 资源 ({{< glossary_tooltip term_id="daemonset" >}},
|
||||
{{< glossary_tooltip term_id="deployment" >}}等) 实现集群功能。因为这些提供集群级别的功能，所以插件的命名空间资源属于 `kube-system` 命名空间。
|
||||
## 插件（Addons） {#addons}
|
||||
|
||||
插件使用 Kubernetes 资源（{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}、
|
||||
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}等）实现集群功能。
|
||||
因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 `kube-system` 命名空间。
|
||||
|
||||
<!--
|
||||
Selected addons are described below; for an extended list of available addons, please
|
||||
see [Addons](/docs/concepts/cluster-administration/addons/).
|
||||
-->
|
||||
所选的插件如下所述：有关可用插件的扩展列表，请参见[插件 (Addons)](/docs/concepts/cluster-administration/addons/)。
|
||||
|
||||
### DNS
|
||||
下面描述众多插件中的几种。有关可用插件的完整列表，请参见
|
||||
[插件（Addons）](/zh/docs/concepts/cluster-administration/addons/)。
|
||||
|
||||
<!--
|
||||
### DNS
|
||||
|
||||
While the other addons are not strictly required, all Kubernetes clusters should have [cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it.
|
||||
|
||||
Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services.
|
||||
|
||||
Containers started by Kubernetes automatically include this DNS server in their DNS searches.
|
||||
-->
|
||||
尽管并非严格要求其他附加组件，但所有示例都依赖[集群 DNS](/docs/concepts/services-networking/dns-pod-service/)，因此所有 Kubernetes 集群都应具有 DNS。
|
||||
### DNS {#dns}
|
||||
|
||||
除了您环境中的其他 DNS 服务器之外，集群 DNS 还是一个 DNS 服务器，它为 Kubernetes 服务提供 DNS 记录。
|
||||
尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该
|
||||
有[集群 DNS](/zh/docs/concepts/services-networking/dns-pod-service/)，
|
||||
因为很多示例都需要 DNS 服务。
|
||||
|
||||
Cluster DNS 是一个 DNS 服务器，和您部署环境中的其他 DNS 服务器一起工作，为 Kubernetes 服务提供DNS记录。
|
||||
集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。
|
||||
|
||||
Kubernetes 启动的容器自动将 DNS 服务器包含在 DNS 搜索中。
|
||||
Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。
|
||||
|
||||
<!--
|
||||
### Web UI (Dashboard)
|
||||
-->
|
||||
### 用户界面(Dashboard)
|
||||
|
||||
<!--
|
||||
[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself.
|
||||
-->
|
||||
[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) 是 Kubernetes 集群的通用基于 Web 的 UI。它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
|
||||
### Web 界面（仪表盘）
|
||||
|
||||
[Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) 是K
|
||||
ubernetes 集群的通用的、基于 Web 的用户界面。
|
||||
它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
|
||||
|
||||
<!--
|
||||
### Container Resource Monitoring
|
||||
-->
|
||||
### 容器资源监控
|
||||
|
||||
<!--
|
||||
[Container Resource Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) records generic time-series metrics
|
||||
about containers in a central database, and provides a UI for browsing that data.
|
||||
-->
|
||||
[容器资源监控](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
|
||||
### 容器资源监控
|
||||
|
||||
[容器资源监控](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
|
||||
|
||||
<!--
|
||||
### Cluster-level Logging
|
||||
-->
|
||||
### 集群层面日志
|
||||
|
||||
<!--
|
||||
A [Cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible for
|
||||
saving container logs to a central log store with search/browsing interface.
|
||||
-->
|
||||
[集群层面日志](/docs/concepts/cluster-administration/logging/) 机制负责将容器的日志数据保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。
|
||||
### 集群层面日志
|
||||
|
||||
[集群层面日志](/zh/docs/concepts/cluster-administration/logging/) 机制负责将容器的日志数据
|
||||
保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn about [Nodes](/docs/concepts/architecture/nodes/)
|
||||
* Learn about [Controllers](/docs/concepts/architecture/controller/)
|
||||
* Learn about [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)
|
||||
* Read etcd's official [documentation](https://etcd.io/docs/)
|
||||
-->
|
||||
* 进一步了解 [Nodes](/docs/concepts/architecture/nodes/)
|
||||
* 进一步了解 [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)
|
||||
* 进一步了解[节点](/zh/docs/concepts/architecture/nodes/)
|
||||
* 进一步了解[控制器](/zh/docs/concepts/architecture/controller/)
|
||||
* 进一步了解 [kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
* 阅读 etcd 官方[文档](https://etcd.io/docs/)
|
||||
|
||||
|
|
|
|||
|
|
@ -5,46 +5,39 @@ weight: 50
|
|||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Annotations
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
你可以使用 Kubernetes 注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。
|
||||
<!--
|
||||
You can use Kubernetes annotations to attach arbitrary non-identifying metadata
|
||||
to objects. Clients such as tools and libraries can retrieve this metadata.
|
||||
-->
|
||||
|
||||
你可以使用 Kubernetes 注解为对象附加任意的非标识的元数据。客户端程序（例如工具和库）能够获取这些元数据信息。
|
||||
|
||||
<!-- body -->
|
||||
## 为对象附加元数据
|
||||
<!--
|
||||
## Attaching metadata to objects
|
||||
-->
|
||||
|
||||
您可以使用标签或注解将元数据附加到 Kubernetes 对象。
|
||||
标签可以用来选择对象和查找满足某些条件的对象集合。 相反，注解不用于标识和选择对象。
|
||||
注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。
|
||||
|
||||
<!--
|
||||
You can use either labels or annotations to attach metadata to Kubernetes
|
||||
objects. Labels can be used to select objects and to find
|
||||
collections of objects that satisfy certain conditions. In contrast, annotations
|
||||
are not used to identify and select objects. The metadata
|
||||
in an annotation can be small or large, structured or unstructured, and can
|
||||
include characters not permitted by labels.
|
||||
-->
|
||||
|
||||
|
||||
注解和标签一样，是键/值对:
|
||||
<!--
|
||||
Annotations, like labels, are key/value maps:
|
||||
-->
|
||||
## 为对象附加元数据
|
||||
|
||||
你可以使用标签或注解将元数据附加到 Kubernetes 对象。
|
||||
标签可以用来选择对象和查找满足某些条件的对象集合。 相反，注解不用于标识和选择对象。
|
||||
注解中的元数据，可以很小，也可以很大，可以是结构化的，也可以是非结构化的，能够包含标签不允许的字符。
|
||||
|
||||
注解和标签一样，是键/值对:
|
||||
|
||||
```json
|
||||
"metadata": {
|
||||
|
|
@ -55,75 +48,63 @@ Annotations, like labels, are key/value maps:
|
|||
}
|
||||
```
|
||||
|
||||
以下是一些例子，用来说明哪些信息可以使用注解来记录:
|
||||
<!--
|
||||
Here are some examples of information that could be recorded in annotations:
|
||||
-->
|
||||
|
||||
* 由声明性配置所管理的字段。
|
||||
将这些字段附加为注解，能够将它们与客户端或服务端设置的默认值、自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。
|
||||
以下是一些例子，用来说明哪些信息可以使用注解来记录:
|
||||
|
||||
<!--
|
||||
* Fields managed by a declarative configuration layer. Attaching these fields
|
||||
as annotations distinguishes them from default values set by clients or
|
||||
servers, and from auto-generated fields and fields set by
|
||||
auto-sizing or auto-scaling systems.
|
||||
-->
|
||||
|
||||
* 构建、发布或镜像信息（如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址）。
|
||||
|
||||
<!--
|
||||
* Build, release, or image information like timestamps, release IDs, git branch,
|
||||
PR numbers, image hashes, and registry address.
|
||||
-->
|
||||
|
||||
* 指向日志记录、监控、分析或审计仓库的指针。
|
||||
|
||||
<!--
|
||||
* Pointers to logging, monitoring, analytics, or audit repositories.
|
||||
-->
|
||||
|
||||
* 可用于调试目的的客户端库或工具信息：例如，名称、版本和构建信息。
|
||||
* 由声明性配置所管理的字段。
|
||||
将这些字段附加为注解，能够将它们与客户端或服务端设置的默认值、
|
||||
自动生成的字段以及通过自动调整大小或自动伸缩系统设置的字段区分开来。
|
||||
* 构建、发布或镜像信息（如时间戳、发布 ID、Git 分支、PR 数量、镜像哈希、仓库地址）。
|
||||
* 指向日志记录、监控、分析或审计仓库的指针。
|
||||
|
||||
|
||||
<!--
|
||||
* Client library or tool information that can be used for debugging purposes:
|
||||
for example, name, version, and build information.
|
||||
-->
|
||||
|
||||
* 用户或者工具/系统的来源信息，例如来自其他生态系统组件的相关对象的 URL。
|
||||
|
||||
<!--
|
||||
* User or tool/system provenance information, such as URLs of related objects
|
||||
from other ecosystem components.
|
||||
-->
|
||||
|
||||
* 推出的轻量级工具的元数据信息：例如，配置或检查点。
|
||||
|
||||
<!--
|
||||
* Lightweight rollout tool metadata: for example, config or checkpoints.
|
||||
-->
|
||||
|
||||
* 负责人员的电话或呼机号码，或指定在何处可以找到该信息的目录条目，如团队网站。
|
||||
|
||||
<!--
|
||||
* Phone or pager numbers of persons responsible, or directory entries that
|
||||
specify where that information can be found, such as a team web site.
|
||||
-->
|
||||
|
||||
|
||||
从用户到最终运行的指令，以修改行为或使用非标准功能。
|
||||
<!--
|
||||
* Directives from the end-user to the implementations to modify behavior or
|
||||
engage non-standard features.
|
||||
-->
|
||||
* 可用于调试目的的客户端库或工具信息：例如，名称、版本和构建信息。
|
||||
|
||||
* 用户或者工具/系统的来源信息，例如来自其他生态系统组件的相关对象的 URL。
|
||||
|
||||
* 轻量级上线工具的元数据信息：例如，配置或检查点。
|
||||
|
||||
* 负责人员的电话或呼机号码，或指定在何处可以找到该信息的目录条目，如团队网站。
|
||||
|
||||
* 从用户到最终运行的指令，以修改行为或使用非标准功能。
|
||||
|
||||
您可以将这类信息存储在外部数据库或目录中而不使用注解，但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。
|
||||
<!--
|
||||
Instead of using annotations, you could store this type of information in an
|
||||
external database or directory, but that would make it much harder to produce
|
||||
shared client libraries and tools for deployment, management, introspection,
|
||||
and the like.
|
||||
-->
|
||||
你可以将这类信息存储在外部数据库或目录中而不使用注解，
|
||||
但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。
|
||||
|
||||
<!--
|
||||
## Syntax and character set
|
||||
|
|
@ -132,22 +113,28 @@ _Annotations_ are key/value pairs. Valid annotation keys have two segments: an o
|
|||
|
||||
If the prefix is omitted, the annotation Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add annotations to end-user objects must specify a prefix.
|
||||
-->
|
||||
|
||||
## 语法和字符集
|
||||
_注解_ 存储的形式是键/值对。有效的注解键分为两部分：可选的前缀和名称，以斜杠（`/`）分隔。 名称段是必需项，并且必须在63个字符以内，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，并允许使用破折号（`-`），下划线（`_`），点（`.`）和字母数字。 前缀是可选的。 如果指定，则前缀必须是DNS子域：一系列由点（`.`）分隔的DNS标签，总计不超过253个字符，后跟斜杠（`/`）。
|
||||
如果省略前缀，则假定注释键对用户是私有的。 由系统组件添加的注释（例如，`kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl` 或其他第三方组件），必须为终端用户添加注释前缀。
|
||||
|
||||
_注解（Annotations）_ 存储的形式是键/值对。有效的注解键分为两部分：
|
||||
可选的前缀和名称，以斜杠（`/`）分隔。
|
||||
名称段是必需项，并且必须在63个字符以内，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，
|
||||
并允许使用破折号（`-`），下划线（`_`），点（`.`）和字母数字。
|
||||
前缀是可选的。如果指定，则前缀必须是DNS子域：一系列由点（`.`）分隔的DNS标签，
|
||||
总计不超过253个字符，后跟斜杠（`/`）。
|
||||
如果省略前缀，则假定注释键对用户是私有的。 由系统组件添加的注释
|
||||
（例如，`kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl`
|
||||
或其他第三方组件），必须为终端用户添加注释前缀。
|
||||
|
||||
<!--
|
||||
The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components.
|
||||
|
||||
For example, here’s the configuration file for a Pod that has the annotation `imageregistry: https://hub.docker.com/` :
|
||||
-->
|
||||
`kubernetes.io/` 和 `k8s.io/` 前缀是为Kubernetes核心组件保留的。
|
||||
|
||||
`kubernetes.io /` 和 `k8s.io /` 前缀是为Kubernetes核心组件保留的。
|
||||
例如，这是Pod的配置文件，其注释为 `imageregistry: https://hub.docker.com/`：
|
||||
|
||||
例如，这是Pod的配置文件，其注释为 `imageregistry：https：// hub.docker.com /` ：
|
||||
```yaml
|
||||
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
|
|
@ -160,15 +147,12 @@ spec:
|
|||
image: nginx:1.7.9
|
||||
ports:
|
||||
- containerPort: 80
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
进一步了解[标签和选择器](/docs/concepts/overview/working-with-objects/labels/)。
|
||||
<!--
|
||||
Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/).
|
||||
* Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/).
|
||||
-->
|
||||
* 进一步了解[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。
|
||||
|
||||
|
|
|
|||
|
|
@ -3,16 +3,15 @@ title: 字段选择器
|
|||
weight: 60
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: Field Selectors
|
||||
weight: 60
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
_Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/working-with-objects/kubernetes-objects) based on the value of one or more resource fields. Here are some example field selector queries:
|
||||
-->
|
||||
_字段选择器_（_Field selectors_）允许您根据一个或多个资源字段的值[筛选 Kubernetes 资源](/docs/concepts/overview/working-with-objects/kubernetes-objects)。
|
||||
_字段选择器（Field selectors_）允许你根据一个或多个资源字段的值
|
||||
[筛选 Kubernetes 资源](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。
|
||||
下面是一些使用字段选择器查询的例子：
|
||||
|
||||
* `metadata.name=my-service`
|
||||
|
|
@ -22,18 +21,18 @@ _字段选择器_（_Field selectors_）允许您根据一个或多个资源字
|
|||
<!--
|
||||
This `kubectl` command selects all Pods for which the value of the [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) field is `Running`:
|
||||
-->
|
||||
下面这个 `kubectl` 命令将筛选出 [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) 字段值为 `Running` 的所有 Pod：
|
||||
|
||||
下面这个 `kubectl` 命令将筛选出 [`status.phase`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)
|
||||
字段值为 `Running` 的所有 Pod：
|
||||
|
||||
```shell
|
||||
kubectl get pods --field-selector status.phase=Running
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Field selectors are essentially resource *filters*. By default, no selectors/filters are applied, meaning that all resources of the specified type are selected. This makes the following `kubectl` queries equivalent:
|
||||
-->
|
||||
字段选择器本质上是资源*过滤器*。默认情况下，字段选择器/过滤器是未被应用的，这意味着指定类型的所有资源都会被筛选出来。
|
||||
{{< note >}}
|
||||
字段选择器本质上是资源*过滤器（Filters）*。默认情况下，字段选择器/过滤器是未被应用的，
|
||||
这意味着指定类型的所有资源都会被筛选出来。
|
||||
这使得以下的两个 `kubectl` 查询是等价的：
|
||||
|
||||
```shell
|
||||
|
|
@ -44,30 +43,32 @@ kubectl get pods --field-selector ""
|
|||
|
||||
<!--
|
||||
## Supported fields
|
||||
-->
|
||||
## 支持的字段
|
||||
|
||||
<!--
|
||||
Supported field selectors vary by Kubernetes resource type. All resource types support the `metadata.name` and `metadata.namespace` fields. Using unsupported field selectors produces an error. For example:
|
||||
-->
|
||||
不同的 Kubernetes 资源类型支持不同的字段选择器。所有资源类型都支持 `metadata.name` 和 `metadata.namespace` 字段。使用不被支持的字段选择器会产生错误，例如：
|
||||
## 支持的字段 {#supported-fields}
|
||||
|
||||
不同的 Kubernetes 资源类型支持不同的字段选择器。
|
||||
所有资源类型都支持 `metadata.name` 和 `metadata.namespace` 字段。
|
||||
使用不被支持的字段选择器会产生错误。例如：
|
||||
|
||||
```shell
|
||||
kubectl get ingress --field-selector foo.bar=baz
|
||||
```
|
||||
|
||||
```
|
||||
Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"
|
||||
```
|
||||
|
||||
<!--
|
||||
## Supported operators
|
||||
-->
|
||||
## 支持的运算符
|
||||
|
||||
<!--
|
||||
You can use the `=`, `==`, and `!=` operators with field selectors (`=` and `==` mean the same thing). This `kubectl` command, for example, selects all Kubernetes Services that aren't in the `default` namespace:
|
||||
-->
|
||||
您可以使用 `=`、`==`和 `!=` 对字段选择器进行运算（`=` 和 `==` 的意义是相同的）。例如，下面这个 `kubectl` 命令将筛选所有不属于 `default` 命名空间的 Kubernetes Service：
|
||||
## 支持的操作符 {#supported-operators}
|
||||
|
||||
你可在字段选择器中使用 `=`、`==`和 `!=` （`=` 和 `==` 的意义是相同的）操作符。
|
||||
例如，下面这个 `kubectl` 命令将筛选所有不属于 `default` 命名空间的 Kubernetes 服务：
|
||||
|
||||
```shell
|
||||
kubectl get services --all-namespaces --field-selector metadata.namespace!=default
|
||||
|
|
@ -75,13 +76,15 @@ kubectl get services --all-namespaces --field-selector metadata.namespace!=defa
|
|||
|
||||
<!--
|
||||
## Chained selectors
|
||||
-->
|
||||
## 链式选择器
|
||||
|
||||
<!--
|
||||
As with [label](/docs/concepts/overview/working-with-objects/labels) and other selectors, field selectors can be chained together as a comma-separated list. This `kubectl` command selects all Pods for which the `status.phase` does not equal `Running` and the `spec.restartPolicy` field equals `Always`:
|
||||
-->
|
||||
同[标签](/docs/concepts/overview/working-with-objects/labels)和其他选择器一样，字段选择器可以通过使用逗号分隔的列表组成一个选择链。下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod：
|
||||
## 链式选择器 {#chained-selectors}
|
||||
|
||||
同[标签](/zh/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样，
|
||||
字段选择器可以通过使用逗号分隔的列表组成一个选择链。
|
||||
下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时
|
||||
`spec.restartPolicy` 字段等于 `Always` 的所有 Pod：
|
||||
|
||||
```shell
|
||||
kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
|
||||
|
|
@ -89,13 +92,13 @@ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Alway
|
|||
|
||||
<!--
|
||||
## Multiple resource types
|
||||
-->
|
||||
## 多种资源类型
|
||||
|
||||
<!--
|
||||
You use field selectors across multiple resource types. This `kubectl` command selects all Statefulsets and Services that are not in the `default` namespace:
|
||||
-->
|
||||
您能够跨多种资源类型来使用字段选择器。下面这个 `kubectl` 命令将筛选出所有不在 `default` 命名空间中的 StatefulSet 和 Service：
|
||||
## 多种资源类型 {#multiple-resource-types}
|
||||
|
||||
你能够跨多种资源类型来使用字段选择器。
|
||||
下面这个 `kubectl` 命令将筛选出所有不在 `default` 命名空间中的 StatefulSet 和 Service：
|
||||
|
||||
```shell
|
||||
kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
|
||||
|
|
|
|||
|
|
@ -33,51 +33,82 @@ This page explains how Kubernetes objects are represented in the Kubernetes API,
|
|||
* The resources available to those applications
|
||||
* The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
|
||||
-->
|
||||
|
||||
## 理解 Kubernetes 对象
|
||||
|
||||
在 Kubernetes 系统中，*Kubernetes 对象* 是持久化的实体。Kubernetes 使用这些实体去表示整个集群的状态。特别地，它们描述了如下信息：
|
||||
在 Kubernetes 系统中，*Kubernetes 对象* 是持久化的实体。
|
||||
Kubernetes 使用这些实体去表示整个集群的状态。特别地，它们描述了如下信息：
|
||||
|
||||
* 哪些容器化应用在运行（以及在哪个 Node 上）
|
||||
* 哪些容器化应用在运行（以及在哪些节点上）
|
||||
* 可以被应用使用的资源
|
||||
* 关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略
|
||||
|
||||
<!--
|
||||
A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's *desired state*.
|
||||
A Kubernetes object is a "record of intent" - once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's *desired state*.
|
||||
|
||||
To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the [Client Libraries](/docs/reference/using-api/client-libraries/).
|
||||
To work with Kubernetes objects - whether to create, modify, or delete them - you'll need to use the [Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the [Client Libraries](/docs/reference/using-api/client-libraries/).
|
||||
-->
|
||||
Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。
|
||||
通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，
|
||||
这就是 Kubernetes 集群的 **期望状态（Desired State）**。
|
||||
|
||||
Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群的 **期望状态（Desired State）**。
|
||||
|
||||
操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中使用 [客户端库](/docs/reference/using-api/client-libraries/) 直接调用 Kubernetes API。
|
||||
操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用
|
||||
[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api)。
|
||||
比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，
|
||||
也可以在程序中使用
|
||||
[客户端库](/zh/docs/reference/using-api/client-libraries/)直接调用 Kubernetes API。
|
||||
|
||||
<!--
|
||||
### Object Spec and Status
|
||||
|
||||
Every Kubernetes object includes two nested object fields that govern the object's configuration: the object *spec* and the object *status*. The *spec*, which you must provide, describes your desired state for the object--the characteristics that you want the object to have. The *status* describes the *actual state* of the object, and is supplied and updated by the Kubernetes system. At any given time, the Kubernetes Control Plane actively manages an object's actual state to match the desired state you supplied.
|
||||
Almost every Kubernetes object includes two nested object fields that govern
|
||||
the object's configuration: the object *`spec`* and the object *`status`*.
|
||||
For objects that have a `spec`, you have to set this when you create the object,
|
||||
providing a description of the characteristics you want the resource to have:
|
||||
its _desired state_.
|
||||
-->
|
||||
### 对象规约（Spec）与状态（Status） {#object-spec-and-status}
|
||||
|
||||
### 对象规约（Spec）与状态（Status）
|
||||
|
||||
每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：对象 *spec* 和 对象 *status* 。
|
||||
*spec* 是必需的，它描述了对象的 *期望状态（Desired State）* —— 希望对象所具有的特征。
|
||||
*status* 描述了对象的 *实际状态（Actual State）* ，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。
|
||||
几乎每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：
|
||||
对象 *`spec`（规约）* 和 对象 *`status`（状态）* 。
|
||||
对于具有 `spec` 的对象，你必须在创建对象时设置其内容，描述你希望对象所具有的特征：
|
||||
*期望状态（Desired State）* 。
|
||||
|
||||
<!--
|
||||
For example, a Kubernetes Deployment is an object that can represent an application running on your cluster. When you create the Deployment, you might set the Deployment spec to specify that you want three replicas of the application to be running. The Kubernetes system reads the Deployment spec and starts three instances of your desired application--updating the status to match your spec. If any of those instances should fail (a status change), the Kubernetes system responds to the difference between spec and status by making a correction--in this case, starting a replacement instance.
|
||||
The `status` describes the _current state_ of the object, supplied and updated
|
||||
by the Kubernetes system and its components. The Kubernetes
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}} continually
|
||||
and actively manages every object's actual state to match the desired state you
|
||||
supplied.
|
||||
-->
|
||||
`status` 描述了对象的 _当前状态（Current State）_，它是由 Kubernetes 系统和组件
|
||||
设置并更新的。在任何时刻，Kubernetes
|
||||
{{< glossary_tooltip text="控制面" term_id="control-plane" >}}
|
||||
都一直积极地管理着对象的实际状态，以使之与期望状态相匹配。
|
||||
|
||||
例如，Kubernetes Deployment 对象能够表示运行在集群中的应用。
|
||||
当创建 Deployment 时，可能需要设置 Deployment 的规约，以指定该应用需要有 3 个副本在运行。
|
||||
Kubernetes 系统读取 Deployment 规约，并启动我们所期望的该应用的 3 个实例 —— 更新状态以与规约相匹配。
|
||||
如果那些实例中有失败的（一种状态变更），Kubernetes 系统通过修正来响应规约和状态之间的不一致 —— 这种情况，会启动一个新的实例来替换。
|
||||
<!--
|
||||
For example: in Kubernetes, a Deployment is an object that can represent an
|
||||
application running on your cluster. When you create the Deployment, you
|
||||
might set the Deployment `spec` to specify that you want three replicas of
|
||||
the application to be running. The Kubernetes system reads the Deployment
|
||||
spec and starts three instances of your desired application-updating
|
||||
the status to match your spec. If any of those instances should fail
|
||||
(a status change), the Kubernetes system responds to the difference
|
||||
between spec and status by making a correction-in this case, starting
|
||||
a replacement instance.
|
||||
-->
|
||||
例如，Kubernetes 中的 Deployment 对象能够表示运行在集群中的应用。
|
||||
当创建 Deployment 时，可能需要设置 Deployment 的 `spec`，以指定该应用需要有 3 个副本运行。
|
||||
Kubernetes 系统读取 Deployment 规约，并启动我们所期望的应用的 3 个实例
|
||||
—— 更新状态以与规约相匹配。
|
||||
如果这些实例中有的失败了（一种状态变更），Kubernetes 系统通过执行修正操作
|
||||
来响应规约和状态间的不一致 —— 在这里意味着它会启动一个新的实例来替换。
|
||||
|
||||
<!--
|
||||
For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
|
||||
-->
|
||||
|
||||
关于对象 spec、status 和 metadata 的更多信息，查看 [Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。
|
||||
关于对象 spec、status 和 metadata 的更多信息，可参阅
|
||||
[Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。
|
||||
|
||||
<!--
|
||||
### Describing a Kubernetes Object
|
||||
|
|
@ -86,11 +117,12 @@ When you create an object in Kubernetes, you must provide the object spec that d
|
|||
|
||||
Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:
|
||||
-->
|
||||
|
||||
### 描述 Kubernetes 对象
|
||||
|
||||
当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。
|
||||
当使用 Kubernetes API 创建对象时（或者直接创建，或者基于`kubectl`），API 请求必须在请求体中包含 JSON 格式的信息。
|
||||
创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，
|
||||
以及关于对象的一些基本信息（例如名称）。
|
||||
当使用 Kubernetes API 创建对象时（或者直接创建，或者基于`kubectl`），
|
||||
API 请求必须在请求体中包含 JSON 格式的信息。
|
||||
**大多数情况下，需要在 .yaml 文件中为 `kubectl` 提供这些信息**。
|
||||
`kubectl` 在发起 API 请求时，将这些信息转换成 JSON 格式。
|
||||
|
||||
|
|
@ -103,8 +135,7 @@ One way to create a Deployment using a `.yaml` file like the one above is to use
|
|||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command
|
||||
in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
|
||||
-->
|
||||
|
||||
使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的
|
||||
使用类似于上面的 `.yaml` 文件来创建 Deployment的一种方式是使用 `kubectl` 命令行接口（CLI）中的
|
||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 命令，
|
||||
将 `.yaml` 文件作为参数。下面是一个示例：
|
||||
|
||||
|
|
@ -115,10 +146,9 @@ kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
|
|||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
|
||||
输出类似如下这样：
|
||||
|
||||
```shell
|
||||
```
|
||||
deployment.apps/nginx-deployment created
|
||||
```
|
||||
|
||||
|
|
@ -131,14 +161,13 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
|
|||
* `kind` - What kind of object you want to create
|
||||
* `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`
|
||||
-->
|
||||
|
||||
### 必需字段
|
||||
### 必需字段 {#required-fields}
|
||||
|
||||
在想要创建的 Kubernetes 对象对应的 `.yaml` 文件中，需要配置如下的字段：
|
||||
|
||||
* `apiVersion` - 创建该对象所使用的 Kubernetes API 的版本
|
||||
* `kind` - 想要创建的对象的类型
|
||||
* `metadata` - 帮助识别对象唯一性的数据，包括一个 `name` 字符串、UID 和可选的 `namespace`
|
||||
* `kind` - 想要创建的对象的类别
|
||||
* `metadata` - 帮助唯一性标识对象的一些数据，包括一个 `name` 字符串、UID 和可选的 `namespace`
|
||||
|
||||
<!--
|
||||
You'll also need to provide the object `spec` field. The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) can help you find the spec format for all of the objects you can create using Kubernetes.
|
||||
|
|
@ -147,13 +176,15 @@ For example, the `spec` format for a `Pod` can be found
|
|||
and the `spec` format for a `Deployment` can be found
|
||||
[here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
|
||||
-->
|
||||
|
||||
您也需要提供对象的 `spec` 字段。对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。[Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)能够帮助我们找到任何我们想创建的对象的 spec 格式。
|
||||
你也需要提供对象的 `spec` 字段。
|
||||
对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。
|
||||
[Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
能够帮助我们找到任何我们想创建的对象的 spec 格式。
|
||||
例如，可以从
|
||||
[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
[core/v1 PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
|
||||
查看 `Pod` 的 `spec` 格式，
|
||||
并且可以从
|
||||
[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)
|
||||
[apps/v1 DeploymentSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)
|
||||
查看 `Deployment` 的 `spec` 格式。
|
||||
|
||||
|
||||
|
|
@ -164,9 +195,7 @@ and the `spec` format for a `Deployment` can be found
|
|||
* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
|
||||
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
|
||||
-->
|
||||
* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) 提供关于 API 概念的进一步阐述
|
||||
* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/docs/concepts/workloads/pods/pod-overview/)。
|
||||
* 了解 Kubernetes 中的[控制器](/docs/concepts/architecture/controller/)。
|
||||
|
||||
|
||||
* [Kubernetes API 概述](/zh/docs/reference/using-api/api-overview/) 提供关于 API 概念的进一步阐述
|
||||
* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)
|
||||
* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,26 +1,26 @@
|
|||
---
|
||||
title: 标签和选择器
|
||||
title: 标签和选择算符
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- mikedanese
|
||||
title: Labels and Selectors
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
_Labels_ are key/value pairs that are attached to objects, such as pods.
|
||||
Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system.
|
||||
Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modified at any time.
|
||||
Labels can be used to organize and to select subsets of objects.
|
||||
Labels can be attached to objects at creation time and subsequently added and modified at any time.
|
||||
Each object can have a set of key/value labels defined. Each Key must be unique for a given object.
|
||||
-->
|
||||
_标签_ 是附加到 Kubernetes 对象（比如 Pods）上的键值对。
|
||||
_标签（Labels）_ 是附加到 Kubernetes 对象（比如 Pods）上的键值对。
|
||||
标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。
|
||||
标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。
|
||||
每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。
|
||||
|
|
@ -35,116 +35,135 @@ _标签_ 是附加到 Kubernetes 对象（比如 Pods）上的键值对。
|
|||
```
|
||||
|
||||
<!--
|
||||
We'll eventually index and reverse-index labels for efficient queries and watches, use them to sort and group in UIs and CLIs, etc. We don't want to pollute labels with non-identifying, especially large and/or structured, data. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/).
|
||||
Labels allow for efficient queries and watches and are ideal for use in UIs
|
||||
and CLIs. Non-identifying information should be recorded using
|
||||
[annotations](/docs/concepts/overview/working-with-objects/annotations/).
|
||||
-->
|
||||
|
||||
我们最终将标签索引和反向索引，用于高效查询和监视，使用它们在 UI 和 CLI 中进行排序和分组等。我们不希望将非标识性的、尤其是大型或结构化数据用作标签，给后者带来污染。应使用 [注解](/docs/concepts/overview/working-with-objects/annotations/) 记录非识别信息
|
||||
|
||||
|
||||
|
||||
标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。
|
||||
应使用[注解](/zh/docs/concepts/overview/working-with-objects/annotations/) 记录非识别信息。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Motivation
|
||||
-->
|
||||
|
||||
## 动机
|
||||
|
||||
<!--
|
||||
Labels enable users to map their own organizational structures onto system objects in a loosely coupled fashion, without requiring clients to store these mappings.
|
||||
-->
|
||||
## 动机
|
||||
|
||||
标签使用户能够以松散耦合的方式将他们自己的组织结构映射到系统对象，而无需客户端存储这些映射。
|
||||
|
||||
<!--
|
||||
Service deployments and batch processing pipelines are often multi-dimensional entities (e.g., multiple partitions or deployments, multiple release tracks, multiple tiers, multiple micro-services per tier). Management often requires cross-cutting operations, which breaks encapsulation of strictly hierarchical representations, especially rigid hierarchies determined by the infrastructure rather than by users.
|
||||
-->
|
||||
服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发行序列、多个层，每层多个微服务）。管理通常需要交叉操作，这打破了严格的层次表示的封装，特别是由基础设施而不是用户确定的严格的层次结构。
|
||||
|
||||
<!--
|
||||
Example labels:
|
||||
-->
|
||||
服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发行序列、多个层，每层多个微服务）。
|
||||
管理通常需要交叉操作，这打破了严格的层次表示的封装，特别是由基础设施而不是用户确定的严格的层次结构。
|
||||
|
||||
示例标签：
|
||||
|
||||
* `"release" : "stable"`, `"release" : "canary"`
|
||||
* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"`
|
||||
* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"`
|
||||
* `"partition" : "customerA"`, `"partition" : "customerB"`
|
||||
* `"track" : "daily"`, `"track" : "weekly"`
|
||||
* `"release" : "stable"`, `"release" : "canary"`
|
||||
* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"`
|
||||
* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"`
|
||||
* `"partition" : "customerA"`, `"partition" : "customerB"`
|
||||
* `"track" : "daily"`, `"track" : "weekly"`
|
||||
|
||||
<!--
|
||||
These are just examples of commonly used labels; you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object.
|
||||
These are just examples of commonly used labels;
|
||||
you are free to develop your own conventions.
|
||||
Keep in mind that label Key must be unique for a given object.
|
||||
-->
|
||||
这些只是常用标签的例子; 您可以任意制定自己的约定。请记住，对于给定对象标签的键必须是唯一的。
|
||||
这些只是常用标签的例子; 你可以任意制定自己的约定。请记住，对于给定对象标签的键必须是唯一的。
|
||||
|
||||
<!--
|
||||
## Syntax and character set
|
||||
|
||||
_Labels_ are key/value pairs. Valid label keys have two segments: an optional prefix and name, separated by a slash (`/`). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (`.`), not longer than 253 characters in total, followed by a slash (`/`).
|
||||
|
||||
If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix.
|
||||
|
||||
The `kubernetes.io/` prefix is reserved for Kubernetes core components.
|
||||
-->
|
||||
## 语法和字符集
|
||||
|
||||
_标签_ 是键值对。有效的标签键有两个段：可选的前缀和名称，用斜杠（`/`）分隔。
|
||||
名称段是必需的，必须小于等于 63 个字符，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，
|
||||
带有破折号（`-`），下划线（`_`），点（ `.`）和之间的字母数字。
|
||||
前缀是可选的。如果指定，前缀必须是 DNS 子域：由点（`.`）分隔的一系列 DNS 标签，总共不超过 253 个字符，
|
||||
后跟斜杠（`/`）。
|
||||
|
||||
<!--
|
||||
_Labels_ are key/value pairs. Valid label keys have two segments: an optional prefix and name, separated by a slash (`/`). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (`.`), not longer than 253 characters in total, followed by a slash (`/`).
|
||||
If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix. The `kubernetes.io/` prefix is reserved for Kubernetes core components.
|
||||
-->
|
||||
_标签_ 是键值对。有效的标签键有两个段：可选的前缀和名称，用斜杠（`/`）分隔。名称段是必需的，必须小于等于 63 个字符，以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，带有破折号（`-`），下划线（`_`），点（ `.`）和之间的字母数字。前缀是可选的。如果指定，前缀必须是 DNS 子域：由点（`.`）分隔的一系列 DNS 标签，总共不超过 253 个字符，后跟斜杠（`/`）。
|
||||
如果省略前缀，则假定标签键对用户是私有的。 向最终用户对象添加标签的自动系统组件（例如 `kube-scheduler`，`kube-controller-manager`，`kube-apiserver`，`kubectl` 或其他第三方自动化）必须指定前缀。`kubernetes.io/` 前缀是为 Kubernetes 核心组件保留的。
|
||||
如果省略前缀，则假定标签键对用户是私有的。
|
||||
向最终用户对象添加标签的自动系统组件（例如 `kube-scheduler`、`kube-controller-manager`、
|
||||
`kube-apiserver`、`kubectl` 或其他第三方自动化工具）必须指定前缀。
|
||||
|
||||
`kubernetes.io/` 前缀是为 Kubernetes 核心组件保留的。
|
||||
|
||||
<!--
|
||||
Valid label values must be 63 characters or less and must be empty or begin and end with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between.
|
||||
-->
|
||||
有效标签值必须为 63 个字符或更少，并且必须为空或以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，中间可以包含破折号（`-`）、下划线（`_`）、点（`.`）和字母或数字。
|
||||
有效标签值必须为 63 个字符或更少，并且必须为空或以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，
|
||||
中间可以包含破折号（`-`）、下划线（`_`）、点（`.`）和字母或数字。
|
||||
|
||||
<!--
|
||||
## Label selectors
|
||||
-->
|
||||
## 标签选择器
|
||||
|
||||
<!--
|
||||
Unlike [names and UIDs](/docs/user-guide/identifiers), labels do not provide uniqueness. In general, we expect many objects to carry the same label(s).
|
||||
-->
|
||||
与 [名称和 UID](/docs/user-guide/identifiers) 不同，标签不提供唯一性。通常，我们希望许多对象携带相同的标签。
|
||||
## 标签选择算符 {#label-selectors}
|
||||
|
||||
与[名称和 UID](/zh/docs/concepts/overview/working-with-objects/names/) 不同，
|
||||
标签不支持唯一性。通常，我们希望许多对象携带相同的标签。
|
||||
|
||||
<!--
|
||||
Via a _label selector_, the client/user can identify a set of objects. The label selector is the core grouping primitive in Kubernetes.
|
||||
-->
|
||||
通过 _标签选择器_，客户端/用户可以识别一组对象。标签选择器是 Kubernetes 中的核心分组原语。
|
||||
通过 _标签选择算符_，客户端/用户可以识别一组对象。标签选择算符是 Kubernetes 中的核心分组原语。
|
||||
|
||||
<!--
|
||||
The API currently supports two types of selectors: _equality-based_ and _set-based_.
|
||||
A label selector can be made of multiple _requirements_ which are comma-separated. In the case of multiple requirements, all must be satisfied so the comma separator acts as a logical _AND_ (`&&`) operator.
|
||||
-->
|
||||
API 目前支持两种类型的选择器：_基于相等性的_ 和 _基于集合的_。
|
||||
标签选择器可以由逗号分隔的多个 _需求_ 组成。在多个需求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑 _与_（`&&`）运算符。
|
||||
API 目前支持两种类型的选择算符：_基于等值的_ 和 _基于集合的_。
|
||||
标签选择算符可以由逗号分隔的多个 _需求_ 组成。
|
||||
在多个需求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑 _与_（`&&`）运算符。
|
||||
|
||||
<!--
|
||||
An empty label selector (that is, one with zero requirements) selects every object in the collection.
|
||||
The semantics of empty or non-specified selectors are dependent on the context,
|
||||
and API types that use selectors should document the validity and meaning of
|
||||
them.
|
||||
-->
|
||||
空标签选择器（即，需求为零的选择器）选择集合中的每个对象。
|
||||
空标签选择算符或者未指定的选择算符的语义取决于上下文，
|
||||
支持使用选择算符的 API 类别应该将算符的合法性和含义用文档记录下来。
|
||||
|
||||
<!--
|
||||
A null label selector (which is only possible for optional selector fields) selects no objects.
|
||||
For some API types, such as ReplicaSets, the label selectors of two instances must not overlap within a namespace, or the controller can see that as conflicting instructions and fail to determine how many replicas should be present.
|
||||
-->
|
||||
null 值的标签选择器（仅可用于可选选择器字段）不选择任何对象
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note**: the label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other.
|
||||
-->
|
||||
**注意**：两个控制器的标签选择器不得在命名空间内重叠，否则它们将互相冲突。
|
||||
对于某些 API 类别（例如 ReplicaSet）而言，两个实例的标签选择算符不得在命名空间内重叠，
|
||||
否则它们的控制器将互相冲突，无法确定应该存在的副本个数。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### _Equality-based_ requirement
|
||||
For both equality-based and set-based conditions there is no logical _OR_ (`||`) operator. Ensure your filter statements are structured accordingly.
|
||||
-->
|
||||
### _基于相等性的_ 需求
|
||||
|
||||
{{< caution >}}
|
||||
对于基于等值的和基于集合的条件而言，不存在逻辑或（`||`）操作符。
|
||||
你要确保你的过滤语句按合适的方式组织。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
### _Equality-based_ requirement
|
||||
|
||||
_Equality-_ or _inequality-based_ requirements allow filtering by label keys and values. Matching objects must satisfy all of the specified label constraints, though they may have additional labels as well.
|
||||
Three kinds of operators are admitted `=`,`==`,`!=`. The first two represent _equality_ (and are simply synonyms), while the latter represents _inequality_. For example:
|
||||
-->
|
||||
_基于相等性_ 或 _不相等_ 的需求允许按标签键和值进行过滤。匹配对象必须满足所有指定的标签约束，尽管它们也可能具有其他标签。
|
||||
可接受的运算符有`=`、`==` 和 `！=` 三种。 前两个表示 _相等_（并且只是同义词），而后者表示 _不相等_。 例如：
|
||||
### _基于等值的_ 需求
|
||||
|
||||
_基于等值_ 或 _基于不等值_ 的需求允许按标签键和值进行过滤。
|
||||
匹配对象必须满足所有指定的标签约束，尽管它们也可能具有其他标签。
|
||||
可接受的运算符有`=`、`==` 和 `！=` 三种。
|
||||
前两个表示 _相等_（并且只是同义词），而后者表示 _不相等_。例如：
|
||||
|
||||
```
|
||||
environment = production
|
||||
|
|
@ -165,7 +184,8 @@ One usage scenario for equality-based label requirement is for Pods to specify
|
|||
node selection criteria. For example, the sample Pod below selects nodes with
|
||||
the label "`accelerator=nvidia-tesla-p100`".
|
||||
-->
|
||||
基于相等性的标签要求的一种使用场景是 Pods 要指定节点选择标准。例如，下面的示例 Pod 选择带有标签 "`accelerator=nvidia-tesla-p100`"。
|
||||
基于等值的标签要求的一种使用场景是 Pod 要指定节点选择标准。
|
||||
例如，下面的示例 Pod 选择带有标签 "`accelerator=nvidia-tesla-p100`"。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -185,13 +205,13 @@ spec:
|
|||
|
||||
<!--
|
||||
### _Set-based_ requirement
|
||||
|
||||
_Set-based_ label requirements allow filtering keys according to a set of values. Three kinds of operators are supported: `in`,`notin` and `exists` (only the key identifier). For example:
|
||||
-->
|
||||
### _基于集合_ 的需求
|
||||
|
||||
<!--
|
||||
_Set-based_ label requirements allow filtering keys according to a set of values. Three kinds of operators are supported: `in`,`notin` and `exists` (only the key identifier). For example:
|
||||
-->
|
||||
_基于集合_ 的标签需求允许您通过一组值来过滤键。支持三种操作符：`in`,`notin` and `exists` (只可以用在键标识符上)。例如：
|
||||
_基于集合_ 的标签需求允许你通过一组值来过滤键。
|
||||
支持三种操作符：`in`、`notin` 和 `exists` (只可以用在键标识符上)。例如：
|
||||
|
||||
```
|
||||
environment in (production, qa)
|
||||
|
|
@ -202,38 +222,24 @@ partition
|
|||
|
||||
<!--
|
||||
The first example selects all resources with key equal to `environment` and value equal to `production` or `qa`.
|
||||
The second example selects all resources with key equal to `tier` and values other than `frontend` and `backend`, and all resources with no labels with the `tier` key.
|
||||
The third example selects all resources including a label with key `partition`; no values are checked.
|
||||
The fourth example selects all resources without a label with key `partition`; no values are checked.
|
||||
Similarly the comma separator acts as an _AND_ operator. So filtering resources with a `partition` key (no matter the value) and with `environment` different than `qa` can be achieved using `partition,environment notin (qa)`.
|
||||
-->
|
||||
|
||||
第一个示例选择了所有键等于 `environment` 并且值等于 `production` 或者 `qa` 的资源。
|
||||
|
||||
<!--
|
||||
The second example selects all resources with key equal to `tier` and values other than `frontend` and `backend`, and all resources with no labels with the `tier` key.
|
||||
-->
|
||||
|
||||
第二个示例选择了所有键等于 `tier` 并且值不等于 `frontend` 或者 `backend` 的资源，以及所有没有 `tier` 键标签的资源。
|
||||
|
||||
<!--
|
||||
The third example selects all resources including a label with key `partition`; no values are checked.
|
||||
--->
|
||||
|
||||
第三个示例选择了所有包含了有 `partition` 标签的资源；没有校验它的值。
|
||||
|
||||
<!--
|
||||
The fourth example selects all resources without a label with key `partition`; no values are checked.
|
||||
-->
|
||||
|
||||
第四个示例选择了所有没有 `partition` 标签的资源；没有校验它的值。
|
||||
|
||||
<!--
|
||||
Similarly the comma separator acts as an _AND_ operator. So filtering resources with a `partition` key (no matter the value) and with `environment` different than `qa` can be achieved using `partition,environment notin (qa)`.
|
||||
-->
|
||||
类似地，逗号分隔符充当 _AND_ 运算符。因此，使用 `partition` 键（无论为何值）和 `environment` 不同于 `qa` 来过滤资源可以使用 `partition，environment notin（qa)` 来实现。
|
||||
类似地，逗号分隔符充当 _与_ 运算符。因此，使用 `partition` 键（无论为何值）和
|
||||
`environment` 不同于 `qa` 来过滤资源可以使用 `partition, environment notin（qa)` 来实现。
|
||||
|
||||
<!--
|
||||
The _set-based_ label selector is a general form of equality since `environment=production` is equivalent to `environment in (production)`; similarly for `!=` and `notin`.
|
||||
-->
|
||||
|
||||
_基于集合_ 的标签选择器是相等标签选择器的一般形式，因为 `environment = production` 等同于 `environment in（production）`;`！=` 和 `notin` 也是类似的。
|
||||
_基于集合_ 的标签选择算符是相等标签选择算符的一般形式，因为 `environment=production`
|
||||
等同于 `environment in（production`；`!=` 和 `notin` 也是类似的。
|
||||
|
||||
<!--
|
||||
_Set-based_ requirements can be mixed with _equality-based_ requirements. For example: `partition in (customerA, customerB),environment!=qa`.
|
||||
|
|
@ -244,38 +250,37 @@ _基于集合_ 的要求可以与基于 _相等_ 的要求混合使用。例如
|
|||
|
||||
<!--
|
||||
### LIST and WATCH filtering
|
||||
|
||||
LIST and WATCH operations may specify label selectors to filter the sets of objects returned using a query parameter. Both requirements are permitted (presented here as they would appear in a URL query string):
|
||||
-->
|
||||
### LIST 和 WATCH 过滤
|
||||
|
||||
<!--
|
||||
LIST and WATCH operations may specify label selectors to filter the sets of objects returned using a query parameter. Both requirements are permitted (presented here as they would appear in a URL query string):
|
||||
-->
|
||||
LIST and WATCH 操作可以使用查询参数指定标签选择器过滤一组对象。两种需求都是允许的。（这里显示的是它们出现在 URL 查询字符串中）
|
||||
LIST and WATCH 操作可以使用查询参数指定标签选择算符过滤一组对象。
|
||||
两种需求都是允许的。（这里显示的是它们出现在 URL 查询字符串中）
|
||||
|
||||
<!--
|
||||
* _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
||||
* _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
||||
* _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
||||
* _set-based_ requirements: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
||||
-->
|
||||
* _基于相等性_ 的需求: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
||||
* _基于集合_ 的需求: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
||||
* _基于等值_ 的需求: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
||||
* _基于集合_ 的需求: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
|
||||
|
||||
<!--
|
||||
Both label selector styles can be used to list or watch resources via a REST client. For example, targeting `apiserver` with `kubectl` and using _equality-based_ one may write:
|
||||
-->
|
||||
两种标签选择器都可以通过 REST 客户端用于 list 或者 watch 资源。例如，使用 `kubectl` 定位 `apiserver`，可以使用 _基于相等性_ 的标签选择器可以这么写：
|
||||
两种标签选择算符都可以通过 REST 客户端用于 list 或者 watch 资源。
|
||||
例如，使用 `kubectl` 定位 `apiserver`，可以使用 _基于等值_ 的标签选择算符可以这么写：
|
||||
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -l environment=production,tier=frontend
|
||||
kubectl get pods -l environment=production,tier=frontend
|
||||
```
|
||||
|
||||
<!--
|
||||
or using _set-based_ requirements:
|
||||
-->
|
||||
<!-- or using _set-based_ requirements: -->
|
||||
或者使用 _基于集合的_ 需求：
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -l 'environment in (production),tier in (frontend)'
|
||||
kubectl get pods -l 'environment in (production),tier in (frontend)'
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
@ -284,26 +289,30 @@ As already mentioned _set-based_ requirements are more expressive. For instanc
|
|||
正如刚才提到的，_基于集合_ 的需求更具有表达力。例如，它们可以实现值的 _或_ 操作：
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -l 'environment in (production, qa)'
|
||||
kubectl get pods -l 'environment in (production, qa)'
|
||||
```
|
||||
|
||||
<!--
|
||||
or restricting negative matching via _exists_ operator:
|
||||
-->
|
||||
<!-- or restricting negative matching via _exists_ operator: -->
|
||||
或者通过 _exists_ 运算符限制不匹配：
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -l 'environment,environment notin (frontend)'
|
||||
kubectl get pods -l 'environment,environment notin (frontend)'
|
||||
```
|
||||
|
||||
<!--
|
||||
### Set references in API objects
|
||||
|
||||
Some Kubernetes objects, such as [`services`](/docs/user-guide/services) and [`replicationcontrollers`](/docs/user-guide/replication-controller), also use label selectors to specify sets of other resources, such as [pods](/docs/user-guide/pods).
|
||||
Some Kubernetes objects, such as [`services`](/docs/concepts/services-networking/service/)
|
||||
and [`replicationcontrollers`](/docs/concepts/workloads/controllers/replicationcontroller/),
|
||||
also use label selectors to specify sets of other resources, such as
|
||||
[pods](/docs/concepts/workloads/pods/).
|
||||
-->
|
||||
### 在 API 对象上设置引用
|
||||
|
||||
一些 Kubernetes 对象，例如 [`services`](/docs/user-guide/services) 和 [`replicationcontrollers`](/docs/user-guide/replication-controller) ，也使用了标签选择器去指定了其他资源的集合，例如 [pods](/docs/user-guide/pods)。
|
||||
一些 Kubernetes 对象，例如 [`services`](/zh/docs/concepts/services-networking/service/)
|
||||
和 [`replicationcontrollers`](/zh/docs/concepts/workloads/controllers/replicationcontroller/) ，
|
||||
也使用了标签选择算符去指定了其他资源的集合，例如
|
||||
[pods](/zh/docs/concepts/workloads/pods/)。
|
||||
|
||||
<!--
|
||||
#### Service and ReplicationController
|
||||
|
|
@ -314,9 +323,9 @@ Labels selectors for both objects are defined in `json` or `yaml` files using ma
|
|||
-->
|
||||
#### Service 和 ReplicationController
|
||||
|
||||
一个 `Service` 指向的一组 pods 是由标签选择器定义的。同样，一个 `ReplicationController` 应该管理的 pods 的数量也是由标签选择器定义的。
|
||||
一个 `Service` 指向的一组 pods 是由标签选择算符定义的。同样，一个 `ReplicationController` 应该管理的 pods 的数量也是由标签选择算符定义的。
|
||||
|
||||
两个对象的标签选择器都是在 `json` 或者 `yaml` 文件中使用映射定义的，并且只支持 _基于相等性_ 需求的选择器：
|
||||
两个对象的标签选择算符都是在 `json` 或者 `yaml` 文件中使用映射定义的，并且只支持 _基于等值_ 需求的选择算符：
|
||||
|
||||
```json
|
||||
"selector": {
|
||||
|
|
@ -324,9 +333,7 @@ Labels selectors for both objects are defined in `json` or `yaml` files using ma
|
|||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
or
|
||||
-->
|
||||
<!-- or -->
|
||||
或者
|
||||
|
||||
```yaml
|
||||
|
|
@ -337,7 +344,7 @@ selector:
|
|||
<!---
|
||||
this selector (respectively in `json` or `yaml` format) is equivalent to `component=redis` or `component in (redis)`.
|
||||
-->
|
||||
这个选择器(分别在 `json` 或者 `yaml` 格式中) 等价于 `component=redis` 或 `component in (redis)` 。
|
||||
这个选择算符(分别在 `json` 或者 `yaml` 格式中) 等价于 `component=redis` 或 `component in (redis)` 。
|
||||
|
||||
<!--
|
||||
#### Resources that support set-based requirements
|
||||
|
|
@ -346,7 +353,11 @@ Newer resources, such as [`Job`](/docs/concepts/jobs/run-to-completion-finite-wo
|
|||
-->
|
||||
#### 支持基于集合需求的资源
|
||||
|
||||
比较新的资源，例如 [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)、[`Deployment`](/docs/concepts/workloads/controllers/deployment/)、[`Replica Set`](/docs/concepts/workloads/controllers/replicaset/) 和[`Daemon Set`](/docs/concepts/workloads/controllers/daemonset/) ,也支持 _基于集合的_ 需求。
|
||||
比较新的资源，例如 [`Job`](/zh/docs/concepts/workloads/controllers/job/)、
|
||||
[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)、
|
||||
[`Replica Set`](/zh/docs/concepts/workloads/controllers/replicaset/) 和
|
||||
[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) ，
|
||||
也支持 _基于集合的_ 需求。
|
||||
|
||||
```yaml
|
||||
selector:
|
||||
|
|
@ -358,21 +369,26 @@ selector:
|
|||
```
|
||||
|
||||
<!--
|
||||
`matchLabels` is a map of `{key,value}` pairs. A single `{key,value}` in the `matchLabels` map is equivalent to an element of `matchExpressions`, whose `key` field is "key", the `operator` is "In", and the `values` array contains only "value". `matchExpressions` is a list of pod selector requirements. Valid operators include In, NotIn, Exists, and DoesNotExist. The values set must be non-empty in the case of In and NotIn. All of the requirements, from both `matchLabels` and `matchExpressions` are ANDed together -- they must all be satisfied in order to match.
|
||||
`matchLabels` is a map of `{key,value}` pairs. A single `{key,value}` in the `matchLabels` map is equivalent to an element of `matchExpressions`, whose `key` field is "key", the `operator` is "In", and the `values` array contains only "value". `matchExpressions` is a list of pod selector requirements. Valid operators include In, NotIn, Exists, and DoesNotExist. The values set must be non-empty in the case of In and NotIn. All of the requirements, from both `matchLabels` and `matchExpressions` are ANDed together - they must all be satisfied in order to match.
|
||||
-->
|
||||
|
||||
`matchLabels` 是由 `{key，value}` 对组成的映射。`matchLabels` 映射中的单个 `{key，value }` 等同于 `matchExpressions` 的元素，其 `key`字段为 "key"，`operator` 为 "In"，而 `values` 数组仅包含 "value"。`matchExpressions` 是 pod 选择器要求的列表。有效的运算符包括 In，NotIn，Exists 和 DoesNotExist。在 In 和 NotIn 的情况下，设置的值必须是非空的。来自 `matchLabels` 和 `matchExpressions` 的所有要求都是合在一起 -- 它们必须都满足才能匹配。
|
||||
`matchLabels` 是由 `{key,value}` 对组成的映射。
|
||||
`matchLabels` 映射中的单个 `{key,value }` 等同于 `matchExpressions` 的元素，
|
||||
其 `key` 字段为 "key"，`operator` 为 "In"，而 `values` 数组仅包含 "value"。
|
||||
`matchExpressions` 是 Pod 选择算符需求的列表。
|
||||
有效的运算符包括 `In`、`NotIn`、`Exists` 和 `DoesNotExist`。
|
||||
在 `In` 和 `NotIn` 的情况下，设置的值必须是非空的。
|
||||
来自 `matchLabels` 和 `matchExpressions` 的所有要求都按逻辑与的关系组合到一起
|
||||
-- 它们必须都满足才能匹配。
|
||||
|
||||
<!--
|
||||
#### Selecting sets of nodes
|
||||
-->
|
||||
#### 选择节点集
|
||||
|
||||
<!--
|
||||
One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule.
|
||||
See the documentation on [node selection](/docs/concepts/configuration/assign-pod-node/) for more information.
|
||||
-->
|
||||
通过标签进行选择的一个用例是确定节点集，方便 pod 调度。
|
||||
有关更多信息，请参阅 [选择节点](/docs/concepts/configuration/assign-pod-node/) 上的文档。
|
||||
#### 选择节点集
|
||||
|
||||
通过标签进行选择的一个用例是确定节点集，方便 Pod 调度。
|
||||
有关更多信息，请参阅[选择节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)文档。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 对象名称和IDs
|
||||
title: 对象名称和 IDs
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
|
@ -13,46 +13,32 @@ Every Kubernetes object also has a [_UID_](#uids) that is unique across your who
|
|||
For example, you can only have one Pod named `myapp-1234` within the same [namespace](/docs/concepts/overview/working-with-objects/namespaces/), but you can have one Pod and one Deployment that are each named `myapp-1234`.
|
||||
-->
|
||||
|
||||
集群中的每一个对象都一个[_名称_](#名称) 来标识在同类资源中的唯一性。
|
||||
集群中的每一个对象都一个[_名称_](#names) 来标识在同类资源中的唯一性。
|
||||
|
||||
每个 Kubernetes 对象也有一个[_UID_](#uids) 来标识在整个集群中的唯一性。
|
||||
|
||||
比如，在同一个[namespace](/docs/concepts/overview/working-with-objects/namespaces/)中只能命名一个名为 `myapp-1234` 的 Pod, 但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`.
|
||||
比如，在同一个[名字空间](/zh/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
中有一个名为 `myapp-1234` 的 Pod, 但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`.
|
||||
|
||||
<!--
|
||||
For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user-guide/labels) and [annotations](/docs/concepts/overview/working-with-objects/annotations/).
|
||||
|
||||
See the [identifiers design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) for the precise syntax rules for Names and
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
.
|
||||
-->
|
||||
|
||||
对于非唯一的用户提供的属性，Kubernetes 提供了[标签](/docs/user-guide/labels)和[注释](/docs/concepts/overview/working-with-objects/annotations/)。
|
||||
|
||||
有关名称和 UID 的精确语法规则，请参见[标识符设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)。
|
||||
|
||||
|
||||
|
||||
对于用户提供的非唯一性的属性，Kubernetes 提供了
|
||||
[标签（Labels）](/zh/docs/concepts/working-with-objects/labels)和
|
||||
[注解（Annotation）](/zh/docs/concepts/overview/working-with-objects/annotations/)机制。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Names
|
||||
-->
|
||||
|
||||
## 名称
|
||||
## 名称 {#names}
|
||||
|
||||
{{< glossary_definition term_id="name" length="all" >}}
|
||||
|
||||
<!--
|
||||
Below are three types of commonly used name constraints for resources.
|
||||
-->
|
||||
|
||||
以下是比较常见的三种资源命名约束。
|
||||
|
||||
<!--
|
||||
|
|
@ -68,9 +54,11 @@ This means the name must:
|
|||
- end with an alphanumeric character
|
||||
-->
|
||||
|
||||
### DNS 子域名
|
||||
### DNS 子域名 {#dns-subdomain-names}
|
||||
|
||||
某些资源类型需要一个 name 来作为一个 DNS 子域名，见定义 [RFC 1123](https://tools.ietf.org/html/rfc1123)。也就是命名必须满足如下规则：
|
||||
很多资源类型需要可以用作 DNS 子域名的名称。
|
||||
DNS 子域名的定义可参见 [RFC 1123](https://tools.ietf.org/html/rfc1123)。
|
||||
这一要求意味着名称必须满足如下规则：
|
||||
|
||||
- 不能超过253个字符
|
||||
- 只能包含字母数字，以及'-' 和 '.'
|
||||
|
|
@ -89,10 +77,10 @@ This means the name must:
|
|||
- start with an alphanumeric character
|
||||
- end with an alphanumeric character
|
||||
-->
|
||||
### DNS 标签名 {#dns-label-names}
|
||||
|
||||
### DNS 标签名称
|
||||
|
||||
某些资源类型需要其名称遵循 DNS 标签的标准，见[RFC 1123](https://tools.ietf.org/html/rfc1123)。也就是命名必须满足如下规则：
|
||||
某些资源类型需要其名称遵循 [RFC 1123](https://tools.ietf.org/html/rfc1123)
|
||||
所定义的 DNS 标签标准。也就是命名必须满足如下规则：
|
||||
|
||||
- 最多63个字符
|
||||
- 只能包含字母数字，以及'-'
|
||||
|
|
@ -100,19 +88,20 @@ This means the name must:
|
|||
- 须以字母数字结尾
|
||||
|
||||
<!--
|
||||
### Path Segment Names
|
||||
|
||||
Some resource types require their names to be able to be safely encoded as a
|
||||
path segment. In other words, the name may not be "." or ".." and the name may
|
||||
not contain "/" or "%".
|
||||
-->
|
||||
### 路径分段名称 {#path-segment-names}
|
||||
|
||||
### Path 部分名称
|
||||
|
||||
一些用与 Path 部分的资源类型要求名称能被安全的 encode。换句话说，其名称不能含有这些字符 "."、".."、"/"或"%"。
|
||||
某些资源类型要求名称能被安全地用作路径中的片段。
|
||||
换句话说，其名称不能是 `.`、`..`，也不可以包含 `/` 或 `%` 这些字符。
|
||||
|
||||
<!--
|
||||
Here’s an example manifest for a Pod named `nginx-demo`.
|
||||
-->
|
||||
|
||||
下面是一个名为`nginx-demo`的 Pod 的配置清单：
|
||||
|
||||
```yaml
|
||||
|
|
@ -127,16 +116,14 @@ spec:
|
|||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
{{< note >}}
|
||||
|
||||
<!--
|
||||
Some resource types have additional restrictions on their names.
|
||||
-->
|
||||
|
||||
某些资源类型可能有其相应的附加命名约束。
|
||||
|
||||
{{< note >}}
|
||||
某些资源类型可能具有额外的命名约束。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## UIDs
|
||||
|
||||
{{< glossary_definition term_id="uid" length="all" >}}
|
||||
|
|
@ -145,18 +132,16 @@ Some resource types have additional restrictions on their names.
|
|||
Kubernetes UIDs are universally unique identifiers (also known as UUIDs).
|
||||
UUIDs are standardized as ISO/IEC 9834-8 and as ITU-T X.667.
|
||||
-->
|
||||
Kubernetes UIDs 是通用的唯一标识符 (也叫 UUIDs).
|
||||
Kubernetes UIDs 是全局唯一标识符（也叫 UUIDs）。
|
||||
UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes.
|
||||
* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document.
|
||||
-->
|
||||
* 阅读关于 Kubernetes [labels](/docs/concepts/overview/working-with-objects/labels/)。
|
||||
* 更多参见 [Kubernetes 标识符和名称设计文档](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md).
|
||||
* 进一步了解 Kubernetes [标签](/zh/docs/concepts/overview/working-with-objects/labels/)
|
||||
* 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)的设计文档
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,9 @@
|
|||
---
|
||||
title: 命名空间
|
||||
title: 名字空间
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- derekwaynecarr
|
||||
- mikedanese
|
||||
|
|
@ -12,7 +11,6 @@ reviewers:
|
|||
title: Namespaces
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -22,16 +20,14 @@ Kubernetes supports multiple virtual clusters backed by the same physical cluste
|
|||
These virtual clusters are called namespaces.
|
||||
-->
|
||||
Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。
|
||||
这些虚拟集群被称为命名空间。
|
||||
|
||||
|
||||
这些虚拟集群被称为名字空间。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## When to Use Multiple Namespaces
|
||||
-->
|
||||
## 何时使用多个命名空间
|
||||
## 何时使用多个名字空间
|
||||
|
||||
<!--
|
||||
Namespaces are intended for use in environments with many users spread across multiple
|
||||
|
|
@ -39,60 +35,59 @@ teams, or projects. For clusters with a few to tens of users, you should not
|
|||
need to create or think about namespaces at all. Start using namespaces when you
|
||||
need the features they provide.
|
||||
-->
|
||||
命名空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑命名空间。当需要名称空间提供的功能时，请开始使用它们。
|
||||
名字空间适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑名字空间。当需要名称空间提供的功能时，请开始使用它们。
|
||||
|
||||
<!--
|
||||
Namespaces provide a scope for names. Names of resources need to be unique within a namespace,
|
||||
but not across namespaces. Namespaces can not be nested inside one another and each Kubernetes
|
||||
resource can only be in one namespace.
|
||||
-->
|
||||
命名空间为名称提供了一个范围。资源的名称需要在命名空间内是唯一的，但不能跨命名空间。命名空间不能相互嵌套，每个 Kubernetes 资源只能在一个命名空间中。
|
||||
名字空间为名称提供了一个范围。资源的名称需要在名字空间内是唯一的，但不能跨名字空间。
|
||||
名字空间不能相互嵌套，每个 Kubernetes 资源只能在一个名字空间中。
|
||||
|
||||
<!--
|
||||
Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
|
||||
-->
|
||||
命名空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/docs/concepts/policy/resource-quotas/)）。
|
||||
|
||||
<!--
|
||||
In future versions of Kubernetes, objects in the same namespace will have the same
|
||||
access control policies by default.
|
||||
-->
|
||||
在 Kubernetes 未来版本中，相同命名空间中的对象默认将具有相同的访问控制策略。
|
||||
名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh/docs/concepts/policy/resource-quotas/)）。
|
||||
在 Kubernetes 未来版本中，相同名字空间中的对象默认将具有相同的访问控制策略。
|
||||
|
||||
<!--
|
||||
It is not necessary to use multiple namespaces just to separate slightly different
|
||||
resources, such as different versions of the same software: use [labels](/docs/user-guide/labels) to distinguish
|
||||
resources, such as different versions of the same software: use
|
||||
[labels](/docs/concepts/overview/working-with-objects/labels/) to distinguish
|
||||
resources within the same namespace.
|
||||
-->
|
||||
不需要使用多个命名空间来分隔轻微不同的资源，例如同一软件的不同版本：使用 [labels](/docs/user-guide/labels) 来区分同一命名空间中的不同资源。
|
||||
不需要使用多个名字空间来分隔轻微不同的资源，例如同一软件的不同版本：
|
||||
使用[标签](/zh/docs/concepts/overview/working-with-objects/labels)来区分同一名字空间中的不同资源。
|
||||
|
||||
<!--
|
||||
## Working with Namespaces
|
||||
-->
|
||||
## 使用命名空间
|
||||
|
||||
<!--
|
||||
Creation and deletion of namespaces are described in the [Admin Guide documentation
|
||||
for namespaces](/docs/admin/namespaces).
|
||||
for namespaces](/docs/tasks/administer-cluster/namespaces/).
|
||||
-->
|
||||
命名空间的创建和删除已在[命名空间的管理指南文档](/docs/admin/namespaces)中进行了描述。
|
||||
## 使用名字空间
|
||||
|
||||
名字空间的创建和删除在[名字空间的管理指南文档](/zh/docs/tasks/administer-cluster/namespaces/)描述。
|
||||
|
||||
<!--
|
||||
Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
|
||||
-->
|
||||
{{< note >}}
|
||||
避免使用前缀 `kube-` 创建命名空间，因为它是为 Kubernetes 系统命名空间保留的。
|
||||
避免使用前缀 `kube-` 创建名字空间，因为它是为 Kubernetes 系统名字空间保留的。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Viewing namespaces
|
||||
-->
|
||||
### 查看命名空间
|
||||
|
||||
<!--
|
||||
You can list the current namespaces in a cluster using:
|
||||
-->
|
||||
您可以使用以下命令列出集群中现存的命名空间：
|
||||
### 查看名字空间
|
||||
|
||||
你可以使用以下命令列出集群中现存的名字空间：
|
||||
|
||||
```shell
|
||||
kubectl get namespace
|
||||
|
|
@ -100,74 +95,72 @@ kubectl get namespace
|
|||
```
|
||||
NAME STATUS AGE
|
||||
default Active 1d
|
||||
kube-node-lease Active 1d
|
||||
kube-system Active 1d
|
||||
kube-public Active 1d
|
||||
```
|
||||
|
||||
<!--
|
||||
Kubernetes starts with three initial namespaces:
|
||||
-->
|
||||
Kubernetes 会创建三个初始命名空间：
|
||||
Kubernetes starts with four initial namespaces:
|
||||
|
||||
<!--
|
||||
* `default` The default namespace for objects with no other namespace
|
||||
-->
|
||||
* `default` 没有指明使用其它命名空间的对象所使用的默认命名空间
|
||||
<!--
|
||||
* `kube-system` The namespace for objects created by the Kubernetes system
|
||||
-->
|
||||
* `kube-system` Kubernetes 系统创建对象所使用的命名空间
|
||||
<!--
|
||||
* `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.
|
||||
-->
|
||||
* `kube-public` 这个命名空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。这个命名空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定，而不是要求。
|
||||
* `default` The default namespace for objects with no other namespace
|
||||
* `kube-system` The namespace for objects created by the Kubernetes system
|
||||
* `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.
|
||||
* `kube-node-lease` This namespace for the lease objects associated with each node which improves the performance of the node heartbeats as the cluster scales.
|
||||
-->
|
||||
Kubernetes 会创建三个初始名字空间：
|
||||
|
||||
* `default` 没有指明使用其它名字空间的对象所使用的默认名字空间
|
||||
* `kube-system` Kubernetes 系统创建对象所使用的名字空间
|
||||
* `kube-public` 这个名字空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。
|
||||
这个名字空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。
|
||||
这个名字空间的公共方面只是一种约定，而不是要求。
|
||||
* `kube-node-lease` 此名字空间用于与哥哥节点相关的租期（Lease）对象；
|
||||
此对象的设计使得集群规模很大时节点心跳检测性能得到提升。
|
||||
|
||||
<!--
|
||||
### Setting the namespace for a request
|
||||
-->
|
||||
### 为请求设置命名空间
|
||||
|
||||
<!--
|
||||
To set the namespace for a current request, use the `--namespace` flag.
|
||||
-->
|
||||
要为当前请求设置命名空间，请使用 `--namespace` 参数。
|
||||
To set the namespace for a current request, use the `-namespace` flag.
|
||||
|
||||
<!--
|
||||
For example:
|
||||
-->
|
||||
### 为请求设置名字空间
|
||||
|
||||
要为当前请求设置名字空间，请使用 `--namespace` 参数。
|
||||
|
||||
例如：
|
||||
|
||||
```shell
|
||||
kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
|
||||
kubectl get pods --namespace=<insert-namespace-name-here>
|
||||
kubectl run nginx --image=nginx --namespace=<名字空间名称>
|
||||
kubectl get pods --namespace=<名字空间名称>
|
||||
```
|
||||
|
||||
<!--
|
||||
### Setting the namespace preference
|
||||
-->
|
||||
### 设置命名空间首选项
|
||||
|
||||
<!--
|
||||
You can permanently save the namespace for all subsequent kubectl commands in that
|
||||
context.
|
||||
-->
|
||||
您可以永久保存该上下文中所有后续 kubectl 命令使用的命名空间。
|
||||
### 设置名字空间偏好
|
||||
|
||||
你可以永久保存名字空间，以用于对应上下文中所有后续 kubectl 命令。
|
||||
|
||||
```shell
|
||||
kubectl config set-context --current --namespace=<insert-namespace-name-here>
|
||||
# Validate it
|
||||
kubectl config set-context --current --namespace=<名字空间名称>
|
||||
# 验证之
|
||||
kubectl config view | grep namespace:
|
||||
```
|
||||
|
||||
<!--
|
||||
## Namespaces and DNS
|
||||
-->
|
||||
## 命名空间和 DNS
|
||||
|
||||
<!--
|
||||
When you create a [Service](/docs/user-guide/services), it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/).
|
||||
-->
|
||||
当您创建一个 [Service](/docs/user-guide/services) 时，Kubernetes 会创建一个相应的 [DNS 条目](/docs/concepts/services-networking/dns-pod-service/)。
|
||||
## 名字空间和 DNS
|
||||
|
||||
当你创建一个[服务](/zh/docs/concepts/services-networking/service/) 时，
|
||||
Kubernetes 会创建一个相应的 [DNS 条目](/zh/docs/concepts/services-networking/dns-pod-service/)。
|
||||
|
||||
<!--
|
||||
This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means
|
||||
|
|
@ -176,44 +169,44 @@ is local to a namespace. This is useful for using the same configuration across
|
|||
multiple namespaces such as Development, Staging and Production. If you want to reach
|
||||
across namespaces, you need to use the fully qualified domain name (FQDN).
|
||||
-->
|
||||
该条目的形式是 `<service-name>.<namespace-name>.svc.cluster.local`，这意味着如果容器只使用 `<service-name>`，它将被解析到本地命名空间的服务。这对于跨多个命名空间（如开发、分级和生产）使用相同的配置非常有用。如果您希望跨命名空间访问，则需要使用完全限定域名（FQDN）。
|
||||
该条目的形式是 `<服务名称>.<名字空间名称>.svc.cluster.local`，这意味着如果容器只使用
|
||||
`<服务名称>`，它将被解析到本地名字空间的服务。这对于跨多个名字空间（如开发、分级和生产）
|
||||
使用相同的配置非常有用。如果你希望跨名字空间访问，则需要使用完全限定域名（FQDN）。
|
||||
|
||||
<!--
|
||||
## Not All Objects are in a Namespace
|
||||
-->
|
||||
## 并非所有对象都在命名空间中
|
||||
## 并非所有对象都在名字空间中
|
||||
|
||||
<!--
|
||||
Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are
|
||||
in some namespaces. However namespace resources are not themselves in a namespace.
|
||||
And low-level resources, such as [nodes](/docs/admin/node) and
|
||||
And low-level resources, such as [nodes](/docs/concepts/architecture/nodes/) and
|
||||
persistentVolumes, are not in any namespace.
|
||||
-->
|
||||
大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些命名空间中。但是命名空间资源本身并不在命名空间中。而且底层资源，例如 [nodes](/docs/admin/node) 和持久化卷不属于任何命名空间。
|
||||
大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。
|
||||
但是名字空间资源本身并不在名字空间中。而且底层资源，例如
|
||||
[节点](/zh/docs/concepts/architecture/nodes/) 和持久化卷不属于任何名字空间。
|
||||
|
||||
<!--
|
||||
To see which Kubernetes resources are and aren't in a namespace:
|
||||
-->
|
||||
查看哪些 Kubernetes 资源在命名空间中，哪些不在命名空间中：
|
||||
查看哪些 Kubernetes 资源在名字空间中，哪些不在名字空间中：
|
||||
|
||||
```shell
|
||||
# In a namespace
|
||||
# 位于名字空间中的资源
|
||||
kubectl api-resources --namespaced=true
|
||||
|
||||
# Not in a namespace
|
||||
# 不在名字空间中的资源
|
||||
kubectl api-resources --namespaced=false
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Learn more about [creating a new namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace).
|
||||
* Learn more about [deleting a namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).
|
||||
-->
|
||||
* 进一步了解[建立新的命名空间](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。
|
||||
* 进一步了解[删除命名空间](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。
|
||||
|
||||
|
||||
* 进一步了解[建立新的名字空间](/zh/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。
|
||||
* 进一步了解[删除名字空间](/zh/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue