Merge remote-tracking branch 'upstream/main' into dev-1.24
This commit is contained in:
@@ -142,7 +142,7 @@ IP 地址、网络包过滤、目标健康检查等云基础设施组件集成
|
||||
<!--
|
||||
## Authorization
|
||||
|
||||
This section breaks down the access that the cloud controller managers requires
|
||||
This section breaks down the access that the cloud controller manager requires
|
||||
on various API objects, in order to perform its operations.
|
||||
-->
|
||||
## 鉴权 {#authorization}
|
||||
|
||||
@@ -29,7 +29,7 @@ This page is an overview of Kubernetes.
|
||||
|
||||
<!-- body -->
|
||||
<!--
|
||||
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
|
||||
Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
|
||||
-->
|
||||
Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。
|
||||
Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
|
||||
|
||||
@@ -10,7 +10,7 @@ weight: 60
|
||||
<!--
|
||||
_Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/working-with-objects/kubernetes-objects) based on the value of one or more resource fields. Here are some example field selector queries:
|
||||
-->
|
||||
_字段选择器(Field selectors_)允许你根据一个或多个资源字段的值
|
||||
“字段选择器(Field selectors)”允许你根据一个或多个资源字段的值
|
||||
[筛选 Kubernetes 资源](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。
|
||||
下面是一些使用字段选择器查询的例子:
|
||||
|
||||
|
||||
@@ -231,6 +231,7 @@ partition
|
||||
* The second example selects all resources with key equal to `tier` and values other than `frontend` and `backend`, and all resources with no labels with the `tier` key.
|
||||
* The third example selects all resources including a label with key `partition`; no values are checked.
|
||||
* The fourth example selects all resources without a label with key `partition`; no values are checked.
|
||||
|
||||
Similarly the comma separator acts as an _AND_ operator. So filtering resources with a `partition` key (no matter the value) and with `environment` different than `qa` can be achieved using `partition,environment notin (qa)`.
|
||||
-->
|
||||
|
||||
@@ -238,6 +239,7 @@ Similarly the comma separator acts as an _AND_ operator. So filtering resources
|
||||
* 第二个示例选择了所有键等于 `tier` 并且值不等于 `frontend` 或者 `backend` 的资源,以及所有没有 `tier` 键标签的资源。
|
||||
* 第三个示例选择了所有包含了有 `partition` 标签的资源;没有校验它的值。
|
||||
* 第四个示例选择了所有没有 `partition` 标签的资源;没有校验它的值。
|
||||
|
||||
类似地,逗号分隔符充当 _与_ 运算符。因此,使用 `partition` 键(无论为何值)和
|
||||
`environment` 不同于 `qa` 来过滤资源可以使用 `partition, environment notin(qa)` 来实现。
|
||||
|
||||
|
||||
@@ -178,13 +178,13 @@ for the Pod. It is within this pod that the underlying container runtime will cr
|
||||
Pod 中创建容器。
|
||||
|
||||
<!--
|
||||
If the resource has a limit defined for each container (Guaranteed QoS or Bustrable QoS with limits defined),
|
||||
If the resource has a limit defined for each container (Guaranteed QoS or Burstable QoS with limits defined),
|
||||
the kubelet will set an upper limit for the pod cgroup associated with that resource (cpu.cfs_quota_us for CPU
|
||||
and memory.limit_in_bytes memory). This upper limit is based on the sum of the container limits plus the `overhead`
|
||||
defined in the PodSpec.
|
||||
-->
|
||||
如果该资源对每一个容器都定义了一个限制(定义了限制值的 Guaranteed QoS 或者
|
||||
Bustrable QoS),kubelet 会为与该资源(CPU 的 `cpu.cfs_quota_us` 以及内存的
|
||||
Burstable QoS),kubelet 会为与该资源(CPU 的 `cpu.cfs_quota_us` 以及内存的
|
||||
`memory.limit_in_bytes`)
|
||||
相关的 Pod cgroup 设定一个上限。该上限基于 PodSpec 中定义的容器限制总量与 `overhead` 之和。
|
||||
|
||||
|
||||
@@ -137,7 +137,7 @@ A minimal Ingress resource example:
|
||||
{{< codenew file="service/networking/minimal-ingress.yaml" >}}
|
||||
|
||||
<!--
|
||||
As with all other Kubernetes resources, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.
|
||||
An Ingress needs `apiVersion`, `kind`, `metadata` and `spec` fields.
|
||||
The name of an Ingress object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/).
|
||||
@@ -146,7 +146,7 @@ For general information about working with config files, see [deploying applicat
|
||||
Different [Ingress controllers](/docs/concepts/services-networking/ingress-controllers) support different annotations. Review the documentation for
|
||||
your choice of Ingress controller to learn which annotations are supported.
|
||||
-->
|
||||
与所有其他 Kubernetes 资源一样,Ingress 需要指定 `apiVersion`、`kind` 和 `metadata` 字段。
|
||||
Ingress 需要指定 `apiVersion`、`kind`、 `metadata`和 `spec` 字段。
|
||||
Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
|
||||
关于如何使用配置文件,请参见[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、
|
||||
[配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)、
|
||||
|
||||
@@ -32,6 +32,18 @@ _拓扑感知提示_ 包含客户怎么使用服务端点的建议,从而实
|
||||
|
||||
例如,你可以在一个地域内路由流量,以降低通信成本,或提高网络性能。
|
||||
|
||||
<!--
|
||||
The "topology-aware hints" feature is at Beta stage and it is **NOT** enabled
|
||||
by default. To try out this feature, you have to enable the `TopologyAwareHints`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
“拓扑感知提示”特性处于 Beta 阶段,并且默认情况下**未**启用。
|
||||
要试用此特性,你必须启用 `TopologyAwareHints`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
|
||||
@@ -70,11 +70,15 @@ To enable dynamic provisioning, a cluster administrator needs to pre-create
|
||||
one or more StorageClass objects for users.
|
||||
StorageClass objects define which provisioner should be used and what parameters
|
||||
should be passed to that provisioner when dynamic provisioning is invoked.
|
||||
The name of a StorageClass object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
The following manifest creates a storage class "slow" which provisions standard
|
||||
disk-like persistent disks.
|
||||
-->
|
||||
要启用动态供应功能,集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。
|
||||
`StorageClass` 对象定义当动态供应被调用时,哪一个驱动将被使用和哪些参数将被传递给驱动。
|
||||
StorageClass 对象的名字必须是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
|
||||
以下清单创建了一个 `StorageClass` 存储类 "slow",它提供类似标准磁盘的永久磁盘。
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -273,6 +273,21 @@ features must be enabled.
|
||||
[Azure 磁盘 CSI 驱动程序](https://github.com/kubernetes-sigs/azuredisk-csi-driver),
|
||||
并且 `CSIMigration` 和 `CSIMigrationAzureDisk` 功能必须被启用。
|
||||
|
||||
<!--
|
||||
#### azureDisk CSI migration complete
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
|
||||
To disable the `azureDisk` storage plugin from being loaded by the controller manager
|
||||
and the kubelet, set the `InTreePluginAzureDiskUnregister` flag to `true`.
|
||||
-->
|
||||
#### azureDisk CSI 迁移完成
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
|
||||
要禁止控制器管理器和 kubelet 加载 `azureDisk` 存储插件,
|
||||
请将 `InTreePluginAzureDiskUnregister` 标志设置为 `true`。
|
||||
|
||||
### azureFile {#azurefile}
|
||||
|
||||
<!--
|
||||
@@ -312,6 +327,21 @@ Azure File CSI driver does not support using same volume with different fsgroups
|
||||
Azure 文件 CSI 驱动尚不支持为同一卷设置不同的 fsgroup。
|
||||
如果 AzureFile CSI 迁移被启用,用不同的 fsgroup 来使用同一卷也是不被支持的。
|
||||
|
||||
<!--
|
||||
#### azureDisk CSI migration complete
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
|
||||
To disable the `azureDisk` storage plugin from being loaded by the controller manager
|
||||
and the kubelet, set the `InTreePluginAzureDiskUnregister` flag to `true`.
|
||||
-->
|
||||
#### azureDisk CSI 迁移完成
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
|
||||
要禁止控制器管理器和 kubelet 加载 `azureDisk` 存储插件,
|
||||
请将 `InTreePluginAzureDiskUnregister` 标志设置为 `true`。
|
||||
|
||||
### cephfs {#cephfs}
|
||||
|
||||
<!--
|
||||
|
||||
@@ -136,9 +136,9 @@ A Pod Template in a DaemonSet must have a [`RestartPolicy`](/docs/concepts/workl
|
||||
The `.spec.selector` field is a pod selector. It works the same as the `.spec.selector` of
|
||||
a [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
|
||||
|
||||
As of Kubernetes 1.8, you must specify a pod selector that matches the labels of the
|
||||
`.spec.template`. The pod selector will no longer be defaulted when left empty. Selector
|
||||
defaulting was not compatible with `kubectl apply`. Also, once a DaemonSet is created,
|
||||
You must specify a pod selector that matches the labels of the
|
||||
`.spec.template`.
|
||||
Also, once a DaemonSet is created,
|
||||
its `.spec.selector` can not be mutated. Mutating the pod selector can lead to the
|
||||
unintentional orphaning of Pods, and it was found to be confusing to users.
|
||||
-->
|
||||
@@ -147,9 +147,7 @@ unintentional orphaning of Pods, and it was found to be confusing to users.
|
||||
`.spec.selector` 字段表示 Pod 选择算符,它与
|
||||
[Job](/zh/docs/concepts/workloads/controllers/job/) 的 `.spec.selector` 的作用是相同的。
|
||||
|
||||
从 Kubernetes 1.8 开始,您必须指定与 `.spec.template` 的标签匹配的 Pod 选择算符。
|
||||
用户不指定 Pod 选择算符时,该字段不再有默认值。
|
||||
选择算符的默认值生成结果与 `kubectl apply` 不兼容。
|
||||
你必须指定与 `.spec.template` 的标签匹配的 Pod 选择算符。
|
||||
此外,一旦创建了 DaemonSet,它的 `.spec.selector` 就不能修改。
|
||||
修改 Pod 选择算符可能导致 Pod 意外悬浮,并且这对用户来说是费解的。
|
||||
|
||||
@@ -175,11 +173,11 @@ When the two are specified the result is ANDed.
|
||||
当上述两个字段都指定时,结果会按逻辑与(AND)操作处理。
|
||||
|
||||
<!--
|
||||
If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`.
|
||||
Config with these not matching will be rejected by the API.
|
||||
The `.spec.selector` must match the `.spec.template.metadata.labels`.
|
||||
Config with these two not matching will be rejected by the API.
|
||||
-->
|
||||
如果指定了 `.spec.selector`,必须与 `.spec.template.metadata.labels` 相匹配。
|
||||
如果与后者不匹配,则 DeamonSet 会被 API 拒绝。
|
||||
`.spec.selector` 必须与 `.spec.template.metadata.labels` 相匹配。
|
||||
如果配置中这两个字段不匹配,则会被 API 拒绝。
|
||||
|
||||
<!--
|
||||
### Running Pods on Only Some Nodes
|
||||
@@ -209,7 +207,7 @@ If you do not specify either, then the DaemonSet controller will create Pods on
|
||||
|
||||
### 通过默认调度器调度 {#scheduled-by-default-scheduler}
|
||||
|
||||
{{< feature-state for_kubernetes_version="1.17" state="stable" >}}
|
||||
{{< feature-state for_k8s_version="1.17" state="stable" >}}
|
||||
|
||||
<!--
|
||||
A DaemonSet ensures that all eligible nodes run a copy of a Pod. Normally, the
|
||||
|
||||
@@ -340,7 +340,7 @@ Follow the steps given below to update your Deployment:
|
||||
1. 先来更新 nginx Pod 以使用 `nginx:1.16.1` 镜像,而不是 `nginx:1.14.2` 镜像。
|
||||
|
||||
```shell
|
||||
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
|
||||
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
|
||||
```
|
||||
<!--
|
||||
or use the following command:
|
||||
|
||||
@@ -561,7 +561,7 @@ cleaned up by CronJobs based on the specified capacity-based cleanup policy.
|
||||
|
||||
### 已完成 Job 的 TTL 机制 {#ttl-mechanisms-for-finished-jobs}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
<!--
|
||||
Another way to clean up finished Jobs (either `Complete` or `Failed`)
|
||||
@@ -733,15 +733,21 @@ version of Kubernetes you're using](/docs/home/supported-doc-versions/).
|
||||
When a Job is created, the Job controller will immediately begin creating Pods
|
||||
to satisfy the Job's requirements and will continue to do so until the Job is
|
||||
complete. However, you may want to temporarily suspend a Job's execution and
|
||||
resume it later. To suspend a Job, you can update the `.spec.suspend` field of
|
||||
resume it later, or start Jobs in suspended state and have a custom controller
|
||||
decide later when to start them.
|
||||
-->
|
||||
Job 被创建时,Job 控制器会马上开始执行 Pod 创建操作以满足 Job 的需求,
|
||||
并持续执行此操作直到 Job 完成为止。
|
||||
不过你可能想要暂时挂起 Job 执行,或启动处于挂起状态的job,
|
||||
并拥有一个自定义控制器以后再决定什么时候开始。
|
||||
|
||||
<!--
|
||||
To suspend a Job, you can update the `.spec.suspend` field of
|
||||
the Job to true; later, when you want to resume it again, update it to false.
|
||||
Creating a Job with `.spec.suspend` set to true will create it in the suspended
|
||||
state.
|
||||
-->
|
||||
Job 被创建时,Job 控制器会马上开始执行 Pod 创建操作以满足 Job 的需求,
|
||||
并持续执行此操作直到 Job 完成为止。
|
||||
不过你可能想要暂时挂起 Job 执行,之后再恢复其执行。
|
||||
要挂起一个 Job,你可以将 Job 的 `.spec.suspend` 字段更新为 true。
|
||||
要挂起一个 Job,你可以更新 `.spec.suspend` 字段为 true,
|
||||
之后,当你希望恢复其执行时,将其更新为 false。
|
||||
创建一个 `.spec.suspend` 被设置为 true 的 Job 本质上会将其创建为被挂起状态。
|
||||
|
||||
@@ -858,6 +864,61 @@ as soon as the Job was resumed.
|
||||
字段值被改来改去造成的。在这两个事件之间,我们看到没有 Pod 被创建,不过当
|
||||
Job 被恢复执行时,Pod 创建操作立即被重启执行。
|
||||
|
||||
<!--
|
||||
### Mutable Scheduling Directives
|
||||
-->
|
||||
### 可变调度指令 {#mutable-scheduling-directives}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
|
||||
|
||||
<!--
|
||||
In order to use this behavior, you must enable the `JobMutableNodeSchedulingDirectives`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/).
|
||||
It is enabled by default.
|
||||
-->
|
||||
{{< note >}}
|
||||
为了使用此功能,你必须在 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)上启用
|
||||
`JobMutableNodeSchedulingDirectives` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
默认情况下启用。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
In most cases a parallel job will want the pods to run with constraints,
|
||||
like all in the same zone, or all either on GPU model x or y but not a mix of both.
|
||||
-->
|
||||
在大多数情况下,并行作业会希望 Pod 在一定约束条件下运行,
|
||||
比如所有的 Pod 都在同一个区域,或者所有的 Pod 都在 GPU 型号 x 或 y 上,而不是两者的混合。
|
||||
|
||||
<!--
|
||||
The [suspend](#suspending-a-job) field is the first step towards achieving those semantics. Suspend allows a
|
||||
custom queue controller to decide when a job should start; However, once a job is unsuspended,
|
||||
a custom queue controller has no influence on where the pods of a job will actually land.
|
||||
-->
|
||||
[suspend](#suspend-a-job) 字段是实现这些语义的第一步。
|
||||
suspend 允许自定义队列控制器,以决定工作何时开始;然而,一旦工作被取消暂停,
|
||||
自定义队列控制器对 Job 中 Pods 的实际放置位置没有影响。
|
||||
|
||||
<!--
|
||||
This feature allows updating a Job's scheduling directives before it starts, which gives custom queue
|
||||
controllers the ability to influence pod placement while at the same time offloading actual
|
||||
pod-to-node assignment to kube-scheduler. This is allowed only for suspended Jobs that have never
|
||||
been unsuspended before.
|
||||
-->
|
||||
此特性允许在 Job 开始之前更新调度指令,从而为定制队列提供影响 Pod
|
||||
放置的能力,同时将 Pod 与节点间的分配关系留给 kube-scheduler 决定。
|
||||
这一特性仅适用于之前从未被暂停过的、已暂停的 Job。
|
||||
控制器能够影响 Pod 放置,同时参考实际
|
||||
pod-to-node 分配给 kube-scheduler。这仅适用于从未暂停的 Jobs。
|
||||
|
||||
<!--
|
||||
The fields in a Job's pod template that can be updated are node affinity, node selector,
|
||||
tolerations, labels and annotations.
|
||||
-->
|
||||
Job 的 Pod 模板中可以更新的字段是节点亲和性、节点选择器、容忍、标签和注解。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
### Specifying your own Pod selector {#specifying-your-own-pod-selector}
|
||||
|
||||
@@ -964,7 +1025,7 @@ spec:
|
||||
|
||||
<!--
|
||||
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
|
||||
`manualSelector: true` tells the system that you know what you are doing and to allow this
|
||||
mismatch.
|
||||
-->
|
||||
新的 Job 自身会有一个不同于 `a8f3d00d-c6d2-11e5-9f87-42010af00002` 的唯一 ID。
|
||||
@@ -978,24 +1039,25 @@ In order to use this behavior, you must enable the `JobTrackingWithFinalizers`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/)
|
||||
and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
|
||||
It is disabled by default.
|
||||
It is enabled by default.
|
||||
|
||||
When enabled, the control plane tracks new Jobs using the behavior described
|
||||
below. Existing Jobs are unaffected. As a user, the only difference you would
|
||||
see is that the control plane tracking of Job completion is more accurate.
|
||||
below. Jobs created before the feature was enabled are unaffected. As a user,
|
||||
the only difference you would see is that the control plane tracking of Job
|
||||
completion is more accurate.
|
||||
-->
|
||||
### 使用 Finalizer 追踪 Job {#job-tracking-with-finalizers}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
|
||||
|
||||
{{< note >}}
|
||||
要使用该行为,你必须为 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
|
||||
和[控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
|
||||
启用 `JobTrackingWithFinalizers`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
默认是禁用的。
|
||||
默认是启用的。
|
||||
|
||||
启用后,控制面基于下述行为追踪新的 Job。现有 Job 不受影响。
|
||||
启用后,控制面基于下述行为追踪新的 Job。在启用该特性之前创建的 Job 不受影响。
|
||||
作为用户,你会看到的唯一区别是控制面对 Job 完成情况的跟踪更加准确。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 高级贡献
|
||||
title: 进阶贡献
|
||||
slug: advanced
|
||||
content_type: concept
|
||||
weight: 98
|
||||
|
||||
@@ -15,7 +15,7 @@ weight: 15
|
||||
|
||||
<!--
|
||||
This guide shows you how to create, edit and share diagrams using the Mermaid
|
||||
Javascript library. Mermaid.js allows you to generate diagrams using a simple
|
||||
JavaScript library. Mermaid.js allows you to generate diagrams using a simple
|
||||
markdown-like syntax inside Markdown files. You can also use Mermaid to
|
||||
generate `.svg` or `.png` image files that you can add to your documentation.
|
||||
|
||||
@@ -24,7 +24,7 @@ and/or how to create and add diagrams to Kubernetes documentation.
|
||||
|
||||
Figure 1 outlines the topics covered in this section.
|
||||
-->
|
||||
本指南为你展示如何创建、编辑和分享基于 Mermaid Javascript 库的图表。
|
||||
本指南为你展示如何创建、编辑和分享基于 Mermaid JavaScript 库的图表。
|
||||
Mermaid.js 允许你使用简单的、类似于 Markdown 的语法来在 Markdown 文件中生成图表。
|
||||
你也可以使用 Mermaid 来创建 `.svg` 或 `.png` 图片文件,将其添加到你的文档中。
|
||||
|
||||
|
||||
@@ -9,10 +9,14 @@ content_type: concept
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!-- This page explains the custom Hugo shortcodes that can be used in Kubernetes Markdown documentation. -->
|
||||
<!--
|
||||
This page explains the custom Hugo shortcodes that can be used in Kubernetes Markdown documentation.
|
||||
-->
|
||||
本页面将介绍 Hugo 自定义短代码,可以用于 Kubernetes Markdown 文档书写。
|
||||
|
||||
<!-- Read more about shortcodes in the [Hugo documentation](https://gohugo.io/content-management/shortcodes). -->
|
||||
<!--
|
||||
Read more about shortcodes in the [Hugo documentation](https://gohugo.io/content-management/shortcodes).
|
||||
-->
|
||||
关于短代码的更多信息可参见 [Hugo 文档](https://gohugo.io/content-management/shortcodes)。
|
||||
|
||||
<!-- body -->
|
||||
@@ -20,18 +24,18 @@ content_type: concept
|
||||
<!--
|
||||
## Feature state
|
||||
|
||||
In a Markdown page (.md file) on this site, you can add a shortcode to display
|
||||
version and state of the documented feature.
|
||||
In a Markdown page (`.md` file) on this site, you can add a shortcode to
|
||||
display version and state of the documented feature.
|
||||
-->
|
||||
## 功能状态
|
||||
|
||||
在本站的 Markdown 页面中,你可以加入短代码来展示所描述的功能特性的版本和状态。
|
||||
在本站的 Markdown 页面(`.md` 文件)中,你可以加入短代码来展示所描述的功能特性的版本和状态。
|
||||
|
||||
<!--
|
||||
### Feature state demo
|
||||
|
||||
Below is a demo of the feature state snippet, which displays the feature as stable
|
||||
in the latest Kubernetes version.
|
||||
Below is a demo of the feature state snippet, which displays the feature as
|
||||
stable in the latest Kubernetes version.
|
||||
-->
|
||||
### 功能状态示例
|
||||
|
||||
@@ -41,12 +45,16 @@ in the latest Kubernetes version.
|
||||
{{</* feature-state state="stable" */>}}
|
||||
```
|
||||
|
||||
<!-- Renders to: -->
|
||||
<!--
|
||||
Renders to:
|
||||
-->
|
||||
会转换为:
|
||||
|
||||
{{< feature-state state="stable" >}}
|
||||
|
||||
<!-- The valid values for `state` are: -->
|
||||
<!--
|
||||
The valid values for `state` are:
|
||||
-->
|
||||
`state` 的可选值如下:
|
||||
|
||||
* alpha
|
||||
@@ -69,7 +77,9 @@ feature state version by passing the `for_k8s_version` shortcode parameter. For
|
||||
{{</* feature-state for_k8s_version="v1.10" state="beta" */>}}
|
||||
```
|
||||
|
||||
<!-- Renders to: -->
|
||||
<!--
|
||||
Renders to:
|
||||
-->
|
||||
会转换为:
|
||||
|
||||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
@@ -78,10 +88,10 @@ feature state version by passing the `for_k8s_version` shortcode parameter. For
|
||||
## Glossary
|
||||
There are two glossary shortcodes: `glossary_tooltip` and `glossary_definition`.
|
||||
|
||||
You can reference glossary terms with an inclusion that will automatically
|
||||
update and replace content with the relevant links from [our
|
||||
glossary](/docs/reference/glossary/). When the glossary term is moused-over,
|
||||
the glossary entry displays a tooltip. The glossary term also displays as a link.
|
||||
You can reference glossary terms with an inclusion that automatically updates
|
||||
and replaces content with the relevant links from [our glossary](/docs/reference/glossary/).
|
||||
When the glossary term is moused-over, the glossary entry displays a tooltip.
|
||||
The glossary term also displays as a link.
|
||||
|
||||
As well as inclusions with tooltips, you can reuse the definitions from the glossary in
|
||||
page content.
|
||||
@@ -96,21 +106,24 @@ page content.
|
||||
|
||||
除了包含工具提示外,你还可以重用页面内容中词汇表中的定义。
|
||||
<!--
|
||||
The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary), with a content file for each glossary term.
|
||||
The raw data for glossary terms is stored at
|
||||
[the glossary directory](https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary),
|
||||
with a content file for each glossary term.
|
||||
-->
|
||||
|
||||
词汇术语的原始数据保存在 [https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary),每个内容文件对应相应的术语解释。
|
||||
词汇术语的原始数据保存在[词汇目录](https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary),
|
||||
每个内容文件对应相应的术语解释。
|
||||
|
||||
<!--
|
||||
### Glossary demo
|
||||
|
||||
For example, the following include within the Markdown will render to
|
||||
For example, the following include within the Markdown renders to
|
||||
{{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip:
|
||||
-->
|
||||
### 词汇演示
|
||||
|
||||
例如,下面的代码在 Markdown 中将会转换为 `{{< glossary_tooltip text="cluster" term_id="cluster" >}}`,
|
||||
然后在提示框中显示。
|
||||
例如下面的代码在 Markdown 中将会转换为
|
||||
{{< glossary_tooltip text="cluster" term_id="cluster" >}},然后在提示框中显示。
|
||||
|
||||
```
|
||||
{{</* glossary_tooltip text="cluster" term_id="cluster" */>}}
|
||||
@@ -146,10 +159,68 @@ which renders as:
|
||||
呈现为:
|
||||
{{< glossary_definition term_id="cluster" length="all" >}}
|
||||
|
||||
<!--
|
||||
## Links to API Reference
|
||||
-->
|
||||
## 链接至 API 参考 {#links-to-api-reference}
|
||||
|
||||
<!--
|
||||
You can link to a page of the Kubernetes API reference using the
|
||||
`api-reference` shortcode, for example to the
|
||||
{{< api-reference page="workload-resources/pod-v1" >}} reference:
|
||||
-->
|
||||
你可以使用 `api-reference` 短代码链接到 Kubernetes API 参考页面,例如
|
||||
Pod
|
||||
{{< api-reference page="workload-resources/pod-v1" >}} 参考文件:
|
||||
|
||||
```
|
||||
{{</* api-reference page="workload-resources/pod-v1" */>}}
|
||||
```
|
||||
|
||||
<!--
|
||||
The content of the `page` parameter is the suffix of the URL of the API reference page.
|
||||
-->
|
||||
本语句中 `page` 参数的内容是 API 参考页面的 URL 后缀。
|
||||
|
||||
|
||||
<!--
|
||||
You can link to a specific place into a page by specifying an `anchor`
|
||||
parameter, for example to the {{< api-reference page="workload-resources/pod-v1" anchor="PodSpec" >}}
|
||||
reference or the {{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" >}}
|
||||
section of the page:
|
||||
-->
|
||||
你可以通过指定 `anchor` 参数链接到页面中的特定位置,例如到
|
||||
{{< api-reference page="workload-resources/pod-v1" anchor="PodSpec" >}} 参考,或页面的
|
||||
{{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" >}}
|
||||
部分。
|
||||
|
||||
```
|
||||
{{</* api-reference page="workload-resources/pod-v1" anchor="PodSpec" */>}}
|
||||
{{</* api-reference page="workload-resources/pod-v1" anchor="environment-variables" */>}}
|
||||
```
|
||||
|
||||
|
||||
<!--
|
||||
You can change the text of the link by specifying a `text` parameter, for
|
||||
example by linking to the
|
||||
{{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" text="Environment Variables">}}
|
||||
section of the page:
|
||||
-->
|
||||
你可以通过指定 `text` 参数来更改链接的文本,例如通过链接到页面的
|
||||
{{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" text="环境变量">}}
|
||||
部分:
|
||||
|
||||
```
|
||||
{{</* api-reference page="workload-resources/pod-v1" anchor="environment-variables" text="环境变量" */>}}
|
||||
```
|
||||
|
||||
|
||||
<!--
|
||||
## Table captions
|
||||
|
||||
You can make tables more accessible to screen readers by adding a table caption. To add a [caption](https://www.w3schools.com/tags/tag_caption.asp) to a table, enclose the table with a `table` shortcode and specify the caption with the `caption` parameter.
|
||||
You can make tables more accessible to screen readers by adding a table caption. To add a
|
||||
[caption](https://www.w3schools.com/tags/tag_caption.asp) to a table,
|
||||
enclose the table with a `table` shortcode and specify the caption with the `caption` parameter.
|
||||
|
||||
{{< note >}}
|
||||
Table captions are visible to screen readers but invisible when viewed in standard HTML.
|
||||
@@ -205,7 +276,8 @@ Parameter | Description | Default
|
||||
{{< /table >}}
|
||||
|
||||
<!--
|
||||
If you inspect the HTML for the table, you should see this element immediately after the opening `<table>` element:
|
||||
If you inspect the HTML for the table, you should see this element immediately
|
||||
after the opening `<table>` element:
|
||||
|
||||
```html
|
||||
<caption style="display: none;">Configuration parameters</caption>
|
||||
@@ -235,8 +307,17 @@ The `tabs` shortcode takes these parameters:
|
||||
|
||||
<!--
|
||||
* `name`: The name as shown on the tab.
|
||||
* `codelang`: If you provide inner content to the `tab` shortcode, you can tell Hugo what code language to use for highlighting.
|
||||
* `include`: The file to include in the tab. If the tab lives in a Hugo [leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles), the file -- which can be any MIME type supported by Hugo -- will be looked up in the bundle itself. If not, the content page to include will be looked up relative to the current. Note that with the `include` you will not have any shortcode inner content and must use the self-closing syntax, e.g. {{</* tab name="Content File #1" include="example1" /*/>}}. Non-content files will be code-highlighted. The language to use will be taken from the filename if not provided in `codelang`.
|
||||
* `codelang`: If you provide inner content to the `tab` shortcode, you can tell Hugo
|
||||
what code language to use for highlighting.
|
||||
* `include`: The file to include in the tab. If the tab lives in a Hugo
|
||||
[leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles),
|
||||
the file -- which can be any MIME type supported by Hugo -- is looked up in the bundle itself.
|
||||
If not, the content page that needs to be included is looked up relative to the current page.
|
||||
Note that with the `include`, you do not have any shortcode inner content and must use the
|
||||
self-closing syntax. For example,
|
||||
`{{</* tab name="Content File #1" include="example1" /*/>}}`. The language needs to be specified
|
||||
under `codelang` or the language is taken based on the file name.
|
||||
Non-content files are code-highlighted by default.
|
||||
-->
|
||||
* `name`: 标签页上显示的名字。
|
||||
* `codelang`: 如果要在 `tab` 短代码中加入内部内容,需要告知 Hugo 使用的是什么代码语言,方便代码高亮。
|
||||
@@ -245,10 +326,12 @@ The `tabs` shortcode takes these parameters:
|
||||
Hugo 会在包内查找文件(可以是 Hugo 所支持的任何 MIME 类型文件)。
|
||||
否则,Hugo 会在当前路径的相对路径下查找所要包含的内容页面。
|
||||
注意,在 `include` 页面中不能包含短代码内容,必须要使用自结束(self-closing)语法。
|
||||
非内容文件将会被代码高亮。
|
||||
例如 `{{</* tab name="Content File #1" include="example1" /*/>}}`。
|
||||
如果没有在 `codelang` 进行声明的话,Hugo 会根据文件名推测所用的语言。
|
||||
默认情况下,非内容文件将会被代码高亮。
|
||||
<!--
|
||||
* If your inner content is markdown, you must use `%`-delimiter to surorund the tab, e.g. `{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}`
|
||||
* If your inner content is markdown, you must use the `%`-delimiter to surround the tab.
|
||||
For example, `{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}`
|
||||
* You can combine the variations mentioned above inside a tab set.
|
||||
-->
|
||||
* 如果内部内容是 Markdown,你必须要使用 `%` 分隔符来包装标签页。
|
||||
@@ -282,7 +365,9 @@ println "This is tab 2."
|
||||
{{< /tabs */>}}
|
||||
```
|
||||
|
||||
<!-- Will be rendered as: -->
|
||||
<!--
|
||||
Renders to:
|
||||
-->
|
||||
会转换为:
|
||||
|
||||
{{< tabs name="tab_with_code" >}}
|
||||
@@ -294,41 +379,51 @@ println "This is tab 2."
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!-- ### Tabs demo: Inline Markdown and HTML -->
|
||||
<!--
|
||||
### Tabs demo: Inline Markdown and HTML
|
||||
-->
|
||||
### 标签页演示:内联 Markdown 和 HTML
|
||||
|
||||
```go-html-template
|
||||
{{</* tabs name="tab_with_md" >}}
|
||||
{{% tab name="Markdown" %}}
|
||||
这是 **一些 markdown 。**
|
||||
{{< note >}}它甚至可以包含短代码。{{< /note >}}
|
||||
这是 **一些 markdown。**
|
||||
{{< note >}}
|
||||
它甚至可以包含短代码。
|
||||
{{< /note >}}
|
||||
{{% /tab %}}
|
||||
{{< tab name="HTML" >}}
|
||||
<div>
|
||||
<h3>纯 HTML</h3>
|
||||
<p>这是一些 <i>纯</i> HTML 。</p>
|
||||
<p>这是一些 <i>纯</i> HTML。</p>
|
||||
</div>
|
||||
{{< /tab >}}
|
||||
{{< /tabs */>}}
|
||||
```
|
||||
|
||||
<!-- Will be rendered as: -->
|
||||
<!--
|
||||
Renders to:
|
||||
-->
|
||||
会转换为:
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="Markdown" %}}
|
||||
这是 **一些 markdown 。**
|
||||
{{< note >}}它甚至可以包含短代码。{{< /note >}}
|
||||
这是 **一些 markdown。**
|
||||
{{< note >}}
|
||||
它甚至可以包含短代码。
|
||||
{{< /note >}}
|
||||
{{% /tab %}}
|
||||
{{< tab name="HTML" >}}
|
||||
<div>
|
||||
<h3>纯 HTML</h3>
|
||||
<p>这是一些 <i>纯</i> HTML 。</p>
|
||||
<p>这是一些 <i>纯</i> HTML。</p>
|
||||
</div>
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!-- ### Tabs demo: File include -->
|
||||
<!--
|
||||
### Tabs demo: File include
|
||||
-->
|
||||
### 标签页演示:文件嵌套
|
||||
|
||||
```go-text-template
|
||||
@@ -339,7 +434,9 @@ println "This is tab 2."
|
||||
{{< /tabs */>}}
|
||||
```
|
||||
|
||||
<!-- Will be rendered as: -->
|
||||
<!--
|
||||
Renders to:
|
||||
-->
|
||||
会转换为:
|
||||
|
||||
{{< tabs name="tab_with_file_include" >}}
|
||||
@@ -348,6 +445,78 @@ println "This is tab 2."
|
||||
{{< tab name="JSON File" include="podtemplate.json" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
## Third party content marker
|
||||
-->
|
||||
## 第三方内容标记 {#third-party-content-marker}
|
||||
|
||||
<!--
|
||||
Running Kubernetes requires third-party software. For example: you
|
||||
usually need to add a
|
||||
[DNS server](/docs/tasks/administer-cluster/dns-custom-nameservers/#introduction)
|
||||
to your cluster so that name resolution works.
|
||||
-->
|
||||
运行 Kubernetes 需要第三方软件。例如:你通常需要将
|
||||
[DNS 服务器](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#introduction)
|
||||
添加到集群中,以便名称解析工作。
|
||||
|
||||
<!--
|
||||
When we link to third-party software, or otherwise mention it,
|
||||
we follow the [content guide](/docs/contribute/style/content-guide/)
|
||||
and we also mark those third party items.
|
||||
-->
|
||||
当我们链接到第三方软件或以其他方式提及它时,我们会遵循[内容指南](/zh/docs/contribute/style/content-guide/)
|
||||
并标记这些第三方项目。
|
||||
|
||||
<!--
|
||||
Using these shortcodes adds a disclaimer to any documentation page
|
||||
that uses them.
|
||||
-->
|
||||
使用这些短代码会向使用它们的任何文档页面添加免责声明。
|
||||
|
||||
<!--
|
||||
### Lists {#third-party-content-list}
|
||||
-->
|
||||
### 列表 {#third-party-content-list}
|
||||
|
||||
<!--
|
||||
For a list of several third-party items, add:
|
||||
-->
|
||||
对于有关几个第三方项目的列表,请添加:
|
||||
```
|
||||
{{%/* thirdparty-content */%}}
|
||||
```
|
||||
<!--
|
||||
just below the heading for the section that includes all items.
|
||||
-->
|
||||
在包含所有项目的段落标题正下方。
|
||||
|
||||
<!--
|
||||
### Items {#third-party-content-item}
|
||||
-->
|
||||
### 项目 {#third-party-content-item}
|
||||
|
||||
<!--
|
||||
If you have a list where most of the items refer to in-project
|
||||
software (for example: Kubernetes itself, and the separate
|
||||
[Descheduler](https://github.com/kubernetes-sigs/descheduler)
|
||||
component), then there is a different form to use.
|
||||
-->
|
||||
如果你有一个列表,其中大多数项目引用项目内软件(例如:Kubernetes 本身,以及单独的
|
||||
[Descheduler](https://github.com/kubernetes-sigs/descheduler)
|
||||
组件),那么可以使用不同的形式。
|
||||
|
||||
<!--
|
||||
Add the shortcode:
|
||||
|
||||
before the item, or just below the heading for the specific item.
|
||||
-->
|
||||
在项目之前,或在特定项目的段落下方添加此短代码:
|
||||
```
|
||||
{{%/* thirdparty-content single="true" */%}}
|
||||
```
|
||||
|
||||
|
||||
<!--
|
||||
## Version strings
|
||||
|
||||
@@ -364,9 +533,10 @@ The two most commonly used version parameters are `latest` and `version`.
|
||||
<!--
|
||||
### `{{</* param "version" */>}}`
|
||||
|
||||
The `{{</* param "version" */>}}` shortcode generates the value of the current version of
|
||||
the Kubernetes documentation from the `version` site parameter. The `param` shortcode accepts
|
||||
the name of one site parameter, in this case: `version`.
|
||||
The `{{</* param "version" */>}}` shortcode generates the value of the current
|
||||
version of the Kubernetes documentation from the `version` site parameter. The
|
||||
`param` shortcode accepts the name of one site parameter, in this case:
|
||||
`version`.
|
||||
-->
|
||||
### `{{</* param "version" */>}}`
|
||||
|
||||
@@ -375,10 +545,11 @@ the name of one site parameter, in this case: `version`.
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
In previously released documentation, `latest` and `version` parameter values are not equivalent.
|
||||
After a new version is released, `latest` is incremented and the value of `version` for the
|
||||
documentation set remains unchanged. For example, a previously released version of the
|
||||
documentation displays `version` as `v1.19` and `latest` as `v1.20`.
|
||||
In previously released documentation, `latest` and `version` parameter values
|
||||
are not equivalent. After a new version is released, `latest` is incremented
|
||||
and the value of `version` for the documentation set remains unchanged. For
|
||||
example, a previously released version of the documentation displays `version`
|
||||
as `v1.19` and `latest` as `v1.20`.
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
@@ -415,7 +586,8 @@ Renders to:
|
||||
<!--
|
||||
### `{{</* latest-semver */>}}`
|
||||
|
||||
The `{{</* latest-semver */>}}` shortcode generates the value of `latest` without the "v" prefix.
|
||||
The `{{</* latest-semver */>}}` shortcode generates the value of `latest`
|
||||
without the "v" prefix.
|
||||
|
||||
Renders to:
|
||||
-->
|
||||
@@ -432,7 +604,7 @@ Renders to:
|
||||
|
||||
The `{{</* version-check */>}}` shortcode checks if the `min-kubernetes-server-version`
|
||||
page parameter is present and then uses this value to compare to `version`.
|
||||
|
||||
|
||||
Renders to:
|
||||
-->
|
||||
### `{{</* version-check */>}}`
|
||||
@@ -447,9 +619,9 @@ Renders to:
|
||||
<!--
|
||||
### `{{</* latest-release-notes */>}}`
|
||||
|
||||
The `{{</* latest-release-notes */>}}` shortcode generates a version string from `latest` and removes
|
||||
the "v" prefix. The shortcode prints a new URL for the release note CHANGELOG page with the modified
|
||||
version string.
|
||||
The `{{</* latest-release-notes */>}}` shortcode generates a version string
|
||||
from `latest` and removes the "v" prefix. The shortcode prints a new URL for
|
||||
the release note CHANGELOG page with the modified version string.
|
||||
|
||||
Renders to:
|
||||
-->
|
||||
@@ -466,14 +638,14 @@ Renders to:
|
||||
|
||||
<!--
|
||||
* Learn about [Hugo](https://gohugo.io/).
|
||||
* Learn about [writing a new topic](/docs/home/contribute/style/write-new-topic/).
|
||||
* Learn about [page content types](/docs/home/contribute/style/page-content-types/).
|
||||
* Learn about [creating a pull request](/docs/contribute/new-content/open-a-pr/).
|
||||
* Learn about [writing a new topic](/docs/contribute/style/write-new-topic/).
|
||||
* Learn about [page content types](/docs/contribute/style/page-content-types/).
|
||||
* Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/).
|
||||
* Learn about [advanced contributing](/docs/contribute/advanced/).
|
||||
-->
|
||||
|
||||
* 了解[Hugo](https://gohugo.io/)。
|
||||
* 了解 [Hugo](https://gohugo.io/)。
|
||||
* 了解[撰写新的话题](/zh/docs/contribute/style/write-new-topic/)。
|
||||
* 了解[使用页面内容类型](/zh/docs/contribute/style/page-content-types/)。
|
||||
* 了解[发起 PR](/zh/docs/contribute/new-content/open-a-pr/)。
|
||||
* 了解[高级贡献](/zh/docs/contribute/advanced/)。
|
||||
* 了解[进阶贡献](/zh/docs/contribute/advanced/)。
|
||||
|
||||
@@ -42,8 +42,8 @@ This section of the Kubernetes documentation contains references.
|
||||
|
||||
* [术语表](/zh/docs/reference/glossary/) - 一个全面的标准化的 Kubernetes 术语表
|
||||
|
||||
* [Kubernetes API 单页参考](/zh/docs/reference/kubernetes-api/)
|
||||
* [Kubernetes API 参考 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。
|
||||
* [Kubernetes API 参考](/zh/docs/reference/kubernetes-api/)
|
||||
* [Kubernetes API 单页参考 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。
|
||||
* [使用 Kubernetes API ](/zh/docs/reference/using-api/) - Kubernetes 的 API 概述
|
||||
* [API 的访问控制](/zh/docs/reference/access-authn-authz/) - 关于 Kubernetes 如何控制 API 访问的详细信息
|
||||
* [常见的标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)
|
||||
|
||||
@@ -52,13 +52,13 @@ properties:
|
||||
- `group`, type string; if you specify `group`, it must match one of the groups of the authenticated user. `system:authenticated` matches all authenticated requests. `system:unauthenticated` matches all unauthenticated requests.
|
||||
- Resource-matching properties:
|
||||
- `apiGroup`, type string; an API group.
|
||||
- Ex: `extensions`
|
||||
- Ex: `apps`, `networking.k8s.io`
|
||||
- Wildcard: `*` matches all API groups.
|
||||
- `namespace`, type string; a namespace.
|
||||
- Ex: `kube-system`
|
||||
- Wildcard: `*` matches all resource requests.
|
||||
- `resource`, type string; a resource type
|
||||
- Ex: `pods`
|
||||
- Ex: `pods`, `deployments`
|
||||
- Wildcard: `*` matches all resource requests.
|
||||
- Non-resource-matching properties:
|
||||
- `nonResourcePath`, type string; non-resource request paths.
|
||||
@@ -86,13 +86,13 @@ properties:
|
||||
- `group`,字符串类型;如果指定 `group`,它必须与经过身份验证的用户的一个组匹配,`system:authenticated`匹配所有经过身份验证的请求。`system:unauthenticated`匹配所有未经过身份验证的请求。
|
||||
- 资源匹配属性:
|
||||
- `apiGroup`,字符串类型;一个 API 组。
|
||||
- 例: `extensions`
|
||||
- 例: `apps`, `networking.k8s.io`
|
||||
- 通配符:`*`匹配所有 API 组。
|
||||
- `namespace`,字符串类型;一个命名空间。
|
||||
- 例如:`kube-system`
|
||||
- 通配符:`*`匹配所有资源请求。
|
||||
- `resource`,字符串类型;资源类型。
|
||||
- 例:`pods`
|
||||
- 例:`pods`, `deployments`
|
||||
- 通配符:`*`匹配所有资源请求。
|
||||
- 非资源匹配属性:
|
||||
- `nonResourcePath`,字符串类型;非资源请求路径。
|
||||
|
||||
@@ -574,23 +574,23 @@ rules:
|
||||
|
||||
<!--
|
||||
Allow reading/writing Deployments (at the HTTP level: objects with `"deployments"`
|
||||
in the resource part of their URL) in both the `"extensions"` and `"apps"` API groups:
|
||||
in the resource part of their URL) in the `"apps"` API groups:
|
||||
-->
|
||||
允许读/写在 "extensions" 和 "apps" API 组中的 Deployment(在 HTTP 层面,对应
|
||||
允许读/写在 `"apps"` API 组中的 Deployment(在 HTTP 层面,对应
|
||||
URL 中资源部分为 "deployments"):
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups: ["extensions", "apps"]
|
||||
- apiGroups: ["apps"]
|
||||
resources: ["deployments"]
|
||||
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
|
||||
```
|
||||
|
||||
<!--
|
||||
Allow reading Pods in the core API group, as well as reading or writing Job
|
||||
resources in the `"batch"` or `"extensions"` API groups:
|
||||
resources in the `"batch"` API group:
|
||||
-->
|
||||
允许读取核心 API 组中的 "pods" 和读/写 `"batch"` 或 `"extensions"` API 组中的
|
||||
允许读取核心 API 组中的 "pods" 和读/写 `"batch"` API 组中的
|
||||
"jobs":
|
||||
|
||||
```yaml
|
||||
@@ -598,7 +598,7 @@ rules:
|
||||
- apiGroups: [""]
|
||||
resources: ["pods"]
|
||||
verbs: ["get", "list", "watch"]
|
||||
- apiGroups: ["batch", "extensions"]
|
||||
- apiGroups: ["batch"]
|
||||
resources: ["jobs"]
|
||||
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
|
||||
```
|
||||
@@ -758,9 +758,9 @@ subjects:
|
||||
```
|
||||
|
||||
<!--
|
||||
For all service accounts in the "qa" group in any namespace:
|
||||
For all service accounts in the "qa" namespace:
|
||||
-->
|
||||
对于任何名称空间中的 "qa" 组中所有的服务账户:
|
||||
对于 "qa" 名称空间中的所有服务账户:
|
||||
|
||||
```yaml
|
||||
subjects:
|
||||
@@ -769,19 +769,6 @@ subjects:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
|
||||
<!--
|
||||
For all service accounts in the "dev" group in the "development" namespace:
|
||||
-->
|
||||
对于 "development" 名称空间中 "dev" 组中的所有服务帐户:
|
||||
|
||||
```yaml
|
||||
subjects:
|
||||
- kind: Group
|
||||
name: system:serviceaccounts:dev
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
namespace: development
|
||||
```
|
||||
|
||||
<!--
|
||||
For all service accounts in any namespace:
|
||||
-->
|
||||
|
||||
@@ -111,7 +111,8 @@ different Kubernetes components.
|
||||
| `AllowInsecureBackendProxy` | `true` | Beta | 1.17 | |
|
||||
| `AnyVolumeDataSource` | `false` | Alpha | 1.18 | |
|
||||
| `AppArmor` | `true` | Beta | 1.4 | |
|
||||
| `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | |
|
||||
| `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | 1.21 |
|
||||
| `ControllerManagerLeaderMigration` | `true` | Beta | 1.22 | |
|
||||
| `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
|
||||
| `CPUManager` | `true` | Beta | 1.10 | |
|
||||
| `CPUManagerPolicyAlphaOptions` | `false` | Alpha | 1.23 | |
|
||||
@@ -485,6 +486,7 @@ different Kubernetes components.
|
||||
| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
|
||||
| `ServerSideApply` | `true` | Beta | 1.16 | 1.21 |
|
||||
| `ServerSideApply` | `true` | GA | 1.22 | - |
|
||||
| `ServerSideFieldValidation` | `false` | Alpha | 1.23 | - |
|
||||
| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | 1.19 |
|
||||
| `ServiceAccountIssuerDiscovery` | `true` | Beta | 1.20 | 1.20 |
|
||||
| `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - |
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -38,10 +38,21 @@ You can request eviction either by directly calling the Eviction API
|
||||
using a client of the kube-apiserver, like the `kubectl drain` command.
|
||||
When an `Eviction` object is created, the API server terminates the Pod.
|
||||
|
||||
API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/)
|
||||
and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination).
|
||||
|
||||
API-initiated eviction is not the same as [node-pressure eviction](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction).
|
||||
-->
|
||||
你可以通过 kube-apiserver 的客户端,比如 `kubectl drain` 这样的命令,直接调用 Eviction API 发起驱逐。
|
||||
当 `Eviction` 对象创建出来之后,该对象将驱动 API 服务器终止选定的Pod。
|
||||
|
||||
API 发起的驱逐取决于你配置的 [`PodDisruptionBudgets`](/zh/docs/tasks/run-application/configure-pdb/)
|
||||
和 [`terminationGracePeriodSeconds`](/zh/docs/concepts/workloads/pods/pod-lifecycle#pod-termination)。
|
||||
|
||||
API 发起的驱逐不同于
|
||||
[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)。
|
||||
|
||||
<!--
|
||||
* See [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/) for more information.
|
||||
-->
|
||||
* 有关详细信息,请参阅 [API 发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/)。
|
||||
@@ -17,7 +17,7 @@ id: cadvisor
|
||||
date: 2021-12-09
|
||||
full_link: https://github.com/google/cadvisor/
|
||||
short_description: >
|
||||
Tool that provides understanding of the resource usage and perfomance characteristics for containers
|
||||
Tool that provides understanding of the resource usage and performance characteristics for containers
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: 混排切片(Shuffle Sharding)
|
||||
id: shuffle-sharding
|
||||
id: shuffle sharding
|
||||
date: 2020-03-04
|
||||
full_link:
|
||||
short_description: >
|
||||
@@ -40,8 +40,8 @@ We are often concerned with insulating different flows of requests
|
||||
from each other, so that a high-intensity flow does not crowd out low-intensity flows.
|
||||
A simple way to put requests into queues is to hash some
|
||||
characteristics of the request, modulo the number of queues, to get
|
||||
the index of the queue to use. The hash function uses as input
|
||||
characteristics of the request that align with flows. For example, in
|
||||
the index of the queue to use. The hash function uses as input
|
||||
characteristics of the request that align with flows. For example, in
|
||||
the Internet this is often the 5-tuple of source and destination
|
||||
address, protocol, and source and destination port.
|
||||
-->
|
||||
@@ -57,21 +57,21 @@ address, protocol, and source and destination port.
|
||||
That simple hash-based scheme has the property that any high-intensity flow
|
||||
will crowd out all the low-intensity flows that hash to the same queue.
|
||||
Providing good insulation for a large number of flows requires a large
|
||||
number of queues, which is problematic. Shuffle sharding is a more
|
||||
number of queues, which is problematic. Shuffle sharding is a more
|
||||
nimble technique that can do a better job of insulating the low-intensity
|
||||
flows from the high-intensity flows. The terminology of shuffle sharding uses
|
||||
flows from the high-intensity flows. The terminology of shuffle sharding uses
|
||||
the metaphor of dealing a hand from a deck of cards; each queue is a
|
||||
metaphorical card. The shuffle sharding technique starts with hashing
|
||||
metaphorical card. The shuffle sharding technique starts with hashing
|
||||
the flow-identifying characteristics of the request, to produce a hash
|
||||
value with dozens or more of bits. Then the hash value is used as a
|
||||
value with dozens or more of bits. Then the hash value is used as a
|
||||
source of entropy to shuffle the deck and deal a hand of cards
|
||||
(queues). All the dealt queues are examined, and the request is put
|
||||
into one of the examined queues with the shortest length. With a
|
||||
(queues). All the dealt queues are examined, and the request is put
|
||||
into one of the examined queues with the shortest length. With a
|
||||
modest hand size, it does not cost much to examine all the dealt cards
|
||||
and a given low-intensity flow has a good chance to dodge the effects of a
|
||||
given high-intensity flow. With a large hand size it is expensive to examine
|
||||
given high-intensity flow. With a large hand size it is expensive to examine
|
||||
the dealt queues and more difficult for the low-intensity flows to dodge the
|
||||
collective effects of a set of high-intensity flows. Thus, the hand size
|
||||
collective effects of a set of high-intensity flows. Thus, the hand size
|
||||
should be chosen judiciously.
|
||||
-->
|
||||
这种简单的基于哈希的模式有一种特性,高密度的请求序列(流)会湮没那些被
|
||||
|
||||
@@ -0,0 +1,222 @@
|
||||
---
|
||||
api_metadata:
|
||||
apiVersion: "authentication.k8s.io/v1"
|
||||
import: "k8s.io/api/authentication/v1"
|
||||
kind: "TokenReview"
|
||||
content_type: "api_reference"
|
||||
description: "TokenReview 尝试通过验证令牌来确认已知用户。"
|
||||
title: "TokenReview"
|
||||
weight: 3
|
||||
auto_generated: true
|
||||
---
|
||||
|
||||
<!--
|
||||
api_metadata:
|
||||
apiVersion: "authentication.k8s.io/v1"
|
||||
import: "k8s.io/api/authentication/v1"
|
||||
kind: "TokenReview"
|
||||
content_type: "api_reference"
|
||||
description: "TokenReview attempts to authenticate a token to a known user."
|
||||
title: "TokenReview"
|
||||
weight: 3
|
||||
auto_generated: true
|
||||
-->
|
||||
|
||||
`apiVersion: authentication.k8s.io/v1`
|
||||
|
||||
`import "k8s.io/api/authentication/v1"`
|
||||
|
||||
<!--
|
||||
## TokenReview {#TokenReview}
|
||||
TokenReview attempts to authenticate a token to a known user. Note: TokenReview requests may be cached by the webhook token authenticator plugin in the kube-apiserver.
|
||||
-->
|
||||
## TokenReview {#TokenReview}
|
||||
|
||||
TokenReview 尝试通过验证令牌来确认已知用户。
|
||||
注意:TokenReview 请求可能会被 kube-apiserver 中的 webhook 令牌验证器插件缓存。
|
||||
|
||||
<hr>
|
||||
|
||||
- **apiVersion**: authentication.k8s.io/v1
|
||||
|
||||
|
||||
- **kind**: TokenReview
|
||||
|
||||
|
||||
- **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta</a>)
|
||||
|
||||
<!--
|
||||
Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
|
||||
-->
|
||||
标准对象的元数据,更多信息:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
|
||||
|
||||
- **spec** (<a href="{{< ref "../authentication-resources/token-review-v1#TokenReviewSpec" >}}">TokenReviewSpec</a>), required
|
||||
|
||||
<!--
|
||||
Spec holds information about the request being evaluated
|
||||
-->
|
||||
spec 保存有关正在评估的请求的信息
|
||||
|
||||
- **status** (<a href="{{< ref "../authentication-resources/token-review-v1#TokenReviewStatus" >}}">TokenReviewStatus</a>)
|
||||
|
||||
<!--
|
||||
Status is filled in by the server and indicates whether the request can be authenticated.
|
||||
-->
|
||||
status 由服务器填写,指示请求是否可以通过身份验证。
|
||||
|
||||
|
||||
## TokenReviewSpec {#TokenReviewSpec}
|
||||
|
||||
<!--
|
||||
TokenReviewSpec is a description of the token authentication request.
|
||||
-->
|
||||
TokenReviewPec 是对令牌身份验证请求的描述。
|
||||
|
||||
<hr>
|
||||
|
||||
- **audiences** ([]string)
|
||||
|
||||
<!--
|
||||
Audiences is a list of the identifiers that the resource server presented with the token identifies as. Audience-aware token authenticators will verify that the token was intended for at least one of the audiences in this list. If no audiences are provided, the audience will default to the audience of the Kubernetes apiserver.
|
||||
-->
|
||||
audiences 是带有令牌的资源服务器标识为受众的标识符列表。
|
||||
受众感知令牌身份验证器将验证令牌是否适用于此列表中的至少一个受众。
|
||||
如果未提供受众,受众将默认为 Kubernetes API 服务器的受众。
|
||||
|
||||
- **token** (string)
|
||||
|
||||
<!--
|
||||
Token is the opaque bearer token.
|
||||
-->
|
||||
token 是不透明的持有者令牌(Bearer Token)。
|
||||
|
||||
## TokenReviewStatus {#TokenReviewStatus}
|
||||
|
||||
<!--
|
||||
TokenReviewStatus is the result of the token authentication request.
|
||||
-->
|
||||
TokenReviewStatus 是令牌认证请求的结果。
|
||||
|
||||
<hr>
|
||||
|
||||
- **audiences** ([]string)
|
||||
|
||||
<!--
|
||||
Audiences are audience identifiers chosen by the authenticator that are compatible with both the TokenReview and token. An identifier is any identifier in the intersection of the TokenReviewSpec audiences and the token's audiences. A client of the TokenReview API that sets the spec.audiences field should validate that a compatible audience identifier is returned in the status.audiences field to ensure that the TokenReview server is audience aware. If a TokenReview returns an empty status.audience field where status.authenticated is "true", the token is valid against the audience of the Kubernetes API server.
|
||||
-->
|
||||
audiences 是身份验证者选择的与 TokenReview 和令牌兼容的受众标识符。 标识符是
|
||||
TokenReviewSpec 受众和令牌受众的交集中的任何标识符。 设置 spec.audiences
|
||||
字段的 TokenReview API 的客户端应验证在 status.audiences 字段中返回了兼容的受众标识符,
|
||||
以确保 TokenReview 服务器能够识别受众。 如果 TokenReview
|
||||
返回一个空的 status.audience 字段,其中 status.authenticated 为 “true”,
|
||||
则该令牌对 Kubernetes API 服务器的受众有效。
|
||||
|
||||
- **authenticated** (boolean)
|
||||
<!--
|
||||
Authenticated indicates that the token was associated with a known user.
|
||||
-->
|
||||
authenticated 表示令牌与已知用户相关联。
|
||||
|
||||
- **error** (string)
|
||||
|
||||
<!--
|
||||
Error indicates that the token couldn't be checked
|
||||
-->
|
||||
error 表示无法检查令牌
|
||||
|
||||
- **user** (UserInfo)
|
||||
|
||||
<!--
|
||||
User is the UserInfo associated with the provided token.
|
||||
-->
|
||||
user 是与提供的令牌关联的 UserInfo。
|
||||
|
||||
<a name="UserInfo"></a>
|
||||
<--
|
||||
*UserInfo holds the information about the user needed to implement the user.Info interface.*
|
||||
-->
|
||||
**UserInfo 保存实现 user.Info 接口所需的用户信息**
|
||||
|
||||
- **user.extra** (map[string][]string)
|
||||
|
||||
<!--
|
||||
Any additional information provided by the authenticator.
|
||||
-->
|
||||
验证者提供的任何附加信息。
|
||||
|
||||
- **user.groups** ([]string)
|
||||
|
||||
<!--
|
||||
The names of groups this user is a part of.
|
||||
-->
|
||||
此用户所属的组的名称。
|
||||
|
||||
- **user.uid** (string)
|
||||
|
||||
<!--
|
||||
A unique value that identifies this user across time. If this user is deleted and another user by the same name is added, they will have different UIDs.
|
||||
-->
|
||||
跨时间标识此用户的唯一值。如果删除此用户并添加另一个同名用户,他们将拥有不同的 UID。
|
||||
|
||||
- **user.username** (string)
|
||||
|
||||
<!--
|
||||
The name that uniquely identifies this user among all active users.
|
||||
-->
|
||||
在所有活动用户中唯一标识此用户的名称。
|
||||
|
||||
<!--
|
||||
## Operations {#Operations}
|
||||
-->
|
||||
## 操作 {#Operations}
|
||||
|
||||
<hr>
|
||||
|
||||
<!--
|
||||
### `create` create a TokenReview
|
||||
|
||||
#### HTTP Request
|
||||
-->
|
||||
### `create` 创建一个TokenReview
|
||||
|
||||
#### HTTP 请求
|
||||
|
||||
POST /apis/authentication.k8s.io/v1/tokenreviews
|
||||
|
||||
<!--
|
||||
#### Parameters
|
||||
- **body**: <a href="{{< ref "../authentication-resources/token-review-v1#TokenReview" >}}">TokenReview</a>, required
|
||||
-->
|
||||
#### 参数
|
||||
|
||||
- **body**: <a href="{{< ref "../authentication-resources/token-review-v1#TokenReview" >}}">TokenReview</a>, 必需
|
||||
|
||||
- **dryRun** (*in query*): string
|
||||
|
||||
<a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun</a>
|
||||
|
||||
- **fieldManager** (*in query*): string
|
||||
|
||||
<a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
|
||||
|
||||
- **fieldValidation** (*in query*): string
|
||||
|
||||
<a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
|
||||
|
||||
- **pretty** (*in query*): string
|
||||
|
||||
<a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
|
||||
|
||||
<!--
|
||||
#### Response
|
||||
-->
|
||||
#### 响应
|
||||
|
||||
200 (<a href="{{< ref "../authentication-resources/token-review-v1#TokenReview" >}}">TokenReview</a>): OK
|
||||
|
||||
201 (<a href="{{< ref "../authentication-resources/token-review-v1#TokenReview" >}}">TokenReview</a>): Created
|
||||
|
||||
202 (<a href="{{< ref "../authentication-resources/token-review-v1#TokenReview" >}}">TokenReview</a>): Accepted
|
||||
|
||||
401: Unauthorized
|
||||
|
||||
@@ -26,15 +26,151 @@ Kubernetes 将所有标签和注解保留在 kubernetes.io Namespace中。
|
||||
<!--
|
||||
## Labels, annotations and taints used on API objects
|
||||
|
||||
### app.kubernetes.io/component
|
||||
|
||||
Example: `app.kubernetes.io/component=database`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The component within the architecture.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
-->
|
||||
## API 对象上使用的标签、注解和污点
|
||||
|
||||
### app.kubernetes.io/component
|
||||
|
||||
例子: `app.kubernetes.io/component=database`
|
||||
|
||||
用于: 所有对象
|
||||
|
||||
架构中的组件。
|
||||
|
||||
[推荐标签](/zh/docs/concepts/overview/working-with-objects/common-labels/#labels)之一。
|
||||
|
||||
<!-- ### app.kubernetes.io/created-by
|
||||
|
||||
Example: `app.kubernetes.io/created-by=controller-manager`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The controller/user who created this resource.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). -->
|
||||
### app.kubernetes.io/created-by
|
||||
|
||||
示例:`app.kubernetes.io/created-by=controller-manager`
|
||||
|
||||
用于:所有对象
|
||||
|
||||
创建此资源的控制器/用户。
|
||||
|
||||
[推荐标签](/zh/docs/concepts/overview/working-with-objects/common-labels/#labels)之一。
|
||||
|
||||
<!-- ### app.kubernetes.io/instance
|
||||
|
||||
Example: `app.kubernetes.io/instance=mysql-abcxzy`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
A unique name identifying the instance of an application.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). -->
|
||||
### app.kubernetes.io/instance
|
||||
|
||||
示例:`app.kubernetes.io/instance=mysql-abcxzy`
|
||||
|
||||
用于:所有对象
|
||||
|
||||
标识应用实例的唯一名称。
|
||||
|
||||
[推荐标签](/zh/docs/concepts/overview/working-with-objects/common-labels/#labels)之一。
|
||||
|
||||
<!-- ### app.kubernetes.io/managed-by
|
||||
|
||||
Example: `app.kubernetes.io/managed-by=helm`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The tool being used to manage the operation of an application.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). -->
|
||||
### app.kubernetes.io/managed-by
|
||||
|
||||
示例:`app.kubernetes.io/managed-by=helm`
|
||||
|
||||
用于:所有对象
|
||||
|
||||
用于管理应用操作的工具。
|
||||
|
||||
[推荐标签](/zh/docs/concepts/overview/working-with-objects/common-labels/#labels)之一。
|
||||
|
||||
<!-- ### app.kubernetes.io/name
|
||||
|
||||
Example: `app.kubernetes.io/name=mysql`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The name of the application.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). -->
|
||||
|
||||
### app.kubernetes.io/name
|
||||
|
||||
示例:`app.kubernetes.io/name=mysql`
|
||||
|
||||
用于:所有对象
|
||||
|
||||
应用的名称。
|
||||
|
||||
[推荐标签](/zh/docs/concepts/overview/working-with-objects/common-labels/#labels)之一。
|
||||
|
||||
<!-- ### app.kubernetes.io/part-of
|
||||
|
||||
Example: `app.kubernetes.io/part-of=wordpress`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The name of a higher level application this one is part of.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). -->
|
||||
### app.kubernetes.io/part-of
|
||||
|
||||
示例:`app.kubernetes.io/part-of=wordpress`
|
||||
|
||||
用于:所有对象
|
||||
|
||||
此应用所属的更高级别应用的名称。
|
||||
|
||||
[推荐标签](/zh/docs/concepts/overview/working-with-objects/common-labels/#labels)之一。
|
||||
|
||||
<!-- ### app.kubernetes.io/version
|
||||
|
||||
Example: `app.kubernetes.io/version="5.7.21"`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The current version of the application (e.g., a semantic version, revision hash, etc.).
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). -->
|
||||
### app.kubernetes.io/version
|
||||
|
||||
示例:`app.kubernetes.io/version="5.7.21"`
|
||||
|
||||
用于:所有对象
|
||||
|
||||
应用的当前版本(例如,语义版本、修订哈希等)。
|
||||
|
||||
[推荐标签](/zh/docs/concepts/overview/working-with-objects/common-labels/#labels)之一。
|
||||
|
||||
<!--
|
||||
### kubernetes.io/arch
|
||||
|
||||
Example: `kubernetes.io/arch=amd64`
|
||||
|
||||
Used on: Node
|
||||
|
||||
The Kubelet populates this with `runtime.GOARCH` as defined by Go. This can be handy if you are mixing arm and x86 nodes.
|
||||
-->
|
||||
## API 对象上使用的标签、注解和污点
|
||||
The Kubelet populates this with `runtime.GOARCH` as defined by Go. This can be handy if you are mixing arm and x86 nodes. -->
|
||||
|
||||
### kubernetes.io/arch {#kubernetes-io-arch}
|
||||
|
||||
@@ -185,8 +321,6 @@ Used on: Pod
|
||||
|
||||
This annotation is used to set [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)
|
||||
which allows users to influence ReplicaSet downscaling order. The annotation parses into an `int32` type.
|
||||
|
||||
### beta.kubernetes.io/instance-type (deprecated)
|
||||
-->
|
||||
### controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost}
|
||||
|
||||
@@ -194,8 +328,85 @@ which allows users to influence ReplicaSet downscaling order. The annotation par
|
||||
|
||||
用于:Pod
|
||||
|
||||
该注解用于设置 [Pod 删除成本](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost) 允许用户影响 ReplicaSet 缩减顺序。注解解析为 `int32` 类型。
|
||||
该注解用于设置 [Pod 删除成本](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)允许用户影响 ReplicaSet 缩减顺序。注解解析为 `int32` 类型。
|
||||
|
||||
<!--
|
||||
### kubernetes.io/ingress-bandwidth
|
||||
|
||||
Ingress traffic shaping annotation is an experimental feature.
|
||||
If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI configuration file (default `/etc/cni/net.d`) and
|
||||
ensure that the binary is included in your CNI bin dir (default `/opt/cni/bin`).
|
||||
|
||||
Example: `kubernetes.io/ingress-bandwidth: 10M`
|
||||
|
||||
Used on: Pod
|
||||
|
||||
You can apply quality-of-service traffic shaping to a pod and effectively limit its available bandwidth.
|
||||
Ingress traffic (to the pod) is handled by shaping queued packets to effectively handle data.
|
||||
To limit the bandwidth on a pod, write an object definition JSON file and specify the data traffic
|
||||
speed using `kubernetes.io/ingress-bandwidth` annotation. The unit used for specifying ingress
|
||||
rate is bits per second, as a [Quantity](/docs/reference/kubernetes-api/common-definitions/quantity/).
|
||||
For example, `10M` means 10 megabits per second.
|
||||
-->
|
||||
|
||||
### kubernetes.io/ingress-bandwidth
|
||||
|
||||
{{< note >}}
|
||||
入站流量控制注解是一项实验性功能。
|
||||
如果要启用流量控制支持,必须将`bandwidth`插件添加到 CNI 配置文件(默认为`/etc/cni/net.d`)
|
||||
并确保二进制文件包含在你的 CNI bin 目录中(默认为`/opt/cni/bin`)。
|
||||
{{< /note >}}
|
||||
|
||||
示例:`kubernetes.io/ingress-bandwidth: 10M`
|
||||
|
||||
用于:Pod
|
||||
|
||||
你可以对 Pod 应用服务质量流量控制并有效限制其可用带宽。
|
||||
入站流量(到 Pod)通过控制排队的数据包来处理,以有效地处理数据。
|
||||
要限制 Pod 的带宽,请编写对象定义 JSON 文件并使用 `kubernetes.io/ingress-bandwidth`
|
||||
注解指定数据流量速度。 用于指定入站的速率单位是每秒,
|
||||
作为[量纲(Quantity)](/zh/docs/reference/kubernetes-api/common-definitions/quantity/)。
|
||||
例如,`10M`表示每秒 10 兆比特。
|
||||
|
||||
<!--
|
||||
### kubernetes.io/egress-bandwidth
|
||||
|
||||
Egress traffic shaping annotation is an experimental feature.
|
||||
If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI configuration file (default `/etc/cni/net.d`) and
|
||||
ensure that the binary is included in your CNI bin dir (default `/opt/cni/bin`).
|
||||
|
||||
Example: `kubernetes.io/egress-bandwidth: 10M`
|
||||
|
||||
Used on: Pod
|
||||
|
||||
Egress traffic (from the pod) is handled by policing, which simply drops packets in excess of the configured rate.
|
||||
The limits you place on a pod do not affect the bandwidth of other pods.
|
||||
To limit the bandwidth on a pod, write an object definition JSON file and specify the data traffic
|
||||
speed using `kubernetes.io/egress-bandwidth` annotation. The unit used for specifying egress
|
||||
rate is bits per second, as a [Quantity](/docs/reference/kubernetes-api/common-definitions/quantity/).
|
||||
For example, `10M` means 10 megabits per second.
|
||||
-->
|
||||
|
||||
### kubernetes.io/egress-bandwidth
|
||||
|
||||
{{< note >}}
|
||||
出站流量控制注解是一项实验性功能。
|
||||
如果要启用流量控制支持,必须将`bandwidth`插件添加到 CNI 配置文件(默认为`/etc/cni/net.d`)
|
||||
并确保二进制文件包含在你的 CNI bin 目录中(默认为`/opt/cni/bin`)。
|
||||
{{< /note >}}
|
||||
|
||||
示例:`kubernetes.io/egress-bandwidth: 10M`
|
||||
|
||||
用于:Pod
|
||||
|
||||
出站流量(来自 pod)由策略控制,策略只是丢弃超过配置速率的数据包。
|
||||
你为一个 Pod 所设置的限制不会影响其他 Pod 的带宽。
|
||||
要限制 Pod 的带宽,请编写对象定义 JSON 文件并使用 `kubernetes.io/egress-bandwidth` 注解指定数据流量速度。
|
||||
用于指定出站的速率单位是每秒比特数,
|
||||
以[量纲(Quantity)](/zh/docs/reference/kubernetes-api/common-definitions/quantity/)的形式给出。
|
||||
例如,`10M` 表示每秒 10 兆比特。
|
||||
|
||||
<!-- ### beta.kubernetes.io/instance-type (deprecated) -->
|
||||
### beta.kubernetes.io/instance-type (已弃用) {#beta-kubernetes-io-instance-type}
|
||||
|
||||
<!--
|
||||
@@ -1025,16 +1236,20 @@ seccomp 配置文件应用于 Pod 或其容器的步骤。
|
||||
<!--
|
||||
## Annotations used for audit
|
||||
|
||||
- [`pod-security.kubernetes.io/exempt`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
|
||||
- [`pod-security.kubernetes.io/enforce-policy`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
|
||||
- [`authorization.k8s.io/decision`](/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-decision)
|
||||
- [`authorization.k8s.io/reason`](/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-reason)
|
||||
- [`pod-security.kubernetes.io/audit-violations`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations)
|
||||
- [`pod-security.kubernetes.io/enforce-policy`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
|
||||
- [`pod-security.kubernetes.io/exempt`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
|
||||
|
||||
See more details on the [Audit Annotations](/docs/reference/labels-annotations-taints/audit-annotations/) page.
|
||||
-->
|
||||
## 用于审计的注解 {#annonations-used-for-audit}
|
||||
|
||||
- [`pod-security.kubernetes.io/exempt`](/zh/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
|
||||
- [`pod-security.kubernetes.io/enforce-policy`](/zh/zh/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
|
||||
- [`authorization.k8s.io/decision`](/zh/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-decision)
|
||||
- [`authorization.k8s.io/reason`](/zh/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-reason)
|
||||
- [`pod-security.kubernetes.io/audit-violations`](/zh/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations)
|
||||
- [`pod-security.kubernetes.io/enforce-policy`](/zh/zh/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
|
||||
- [`pod-security.kubernetes.io/exempt`](/zh/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
|
||||
|
||||
在[审计注解](/zh/docs/reference/labels-annotations-taints/audit-annotations/)页面上查看更多详细信息。
|
||||
@@ -21,10 +21,10 @@ Print configuration
|
||||
|
||||
<!--
|
||||
This command prints configurations for subcommands provided.
|
||||
For details, see: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
|
||||
For details, see: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories
|
||||
-->
|
||||
此命令打印子命令所提供的配置信息。
|
||||
相关细节可参阅 https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
|
||||
相关细节可参阅: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories
|
||||
|
||||
```
|
||||
kubeadm config print [flags]
|
||||
|
||||
@@ -594,7 +594,7 @@ API 服务器的静态 Pod 清单会受到用户提供的以下参数的影响:
|
||||
#### 控制器管理器 {#controller-manager}
|
||||
|
||||
<!--
|
||||
The static Pod manifest for the controller-manager is affected by following parameters provided by the users:
|
||||
The static Pod manifest for the controller manager is affected by following parameters provided by the users:
|
||||
-->
|
||||
控制器管理器的静态 Pod 清单受用户提供的以下参数的影响:
|
||||
|
||||
|
||||
@@ -43,20 +43,6 @@ Using this phase you can execute preflight checks on a node that is being reset.
|
||||
{{< tab name="preflight" include="generated/kubeadm_reset_phase_preflight.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
## kubeadm reset phase update-cluster-status
|
||||
-->
|
||||
## kubeadm reset phase update-cluster-status {#cmd-reset-phase-update-cluster-status}
|
||||
|
||||
<!--
|
||||
Using this phase you can remove this control-plane node from the ClusterStatus object.
|
||||
-->
|
||||
使用此阶段,你可以从 ClusterStatus 对象中删除此控制平面节点。
|
||||
|
||||
{{< tabs name="tab-update-cluster-status" >}}
|
||||
{{< tab name="update-cluster-status" include="generated/kubeadm_reset_phase_update-cluster-status.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
<!--
|
||||
## kubeadm reset phase remove-etcd-member
|
||||
-->
|
||||
|
||||
@@ -142,37 +142,41 @@ might have to add an equivalent field or represent it as an annotation.
|
||||
添加一个新的等效字段或者将其表现为一个注解。
|
||||
|
||||
<!--
|
||||
**Rule #3: An API version in a given track may not be deprecated until a new
|
||||
API version at least as stable is released.**
|
||||
**Rule #3: An API version in a given track may not be deprecated in favor of a less stable API version.**
|
||||
|
||||
GA API versions can replace GA API versions as well as beta and alpha API
|
||||
versions. Beta API versions *may not* replace GA API versions.
|
||||
* GA API versions can replace beta and alpha API versions.
|
||||
* Beta API versions can replace earlier beta and alpha API versions, but *may not* replace GA API versions.
|
||||
* Alpha API versions can replace earlier alpha API versions, but *may not* replace GA or beta API versions.
|
||||
-->
|
||||
**规则 #3:给定类别的 API 版本在新的、稳定性未降低的 API 版本发布之前不可被废弃。**
|
||||
**规则 #3:给定类别的 API 版本不可被弃用以支持稳定性更差的 API 版本。**
|
||||
|
||||
一个正式发布的(GA)API 版本可替换现有的正式 API 版本或 alpha、beta API 版本。
|
||||
Beta API 版本 *不可以* 替代正式的 API 版本。
|
||||
* 一个正式发布的(GA)API 版本可替换 beta 或 alpha API 版本。
|
||||
* Beta API 版本可以替换早期的 beta 和 alpha API 版本,但 **不可以** 替换正式的 API 版本。
|
||||
* Alpha API 版本可以替换早期的 alpha API 版本,但 **不可以** 替换正式的或 beta API 版本。
|
||||
|
||||
<!--
|
||||
**Rule #4a: Other than the most recent API versions in each track, older API
|
||||
versions must be supported after their announced deprecation for a duration of
|
||||
no less than:**
|
||||
**Rule #4a: minimum API lifetime is determined by the API stability level**
|
||||
|
||||
* **GA: 12 months or 3 releases (whichever is longer)**
|
||||
* **Beta: 9 months or 3 releases (whichever is longer)**
|
||||
* **Alpha: 0 releases**
|
||||
* **GA API versions may be marked as deprecated, but must not be removed within a major version of Kubernetes**
|
||||
* **Beta API versions must be supported for 9 months or 3 releases (whichever is longer) after deprecation**
|
||||
* **Alpha API versions may be removed in any release without prior deprecation notice**
|
||||
|
||||
This covers the [maximum supported version skew of 2 releases](/docs/setup/release/version-skew-policy/).
|
||||
This ensures beta API support covers the [maximum supported version skew of 2 releases](/releases/version-skew-policy/).
|
||||
-->
|
||||
**规则 #4a:除了每类 API 版本中的最新版本,旧的 API 版本在其被宣布被废弃之后
|
||||
至少以下时长内仍需被支持:**
|
||||
**规则 #4a:最短 API 生命周期由 API 稳定性级别决定**
|
||||
|
||||
* **GA:12 个月或者 3 个发布版本(取其较长者)**
|
||||
* **Beta: 9 个月或者 3 个发布版本(取其较长者)**
|
||||
* **Alpha: 0 个发布版本**
|
||||
* **GA API 版本可以被标记为已弃用,但不得在 Kubernetes 的主要版本中删除**
|
||||
* **Beta API 版本必须支持 9 个月或弃用后的 3 个版本(以较长者为准)**
|
||||
* **Alpha API 版本可能会在任何版本中被删除,不另行通知**
|
||||
|
||||
这里也包含了关于[最大支持 2 个发布版本的版本偏差](/zh/docs/setup/release/version-skew-policy/)
|
||||
的约定。
|
||||
这确保了 beta API 支持涵盖了[最多 2 个版本的支持版本偏差](/zh/releases/version-skew-policy/)。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
There are no current plans for a major version revision of Kubernetes that removes GA APIs.
|
||||
-->
|
||||
目前没有删除正式版本 API 的 Kubernetes 主要版本修订计划。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is
|
||||
@@ -363,9 +367,9 @@ API versions are supported in a series of subsequent releases.
|
||||
<td>
|
||||
<ul>
|
||||
<!-- li>v2beta2 is deprecated, "action required" relnote</li>
|
||||
<li>v1 is deprecated, "action required" relnote</li -->
|
||||
<li>v1 is deprecated in favor of v2, but will not be removed</li -->
|
||||
<li>v2beta2 已被弃用,发布说明中包含对应的 "action required(采取行动)" 说明</li>
|
||||
<li>v1 已被弃用,发布说明中包含对应的 "action required(采取行动)" 说明</li>
|
||||
<li>v1 已被弃用,取而代之的是 v2,但不会被删除</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
@@ -400,23 +404,6 @@ API versions are supported in a series of subsequent releases.
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>X+16</td>
|
||||
<!-- td>v2, v1 (deprecated)</td -->
|
||||
<td>v2、v1(已弃用)</td>
|
||||
<td>v2</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>X+17</td>
|
||||
<td>v2</td>
|
||||
<td>v2</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li>v1 被删除,发布说明中包含对应的 "action required(采取行动)" 说明</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ weight: 50
|
||||
---
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Options for Highly Available topology
|
||||
title: Options for Highly Available Topology
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
@@ -27,7 +27,6 @@ For information on how to create a cluster with kubeadm once you have performed
|
||||
有关在执行此安装过程后如何使用 kubeadm 创建集群的信息,请参见
|
||||
[使用 kubeadm 创建集群](/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 页面。
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
@@ -78,7 +78,7 @@ by the kubelet, using the `--cluster-dns` flag. This setting needs to be the sam
|
||||
on every manager and Node in the cluster. The kubelet provides a versioned, structured API object
|
||||
that can configure most parameters in the kubelet and push out this configuration to each running
|
||||
kubelet in the cluster. This object is called
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/).
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/).
|
||||
The `KubeletConfiguration` allows the user to specify flags such as the cluster DNS IP addresses expressed as
|
||||
a list of values to a camelCased key, illustrated by the following example:
|
||||
|
||||
@@ -186,7 +186,7 @@ for more information on the individual fields.
|
||||
通过调用 `kubeadm config print init-defaults --component-configs KubeletConfiguration`,
|
||||
你可以看到此结构中的所有默认值。
|
||||
|
||||
也可以阅读 [KubeletConfiguration 参考](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
也可以阅读 [KubeletConfiguration 参考](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
来获取有关各个字段的更多信息。
|
||||
|
||||
<!--
|
||||
@@ -308,10 +308,15 @@ It augments the basic
|
||||
[`kubelet.service` for RPM](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service) or
|
||||
[`kubelet.service` for DEB](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service):
|
||||
|
||||
{{< note >}}
|
||||
The contents below are just an example. If you don't want to use a package manager
|
||||
follow the guide outlined in the [Without a package manager](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#k8s-install-2))
|
||||
section.
|
||||
{{< /note >}}
|
||||
|
||||
```none
|
||||
[Service]
|
||||
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
|
||||
--kubeconfig=/etc/kubernetes/kubelet.conf"
|
||||
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
|
||||
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
|
||||
# This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating
|
||||
the KUBELET_KUBEADM_ARGS variable dynamically
|
||||
@@ -347,10 +352,15 @@ This file specifies the default locations for all of the files managed by kubead
|
||||
或者 [DEB 版本 `kubelet.service`](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service)
|
||||
作了增强:
|
||||
|
||||
{{< note >}}
|
||||
下面的内容只是一个例子。 如果您不想使用包管理器,
|
||||
请遵循[没有包管理器](/zh/docs/setup/productionenvironment/tools/kubeadm/install-kubeadm/#k8s-install-2))
|
||||
部分中叙述的指南。
|
||||
{{< /note >}}
|
||||
|
||||
```none
|
||||
[Service]
|
||||
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
|
||||
--kubeconfig=/etc/kubernetes/kubelet.conf"
|
||||
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
|
||||
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
|
||||
# 这是 "kubeadm init" 和 "kubeadm join" 运行时生成的文件,动态地填充 KUBELET_KUBEADM_ARGS 变量
|
||||
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
|
||||
@@ -381,9 +391,10 @@ The DEB and RPM packages shipped with the Kubernetes releases are:
|
||||
| Package name | Description |
|
||||
|----------------|-------------|
|
||||
| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
|
||||
| `kubelet` | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. |
|
||||
| `kubelet` | Installs the `/usr/bin/kubelet` binary. |
|
||||
| `kubectl` | Installs the `/usr/bin/kubectl` binary. |
|
||||
| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-sigs/cri-tools). |
|
||||
| `kubernetes-cni` | Installs the `/opt/cni/bin` binaries from the [plugins git repository](https://github.com/containernetworking/plugins). |
|
||||
-->
|
||||
## Kubernetes 可执行文件和软件包内容
|
||||
|
||||
@@ -392,7 +403,8 @@ Kubernetes 版本对应的 DEB 和 RPM 软件包是:
|
||||
| Package name | Description |
|
||||
|--------------|-------------|
|
||||
| `kubeadm` | 给 kubelet 安装 `/usr/bin/kubeadm` CLI 工具和 [kubelet 的 systemd 文件](#the-kubelet-drop-in-file-for-systemd)。 |
|
||||
| `kubelet` | 安装 kubelet 可执行文件到 `/usr/bin` 路径,安装 CNI 可执行文件到 `/opt/cni/bin` 路径。 |
|
||||
| `kubelet` | 安装 `/usr/bin/kubelet` 可执行文件。 |
|
||||
| `kubectl` | 安装 `/usr/bin/kubectl` 可执行文件。 |
|
||||
| `cri-tools` | 从 [cri-tools git 仓库](https://github.com/kubernetes-sigs/cri-tools)中安装 `/usr/bin/crictl` 可执行文件。 |
|
||||
| `kubernetes-cni` | 从 [plugins git 仓库](https://github.com/containernetworking/plugins)中安装 `/opt/cni/bin` 可执行文件。|
|
||||
|
||||
|
||||
+3
-4
@@ -187,7 +187,7 @@ URL 的 `<service_name>` 段支持的格式为:
|
||||
-->
|
||||
##### 示例
|
||||
|
||||
* 如要访问 Elasticsearch 服务末端 `_search?q=user:kimchy`,你可以使用:
|
||||
* 如要访问 Elasticsearch 服务末端 `_search?q=user:kimchy`,你可以使用:
|
||||
|
||||
```
|
||||
http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
|
||||
@@ -199,7 +199,7 @@ URL 的 `<service_name>` 段支持的格式为:
|
||||
* 如要访问 Elasticsearch 集群健康信息`_cluster/health?pretty=true`,你会使用:
|
||||
|
||||
```
|
||||
https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
|
||||
https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -246,8 +246,7 @@ You may be able to put an apiserver proxy URL into the address bar of a browser.
|
||||
- Some web apps may not work, particularly those with client side javascript that construct URLs in a
|
||||
way that is unaware of the proxy path prefix.
|
||||
-->
|
||||
- Web 服务器通常不能传递令牌,所以你可能需要使用基本(密码)认证。
|
||||
- Web 服务器通常不能传递令牌,所以你可能需要使用基本(密码)认证。
|
||||
API 服务器可以配置为接受基本认证,但你的集群可能并没有这样配置。
|
||||
- 某些 Web 应用可能无法工作,特别是那些使用客户端 Javascript 构造 URL 的
|
||||
应用,所构造的 URL 可能并不支持代理路径前缀。
|
||||
|
||||
@@ -316,82 +316,32 @@ Python 客户端可以像 kubectl CLI 一样使用相同的
|
||||
## Accessing the API from a Pod
|
||||
|
||||
When accessing the API from a pod, locating and authenticating
|
||||
to the apiserver are somewhat different.
|
||||
|
||||
The recommended way to locate the apiserver within the pod is with
|
||||
the `kubernetes.default.svc` DNS name, which resolves to a Service IP which in turn
|
||||
will be routed to an apiserver.
|
||||
|
||||
The recommended way to authenticate to the apiserver is with a
|
||||
[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By kube-system, a pod
|
||||
is associated with a service account, and a credential (token) for that
|
||||
service account is placed into the filesystem tree of each container in that pod,
|
||||
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
|
||||
to the API server are somewhat different.
|
||||
-->
|
||||
### 从 Pod 中访问 API {#accessing-the-api-from-a-pod}
|
||||
|
||||
当你从 Pod 中访问 API 时,定位和验证 apiserver 会有些许不同。
|
||||
|
||||
在 Pod 中定位 apiserver 的推荐方式是通过 `kubernetes.default.svc`
|
||||
这个 DNS 名称,该名称将会解析为服务 IP,然后服务 IP 将会路由到 apiserver。
|
||||
|
||||
向 apiserver 进行身份验证的推荐方法是使用
|
||||
[服务帐户](/zh/docs/tasks/configure-pod-container/configure-service-account/) 凭据。
|
||||
通过 kube-system,Pod 与服务帐户相关联,并且该服务帐户的凭证(token)
|
||||
被放置在该 Pod 中每个容器的文件系统中,位于
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/token`。
|
||||
当你从 Pod 中访问 API 时,定位和验证 API 服务器会有些许不同。
|
||||
|
||||
<!--
|
||||
If available, a certificate bundle is placed into the filesystem tree of each
|
||||
container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
|
||||
used to verify the serving certificate of the apiserver.
|
||||
|
||||
Finally, the default namespace to be used for namespaced API operations is placed in a file
|
||||
at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
|
||||
Please check [Accessing the API from within a Pod](/docs/tasks/run-application/access-api-from-pod/)
|
||||
for more details.
|
||||
-->
|
||||
如果可用,则将证书放入每个容器的文件系统中的
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`,
|
||||
并且应该用于验证 apiserver 的服务证书。
|
||||
|
||||
最后,名字空间作用域的 API 操作所使用的 default 名字空间将被放置在
|
||||
每个容器的 `/var/run/secrets/kubernetes.io/serviceaccount/namespace`
|
||||
文件中。
|
||||
|
||||
<!--
|
||||
From within a pod the recommended ways to connect to API are:
|
||||
|
||||
- run `kubectl proxy` in a sidecar container in the pod, or as a background
|
||||
process within the container. This proxies the
|
||||
Kubernetes API to the localhost interface of the pod, so that other processes
|
||||
in any container of the pod can access it.
|
||||
- use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
|
||||
They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
|
||||
|
||||
In each case, the credentials of the pod are used to communicate securely with the apiserver.
|
||||
-->
|
||||
在 Pod 中,建议连接 API 的方法是:
|
||||
|
||||
- 在 Pod 的边车容器中运行 `kubectl proxy`,或者以后台进程的形式运行。
|
||||
这将把 Kubernetes API 代理到当前 Pod 的 localhost 接口,
|
||||
所以 Pod 中的所有容器中的进程都能访问它。
|
||||
- 使用 Go 客户端库,并使用 `rest.InClusterConfig()` 和
|
||||
`kubernetes.NewForConfig()` 函数创建一个客户端。
|
||||
他们处理 apiserver 的定位和身份验证。
|
||||
[示例](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
|
||||
|
||||
在每种情况下,Pod 的凭证都是为了与 apiserver 安全地通信。
|
||||
请参阅[从 Pod 中访问 API](/zh/docs/tasks/run-application/access-api-from-pod/)
|
||||
了解更多详情。
|
||||
|
||||
<!--
|
||||
## Accessing services running on the cluster
|
||||
|
||||
The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/administer-cluster/access-cluster-services/)
|
||||
The previous section describes how to connect to the Kubernetes API server.
|
||||
For information about connecting to other services running on a Kubernetes cluster, see
|
||||
[Access Cluster Services](/docs/tasks/administer-cluster/access-cluster-services/).
|
||||
-->
|
||||
|
||||
## 访问集群上运行的服务 {#accessing-services-running-on-the-cluster}
|
||||
|
||||
上一节介绍了如何连接到 Kubernetes API 服务器。
|
||||
有关连接到 Kubernetes 集群上运行的其他服务的信息,请参阅[访问集群服务](/zh/docs/tasks/administer-cluster/access-cluster-services/)。
|
||||
|
||||
有关连接到 Kubernetes 集群上运行的其他服务的信息,请参阅
|
||||
[访问集群服务](/zh/docs/tasks/administer-cluster/access-cluster-services/)。
|
||||
|
||||
<!--
|
||||
## Requesting redirects
|
||||
|
||||
@@ -357,13 +357,13 @@ The following manifest defines an Ingress that sends traffic to your Service via
|
||||
|
||||
|
||||
```yaml
|
||||
- path: /v2
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: web2
|
||||
port:
|
||||
number: 8080
|
||||
- path: /v2
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: web2
|
||||
port:
|
||||
number: 8080
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
@@ -228,12 +228,12 @@ describes how you can configure this as a cluster administrator.
|
||||
<!--
|
||||
### Programmatic access to the API
|
||||
|
||||
Kubernetes officially supports client libraries for [Go](#go-client), [Python](#python-client), [Java](#java-client), [dotnet](#dotnet-client), [Javascript](#javascript-client), and [Haskell](#haskell-client). There are other client libraries that are provided and maintained by their authors, not the Kubernetes team. See [client libraries](/docs/reference/using-api/client-libraries/) for accessing the API from other languages and how they authenticate.
|
||||
Kubernetes officially supports client libraries for [Go](#go-client), [Python](#python-client), [Java](#java-client), [dotnet](#dotnet-client), [JavaScript](#javascript-client), and [Haskell](#haskell-client). There are other client libraries that are provided and maintained by their authors, not the Kubernetes team. See [client libraries](/docs/reference/using-api/client-libraries/) for accessing the API from other languages and how they authenticate.
|
||||
-->
|
||||
### 编程方式访问 API
|
||||
|
||||
Kubernetes 官方支持 [Go](#go-client)、[Python](#python-client)、[Java](#java-client)、
|
||||
[dotnet](#dotnet-client)、[Javascript](#javascript-client) 和 [Haskell](#haskell-client)
|
||||
[dotnet](#dotnet-client)、[JavaScript](#javascript-client) 和 [Haskell](#haskell-client)
|
||||
语言的客户端库。还有一些其他客户端库由对应作者而非 Kubernetes 团队提供并维护。
|
||||
参考[客户端库](/zh/docs/reference/using-api/client-libraries/)了解如何使用其他语言
|
||||
来访问 API 以及如何执行身份认证。
|
||||
|
||||
@@ -25,7 +25,6 @@ You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can m
|
||||
混合使用运行于 Linux 上的 Pod 和运行于 Windows 上的 Pod。
|
||||
本页面展示如何将 Windows 节点注册到你的集群。
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
{{< version-check >}}
|
||||
|
||||
+14
-2
@@ -16,11 +16,14 @@ weight: 20
|
||||
<!--
|
||||
The `dockershim` component of Kubernetes allows to use Docker as a Kubernetes's
|
||||
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
|
||||
Kubernetes' built-in `dockershim` component was deprecated in release v1.20.
|
||||
Kubernetes' built-in `dockershim` component was
|
||||
[deprecated](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
|
||||
in release v1.20.
|
||||
-->
|
||||
Kubernetes 的 `dockershim` 组件使得你可以把 Docker 用作 Kubernetes 的
|
||||
{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}。
|
||||
在 Kubernetes v1.20 版本中,内建组件 `dockershim` 被弃用。
|
||||
在 Kubernetes v1.20 版本中,内建组件 `dockershim` 被[弃用](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)。
|
||||
|
||||
|
||||
<!--
|
||||
This page explains how your cluster could be using Docker as a container runtime,
|
||||
@@ -171,3 +174,12 @@ by Kubernetes.
|
||||
但用 Docker 创建、下载的镜像,对于容器运行时和 Kubernetes,均不可见。
|
||||
为了在 Kubernetes 中使用,需要把镜像推送(push)到某镜像仓库。
|
||||
|
||||
<!-- ## {{% heading "whatsnext" %}}
|
||||
|
||||
- Read [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) to understand your next steps
|
||||
- Read the [dockershim deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article for more information.
|
||||
-->
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- 阅读[从 dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)以了解你的下一步工作
|
||||
- 阅读[dockershim 弃用常见问题解答](/zh/blog/2020/12/02/dockershim-faq/)文章了解更多信息。
|
||||
@@ -217,7 +217,7 @@ For details, read the [documentation for your Kubernetes version](/docs/home/sup
|
||||
1. Use either `kubectl` or the Kubernetes API to delete the Deployment,
|
||||
depending on the Kubernetes version your cluster runs. {{<version-check>}}
|
||||
-->
|
||||
1. [创建一个 Deployment 示例](zh/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment)。
|
||||
1. [创建一个 Deployment 示例](/zh/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment)。
|
||||
1. 基于你的集群所运行的 Kubernetes 版本,使用 `kubectl` 或者 Kubernetes API 来删除 Deployment。
|
||||
{{<version-check>}}
|
||||
|
||||
|
||||
@@ -608,7 +608,7 @@ appropriate Pod Security profile is applied to new namespaces.
|
||||
<!--
|
||||
You can also statically configure the Pod Security admission controller to set a default enforce,
|
||||
audit, and/or warn level for unlabeled namespaces. See
|
||||
[Configure the Admission Controller](docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
|
||||
[Configure the Admission Controller](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)
|
||||
for more information.
|
||||
-->
|
||||
你也可以静态配置 Pod 安全性准入控制器,为尚未打标签的名字空间设置默认的
|
||||
|
||||
@@ -143,8 +143,8 @@ worker node, but it can't run on that machine. Again, the information from
|
||||
|
||||
* Make sure that you have the name of the image correct.
|
||||
* Have you pushed the image to the repository?
|
||||
* Run a manual `docker pull <image>` on your machine to see if the image can be
|
||||
pulled.
|
||||
* Try to manually pull the image to see if it can be pulled. For example, if you
|
||||
use Docker on your PC, run `docker pull <image>`.
|
||||
-->
|
||||
### 我的 Pod 一直在 Waiting
|
||||
|
||||
@@ -154,7 +154,7 @@ worker node, but it can't run on that machine. Again, the information from
|
||||
|
||||
* 确保你的镜像的名称正确。
|
||||
* 你是否将镜像推送到存储库?
|
||||
* 在你的机器上手动运行 `docker pull <image>`,看看是否可以拉取镜像。
|
||||
* 尝试手动拉取镜像,看能否拉取。例如,如果你在 PC 上使用 Docker,运行 `docker pull <image>`。
|
||||
|
||||
<!--
|
||||
### My pod is crashing or otherwise unhealthy
|
||||
|
||||
@@ -162,19 +162,27 @@ With the additional entries specified at the bottom.
|
||||
-->
|
||||
在最下面额外添加了一些条目。
|
||||
|
||||
<!--
|
||||
## Why Does Kubelet Manage the Hosts File?
|
||||
<!--
|
||||
## Why does the kubelet manage the hosts file? {#why-does-kubelet-manage-the-hosts-file}
|
||||
|
||||
Kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the
|
||||
`hosts` file for each container of the Pod to prevent Docker from
|
||||
[modifying](https://github.com/moby/moby/issues/17190) the file after the
|
||||
containers have already been started.
|
||||
The kubelet manages the
|
||||
`hosts` file for each container of the Pod to prevent the container runtime from
|
||||
modifying the file after the containers have already been started.
|
||||
Historically, Kubernetes always used Docker Engine as its container runtime, and Docker Engine would
|
||||
then modify the `/etc/hosts` file after each container had started.
|
||||
|
||||
Current Kubernetes can use a variety of container runtimes; even so, the kubelet manages the
|
||||
hosts file within each container so that the outcome is as intended regardless of which
|
||||
container runtime you use.
|
||||
-->
|
||||
## 为什么 kubelet 管理 hosts 文件?
|
||||
## 为什么 kubelet 管理 hosts 文件?{#why-does-kubelet-manage-the-hosts-file}
|
||||
|
||||
kubelet [管理](https://github.com/kubernetes/kubernetes/issues/14633) Pod
|
||||
中每个容器的 hosts 文件,避免 Docker 在容器已经启动之后去
|
||||
[修改](https://github.com/moby/moby/issues/17190) 该文件。
|
||||
kubelet 管理每个Pod 容器的 `hosts` 文件,以防止容器运行时在容器已经启动后修改文件。
|
||||
由于历史原因,Kubernetes 总是使用 Docker Engine 作为其容器运行时,而 Docker Engine
|
||||
将在容器启动后修改 `/etc/hosts` 文件。
|
||||
|
||||
当前的 Kubernetes 可以使用多种容器运行时;即便如此,kubelet 管理在每个容器中创建 hosts文件,
|
||||
以便你使用任何容器运行时运行容器时,结果都符合预期。
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
|
||||
@@ -93,7 +93,8 @@ Kubernetes API 服务器。也就是说,Pod 可以使用 `kubernetes.default.s
|
||||
|
||||
<!--
|
||||
The recommended way to authenticate to the API server is with a
|
||||
[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By default, a Pod
|
||||
[service account](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
credential. By default, a Pod
|
||||
is associated with a service account, and a credential (token) for that
|
||||
service account is placed into the filesystem tree of each container in that Pod,
|
||||
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
|
||||
|
||||
@@ -162,7 +162,7 @@ Or use this for detailed view of version:
|
||||
|
||||
或者使用如下命令来查看版本的详细信息:
|
||||
```cmd
|
||||
kubectl version --client --output=yaml
|
||||
kubectl version --client --output=yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
@@ -120,7 +120,7 @@ The following methods exist for installing kubectl on Windows:
|
||||
```
|
||||
或者使用下面命令来查看版本的详细信息:
|
||||
```cmd
|
||||
kubectl version --client --output=yaml
|
||||
kubectl version --client --output=yaml
|
||||
```
|
||||
|
||||
|
||||
|
||||
@@ -398,7 +398,7 @@ metadata:
|
||||
spec:
|
||||
containers:
|
||||
- name: hello
|
||||
image: busybox
|
||||
image: busybox:1.28
|
||||
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
|
||||
EOF
|
||||
pod/hello-apparmor-2 created
|
||||
@@ -510,10 +510,10 @@ Pod 在具有所需配置文件的节点上运行。
|
||||
{{< note >}}
|
||||
<!--
|
||||
PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25.
|
||||
See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information.
|
||||
See [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) documentation for more information.
|
||||
-->
|
||||
PodSecurityPolicy 在 Kubernetes v1.21 版本中已被废弃,将在 v1.25 版本移除。
|
||||
查看 [PodSecurityPolicy 文档](/zh/docs/concepts/policy/pod-security-policy/)获取更多信息。
|
||||
查看 [PodSecurityPolicy](/zh/docs/concepts/security/pod-security-policy/) 文档获取更多信息。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
@@ -559,47 +559,21 @@ specification.
|
||||
|
||||
<!--
|
||||
When disabled, any Pod that includes an AppArmor profile will fail validation with a "Forbidden"
|
||||
error. Note that by default docker always enables the "docker-default" profile on non-privileged
|
||||
pods (if the AppArmor kernel module is enabled), and will continue to do so even if the feature-gate
|
||||
is disabled. The option to disable AppArmor will be removed when AppArmor graduates to general
|
||||
availability (GA).
|
||||
error.
|
||||
-->
|
||||
禁用时,任何包含 AppArmor 配置文件的 Pod 都将导致验证失败,且返回 “Forbidden” 错误。
|
||||
注意,默认情况下,docker 总是在非特权 Pod 上启用 “docker-default” 配置文件(如果 AppArmor 内核模块已启用),
|
||||
并且即使特性门控已禁用,也将继续启用该配置文件。
|
||||
当 AppArmor 升级到正式发布(GA)阶段时,禁用 Apparmor 的选项将被删除。
|
||||
|
||||
<!-- ### Upgrading to Kubernetes v1.4 with AppArmor -->
|
||||
### 使用 AppArmor 升级到 Kubernetes v1.4
|
||||
|
||||
<!--
|
||||
No action is required with respect to AppArmor to upgrade your cluster to v1.4. However, if any
|
||||
existing pods had an AppArmor annotation, they will not go through validation (or PodSecurityPolicy
|
||||
admission). If permissive profiles are loaded on the nodes, a malicious user could pre-apply a
|
||||
permissive profile to escalate the pod privileges above the docker-default. If this is a concern, it
|
||||
is recommended to scrub the cluster of any pods containing an annotation with
|
||||
`apparmor.security.beta.kubernetes.io`.
|
||||
{{<note>}}
|
||||
<!--
|
||||
Even if the Kubernetes feature is disabled, runtimes may still enforce the default profile. The
|
||||
option to disable the AppArmor feature will be removed when AppArmor graduates to general
|
||||
availability (GA).
|
||||
-->
|
||||
不需要对 AppArmor 执行任何操作即可将集群升级到 v1.4。但是,
|
||||
如果任何现有的 Pod 有一个 AppArmor 注解,
|
||||
它们将无法通过合法性检查(或 PodSecurityPolicy 准入控制)。
|
||||
如果节点上加载了宽松的配置文件,恶意用户可以预先应用宽松的配置文件,
|
||||
将 Pod 权限提升到 docker-default 权限之上。
|
||||
如果存在这个问题,建议清除集群中包含 `apparmor.security.beta.kubernetes.io` 注解的所有 Pod。
|
||||
即使此 Kubernetes 特性被禁用,运行时仍可能强制执行默认配置文件。
|
||||
当 AppArmor 升级为正式版 (GA) 时,禁用 AppArmor 功能的选项将被删除。
|
||||
|
||||
<!-- ### Upgrade path to General Availability -->
|
||||
### 升级到正式发布的途径 {#upgrade-path-to-general-availability}
|
||||
{{</note>}}
|
||||
|
||||
<!--
|
||||
When AppArmor is ready to be graduated to general availability (GA), the options currently specified
|
||||
through annotations will be converted to fields. Supporting all the upgrade and downgrade paths
|
||||
through the transition is very nuanced, and will be explained in detail when the transition
|
||||
occurs. We will commit to supporting both fields and annotations for at least 2 releases, and will
|
||||
explicitly reject the annotations for at least 2 releases after that.
|
||||
-->
|
||||
当 Apparmor 准备升级到正式发布(GA)状态时,当前通过注解指定的选项将转换为字段。
|
||||
通过转换支持所有升级和降级路径是非常微妙的,并将在转换发生时详细解释。
|
||||
我们将承诺在至少两个发行版本中同时支持字段和注解,并在之后的至少两个版本中显式拒绝注解。
|
||||
|
||||
<!-- ## Authoring Profiles -->
|
||||
## 编写配置文件 {#authoring-profiles}
|
||||
@@ -623,14 +597,6 @@ tools to help with that:
|
||||
* [bane](https://github.com/jfrazelle/bane)
|
||||
是一个用于 Docker的 AppArmor 配置文件生成器,它使用一种简化的画像语言(profile language)
|
||||
|
||||
<!--
|
||||
It is recommended to run your application through Docker on a development workstation to generate
|
||||
the profiles, but there is nothing preventing running the tools on the Kubernetes node where your
|
||||
Pod is running.
|
||||
-->
|
||||
建议在开发工作站上通过 Docker 运行应用程序以生成配置文件,
|
||||
不过在运行 Pod 的 Kubernetes 节点上运行这些工具也是可以的。
|
||||
|
||||
<!--
|
||||
To debug problems with AppArmor, you can check the system logs to see what, specifically, was
|
||||
denied. AppArmor logs verbose messages to `dmesg`, and errors can usually be found in the system
|
||||
@@ -669,9 +635,8 @@ AppArmor 将详细消息记录到 `dmesg`,
|
||||
- `runtime/default`: Refers to the default runtime profile.
|
||||
- Equivalent to not specifying a profile (without a PodSecurityPolicy default), except it still
|
||||
requires AppArmor to be enabled.
|
||||
- For Docker, this resolves to the
|
||||
[`docker-default`](https://docs.docker.com/engine/security/apparmor/) profile for non-privileged
|
||||
containers, and unconfined (no profile) for privileged containers.
|
||||
- In practice, many container runtimes use the same OCI default profile, defined here:
|
||||
https://github.com/containers/common/blob/main/pkg/apparmor/apparmor_linux_template.go
|
||||
- `localhost/<profile_name>`: Refers to a profile loaded on the node (localhost) by name.
|
||||
- The possible profile names are detailed in the
|
||||
[core policy reference](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications).
|
||||
@@ -679,9 +644,8 @@ AppArmor 将详细消息记录到 `dmesg`,
|
||||
-->
|
||||
- `runtime/default`: 指默认运行时配置文件。
|
||||
- 等同于不指定配置文件(没有 PodSecurityPolicy 默认值),只是它仍然需要启用 AppArmor。
|
||||
- 对于 Docker,针对非特权容器时解析为
|
||||
[`Docker default`](https://docs.docker.com/engine/security/apparmor/) 配置文件,
|
||||
针对特权容器时解析为 unconfined(无配置文件)。
|
||||
- 实际上,许多容器运行时使用相同的 OCI 默认配置文件,在此处定义:
|
||||
https://github.com/containers/common/blob/main/pkg/apparmor/apparmor_linux_template.go
|
||||
- `localhost/<profile_name>`: 按名称引用加载到节点(localhost)上的配置文件。
|
||||
- 可能的配置文件名在[核心策略参考](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)。
|
||||
- `unconfined`: 这相当于为容器禁用 AppArmor。
|
||||
|
||||
@@ -16,15 +16,16 @@ weight: 10
|
||||
{{% /alert %}}
|
||||
|
||||
<!--
|
||||
Pod Security admission (PSA) is enabled by default in v1.23 and later, as it [graduated
|
||||
to beta](/blog/2021/12/09/pod-security-admission-beta/). Pod Security Admission
|
||||
Pod Security admission (PSA) is enabled by default in v1.23 and later, as it
|
||||
[graduated to beta](/blog/2021/12/09/pod-security-admission-beta/). Pod Security Admission
|
||||
is an admission controller that applies
|
||||
[Pod Security Standards](docs/concepts/security/pod-security-standards/)
|
||||
[Pod Security Standards](/docs/concepts/security/pod-security-standards/)
|
||||
when pods are created. In this tutorial, you will enforce the `baseline` Pod Security Standard,
|
||||
one namespace at a time.
|
||||
|
||||
You can also apply Pod Security Standards to multiple namespaces at once at the cluster
|
||||
level. For instructions, refer to [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss).
|
||||
level. For instructions, refer to
|
||||
[Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss).
|
||||
-->
|
||||
Pod 安全准入(PSA)在 v1.23 及更高版本默认启用,
|
||||
因为它[升级到测试版(beta)](/blog/2021/12/09/pod-security-admission-beta/)。
|
||||
@@ -41,12 +42,12 @@ Pod 安全准入是在创建 Pod 时应用
|
||||
Install the following on your workstation:
|
||||
|
||||
- [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation)
|
||||
- [kubectl](https://kubernetes.io/docs/tasks/tools/)
|
||||
- [kubectl](/docs/tasks/tools/)
|
||||
-->
|
||||
在你的工作站中安装以下内容:
|
||||
|
||||
- [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation)
|
||||
- [kubectl](https://kubernetes.io/docs/tasks/tools/)
|
||||
- [kubectl](/zh/docs/tasks/tools/)
|
||||
|
||||
<!--
|
||||
## Create cluster
|
||||
@@ -104,8 +105,10 @@ Create a new namespace called `example`:
|
||||
```shell
|
||||
kubectl create ns example
|
||||
```
|
||||
|
||||
<!-- The output is similar to this: -->
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
namespace/example created
|
||||
```
|
||||
@@ -190,11 +193,14 @@ namespace/example created
|
||||
1. Apply the pod spec to the cluster in `default` namespace:
|
||||
-->
|
||||
3. 将 Pod 规约应用到集群中的 `default` 名字空间中:
|
||||
```shell
|
||||
kubectl apply -n default -f /tmp/pss/nginx-pod.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl apply -n default -f /tmp/pss/nginx-pod.yaml
|
||||
```
|
||||
|
||||
<!-- Output is similar to this: -->
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
pod/nginx created
|
||||
```
|
||||
@@ -222,6 +228,7 @@ Run `kind delete cluster -name psa-ns-level` to delete the cluster created.
|
||||
- Run a
|
||||
[shell script](/examples/security/kind-with-namespace-level-baseline-pod-security.sh)
|
||||
to perform all the preceding steps all at once.
|
||||
|
||||
1. Create KinD cluster
|
||||
2. Create new namespace
|
||||
3. Apply `baseline` Pod Security Standard in `enforce` mode while applying
|
||||
@@ -232,12 +239,14 @@ Run `kind delete cluster -name psa-ns-level` to delete the cluster created.
|
||||
- [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss/)
|
||||
-->
|
||||
- 运行一个 [shell 脚本](/examples/security/kind-with-namespace-level-baseline-pod-security.sh)
|
||||
一次执行所有前面的步骤。
|
||||
一次执行所有前面的步骤。
|
||||
|
||||
1. 创建 KinD 集群
|
||||
2. 创建新的名字空间
|
||||
3. 在 `enforce` 模式下应用 `baseline` Pod 安全标准,
|
||||
同时在 `warn` 和 `audit` 模式下应用 `restricted` Pod 安全标准。
|
||||
4. 创建一个应用以下 Pod 安全标准的新 Pod
|
||||
|
||||
- [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/)
|
||||
- [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)
|
||||
- [在集群级别应用 Pod 安全标准](/zh/docs/tutorials/security/cluster-level-pss/)
|
||||
|
||||
@@ -981,6 +981,8 @@ statefulset rolling update complete 3 pods at revision zk-5db4499664...
|
||||
This terminates the Pods, one at a time, in reverse ordinal order, and recreates them with the new configuration. This ensures that quorum is maintained during a rolling update.
|
||||
|
||||
Use the `kubectl rollout history` command to view a history or previous configurations.
|
||||
|
||||
The output is similar to this:
|
||||
-->
|
||||
这项操作会逆序地依次终止每一个 Pod,并用新的配置重新创建。
|
||||
这样做确保了在滚动更新的过程中 quorum 依旧保持工作。
|
||||
@@ -991,6 +993,8 @@ Use the `kubectl rollout history` command to view a history or previous configur
|
||||
kubectl rollout history sts/zk
|
||||
```
|
||||
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
statefulsets "zk"
|
||||
REVISION
|
||||
@@ -1000,6 +1004,8 @@ REVISION
|
||||
|
||||
<!--
|
||||
Use the `kubectl rollout undo` command to roll back the modification.
|
||||
|
||||
The output is similar to this:
|
||||
-->
|
||||
使用 `kubectl rollout undo` 命令撤销这次的改动。
|
||||
|
||||
@@ -1007,6 +1013,8 @@ Use the `kubectl rollout undo` command to roll back the modification.
|
||||
kubectl rollout undo sts/zk
|
||||
```
|
||||
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
statefulset.apps/zk rolled back
|
||||
```
|
||||
@@ -1154,7 +1162,7 @@ In another window, using the following command to delete the `zookeeper-ready` s
|
||||
在另一个窗口中,从 Pod `zk-0` 的文件系统中删除 `zookeeper-ready` 脚本。
|
||||
|
||||
```shell
|
||||
kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready
|
||||
kubectl exec zk-0 -- rm /opt/zookeeper/bin/zookeeper-ready
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -1406,6 +1414,8 @@ kubernetes-node-i4c4
|
||||
<!--
|
||||
Use [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain) to cordon and
|
||||
drain the node on which the `zk-0` Pod is scheduled.
|
||||
|
||||
The output is similar to this:
|
||||
-->
|
||||
|
||||
使用 [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain)
|
||||
@@ -1415,6 +1425,8 @@ drain the node on which the `zk-0` Pod is scheduled.
|
||||
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
node "kubernetes-node-pb41" cordoned
|
||||
|
||||
@@ -1449,14 +1461,19 @@ zk-0 1/1 Running 0 1m
|
||||
<!--
|
||||
Keep watching the `StatefulSet`'s Pods in the first terminal and drain the node on which
|
||||
`zk-1` is scheduled.
|
||||
|
||||
The output is similar to this:
|
||||
-->
|
||||
在第一个终端中持续观察 `StatefulSet` 的 Pods 并腾空 `zk-1` 调度所在的节点。
|
||||
|
||||
```shell
|
||||
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force -delete-emptydir-data "kubernetes-node-ixsl" cordoned
|
||||
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
kubernetes-node-ixsl" cordoned
|
||||
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74
|
||||
pod "zk-1" deleted
|
||||
node "kubernetes-node-ixsl" drained
|
||||
@@ -1465,6 +1482,8 @@ node "kubernetes-node-ixsl" drained
|
||||
<!--
|
||||
The `zk-1` Pod cannot be scheduled because the `zk` `StatefulSet` contains a `PodAntiAffinity` rule preventing
|
||||
co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state.
|
||||
|
||||
The output is similar to this:
|
||||
-->
|
||||
`zk-1` Pod 不能被调度,这是因为 `zk` `StatefulSet` 包含了一个防止 Pods
|
||||
共存的 `PodAntiAffinity` 规则,而且只有两个节点可用于调度,
|
||||
@@ -1474,6 +1493,8 @@ co-location of the Pods, and as only two nodes are schedulable, the Pod will rem
|
||||
kubectl get pods -w -l app=zk
|
||||
```
|
||||
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
zk-0 1/1 Running 2 1h
|
||||
@@ -1500,12 +1521,17 @@ zk-1 0/1 Pending 0 0s
|
||||
<!--
|
||||
Continue to watch the Pods of the StatefulSet, and drain the node on which
|
||||
`zk-2` is scheduled.
|
||||
|
||||
The output is similar to this:
|
||||
-->
|
||||
继续观察 StatefulSet 中的 Pods 并腾空 `zk-2` 调度所在的节点。
|
||||
|
||||
```shell
|
||||
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
node "kubernetes-node-i4c4" cordoned
|
||||
|
||||
@@ -1556,6 +1582,8 @@ numChildren = 0
|
||||
|
||||
<!--
|
||||
Use [`kubectl uncordon`](/docs/reference/generated/kubectl/kubectl-commands/#uncordon) to uncordon the first node.
|
||||
|
||||
The output is similar to this:
|
||||
-->
|
||||
使用 [`kubectl uncordon`](/docs/reference/generated/kubectl/kubectl-commands/#uncordon)
|
||||
来取消对第一个节点的隔离。
|
||||
@@ -1564,12 +1592,16 @@ Use [`kubectl uncordon`](/docs/reference/generated/kubectl/kubectl-commands/#unc
|
||||
kubectl uncordon kubernetes-node-pb41
|
||||
```
|
||||
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
node "kubernetes-node-pb41" uncordoned
|
||||
```
|
||||
|
||||
<!--
|
||||
`zk-1` is rescheduled on this node. Wait until `zk-1` is Running and Ready.
|
||||
|
||||
The output is similar to this:
|
||||
-->
|
||||
`zk-1` 被重新调度到了这个节点。等待 `zk-1` 变为 Running 和 Ready 状态。
|
||||
|
||||
@@ -1577,6 +1609,8 @@ node "kubernetes-node-pb41" uncordoned
|
||||
kubectl get pods -w -l app=zk
|
||||
```
|
||||
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
zk-0 1/1 Running 2 1h
|
||||
@@ -1614,9 +1648,9 @@ kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-dae
|
||||
```
|
||||
|
||||
<!--
|
||||
The output:
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出:
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
node "kubernetes-node-i4c4" already cordoned
|
||||
@@ -1630,6 +1664,8 @@ node "kubernetes-node-i4c4" drained
|
||||
This time `kubectl drain` succeeds.
|
||||
|
||||
Uncordon the second node to allow `zk-2` to be rescheduled.
|
||||
|
||||
The output is similar to this:
|
||||
-->
|
||||
这次 `kubectl drain` 执行成功。
|
||||
|
||||
@@ -1639,6 +1675,8 @@ Uncordon the second node to allow `zk-2` to be rescheduled.
|
||||
kubectl uncordon kubernetes-node-ixsl
|
||||
```
|
||||
|
||||
输出类似于:
|
||||
|
||||
```
|
||||
node "kubernetes-node-ixsl" uncordoned
|
||||
```
|
||||
|
||||
@@ -362,7 +362,11 @@ The `Redis` Services you applied is only accessible within the Kubernetes cluste
|
||||
`ClusterIP` 为服务指向的 Pod 集提供一个 IP 地址。这个 IP 地址只能在集群中访问。
|
||||
|
||||
<!--
|
||||
If you want guests to be able to access your guestbook, you must configure the frontend Service to be externally visible, so a client can request the Service from outside the Kubernetes cluster. However a Kubernetes user you can use `kubectl port-forward` to access the service even though it uses a `ClusterIP`.
|
||||
If you want guests to be able to access your guestbook, you must configure the
|
||||
frontend Service to be externally visible, so a client can request the Service
|
||||
from outside the Kubernetes cluster. However a Kubernetes user can use
|
||||
`kubectl port-forward` to access the service even though it uses a
|
||||
`ClusterIP`.
|
||||
-->
|
||||
如果你希望访客能够访问你的 Guestbook,你必须将前端服务配置为外部可见的,
|
||||
以便客户端可以从 Kubernetes 集群之外请求服务。
|
||||
|
||||
Reference in New Issue
Block a user