@@ -24,9 +24,9 @@ This page shows how to view, work in, and delete {{< glossary_tooltip text="name
24
24
* You have a basic understanding of Kubernetes {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="Services" >}}, and {{< glossary_tooltip text="Deployments" term_id="deployment" >}}.
25
25
-->
26
26
* 你已拥有一个[ 配置好的 Kubernetes 集群] ( /zh-cn/docs/setup/ ) 。
27
- * 你已对 Kubernetes 的 {{< glossary_tooltip text="Pods " term_id="pod" >}} ,
28
- {{< glossary_tooltip term_id="service" text="Services " >}} , 和
29
- {{< glossary_tooltip text="Deployments " term_id="deployment" >}} 有基本理解。
27
+ * 你已对 Kubernetes 的 {{< glossary_tooltip text="Pod " term_id="pod" >}}、
28
+ {{< glossary_tooltip term_id="service" text="Service " >}} 和
29
+ {{< glossary_tooltip text="Deployment " term_id="deployment" >}} 有基本理解。
30
30
31
31
<!-- steps -->
32
32
@@ -91,16 +91,18 @@ Resource Limits
91
91
92
92
<!-- Resource quota tracks aggregate usage of resources in the *Namespace* and allows cluster operators
93
93
to define *Hard* resource usage limits that a *Namespace* may consume. -->
94
- 资源配额跟踪并聚合 * Namespace* 中资源的使用情况,并允许集群运营者定义 * Namespace* 可能消耗的 * Hard* 资源使用限制。
94
+ 资源配额跟踪并聚合 ** Namespace** 中资源的使用情况,并允许集群运营者定义 ** Namespace** 可能消耗的 ** Hard* * 资源使用限制。
95
95
96
- <!-- A limit range defines min/max constraints on the amount of resources a single entity can consume in
96
+ <!--
97
+ A limit range defines min/max constraints on the amount of resources a single entity can consume in
97
98
a *Namespace*.
98
99
99
- See [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) -->
100
+ See [Admission control: Limit Range](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)
101
+ -->
100
102
101
- 限制区间定义了单个实体在一个 * Namespace* 中可使用的最小/最大资源量约束。
103
+ 限制区间定义了单个实体在一个 ** Namespace* * 中可使用的最小/最大资源量约束。
102
104
103
- 参阅 [ 准入控制: 限制区间] ( https://git.k8s.io/community/contributors/ design-proposals/resource-management/admission_control_limit_range.md )
105
+ 参阅 [ 准入控制: 限制区间] ( https://git.k8s.io/design-proposals-archive /resource-management/admission_control_limit_range.md ) 。
104
106
105
107
<!--
106
108
A namespace can be in one of two phases:
@@ -110,14 +112,14 @@ A namespace can be in one of two phases:
110
112
111
113
For more details, see [Namespace](/docs/reference/kubernetes-api/cluster-resources/namespace-v1/)
112
114
in the API reference.
113
- -->
115
+ -->
114
116
115
117
名字空间可以处于下列两个阶段中的一个:
116
118
117
119
* ` Active ` 名字空间正在被使用中
118
120
* ` Terminating ` 名字空间正在被删除,且不能被用于新对象。
119
121
120
- 更多细节,参阅 API 参考中的[ 命名空间] ( /docs/reference/kubernetes-api/cluster-resources/namespace-v1/ ) 。
122
+ 更多细节,参阅 API 参考中的[ 命名空间] ( /zh-cn/ docs/reference/kubernetes-api/cluster-resources/namespace-v1/ ) 。
121
123
122
124
<!-- ## Creating a new namespace -->
123
125
## 创建名字空间
@@ -165,11 +167,14 @@ The name of your namespace must be a valid
165
167
<!--
166
168
There's an optional field `finalizers`, which allows observables to purge resources whenever the namespace is deleted. Keep in mind that if you specify a nonexistent finalizer, the namespace will be created but will get stuck in the `Terminating` state if the user tries to delete it.
167
169
168
- More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/community/contributors/ design-proposals/architecture/namespaces.md#finalizers).
170
+ More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/design-proposals-archive /architecture/namespaces.md#finalizers).
169
171
-->
170
- 可选字段 ` finalizers ` 允许观察者们在名字空间被删除时清除资源。记住如果指定了一个不存在的终结器,名字空间仍会被创建,但如果用户试图删除它,它将陷入 ` Terminating ` 状态。
172
+ 可选字段 ` finalizers ` 允许观察者们在名字空间被删除时清除资源。
173
+ 记住如果指定了一个不存在的终结器,名字空间仍会被创建,
174
+ 但如果用户试图删除它,它将陷入 ` Terminating ` 状态。
171
175
172
- 更多有关 ` finalizers ` 的信息请查阅 [ 设计文档] ( https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers ) 中名字空间部分。
176
+ 更多有关 ` finalizers ` 的信息请查阅
177
+ [ 设计文档] ( https://git.k8s.io/design-proposals-archive/architecture/namespaces.md#finalizers ) 中名字空间部分。
173
178
174
179
<!-- ## Deleting a namespace -->
175
180
## 删除名字空间
@@ -185,7 +190,7 @@ kubectl delete namespaces <insert-some-namespace-name>
185
190
186
191
<!-- This deletes _everything_ under the namespace! -->
187
192
{{< warning >}}
188
- 这会删除名字空间下的 _ 所有内容 _ !
193
+ 这会删除名字空间下的 ** 所有内容 ** !
189
194
{{< /warning >}}
190
195
191
196
<!-- This delete is asynchronous, so for a time you will see the namespace in the `Terminating` state. -->
@@ -206,13 +211,13 @@ kubectl delete namespaces <insert-some-namespace-name>
206
211
1 . 理解 default 名字空间
207
212
208
213
默认情况下,Kubernetes 集群会在配置集群时实例化一个 default 名字空间,用以存放集群所使用的默认
209
- Pods、Services 和 Deployments 集合。
214
+ Pod、Service 和 Deployment 集合。
210
215
211
216
<!--
212
217
Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following:
213
218
-->
214
219
215
- 假设你有一个新的集群,你可以通过执行以下操作来内省可用的名字空间
220
+ 假设你有一个新的集群,你可以通过执行以下操作来内省可用的名字空间:
216
221
217
222
``` shell
218
223
kubectl get namespaces
@@ -245,8 +250,8 @@ kubectl delete namespaces <insert-some-namespace-name>
245
250
and go, and the restrictions on who can or cannot modify resources
246
251
are relaxed to enable agile development.
247
252
-->
248
- 开发团队希望在集群中维护一个空间,以便他们可以查看用于构建和运行其应用程序的 Pods、Services
249
- 和 Deployments 列表。在这个空间里,Kubernetes 资源被自由地加入或移除,
253
+ 开发团队希望在集群中维护一个空间,以便他们可以查看用于构建和运行其应用程序的 Pod、Service
254
+ 和 Deployment 列表。在这个空间里,Kubernetes 资源被自由地加入或移除,
250
255
对谁能够或不能修改资源的限制被放宽,以实现敏捷开发。
251
256
252
257
<!--
@@ -255,13 +260,13 @@ kubectl delete namespaces <insert-some-namespace-name>
255
260
Pods, Services, and Deployments that run the production site.
256
261
-->
257
262
运维团队希望在集群中维护一个空间,以便他们可以强制实施一些严格的规程,
258
- 对谁可以或不可以操作运行生产站点的 Pods、Services 和 Deployments 集合进行控制。
263
+ 对谁可以或不可以操作运行生产站点的 Pod、Service 和 Deployment 集合进行控制。
259
264
260
265
<!--
261
266
One pattern this organization could follow is to partition the Kubernetes cluster into
262
267
two namespaces: `development` and `production`.
263
268
-->
264
- 该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个名字空间:development 和 production。
269
+ 该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个名字空间:` development ` 和 ` production ` 。
265
270
266
271
<!-- Let's create two new namespaces to hold our work. -->
267
272
让我们创建两个新的名字空间来保存我们的工作。
@@ -294,14 +299,14 @@ kubectl delete namespaces <insert-some-namespace-name>
294
299
```
295
300
296
301
<!-- 3. Create pods in each namespace -->
297
- 3 . 在每个名字空间中创建 pod
302
+ 3 . 在每个名字空间中创建 Pod
298
303
299
304
<!--
300
305
A Kubernetes namespace provides the scope for Pods, Services, and Deployments in the cluster.
301
306
302
307
Users interacting with one namespace do not see the content in another namespace.
303
308
-->
304
- Kubernetes 名字空间为集群中的 Pods、Services 和 Deployments 提供了作用域。
309
+ Kubernetes 名字空间为集群中的 Pod、Service 和 Deployment 提供了作用域。
305
310
306
311
与一个名字空间交互的用户不会看到另一个名字空间中的内容。
307
312
@@ -346,8 +351,8 @@ kubectl delete namespaces <insert-some-namespace-name>
346
351
看起来还不错,开发人员能够做他们想做的事,而且他们不必担心会影响到
347
352
` production ` 名字空间下面的内容。
348
353
349
- 让我们切换到 ` production ` 名字空间,展示一下一个名字空间中的资源是如何对
350
- 另一个名字空间隐藏的 。
354
+ 让我们切换到 ` production ` 名字空间,
355
+ 展示一下一个名字空间中的资源是如何对另一个名字空间隐藏的 。
351
356
352
357
名字空间 ` production ` 应该是空的,下面的命令应该不会返回任何东西。
353
358
@@ -387,7 +392,7 @@ kubectl delete namespaces <insert-some-namespace-name>
387
392
<!--
388
393
At this point, it should be clear that the resources users create in one namespace are hidden from the other namespace.
389
394
-->
390
- 此时,应该很清楚的展示了用户在一个名字空间中创建的资源对另一个名字空间是隐藏的 。
395
+ 此时,应该很清楚地展示了用户在一个名字空间中创建的资源对另一个名字空间是隐藏的 。
391
396
392
397
<!--
393
398
As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different
@@ -408,7 +413,7 @@ A single cluster should be able to satisfy the needs of multiple users or groups
408
413
单个集群应该能满足多个用户及用户组的需求(以下称为 “用户社区”)。
409
414
410
415
<!-- Kubernetes _namespaces_ help different projects, teams, or customers to share a Kubernetes cluster. -->
411
- Kubernetes _ 名字空间 _ 帮助不同的项目、团队或客户去共享 Kubernetes 集群。
416
+ Kubernetes ** 名字空间 ** 帮助不同的项目、团队或客户去共享 Kubernetes 集群。
412
417
413
418
<!--
414
419
It does this by providing the following:
@@ -440,9 +445,9 @@ Each user community has its own:
440
445
-->
441
446
每个用户社区都有自己的:
442
447
443
- 1 . 资源(pods 、服务、 副本控制器等等)
448
+ 1 . 资源(Pod 、服务、副本控制器等等)
444
449
2 . 策略(谁能或不能在他们的社区里执行操作)
445
- 3 . 约束(该社区允许多少配额,等等 )
450
+ 3 . 约束(该社区允许多少配额等等 )
446
451
447
452
<!--
448
453
A cluster operator may create a Namespace for each unique user community.
@@ -505,10 +510,10 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
505
510
<!--
506
511
* Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference).
507
512
* Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request)
508
- * See [namespaces design](https://github.com/kubernetes/community/blob/master/contributors/ design-proposals/architecture/namespaces.md).
513
+ * See [namespaces design](https://git.k8s.io/ design-proposals-archive /architecture/namespaces.md).
509
514
-->
510
515
511
516
* 进一步了解[ 设置名字空间偏好] ( /zh-cn/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference )
512
517
* 进一步了解[ 设置请求的名字空间] ( /zh-cn/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request )
513
- * 参阅[ 名字空间的设计文档] ( https://github.com/kubernetes/community/blob/master/contributors/ design-proposals/architecture/namespaces.md )
518
+ * 参阅[ 名字空间的设计文档] ( https://git.k8s.io/ design-proposals-archive /architecture/namespaces.md )
514
519
0 commit comments