release-1.17_zh issue tasks (#18295)
This commit is contained in:
Xiaolong He
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
11a30d3e2e
commit
0b5b5fd6ea
@@ -1,868 +0,0 @@
|
||||
---
|
||||
title: Job 从运行到完成
|
||||
content_template: templates/concept
|
||||
feature:
|
||||
title: Batch execution
|
||||
description: >
|
||||
In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
- soltysh
|
||||
title: Jobs - Run to Completion
|
||||
content_template: templates/concept
|
||||
feature:
|
||||
title: Batch execution
|
||||
description: >
|
||||
In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
|
||||
weight: 70
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
A Job creates one or more Pods and ensures that a specified number of them successfully terminate.
|
||||
As pods successfully complete, the Job tracks the successful completions. When a specified number
|
||||
of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up
|
||||
the Pods it created.
|
||||
-->
|
||||
|
||||
Job 创建一个或多个 pod，并且确保指定数量的 pod 成功终止。Pod 成功完成后，Job 将跟踪成功完成的情况。当达到指定的成功完成次数时，任务（即 Job）就完成了。删除 Job 将清除其创建的 pod。
|
||||
|
||||
<!--
|
||||
A simple case is to create one Job object in order to reliably run one Pod to completion.
|
||||
The Job object will start a new Pod if the first Pod fails or is deleted (for example
|
||||
due to a node hardware failure or a node reboot).
|
||||
-->
|
||||
|
||||
一种简单的情况时创建一个 Job 对象，以便可靠地运行一个 Pod 来完成。如果第一个 pod 失败了或被删除了（例如，由于节点硬件故障或节点重启），则 Job 对象将启动一个新的 pod。
|
||||
|
||||
<!--
|
||||
You can also use a Job to run multiple Pods in parallel.
|
||||
-->
|
||||
|
||||
也可以使用 Job 去并行运行多个 pod。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Running an example Job
|
||||
-->
|
||||
|
||||
## 运行一个 Job 示例
|
||||
|
||||
<!--
|
||||
Here is an example Job config. It computes π to 2000 places and prints it out.
|
||||
It takes around 10s to complete.
|
||||
-->
|
||||
|
||||
下面是一个 Job 配置样例。它计算 π 到2000位并将其打印出来。大约需要 10 秒钟才能完成。
|
||||
|
||||
{{< codenew file="controllers/job.yaml" >}}
|
||||
|
||||
<!--
|
||||
You can run the example with this command:
|
||||
-->
|
||||
|
||||
可以使用以下命令运行示例：
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/job.yaml
|
||||
```
|
||||
```
|
||||
job "pi" created
|
||||
```
|
||||
|
||||
<!--
|
||||
Check on the status of the Job with `kubectl`:
|
||||
-->
|
||||
|
||||
使用 `kubectl` 命令检查 Job 的状态：
|
||||
|
||||
```shell
|
||||
kubectl describe jobs/pi
|
||||
```
|
||||
```
|
||||
Name: pi
|
||||
Namespace: default
|
||||
Selector: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495
|
||||
Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495
|
||||
job-name=pi
|
||||
Annotations: <none>
|
||||
Parallelism: 1
|
||||
Completions: 1
|
||||
Start Time: Tue, 07 Jun 2016 10:56:16 +0200
|
||||
Pods Statuses: 0 Running / 1 Succeeded / 0 Failed
|
||||
Pod Template:
|
||||
Labels: controller-uid=b1db589a-2c8d-11e6-b324-0209dc45a495
|
||||
job-name=pi
|
||||
Containers:
|
||||
pi:
|
||||
Image: perl
|
||||
Port:
|
||||
Command:
|
||||
perl
|
||||
-Mbignum=bpi
|
||||
-wle
|
||||
print bpi(2000)
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {job-controller } Normal SuccessfulCreate Created pod: pi-dtn4q
|
||||
```
|
||||
|
||||
<!--
|
||||
To view completed Pods of a Job, use `kubectl get pods`.
|
||||
-->
|
||||
|
||||
要查看 Job 的已完成 pod，可以使用 `kubectl get pods` 命令。
|
||||
|
||||
<!--
|
||||
To list all the Pods that belong to a Job in a machine readable form, you can use a command like this:
|
||||
-->
|
||||
|
||||
要以机器可读的形式列出属于 Job 的所有 pod，可以使用以下命令：
|
||||
|
||||
```shell
|
||||
pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
|
||||
echo $pods
|
||||
```
|
||||
```
|
||||
pi-aiw0a
|
||||
```
|
||||
|
||||
<!--
|
||||
Here, the selector is the same as the selector for the Job. The `--output=jsonpath` option specifies an expression
|
||||
that just gets the name from each Pod in the returned list.
|
||||
-->
|
||||
|
||||
这里，选择器与 Job 的选择器相同。`--output=jsonpath` 选项指定一个表达式来从 pod 返回列表中获取每个 pod 的名称。
|
||||
|
||||
<!--
|
||||
View the standard output of one of the pods:
|
||||
-->
|
||||
|
||||
查看其中一个 pod 的标准输出：
|
||||
|
||||
```shell
|
||||
kubectl logs $pods
|
||||
```
|
||||
The output is similar to this:
|
||||
```shell
|
||||
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
|
||||
```
|
||||
|
||||
<!--
|
||||
## Writing a Job Spec
|
||||
-->
|
||||
|
||||
## 编写 Job 规范
|
||||
|
||||
<!--
|
||||
As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.
|
||||
-->
|
||||
|
||||
和其他 Kubernetes 配置一样，Job 需要 `apiVersion`，`kind` 和 `metadata` 字段。
|
||||
|
||||
<!--
|
||||
A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
|
||||
-->
|
||||
|
||||
Job 也需要 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
|
||||
|
||||
<!--
|
||||
### Pod Template
|
||||
-->
|
||||
|
||||
### Pod 模板
|
||||
|
||||
<!--
|
||||
The `.spec.template` is the only required field of the `.spec`.
|
||||
-->
|
||||
|
||||
`.spec.template` 是 `.spec` 中唯一必填字段。
|
||||
|
||||
<!--
|
||||
The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`.
|
||||
-->
|
||||
|
||||
`.spec.template` 是 [pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它具有与 [pod](/docs/user-guide/pods) 完全相同的架构，只是它是嵌套的并且没有 `apiVersion` 或 `kind`。
|
||||
|
||||
<!--
|
||||
In addition to required fields for a Pod, a pod template in a Job must specify appropriate
|
||||
labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
|
||||
-->
|
||||
|
||||
除了 pod 的必填字段，Job 中的 pod 模板还必须指定合适的标签（参考 [pod 选择器](#pod-selector)）和适当的重启策略。
|
||||
|
||||
<!--
|
||||
Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed.
|
||||
-->
|
||||
|
||||
[`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 只能等于 `Never` 或 `OnFailure`。
|
||||
|
||||
<!--
|
||||
### Pod Selector
|
||||
-->
|
||||
|
||||
### Pod 选择器
|
||||
|
||||
<!--
|
||||
The `.spec.selector` field is optional. In almost all cases you should not specify it.
|
||||
See section [specifying your own pod selector](#specifying-your-own-pod-selector).
|
||||
-->
|
||||
|
||||
`.spec.selector` 字段是可选的。在大多数场景下不必指定它。请参阅[指定自己的 pod 选择器](#specifying-your-own-pod-selector)。
|
||||
|
||||
<!--
|
||||
### Parallel Jobs
|
||||
-->
|
||||
|
||||
### 并行 Job
|
||||
|
||||
<!--
|
||||
There are three main types of task suitable to run as a Job:
|
||||
-->
|
||||
|
||||
下面是适合作为 Job 运行的三种主要任务类型：
|
||||
|
||||
<!--
|
||||
1. Non-parallel Jobs
|
||||
- normally, only one Pod is started, unless the Pod fails.
|
||||
- the Job is complete as soon as its Pod terminates successfully.
|
||||
1. Parallel Jobs with a *fixed completion count*:
|
||||
- specify a non-zero positive value for `.spec.completions`.
|
||||
- the Job represents the overall task, and is complete when there is one successful Pod for each value in the range 1 to `.spec.completions`.
|
||||
- **not implemented yet:** Each Pod is passed a different index in the range 1 to `.spec.completions`.
|
||||
1. Parallel Jobs with a *work queue*:
|
||||
- do not specify `.spec.completions`, default to `.spec.parallelism`.
|
||||
- the Pods must coordinate amongst themselves or an external service to determine what each should work on. For example, a Pod might fetch a batch of up to N items from the work queue.
|
||||
- each Pod is independently capable of determining whether or not all its peers are done, and thus that the entire Job is done.
|
||||
- when _any_ Pod from the Job terminates with success, no new Pods are created.
|
||||
- once at least one Pod has terminated with success and all Pods are terminated, then the Job is completed with success.
|
||||
- once any Pod has exited with success, no other Pod should still be doing any work for this task or writing any output. They should all be in the process of exiting.
|
||||
-->
|
||||
|
||||
1. 非并行 Job
|
||||
- 通常，除非 pod 发生故障，否则仅启动一个 pod。
|
||||
- 一旦 pod 成功终止，Job 即完成。
|
||||
1. 配置了*固定完成计数*的并行 Job：
|
||||
- 为 `.spec.completions` 指定一个非零正数值。
|
||||
- Job 代表整体任务，并且在 1 到 `.spec.completions` 范围内都有一个 pod 成功完成时，Job 才算完成。
|
||||
- **尚未实现:** 每个 pod 都会被传递一个从 1 到 `.spec.completions` 之间的索引值。
|
||||
1. 具有*工作队列*的并行 Job：
|
||||
- 不指定 `.spec.completions` 的话, 默认为 `.spec.parallelism`。
|
||||
- Pod 必须在彼此之间或外部服务之间进行协调，来确定每个 pod 该处理什么任务。例如，一个 pod 可以从工作队列中获取一批任务（最多 N 个）。
|
||||
- 每个 pod 都可以独立确定其所有对端是否完成，从而确定整个 Job 完成。
|
||||
- 当 Job 中的_任何_ pod 成功结束后，不会再创建新的 pod。
|
||||
- 一旦至少一个 pod 成功终止并且所有的 pod 都终止了，则 Job 就成功完成了。
|
||||
- 一旦 任何 pod 成功退出，其他 pod 都不应该为此任务做任务工作或编写任何输出。它们都应该处在退出过程中。
|
||||
|
||||
<!--
|
||||
For a _non-parallel_ Job, you can leave both `.spec.completions` and `.spec.parallelism` unset. When both are
|
||||
unset, both are defaulted to 1.
|
||||
-->
|
||||
|
||||
对于_非并行_ Job，可以不设置 `.spec.completions` 和 `.spec.parallelism`。两者均未设置时，默认值为 1。
|
||||
|
||||
<!--
|
||||
For a _fixed completion count_ Job, you should set `.spec.completions` to the number of completions needed.
|
||||
You can set `.spec.parallelism`, or leave it unset and it will default to 1.
|
||||
-->
|
||||
|
||||
对于一个_固定完成计数_ Job，应该将 `.spec.completions` 设置为所需的完成数量。`.spec.parallelism` 可以设置，也可以不设置，默认值为 1。
|
||||
|
||||
<!--
|
||||
For a _work queue_ Job, you must leave `.spec.completions` unset, and set `.spec.parallelism` to
|
||||
a non-negative integer.
|
||||
-->
|
||||
|
||||
对于一个_工作队列_ Job，不要设置 `.spec.completions`，并且将 `.spec.parallelism` 设置一个非负整数。
|
||||
|
||||
<!--
|
||||
For more information about how to make use of the different types of job, see the [job patterns](#job-patterns) section.
|
||||
-->
|
||||
|
||||
有关如何使用不同类型 Job 的更多信息，请参考 [Job 模式](#job-patterns)部分。
|
||||
|
||||
|
||||
<!--
|
||||
#### Controlling Parallelism
|
||||
-->
|
||||
|
||||
#### 控制并行
|
||||
|
||||
<!--
|
||||
The requested parallelism (`.spec.parallelism`) can be set to any non-negative value.
|
||||
If it is unspecified, it defaults to 1.
|
||||
If it is specified as 0, then the Job is effectively paused until it is increased.
|
||||
-->
|
||||
|
||||
请求的并发数（`.spec.parallelism`）可以设置为任何非负的整数。如果未指定，默认值为 1。如果指定为 0，则 Job 就被有效地暂停直到该配置值增加。
|
||||
|
||||
<!--
|
||||
Actual parallelism (number of pods running at any instant) may be more or less than requested
|
||||
parallelism, for a variety of reasons:
|
||||
-->
|
||||
|
||||
实际的并发数（在任何时刻运行着的 pod 数量）由于下面的一些原因，可能大于或小于请求的并发数：
|
||||
|
||||
<!--
|
||||
- For _fixed completion count_ Jobs, the actual number of pods running in parallel will not exceed the number of
|
||||
remaining completions. Higher values of `.spec.parallelism` are effectively ignored.
|
||||
- For _work queue_ Jobs, no new Pods are started after any Pod has succeeded -- remaining Pods are allowed to complete, however.
|
||||
- If the controller has not had time to react.
|
||||
- If the controller failed to create Pods for any reason (lack of `ResourceQuota`, lack of permission, etc.),
|
||||
then there may be fewer pods than requested.
|
||||
- The controller may throttle new Pod creation due to excessive previous pod failures in the same Job.
|
||||
- When a Pod is gracefully shut down, it takes time to stop.
|
||||
-->
|
||||
|
||||
- 对于_固定完成计数_ Job，实际上并行运行的 pod 数量不会超过剩余的完成数。更高的 `.spec.parallelism` 值将被优先忽略。
|
||||
- 对于_工作队列_ Job，任何 pod 成功之后都不会启动新的 pod。然而，剩余的 pod 可以完成。
|
||||
- 如果控制器还没来得及反应。
|
||||
- 如果控制器由于任何原因（缺少 `ResourceQuota`，缺少权限等）未能创建 pod，则 pod 数量将少于请求数。
|
||||
- 控制器可能会因为同一 Job 中有过多之前失败的 pod，从而限制新的 pod 的创建。
|
||||
- 当 pod 优雅关闭时，需要花费一些时间才能停止。
|
||||
|
||||
<!--
|
||||
## Handling Pod and Container Failures
|
||||
-->
|
||||
|
||||
## 处理 Pod 和容器失败
|
||||
|
||||
<!--
|
||||
A container in a Pod may fail for a number of reasons, such as because the process in it exited with
|
||||
a non-zero exit code, or the container was killed for exceeding a memory limit, etc. If this
|
||||
happens, and the `.spec.template.spec.restartPolicy = "OnFailure"`, then the Pod stays
|
||||
on the node, but the container is re-run. Therefore, your program needs to handle the case when it is
|
||||
restarted locally, or else specify `.spec.template.spec.restartPolicy = "Never"`.
|
||||
See [pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) for more information on `restartPolicy`.
|
||||
-->
|
||||
|
||||
Pod 中的容器可能由于多种原因而失败，例如，由于容器中的进程以非零退出码退出，或者容器由于超过内存限制而被杀掉等。如果容器失败发生，并且 `.spec.template.spec.restartPolicy = "OnFailure"`，则 pod 停留在节点上，但是容器会重新运行。因此，你的程序需要处理本地重启的情况，或者指定 `.spec.template.spec.restartPolicy = "Never"`。参阅 [pod 生命周期](/docs/concepts/workloads/pods/pod-lifecycle/#example-states)获取更多关于 `restartPolicy` 的信息。
|
||||
|
||||
<!--
|
||||
An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node
|
||||
(node is upgraded, rebooted, deleted, etc.), or if a container of the Pod fails and the
|
||||
`.spec.template.spec.restartPolicy = "Never"`. When a Pod fails, then the Job controller
|
||||
starts a new Pod. This means that your application needs to handle the case when it is restarted in a new
|
||||
pod. In particular, it needs to handle temporary files, locks, incomplete output and the like
|
||||
caused by previous runs.
|
||||
-->
|
||||
|
||||
由于多种原因，整个 pod 也可能失败，比如，当 pod 从节点上被踢走（节点在升级，重启，被删除等），或者 pod 中的容器失败且设置了 `.spec.template.spec.restartPolicy = "Never"`。当 pod 失败后，Job 控制器将启动一个新的 pod。这意味着你的应用程序需要处理这种情况（应用程序在新的 pod 中重启）。特别是，它需要处理由先前运行引起的临时文件，锁，不完整输出等等。
|
||||
|
||||
<!--
|
||||
Note that even if you specify `.spec.parallelism = 1` and `.spec.completions = 1` and
|
||||
`.spec.template.spec.restartPolicy = "Never"`, the same program may
|
||||
sometimes be started twice.
|
||||
-->
|
||||
|
||||
请注意，即使你指定了 `.spec.parallelism = 1`，`.spec.completions = 1` 和 `.spec.template.spec.restartPolicy = "Never"`，统一程序有时也会启动两次。
|
||||
|
||||
<!--
|
||||
If you do specify `.spec.parallelism` and `.spec.completions` both greater than 1, then there may be
|
||||
multiple pods running at once. Therefore, your pods must also be tolerant of concurrency.
|
||||
-->
|
||||
|
||||
如果你指定 `.spec.parallelism` 和 `.spec.completions` 配置都大于 1，则可能同时有多个 pod 运行。因此，你的 pod 必须容忍并发。
|
||||
|
||||
<!--
|
||||
### Pod backoff failure policy
|
||||
-->
|
||||
|
||||
### Pod 的退避失败策略
|
||||
|
||||
<!--
|
||||
There are situations where you want to fail a Job after some amount of retries
|
||||
due to a logical error in configuration etc.
|
||||
To do so, set `.spec.backoffLimit` to specify the number of retries before
|
||||
considering a Job as failed. The back-off limit is set by default to 6. Failed
|
||||
Pods associated with the Job are recreated by the Job controller with an
|
||||
exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The
|
||||
back-off count is reset if no new failed Pods appear before the Job's next
|
||||
status check.
|
||||
-->
|
||||
|
||||
在某些情况下（配置中的逻辑错误等），你需要在重试一定次数后才使 Job 失败。为此需要设置 `.spec.backoffLimit` 配置值为判断 Job 失败前的重试次数。 退避限制默认设置为 6。与 Job 相关的 pod在失败后，经过一个指数级退避延迟（10 秒，20 秒，40 秒，上限为 6 分钟），由 Job 控制器重新创建。 如果在 Job 的下一次状态检查之前未出现新的失败 pod，则会重置退避计数。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12
|
||||
-->
|
||||
|
||||
1.12 之前的 Kubernetes 版本仍然存在问题 [#54870](https://github.com/kubernetes/kubernetes/issues/54870)
|
||||
|
||||
{{< /note >}}
|
||||
{{< note >}}
|
||||
<!--
|
||||
If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job
|
||||
will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting
|
||||
`restartPolicy = "Never"` when debugging the Job or using a logging system to ensure output
|
||||
from failed Jobs is not lost inadvertently.
|
||||
-->
|
||||
|
||||
如果你的 Job 外配置了 `restartPolicy = "OnFailure"`，请记住，一旦 Job 达到退避限制，运行在该 Job 的容器将被终止。这会使得调试 Job 的可执行将变得更加困难。我们建议在调试 Job 或使用日志系统时设置 `restartPolicy = "Never"`，以确保失败 Job 的输出不会在不经意间丢失。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Job Termination and Cleanup
|
||||
-->
|
||||
|
||||
## Job 终止和清理
|
||||
|
||||
<!--
|
||||
When a Job completes, no more Pods are created, but the Pods are not deleted either. Keeping them around
|
||||
allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output.
|
||||
The job object also remains after it is completed so that you can view its status. It is up to the user to delete
|
||||
old jobs after noting their status. Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too.
|
||||
-->
|
||||
|
||||
当 Job 完成后，不会再创建 pod，但是 pod 也不会被删除。将这些 pod 保留，使你仍然可以查看已完成 pod 的日志来检查错误，警告或其他诊断输出。Job 对象在完成后也同样保留下来，以便你可以查看它的状态。由用户来决定在查看完状态后删除旧的 Job。使用 `kubectl`（例如 `kubectl delete jobs/pi` 或 `kubectl delete -f ./job.yaml` ）来删除 Job。当你使用 `kubectl` 删除 Job 后，它所创建的所有 pod 也会被删除。
|
||||
|
||||
<!--
|
||||
By default, a Job will run uninterrupted unless a Pod fails (`restartPolicy=Never`) or a Container exits in error (`restartPolicy=OnFailure`), at which point the Job defers to the
|
||||
`.spec.backoffLimit` described above. Once `.spec.backoffLimit` has been reached the Job will be marked as failed and any running Pods will be terminated.
|
||||
-->
|
||||
|
||||
默认情况下，除非 pod 失败（`restartPolicy=Never`）或容器错误退出（`restartPolicy=OnFailure`），否则 Job 将不会被中断运行。Job 中断将遵循上面介绍的 `.spec.backoffLimit`。一旦 `.spec.backoffLimit` 达到，Job 将被标记为失败，企鹅别所有正运行的 pod 将被终止。
|
||||
|
||||
<!--
|
||||
Another way to terminate a Job is by setting an active deadline.
|
||||
Do this by setting the `.spec.activeDeadlineSeconds` field of the Job to a number of seconds.
|
||||
The `activeDeadlineSeconds` applies to the duration of the job, no matter how many Pods are created.
|
||||
Once a Job reaches `activeDeadlineSeconds`, all of its running Pods are terminated and the Job status will become `type: Failed` with `reason: DeadlineExceeded`.
|
||||
-->
|
||||
|
||||
终止 Job 的另一种方式是设置有限期限。通过设置 Job 对象的 `.spec.activeDeadlineSeconds` 字段为秒数来达到。`activeDeadlineSeconds` 适用于 Job 存在期间，不管有多少 pod 被创建。一旦 Job 达到 `activeDeadlineSeconds`，所有运行中的 pod将被终止，并且 Job 的状态将变成 `type: Failed` 与 `reason: DeadlineExceeded`。
|
||||
|
||||
<!--
|
||||
Note that a Job's `.spec.activeDeadlineSeconds` takes precedence over its `.spec.backoffLimit`. Therefore, a Job that is retrying one or more failed Pods will not deploy additional Pods once it reaches the time limit specified by `activeDeadlineSeconds`, even if the `backoffLimit` is not yet reached.
|
||||
-->
|
||||
|
||||
请注意，Job 的 `.spec.activeDeadlineSeconds` 配置优先于 `.spec.backoffLimit` 配置。因此，重试一个或多个失败 pod 的 Job 在达到 `activeDeadlineSeconds` 指定的时间限制前，不会部署其他的 pod，即使 `backoffLimit` 尚未达到。
|
||||
|
||||
<!--
|
||||
Example:
|
||||
-->
|
||||
|
||||
例子：
|
||||
|
||||
```yaml
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: pi-with-timeout
|
||||
spec:
|
||||
backoffLimit: 5
|
||||
activeDeadlineSeconds: 100
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: pi
|
||||
image: perl
|
||||
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
restartPolicy: Never
|
||||
```
|
||||
|
||||
<!--
|
||||
Note that both the Job spec and the [Pod template spec](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) within the Job have an `activeDeadlineSeconds` field. Ensure that you set this field at the proper level.
|
||||
-->
|
||||
|
||||
请注意，Job 对象中的 Job 规范和 [Pod 模板规范](/docs/concepts/workloads/pods/init-containers/#detailed-behavior)都有 `activeDeadlineSeconds` 字段。确保将此字段设置在适当的层级。
|
||||
|
||||
<!--
|
||||
## Clean Up Finished Jobs Automatically
|
||||
-->
|
||||
|
||||
## 自动清理已完成的 Job
|
||||
|
||||
<!--
|
||||
Finished Jobs are usually no longer needed in the system. Keeping them around in
|
||||
the system will put pressure on the API server. If the Jobs are managed directly
|
||||
by a higher level controller, such as
|
||||
[CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be
|
||||
cleaned up by CronJobs based on the specified capacity-based cleanup policy.
|
||||
-->
|
||||
|
||||
系统中已完成的 Job 通常不再需要。将它们保留在系统中将会给 API 服务器带来压力。如果 Job 由更高级别的控制器管理，比如 [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/)，则 Job 可以由 CronJobs 基于指定的基于容量的清理策略来进行清除。
|
||||
|
||||
<!--
|
||||
### TTL Mechanism for Finished Jobs
|
||||
-->
|
||||
|
||||
### 已完成 Job 的 TTL 机制
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
<!--
|
||||
Another way to clean up finished Jobs (either `Complete` or `Failed`)
|
||||
automatically is to use a TTL mechanism provided by a
|
||||
[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
|
||||
finished resources, by specifying the `.spec.ttlSecondsAfterFinished` field of
|
||||
the Job.
|
||||
-->
|
||||
|
||||
清理已完成 Job（`Complete` 或 `Failed`）的另一个方式是通过使用 [TTL 控制器](/docs/concepts/workloads/controllers/ttlafterfinished/)提供的 TTL 机制，TTL 通过指定 Job 的 `.spec.ttlSecondsAfterFinished` 字段来清理已完成资源。
|
||||
|
||||
<!--
|
||||
When the TTL controller cleans up the Job, it will delete the Job cascadingly,
|
||||
i.e. delete its dependent objects, such as Pods, together with the Job. Note
|
||||
that when the Job is deleted, its lifecycle guarantees, such as finalizers, will
|
||||
be honored.
|
||||
-->
|
||||
|
||||
当 TTL 控制器清理 Job 时，它将级联删除 Job，即删除它的依赖对象，比如 pod 将和 Job 一起被删除。请注意，当 Job 被删除后，它的生命周期保证，如终结者，将被触发。
|
||||
|
||||
<!--
|
||||
For example:
|
||||
-->
|
||||
|
||||
例如：
|
||||
|
||||
```yaml
|
||||
apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: pi-with-ttl
|
||||
spec:
|
||||
ttlSecondsAfterFinished: 100
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: pi
|
||||
image: perl
|
||||
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
restartPolicy: Never
|
||||
```
|
||||
|
||||
<!--
|
||||
The Job `pi-with-ttl` will be eligible to be automatically deleted, `100`
|
||||
seconds after it finishes.
|
||||
-->
|
||||
|
||||
`pi-with-ttl` Job 在完成后 100 秒就会自动删除掉。
|
||||
|
||||
<!--
|
||||
If the field is set to `0`, the Job will be eligible to be automatically deleted
|
||||
immediately after it finishes. If the field is unset, this Job won't be cleaned
|
||||
up by the TTL controller after it finishes.
|
||||
-->
|
||||
|
||||
如果该字段设为为 `0`，那么 Job 将在完成后立即被自动删除掉。如果该字段未设置，则 Job 在完成后将不会被 TTL 控制器清理掉。
|
||||
|
||||
<!--
|
||||
Note that this TTL mechanism is alpha, with feature gate `TTLAfterFinished`. For
|
||||
more information, see the documentation for
|
||||
[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
|
||||
finished resources.
|
||||
-->
|
||||
|
||||
请注意，此 TTL 机制处于 alpha 阶段，由 `TTLAfterFinished` 功能门控制是否启动。有关详细信息，请参阅 [TTL 控制器](/docs/concepts/workloads/controllers/ttlafterfinished/)中关于已完成资源的处理。
|
||||
|
||||
<!--
|
||||
## Job Patterns
|
||||
-->
|
||||
|
||||
## Job 模式
|
||||
|
||||
<!--
|
||||
The Job object can be used to support reliable parallel execution of Pods. The Job object is not
|
||||
designed to support closely-communicating parallel processes, as commonly found in scientific
|
||||
computing. It does support parallel processing of a set of independent but related *work items*.
|
||||
These might be emails to be sent, frames to be rendered, files to be transcoded, ranges of keys in a
|
||||
NoSQL database to scan, and so on.
|
||||
-->
|
||||
|
||||
Job 对象可用于支持 pod 的可靠并行执行。Job 对象并非设计为支持紧密通信的并行过程（常见于科学计算领域）。它被用于支持一组独立但相关的*工作项*的并行处理。这些可能是要发送的电子邮件，要渲染的帧，要编码转换的文件，要扫描的 NoSQL 数据库中一段范围内的键等等。
|
||||
|
||||
<!--
|
||||
In a complex system, there may be multiple different sets of work items. Here we are just
|
||||
considering one set of work items that the user wants to manage together — a *batch job*.
|
||||
-->
|
||||
|
||||
在复杂的系统中，可能会有多个不同的工作项集。这里我们只考虑用户想要一起管理一组工作项 — *批处理任务*。
|
||||
|
||||
<!--
|
||||
There are several different patterns for parallel computation, each with strengths and weaknesses.
|
||||
The tradeoffs are:
|
||||
-->
|
||||
|
||||
并行计算有几种不同的模式，每种都有各自的优缺点。权衡点如下：
|
||||
|
||||
<!--
|
||||
- One Job object for each work item, vs. a single Job object for all work items. The latter is
|
||||
better for large numbers of work items. The former creates some overhead for the user and for the
|
||||
system to manage large numbers of Job objects.
|
||||
- Number of pods created equals number of work items, vs. each Pod can process multiple work items.
|
||||
The former typically requires less modification to existing code and containers. The latter
|
||||
is better for large numbers of work items, for similar reasons to the previous bullet.
|
||||
- Several approaches use a work queue. This requires running a queue service,
|
||||
and modifications to the existing program or container to make it use the work queue.
|
||||
Other approaches are easier to adapt to an existing containerised application.
|
||||
-->
|
||||
|
||||
- 一个 Job 对象处理一个工作项，还是一个 Job 对象处理所有的工作项。后者适用于有大量工作项的场景。前者在管理大量 Job 对象时会对用户和系统带来一些开销。
|
||||
- 创建和工作项数量一样多的 pod，还是一个 pod 处理多个工作项。前者通常对现有代码和容器进行较少的修改。后者更适用于处理大量工作项（理由和前一条的相似）。
|
||||
- 几种方法使用工作队列。这需要运行一个队列服务，并对现有的程序和容器进行修改以使其能够使用工作队列。其他方法更容易适应现有的容器化应用程序。
|
||||
|
||||
|
||||
<!--
|
||||
The tradeoffs are summarized here, with columns 2 to 4 corresponding to the above tradeoffs.
|
||||
The pattern names are also links to examples and more detailed description.
|
||||
-->
|
||||
|
||||
权衡总结如下表，第 2 至 4 列对应上面的权衡点。模式名称也是样例和详细描述的链接。
|
||||
|
||||
<!--
|
||||
| Pattern | Single Job object | Fewer pods than work items? | Use app unmodified? | Works in Kube 1.1? |
|
||||
| -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
|
||||
| [Job Template Expansion](/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ |
|
||||
| [Queue with Pod Per Work Item](/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | sometimes | ✓ |
|
||||
| [Queue with Variable Pod Count](/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ |
|
||||
| Single Job with Static Work Assignment | ✓ | | ✓ |
|
||||
|
|
||||
-->
|
||||
|
||||
| 模式 | 单个 Job 对象 | 比工作项更少的 pod？ | 使用未修改的 app？ | Kube 1.1 中生效？ |
|
||||
| -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:|
|
||||
| [Job 模板扩展](/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ |
|
||||
| [一个项对应一个 pod 的队列](/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 有时 | ✓ |
|
||||
| [具有可变 pod 数量的队列](/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ |
|
||||
| 具有静态工作分配的单个 Job | ✓ | | ✓ | |
|
||||
|
||||
<!--
|
||||
When you specify completions with `.spec.completions`, each Pod created by the Job controller
|
||||
has an identical [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). This means that
|
||||
all pods for a task will have the same command line and the same
|
||||
image, the same volumes, and (almost) the same environment variables. These patterns
|
||||
are different ways to arrange for pods to work on different things.
|
||||
-->
|
||||
|
||||
当使用 `.spec.completions` 指定完成数时，由 Job 控制器创建的每个 pod 都有一个相同的 [`规范`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。这意味着一个任务的所有 pod 将有相同的命令行和镜像，相同的卷以及（几乎）相同的环境变量。这些模式通过不同的方式安排 pod 去处理不同的任务。
|
||||
|
||||
<!--
|
||||
This table shows the required settings for `.spec.parallelism` and `.spec.completions` for each of the patterns.
|
||||
Here, `W` is the number of work items.
|
||||
-->
|
||||
|
||||
下表列出了每种模式下对 `.spec.parallelism` 和 `.spec.completions` 需要做的设置。
|
||||
|
||||
<!--
|
||||
| Pattern | `.spec.completions` | `.spec.parallelism` |
|
||||
| -------------------------------------------------------------------- |:-------------------:|:--------------------:|
|
||||
| [Job Template Expansion](/docs/tasks/job/parallel-processing-expansion/) | 1 | should be 1 |
|
||||
| [Queue with Pod Per Work Item](/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | any |
|
||||
| [Queue with Variable Pod Count](/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | any |
|
||||
| Single Job with Static Work Assignment | W | any |
|
||||
-->
|
||||
|
||||
|
||||
| 模式 | `.spec.completions` | `.spec.parallelism` |
|
||||
| -------------------------------------------------------------------- |:-------------------:|:--------------------:|
|
||||
| [Job 模板扩展](/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 |
|
||||
| [一个项对应一个 pod 的队列](/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意 |
|
||||
| [具有可变 pod 数量的队列](/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意 |
|
||||
| 具有静态工作分配的单个 Job | W | 任意 |
|
||||
|
||||
<!--
|
||||
## Advanced Usage
|
||||
-->
|
||||
|
||||
## 高级用法
|
||||
|
||||
<!--
|
||||
### Specifying your own pod selector
|
||||
-->
|
||||
|
||||
### 指定你的 pod 选择器
|
||||
|
||||
<!--
|
||||
Normally, when you create a Job object, you do not specify `.spec.selector`.
|
||||
The system defaulting logic adds this field when the Job is created.
|
||||
It picks a selector value that will not overlap with any other jobs.
|
||||
-->
|
||||
|
||||
通常，在创建 Job 对象时，不用指定 `.spec.selector`。系统的默认逻辑会在创建 Job 时添加这个字段。它会选择一个不会和其他 pod 重叠的选择器。
|
||||
|
||||
<!--
|
||||
However, in some cases, you might need to override this automatically set selector.
|
||||
To do this, you can specify the `.spec.selector` of the Job.
|
||||
-->
|
||||
|
||||
但是，在某些情况下，你可能需要去覆盖默认设置的选择器。为此，你需要指定 Job 的 `.spec.selector`。
|
||||
|
||||
<!--
|
||||
Be very careful when doing this. If you specify a label selector which is not
|
||||
unique to the pods of that Job, and which matches unrelated Pods, then pods of the unrelated
|
||||
job may be deleted, or this Job may count other Pods as completing it, or one or both
|
||||
Jobs may refuse to create Pods or run to completion. If a non-unique selector is
|
||||
chosen, then other controllers (e.g. ReplicationController) and their Pods may behave
|
||||
in unpredictable ways too. Kubernetes will not stop you from making a mistake when
|
||||
specifying `.spec.selector`.
|
||||
-->
|
||||
|
||||
当设置时需要特别小心。如果你指定的标签选择器不是 Job 的 pod 所独有的，并且匹配到了不相关的 pod，那么不相关 Job 的 pod 可能会被删除，或此 Job 可能将其他 pod 统计为已完成，或者其中一个或两个 Job 可能拒绝创建 pod 或运行完成。如果一个选择了非唯一的选择器，则其他的控制器（比如 ReplicationController）和它的 pod 的行为也将是不可预测的。当指定了 `.spec.selector`，Kubernetes将不会阻止你产生错误。
|
||||
|
||||
<!--
|
||||
Here is an example of a case when you might want to use this feature.
|
||||
-->
|
||||
|
||||
下面的例子描述了你想要使用该功能的场景。
|
||||
|
||||
<!--
|
||||
Say Job `old` is already running. You want existing Pods
|
||||
to keep running, but you want the rest of the Pods it creates
|
||||
to use a different pod template and for the Job to have a new name.
|
||||
You cannot update the Job because these fields are not updatable.
|
||||
Therefore, you delete Job `old` but _leave its pods
|
||||
running_, using `kubectl delete jobs/old --cascade=false`.
|
||||
Before deleting it, you make a note of what selector it uses:
|
||||
-->
|
||||
|
||||
假设 `old` Job 已经在运行了。你想要运行中的 pod 保持运行，但是你想 Job 创建的其他 pod 使用不同的 pod 模板，并使 Job 具有一个新的名称。你不能更新 Job 对象，因为这些字段是不可更新的。因此，你需要删除 `old` 但是_让它的 pod 运行_，可以使用 `kubectl delete jobs/old --cascade=false` 命令。在删除之前，你需要记下它所使用的选择器：
|
||||
|
||||
```
|
||||
kubectl get job old -o yaml
|
||||
```
|
||||
```
|
||||
kind: Job
|
||||
metadata:
|
||||
name: old
|
||||
...
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
Then you create a new Job with name `new` and you explicitly specify the same selector.
|
||||
Since the existing Pods have label `controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`,
|
||||
they are controlled by Job `new` as well.
|
||||
-->
|
||||
|
||||
然后使用新名称 `new` 创建一个新的 Job ，并且显示指定相同的选择器。由于现有的 pod 具有 `controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002` 标签，它们也受 `new` Job 的控制。
|
||||
|
||||
<!--
|
||||
You need to specify `manualSelector: true` in the new Job since you are not using
|
||||
the selector that the system normally generates for you automatically.
|
||||
-->
|
||||
|
||||
由于你不再使用系统通常为你自动生成的选择器，你需要在新的 Job 中指定 `manualSelector: true`。
|
||||
|
||||
```
|
||||
kind: Job
|
||||
metadata:
|
||||
name: new
|
||||
...
|
||||
spec:
|
||||
manualSelector: true
|
||||
selector:
|
||||
matchLabels:
|
||||
controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010af00002`. Setting
|
||||
`manualSelector: true` tells the system to that you know what you are doing and to allow this
|
||||
mismatch.
|
||||
-->
|
||||
|
||||
新的 Job 本身将具有一个与 `a8f3d00d-c6d2-11e5-9f87-42010af00002` 不通的 uid。设置 `manualSelector: true` 来告诉系统你知道自己在做什么，并使其允许这种不匹配。
|
||||
|
||||
<!--
|
||||
## Alternatives
|
||||
-->
|
||||
|
||||
## 备选方案
|
||||
|
||||
<!--
|
||||
### Bare Pods
|
||||
-->
|
||||
|
||||
### 裸 pod
|
||||
|
||||
<!--
|
||||
When the node that a Pod is running on reboots or fails, the pod is terminated
|
||||
and will not be restarted. However, a Job will create new Pods to replace terminated ones.
|
||||
For this reason, we recommend that you use a Job rather than a bare Pod, even if your application
|
||||
requires only a single Pod.
|
||||
-->
|
||||
|
||||
当 pod 所在节点重启或发生故障时，pod 将终止并且不会重启。然后，Job 将创建新的 pod 替换终止的 pod。因此，即使你的应用仅需要一个 pod，我们还是推荐使用 Job 而不是裸 pod。
|
||||
|
||||
<!--
|
||||
### Replication Controller
|
||||
-->
|
||||
|
||||
### 副本控制器
|
||||
|
||||
<!--
|
||||
Jobs are complementary to [Replication Controllers](/docs/user-guide/replication-controller).
|
||||
A Replication Controller manages Pods which are not expected to terminate (e.g. web servers), and a Job
|
||||
manages Pods that are expected to terminate (e.g. batch tasks).
|
||||
-->
|
||||
|
||||
Job 是[副本控制器](/docs/user-guide/replication-controller)的补充。副本控制器管理预期不会终止的 pod（比如 web 服务器），而 Job 管理预期将会终止的 pod（比如批处理任务）。
|
||||
|
||||
<!--
|
||||
As discussed in [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` is *only* appropriate
|
||||
for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
|
||||
(Note: If `RestartPolicy` is not set, the default value is `Always`.)
|
||||
-->
|
||||
|
||||
正如在 [Pod 生命周期](/docs/concepts/workloads/pods/pod-lifecycle/)中所讨论的，`Job` *仅*适用于具有 `RestartPolicy` 值为 `OnFailure` 或 `Never` 的 pod。（注意：如果 `RestartPolicy` 未指定，默认值为 `Always`。）
|
||||
|
||||
<!--
|
||||
### Single Job starts Controller Pod
|
||||
-->
|
||||
|
||||
### 单 Job 启动控制 pod
|
||||
|
||||
<!--
|
||||
Another pattern is for a single Job to create a Pod which then creates other Pods, acting as a sort
|
||||
of custom controller for those Pods. This allows the most flexibility, but may be somewhat
|
||||
complicated to get started with and offers less integration with Kubernetes.
|
||||
-->
|
||||
|
||||
单个 Job 的另一种模式是创建一个创建其他 pod 的 pod，充当这些 pod 的一种自定义控制器。这提供了更大的灵活性，但是入门起来可能有点复杂，并且与 Kubernetes 的集成较少。
|
||||
|
||||
<!--
|
||||
One example of this pattern would be a Job which starts a Pod which runs a script that in turn
|
||||
starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)), runs a spark
|
||||
driver, and then cleans up.
|
||||
-->
|
||||
|
||||
这种模式的一个样例是：一个 Job 启动一个 pod 来运行一个脚本，该脚本依次启动 Spark 主控制器（参阅 [spark 例子](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)），并运行 spark 驱动，然后进行清理。
|
||||
|
||||
<!--
|
||||
An advantage of this approach is that the overall process gets the completion guarantee of a Job
|
||||
object, but complete control over what Pods are created and how work is assigned to them.
|
||||
-->
|
||||
|
||||
这种方法的优点是整个过程可以获取 Job 对象的完成保证，不是完全控制 pod 的创建以及如何将工作分配给 pod。
|
||||
|
||||
## Cron Jobs {#cron-jobs}
|
||||
|
||||
<!--
|
||||
You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`.
|
||||
-->
|
||||
|
||||
你可以使用 [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) 来创建一个会在指定的时间/日期执行的 Job，类似于 Unix 工具 `cron`。
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,409 +0,0 @@
|
||||
---
|
||||
title: 安装 kubeadm
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
---
|
||||
title: Installing kubeadm
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
<img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">This page shows how to install the `kubeadm` toolbox.
|
||||
For information how to create a cluster with kubeadm once you have performed this installation process,
|
||||
see the [Using kubeadm to Create a Cluster](/docs/setup/independent/create-cluster-kubeadm/) page.
|
||||
-->
|
||||
<img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">本文会告诉您如何安装 `kubeadm` 工具。完成本文提到的安装步骤后，您可以阅读 [使用 kubeadm 来创建集群](/docs/setup/independent/create-cluster-kubeadm/) 了解如何使用 kubeadm 来创建集群。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
<!--
|
||||
* One or more machines running one of:
|
||||
- Ubuntu 16.04+
|
||||
- Debian 9
|
||||
- CentOS 7
|
||||
- RHEL 7
|
||||
- Fedora 25/26 (best-effort)
|
||||
- HypriotOS v1.0.1+
|
||||
- Container Linux (tested with 1800.6.0)
|
||||
* 2 GB or more of RAM per machine (any less will leave little room for your apps)
|
||||
* 2 CPUs or more
|
||||
* Full network connectivity between all machines in the cluster (public or private network is fine)
|
||||
* Unique hostname, MAC address, and product_uuid for every node. See [here](#verify-the-mac-address-and-product-uuid-are-unique-for-every-node) for more details.
|
||||
* Certain ports are open on your machines. See [here](#check-required-ports) for more details.
|
||||
* Swap disabled. You **MUST** disable swap in order for the kubelet to work properly.
|
||||
-->
|
||||
* 一台或多台运行着下列系统的机器:
|
||||
- Ubuntu 16.04+
|
||||
- Debian 9
|
||||
- CentOS 7
|
||||
- RHEL 7
|
||||
- Fedora 25/26 (尽力服务)
|
||||
- HypriotOS v1.0.1+
|
||||
- Container Linux (针对1800.6.0 版本测试)
|
||||
* 每台机器 2 GB 或更多的 RAM (如果少于这个数字将会影响您应用的运行内存)
|
||||
* 2 CPU 核心或更多
|
||||
* 集群中的所有机器的网络彼此均能相互连接(公网和内网都可以)
|
||||
* 节点之中不可以有重复的主机名，MAC 地址，product_uuid。更多详细信息请参见[这里](#verify-the-mac-address-and-product-uuid-are-unique-for-every-node) 。
|
||||
* 开启主机上的一些特定端口. 更多详细信息请参见[这里](#check-required-ports)。
|
||||
* 禁用 Swap 交换分区。为了保证 kubelet 正确运行，您 **必须** 禁用交换分区。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Verify the MAC address and product_uuid are unique for every node
|
||||
-->
|
||||
## 确保每个节点上 MAC 地址和 product_uuid 的唯一性。
|
||||
|
||||
<!--
|
||||
* You can get the MAC address of the network interfaces using the command `ip link` or `ifconfig -a`
|
||||
* The product_uuid can be checked by using the command `sudo cat /sys/class/dmi/id/product_uuid`
|
||||
-->
|
||||
* 您可以使用下列命令获取网络接口的 MAC 地址：`ip link` 或是 `ifconfig -a`
|
||||
* 下列命令可以用来获取 product_uuid `sudo cat /sys/class/dmi/id/product_uuid`
|
||||
|
||||
<!--
|
||||
It is very likely that hardware devices will have unique addresses, although some virtual machines may have
|
||||
identical values. Kubernetes uses these values to uniquely identify the nodes in the cluster.
|
||||
If these values are not unique to each node, the installation process
|
||||
may [fail](https://github.com/kubernetes/kubeadm/issues/31).
|
||||
-->
|
||||
一般来讲，硬件设备会拥有独一无二的地址，但是有些虚拟机可能会雷同。Kubernetes 使用这些值来唯一确定集群中的节点。如果这些值在集群中不唯一，可能会导致安装[失败](https://github.com/kubernetes/kubeadm/issues/31)。
|
||||
|
||||
<!--
|
||||
## Check network adapters
|
||||
-->
|
||||
|
||||
## 检查网络适配器
|
||||
|
||||
<!--
|
||||
If you have more than one network adapter, and your Kubernetes components are not reachable on the default
|
||||
route, we recommend you add IP route(s) so Kubernetes cluster addresses go via the appropriate adapter.
|
||||
-->
|
||||
|
||||
如果您有一个以上的网络适配器，同时您的 Kubernetes 组件通过默认路由不可达，我们建议您预先添加 IP 路由规则，这样 Kubernetes 集群就可以通过对应的适配器完成连接。
|
||||
|
||||
<!--
|
||||
## Check required ports
|
||||
-->
|
||||
|
||||
## 检查所需端口
|
||||
|
||||
<!--
|
||||
### Master node(s)
|
||||
| Protocol | Direction | Port Range | Purpose | Used By |
|
||||
-->
|
||||
|
||||
### Master 节点
|
||||
| 规则 | 方向 | 端口范围 | 作用 | 使用者 |
|
||||
|----------|-----------|------------|-------------------------|---------------------------|
|
||||
| TCP | Inbound | 6443* | Kubernetes API server | All |
|
||||
| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd |
|
||||
| TCP | Inbound | 10250 | Kubelet API | Self, Control plane |
|
||||
| TCP | Inbound | 10251 | kube-scheduler | Self |
|
||||
| TCP | Inbound | 10252 | kube-controller-manager | Self |
|
||||
<!--
|
||||
### Worker node(s)
|
||||
| Protocol | Direction | Port Range | Purpose | Used By |
|
||||
-->
|
||||
|
||||
### Worker 节点
|
||||
|
||||
| 规则 | 方向 | 端口范围 | 作用 | 使用者 |
|
||||
|----------|-----------|-------------|-----------------------|-------------------------|
|
||||
| TCP | Inbound | 10250 | Kubelet API | Self, Control plane |
|
||||
| TCP | Inbound | 30000-32767 | NodePort Services** | All |
|
||||
<!--
|
||||
** Default port range for [NodePort Services](/docs/concepts/services-networking/service/).
|
||||
-->
|
||||
|
||||
** [NodePort 服务](/docs/concepts/services-networking/service/) 的默认端口范围。
|
||||
|
||||
<!--
|
||||
Any port numbers marked with * are overridable, so you will need to ensure any
|
||||
custom ports you provide are also open.
|
||||
-->
|
||||
任何使用 * 标记的端口号都有可能被覆盖，所以您需要保证您的自定义端口的状态是开放的。
|
||||
|
||||
<!--
|
||||
Although etcd ports are included in master nodes, you can also host your own
|
||||
etcd cluster externally or on custom ports.
|
||||
-->
|
||||
虽然主节点已经包含了 etcd 的端口，您也可以使用自定义的外部 etcd 集群，或是指定自定义端口。
|
||||
<!--
|
||||
The pod network plugin you use (see below) may also require certain ports to be
|
||||
open. Since this differs with each pod network plugin, please see the
|
||||
documentation for the plugins about what port(s) those need.
|
||||
-->
|
||||
您使用的 pod 网络插件 (见下) 也可能需要某些特定端口开启。由于各个 pod 网络插件都有所不同，请参阅他们各自文档中对端口的要求。
|
||||
|
||||
<!-- ## Installing runtime -->
|
||||
## 安装 runtime
|
||||
|
||||
<!--
|
||||
Since v1.6.0, Kubernetes has enabled the use of CRI, Container Runtime Interface, by default.
|
||||
The container runtime used by default is Docker, which is enabled through the built-in
|
||||
`dockershim` CRI implementation inside of the `kubelet`.
|
||||
-->
|
||||
从 v1.6.0 起，Kubernetes 开始允许使用 CRI，容器运行时接口。默认的容器运行时是 Docker，这是由 `kubelet` 内置的 CRI 实现 `dockershim` 开启的。
|
||||
|
||||
<!--
|
||||
Other CRI-based runtimes include:
|
||||
|
||||
- [containerd](https://github.com/containerd/cri) (CRI plugin built into containerd)
|
||||
- [cri-o](https://cri-o.io/)
|
||||
- [frakti](https://github.com/kubernetes/frakti)
|
||||
- [rkt](https://github.com/kubernetes-incubator/rktlet)
|
||||
-->
|
||||
其他的容器运行时有：
|
||||
|
||||
- [containerd](https://github.com/containerd/cri) (containerd 的内置 CRI 插件)
|
||||
- [cri-o](https://cri-o.io/)
|
||||
- [frakti](https://github.com/kubernetes/frakti)
|
||||
- [rkt](https://github.com/kubernetes-incubator/rktlet)
|
||||
|
||||
<!--
|
||||
Refer to the [CRI installation instructions](/docs/setup/cri) for more information.
|
||||
-->
|
||||
参考 [CRI 安装指南](/docs/setup/cri) 获取更多信息.
|
||||
|
||||
<!--
|
||||
## Installing kubeadm, kubelet and kubectl
|
||||
-->
|
||||
## 安装 kubeadm, kubelet 和 kubectl
|
||||
|
||||
<!--
|
||||
You will install these packages on all of your machines:
|
||||
|
||||
* `kubeadm`: the command to bootstrap the cluster.
|
||||
|
||||
* `kubelet`: the component that runs on all of the machines in your cluster
|
||||
and does things like starting pods and containers.
|
||||
|
||||
* `kubectl`: the command line util to talk to your cluster.
|
||||
-->
|
||||
您需要在每台机器上都安装以下的软件包：
|
||||
|
||||
* `kubeadm`: 用来初始化集群的指令。
|
||||
|
||||
* `kubelet`: 在集群中的每个节点上用来启动 pod 和 container 等。
|
||||
|
||||
* `kubectl`: 用来与集群通信的命令行工具。
|
||||
|
||||
<!--
|
||||
kubeadm **will not** install or manage `kubelet` or `kubectl` for you, so you will
|
||||
need to ensure they match the version of the Kubernetes control plane you want
|
||||
kubeadm to install for you. If you do not, there is a risk of a version skew occurring that
|
||||
can lead to unexpected, buggy behaviour. However, _one_ minor version skew between the
|
||||
kubelet and the control plane is supported, but the kubelet version may never exceed the API
|
||||
server version. For example, kubelets running 1.7.0 should be fully compatible with a 1.8.0 API server,
|
||||
but not vice versa.
|
||||
-->
|
||||
kubeadm **不能** 帮您安装或管理 `kubelet` 或 `kubectl` ，所以您得保证他们满足通过 kubeadm 安装的 Kubernetes 控制层对版本的要求。如果版本没有满足要求，就有可能导致一些难以想到的错误或问题。然而控制层与 kubelet 间的 _小版本号_ 不一致无伤大雅，不过请记住 kubelet 的版本不可以超过 API server 的版本。例如 1.8.0 的 API server 可以适配 1.7.0 的 kubelet，反之就不行了。
|
||||
|
||||
<!--
|
||||
{{< warning >}}
|
||||
These instructions exclude all Kubernetes packages from any system upgrades.
|
||||
This is because kubeadm and Kubernetes require
|
||||
[special attention to upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/).
|
||||
{{</ warning >}}
|
||||
-->
|
||||
{{< warning >}}
|
||||
这些指南不包括所有系统升级时使用的 Kubernetes 程序包。这是因为 kubeadm 和 Kubernetes 需要 [升级时的特别注意事项](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/)。
|
||||
{{</ warning >}}
|
||||
|
||||
<!--
|
||||
For more information on version skews, please read our
|
||||
[version skew policy](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy).
|
||||
-->
|
||||
|
||||
更多关于版本偏差的信息，请参阅 [版本偏差政策](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy)。
|
||||
|
||||
{{< tabs name="k8s_install" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
```bash
|
||||
apt-get update && apt-get install -y apt-transport-https curl
|
||||
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
|
||||
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
|
||||
deb https://apt.kubernetes.io/ kubernetes-xenial main
|
||||
EOF
|
||||
apt-get update
|
||||
apt-get install -y kubelet kubeadm kubectl
|
||||
apt-mark hold kubelet kubeadm kubectl
|
||||
```
|
||||
|
||||
<!--
|
||||
# Set SELinux in permissive mode (effectively disabling it)
|
||||
-->
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="CentOS, RHEL or Fedora" %}}
|
||||
```bash
|
||||
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
|
||||
[kubernetes]
|
||||
name=Kubernetes
|
||||
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
repo_gpgcheck=1
|
||||
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
|
||||
exclude=kube*
|
||||
EOF
|
||||
|
||||
# 将 SELinux 设置为 permissive 模式(将其禁用)
|
||||
setenforce 0
|
||||
sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
|
||||
|
||||
yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
|
||||
|
||||
systemctl enable kubelet && systemctl start kubelet
|
||||
```
|
||||
|
||||
<!-- **Note:** -->
|
||||
**请注意：**
|
||||
|
||||
<!--
|
||||
- Setting SELinux in permissive mode by running `setenforce 0` and `sed ...` effectively disables it.
|
||||
This is required to allow containers to access the host filesystem, which is needed by pod networks for example.
|
||||
You have to do this until SELinux support is improved in the kubelet.
|
||||
- Some users on RHEL/CentOS 7 have reported issues with traffic being routed incorrectly due to iptables being bypassed. You should ensure
|
||||
`net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g.
|
||||
-->
|
||||
- 通过命令 `setenforce 0` 和 `sed ...` 可以将 SELinux 设置为 permissive 模式(将其禁用)。
|
||||
只有执行这一操作之后，容器才能访问宿主的文件系统，进而能够正常使用 Pod 网络。您必须这么做，直到 kubelet 做出升级支持 SELinux 为止。
|
||||
- 一些 RHEL/CentOS 7 的用户曾经遇到过：由于 iptables 被绕过导致网络请求被错误的路由。您得保证
|
||||
在您的 `sysctl` 配置中 `net.bridge.bridge-nf-call-iptables` 被设为1。
|
||||
|
||||
```bash
|
||||
cat <<EOF > /etc/sysctl.d/k8s.conf
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
EOF
|
||||
sysctl --system
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Container Linux" %}}
|
||||
<!--
|
||||
Install CNI plugins (required for most pod network):
|
||||
-->
|
||||
安装 CNI 插件（大多数 Pod 网络都需要）：
|
||||
|
||||
```bash
|
||||
CNI_VERSION="v0.6.0"
|
||||
mkdir -p /opt/cni/bin
|
||||
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz
|
||||
```
|
||||
|
||||
<!--
|
||||
Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI))
|
||||
-->
|
||||
安装 crictl (kubeadm / Kubelet 的容器运行时接口 (CRI) 要求)
|
||||
|
||||
```bash
|
||||
CRICTL_VERSION="v1.11.1"
|
||||
mkdir -p /opt/bin
|
||||
curl -L "https://github.com/kubernetes-incubator/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz
|
||||
```
|
||||
|
||||
<!--
|
||||
Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service: -->
|
||||
|
||||
安装 `kubeadm`, `kubelet`, `kubectl` 并且添加一个 `kubelet` systemd 服务:
|
||||
|
||||
```bash
|
||||
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
|
||||
|
||||
mkdir -p /opt/bin
|
||||
cd /opt/bin
|
||||
curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
|
||||
chmod +x {kubeadm,kubelet,kubectl}
|
||||
|
||||
curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service
|
||||
mkdir -p /etc/systemd/system/kubelet.service.d
|
||||
curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/10-kubeadm.conf" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
|
||||
```
|
||||
|
||||
<!--
|
||||
Enable and start `kubelet`:
|
||||
-->
|
||||
启用并启动 `kubelet`:
|
||||
|
||||
```bash
|
||||
systemctl enable kubelet && systemctl start kubelet
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
The kubelet is now restarting every few seconds, as it waits in a crashloop for
|
||||
kubeadm to tell it what to do.
|
||||
-->
|
||||
kubelet 现在每隔几秒就会重启，因为它陷入了一个等待 kubeadm 指令的死循环。
|
||||
|
||||
<!--
|
||||
## Configure cgroup driver used by kubelet on Master Node
|
||||
-->
|
||||
## 在 Master 节点上配置 kubelet 所需的 cgroup 驱动
|
||||
|
||||
<!--
|
||||
When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet
|
||||
and set it in the `/var/lib/kubelet/kubeadm-flags.env` file during runtime.
|
||||
-->
|
||||
使用 Docker 时，kubeadm 会自动为其检测 cgroup 驱动在运行时对 `/var/lib/kubelet/kubeadm-flags.env` 文件进行配置。
|
||||
<!--
|
||||
If you are using a different CRI, you have to modify the file
|
||||
`/etc/default/kubelet` with your `cgroup-driver` value, like so:
|
||||
-->
|
||||
如果您使用了不同的 CRI， 您得把 `/etc/default/kubelet` 文件中的 `cgroup-driver` 位置改为对应的值，像这样：
|
||||
|
||||
```bash
|
||||
KUBELET_EXTRA_ARGS=--cgroup-driver=<value>
|
||||
```
|
||||
|
||||
<!--
|
||||
This file will be used by `kubeadm init` and `kubeadm join` to source extra
|
||||
user defined arguments for the kubelet.
|
||||
-->
|
||||
这个文件将会被 `kubeadm init` 和 `kubeadm join` 用于为 kubelet 获取 额外的用户参数。
|
||||
|
||||
<!--
|
||||
Please mind, that you **only** have to do that if the cgroup driver of your CRI
|
||||
is not `cgroupfs`, because that is the default value in the kubelet already.
|
||||
-->
|
||||
请注意，您**只**需要在您的 cgroup driver 不是 `cgroupfs` 时这么做，因为 `cgroupfs` 已经是 kubelet 的默认值了。
|
||||
|
||||
<!--
|
||||
Restarting the kubelet is required:
|
||||
-->
|
||||
需要重启 kubelet：
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload
|
||||
systemctl restart kubelet
|
||||
```
|
||||
|
||||
<!--
|
||||
## Troubleshooting
|
||||
-->
|
||||
## 查错
|
||||
|
||||
<!--
|
||||
If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/independent/troubleshooting-kubeadm/).
|
||||
-->
|
||||
如果您在使用 kubeadm 时候遇到问题，请查看我们的[疑难解答文档](/docs/setup/independent/troubleshooting-kubeadm/).
|
||||
{{% capture whatsnext %}}
|
||||
<!--
|
||||
* [Using kubeadm to Create a Cluster](/docs/setup/independent/create-cluster-kubeadm/)
|
||||
-->
|
||||
* [使用 kubeadm 来创建集群](/docs/setup/independent/create-cluster-kubeadm/)
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,248 +0,0 @@
|
||||
---
|
||||
title: 安装 Minikube
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
card:
|
||||
name: tasks
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!-- This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer. -->
|
||||
该页面向您展示了如何安装 [Minikube](/docs/tutorials/hello-minikube)，Minikube 是一个安装在您电脑虚拟机上的单节点 Kubernetes 集群。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< tabs name="minikube_before_you_begin" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
<!-- To check if virtualization is supported on Linux, run the following command and verify that the output is non-empty: -->
|
||||
检查 Linux 上是否支持虚拟化，运行如下命令并确保输出不为空：
|
||||
```
|
||||
grep -E --color 'vmx|svm' /proc/cpuinfo
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="macOS" %}}
|
||||
<!-- To check if virtualization is supported on macOS, run the following command on your terminal. -->
|
||||
检查 macOS 上是否支持虚拟化，运行如下命令并确保输出不为空：
|
||||
```
|
||||
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
|
||||
```
|
||||
<!-- If you see `VMX` in the output (should be colored), the VT-x feature is enabled in your machine. -->
|
||||
如果输出内容为有颜色的 `VMX`，表示在您的电脑上 VT-x 功能已经开启。
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Windows" %}}
|
||||
<!-- To check if virtualization is supported on Windows 8 and above, run the following command on your Windows terminal or command prompt. -->
|
||||
检查在 Windows 8 及以上系统是否支持虚拟化，在您 Windows 终端或命令行运行如下命令：
|
||||
```
|
||||
systeminfo
|
||||
```
|
||||
<!-- If you see the following output, virtualization is supported on Windows. -->
|
||||
如果输出如下内容，表示您的 Windows 支持虚拟化。
|
||||
```
|
||||
Hyper-V Requirements: VM Monitor Mode Extensions: Yes
|
||||
Virtualization Enabled In Firmware: Yes
|
||||
Second Level Address Translation: Yes
|
||||
Data Execution Prevention Available: Yes
|
||||
```
|
||||
|
||||
<!-- If you see the following output, your system already has a Hypervisor installed and you can skip the next step. -->
|
||||
如果输出如下内容，表示您的操作系统已经安装了虚拟机管理程序，您可以跳过下一步。
|
||||
```
|
||||
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
|
||||
```
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!-- # Installing minikube -->
|
||||
# 安装 minikube
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
<!-- ### Install kubectl -->
|
||||
### 安装 kubectl
|
||||
|
||||
<!-- Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux). -->
|
||||
确保您已经安装了 kubectl。您可以按照[安装和配置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)的指引来安装 kubectl。
|
||||
|
||||
<!-- ### Install a Hypervisor -->
|
||||
### 安装虚拟机管理程序
|
||||
|
||||
<!-- If you do not already have a hypervisor installed, install one of these now: -->
|
||||
如果您没有安装虚拟机管理程序，选择如下一项进行安装：
|
||||
|
||||
<!-- • [KVM](https://www.linux-kvm.org/), which also uses QEMU -->
|
||||
• [KVM](https://www.linux-kvm.org/)，使用了 QEMU
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
{{< note >}}
|
||||
<!-- Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires [Docker](https://www.docker.com/products/docker-desktop) and a Linux environment but not a hypervisor. It is recommended to use the apt installation of docker from ([Docker](https://www.docker.com/products/docker-desktop), when using the none driver. The snap installation of docker does not work with minikube. -->
|
||||
minikube 也支持 `--vm-driver=none` 选项使 Kubernetes 组件运行在宿主机而不是虚拟机中。使用这种驱动模式需要 [Docker](https://www.docker.com/products/docker-desktop)和 Linux 环境，而不是虚拟机管理器。使用无驱动模式时，推荐从([Docker](https://www.docker.com/products/docker-desktop)使用 apt 进行安装。docker 这种快照式的安装不适用于 minikube。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- ### Install Minikube using a package -->
|
||||
### 使用安装包安装 Minikube
|
||||
|
||||
<!-- There are *experimental* packages for Minikube available; you can find Linux (AMD64) packages
|
||||
from Minikube's [releases](https://github.com/kubernetes/minikube/releases) page on GitHub. -->
|
||||
有*试验性*的 Minikube 安装包可供使用。您可以在 GitHub 上 Minikube 的 [releases](https://github.com/kubernetes/minikube/releases)页面找到Linux (AMD64)的安装包。
|
||||
|
||||
<!-- Use your Linux's distribution's package tool to install a suitable package. -->
|
||||
使用您的发布版 Linux 包工具进行安装。
|
||||
|
||||
<!-- ### Install Minikube via direct download -->
|
||||
### 通过直接下载来安装 Minikube
|
||||
|
||||
<!-- If you're not installing via a package, you can download a stand-alone
|
||||
binary and use that. -->
|
||||
如果您没有通过安装包进行安装，您可以下载一个独立的二进制版本使用。
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
<!-- Here's an easy way to add the Minikube executable to your path: -->
|
||||
如下是一种简单的方式将 Minikube 添加到您的执行路径中：
|
||||
|
||||
```shell
|
||||
sudo install minikube /usr/local/bin
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="macOS" %}}
|
||||
<!-- ### Install kubectl -->
|
||||
### 安装 kubectl
|
||||
|
||||
<!-- Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos). -->
|
||||
确保您已经安装了 kubectl。您可以通过[安装和配置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)来安装 kubectl。
|
||||
|
||||
<!-- ### Install a Hypervisor -->
|
||||
### 安装虚拟机管理器
|
||||
|
||||
<!-- If you do not already have a hypervisor installed, install one of these now: -->
|
||||
如果您没有安装虚拟机管理器，现在就选一个安装：
|
||||
|
||||
• [HyperKit](https://github.com/moby/hyperkit)
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
• [VMware Fusion](https://www.vmware.com/products/fusion)
|
||||
|
||||
<!-- ### Install Minikube -->
|
||||
### 安装Minikube
|
||||
<!-- The easiest way to install Minikube on macOS is using [Homebrew](https://brew.sh): -->
|
||||
在 macOS 上安装 Minikube 最简单的方法是使用[Homebrew](https://brew.sh)：
|
||||
|
||||
```shell
|
||||
brew cask install minikube
|
||||
```
|
||||
|
||||
<!-- You can also install it on macOS by downloading a stand-alone binary: -->
|
||||
您也可以通过下载独立二进制文件来安装在 macOS 上。
|
||||
|
||||
```shell
|
||||
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
|
||||
&& chmod +x minikube
|
||||
```
|
||||
|
||||
<!-- Here's an easy way to add the Minikube executable to your path: -->
|
||||
如下是一种简单的方式将 Minikube 添加到您的执行路径中：
|
||||
|
||||
```shell
|
||||
sudo mv minikube /usr/local/bin
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows" %}}
|
||||
<!-- ### Install kubectl -->
|
||||
安装 kubectl
|
||||
|
||||
<!-- Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows). -->
|
||||
确保您已经安装了 kubectl。您可以通过[安装和配置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)来安装 kubectl。
|
||||
|
||||
<!-- ### Install a Hypervisor -->
|
||||
### 安装虚拟机管理器
|
||||
|
||||
<!-- If you do not already have a hypervisor installed, install one of these now: -->
|
||||
如果您没有安装虚拟机管理器，现在就选一个安装：
|
||||
|
||||
• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
|
||||
|
||||
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
|
||||
|
||||
{{< note >}}
|
||||
<!-- Hyper-V can run on three versions of Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education. -->
|
||||
Hyper-V 可以运行在3种版本的 Windows 10 中：Windows 10 企业版，Windows 10 专业版，Windows 10教育版。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- ### Install Minikube using Chocolatey -->
|
||||
使用 Chocolatey 安装 Minikube
|
||||
|
||||
<!-- The easiest way to install Minikube on Windows is using [Chocolatey](https://chocolatey.org/) (run as an administrator): -->
|
||||
在 Windows 上安装 Minikube 最简单的方式是使用[Chocolatey](https://chocolatey.org/) (以管理员身份运行)：
|
||||
|
||||
```shell
|
||||
choco install minikube
|
||||
```
|
||||
|
||||
<!-- After Minikube has finished installing, close the current CLI session and restart. Minikube should have been added to your path automatically. -->
|
||||
Minikube 安装结束后，关闭命令行并重启。Minikube 应该已经添加到可执行路径中。
|
||||
|
||||
<!-- ### Install Minikube using an installer executable -->
|
||||
### 使用安装器安装 Minikube
|
||||
|
||||
<!-- To install Minikube manually on Windows using [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), download [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe) and execute the installer. -->
|
||||
手动在 Windows 上安装 Minikube 使用[Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)，下载[`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe)然后执行安装器。
|
||||
|
||||
<!-- ### Install Minikube via direct download -->
|
||||
### 直接下载安装 Minikube
|
||||
|
||||
<!-- To install Minikube manually on Windows, download [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest), rename it to `minikube.exe`, and add it to your path. -->
|
||||
在 Windows 上手动安装 Minikube，下载[`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)，重命名为`minikube.exe`，并将其添加到执行路径中。
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!-- * [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/) -->
|
||||
* [通过 Minikube 在本地运行 Kubernetes](/docs/setup/learning-environment/minikube/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
<!-- ## Cleanup local state -->
|
||||
## 清理本地状态
|
||||
|
||||
<!-- If you have previously installed minikube, and run: -->
|
||||
如果您之前安装过 Minikube，运行如下命令：
|
||||
```shell
|
||||
minikube start
|
||||
```
|
||||
|
||||
<!-- And this command returns an error: -->
|
||||
然后这条命令会返回一个错误：
|
||||
```shell
|
||||
machine does not exist
|
||||
```
|
||||
|
||||
<!-- You need to clear minikube's local state: -->
|
||||
您需要清理 Minikube 的本地状态：
|
||||
```shell
|
||||
minikube delete
|
||||
```
|
||||
@@ -1,10 +0,0 @@
|
||||
#include <tunables/global>
|
||||
|
||||
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
|
||||
#include <abstractions/base>
|
||||
|
||||
file,
|
||||
|
||||
# Deny all file writes.
|
||||
deny /** w,
|
||||
}
|
||||
@@ -1,280 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: 高级主题
|
||||
track: "USERS › APPLICATION DEVELOPER › ADVANCED"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- chenopis
|
||||
layout: docsportal
|
||||
css: /css/style_user_journeys.css
|
||||
js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
|
||||
title: Advanced Topics
|
||||
track: "USERS › APPLICATION DEVELOPER › ADVANCED"
|
||||
content_template: templates/user-journey-content
|
||||
---
|
||||
-->
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
This page assumes that you're familiar with core Kubernetes concepts, and are comfortable deploying your own apps. If not, you should review the {{< link text="Intermediate App Developer" url="/docs/user-journeys/users/application-developer/intermediate/" >}} topics first.
|
||||
-->
|
||||
{{< note >}}
|
||||
本页假设您熟悉核心 Kubernetes 概念，并且可以轻松部署自己的应用程序。如果没有，您应首先查看 {{< link text="中级应用程序开发人员" url="/docs/user-journeys/users/application-developer/intermediate/" >}}主题。
|
||||
{{< /note >}}
|
||||
<!--
|
||||
After checking out the current page and its linked sections, you should have a better understanding of the following:
|
||||
|
||||
* Advanced features that you can leverage in your application
|
||||
* The various ways of extending the Kubernetes API
|
||||
-->
|
||||
在检测完当前页和它的链接部分后，您应该对以下内容有更好的了解：
|
||||
* 您可以在应用程序中使用的高级功能
|
||||
* 扩展 Kubernetes API 的各种方法
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Deploy an application with advanced features
|
||||
-->
|
||||
## 用高级功能部署应用程序
|
||||
|
||||
<!--
|
||||
Now you know the set of API objects that Kubernetes provides. Understanding the difference between a {{< glossary_tooltip term_id="daemonset" >}} and a {{< glossary_tooltip term_id="deployment" >}} is oftentimes sufficient for app deployment. That being said, it's also worth familiarizing yourself with Kubernetes's lesser known features. They can be quite powerful when applied to the right use cases.
|
||||
-->
|
||||
现在您知道了 Kubernetes 提供的一组 API 对象。理解{{< glossary_tooltip term_id="daemonset" >}}和{{< glossary_tooltip term_id="deployment" >}}之间的差异通常足以支持应用程序的部署。话虽如此，也值得熟悉 Kubernetes 鲜为人知的功能。当应用于正确的用例时，它们可以非常强大。
|
||||
|
||||
<!--
|
||||
#### Container-level features
|
||||
-->
|
||||
#### 容器级功能
|
||||
|
||||
<!--
|
||||
As you may know, it's an antipattern to migrate an entire app (e.g. containerized Rails app, MySQL database, and all) into a single Pod. That being said, there are some very useful patterns that go beyond a 1:1 correspondence between a container and its Pod:
|
||||
-->
|
||||
就像你知道的那样，将整个应用程序（例如，容器化的 Rails 应用程序，MySQL 数据库和所有应用程序）迁移到单个 Pod 中是一种反模式。话虽如此，有一些非常有用的模式超出了容器和它的 pod 之间 1:1 的对应关系。
|
||||
|
||||
<!--
|
||||
* **Sidecar container**: Although your Pod should still have a single main container, you can add a secondary container that acts as a helper (see a {{< link text="logging example" url="/docs/concepts/cluster-administration/logging/#sidecar-container-with-a-logging-agent" >}}). Two containers within a single Pod can communicate {{< link text="via a shared volume" url="/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/" >}}.
|
||||
-->
|
||||
* **Sidecar 容器**:虽然您的 Pod 仍然应该有一个主容器，但您可以添加一个充当帮助程序的辅助容器(请参阅 {{< link text="记录示例" url="/docs/concepts/cluster-administration/logging/#sidecar-container-with-a-logging-agent" >}})。一个 Pod 里的两个容器可以沟通{{< link text="通过共享卷" url="/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/" >}}。
|
||||
|
||||
<!--
|
||||
* **Init containers**: *Init containers* run before any of a Pod's *app containers* (such as main and sidecar containers). {{< link text="Read more" url="/docs/concepts/workloads/pods/init-containers/" >}}, see an {{< link text="nginx server example" url="/docs/tasks/configure-pod-container/configure-pod-initialization/" >}}, and {{< link text="learn how to debug these containers" url="/docs/tasks/debug-application-cluster/debug-init-containers/" >}}.
|
||||
-->
|
||||
* **Init 容器**:*Init 容器*在 Pod 的任何应用程序容器之前运行。{{< link text="阅读更多" url="/docs/concepts/workloads/pods/init-containers/" >}}，请参阅{{< link text="nginx 服务器示例" url="/docs/tasks/configure-pod-container/configure-pod-initialization/" >}}，和{{< link text="了解如何调试这些容器" url="/docs/tasks/debug-application-cluster/debug-init-containers/" >}}。
|
||||
|
||||
<!--
|
||||
#### Pod configuration
|
||||
-->
|
||||
#### Pod 配置
|
||||
|
||||
<!--
|
||||
Usually, you use {{< glossary_tooltip text="labels" term_id="label" >}} and {{< glossary_tooltip text="annotations" term_id="annotation" >}} to attach metadata to your resources. To inject data into your resources, you'd likely create {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}} (for nonconfidential data) or {{< glossary_tooltip text="Secrets" term_id="secret" >}} (for confidential data).
|
||||
-->
|
||||
通常，您使用{{< glossary_tooltip text="labels" term_id="label" >}}和{{< glossary_tooltip text="annotations" term_id="annotation" >}}将元数据附加到您的资源。要将数据注入到您的资源，您最好创建{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}（对于非机密数据）或{{< glossary_tooltip text="Secrets" term_id="secret" >}}（对于机密数据）。
|
||||
|
||||
<!--
|
||||
Below are some other, lesser-known ways of configuring your resources' Pods:
|
||||
-->
|
||||
以下是一些其他鲜为人知的配置资源的方法：
|
||||
|
||||
<!--
|
||||
* **Taints and Tolerations** - These provide a way for nodes to "attract" or "repel" your Pods. They are often used when an application needs to be deployed onto specific hardware, such as GPUs for scientific computing. {{< link text="Read more" url="/docs/concepts/configuration/taint-and-toleration/" >}}.
|
||||
-->
|
||||
* **污点和容忍度** -这些为节点“吸引“或”击退“你的 Pod 提供了一种方法。通常在应用程序需要部署在特殊硬件上时使用，比如用于科学计算的 GPU。{{< link text="阅读更多" url="/docs/concepts/configuration/taint-and-toleration/" >}}。
|
||||
<!--
|
||||
* **Downward API** - This allows your containers to consume information about themselves or the cluster, without being overly coupled to the Kubernetes API server. This can be achieved with {{< link text="environment variables" url="/docs/tasks/inject-data-application/environment-variable-expose-pod-information/" >}} or {{< link text="DownwardAPIVolumeFiles" url="/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/" >}}.
|
||||
-->
|
||||
* **下载 API** -这允许您的容器使用有关自身或集群的信息，而不会过度耦合到 Kubernetes API 服务器。这个可以通过{{< link text="环境变量" url="/docs/tasks/inject-data-application/environment-variable-expose-pod-information/" >}}或者{{< link text="向下的 API 卷文件" url="/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/" >}}来实现。
|
||||
<!--
|
||||
* **Pod Presets** - Normally, to mount runtime requirements (such as environmental variables, ConfigMaps, and Secrets) into a resource, you specify them in the resource's configuration file. {{< link text="PodPresets" url="/docs/concepts/workloads/pods/podpreset/" >}} allow you to dynamically inject these requirements instead, when the resource is created. For instance, this allows team A to mount any number of new Secrets into the resources created by teams B and C, without requiring action from B and C. {{< link text="See an example" url="/docs/tasks/inject-data-application/podpreset/" >}}.
|
||||
-->
|
||||
* **Pod 预设** -通常，将运行时的要求安装到资源中（比如环境变量、ConfigMaps、和 Secrets），请在资源的配置文件中指定它们。{{< link text="Pod 预设值" url="/docs/concepts/workloads/pods/podpreset/" >}}允许您在创建资源时动态地注入这些需求。例如，这允许团队 A 将任意数量的新 Secrets 安装到团队 B 和 C 创建的资源中，而无需 B 和 C 的命令操作。{{< link text="看一个例子" url="/docs/tasks/inject-data-application/podpreset/" >}}。
|
||||
*
|
||||
<!--
|
||||
#### Additional API Objects
|
||||
-->
|
||||
#### 其他 API 对象
|
||||
|
||||
<!--
|
||||
Before setting up the following resources, check to see if they are the responsibility of your organization's {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}}.
|
||||
-->
|
||||
{{< note >}}
|
||||
在设置以下资源之前，请检查您的组织是否负责{{< glossary_tooltip text="集群 operators" term_id="cluster-operator" >}}。
|
||||
{{< /note >}}
|
||||
<!--
|
||||
* **{{< glossary_tooltip text="Horizontal Pod Autoscaler (HPA)" term_id="horizontal-pod-autoscaler" >}}** - These resources are a great way to automate the process of scaling your application when CPU usage or other {{< link text="custom metrics" url="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md" >}} spike. {{< link text="See an example" url="/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/" >}} to understand how HPAs are set up.
|
||||
-->
|
||||
* **{{< glossary_tooltip text="Horizontal Pod Autoscaler (HPA)" term_id="horizontal-pod-autoscaler" >}}** - 这些资源是在 CPU 使用或其他{{< link text="自定义指标" url="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md" >}}峰值时自动执行缩放应用程序的好方法。
|
||||
{{< link text="参看一个例子" url="/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/" >}}以了解如何设置 HPA。
|
||||
<!--
|
||||
* **Federated cluster objects** - If you are running an application on multiple Kubernetes clusters using *federation*, you need to deploy the federated version of the standard Kubernetes API objects. For reference, check out the guides for setting up {{< link text="Federated ConfigMaps" url="/docs/tasks/administer-federation/configmap/" >}} and {{< link text="Federated Deployments" url="/docs/tasks/administer-federation/deployment/" >}}.
|
||||
-->
|
||||
* **联合集群对象** - 如果您在多个 Kubernetes 集群上使用*federation*运行应用程序，您需要部署标准 Kubernetes API 对象的联合版本。有关参考，请查看设置指南{{< link text="联邦 ConfigMaps" url="/docs/tasks/administer-federation/configmap/" >}} and {{< link text="联邦 Deployments" url="/docs/tasks/administer-federation/deployment/" >}}。
|
||||
|
||||
<!--
|
||||
## Extend the Kubernetes API
|
||||
-->
|
||||
## 扩展 Kunernetes API
|
||||
|
||||
<!--
|
||||
Kubernetes is designed with extensibility in mind. If the API resources and features mentioned above are not enough for your needs, there are ways to customize its behavior without having to modify core Kubernetes code.
|
||||
-->
|
||||
Kubernetes 在设计时考虑了可扩展性。如果以上提到的 API 资源和功能不足以满足您的需求，可以通过各种方法自定义其行为，而无需修改核心 Kubernetes 代码。
|
||||
|
||||
<!--
|
||||
#### Understand Kubernetes's default behavior
|
||||
-->
|
||||
#### 了解 Kubernetes 的默认行为
|
||||
|
||||
<!--
|
||||
Before making any customizations, it's important that you understand the general abstraction behind Kubernetes API objects. Although Deployments and Secrets may seem quite different, the following concepts are true for *any* object:
|
||||
-->
|
||||
在进行任何自定义之前，了解 Kubernetes API 对象背后的一般抽象非常重要。尽管 Deployments 和 Secrets 可能看起来非常不同，以下概念适用于*any* 对象:
|
||||
|
||||
<!--
|
||||
* **Kubernetes objects are a way of storing structured data about your cluster.**
|
||||
-->
|
||||
* **Kubernetes 对象是一种存储集群结构化数据的方法。**
|
||||
<!--
|
||||
In the case of Deployments, this data represents desired state (such as "How many replicas should be running?"), but it can also be general metadata (such as database credentials).
|
||||
-->
|
||||
对于 Deployments，此数据表示所需的状态（例如“应运行多少个副本？”），但它也可以是常规元数据（例如数据库凭据）。
|
||||
<!--
|
||||
* **Kubernetes objects are modified via the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}}**.
|
||||
-->
|
||||
* **Kubernetes 对象通过{{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}}进行修改**。
|
||||
<!--
|
||||
In other words, you can make `GET` and `POST` requests to a specific resource path (such as `<api-server-url>/api/v1/namespaces/default/deployments`) to read and write the corresponding object type.
|
||||
-->
|
||||
换句话说，您可以对特定的资源路径（例如`<api-server-url>/api/v1/namespaces/default/deployments`）发出`GET`和`POST`请求来读写相应的对象类型。
|
||||
<!--
|
||||
* **By leveraging the {{< link text="Controller pattern" url="/docs/concepts/api-extension/custom-resources/#custom-controllers" >}}, Kubernetes objects can be used to enforce desired state**. For simplicity, you can think of the Controller pattern as the following continuous loop:
|
||||
-->
|
||||
* **通过利用{{< link text="控制器模式" url="/docs/concepts/api-extension/custom-resources/#custom-controllers" >}}，可以使用 Kubernetes 对象来强制执行所需的状态**。为简单起见，您可以将 Controller 模式视为以下连续循环：
|
||||
|
||||
<!--
|
||||
<div class="emphasize-box" markdown="1">
|
||||
1. Check current state (number of replicas, container image, etc)
|
||||
2. Compare current state to desired state
|
||||
3. Update if there's a mismatch
|
||||
</div>
|
||||
-->
|
||||
<div class="emphasize-box" markdown="1">
|
||||
1. 检查当前状态(副本数量, 容器镜像等)
|
||||
2. 比较当前状态与期望状态
|
||||
3. 如果不匹配则更新
|
||||
</div>
|
||||
|
||||
<!--
|
||||
These states are obtained from the Kubernetes API.
|
||||
-->
|
||||
这些状态来自 Kubernetes API。
|
||||
|
||||
<!--
|
||||
Not all Kubernetes objects need to have a Controller. Though Deployments trigger the cluster to make state changes, ConfigMaps act purely as storage.
|
||||
-->
|
||||
{{< note >}}
|
||||
不是所有 Kubernetes 对象都需要一个 Controller。尽管 Deployment 会触发集群进行状态更改，但 ConfigMap 仅作为存储使用。
|
||||
{{< /note >}}
|
||||
<!--
|
||||
#### Create Custom Resources
|
||||
-->
|
||||
#### 创建自定义资源
|
||||
|
||||
<!--
|
||||
Based on the ideas above, you can define a new {{< link text="Custom Resource" url="/docs/concepts/api-extension/custom-resources/#custom-resources" >}} that is just as legitimate as a Deployment. For example, you might want to define a `Backup` object for periodic backups, if `CronJobs` don't provide all the functionality you need.
|
||||
-->
|
||||
基于以上想法，您可以定义一个新的{{< link text="自定义资源" url="/docs/concepts/api-extension/custom-resources/#custom-resources" >}}作为合理的部署。例如，如果`CronJobs`没有提供您需要的所有功能，您可能希望为定期备份定义一个`Backup`对象。
|
||||
|
||||
<!--
|
||||
There are two main ways of setting up custom resources:
|
||||
1. **Custom Resource Definitions (CRDs)** - This method requires the least amount of implementation work. See {{< link text="an example" url="/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/" >}}.
|
||||
2. **API aggregation** - This method requires some {{< link text="pre-configuration" url="/docs/tasks/access-kubernetes-api/configure-aggregation-layer/" >}} before you actually {{< link text="set up a separate, extension API server" url="/docs/tasks/access-kubernetes-api/setup-extension-api-server/" >}}.
|
||||
-->
|
||||
设置自定义资源有两种主要方式：
|
||||
1.**自定义资源定义 (CRDs)** - 此方法需要的实施工作量最少。请参阅{{< link text="一个例子" url="/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/" >}}。
|
||||
2.**API 聚合** - 此方法需要一些{{< link text="预配置" url="/docs/tasks/access-kubernetes-api/configure-aggregation-layer/" >}}在你实际上{{< link text="设置一个单独的扩展的 API 服务器" url="/docs/tasks/access-kubernetes-api/setup-extension-api-server/" >}}之前。
|
||||
|
||||
<!--
|
||||
Note that unlike standard Kubernetes objects, which rely on the built-in {{< link text="`kube-controller-manager`" url="/docs/reference/generated/kube-controller-manager/" >}}, you'll need to write and run your own {{< link text="custom controllers" url="https://github.com/kubernetes/sample-controller" >}}.
|
||||
-->
|
||||
请注意，与标准的 Kubernetes 对象不同，后者依赖于内置的{{< link text="`kube-controller-manager`" url="/docs/reference/generated/kube-controller-manager/" >}}，您需要编写并运行自己的{{< link text="自定义控制器" url="https://github.com/kubernetes/sample-controller" >}}。
|
||||
|
||||
<!--
|
||||
You may also find the following info helpful:
|
||||
* {{< link text="How to know if custom resources are right for your use case" url="/docs/concepts/api-extension/custom-resources/#should-i-use-a-configmap-or-a-custom-resource" >}}
|
||||
* {{< link text="How to decide between CRDs and API aggregation" url="/docs/concepts/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources" >}}
|
||||
-->
|
||||
您可能还会发现以下信息有用：
|
||||
* {{< link text="如何知道自定义资源是否适合您的用例" url="/docs/concepts/api-extension/custom-resources/#should-i-use-a-configmap-or-a-custom-resource" >}}
|
||||
* {{< link text="如何决定 CRD 和 API 聚合" url="/docs/concepts/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources" >}}
|
||||
|
||||
<!--
|
||||
#### Service Catalog
|
||||
-->
|
||||
#### 服务目录
|
||||
|
||||
<!--
|
||||
If you want to consume or provide complete services (rather than individual resources), **{{< glossary_tooltip text="Service Catalog" term_id="service-catalog" >}}** provides a {{< link text="specification" url="https://github.com/openservicebrokerapi/servicebroker" >}} for doing so. These services are registered using {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} (see {{< link text="some examples" url="https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#example-service-brokers" >}}).
|
||||
-->
|
||||
如果您想使用或提供完整的服务（而不是单个资源），**{{< glossary_tooltip text="Service Catalog" term_id="service-catalog" >}}**提供{{< link text="规格" url="https://github.com/openservicebrokerapi/servicebroker" >}}来这样做。这些服务使用{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}注册（请参阅{{< link text="一些例子" url="https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#example-service-brokers" >}}）。
|
||||
|
||||
<!--
|
||||
If you do not have a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} to manage the installation of Service Catalog, you can do so using {{< link text="Helm" url="/docs/tasks/service-catalog/install-service-catalog-using-helm/" >}} or an {{< link text="installer binary" url="/docs/tasks/service-catalog/install-service-catalog-using-sc/" >}}.
|
||||
-->
|
||||
如果您没有{{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}}来管理服务目录的安装，您可以使用{{< link text="Helm" url="/docs/tasks/service-catalog/install-service-catalog-using-helm/" >}} 或{{< link text="安装程序二进制" url="/docs/tasks/service-catalog/install-service-catalog-using-sc/" >}}。
|
||||
|
||||
|
||||
<!--
|
||||
## Explore additional resources
|
||||
-->
|
||||
## 探索其他资源
|
||||
|
||||
<!--
|
||||
#### References
|
||||
-->
|
||||
#### 参考
|
||||
|
||||
<!--
|
||||
The following topics are also useful for building more complex applications:
|
||||
-->
|
||||
以下主题对于构建更复杂的应用程序也很有用：
|
||||
|
||||
<!--
|
||||
* {{< link text="Other points of extensibility within Kubernetes" url="/docs/concepts/overview/extending/" >}} - A conceptual overview of where you can hook into the Kubernetes architecture.
|
||||
* {{< link text="Kubernetes Client Libraries" url="/docs/reference/using-api/client-libraries/" >}} - Useful for building apps that need to interact heavily with the Kubernetes API.
|
||||
-->
|
||||
* {{< link text="Kubernetes 中的其他可扩展性点" url="/docs/concepts/overview/extending/" >}} - 概述您可以在何处进入 Kubernetes 架构。
|
||||
* {{< link text="Kubernetes 客户库" url="/docs/reference/using-api/client-libraries/" >}} - 用于构建需要与 Kubernetes API 进行大量交互的应用程序。
|
||||
|
||||
<!--
|
||||
#### What's next
|
||||
Congrats on completing the Application Developer user journey! You've covered the majority of features that Kubernetes has to offer. What now?
|
||||
-->
|
||||
#### 接下来是什么
|
||||
恭喜您完成应用程序开发者用户之旅！您已经掌握了 Kubernetes 提供的大多数功能。现在该做什么？
|
||||
|
||||
<!--
|
||||
* If you'd like to suggest new features or keep up with the latest developments around Kubernetes app development, consider joining a {{< glossary_tooltip term_id="sig" >}} such as {{< link text="SIG Apps" url="https://github.com/kubernetes/community/tree/master/sig-apps" >}}.
|
||||
-->
|
||||
* 如果您想推荐新功能或者了解 Kubernentes 应用程序开发的最新进展，请考虑加入{{< glossary_tooltip term_id="sig" >}}，例如{{< link text="SIG Apps" url="https://github.com/kubernetes/community/tree/master/sig-apps" >}}。
|
||||
|
||||
<!--
|
||||
* If you are interested in learning more about the inner workings of Kubernetes (e.g. networking), consider checking out the {{< link text="Cluster Operator journey" url="/docs/user-journeys/users/cluster-operator/foundational/" >}}.
|
||||
-->
|
||||
* 如果您有兴趣了解 Kubernetes 的内部工作（例如网络），请考虑查看{{< link text="Cluster Operator journey" url="/docs/user-journeys/users/cluster-operator/foundational/" >}}。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user