From 0b5b5fd6eaf8f454f9727b711f468d342283befe Mon Sep 17 00:00:00 2001 From: Xiaolong He Date: Thu, 2 Jan 2020 11:55:40 +0800 Subject: [PATCH] release-1.17_zh issue tasks (#18295) --- .../controllers/jobs-run-completion.md | 868 ------------------ .../docs/setup/independent/install-kubeadm.md | 409 --------- ...t-slices.md => enabling-endpointslices.md} | 0 content/zh/docs/tools/install-minikube.md | 248 ----- .../tutorials/clusters/deny-write.profile | 10 - .../users/app-developer/advanced.md | 280 ------ 6 files changed, 1815 deletions(-) delete mode 100644 content/zh/docs/concepts/workloads/controllers/jobs-run-completion.md delete mode 100644 content/zh/docs/setup/independent/install-kubeadm.md rename content/zh/docs/tasks/administer-cluster/{enabling-endpoint-slices.md => enabling-endpointslices.md} (100%) delete mode 100644 content/zh/docs/tools/install-minikube.md delete mode 100644 content/zh/docs/tutorials/clusters/deny-write.profile delete mode 100644 content/zh/docs/user-journeys/users/app-developer/advanced.md diff --git a/content/zh/docs/concepts/workloads/controllers/jobs-run-completion.md b/content/zh/docs/concepts/workloads/controllers/jobs-run-completion.md deleted file mode 100644 index 9a59b28fa9..0000000000 --- a/content/zh/docs/concepts/workloads/controllers/jobs-run-completion.md +++ /dev/null @@ -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 ---- - - - -{{% capture overview %}} - - - -Job 创建一个或多个 pod，并且确保指定数量的 pod 成功终止。Pod 成功完成后，Job 将跟踪成功完成的情况。当达到指定的成功完成次数时，任务（即 Job）就完成了。删除 Job 将清除其创建的 pod。 - - - -一种简单的情况时创建一个 Job 对象，以便可靠地运行一个 Pod 来完成。如果第一个 pod 失败了或被删除了（例如，由于节点硬件故障或节点重启），则 Job 对象将启动一个新的 pod。 - - - -也可以使用 Job 去并行运行多个 pod。 - -{{% /capture %}} - - -{{% capture body %}} - - - -## 运行一个 Job 示例 - - - -下面是一个 Job 配置样例。它计算 π 到2000位并将其打印出来。大约需要 10 秒钟才能完成。 - -{{< codenew file="controllers/job.yaml" >}} - - - -可以使用以下命令运行示例： - -```shell -kubectl apply -f https://k8s.io/examples/controllers/job.yaml -``` -``` -job "pi" created -``` - - - -使用 `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: -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: - Mounts: - Volumes: -Events: - FirstSeen LastSeen Count From SubobjectPath Type Reason Message - --------- -------- ----- ---- ------------- -------- ------ ------- - 1m 1m 1 {job-controller } Normal SuccessfulCreate Created pod: pi-dtn4q -``` - - - -要查看 Job 的已完成 pod，可以使用 `kubectl get pods` 命令。 - - - -要以机器可读的形式列出属于 Job 的所有 pod，可以使用以下命令： - -```shell -pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') -echo $pods -``` -``` -pi-aiw0a -``` - - - -这里，选择器与 Job 的选择器相同。`--output=jsonpath` 选项指定一个表达式来从 pod 返回列表中获取每个 pod 的名称。 - - - -查看其中一个 pod 的标准输出： - -```shell -kubectl logs $pods -``` -The output is similar to this: -```shell -3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 -``` - - - -## 编写 Job 规范 - - - -和其他 Kubernetes 配置一样，Job 需要 `apiVersion`，`kind` 和 `metadata` 字段。 - - - -Job 也需要 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 - - - -### Pod 模板 - - - -`.spec.template` 是 `.spec` 中唯一必填字段。 - - - -`.spec.template` 是 [pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它具有与 [pod](/docs/user-guide/pods) 完全相同的架构，只是它是嵌套的并且没有 `apiVersion` 或 `kind`。 - - - -除了 pod 的必填字段，Job 中的 pod 模板还必须指定合适的标签（参考 [pod 选择器](#pod-selector)）和适当的重启策略。 - - - -[`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 只能等于 `Never` 或 `OnFailure`。 - - - -### Pod 选择器 - - - -`.spec.selector` 字段是可选的。在大多数场景下不必指定它。请参阅[指定自己的 pod 选择器](#specifying-your-own-pod-selector)。 - - - -### 并行 Job - - - -下面是适合作为 Job 运行的三种主要任务类型： - - - -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 都不应该为此任务做任务工作或编写任何输出。它们都应该处在退出过程中。 - - - -对于_非并行_ Job，可以不设置 `.spec.completions` 和 `.spec.parallelism`。两者均未设置时，默认值为 1。 - - - -对于一个_固定完成计数_ Job，应该将 `.spec.completions` 设置为所需的完成数量。`.spec.parallelism` 可以设置，也可以不设置，默认值为 1。 - - - -对于一个_工作队列_ Job，不要设置 `.spec.completions`，并且将 `.spec.parallelism` 设置一个非负整数。 - - - -有关如何使用不同类型 Job 的更多信息，请参考 [Job 模式](#job-patterns)部分。 - - - - -#### 控制并行 - - - -请求的并发数（`.spec.parallelism`）可以设置为任何非负的整数。如果未指定，默认值为 1。如果指定为 0，则 Job 就被有效地暂停直到该配置值增加。 - - - -实际的并发数（在任何时刻运行着的 pod 数量）由于下面的一些原因，可能大于或小于请求的并发数： - - - -- 对于_固定完成计数_ Job，实际上并行运行的 pod 数量不会超过剩余的完成数。更高的 `.spec.parallelism` 值将被优先忽略。 -- 对于_工作队列_ Job，任何 pod 成功之后都不会启动新的 pod。然而，剩余的 pod 可以完成。 -- 如果控制器还没来得及反应。 -- 如果控制器由于任何原因（缺少 `ResourceQuota`，缺少权限等）未能创建 pod，则 pod 数量将少于请求数。 -- 控制器可能会因为同一 Job 中有过多之前失败的 pod，从而限制新的 pod 的创建。 -- 当 pod 优雅关闭时，需要花费一些时间才能停止。 - - - -## 处理 Pod 和容器失败 - - - -Pod 中的容器可能由于多种原因而失败，例如，由于容器中的进程以非零退出码退出，或者容器由于超过内存限制而被杀掉等。如果容器失败发生，并且 `.spec.template.spec.restartPolicy = "OnFailure"`，则 pod 停留在节点上，但是容器会重新运行。因此，你的程序需要处理本地重启的情况，或者指定 `.spec.template.spec.restartPolicy = "Never"`。参阅 [pod 生命周期](/docs/concepts/workloads/pods/pod-lifecycle/#example-states)获取更多关于 `restartPolicy` 的信息。 - - - -由于多种原因，整个 pod 也可能失败，比如，当 pod 从节点上被踢走（节点在升级，重启，被删除等），或者 pod 中的容器失败且设置了 `.spec.template.spec.restartPolicy = "Never"`。当 pod 失败后，Job 控制器将启动一个新的 pod。这意味着你的应用程序需要处理这种情况（应用程序在新的 pod 中重启）。特别是，它需要处理由先前运行引起的临时文件，锁，不完整输出等等。 - - - -请注意，即使你指定了 `.spec.parallelism = 1`，`.spec.completions = 1` 和 `.spec.template.spec.restartPolicy = "Never"`，统一程序有时也会启动两次。 - - - -如果你指定 `.spec.parallelism` 和 `.spec.completions` 配置都大于 1，则可能同时有多个 pod 运行。因此，你的 pod 必须容忍并发。 - - - -### Pod 的退避失败策略 - - - -在某些情况下（配置中的逻辑错误等），你需要在重试一定次数后才使 Job 失败。为此需要设置 `.spec.backoffLimit` 配置值为判断 Job 失败前的重试次数。 退避限制默认设置为 6。与 Job 相关的 pod在失败后，经过一个指数级退避延迟（10 秒，20 秒，40 秒，上限为 6 分钟），由 Job 控制器重新创建。 如果在 Job 的下一次状态检查之前未出现新的失败 pod，则会重置退避计数。 - -{{< note >}} - - -1.12 之前的 Kubernetes 版本仍然存在问题 [#54870](https://github.com/kubernetes/kubernetes/issues/54870) - -{{< /note >}} -{{< note >}} - - -如果你的 Job 外配置了 `restartPolicy = "OnFailure"`，请记住，一旦 Job 达到退避限制，运行在该 Job 的容器将被终止。这会使得调试 Job 的可执行将变得更加困难。我们建议在调试 Job 或使用日志系统时设置 `restartPolicy = "Never"`，以确保失败 Job 的输出不会在不经意间丢失。 -{{< /note >}} - - - -## Job 终止和清理 - - - -当 Job 完成后，不会再创建 pod，但是 pod 也不会被删除。将这些 pod 保留，使你仍然可以查看已完成 pod 的日志来检查错误，警告或其他诊断输出。Job 对象在完成后也同样保留下来，以便你可以查看它的状态。由用户来决定在查看完状态后删除旧的 Job。使用 `kubectl`（例如 `kubectl delete jobs/pi` 或 `kubectl delete -f ./job.yaml` ）来删除 Job。当你使用 `kubectl` 删除 Job 后，它所创建的所有 pod 也会被删除。 - - - -默认情况下，除非 pod 失败（`restartPolicy=Never`）或容器错误退出（`restartPolicy=OnFailure`），否则 Job 将不会被中断运行。Job 中断将遵循上面介绍的 `.spec.backoffLimit`。一旦 `.spec.backoffLimit` 达到，Job 将被标记为失败，企鹅别所有正运行的 pod 将被终止。 - - - -终止 Job 的另一种方式是设置有限期限。通过设置 Job 对象的 `.spec.activeDeadlineSeconds` 字段为秒数来达到。`activeDeadlineSeconds` 适用于 Job 存在期间，不管有多少 pod 被创建。一旦 Job 达到 `activeDeadlineSeconds`，所有运行中的 pod将被终止，并且 Job 的状态将变成 `type: Failed` 与 `reason: DeadlineExceeded`。 - - - -请注意，Job 的 `.spec.activeDeadlineSeconds` 配置优先于 `.spec.backoffLimit` 配置。因此，重试一个或多个失败 pod 的 Job 在达到 `activeDeadlineSeconds` 指定的时间限制前，不会部署其他的 pod，即使 `backoffLimit` 尚未达到。 - - - -例子： - -```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 -``` - - - -请注意，Job 对象中的 Job 规范和 [Pod 模板规范](/docs/concepts/workloads/pods/init-containers/#detailed-behavior)都有 `activeDeadlineSeconds` 字段。确保将此字段设置在适当的层级。 - - - -## 自动清理已完成的 Job - - - -系统中已完成的 Job 通常不再需要。将它们保留在系统中将会给 API 服务器带来压力。如果 Job 由更高级别的控制器管理，比如 [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/)，则 Job 可以由 CronJobs 基于指定的基于容量的清理策略来进行清除。 - - - -### 已完成 Job 的 TTL 机制 - -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} - - - -清理已完成 Job（`Complete` 或 `Failed`）的另一个方式是通过使用 [TTL 控制器](/docs/concepts/workloads/controllers/ttlafterfinished/)提供的 TTL 机制，TTL 通过指定 Job 的 `.spec.ttlSecondsAfterFinished` 字段来清理已完成资源。 - - - -当 TTL 控制器清理 Job 时，它将级联删除 Job，即删除它的依赖对象，比如 pod 将和 Job 一起被删除。请注意，当 Job 被删除后，它的生命周期保证，如终结者，将被触发。 - - - -例如： - -```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 -``` - - - -`pi-with-ttl` Job 在完成后 100 秒就会自动删除掉。 - - - -如果该字段设为为 `0`，那么 Job 将在完成后立即被自动删除掉。如果该字段未设置，则 Job 在完成后将不会被 TTL 控制器清理掉。 - - - -请注意，此 TTL 机制处于 alpha 阶段，由 `TTLAfterFinished` 功能门控制是否启动。有关详细信息，请参阅 [TTL 控制器](/docs/concepts/workloads/controllers/ttlafterfinished/)中关于已完成资源的处理。 - - - -## Job 模式 - - - -Job 对象可用于支持 pod 的可靠并行执行。Job 对象并非设计为支持紧密通信的并行过程（常见于科学计算领域）。它被用于支持一组独立但相关的*工作项*的并行处理。这些可能是要发送的电子邮件，要渲染的帧，要编码转换的文件，要扫描的 NoSQL 数据库中一段范围内的键等等。 - - - -在复杂的系统中，可能会有多个不同的工作项集。这里我们只考虑用户想要一起管理一组工作项 — *批处理任务*。 - - - -并行计算有几种不同的模式，每种都有各自的优缺点。权衡点如下： - - - -- 一个 Job 对象处理一个工作项，还是一个 Job 对象处理所有的工作项。后者适用于有大量工作项的场景。前者在管理大量 Job 对象时会对用户和系统带来一些开销。 -- 创建和工作项数量一样多的 pod，还是一个 pod 处理多个工作项。前者通常对现有代码和容器进行较少的修改。后者更适用于处理大量工作项（理由和前一条的相似）。 -- 几种方法使用工作队列。这需要运行一个队列服务，并对现有的程序和容器进行修改以使其能够使用工作队列。其他方法更容易适应现有的容器化应用程序。 - - - - -权衡总结如下表，第 2 至 4 列对应上面的权衡点。模式名称也是样例和详细描述的链接。 - - - -| 模式 | 单个 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 | ✓ | | ✓ | | - - - -当使用 `.spec.completions` 指定完成数时，由 Job 控制器创建的每个 pod 都有一个相同的 [`规范`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。这意味着一个任务的所有 pod 将有相同的命令行和镜像，相同的卷以及（几乎）相同的环境变量。这些模式通过不同的方式安排 pod 去处理不同的任务。 - - - -下表列出了每种模式下对 `.spec.parallelism` 和 `.spec.completions` 需要做的设置。 - - - - -| 模式 | `.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 | 任意 | - - - -## 高级用法 - - - -### 指定你的 pod 选择器 - - - -通常，在创建 Job 对象时，不用指定 `.spec.selector`。系统的默认逻辑会在创建 Job 时添加这个字段。它会选择一个不会和其他 pod 重叠的选择器。 - - - -但是，在某些情况下，你可能需要去覆盖默认设置的选择器。为此，你需要指定 Job 的 `.spec.selector`。 - - - -当设置时需要特别小心。如果你指定的标签选择器不是 Job 的 pod 所独有的，并且匹配到了不相关的 pod，那么不相关 Job 的 pod 可能会被删除，或此 Job 可能将其他 pod 统计为已完成，或者其中一个或两个 Job 可能拒绝创建 pod 或运行完成。如果一个选择了非唯一的选择器，则其他的控制器（比如 ReplicationController）和它的 pod 的行为也将是不可预测的。当指定了 `.spec.selector`，Kubernetes将不会阻止你产生错误。 - - - -下面的例子描述了你想要使用该功能的场景。 - - - -假设 `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 - ... -``` - - - -然后使用新名称 `new` 创建一个新的 Job ，并且显示指定相同的选择器。由于现有的 pod 具有 `controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002` 标签，它们也受 `new` Job 的控制。 - - - -由于你不再使用系统通常为你自动生成的选择器，你需要在新的 Job 中指定 `manualSelector: true`。 - -``` -kind: Job -metadata: - name: new - ... -spec: - manualSelector: true - selector: - matchLabels: - controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 - ... -``` - - - -新的 Job 本身将具有一个与 `a8f3d00d-c6d2-11e5-9f87-42010af00002` 不通的 uid。设置 `manualSelector: true` 来告诉系统你知道自己在做什么，并使其允许这种不匹配。 - - - -## 备选方案 - - - -### 裸 pod - - - -当 pod 所在节点重启或发生故障时，pod 将终止并且不会重启。然后，Job 将创建新的 pod 替换终止的 pod。因此，即使你的应用仅需要一个 pod，我们还是推荐使用 Job 而不是裸 pod。 - - - -### 副本控制器 - - - -Job 是[副本控制器](/docs/user-guide/replication-controller)的补充。副本控制器管理预期不会终止的 pod（比如 web 服务器），而 Job 管理预期将会终止的 pod（比如批处理任务）。 - - - -正如在 [Pod 生命周期](/docs/concepts/workloads/pods/pod-lifecycle/)中所讨论的，`Job` *仅*适用于具有 `RestartPolicy` 值为 `OnFailure` 或 `Never` 的 pod。（注意：如果 `RestartPolicy` 未指定，默认值为 `Always`。） - - - -### 单 Job 启动控制 pod - - - -单个 Job 的另一种模式是创建一个创建其他 pod 的 pod，充当这些 pod 的一种自定义控制器。这提供了更大的灵活性，但是入门起来可能有点复杂，并且与 Kubernetes 的集成较少。 - - - -这种模式的一个样例是：一个 Job 启动一个 pod 来运行一个脚本，该脚本依次启动 Spark 主控制器（参阅 [spark 例子](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)），并运行 spark 驱动，然后进行清理。 - - - -这种方法的优点是整个过程可以获取 Job 对象的完成保证，不是完全控制 pod 的创建以及如何将工作分配给 pod。 - -## Cron Jobs {#cron-jobs} - - - -你可以使用 [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) 来创建一个会在指定的时间/日期执行的 Job，类似于 Unix 工具 `cron`。 - -{{% /capture %}} diff --git a/content/zh/docs/setup/independent/install-kubeadm.md b/content/zh/docs/setup/independent/install-kubeadm.md deleted file mode 100644 index c897af63e9..0000000000 --- a/content/zh/docs/setup/independent/install-kubeadm.md +++ /dev/null @@ -1,409 +0,0 @@ ---- -title: 安装 kubeadm -content_template: templates/task -weight: 20 ---- - - -{{% capture overview %}} - - - 本文会告诉您如何安装 `kubeadm` 工具。完成本文提到的安装步骤后，您可以阅读 [使用 kubeadm 来创建集群](/docs/setup/independent/create-cluster-kubeadm/) 了解如何使用 kubeadm 来创建集群。 - -{{% /capture %}} - -{{% capture prerequisites %}} - - -* 一台或多台运行着下列系统的机器: - - 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 %}} - - -## 确保每个节点上 MAC 地址和 product_uuid 的唯一性。 - - -* 您可以使用下列命令获取网络接口的 MAC 地址：`ip link` 或是 `ifconfig -a` -* 下列命令可以用来获取 product_uuid `sudo cat /sys/class/dmi/id/product_uuid` - - -一般来讲，硬件设备会拥有独一无二的地址，但是有些虚拟机可能会雷同。Kubernetes 使用这些值来唯一确定集群中的节点。如果这些值在集群中不唯一，可能会导致安装[失败](https://github.com/kubernetes/kubeadm/issues/31)。 - - - -## 检查网络适配器 - - - -如果您有一个以上的网络适配器，同时您的 Kubernetes 组件通过默认路由不可达，我们建议您预先添加 IP 路由规则，这样 Kubernetes 集群就可以通过对应的适配器完成连接。 - - - -## 检查所需端口 - - - -### 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 节点 - -| 规则 | 方向 | 端口范围 | 作用 | 使用者 | -|----------|-----------|-------------|-----------------------|-------------------------| -| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | -| TCP | Inbound | 30000-32767 | NodePort Services** | All | - - -** [NodePort 服务](/docs/concepts/services-networking/service/) 的默认端口范围。 - - -任何使用 * 标记的端口号都有可能被覆盖，所以您需要保证您的自定义端口的状态是开放的。 - - -虽然主节点已经包含了 etcd 的端口，您也可以使用自定义的外部 etcd 集群，或是指定自定义端口。 - -您使用的 pod 网络插件 (见下) 也可能需要某些特定端口开启。由于各个 pod 网络插件都有所不同，请参阅他们各自文档中对端口的要求。 - - -## 安装 runtime - - -从 v1.6.0 起，Kubernetes 开始允许使用 CRI，容器运行时接口。默认的容器运行时是 Docker，这是由 `kubelet` 内置的 CRI 实现 `dockershim` 开启的。 - - -其他的容器运行时有： - -- [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) - - -参考 [CRI 安装指南](/docs/setup/cri) 获取更多信息. - - -## 安装 kubeadm, kubelet 和 kubectl - - -您需要在每台机器上都安装以下的软件包： - - * `kubeadm`: 用来初始化集群的指令。 - - * `kubelet`: 在集群中的每个节点上用来启动 pod 和 container 等。 - - * `kubectl`: 用来与集群通信的命令行工具。 - - -kubeadm **不能** 帮您安装或管理 `kubelet` 或 `kubectl` ，所以您得保证他们满足通过 kubeadm 安装的 Kubernetes 控制层对版本的要求。如果版本没有满足要求，就有可能导致一些难以想到的错误或问题。然而控制层与 kubelet 间的 _小版本号_ 不一致无伤大雅，不过请记住 kubelet 的版本不可以超过 API server 的版本。例如 1.8.0 的 API server 可以适配 1.7.0 的 kubelet，反之就不行了。 - - -{{< warning >}} -这些指南不包括所有系统升级时使用的 Kubernetes 程序包。这是因为 kubeadm 和 Kubernetes 需要 [升级时的特别注意事项](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/)。 -{{}} - - - -更多关于版本偏差的信息，请参阅 [版本偏差政策](/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 </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 -``` - - - -{{% /tab %}} -{{% tab name="CentOS, RHEL or Fedora" %}} -```bash -cat < /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 -``` - - - **请注意：** - - - - 通过命令 `setenforce 0` 和 `sed ...` 可以将 SELinux 设置为 permissive 模式(将其禁用)。 - 只有执行这一操作之后，容器才能访问宿主的文件系统，进而能够正常使用 Pod 网络。您必须这么做，直到 kubelet 做出升级支持 SELinux 为止。 - - 一些 RHEL/CentOS 7 的用户曾经遇到过：由于 iptables 被绕过导致网络请求被错误的路由。您得保证 - 在您的 `sysctl` 配置中 `net.bridge.bridge-nf-call-iptables` 被设为1。 - - ```bash - cat < /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" %}} - -安装 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 -``` - - -安装 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 -``` - - - -安装 `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 -``` - - -启用并启动 `kubelet`: - -```bash -systemctl enable kubelet && systemctl start kubelet -``` -{{% /tab %}} -{{< /tabs >}} - - -kubelet 现在每隔几秒就会重启，因为它陷入了一个等待 kubeadm 指令的死循环。 - - -## 在 Master 节点上配置 kubelet 所需的 cgroup 驱动 - - -使用 Docker 时，kubeadm 会自动为其检测 cgroup 驱动在运行时对 `/var/lib/kubelet/kubeadm-flags.env` 文件进行配置。 - -如果您使用了不同的 CRI， 您得把 `/etc/default/kubelet` 文件中的 `cgroup-driver` 位置改为对应的值，像这样： - -```bash -KUBELET_EXTRA_ARGS=--cgroup-driver= -``` - - -这个文件将会被 `kubeadm init` 和 `kubeadm join` 用于为 kubelet 获取 额外的用户参数。 - - -请注意，您**只**需要在您的 cgroup driver 不是 `cgroupfs` 时这么做，因为 `cgroupfs` 已经是 kubelet 的默认值了。 - - -需要重启 kubelet： - -```bash -systemctl daemon-reload -systemctl restart kubelet -``` - - -## 查错 - - -如果您在使用 kubeadm 时候遇到问题，请查看我们的[疑难解答文档](/docs/setup/independent/troubleshooting-kubeadm/). -{{% capture whatsnext %}} - -* [使用 kubeadm 来创建集群](/docs/setup/independent/create-cluster-kubeadm/) - -{{% /capture %}} diff --git a/content/zh/docs/tasks/administer-cluster/enabling-endpoint-slices.md b/content/zh/docs/tasks/administer-cluster/enabling-endpointslices.md similarity index 100% rename from content/zh/docs/tasks/administer-cluster/enabling-endpoint-slices.md rename to content/zh/docs/tasks/administer-cluster/enabling-endpointslices.md diff --git a/content/zh/docs/tools/install-minikube.md b/content/zh/docs/tools/install-minikube.md deleted file mode 100644 index 903768c21e..0000000000 --- a/content/zh/docs/tools/install-minikube.md +++ /dev/null @@ -1,248 +0,0 @@ ---- -title: 安装 Minikube -content_template: templates/task -weight: 20 -card: - name: tasks - weight: 10 ---- - -{{% capture overview %}} - - -该页面向您展示了如何安装 [Minikube](/docs/tutorials/hello-minikube)，Minikube 是一个安装在您电脑虚拟机上的单节点 Kubernetes 集群。 - -{{% /capture %}} - -{{% capture prerequisites %}} - -{{< tabs name="minikube_before_you_begin" >}} -{{% tab name="Linux" %}} - -检查 Linux 上是否支持虚拟化，运行如下命令并确保输出不为空： -``` -grep -E --color 'vmx|svm' /proc/cpuinfo -``` -{{% /tab %}} - -{{% tab name="macOS" %}} - -检查 macOS 上是否支持虚拟化，运行如下命令并确保输出不为空： -``` -sysctl -a | grep -E --color 'machdep.cpu.features|VMX' -``` - -如果输出内容为有颜色的 `VMX`，表示在您的电脑上 VT-x 功能已经开启。 -{{% /tab %}} - -{{% tab name="Windows" %}} - -检查在 Windows 8 及以上系统是否支持虚拟化，在您 Windows 终端或命令行运行如下命令： -``` -systeminfo -``` - -如果输出如下内容，表示您的 Windows 支持虚拟化。 -``` -Hyper-V Requirements: VM Monitor Mode Extensions: Yes - Virtualization Enabled In Firmware: Yes - Second Level Address Translation: Yes - Data Execution Prevention Available: Yes -``` - - -如果输出如下内容，表示您的操作系统已经安装了虚拟机管理程序，您可以跳过下一步。 -``` -Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed. -``` - - -{{% /tab %}} -{{< /tabs >}} - -{{% /capture %}} - -{{% capture steps %}} - - -# 安装 minikube - -{{< tabs name="tab_with_md" >}} -{{% tab name="Linux" %}} - - -### 安装 kubectl - - -确保您已经安装了 kubectl。您可以按照[安装和配置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)的指引来安装 kubectl。 - - -### 安装虚拟机管理程序 - - -如果您没有安装虚拟机管理程序，选择如下一项进行安装： - - -• [KVM](https://www.linux-kvm.org/)，使用了 QEMU - -• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) - -{{< note >}} - -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 >}} - - -### 使用安装包安装 Minikube - - -有*试验性*的 Minikube 安装包可供使用。您可以在 GitHub 上 Minikube 的 [releases](https://github.com/kubernetes/minikube/releases)页面找到Linux (AMD64)的安装包。 - - -使用您的发布版 Linux 包工具进行安装。 - - -### 通过直接下载来安装 Minikube - - -如果您没有通过安装包进行安装，您可以下载一个独立的二进制版本使用。 - -```shell -curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \ - && chmod +x minikube -``` - - -如下是一种简单的方式将 Minikube 添加到您的执行路径中： - -```shell -sudo install minikube /usr/local/bin -``` - -{{% /tab %}} -{{% tab name="macOS" %}} - -### 安装 kubectl - - -确保您已经安装了 kubectl。您可以通过[安装和配置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)来安装 kubectl。 - - -### 安装虚拟机管理器 - - -如果您没有安装虚拟机管理器，现在就选一个安装： - -• [HyperKit](https://github.com/moby/hyperkit) - -• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) - -• [VMware Fusion](https://www.vmware.com/products/fusion) - - -### 安装Minikube - -在 macOS 上安装 Minikube 最简单的方法是使用[Homebrew](https://brew.sh)： - -```shell -brew cask install minikube -``` - - -您也可以通过下载独立二进制文件来安装在 macOS 上。 - -```shell -curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \ - && chmod +x minikube -``` - - -如下是一种简单的方式将 Minikube 添加到您的执行路径中： - -```shell -sudo mv minikube /usr/local/bin -``` - -{{% /tab %}} -{{% tab name="Windows" %}} - -安装 kubectl - - -确保您已经安装了 kubectl。您可以通过[安装和配置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)来安装 kubectl。 - - -### 安装虚拟机管理器 - - -如果您没有安装虚拟机管理器，现在就选一个安装： - -• [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 可以运行在3种版本的 Windows 10 中：Windows 10 企业版，Windows 10 专业版，Windows 10教育版。 -{{< /note >}} - - -使用 Chocolatey 安装 Minikube - - -在 Windows 上安装 Minikube 最简单的方式是使用[Chocolatey](https://chocolatey.org/) (以管理员身份运行)： - -```shell -choco install minikube -``` - - -Minikube 安装结束后，关闭命令行并重启。Minikube 应该已经添加到可执行路径中。 - - -### 使用安装器安装 Minikube - - -手动在 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)然后执行安装器。 - - -### 直接下载安装 Minikube - - -在 Windows 上手动安装 Minikube，下载[`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)，重命名为`minikube.exe`，并将其添加到执行路径中。 - -{{% /tab %}} -{{< /tabs >}} - - -{{% /capture %}} - -{{% capture whatsnext %}} - - -* [通过 Minikube 在本地运行 Kubernetes](/docs/setup/learning-environment/minikube/) - -{{% /capture %}} - - -## 清理本地状态 - - -如果您之前安装过 Minikube，运行如下命令： -```shell -minikube start -``` - - -然后这条命令会返回一个错误： -```shell -machine does not exist -``` - - -您需要清理 Minikube 的本地状态： -```shell -minikube delete -``` diff --git a/content/zh/docs/tutorials/clusters/deny-write.profile b/content/zh/docs/tutorials/clusters/deny-write.profile deleted file mode 100644 index c2653c7112..0000000000 --- a/content/zh/docs/tutorials/clusters/deny-write.profile +++ /dev/null @@ -1,10 +0,0 @@ -#include - -profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { - #include - - file, - - # Deny all file writes. - deny /** w, -} diff --git a/content/zh/docs/user-journeys/users/app-developer/advanced.md b/content/zh/docs/user-journeys/users/app-developer/advanced.md deleted file mode 100644 index 83d9ffa70d..0000000000 --- a/content/zh/docs/user-journeys/users/app-developer/advanced.md +++ /dev/null @@ -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 ---- - -{{% capture overview %}} - - -{{< note >}} -本页假设您熟悉核心 Kubernetes 概念，并且可以轻松部署自己的应用程序。如果没有，您应首先查看 {{< link text="中级应用程序开发人员" url="/docs/user-journeys/users/application-developer/intermediate/" >}}主题。 -{{< /note >}} - -在检测完当前页和它的链接部分后，您应该对以下内容有更好的了解： -* 您可以在应用程序中使用的高级功能 -* 扩展 Kubernetes API 的各种方法 - -{{% /capture %}} - - -{{% capture body %}} - - -## 用高级功能部署应用程序 - - -现在您知道了 Kubernetes 提供的一组 API 对象。理解{{< glossary_tooltip term_id="daemonset" >}}和{{< glossary_tooltip term_id="deployment" >}}之间的差异通常足以支持应用程序的部署。话虽如此，也值得熟悉 Kubernetes 鲜为人知的功能。当应用于正确的用例时，它们可以非常强大。 - - -#### 容器级功能 - - -就像你知道的那样，将整个应用程序（例如，容器化的 Rails 应用程序，MySQL 数据库和所有应用程序）迁移到单个 Pod 中是一种反模式。话虽如此，有一些非常有用的模式超出了容器和它的 pod 之间 1:1 的对应关系。 - - -* **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 容器**:*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 配置 - - -通常，您使用{{< 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" >}}（对于机密数据）。 - - -以下是一些其他鲜为人知的配置资源的方法： - - -* **污点和容忍度** -这些为节点“吸引“或”击退“你的 Pod 提供了一种方法。通常在应用程序需要部署在特殊硬件上时使用，比如用于科学计算的 GPU。{{< link text="阅读更多" url="/docs/concepts/configuration/taint-and-toleration/" >}}。 - -* **下载 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 预设** -通常，将运行时的要求安装到资源中（比如环境变量、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/" >}}。 -* - -#### 其他 API 对象 - - -{{< note >}} -在设置以下资源之前，请检查您的组织是否负责{{< glossary_tooltip text="集群 operators" term_id="cluster-operator" >}}。 -{{< /note >}} - -* **{{< 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。 - -* **联合集群对象** - 如果您在多个 Kubernetes 集群上使用*federation*运行应用程序，您需要部署标准 Kubernetes API 对象的联合版本。有关参考，请查看设置指南{{< link text="联邦 ConfigMaps" url="/docs/tasks/administer-federation/configmap/" >}} and {{< link text="联邦 Deployments" url="/docs/tasks/administer-federation/deployment/" >}}。 - - -## 扩展 Kunernetes API - - -Kubernetes 在设计时考虑了可扩展性。如果以上提到的 API 资源和功能不足以满足您的需求，可以通过各种方法自定义其行为，而无需修改核心 Kubernetes 代码。 - - -#### 了解 Kubernetes 的默认行为 - - -在进行任何自定义之前，了解 Kubernetes API 对象背后的一般抽象非常重要。尽管 Deployments 和 Secrets 可能看起来非常不同，以下概念适用于*any* 对象: - - -* **Kubernetes 对象是一种存储集群结构化数据的方法。** - -对于 Deployments，此数据表示所需的状态（例如“应运行多少个副本？”），但它也可以是常规元数据（例如数据库凭据）。 - -* **Kubernetes 对象通过{{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}}进行修改**。 - -换句话说，您可以对特定的资源路径（例如`/api/v1/namespaces/default/deployments`）发出`GET`和`POST`请求来读写相应的对象类型。 - -* **通过利用{{< link text="控制器模式" url="/docs/concepts/api-extension/custom-resources/#custom-controllers" >}}，可以使用 Kubernetes 对象来强制执行所需的状态**。为简单起见，您可以将 Controller 模式视为以下连续循环： - - -
- 1. 检查当前状态(副本数量, 容器镜像等) - 2. 比较当前状态与期望状态 - 3. 如果不匹配则更新 -
- - - 这些状态来自 Kubernetes API。 - - - {{< note >}} - 不是所有 Kubernetes 对象都需要一个 Controller。尽管 Deployment 会触发集群进行状态更改，但 ConfigMap 仅作为存储使用。 - {{< /note >}} - -#### 创建自定义资源 - - -基于以上想法，您可以定义一个新的{{< link text="自定义资源" url="/docs/concepts/api-extension/custom-resources/#custom-resources" >}}作为合理的部署。例如，如果`CronJobs`没有提供您需要的所有功能，您可能希望为定期备份定义一个`Backup`对象。 - - -设置自定义资源有两种主要方式： -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/" >}}之前。 - - -请注意，与标准的 Kubernetes 对象不同，后者依赖于内置的{{< link text="`kube-controller-manager`" url="/docs/reference/generated/kube-controller-manager/" >}}，您需要编写并运行自己的{{< link text="自定义控制器" url="https://github.com/kubernetes/sample-controller" >}}。 - - -您可能还会发现以下信息有用： -* {{< 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" >}} - - -#### 服务目录 - - -如果您想使用或提供完整的服务（而不是单个资源），**{{< 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" >}}）。 - - -如果您没有{{< 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/" >}}。 - - - -## 探索其他资源 - - -#### 参考 - - -以下主题对于构建更复杂的应用程序也很有用： - - -* {{< link text="Kubernetes 中的其他可扩展性点" url="/docs/concepts/overview/extending/" >}} - 概述您可以在何处进入 Kubernetes 架构。 -* {{< link text="Kubernetes 客户库" url="/docs/reference/using-api/client-libraries/" >}} - 用于构建需要与 Kubernetes API 进行大量交互的应用程序。 - - -#### 接下来是什么 -恭喜您完成应用程序开发者用户之旅！您已经掌握了 Kubernetes 提供的大多数功能。现在该做什么？ - - -* 如果您想推荐新功能或者了解 Kubernentes 应用程序开发的最新进展，请考虑加入{{< glossary_tooltip term_id="sig" >}}，例如{{< link text="SIG Apps" url="https://github.com/kubernetes/community/tree/master/sig-apps" >}}。 - - -* 如果您有兴趣了解 Kubernetes 的内部工作（例如网络），请考虑查看{{< link text="Cluster Operator journey" url="/docs/user-journeys/users/cluster-operator/foundational/" >}}。 - -{{% /capture %}} - -