Merge pull request #38627 from windsonsea/overviy
[zh] sync /configuration/overview.mdpull/38643/head
Kubernetes Prow Robot
GitHub
commit
0dc101bae8
|
|
@ -4,6 +4,8 @@ content_type: concept
|
|||
weight: 10
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- mikedanese
|
||||
title: Configuration Best Practices
|
||||
content_type: concept
|
||||
weight: 10
|
||||
|
|
@ -11,12 +13,14 @@ weight: 10
|
|||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This document highlights and consolidates configuration best practices that are introduced throughout the user guide, Getting Started documentation, and examples.
|
||||
This document highlights and consolidates configuration best practices that are introduced
|
||||
throughout the user guide, Getting Started documentation, and examples.
|
||||
-->
|
||||
本文档重点介绍并整合了整个用户指南、入门文档和示例中介绍的配置最佳实践。
|
||||
|
||||
<!--
|
||||
This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
|
||||
This is a living document. If you think of something that is not on this list but might be useful
|
||||
to others, please don't hesitate to file an issue or submit a PR.
|
||||
-->
|
||||
这是一份不断改进的文件。
|
||||
如果你认为某些内容缺失但可能对其他人有用，请不要犹豫，提交 Issue 或提交 PR。
|
||||
|
|
@ -33,26 +37,33 @@ This is a living document. If you think of something that is not on this list bu
|
|||
- 定义配置时，请指定最新的稳定 API 版本。
|
||||
|
||||
<!--
|
||||
- Configuration files should be stored in version control before being pushed to the cluster. This allows you to quickly roll back a configuration change if necessary. It also aids cluster re-creation and restoration.
|
||||
- Configuration files should be stored in version control before being pushed to the cluster. This
|
||||
allows you to quickly roll back a configuration change if necessary. It also aids cluster
|
||||
re-creation and restoration.
|
||||
-->
|
||||
- 在推送到集群之前，配置文件应存储在版本控制中。
|
||||
这允许你在必要时快速回滚配置更改。
|
||||
它还有助于集群重新创建和恢复。
|
||||
它还有助于集群重新创建和恢复。
|
||||
|
||||
<!--
|
||||
- Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly.
|
||||
- Write your configuration files using YAML rather than JSON. Though these formats can be used
|
||||
interchangeably in almost all scenarios, YAML tends to be more user-friendly.
|
||||
-->
|
||||
- 使用 YAML 而不是 JSON 编写配置文件。虽然这些格式几乎可以在所有场景中互换使用，但 YAML 往往更加用户友好。
|
||||
|
||||
<!--
|
||||
- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
|
||||
- Group related objects into a single file whenever it makes sense. One file is often easier to
|
||||
manage than several. See the
|
||||
[guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml)
|
||||
file as an example of this syntax.
|
||||
-->
|
||||
- 只要有意义，就将相关对象分组到一个文件中。一个文件通常比几个文件更容易管理。
|
||||
请参阅 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml)
|
||||
文件作为此语法的示例。
|
||||
|
||||
<!--
|
||||
- Note also that many `kubectl` commands can be called on a directory. For example, you can call `kubectl apply` on a directory of config files.
|
||||
- Note also that many `kubectl` commands can be called on a directory. For example, you can call
|
||||
`kubectl apply` on a directory of config files.
|
||||
-->
|
||||
- 另请注意，可以在目录上调用许多 `kubectl` 命令。
|
||||
例如，你可以在配置文件的目录中调用 `kubectl apply`。
|
||||
|
|
@ -67,16 +78,22 @@ This is a living document. If you think of something that is not on this list bu
|
|||
-->
|
||||
- 将对象描述放在注释中，以便更好地进行内省。
|
||||
|
||||
|
||||
<!--
|
||||
## "Naked" Pods versus ReplicaSets, Deployments, and Jobs {#naked-pods-vs-replicasets-deployments-and-jobs}
|
||||
-->
|
||||
## “独立的“ Pod 与 ReplicaSet 、Deployment 和 Job {#naked-pods-vs-replicasets-deployments-and-jobs}
|
||||
## “独立的“ Pod 与 ReplicaSet、Deployment 和 Job {#naked-pods-vs-replicasets-deployments-and-jobs}
|
||||
|
||||
<!--
|
||||
- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
|
||||
- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods
|
||||
will not be rescheduled in the event of a node failure.
|
||||
|
||||
A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) may also be appropriate.
|
||||
A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is
|
||||
always available, and specifies a strategy to replace Pods (such as
|
||||
[RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is
|
||||
almost always preferable to creating Pods directly, except for some explicit
|
||||
[`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios.
|
||||
A [Job](/docs/concepts/workloads/controllers/job/) may also be appropriate.
|
||||
-->
|
||||
- 如果可能，不要使用独立的 Pod（即，未绑定到
|
||||
[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 或
|
||||
|
|
@ -95,9 +112,11 @@ This is a living document. If you think of something that is not on this list bu
|
|||
## 服务 {#services}
|
||||
|
||||
<!--
|
||||
- Create a [Service](/docs/concepts/services-networking/service/) before its corresponding backend workloads (Deployments or ReplicaSets), and before any workloads that need to access it. When Kubernetes starts a container, it provides environment variables pointing to all the Services which were running when the container was started. For example, if a Service named `foo` exists, all containers will get the following variables in their initial environment:
|
||||
|
||||
*This does imply an ordering requirement* - any `Service` that a `Pod` wants to access must be created before the `Pod` itself, or else the environment variables will not be populated. DNS does not have this restriction.
|
||||
- Create a [Service](/docs/concepts/services-networking/service/) before its corresponding backend
|
||||
workloads (Deployments or ReplicaSets), and before any workloads that need to access it.
|
||||
When Kubernetes starts a container, it provides environment variables pointing to all the Services
|
||||
which were running when the container was started. For example, if a Service named `foo` exists,
|
||||
all containers will get the following variables in their initial environment:
|
||||
-->
|
||||
- 在创建相应的后端工作负载（Deployment 或 ReplicaSet），以及在需要访问它的任何工作负载之前创建
|
||||
[服务](/zh-cn/docs/concepts/services-networking/service/)。
|
||||
|
|
@ -109,22 +128,38 @@ This is a living document. If you think of something that is not on this list bu
|
|||
FOO_SERVICE_PORT=<the port the Service is running on>
|
||||
```
|
||||
|
||||
<!--
|
||||
*This does imply an ordering requirement* - any `Service` that a `Pod` wants to access must be
|
||||
created before the `Pod` itself, or else the environment variables will not be populated.
|
||||
DNS does not have this restriction.
|
||||
-->
|
||||
**这确实意味着在顺序上的要求** - 必须在 `Pod` 本身被创建之前创建 `Pod` 想要访问的任何 `Service`，
|
||||
否则将环境变量不会生效。DNS 没有此限制。
|
||||
|
||||
<!--
|
||||
- An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The
|
||||
DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically.
|
||||
- An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/)
|
||||
is a DNS server. The DNS server watches the Kubernetes API for new `Services` and creates a set
|
||||
of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be
|
||||
able to do name resolution of `Services` automatically.
|
||||
-->
|
||||
- 一个可选（尽管强烈推荐）的[集群插件](/zh-cn/docs/concepts/cluster-administration/addons/)
|
||||
是 DNS 服务器。DNS 服务器为新的 `Services` 监视 Kubernetes API，并为每个创建一组 DNS 记录。
|
||||
如果在整个集群中启用了 DNS，则所有 `Pod` 应该能够自动对 `Services` 进行名称解析。
|
||||
|
||||
<!--
|
||||
- Don't specify a `hostPort` for a Pod unless it is absolutely necessary. When you bind a Pod to a `hostPort`, it limits the number of places the Pod can be scheduled, because each <`hostIP`, `hostPort`, `protocol`> combination must be unique. If you don't specify the `hostIP` and `protocol` explicitly, Kubernetes will use `0.0.0.0` as the default `hostIP` and `TCP` as the default `protocol`.
|
||||
- Don't specify a `hostPort` for a Pod unless it is absolutely necessary. When you bind a Pod to a
|
||||
`hostPort`, it limits the number of places the Pod can be scheduled, because each <`hostIP`,
|
||||
`hostPort`, `protocol`> combination must be unique. If you don't specify the `hostIP` and
|
||||
`protocol` explicitly, Kubernetes will use `0.0.0.0` as the default `hostIP` and `TCP` as the
|
||||
default `protocol`.
|
||||
|
||||
If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
|
||||
If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service before resorting to `hostPort`.
|
||||
If you only need access to the port for debugging purposes, you can use the
|
||||
[apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)
|
||||
or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
|
||||
|
||||
If you explicitly need to expose a Pod's port on the node, consider using a
|
||||
[NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service before resorting to
|
||||
`hostPort`.
|
||||
-->
|
||||
- 不要为 Pod 指定 `hostPort`，除非非常有必要这样做。
|
||||
当你为 Pod 绑定了 `hostPort`，那么能够运行该 Pod 的节点就有限了，因为每个 `<hostIP, hostPort, protocol>` 组合必须是唯一的。
|
||||
|
|
@ -145,8 +180,9 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN
|
|||
- 避免使用 `hostNetwork`，原因与 `hostPort` 相同。
|
||||
|
||||
<!--
|
||||
- Use [headless Services](/docs/concepts/services-networking/service/#headless-
|
||||
services) (which have a `ClusterIP` of `None`) for service discovery when you don't need `kube-proxy` load balancing.
|
||||
- Use [headless Services](/docs/concepts/services-networking/service/#headless-services)
|
||||
(which have a `ClusterIP` of `None`) for service discovery when you don't need `kube-proxy`
|
||||
load balancing.
|
||||
-->
|
||||
- 当你不需要 `kube-proxy` 负载均衡时，
|
||||
使用[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
|
||||
|
|
@ -158,9 +194,21 @@ services) (which have a `ClusterIP` of `None`) for service discovery when you do
|
|||
## 使用标签 {#using-labels}
|
||||
|
||||
<!--
|
||||
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app.kubernetes.io/name: MyApp`. See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app for examples of this approach.
|
||||
A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. When you need to update a running service without downtime, use a [Deployment](/docs/concepts/workloads/controllers/deployment/).
|
||||
A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate.
|
||||
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify
|
||||
__semantic attributes__ of your application or Deployment, such as `{ app.kubernetes.io/name:
|
||||
MyApp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the
|
||||
appropriate Pods for other resources; for example, a Service that selects all `tier: frontend`
|
||||
Pods, or all `phase: test` components of `app.kubernetes.io/name: MyApp`.
|
||||
See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app
|
||||
for examples of this approach.
|
||||
|
||||
A Service can be made to span multiple Deployments by omitting release-specific labels from its
|
||||
selector. When you need to update a running service without downtime, use a
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/).
|
||||
|
||||
A desired state of an object is described by a Deployment, and if changes to that spec are
|
||||
_applied_, the deployment controller changes the actual state to the desired state at a controlled
|
||||
rate.
|
||||
-->
|
||||
- 定义并使用[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)来识别应用程序
|
||||
或 Deployment 的 **语义属性**，例如 `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`。
|
||||
|
|
@ -175,16 +223,23 @@ A desired state of an object is described by a Deployment, and if changes to tha
|
|||
控制器以受控速率将实际状态改变为期望状态。
|
||||
|
||||
<!--
|
||||
- Use the [Kubernetes common labels](/docs/concepts/overview/working-with-objects/common-labels/) for common use cases. These standardized labels enrich the metadata in a way that allows tools, including `kubectl` and [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), to work in an interoperable way.
|
||||
- Use the [Kubernetes common labels](/docs/concepts/overview/working-with-objects/common-labels/)
|
||||
for common use cases. These standardized labels enrich the metadata in a way that allows tools,
|
||||
including `kubectl` and [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), to
|
||||
work in an interoperable way.
|
||||
-->
|
||||
|
||||
- 对于常见场景，应使用 [Kubernetes 通用标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/)。
|
||||
这些标准化的标签丰富了对象的元数据，使得包括 `kubectl` 和
|
||||
[仪表板（Dashboard）](/zh-cn/docs/tasks/access-application-cluster/web-ui-dashboard)
|
||||
这些工具能够以可互操作的方式工作。
|
||||
|
||||
<!--
|
||||
- You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and Services match to Pods using selector labels, removing the relevant labels from a Pod will stop it from being considered by a controller or from being served traffic by a Service. If you remove the labels of an existing Pod, its controller will create a new Pod to take its place. This is a useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
|
||||
- You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and
|
||||
Services match to Pods using selector labels, removing the relevant labels from a Pod will stop
|
||||
it from being considered by a controller or from being served traffic by a Service. If you remove
|
||||
the labels of an existing Pod, its controller will create a new Pod to take its place. This is a
|
||||
useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove
|
||||
or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
|
||||
-->
|
||||
- 你可以操纵标签进行调试。
|
||||
由于 Kubernetes 控制器（例如 ReplicaSet）和服务使用选择器标签来匹配 Pod，
|
||||
|
|
@ -199,20 +254,26 @@ A desired state of an object is described by a Deployment, and if changes to tha
|
|||
## 使用 kubectl {#using-kubectl}
|
||||
|
||||
<!--
|
||||
- Use `kubectl apply -f <directory>`. This looks for Kubernetes configuration in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes it to `apply`.
|
||||
- Use `kubectl apply -f <directory>`. This looks for Kubernetes configuration in all `.yaml`,
|
||||
`.yml`, and `.json` files in `<directory>` and passes it to `apply`.
|
||||
-->
|
||||
- 使用 `kubectl apply -f <directory>`。
|
||||
它在 `<directory>` 中的所有` .yaml`、`.yml` 和 `.json` 文件中查找 Kubernetes 配置，并将其传递给 `apply`。
|
||||
- 使用 `kubectl apply -f <目录>`。
|
||||
它在 `<目录>` 中的所有 `.yaml`、`.yml` 和 `.json` 文件中查找 Kubernetes 配置，并将其传递给 `apply`。
|
||||
|
||||
<!--
|
||||
- Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
|
||||
- Use label selectors for `get` and `delete` operations instead of specific object names. See the
|
||||
sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
|
||||
and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
|
||||
-->
|
||||
- 使用标签选择器进行 `get` 和 `delete` 操作，而不是特定的对象名称。
|
||||
- 请参阅[标签选择器](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)和
|
||||
[有效使用标签](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。
|
||||
|
||||
<!--
|
||||
- Use `kubectl create deployment` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
|
||||
- Use `kubectl create deployment` and `kubectl expose` to quickly create single-container
|
||||
Deployments and Services.
|
||||
See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/)
|
||||
for an example.
|
||||
-->
|
||||
- 使用 `kubectl create deployment` 和 `kubectl expose` 来快速创建单容器 Deployment 和 Service。
|
||||
有关示例，请参阅[使用服务访问集群中的应用程序](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/)。
|
||||
|
|
|
|||
Loading…
Reference in New Issue