whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge release1.15 into master (#16512)

Browse Source 
* initial commit

* promote AWS-NLB Support from alpha to beta (#14451) (#16459) (#16484)

* 1. Sync release-1.15 into master
2. Sync with en version

* 1. Add the lost yaml file.
This commit is contained in:
成臣 Chengchen
2019-09-24 15:55:27 +09:00
committed by Kubernetes Prow Robot
parent 513199d5af
commit b23e9ab024
19 changed files with 1964 additions and 132 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/overview/working-with-objects/_index.md
Executable → Regular
View File
content/zh/docs/concepts/overview/working-with-objects/annotations.md
+173
View File
@@ -0,0 +1,173 @@
---
title: 注解
content_template: templates/concept
weight: 50
---
<!--
---
title: Annotations
content_template: templates/concept
weight: 50
---
-->
{{% capture 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.
-->
{{% /capture %}}
{{% capture 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:
-->
```json
"metadata": {
"annotations": {
"key1" : "value1",
"key2" : "value2"
}
}
```
以下是一些例子，用来说明哪些信息可以使用注解来记录:
<!--
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.
-->
* 可用于调试目的的客户端库或工具信息：例如，名称、版本和构建信息。
<!--
* 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.
-->
您可以将这类信息存储在外部数据库或目录中而不使用注解，但这样做就使得开发人员很难生成用于部署、管理、自检的客户端共享库和工具。
<!--
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
_Annotations_ are key/value pairs. Valid annotation 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 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` 或其他第三方组件），必须为终端用户添加注释前缀。
<!--
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核心组件保留的。
例如，这是Pod的配置文件，其注释为 `imageregistry：https：// hub.docker.com /` ：
```yaml
apiVersion: v1
kind: Pod
metadata:
name: annotations-demo
annotations:
imageregistry: "https://hub.docker.com/"
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
```
{{% /capture %}}
{{% capture whatsnext %}}
进一步了解[标签和选择器](/docs/concepts/overview/working-with-objects/labels/)。
<!--
Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/).
-->
{{% /capture %}}
content/zh/docs/concepts/overview/working-with-objects/common-labels.md
+262
View File
@@ -0,0 +1,262 @@
---
title: 推荐使用的标签
content_template: templates/concept
---
<!--
---
title: Recommended Labels
content_template: templates/concept
---
-->
{{% capture overview %}}
<!--
You can visualize and manage Kubernetes objects with more tools than kubectl and
the dashboard. A common set of labels allows tools to work interoperably, describing
objects in a common manner that all tools can understand.
-->
除了 kubectl 和 dashboard 之外，您可以其他工具来可视化和管理 Kubernetes 对象。
一组通用的标签可以让多个工具之间互操作，用所有工具都能理解的通用方式描述对象。
<!--
In addition to supporting tooling, the recommended labels describe applications
in a way that can be queried.
-->
除了支持工具外，推荐的标签还以一种可以查询的方式描述了应用程序。
{{% /capture %}}
{{% capture body %}}
<!--
The metadata is organized around the concept of an _application_. Kubernetes is not
a platform as a service (PaaS) and doesn't have or enforce a formal notion of an application.
Instead, applications are informal and described with metadata. The definition of
what an application contains is loose.
-->
元数据围绕 _应用（application）_ 的概念进行组织。Kubernetes 不是
平台即服务（PaaS），没有或强制执行正式的应用程序概念。
相反，应用程序是非正式的，并使用元数据进行描述。应用程序包含的定义是松散的。
{{< note >}}
<!--
These are recommended labels. They make it easier to manage applications
but aren't required for any core tooling.
-->
这些是推荐的标签。它们使管理应用程序变得更容易但不是任何核心工具所必需的。
{{< /note >}}
<!--
Shared labels and annotations share a common prefix: `app.kubernetes.io`. Labels
without a prefix are private to users. The shared prefix ensures that shared labels
do not interfere with custom user labels.
-->
共享标签和注解都使用同一个前缀：`app.kubernetes.io`。没有前缀的标签是用户私有的。共享前缀可以确保共享标签不会干扰用户自定义的标签。
<!--
## Labels
In order to take full advantage of using these labels, they should be applied
on every resource object.
-->
## 标签
为了充分利用这些标签，应该在每个资源对象上都使用它们。
<!--
| Key | Description | Example | Type |
| ----------------------------------- | --------------------- | -------- | ---- |
| `app.kubernetes.io/name` | The name of the application | `mysql` | string |
| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `wordpress-abcxzy` | string |
| `app.kubernetes.io/version` | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string |
| `app.kubernetes.io/component` | The component within the architecture | `database` | string |
| `app.kubernetes.io/part-of` | The name of a higher level application this one is part of | `wordpress` | string |
| `app.kubernetes.io/managed-by` | The tool being used to manage the operation of an application | `helm` | string |
-->
| 键 | 描述 | 示例 | 类型 |
| ----------------------------------- | --------------------- | -------- | ---- |
| `app.kubernetes.io/name` | 应用程序的名称 | `mysql` | 字符串 |
| `app.kubernetes.io/instance` | 用于唯一确定应用实例的名称 | `wordpress-abcxzy` | 字符串 |
| `app.kubernetes.io/version` | 应用程序的当前版本（例如，语义版本，修订版哈希等） | `5.7.21` | 字符串 |
| `app.kubernetes.io/component` | 架构中的组件 | `database` | 字符串 |
| `app.kubernetes.io/part-of` | 此级别的更高级别应用程序的名称 | `wordpress` | 字符串 |
| `app.kubernetes.io/managed-by` | 用于管理应用程序的工具 | `helm` | 字符串 |
<!--
To illustrate these labels in action, consider the following StatefulSet object:
-->
为说明这些标签的实际使用情况，请看下面的 StatefulSet 对象：
```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: wordpress-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
app.kubernetes.io/managed-by: helm
```
<!--
## Applications And Instances Of Applications
An application can be installed one or more times into a Kubernetes cluster and,
in some cases, the same namespace. For example, wordpress can be installed more
than once where different websites are different installations of wordpress.
The name of an application and the instance name are recorded separately. For
example, WordPress has a `app.kubernetes.io/name` of `wordpress` while it has
an instance name, represented as `app.kubernetes.io/instance` with a value of
`wordpress-abcxzy`. This enables the application and instance of the application
to be identifiable. Every instance of an application must have a unique name.
-->
## 应用和应用实例
应用可以在 Kubernetes 集群中安装一次或多次。在某些情况下，可以安装在同一命名空间中。例如，可以不止一次地为不同的站点安装不同的 wordpress。
应用的名称和实例的名称是分别记录的。例如，某 WordPress 实例的 `app.kubernetes.io/name` 为 `wordpress`，而其实例名称表现为 `app.kubernetes.io/instance` 的属性值 `wordpress-abcxzy`。这使应用程序和应用程序的实例成为可能是可识别的。应用程序的每个实例都必须具有唯一的名称。
<!--
## Examples
-->
## 示例
<!--
To illustrate different ways to use these labels the following examples have varying complexity.
-->
为了说明使用这些标签的不同方式，以下示例具有不同的复杂性。
<!--
### A Simple Stateless Service
-->
### 一个简单的无状态服务
<!--
Consider the case for a simple stateless service deployed using `Deployment` and `Service` objects. The following two snippets represent how the labels could be used in their simplest form.
-->
考虑使用 `Deployment` 和 `Service` 对象部署的简单无状态服务的情况。以下两个代码段表示如何以最简单的形式使用标签。
<!--
The `Deployment` is used to oversee the pods running the application itself.
-->
下面的 `Deployment` 用于监督运行应用本身的 pods。
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/name: myservice
app.kubernetes.io/instance: myservice-abcxzy
...
```
<!--
The `Service` is used to expose the application.
-->
下面的 `Service` 用于暴露应用。
```yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: myservice
app.kubernetes.io/instance: myservice-abcxzy
...
```
<!--
### Web Application With A Database
-->
### 带有一个数据库的 Web 应用程序
<!--
Consider a slightly more complicated application: a web application (WordPress)
using a database (MySQL), installed using Helm. The following snippets illustrate
the start of objects used to deploy this application.
The start to the following `Deployment` is used for WordPress:
-->
考虑一个稍微复杂的应用：一个使用 Helm 安装的 Web 应用（WordPress），其中
使用了数据库（MySQL）。以下代码片段说明用于部署此应用程序的对象的开始。
以下 `Deployment` 的开头用于 WordPress：
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/name: wordpress
app.kubernetes.io/instance: wordpress-abcxzy
app.kubernetes.io/version: "4.9.4"
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: server
app.kubernetes.io/part-of: wordpress
...
```
<!--
The `Service` is used to expose WordPress:
-->
这个 `Service` 用于暴露 WordPress：
```yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: wordpress
app.kubernetes.io/instance: wordpress-abcxzy
app.kubernetes.io/version: "4.9.4"
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: server
app.kubernetes.io/part-of: wordpress
...
```
<!--
MySQL is exposed as a `StatefulSet` with metadata for both it and the larger application it belongs to:
-->
MySQL 作为一个 `StatefulSet` 暴露，包含它和它所属的较大应用程序的元数据：
```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
app.kubernetes.io/version: "5.7.21"
...
```
<!--
The `Service` is used to expose MySQL as part of WordPress:
-->
`Service` 用于将 MySQL 作为 WordPress 的一部分暴露：
```yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/managed-by: helm
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
app.kubernetes.io/version: "5.7.21"
...
```
<!--
With the MySQL `StatefulSet` and `Service` you'll notice information about both MySQL and Wordpress, the broader application, are included.
-->
使用 MySQL `StatefulSet` 和 `Service`，您会注意到有关 MySQL 和 Wordpress 的信息，包括更广泛的应用程序。
{{% /capture %}}
content/zh/docs/concepts/overview/working-with-objects/field-selectors.md
+108
View File
@@ -0,0 +1,108 @@
---
title: 字段选择器
weight: 60
---
<!--
---
title: Field Selectors
weight: 60
---
-->
字段选择器允许您根据一个或多个资源字段的值[筛选 Kubernetes 资源](/docs/concepts/overview/working-with-objects/kubernetes-objects)。
下面是一些使用字段选择器查询的例子：
<!--
_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:
-->
* `metadata.name=my-service`
* `metadata.namespace!=default`
* `status.phase=Pending`
下面这个 `kubectl` 命令将筛选出[`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)字段值为 `Running` 的所有 Pod：
<!--
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`:
-->
```shell
kubectl get pods --field-selector status.phase=Running
```
{{< note >}}
字段选择器本质上是资源*过滤器*。默认情况下，字段选择器/过滤器是未被应用的，这意味着指定类型的所有资源都会被筛选出来。
这使得以下的两个 `kubectl` 查询是等价的：
<!--
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:
-->
```shell
kubectl get pods
kubectl get pods --field-selector ""
```
{{< /note >}}
## 支持的字段
<!--
## Supported fields
-->
不同的 Kubernetes 资源类型支持不同的字段选择器。
所有资源类型都支持 `metadata.name` 和 `metadata.namespace` 字段。
使用不被支持的字段选择器会产生错误，例如：
<!--
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:
-->
```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
-->
您可以使用 `=`、`==`和 `!=` 对字段选择器进行运算（`=` 和 `==` 的意义是相同的）。
例如，下面这个 `kubectl` 命令将筛选所有不属于 `default` 名称空间的 Kubernetes Service：
<!--
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:
-->
```shell
kubectl get services --all-namespaces --field-selector metadata.namespace!=default
```
## 链式选择器
<!--
## Chained selectors
-->
同[标签](/docs/concepts/overview/working-with-objects/labels)和其他选择器一样，字段选择器可以通过使用逗号分隔的列表组成一个选择链。
下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod：
<!--
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`:
-->
```shell
kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
```
## 多种资源类型
<!--
## Multiple resource types
-->
您能够跨多种资源类型来使用字段选择器。
下面这个 `kubectl` 命令将筛选出所有不在 `default` 命名空间中的 StatefulSet 和 Service：
<!--
You use field selectors across multiple resource types. This `kubectl` command selects all Statefulsets and Services that are not in the `default` namespace:
-->
```shell
kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
```
content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+75 -14
View File
@@ -5,18 +5,25 @@ redirect_from:
- "/docs/concepts/abstractions/overview/"
- "/docs/concepts/abstractions/overview.html"
content_template: templates/concept
weight: 10
---
{{% capture overview %}}
<!--
This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can express them in `.yaml` format.
-->
本页说明了 Kubernetes 对象在 Kubernetes API 中是如何表示的，以及如何在 `.yaml` 格式的文件中表示。
{{% /capture %}}
{{% capture body %}}
<!--
## Understanding Kubernetes Objects
*Kubernetes Objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
* What containerized applications are running (and on which nodes)
* The resources available to those applications
* The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
-->
## 理解 Kubernetes 对象
@@ -26,14 +33,21 @@ weight: 10
* 可以被应用使用的资源
* 关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略
<!--
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/).
-->
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 调用，也可以在程序中直接调用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go)
，其它语言库（例如[Python](https://github.com/kubernetes-incubator/client-python)）也正在开发中。
操作 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。
<!--
### 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.
-->
### 对象规约（Spec）与状态（Status）
@@ -41,16 +55,28 @@ Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernete
*spec* 是必需的，它描述了对象的 *期望状态（Desired State）* —— 希望对象所具有的特征。
*status* 描述了对象的 *实际状态（Actual State）* ，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。
<!--
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.
-->
例如，Kubernetes Deployment 对象能够表示运行在集群中的应用。
当创建 Deployment 时，可能需要设置 Deployment 的规约，以指定该应用需要有 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)。
<!--
### Describing a Kubernetes Object
When you create an object in Kubernetes, you must provide the object spec that describes its desired state, as well as some basic information about the object (such as a name). When you use the Kubernetes API to create the object (either directly or via `kubectl`), that API request must include that information as JSON in the request body. **Most often, you provide the information to `kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API request.
Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:
-->
### 描述 Kubernetes 对象
@@ -61,22 +87,41 @@ Kubernetes 系统读取 Deployment 规约，并启动我们所期望的该应用
这里有一个 `.yaml` 示例文件，展示了 Kubernetes Deployment 的必需字段和对象规约：
{{< code file="nginx-deployment.yaml" >}}
{{< codenew file="application/deployment.yaml" >}}
使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的 [`kubectl create`](/docs/user-guide/kubectl/v1.7/#create) 命令，将 `.yaml` 文件作为参数。下面是一个示例：
<!--
One way to create a Deployment using a `.yaml` file like the one above is to use the
[`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）中的
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 命令，
将 `.yaml` 文件作为参数。下面是一个示例：
```shell
$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
```
<!--
The output is similar to this:
-->
输出类似如下这样：
```shell
deployment "nginx-deployment" created
deployment.apps/nginx-deployment created
```
<!--
### Required Fields
In the `.yaml` file for the Kubernetes object you want to create, you'll need to set values for the following fields:
* `apiVersion` - Which version of the Kubernetes API you're using to create this object
* `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`
-->
### 必需字段
@@ -86,13 +131,29 @@ deployment "nginx-deployment" created
* `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.
For example, the `spec` format for a `Pod` can be found
[here](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core),
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/api/)能够帮助我们找到任何我们想创建的对象的 spec 格式。
也需要提供对象的 `spec` 字段。对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。[Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)能够帮助我们找到任何我们想创建的对象的 spec 格式。
例如，可以从
[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
查看 `Pod` 的 `spec` 格式，
并且可以从
[这里](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)
查看 `Deployment` 的 `spec` 格式。
{{% /capture %}}
{{% capture whatsnext %}}
<!--
* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
-->
* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/abstractions/pod/)。
* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/workloads/pods/pod-overview/)。
{{% /capture %}}
content/zh/docs/concepts/overview/working-with-objects/namespaces.md
+209
View File
@@ -0,0 +1,209 @@
---
title: 命名空间
content_template: templates/concept
weight: 30
---
{{% capture overview %}}
Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。
这些虚拟集群被称为命名空间。
<!--
Kubernetes supports multiple virtual clusters backed by the same physical cluster.
These virtual clusters are called namespaces.
-->
{{% /capture %}}
{{% capture body %}}
## 何时使用多个命名空间
<!--
## When to Use Multiple Namespaces
-->
命名空间适用于存在很多跨多个团队或项目的用户的场景。
对于只有几到几十个用户的集群，根本不需要创建或考虑命名空间。当您需要命名空间提供的特性时，请开始使用它们。
<!--
Namespaces are intended for use in environments with many users spread across multiple
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.
-->
命名空间为名称提供了一个范围。
资源的名称需要在命名空间内是惟一的，但不能跨命名空间。命名空间不能嵌套在另外一个命名空间内，而且每个 Kubernetes
资源只能属于一个命名空间。
<!--
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.
-->
命名空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/docs/concepts/policy/resource-quotas/)）。
<!--
Namespaces are a way to divide cluster resources between multiple users (via [resource quota](/docs/concepts/policy/resource-quotas/)).
-->
在 Kubernetes 未来版本中，相同命名空间中的对象默认将具有相同的访问控制策略。
<!--
In future versions of Kubernetes, objects in the same namespace will have the same
access control policies by default.
-->
不需要使用多个命名空间来分隔轻微不同的资源，例如同一软件的不同版本：
使用[标签](/docs/user-guide/labels)来区分同一命名空间中的不同资源。
<!--
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 within the same namespace.
-->
## 使用命名空间
<!--
## Working with Namespaces
-->
命名空间的创建和删除已在[命名空间的管理指南文档](/docs/admin/namespaces)中进行了描述。
<!--
Creation and deletion of namespaces are described in the [Admin Guide documentation
for namespaces](/docs/admin/namespaces).
-->
### 查看命名空间
<!--
### Viewing namespaces
-->
您可以使用以下命令列出集群中现存的命名空间：
<!--
You can list the current namespaces in a cluster using:
-->
```shell
kubectl get namespace
```
```
NAME STATUS AGE
default Active 1d
kube-system Active 1d
kube-public Active 1d
```
Kubernetes 会创建三个初始命名空间：
<!--
Kubernetes starts with three initial namespaces:
* `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.
-->
* `default` 没有指明使用其它命名空间的对象所使用的默认命名空间
* `kube-system` Kubernetes 系统创建对象所使用的命名空间
* `kube-public` 这个命名空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。这个命名空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定，而不是要求。
### 为请求设置命名空间
<!--
### Setting the namespace for a request
-->
要为当前的请求设定一个命名空间，请使用 `--namespace` 参数。
<!--
To set the namespace for a current request, use the `--namespace` flag.
-->
例如：
<!--
For example:
-->
```shell
kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>
```
### 设置命名空间首选项
<!--
### Setting the namespace preference
-->
您可以永久保存该上下文中所有后续 kubectl 命令使用的命名空间。
<!--
You can permanently save the namespace for all subsequent kubectl commands in that
context.
-->
```shell
kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Validate it
kubectl config view | grep namespace:
```
## 命名空间和 DNS
<!--
## Namespaces and DNS
-->
当您创建一个[服务](/docs/user-guide/services)时，Kubernetes 会创建一个相应的[DNS 条目](/docs/concepts/services-networking/dns-pod-service/)。
<!--
When you create a [Service](/docs/user-guide/services), it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/).
-->
该条目的形式是 `<service-name>.<namespace-name>.svc.cluster.local`，
这意味着如果容器只使用 `<service-name>`，它将被解析到本地命名空间的服务。
这对于跨多个命名空间（如开发、分级和生产）使用相同的配置非常有用。
如果您希望跨命名空间访问，则需要使用完全限定域名（FQDN）。
<!--
This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means
that if a container just uses `<service-name>`, it will resolve to the service which
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).
-->
## 并非所有对象都在命名空间中
<!--
## Not All Objects are in a Namespace
-->
大多数 kubernetes 资源（例如 Pod、服务、副本控制器等）都位于某些命名空间中。
但是命名空间资源本身并不在命名空间中。
<!--
Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are
in some namespaces. However namespace resources are not themselves in a namespace.
-->
而且底层资源，例如[节点](/docs/admin/node)和持久化卷不属于任何命名空间。
<!--
And low-level resources, such as [nodes](/docs/admin/node) and
persistentVolumes, are not in any namespace.
-->
查看哪些 Kubernetes 资源在命名空间中，哪些不在命名空间中：
<!--
To see which Kubernetes resources are and aren't in a namespace:
-->
```shell
# In a namespace
kubectl api-resources --namespaced=true
# Not in a namespace
kubectl api-resources --namespaced=false
```
{{% /capture %}}
{{% capture 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).
{{% /capture %}}