You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/zh-cn/docs/concepts/configuration/overview.md
+95-34Lines changed: 95 additions & 34 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,19 +4,23 @@ content_type: concept
4
4
weight: 10
5
5
---
6
6
<!--
7
+
reviewers:
8
+
- mikedanese
7
9
title: Configuration Best Practices
8
10
content_type: concept
9
11
weight: 10
10
12
-->
11
13
12
14
<!-- overview -->
13
15
<!--
14
-
This document highlights and consolidates configuration best practices that are introduced throughout the user guide, Getting Started documentation, and examples.
16
+
This document highlights and consolidates configuration best practices that are introduced
17
+
throughout the user guide, Getting Started documentation, and examples.
15
18
-->
16
19
本文档重点介绍并整合了整个用户指南、入门文档和示例中介绍的配置最佳实践。
17
20
18
21
<!--
19
-
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.
22
+
This is a living document. If you think of something that is not on this list but might be useful
23
+
to others, please don't hesitate to file an issue or submit a PR.
20
24
-->
21
25
这是一份不断改进的文件。
22
26
如果你认为某些内容缺失但可能对其他人有用，请不要犹豫，提交 Issue 或提交 PR。
@@ -33,26 +37,33 @@ This is a living document. If you think of something that is not on this list bu
33
37
- 定义配置时，请指定最新的稳定 API 版本。
34
38
35
39
<!--
36
-
- 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.
40
+
- Configuration files should be stored in version control before being pushed to the cluster. This
41
+
allows you to quickly roll back a configuration change if necessary. It also aids cluster
42
+
re-creation and restoration.
37
43
-->
38
44
- 在推送到集群之前，配置文件应存储在版本控制中。
39
45
这允许你在必要时快速回滚配置更改。
40
-
它还有助于集群重新创建和恢复。
46
+
它还有助于集群重新创建和恢复。
41
47
42
48
<!--
43
-
- 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.
49
+
- Write your configuration files using YAML rather than JSON. Though these formats can be used
50
+
interchangeably in almost all scenarios, YAML tends to be more user-friendly.
- 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.
55
+
- Group related objects into a single file whenever it makes sense. One file is often easier to
- 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.
65
+
- Note also that many `kubectl` commands can be called on a directory. For example, you can call
66
+
`kubectl apply` on a directory of config files.
56
67
-->
57
68
- 另请注意，可以在目录上调用许多 `kubectl` 命令。
58
69
例如，你可以在配置文件的目录中调用 `kubectl apply`。
@@ -67,16 +78,22 @@ This is a living document. If you think of something that is not on this list bu
67
78
-->
68
79
- 将对象描述放在注释中，以便更好地进行内省。
69
80
70
-
71
81
<!--
72
82
## "Naked" Pods versus ReplicaSets, Deployments, and Jobs {#naked-pods-vs-replicasets-deployments-and-jobs}
73
83
-->
74
-
## “独立的“ Pod 与 ReplicaSet、Deployment 和 Job {#naked-pods-vs-replicasets-deployments-and-jobs}
84
+
## “独立的“ Pod 与 ReplicaSet、Deployment 和 Job {#naked-pods-vs-replicasets-deployments-and-jobs}
75
85
76
86
<!--
77
-
- 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.
78
-
79
-
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.
87
+
- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or
88
+
[Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods
89
+
will not be rescheduled in the event of a node failure.
90
+
91
+
A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is
92
+
always available, and specifies a strategy to replace Pods (such as
93
+
[RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is
94
+
almost always preferable to creating Pods directly, except for some explicit
@@ -95,9 +112,11 @@ This is a living document. If you think of something that is not on this list bu
95
112
## 服务 {#services}
96
113
97
114
<!--
98
-
- 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:
99
-
100
-
*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.
115
+
- Create a [Service](/docs/concepts/services-networking/service/) before its corresponding backend
116
+
workloads (Deployments or ReplicaSets), and before any workloads that need to access it.
117
+
When Kubernetes starts a container, it provides environment variables pointing to all the Services
118
+
which were running when the container was started. For example, if a Service named `foo` exists,
119
+
all containers will get the following variables in their initial environment:
- An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The
117
-
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.
140
+
- An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/)
141
+
is a DNS server. The DNS server watches the Kubernetes API for new `Services` and creates a set
142
+
of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be
143
+
able to do name resolution of `Services` automatically.
- 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`.
125
-
126
-
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/).
127
-
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`.
150
+
- Don't specify a `hostPort` for a Pod unless it is absolutely necessary. When you bind a Pod to a
151
+
`hostPort`, it limits the number of places the Pod can be scheduled, because each <`hostIP`,
152
+
`hostPort`, `protocol`> combination must be unique. If you don't specify the `hostIP` and
153
+
`protocol` explicitly, Kubernetes will use `0.0.0.0` as the default `hostIP` and `TCP` as the
154
+
default `protocol`.
155
+
156
+
If you only need access to the port for debugging purposes, you can use the
@@ -158,9 +194,21 @@ services) (which have a `ClusterIP` of `None`) for service discovery when you do
158
194
## 使用标签 {#using-labels}
159
195
160
196
<!--
161
-
- 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.
162
-
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/).
163
-
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.
197
+
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify
198
+
__semantic attributes__ of your application or Deployment, such as `{ app.kubernetes.io/name:
199
+
MyApp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the
200
+
appropriate Pods for other resources; for example, a Service that selects all `tier: frontend`
201
+
Pods, or all `phase: test` components of `app.kubernetes.io/name: MyApp`.
202
+
See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app
203
+
for examples of this approach.
204
+
205
+
A Service can be made to span multiple Deployments by omitting release-specific labels from its
206
+
selector. When you need to update a running service without downtime, use a
@@ -175,16 +223,23 @@ A desired state of an object is described by a Deployment, and if changes to tha
175
223
控制器以受控速率将实际状态改变为期望状态。
176
224
177
225
<!--
178
-
- 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.
226
+
- Use the [Kubernetes common labels](/docs/concepts/overview/working-with-objects/common-labels/)
227
+
for common use cases. These standardized labels enrich the metadata in a way that allows tools,
228
+
including `kubectl` and [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), to
- 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).
237
+
- You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and
238
+
Services match to Pods using selector labels, removing the relevant labels from a Pod will stop
239
+
it from being considered by a controller or from being served traffic by a Service. If you remove
240
+
the labels of an existing Pod, its controller will create a new Pod to take its place. This is a
241
+
useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove
242
+
or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
@@ -199,20 +254,26 @@ A desired state of an object is described by a Deployment, and if changes to tha
199
254
## 使用 kubectl {#using-kubectl}
200
255
201
256
<!--
202
-
- Use `kubectl apply -f <directory>`. This looks for Kubernetes configuration in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes it to `apply`.
257
+
- Use `kubectl apply -f <directory>`. This looks for Kubernetes configuration in all `.yaml`,
258
+
`.yml`, and `.json` files in `<directory>` and passes it to `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).
264
+
- Use label selectors for `get` and `delete` operations instead of specific object names. See the
265
+
sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
266
+
and [using labels effectively](/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.
273
+
- Use `kubectl create deployment` and `kubectl expose` to quickly create single-container
274
+
Deployments and Services.
275
+
See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/)
0 commit comments