fix
This commit is contained in:
ChongmingDu
@@ -0,0 +1 @@
|
||||
/zh/docs/ /zh/docs/home/ 301
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 主页
|
||||
title: 文档
|
||||
weight: 5
|
||||
---
|
||||
|
||||
|
||||
@@ -1,163 +1,416 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- enisoc
|
||||
- erictune
|
||||
- foxish
|
||||
- janetkuo
|
||||
- kow3ns
|
||||
title: DaemonSet
|
||||
redirect_from:
|
||||
- "/docs/admin/daemons/"
|
||||
- "/docs/admin/daemons.html"
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- enisoc
|
||||
- erictune
|
||||
- foxish
|
||||
- janetkuo
|
||||
- kow3ns
|
||||
title: DaemonSet
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
--->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
A _DaemonSet_ ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the
|
||||
cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage
|
||||
collected. Deleting a DaemonSet will clean up the Pods it created.
|
||||
--->
|
||||
_DaemonSet_ 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，
|
||||
也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
|
||||
|
||||
## 什么是 DaemonSet？
|
||||
|
||||
_DaemonSet_ 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。
|
||||
当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
|
||||
|
||||
|
||||
<!--
|
||||
Some typical uses of a DaemonSet are:
|
||||
|
||||
- running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
|
||||
- running a logs collection daemon on every node, such as `fluentd` or `logstash`.
|
||||
- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](
|
||||
https://github.com/prometheus/node_exporter), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` or Instana agent.
|
||||
--->
|
||||
使用 DaemonSet 的一些典型用法：
|
||||
|
||||
- 运行集群存储 daemon，例如在每个节点上运行 `glusterd`、`ceph`。
|
||||
- 在每个节点上运行日志收集 daemon，例如`fluentd`、`logstash`。
|
||||
- 在每个节点上运行监控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、Datadog 代理、New Relic 代理, Ganglia `gmond`, 或 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/)。
|
||||
- 在每个节点上运行监控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/)、 [AppDynamics 代理](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes)、 [Datadog 代理](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/)、[New Relic 代理](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 或 Instana agent。
|
||||
|
||||
一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。
|
||||
一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，和/或对不同硬件类型具有不同的内存、CPU要求。
|
||||
<!--
|
||||
In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
|
||||
A more complex setup might use multiple DaemonSets for a single type of daemon, but with
|
||||
different flags and/or different memory and cpu requests for different hardware types.
|
||||
--->
|
||||
一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使
|
||||
用。
|
||||
一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，
|
||||
和/或对不同硬件类型具有不同的内存、CPU要求。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 编写 DaemonSet 规约
|
||||
<!--
|
||||
## Writing a DaemonSet Spec
|
||||
|
||||
### Create a DaemonSet
|
||||
--->
|
||||
## 编写 DaemonSet 规约
|
||||
|
||||
### 创建 DaemonSet
|
||||
|
||||
<!--
|
||||
You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` file below describes a DaemonSet that runs the fluentd-elasticsearch Docker image:
|
||||
|
||||
{{< codenew file="controllers/daemonset.yaml" >}}
|
||||
|
||||
* Create a DaemonSet based on the YAML file:
|
||||
```
|
||||
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||
```
|
||||
--->
|
||||
您可以在 YAML 文件中描述 DaemonSet。例如，下面的 daemonset.yaml 文件描述了一个运行 fluentd-elasticsearch Docker 镜像的 DaemonSet：
|
||||
|
||||
{{< codenew file="controllers/daemonset.yaml" >}}
|
||||
|
||||
* 基于 YAML 文件创建 DaemonSet:
|
||||
```
|
||||
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
### Required Fields
|
||||
|
||||
As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields. For
|
||||
general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/),
|
||||
[configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/object-management-kubectl/overview/) documents.
|
||||
|
||||
A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) section.
|
||||
--->
|
||||
### 必需字段
|
||||
|
||||
|
||||
|
||||
和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。
|
||||
有关配置文件的基本信息，详见文档 [deploying applications](/docs/user-guide/deploying-applications/)、[配置容器](/docs/user-guide/configuring-containers/) 和 [资源管理](/docs/concepts/tools/kubectl/object-management-overview/) 。
|
||||
和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。有关配置文件的基本信息，详见文档 [部署应用](/docs/user-guide/deploying-applications/)、[配置容器](/docs/tasks/) 和 [使用kubectl进行对象管理](/docs/concepts/overview/object-management-kubectl/overview/) 。
|
||||
|
||||
DaemonSet 也需要一个 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 配置段。
|
||||
|
||||
<!--
|
||||
### Pod Template
|
||||
|
||||
The `.spec.template` is one of the required fields in `.spec`.
|
||||
|
||||
The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
|
||||
|
||||
In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate
|
||||
labels (see [pod selector](#pod-selector)).
|
||||
|
||||
A Pod Template in a DaemonSet must have a [`RestartPolicy`](/docs/user-guide/pod-states)
|
||||
equal to `Always`, or be unspecified, which defaults to `Always`.
|
||||
--->
|
||||
### Pod 模板
|
||||
|
||||
`.spec` 唯一必需的字段是 `.spec.template`。
|
||||
|
||||
|
||||
|
||||
`.spec.template` 是一个 [Pod 模板](/docs/user-guide/replication-controller/#pod-template)。
|
||||
它与 [Pod](/docs/user-guide/pods) 具有相同的 schema，除了它是嵌套的，而且不具有 `apiVersion` 或 `kind` 字段。
|
||||
`.spec.template` 是一个 [Pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它与 [Pod](/docs/concepts/workloads/pods/pod/) 具有相同的 schema，除了它是嵌套的，而且不具有 `apiVersion` 或 `kind` 字段。
|
||||
|
||||
除了 Pod 必需字段外，在 DaemonSet 中的 Pod 模板必须指定合理的标签（查看 [Pod Selector](#pod-selector)）。
|
||||
|
||||
在 DaemonSet 中的 Pod 模板必须具有一个值为 `Always` 的 [`RestartPolicy`](/docs/user-guide/pod-states)，或者未指定它的值，默认是 `Always`。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
### Pod Selector
|
||||
|
||||
`.spec.selector` 字段表示 Pod Selector，它与 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 或其它资源的 `.spec.selector` 的作用是相同的。
|
||||
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,
|
||||
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.
|
||||
--->
|
||||
### Pod Selector
|
||||
|
||||
`.spec.selector` 字段表示 Pod Selector，它与 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 的 `.spec.selector` 的作用是相同的。
|
||||
|
||||
从 Kubernetes 1.8开始，您必须指定与 `.spec.template` 的标签匹配的 pod selector。当不配置时，pod selector 将不再有默认值。selector 默认与 `kubectl apply` 不兼容。 此外，一旦创建了 DaemonSet，它的 `.spec.selector` 就不能修改。修改 pod selector 可能导致成为 孤儿Pod，并且这对用户来说是困惑的。
|
||||
|
||||
<!--
|
||||
The `.spec.selector` is an object consisting of two fields:
|
||||
|
||||
* `matchLabels` - works the same as the `.spec.selector` of a [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
|
||||
* `matchExpressions` - allows to build more sophisticated selectors by specifying key,
|
||||
list of values and an operator that relates the key and values.
|
||||
|
||||
When the two are specified the result is ANDed.
|
||||
|
||||
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.
|
||||
|
||||
Also you should not normally create any Pods whose labels match this selector, either directly, via
|
||||
another DaemonSet, or via other controller such as ReplicaSet. Otherwise, the DaemonSet
|
||||
controller will think that those Pods were created by it. Kubernetes will not stop you from doing
|
||||
this. One case where you might want to do this is manually create a Pod with a different value on
|
||||
a node for testing.
|
||||
--->
|
||||
`spec.selector` 表示一个对象，它由如下两个字段组成：
|
||||
|
||||
* `matchLabels` - 与 [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/) 的 `.spec.selector` 的作用相同。
|
||||
* `matchExpressions` - 允许构建更加复杂的 Selector，可以通过指定 key、value 列表，以及与 key 和 value 列表相关的操作符。
|
||||
|
||||
|
||||
* `matchExpressions` - 允许构建更加复杂的 Selector，可以通过指定 key、value 列表
|
||||
，以及与 key 和 value 列表相关的操作符。
|
||||
|
||||
当上述两个字段都指定时，结果表示的是 AND 关系。
|
||||
|
||||
如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。如果没有指定，它们默认是等价的。如果与它们配置的不匹配，则会被 API 拒绝。
|
||||
|
||||
如果 Pod 的 label 与 selector 匹配，或者直接基于其它的 DaemonSet、或者 Controller（例如 ReplicationController），也不可以创建任何 Pod。
|
||||
否则 DaemonSet Controller 将认为那些 Pod 是它创建的。Kubernetes 不会阻止这样做。一个场景是，可能希望在一个具有不同值的、用来测试用的节点上手动创建 Pod。
|
||||
如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。如果与它们配置的不匹配，则会被 API 拒绝。
|
||||
|
||||
此外，您通常不应该创建任何 pods，它们的 label 与 selector 匹配，或者直接创建，或者通过另一个 DaemonSet、或者其他控制器，比如 ReplicaSet。否则，DaemonSet 控制器会认为这些 Pod 是由它创建的。Kubernetes 不会阻止你这样做。 您可能希望这样做的一种情况是在节点上手动创建具有不同值的 Pod 以进行测试。
|
||||
|
||||
<!--
|
||||
### Running Pods on Only Some Nodes
|
||||
|
||||
If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
|
||||
create Pods on nodes which match that [node
|
||||
selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`,
|
||||
then DaemonSet controller will create Pods on nodes which match that [node affinity](/docs/concepts/configuration/assign-pod-node/).
|
||||
If you do not specify either, then the DaemonSet controller will create Pods on all nodes.
|
||||
--->
|
||||
### 仅在某些节点上运行 Pod
|
||||
|
||||
如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
|
||||
类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [Node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
|
||||
如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配>的节点上创建 Pod。
|
||||
如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。
|
||||
|
||||
<!--
|
||||
## How Daemon Pods are Scheduled
|
||||
|
||||
### Scheduled by DaemonSet controller (disabled by default since 1.12)
|
||||
|
||||
## 如何调度 Daemon Pod
|
||||
Normally, the machine that a Pod runs on is selected by the Kubernetes scheduler. However, Pods
|
||||
created by the DaemonSet controller have the machine already selected (`.spec.nodeName` is specified
|
||||
when the Pod is created, so it is ignored by the scheduler). Therefore:
|
||||
|
||||
正常情况下，Pod 运行在哪个机器上是由 Kubernetes 调度器来选择的。然而，由 Daemon Controller 创建的 Pod 已经确定了在哪个机器上（Pod 创建时指定了 `.spec.nodeName`），因此：
|
||||
- The [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected
|
||||
by the DaemonSet controller.
|
||||
- The DaemonSet controller can make Pods even when the scheduler has not been started, which can help cluster
|
||||
bootstrap.
|
||||
--->
|
||||
## 如何调度 Daemon Pods
|
||||
|
||||
### 由 DaemonSet 控制器调度（从v1.12 开始默认禁用）
|
||||
|
||||
正常情况下，Pod 运行在哪个机器上是由 Kubernetes 调度器来选择的。然而，由 DaemonSet Controller 创建的 Pod 已经确定了在哪个机器上（Pod 创建时指定了 `.spec.nodeName`，调度器会忽略它），因此：
|
||||
|
||||
- DaemonSet Controller 并不关心一个节点的 [`unschedulable`](/docs/admin/node/#manual-node-administration) 字段。
|
||||
- DaemonSet Controller 可以创建 Pod，即使调度器还没有启动，这对集群启动是非常有帮助的。
|
||||
|
||||
<!--
|
||||
### Scheduled by default scheduler (enabled by default since 1.12)
|
||||
|
||||
{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
|
||||
|
||||
Daemon Pod 关心 [Taint 和 Toleration](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)，它们会为没有指定 `tolerationSeconds` 的 `node.kubernetes.io/not-ready` 和 `node.alpha.kubernetes.io/unreachable` 的 Taint，创建具有 `NoExecute` 的 Toleration。这确保了当 alpha 特性的 `TaintBasedEvictions` 被启用时，发生节点故障，比如网络分区，这时它们将不会被清除掉（当 `TaintBasedEvictions` 特性没有启用，在这些场景下也不会被清除，但会因为 NodeController 的硬编码行为而被清除，而不会因为 Toleration 导致被清除）。
|
||||
A DaemonSet ensures that all eligible nodes run a copy of a Pod. Normally, the
|
||||
node that a Pod runs on is selected by the Kubernetes scheduler. However,
|
||||
DaemonSet pods are created and scheduled by the DaemonSet controller instead.
|
||||
That introduces the following issues:
|
||||
|
||||
* Inconsistent Pod behavior: Normal Pods waiting to be scheduled are created
|
||||
and in `Pending` state, but DaemonSet pods are not created in `Pending`
|
||||
state. This is confusing to the user.
|
||||
* [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
is handled by default scheduler. When preemption is enabled, the DaemonSet controller
|
||||
will make scheduling decisions without considering pod priority and preemption.
|
||||
--->
|
||||
### 由默认 scheduler 调度（从v1.12开始默认开启）
|
||||
|
||||
{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
|
||||
|
||||
DaemonSet 确保所有符合条件的节点都运行一个 Pod 的副本。通常，运行 Pod 的节点由 Kubernetes scheduler 选择。然而，DaemonSet pods 由 DaemonSet controller 创建和调度。这将引入以下问题：
|
||||
|
||||
* Pod 行为的不一致性：等待调度的正常 Pod 已被创建并处于 `Pending` 状态，但 DaemonSet pods 未在 `Pending` 状态下创建。 这使用户感到困惑。
|
||||
* [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)由默认 scheduler 处理。 启用抢占后，DaemonSet 控制器将在不考虑 pod 优先级和抢占的情况下制定调度决策。
|
||||
|
||||
<!--
|
||||
`ScheduleDaemonSetPods` allows you to schedule DaemonSets using the default
|
||||
scheduler instead of the DaemonSet controller, by adding the `NodeAffinity` term
|
||||
to the DaemonSet pods, instead of the `.spec.nodeName` term. The default
|
||||
scheduler is then used to bind the pod to the target host. If node affinity of
|
||||
the DaemonSet pod already exists, it is replaced. The DaemonSet controller only
|
||||
performs these operations when creating or modifying DaemonSet pods, and no
|
||||
changes are made to the `spec.template` of the DaemonSet.
|
||||
--->
|
||||
`ScheduleDaemonSetPods` 允许您使用默认 scheduler 而不是 DaemonSet 控制器来调度 DaemonSets，方法是将 `NodeAffinity` 添加到 DaemonSet pods，而不是 `.spec.nodeName`。 然后使用默认 scheduler 将 pod 绑定到目标主机。 如果 DaemonSet pod的亲和节点已存在，则替换它。 DaemonSet 控制器仅在创建或修改 DaemonSet pods 时执行这些操作，并且不对 DaemonSet的 `spec.template` 进行任何更改。
|
||||
|
||||
```yaml
|
||||
nodeAffinity:
|
||||
requiredDuringSchedulingIgnoredDuringExecution:
|
||||
nodeSelectorTerms:
|
||||
- matchFields:
|
||||
- key: metadata.name
|
||||
operator: In
|
||||
values:
|
||||
- target-host-name
|
||||
```
|
||||
|
||||
<!--
|
||||
In addition, `node.kubernetes.io/unschedulable:NoSchedule` toleration is added
|
||||
automatically to DaemonSet Pods. The default scheduler ignores
|
||||
`unschedulable` Nodes when scheduling DaemonSet Pods.
|
||||
--->
|
||||
此外，`node.kubernetes.io/unschedulable：NoSchedule` toleration 会自动添加到 DaemonSet Pods。 在调度DaemonSet Pod 时，默认调度器会忽略 `unschedulable`节点。
|
||||
|
||||
<!--
|
||||
### Taints and Tolerations
|
||||
|
||||
Although Daemon Pods respect
|
||||
[taints and tolerations](/docs/concepts/configuration/taint-and-toleration),
|
||||
the following tolerations are added to DaemonSet Pods automatically according to
|
||||
the related features.
|
||||
--->
|
||||
### Taints and Tolerations
|
||||
|
||||
尽管 Daemon Pods 尊重[taints and tolerations](/docs/concepts/configuration/taint-and-toleration)，根据相关特性，会自动将以下 tolerations 添加到 DaemonSet Pods 中。
|
||||
|
||||
| Toleration Key | Effect | Version | Description |
|
||||
| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
|
||||
| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
|
||||
| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | DaemonSet pods will not be evicted when there are node problems such as a network partition. |
|
||||
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | |
|
||||
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | |
|
||||
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | DaemonSet pods tolerate unschedulable attributes by default scheduler. |
|
||||
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |
|
||||
|
||||
|
||||
|
||||
## 与 Daemon Pod 通信
|
||||
<!--
|
||||
## Communicating with Daemon Pods
|
||||
|
||||
Some possible patterns for communicating with Pods in a DaemonSet are:
|
||||
|
||||
- **Push**: Pods in the DaemonSet are configured to send updates to another service, such
|
||||
as a stats database. They do not have clients.
|
||||
- **NodeIP and Known Port**: Pods in the DaemonSet can use a `hostPort`, so that the pods are reachable via the node IPs. Clients know the list of node IPs somehow, and know the port by convention.
|
||||
- **DNS**: Create a [headless service](/docs/concepts/services-networking/service/#headless-services) with the same pod selector,
|
||||
and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from
|
||||
DNS.
|
||||
- **Service**: Create a service with the same Pod selector, and use the service to reach a
|
||||
daemon on a random node. (No way to reach specific node.)
|
||||
--->
|
||||
## 与 Daemon Pods 通信
|
||||
|
||||
与 DaemonSet 中的 Pod 进行通信，几种可能的模式如下：
|
||||
|
||||
- **Push**：配置 DaemonSet 中的 Pod 向其它 Service 发送更新，例如统计数据库。它们没有客户端。
|
||||
- **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP 访问到 Pod。客户端能通过某种方法知道节点 IP 列表，并且基于此也可以知道端口。
|
||||
- **DNS**：创建具有相同 Pod Selector 的 [Headless Service](/docs/user-guide/services/#headless-services)，然后通过使用 `endpoints` 资源或从 DNS 检索到多个 A 记录来发现 DaemonSet。
|
||||
- **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP 访问到 Pod。客户端能通过某种方法知道节点 IP 列表，并且基于此也可以知道端口
|
||||
。
|
||||
- **DNS**：创建具有相同 Pod Selector 的 [Headless Service](/docs/concepts/services-networking/service/#headless-services)，然后通过使用 `endpoints` 资源或从 DNS 检索到多个 A 记录来发现 DaemonSet。
|
||||
- **Service**：创建具有相同 Pod Selector 的 Service，并使用该 Service 随机访问到某个节点上的 daemon（没有办法访问到特定节点）。
|
||||
|
||||
<!--
|
||||
## Updating a DaemonSet
|
||||
|
||||
If node labels are changed, the DaemonSet will promptly add Pods to newly matching nodes and delete
|
||||
Pods from newly not-matching nodes.
|
||||
|
||||
You can modify the Pods that a DaemonSet creates. However, Pods do not allow all
|
||||
fields to be updated. Also, the DaemonSet controller will use the original template the next
|
||||
time a node (even with the same name) is created.
|
||||
|
||||
You can delete a DaemonSet. If you specify `--cascade=false` with `kubectl`, then the Pods
|
||||
will be left on the nodes. You can then create a new DaemonSet with a different template.
|
||||
The new DaemonSet with the different template will recognize all the existing Pods as having
|
||||
matching labels. It will not modify or delete them despite a mismatch in the Pod template.
|
||||
You will need to force new Pod creation by deleting the Pod or deleting the node.
|
||||
--->
|
||||
## 更新 DaemonSet
|
||||
|
||||
如果修改了节点标签（Label），DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除新近不能够匹配的节点上的 Pod。
|
||||
如果修改了节点标签（Label），DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除不能够匹配的节点上的 Pod。
|
||||
|
||||
我们可以修改 DaemonSet 创建的 Pod。然而，不允许对 Pod 的所有字段进行更新。当下次节点（即使具有相同的名称）被创建时，DaemonSet Controller 还会使用最初的模板。
|
||||
您可以修改 DaemonSet 创建的 Pod。然而，不允许对 Pod 的所有字段进行更新。当下次
|
||||
节点（即使具有相同的名称）被创建时，DaemonSet Controller 还会使用最初的模板。
|
||||
|
||||
您可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=false` 选项，则 Pod 将被保留在节点上。然后可以创建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 将能够通过标签匹配并识别所有已经存在的 Pod。它不会修改或删除它们，即使是错误匹配了 Pod 模板。通过删除 Pod 或者删除节点，可以强制创建新的 Pod。
|
||||
|
||||
|
||||
可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=false` 选项，则 Pod 将被保留在节点上。然后可以创建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 将能够通过标签匹配并识别所有已经存在的 Pod。它不会修改或删除它们，即使是错误匹配了 Pod 模板。通过删除 Pod 或者删除节点，可以强制创建新的 Pod。
|
||||
|
||||
<!--
|
||||
In Kubernetes version 1.6 and later, you can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) on a DaemonSet.
|
||||
--->
|
||||
在 Kubernetes 1.6 或以后版本，可以在 DaemonSet 上 [执行滚动升级](/docs/tasks/manage-daemon/update-daemon-set/)。
|
||||
|
||||
未来的 Kubernetes 版本将支持节点的可控更新。
|
||||
<!--
|
||||
## Alternatives to DaemonSet
|
||||
|
||||
### Init Scripts
|
||||
|
||||
It is certainly possible to run daemon processes by directly starting them on a node (e.g. using
|
||||
`init`, `upstartd`, or `systemd`). This is perfectly fine. However, there are several advantages to
|
||||
running such processes via a DaemonSet:
|
||||
|
||||
- Ability to monitor and manage logs for daemons in the same way as applications.
|
||||
- Same config language and tools (e.g. Pod templates, `kubectl`) for daemons and applications.
|
||||
- Running daemons in containers with resource limits increases isolation between daemons from app
|
||||
containers. However, this can also be accomplished by running the daemons in a container but not in a Pod
|
||||
(e.g. start directly via Docker).
|
||||
--->
|
||||
## DaemonSet 的可替代选择
|
||||
|
||||
### init 脚本
|
||||
|
||||
我们很可能希望直接在一个节点上启动 daemon 进程（例如，使用 `init`、`upstartd`、或 `systemd`）。这非常好，但基于 DaemonSet 来运行这些进程有如下一些好处：
|
||||
|
||||
|
||||
|
||||
- 像对待应用程序一样，具备为 daemon 提供监控和管理日志的能力。
|
||||
- 为 daemon 和应用程序使用相同的配置语言和工具（如 Pod 模板、`kubectl`）。
|
||||
- Kubernetes 未来版本可能会支持对 DaemonSet 创建 Pod 与节点升级工作流进行集成。
|
||||
- 在资源受限的容器中运行 daemon，能够增加 daemon 和应用容器的隔离性。然而，这也实现了在容器中运行 daemon，但却不能在 Pod 中运行（例如，直接基于 Docker 启动）。
|
||||
|
||||
<!--
|
||||
### Bare Pods
|
||||
|
||||
|
||||
It is possible to create Pods directly which specify a particular node to run on. However,
|
||||
a DaemonSet replaces Pods that are deleted or terminated for any reason, such as in the case of
|
||||
node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, you should
|
||||
use a DaemonSet rather than creating individual Pods.
|
||||
--->
|
||||
### 裸 Pod
|
||||
|
||||
可能要直接创建 Pod，同时指定其运行在特定的节点上。
|
||||
然而，DaemonSet 替换了由于任何原因被删除或终止的 Pod，例如节点失败、例行节点维护、内核升级。由于这个原因，我们应该使用 DaemonSet 而不是单独创建 Pod。
|
||||
|
||||
可能要直接创建 Pod，同时指定其运行在特定的节点上。然而，DaemonSet 替换了由于任何原因被删除或终止的 Pod，例如节点失败、例行节点维护、内核升级。由于这个原因，我们应该使用 DaemonSet 而不是单独创建 Pod。
|
||||
|
||||
<!--
|
||||
### Static Pods
|
||||
|
||||
It is possible to create Pods by writing a file to a certain directory watched by Kubelet. These
|
||||
are called [static pods](/docs/concepts/cluster-administration/static-pod/).
|
||||
Unlike DaemonSet, static Pods cannot be managed with kubectl
|
||||
or other Kubernetes API clients. Static Pods do not depend on the apiserver, making them useful
|
||||
in cluster bootstrapping cases. Also, static Pods may be deprecated in the future.
|
||||
--->
|
||||
### 静态 Pod
|
||||
|
||||
可能需要通过在一个指定目录下编写文件来创建 Pod，该目录受 Kubelet 所监视。这些 Pod 被称为 [静态 Pod](/docs/concepts/cluster-administration/static-pod/)。
|
||||
不像 DaemonSet，静态 Pod 不受 kubectl 和其它 Kubernetes API 客户端管理。静态 Pod 不依赖于 apiserver，这使得它们在集群启动的情况下非常有用。
|
||||
而且，未来静态 Pod 可能会被废弃掉。
|
||||
不像 DaemonSet，静态 Pod 不受 kubectl 和其它 Kubernetes API 客户端管理。静态 Pod 不依赖于 apiserver，这使得它们在集群启动的情况下非常有用。而且，未来静态 Pod 可能会被废弃掉。
|
||||
|
||||
<!--
|
||||
### Deployments
|
||||
|
||||
DaemonSets are similar to [Deployments](/docs/concepts/workloads/controllers/deployment/) in that
|
||||
they both create Pods, and those Pods have processes which are not expected to terminate (e.g. web servers,
|
||||
storage servers).
|
||||
|
||||
### Replication Controller
|
||||
Use a Deployment for stateless services, like frontends, where scaling up and down the
|
||||
number of replicas and rolling out updates are more important than controlling exactly which host
|
||||
the Pod runs on. Use a DaemonSet when it is important that a copy of a Pod always run on
|
||||
all or certain hosts, and when it needs to start before other Pods.
|
||||
--->
|
||||
### Deployments
|
||||
|
||||
DaemonSet 与 [Replication Controller](/docs/user-guide/replication-controller) 非常类似，它们都能创建 Pod，这些 Pod 对应的进程都不希望被终止掉（例如，Web 服务器、存储服务器）。
|
||||
为无状态的 Service 使用 Replication Controller，比如前端（Frontend）服务，实现对副本的数量进行扩缩容、平滑升级，比之于精确控制 Pod 运行在某个主机上要重要得多。
|
||||
DaemonSet 与 [Deployments](/docs/concepts/workloads/controllers/deployment/)非常类似，它们都能创建 Pod，这些 Pod 对应的进程都不希望被终止掉（例如，Web 服务器、存储服务器）。
|
||||
为无状态的 Service 使用 Deployments，比如前端 Frontend 服务，实现对副本的数量进行扩缩容、平滑升级，比基于精确控制 Pod 运行在某个主机上要重要得多。
|
||||
需要 Pod 副本总是运行在全部或特定主机上，并需要先于其他 Pod 启动，当这被认为非常重要时，应该使用 Daemon Controller。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,19 +2,98 @@
|
||||
title: Kubernetes 文档
|
||||
layout: docsportal_home
|
||||
noedit: true
|
||||
cid: userJourneys
|
||||
css: /css/style_user_journeys.css
|
||||
js: /js/user-journeys/home.js, https://use.fontawesome.com/4bcc658a89.js
|
||||
class: gridPage
|
||||
display_browse_numbers: true
|
||||
linkTitle: "主页"
|
||||
main_menu: true
|
||||
weight: 10
|
||||
hide_feedback: true
|
||||
menu:
|
||||
main:
|
||||
title: "文档"
|
||||
weight: 20
|
||||
post: >
|
||||
<p>通过演练，示例和参考文档了解如何使用 Kubernetes。你甚至可以<a href="/editdocs/" data-auto-burger-exclude>帮助贡献文档</a>！</p>
|
||||
|
||||
overview: >
|
||||
<!-- Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>). -->
|
||||
Kubernetes 是一个开源容器编排引擎，用于容器化应用的自动化部署、扩展和管理。该项目托管在 <a href="https://www.cncf.io/about">CNCF</a>。
|
||||
|
||||
<!-- cards:
|
||||
- name: concepts
|
||||
title: "Understand the basics"
|
||||
description: "Learn about Kubernetes and its fundamental concepts."
|
||||
button: "Learn Concepts"
|
||||
button_path: "/docs/concepts"
|
||||
- name: tutorials
|
||||
title: "Try Kubernetes"
|
||||
description: "Follow tutorials to learn how to deploy applications in Kubernetes."
|
||||
button: "View Tutorials"
|
||||
button_path: "/docs/tutorials"
|
||||
- name: setup
|
||||
title: "Set up a cluster"
|
||||
description: "Get Kubernetes running based on your resources and needs."
|
||||
button: "Set up Kubernetes"
|
||||
button_path: "/docs/setup"
|
||||
- name: tasks
|
||||
title: "Learn how to use Kubernetes"
|
||||
description: "Look up common tasks and how to perform them using a short sequence of steps."
|
||||
button: "View Tasks"
|
||||
button_path: "/docs/tasks"
|
||||
- name: reference
|
||||
title: Look up reference information
|
||||
description: Browse terminology, command line syntax, API resource types, and setup tool documentation.
|
||||
button: View Reference
|
||||
button_path: /docs/reference
|
||||
- name: contribute
|
||||
title: Contribute to the docs
|
||||
description: Anyone can contribute, whether you’re new to the project or you’ve been around a long time.
|
||||
button: Contribute to the docs
|
||||
button_path: /docs/contribute
|
||||
- name: download
|
||||
title: Download Kubernetes
|
||||
description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes.
|
||||
- name: about
|
||||
title: About the documentation
|
||||
description: This website contains documentation for the current and previous 4 versions of Kubernetes. -->
|
||||
|
||||
cards:
|
||||
- name: concepts
|
||||
title: "了解基本知识"
|
||||
description: "了解 Kubernetes 和其基础概念。"
|
||||
button: "了解概念"
|
||||
button_path: "/zh/docs/concepts"
|
||||
- name: tutorials
|
||||
title: "尝试 Kubernetes"
|
||||
description: "按照教程学习如何在 Kubernetes 上部署应用。"
|
||||
button: "查看教程"
|
||||
button_path: "/zh/docs/tutorials"
|
||||
- name: setup
|
||||
title: "设置集群"
|
||||
description: "按照你的资源情况和需求运行 Kubernetes。"
|
||||
button: "设置 Kubernetes"
|
||||
button_path: "/zh/docs/setup"
|
||||
- name: tasks
|
||||
title: "了解如何使用 Kubernetes"
|
||||
description: "查看常见任务以及如何使用简单步骤执行它们。"
|
||||
button: "查看任务"
|
||||
button_path: "/zh/docs/tasks"
|
||||
- name: reference
|
||||
title: 参考
|
||||
description: 术语、命令行语法、API 资源类型和设置工具文档
|
||||
button: 查看参考
|
||||
button_path: /zh/docs/reference
|
||||
- name: contribute
|
||||
title: 为该文档作出贡献
|
||||
description: 任何人，无论对该项目熟悉与否，都能贡献自己的力量。
|
||||
button: 参与贡献
|
||||
button_path: /zh/docs/contribute
|
||||
- name: download
|
||||
title: 下载 Kubernetes
|
||||
description: 如果你正在安装或升级 Kubernetes 的话，最好参考最新的发行版说明。
|
||||
- name: about
|
||||
title: 关于文档
|
||||
description: 该网站包含了当前版本以及前 4 个版本的 Kubernetes 文档。
|
||||
---
|
||||
|
||||
<!--
|
||||
|
||||
@@ -0,0 +1,330 @@
|
||||
---
|
||||
reviewers:
|
||||
- smarterclayton
|
||||
- lavalamp
|
||||
- whitlockjc
|
||||
- caesarxuchao
|
||||
- deads2k
|
||||
- liggitt
|
||||
- mbohlool
|
||||
<!-- title: Dynamic Admission Control -->
|
||||
title: 动态准入控制
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!--
|
||||
The [admission controllers documentation](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
introduces how to use standard, plugin-style admission controllers. However,
|
||||
plugin admission controllers are not flexible enough for all use cases, due to
|
||||
the following:
|
||||
|
||||
* They need to be compiled into kube-apiserver.
|
||||
* They are only configurable when the apiserver starts up.
|
||||
|
||||
*Admission Webhooks* (beta in 1.9) addresses these limitations. It allows
|
||||
admission controllers to be developed out-of-tree and configured at runtime.
|
||||
|
||||
This page describes how to use Admission Webhooks.
|
||||
-->
|
||||
[admission 控制器文档](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
介绍如何使用标准的插件式 admission 控制器。然而，
|
||||
由于以下原因插件 admission 控制器对于所有用例来说都不够灵活：
|
||||
|
||||
* 他们需要编译到 kube-apiserver 里面。
|
||||
* 它们仅在 apiserver 启动时可配置。
|
||||
|
||||
*Admission Webhooks*（1.9 版中的 beta）解决了这些限制。
|
||||
它允许 admission 控制器能被独立开发以及在运行时配置。
|
||||
|
||||
本页介绍如何使用 Admission Webhooks。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
<!-- ### What are admission webhooks? -->
|
||||
### 什么是 admission webhook？
|
||||
|
||||
<!--
|
||||
Admission webhooks are HTTP callbacks that receive admission requests and do
|
||||
something with them. You can define two types of admission webhooks,
|
||||
[validating admission Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
|
||||
and
|
||||
[mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook).
|
||||
With validating admission Webhooks, you may reject requests to enforce custom
|
||||
admission policies. With mutating admission Webhooks, you may change requests to
|
||||
enforce custom defaults.
|
||||
-->
|
||||
Admission webhooks 是 HTTP 回调，它接收 admission 请求并对它们做一些事情。
|
||||
您可以定义两种类型的 admission webhook，
|
||||
[validating admission Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
|
||||
和
|
||||
[mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。
|
||||
通过 validating admission Webhook，您可以拒绝请求以执行自定义的 admission 策略。
|
||||
通过 mutating admission webhook，您可以更改请求以执行自定义的默认值。
|
||||
|
||||
<!--
|
||||
### Experimenting with admission webhooks
|
||||
|
||||
Admission webhooks are essentially part of the cluster control-plane. You should
|
||||
write and deploy them with great caution. Please read the [user
|
||||
guides](/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server) for
|
||||
instructions if you intend to write/deploy production-grade admission webhooks.
|
||||
In the following, we describe how to quickly experiment with admission webhooks.
|
||||
-->
|
||||
### 尝试 admission webhook
|
||||
|
||||
admission webhook 本质上是集群控制平面的一部分。 您应该非常谨慎地编写和部署它们。
|
||||
如果您打算编写/部署生产级 admission webhook，请阅读[用户指南](/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
|
||||
在下文中，我们将介绍如何快速试验 admission webhook。
|
||||
|
||||
<!--
|
||||
### Prerequisites
|
||||
|
||||
* Ensure that the Kubernetes cluster is at least as new as v1.9.
|
||||
|
||||
* Ensure that MutatingAdmissionWebhook and ValidatingAdmissionWebhook
|
||||
admission controllers are enabled.
|
||||
[Here](/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)
|
||||
is a recommended set of admission controllers to enable in general.
|
||||
|
||||
* Ensure that the admissionregistration.k8s.io/v1beta1 API is enabled.
|
||||
-->
|
||||
### 先决条件
|
||||
|
||||
* 确保 Kubernetes 集群版本至少为 v1.9。
|
||||
|
||||
* 确保启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 控制器。
|
||||
[这里](/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)
|
||||
是一组推荐的 admission 控制器，通常可以启用。
|
||||
|
||||
* 确保启用了`admissionregistration.k8s.io/v1beta1` API。
|
||||
|
||||
<!--
|
||||
### Write an admission webhook server
|
||||
|
||||
Please refer to the implementation of the [admission webhook
|
||||
server](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/main.go)
|
||||
that is validated in a Kubernetes e2e test. The webhook handles the
|
||||
`admissionReview` requests sent by the apiservers, and sends back its decision
|
||||
wrapped in `admissionResponse`.
|
||||
|
||||
the `admissionReview` request can have different versions (e.g. v1beta1 or `v1` in a future version).
|
||||
The webhook can define what version they accept using `admissionReviewVersions` field. API server
|
||||
will try to use first version in the list which it supports. If none of the versions specified
|
||||
in this list supported by API server, validation will fail for this object. If the webhook
|
||||
configuration has already been persisted, calls to the webhook will fail and be
|
||||
subject to the failure policy.
|
||||
|
||||
The example admission webhook server leaves the `ClientAuth` field
|
||||
[empty](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48),
|
||||
which defaults to `NoClientCert`. This means that the webhook server does not
|
||||
authenticate the identity of the clients, supposedly apiservers. If you need
|
||||
mutual TLS or other ways to authenticate the clients, see
|
||||
how to [authenticate apiservers](#authenticate-apiservers).
|
||||
-->
|
||||
### 编写一个admission webhook 服务器
|
||||
|
||||
请参阅 Kubernetes e2e 测试中的
|
||||
[admission webhook 服务器](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/main.go)实现。
|
||||
webhook 处理由 apiservers 发送的 `admissionReview` 请求，并将其决定包含在 `admissionResponse` 中发回。
|
||||
|
||||
`admissionReview` 请求可以有不同的版本（例如，`v1beta1` 或未来版本中的 `v1`）。
|
||||
webhook 可以使用 `admissionReviewVersions` 字段定义它们接受的版本。
|
||||
API 服务器将尝试在其支持的列表中使用第一个版本。
|
||||
如果 API 服务器不支持此列表中指定的任何版本，则此对象的验证将失败。
|
||||
如果 webhook 配置依然如此，则对 webhook 的调用将失败并受到失败策略的控制。
|
||||
|
||||
示例 admission webhook 服务器置 `ClientAuth` 字段为
|
||||
[空](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48)，
|
||||
默认为 `NoClientCert` 。这意味着 webhook 服务器不会验证客户端的身份，认为其是 apiservers。
|
||||
如果您需要双向 TLS 或其他方式来验证客户端，请参阅如何[验证 apiservers](#验证 apiservers)。
|
||||
|
||||
<!--
|
||||
### Deploy the admission webhook service
|
||||
|
||||
The webhook server in the e2e test is deployed in the Kubernetes cluster, via
|
||||
the [deployment API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1beta1-apps).
|
||||
The test also creates a [service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)
|
||||
as the front-end of the webhook server. See
|
||||
[code](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/e2e/apimachinery/webhook.go#L227).
|
||||
|
||||
You may also deploy your webhooks outside of the cluster. You will need to update
|
||||
your [webhook client configurations](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L247) accordingly.
|
||||
-->
|
||||
### 部署 admission webhook 服务
|
||||
|
||||
e2e 测试中的 webhook 服务器部署在 Kubernetes 集群中，通过 [deployment API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1beta1-apps)。
|
||||
该测试还创建了 [service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) 作为 webhook 服务器的前端。
|
||||
参见[代码](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/e2e/apimachinery/webhook.go#L227)。
|
||||
|
||||
您还可以在集群外部署 Webhook，
|
||||
这需要相应地更新 [webhook 客户端配置](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L247)。
|
||||
|
||||
<!--
|
||||
### Configure admission webhooks on the fly
|
||||
|
||||
You can dynamically configure what resources are subject to what admission
|
||||
webhooks via
|
||||
[ValidatingWebhookConfiguration](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L84)
|
||||
or
|
||||
[MutatingWebhookConfiguration](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L114).
|
||||
|
||||
The following is an example `validatingWebhookConfiguration`, a mutating webhook
|
||||
configuration is similar.
|
||||
-->
|
||||
### 动态配置 admission webhook
|
||||
|
||||
您可以通过
|
||||
[ValidatingWebhookConfiguration](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L84)
|
||||
或
|
||||
[MutatingWebhookConfiguration](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/api/admissionregistration/v1beta1/types.go#L114)
|
||||
动态配置哪些资源通过哪些 admission webhook
|
||||
|
||||
以下是 `validatingWebhookConfiguration` 的示例，Mutating Webhook Configuration 类似。
|
||||
|
||||
```yaml
|
||||
apiVersion: admissionregistration.k8s.io/v1beta1
|
||||
kind: ValidatingWebhookConfiguration
|
||||
metadata:
|
||||
name: <name of this configuration object>
|
||||
webhooks:
|
||||
- name: <webhook name, e.g., pod-policy.example.io>
|
||||
rules:
|
||||
- apiGroups:
|
||||
- ""
|
||||
apiVersions:
|
||||
- v1
|
||||
operations:
|
||||
- CREATE
|
||||
resources:
|
||||
- pods
|
||||
scope: "Namespaced"
|
||||
clientConfig:
|
||||
service:
|
||||
namespace: <namespace of the front-end service>
|
||||
name: <name of the front-end service>
|
||||
caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
|
||||
admissionReviewVersions:
|
||||
- v1beta1
|
||||
timeoutSeconds: 1
|
||||
```
|
||||
|
||||
<!--
|
||||
The scope field specifies if only cluster-scoped resources ("Cluster") or namespace-scoped
|
||||
resources ("Namespaced") will match this rule. "*" means that there are no scope restrictions.
|
||||
|
||||
{{< note >}}
|
||||
When using `clientConfig.service`, the server cert must be valid for
|
||||
`<svc_name>.<svc_namespace>.svc`.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
Default timeout for a webhook call is 30 seconds but starting in kubernetes 1.14 you
|
||||
can set the timeout and it is encouraged to use a very small timeout for webhooks.
|
||||
If the webhook call times out, the request is handled according to the webhook's
|
||||
failure policy.
|
||||
{{< /note >}}
|
||||
|
||||
When an apiserver receives a request that matches one of the `rules`, the
|
||||
apiserver sends an `admissionReview` request to webhook as specified in the
|
||||
`clientConfig`.
|
||||
|
||||
After you create the webhook configuration, the system will take a few seconds
|
||||
to honor the new configuration.
|
||||
-->
|
||||
scope 字段指定是否只有集群范围的资源（“Cluster”）或命名空间范围的资源（“Namespaced”）才匹配此规则。 “*” 表示没有范围限制。
|
||||
|
||||
{{< note >}}
|
||||
使用`clientConfig.service`时，服务器证书必须对`<svc_name>.<svc_namespace>.svc`有效。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
webhook 调用的默认超时为 30 秒，但从 kubernetes 1.14 开始，您可以设置超时，并鼓励对 webhook 使用非常小的超时时间。
|
||||
如果 webhook 调用超时，则根据 webhook 的失败策略处理请求。
|
||||
{{< /note >}}
|
||||
|
||||
当一个 apiserver 收到一个与 `rules` 之一匹配的请求时，apiserver 会向 `clientConfig` 中指定的 webhook 发送一个 `admissionReview` 请求。
|
||||
|
||||
创建 webhook 配置后，系统将花费几秒钟来完成新配置的生效。
|
||||
|
||||
<!--
|
||||
### Authenticate apiservers
|
||||
|
||||
If your admission webhooks require authentication, you can configure the
|
||||
apiservers to use basic auth, bearer token, or a cert to authenticate itself to
|
||||
the webhooks. There are three steps to complete the configuration.
|
||||
|
||||
* When starting the apiserver, specify the location of the admission control
|
||||
configuration file via the `--admission-control-config-file` flag.
|
||||
|
||||
* In the admission control configuration file, specify where the
|
||||
MutatingAdmissionWebhook controller and ValidatingAdmissionWebhook controller
|
||||
should read the credentials. The credentials are stored in kubeConfig files
|
||||
(yes, the same schema that's used by kubectl), so the field name is
|
||||
`kubeConfigFile`. Here is an example admission control configuration file:
|
||||
-->
|
||||
### 验证 apiservers
|
||||
|
||||
如果您的 webhooks 需要身份验证，您可以将 apiservers 配置为使用基本身份验证，不记名令牌或证书来对 webhook 进行身份验证。
|
||||
完成配置有三个步骤。
|
||||
|
||||
* 启动apiserver时，通过 `--admission-control-config-file` 参数指定许可控制配置文件的位置。
|
||||
|
||||
* 在准入控制配置文件中，指定 MutatingAdmissionWebhook 控制器和 ValidatingAdmissionWebhook 控制器应该读取凭据的位置。
|
||||
凭证存储在 kubeConfig 文件中（是的，与 kubectl 使用的模式相同），因此字段名称为`kubeConfigFile`。
|
||||
以下是一个示例准入控制配置文件：
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.k8s.io/v1alpha1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- name: ValidatingAdmissionWebhook
|
||||
configuration:
|
||||
apiVersion: apiserver.config.k8s.io/v1alpha1
|
||||
kind: WebhookAdmission
|
||||
kubeConfigFile: <path-to-kubeconfig-file>
|
||||
- name: MutatingAdmissionWebhook
|
||||
configuration:
|
||||
apiVersion: apiserver.config.k8s.io/v1alpha1
|
||||
kind: WebhookAdmission
|
||||
kubeConfigFile: <path-to-kubeconfig-file>
|
||||
```
|
||||
|
||||
<!--
|
||||
The schema of `admissionConfiguration` is defined
|
||||
[here](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/apiserver/pkg/apis/apiserver/v1alpha1/types.go#L27).
|
||||
|
||||
* In the kubeConfig file, provide the credentials:
|
||||
-->
|
||||
`admissionConfiguration` 的 shcema 在
|
||||
[这里](https://github.com/kubernetes/kubernetes/blob/v1.13.0/staging/src/k8s.io/apiserver/pkg/apis/apiserver/v1alpha1/types.go#L27).
|
||||
|
||||
* 在 kubeConfig 文件中，提供凭据：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
users:
|
||||
# DNS name of webhook service, i.e., <service name>.<namespace>.svc, or the URL
|
||||
# of the webhook server.
|
||||
- name: 'webhook1.ns1.svc'
|
||||
user:
|
||||
client-certificate-data: <pem encoded certificate>
|
||||
client-key-data: <pem encoded key>
|
||||
# The `name` supports using * to wildmatch prefixing segments.
|
||||
- name: '*.webhook-company.org'
|
||||
user:
|
||||
password: <password>
|
||||
username: <name>
|
||||
# '*' is the default match.
|
||||
- name: '*'
|
||||
user:
|
||||
token: <token>
|
||||
```
|
||||
|
||||
<!--
|
||||
Of course you need to set up the webhook server to handle these authentications.
|
||||
-->
|
||||
当然，您需要设置 webhook 服务器来处理这些身份验证。
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: sysctl
|
||||
id: sysctl
|
||||
date: 2019-02-12
|
||||
full_link: /docs/tasks/administer-cluster/sysctl-cluster/
|
||||
short_description: >
|
||||
用于获取和设置 Unix 内核参数的接口
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- 工具
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: sysctl
|
||||
id: sysctl
|
||||
date: 2019-02-12
|
||||
full_link: /docs/tasks/administer-cluster/sysctl-cluster/
|
||||
short_description: >
|
||||
An interface for getting and setting Unix kernel parameters
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
`sysctl` is a semi-standardized interface for reading or changing the
|
||||
attributes of the running Unix kernel.
|
||||
-->
|
||||
|
||||
`sysctl` 是一个半标准化的接口，用于读取或更改正在运行的 Unix 内核的属性。
|
||||
|
||||
<!--more-->
|
||||
|
||||
<!--
|
||||
On Unix-like systems, `sysctl` is both the name of the tool that administrators
|
||||
use to view and modify these settings, and also the system call that the tool
|
||||
uses.
|
||||
-->
|
||||
|
||||
在类 Unix 系统上， `sysctl` 既是管理员用于查看和修改这些设置的工具的名称，也是该工具所调用的系统调用的名称。
|
||||
|
||||
<!--
|
||||
{{< glossary_tooltip text="Container" term_id="container" >}} runtimes and
|
||||
network plugins may rely on `sysctl` values being set a certain way.
|
||||
-->
|
||||
|
||||
{{< glossary_tooltip text="容器" term_id="container" >}} 运行时和网络插件可能对 `sysctl` 的取值有一定的要求。
|
||||
+139
@@ -0,0 +1,139 @@
|
||||
|
||||
<!-- Generates a kubeconfig file for the controller manager to use -->
|
||||
为控制器管理器生成要使用的 kubeconfig 文件
|
||||
|
||||
<!-- ### Synopsis -->
|
||||
### 概要
|
||||
|
||||
|
||||
<!-- Generates the kubeconfig file for the controller manager to use and saves it to controller-manager.conf file -->
|
||||
生成控制器管理器要使用的 kubeconfig ，并保存到 controller-manager.conf 文件中
|
||||
|
||||
```
|
||||
kubeadm init phase kubeconfig controller-manager [flags]
|
||||
```
|
||||
|
||||
<!-- ### Options -->
|
||||
### 选项
|
||||
|
||||
<table style="width: 100%; table-layout: fixed;">
|
||||
<colgroup>
|
||||
<col span="1" style="width: 10px;" />
|
||||
<col span="1" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">--apiserver-advertise-address string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address the API Server will advertise it's listening on. Specify '0.0.0.0' to use the address of the default network interface.</td>
|
||||
</tr> -->
|
||||
<tr>
|
||||
<td colspan="2">--apiserver-advertise-address 字符串</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;"> API Server 对外发布的当前监听地址。设置此值为 “0.0.0.0” 以使用默认网络接口的 IP 地址。</td>
|
||||
</tr>
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">--apiserver-bind-port int32 Default: 6443</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Port for the API Server to bind to.</td>
|
||||
</tr> -->
|
||||
<tr>
|
||||
<td colspan="2">--apiserver-bind-port int32
|
||||
默认值: 6443</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">要绑定到 API Server 的端口。</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">--cert-dir string Default: "/etc/kubernetes/pki"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The path where to save and store the certificates.</td>
|
||||
</tr> -->
|
||||
<tr>
|
||||
<td colspan="2">--cert-dir string 默认值: "/etc/kubernetes/pki"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">保存和存储证书的路径。</td>
|
||||
</tr>
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">--config string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to kubeadm config file. WARNING: Usage of a configuration file is experimental.</td>
|
||||
</tr> -->
|
||||
<tr>
|
||||
<td colspan="2">--config string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;"> kubeadm 配置文件的路径。警告：配置文件的使用是实验性的。</td>
|
||||
</tr>
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">-h, --help</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">help for controller-manager</td>
|
||||
</tr> -->
|
||||
<tr>
|
||||
<td colspan="2">-h, --help</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;"> controller-manager 命令的帮助</td>
|
||||
</tr>
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">--kubeconfig-dir string Default: "/etc/kubernetes"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The path where to save the kubeconfig file.</td>
|
||||
</tr> -->
|
||||
<tr>
|
||||
<td colspan="2">--kubeconfig-dir string
|
||||
默认值: "/etc/kubernetes"</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">保存 kubeconfig 的路径。</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!-- ### Options inherited from parent commands -->
|
||||
### 从父命令继承的选项
|
||||
|
||||
<table style="width: 100%; table-layout: fixed;">
|
||||
<colgroup>
|
||||
<col span="1" style="width: 10px;" />
|
||||
<col span="1" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">--rootfs string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td>
|
||||
</tr> -->
|
||||
<tr>
|
||||
<td colspan="2">--rootfs 字符串</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">[实验] 主机根文件系统的“真实”路径。</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
+111
@@ -0,0 +1,111 @@
|
||||
|
||||
<!-- Mark a node as a control-plane -->
|
||||
将节点标记为控制平面
|
||||
|
||||
<!-- ### Synopsis -->
|
||||
### 概要
|
||||
|
||||
|
||||
<!-- Mark a node as a control-plane -->
|
||||
将节点标记为控制平面
|
||||
|
||||
```
|
||||
kubeadm init phase mark-control-plane [flags]
|
||||
```
|
||||
|
||||
<!-- ### Examples -->
|
||||
### 例子
|
||||
|
||||
```
|
||||
# 将控制平面的标签和污点应用于当前节点，功能上等同于 kubeadm init 执行的操作。
|
||||
kubeadm init phase mark-control-plane --config config.yml
|
||||
|
||||
# 将控制平面的标签和污点应用于特定节点
|
||||
kubeadm init phase mark-control-plane --node-name myNode
|
||||
```
|
||||
|
||||
<!-- ### Options -->
|
||||
### 选项
|
||||
|
||||
<table style="width: 100%; table-layout: fixed;">
|
||||
<colgroup>
|
||||
<col span="1" style="width: 10px;" />
|
||||
<col span="1" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">--config string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to kubeadm config file. WARNING: Usage of a configuration file is experimental.</td>
|
||||
</tr> -->
|
||||
<tr>
|
||||
<td colspan="2">--config string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;"> kubeadm 配置文件的路径。 警告：配置文件的使用是实验性的。</td>
|
||||
</tr>
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">-h, --help</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">help for mark-control-plane</td>
|
||||
</tr> -->
|
||||
|
||||
<tr>
|
||||
<td colspan="2">-h, --help</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;"> mark-control-plane 命令的帮助</td>
|
||||
</tr>
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">--node-name string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Specify the node name.</td>
|
||||
</tr> -->
|
||||
|
||||
<tr>
|
||||
<td colspan="2">--node-name string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">指定节点名称。</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<!-- ### Options inherited from parent commands -->
|
||||
<!-- ### Options inherited from parent commands -->
|
||||
### 从父命令继承的选项
|
||||
|
||||
<table style="width: 100%; table-layout: fixed;">
|
||||
<colgroup>
|
||||
<col span="1" style="width: 10px;" />
|
||||
<col span="1" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
|
||||
<!-- <tr>
|
||||
<td colspan="2">--rootfs string</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td>
|
||||
</tr> -->
|
||||
<tr>
|
||||
<td colspan="2">--rootfs 字符串</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">主机根文件系统的“真实”路径。</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
@@ -458,35 +458,61 @@ kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
|
||||
|
||||
{{% tab name="Cilium" %}}
|
||||
有关将 Cilium 与 Kubernetes 一起使用的更多信息，请参阅[关于 Kubernetes 的 Cilium 快速入门](http://docs.cilium.io/en/v1.2/kubernetes/quickinstall/) 和 [适用于 Ciliu m的 kubernetes 安装指南](http://docs.cilium.io/en/v1.2/kubernetes/install/)。
|
||||
<!--
|
||||
For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
|
||||
|
||||
不需要将 `--pod-network-cidr` 选项传递给 `kubeadm init`，但强烈推荐你这么做。
|
||||
For Cilium to work correctly, you must pass `--pod-network-cidr=10.217.0.0/16` to `kubeadm init`.
|
||||
|
||||
这些命令将通过 etcd 运算器管理的自己的 etcd 以部署 Cilium。
|
||||
These commands will deploy Cilium with its own etcd managed by etcd operator.
|
||||
|
||||
_Note_: If you are running kubeadm in a single node please untaint it so that
|
||||
etcd-operator pods can be scheduled in the control-plane node.
|
||||
|
||||
```shell
|
||||
# 从 Cilium 仓库下载所需的清单
|
||||
wget https://github.com/cilium/cilium/archive/v1.2.0.zip
|
||||
unzip v1.2.0.zip
|
||||
cd cilium-1.2.0/examples/kubernetes/addons/etcd-operator
|
||||
|
||||
# 生成并部署 etcd 证书
|
||||
export CLUSTER_DOMAIN=$(kubectl get ConfigMap --namespace kube-system coredns -o yaml | awk '/kubernetes/ {print $2}')
|
||||
tls/certs/gen-cert.sh $CLUSTER_DOMAIN
|
||||
tls/deploy-certs.sh
|
||||
|
||||
# 标记具有固定标识标签的 kube-dns
|
||||
kubectl label -n kube-system pod $(kubectl -n kube-system get pods -l k8s-app=kube-dns -o jsonpath='{range .items[]}{.metadata.name}{" "}{end}') io.cilium.fixed-identity=kube-dns
|
||||
|
||||
kubectl create -f ./
|
||||
|
||||
# 等待几分钟，让 Cilium、coredns 和 etcd pod 收敛到工作状态
|
||||
kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-
|
||||
```
|
||||
|
||||
To deploy Cilium you just need to run:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium.yaml
|
||||
```
|
||||
|
||||
Once all Cilium pods are marked as `READY`, you start using your cluster.
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -n kube-system --selector=k8s-app=cilium
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-drxkl 1/1 Running 0 18m
|
||||
```
|
||||
|
||||
-->
|
||||
有关将 Cilium 与 Kubernetes 一起使用的更多信息，请参阅[适用于 Cilium 的 Kubernetes 安装指南](https://docs.cilium.io/en/stable/kubernetes/)。
|
||||
|
||||
为了使 Cilium 正确工作，您必须向 `kubeadm init` 传递 `--pod-network-cidr=10.217.0.0/16` 参数。
|
||||
|
||||
以下命令将部署 Cilium，包括其运行需要的 etcd（被 etcd operator 管理）。
|
||||
|
||||
_注意_: 如果您在单节点运行 kubeadm，您需要解除该节点的污点（untaint），以便 etcd-operator pod 能被调度到该控制节点。
|
||||
|
||||
```shell
|
||||
kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-
|
||||
```
|
||||
|
||||
部署 Cilium，您只需执行：
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium.yaml
|
||||
```
|
||||
|
||||
一旦所有的 Cilium pod 的状态变成 `READY`，您就可以开始使用集群了。
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -n kube-system --selector=k8s-app=cilium
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-drxkl 1/1 Running 0 18m
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
|
||||
@@ -0,0 +1,218 @@
|
||||
---
|
||||
title: 联邦集群
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Federated Cluster
|
||||
content_template: templates/task
|
||||
---
|
||||
-->
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< deprecationfilewarning >}}
|
||||
{{< include "federation-deprecation-warning-note.md" >}}
|
||||
{{< /deprecationfilewarning >}}
|
||||
|
||||
<!--
|
||||
This guide explains how to use Clusters API resource in a Federation control plane.
|
||||
|
||||
Different than other Kubernetes resources, such as Deployments, Services and ConfigMaps,
|
||||
clusters only exist in the federation context, i.e. those requests must be submitted to the
|
||||
federation api-server.
|
||||
-->
|
||||
本指南介绍了如何在联邦控制平面中使用集群 API 资源。
|
||||
|
||||
与其他 Kubernetes 资源（例如 Deployment，Service 和 ConfigMap）不同， 集群资源仅存在于联邦上下文中，即这些请求必须提交给联邦 api-server。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
* {{< include "federated-task-tutorial-prereqs.md" >}}
|
||||
<!--
|
||||
* You should also have a basic [working knowledge of Kubernetes](/docs/setup/pick-right-solution/) in
|
||||
general.
|
||||
-->
|
||||
* 你还应该对 [Kubernetes 的工作方式](/docs/setup/pick-right-solution/)有基本的认识。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
<!--
|
||||
## Listing Clusters
|
||||
|
||||
To list the clusters available in your federation, you can use [kubectl](/docs/user-guide/kubectl/) by
|
||||
running:
|
||||
|
||||
``` shell
|
||||
kubectl --context=federation get clusters
|
||||
```
|
||||
|
||||
The `--context=federation` flag tells kubectl to submit the
|
||||
request to the Federation apiserver instead of sending it to a Kubernetes
|
||||
cluster. If you submit it to a k8s cluster, you will receive an error saying
|
||||
|
||||
```the server doesn't have a resource type "clusters"```
|
||||
|
||||
If you passed the correct Federation context but received a message error saying
|
||||
|
||||
```No resources found.```
|
||||
|
||||
it means that you haven't
|
||||
added any cluster to the Federation yet.
|
||||
-->
|
||||
## 列出集群
|
||||
|
||||
要列出联邦中可用的集群，可以使用 [kubectl](/docs/user-guide/kubectl/) 运行：
|
||||
|
||||
``` shell
|
||||
kubectl --context=federation get clusters
|
||||
```
|
||||
|
||||
`--context=federation` 参数告诉 kubectl 将请求提交到联邦 apiserver 而不是发送给 Kubernetes 集群。如果您将其提交给 k8s 集群，您将会收到如下的错误信息：
|
||||
|
||||
```the server doesn't have a resource type "clusters"```
|
||||
|
||||
如果您传递了正确的联邦上下文，但却收到错误消息：
|
||||
|
||||
```No resources found.```
|
||||
|
||||
这表示您尚未将任何集群添加到联邦。
|
||||
|
||||
<!--
|
||||
## Creating a Federated Cluster
|
||||
|
||||
Creating a `cluster` resource in federation means joining it to the federation. To do so, you can use
|
||||
`kubefed join`. Basically, you need to give the new cluster a name and say what is the name of the
|
||||
context that corresponds to a cluster that hosts the federation. The following example command adds
|
||||
the cluster `gondor` to the federation running on host cluster `rivendell`:
|
||||
|
||||
``` shell
|
||||
kubefed join gondor --host-cluster-context=rivendell
|
||||
```
|
||||
|
||||
You can find more details on how to do that in the respective section in the
|
||||
[kubefed guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/#adding-a-cluster-to-a-federation).
|
||||
-->
|
||||
## 创建联邦集群
|
||||
|
||||
在联邦中创建 `cluster` 资源意味着将其加入联邦。您也可以使用 `kubefed join` 命令实现该操作。大体上，您需要给新的集群一个名字，并指出联邦主集群对应的上下文名称。以下示例命令将集群 `gondor` 加入运行于主集群 `rivendell` 上的联邦中：
|
||||
|
||||
``` shell
|
||||
kubefed join gondor --host-cluster-context=rivendell
|
||||
```
|
||||
|
||||
您可以在 [kubefed 指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/#adding-a-cluster-to-a-federation)的相应部分找到更多关于如何做到这一点的详细介绍。
|
||||
|
||||
<!--
|
||||
## Deleting a Federated Cluster
|
||||
|
||||
Converse to creating a cluster, deleting a cluster means unjoining this cluster from the
|
||||
federation. This can be done with `kubefed unjoin` command. To remove the `gondor` cluster, just do:
|
||||
|
||||
``` shell
|
||||
kubefed unjoin gondor --host-cluster-context=rivendell
|
||||
```
|
||||
|
||||
You can find more details on unjoin in the
|
||||
[kubefed guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/#removing-a-cluster-from-a-federation).
|
||||
-->
|
||||
|
||||
## 删除联邦集群
|
||||
|
||||
与创建集群相反，删除集群表示将集群从联邦中退出。这可以通过 `kubefed unjoin` 完成。要删除 `gondor` 集群，只需要执行：
|
||||
|
||||
``` shell
|
||||
kubefed unjoin gondor --host-cluster-context=rivendell
|
||||
```
|
||||
|
||||
您可以在 [kubefed 指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/#adding-a-cluster-to-a-federation)中找到更多关于 unjoin 的详细介绍。
|
||||
|
||||
<!--
|
||||
## Labeling Clusters
|
||||
|
||||
You can label clusters the same way as any other Kubernetes object, which can help with grouping clusters and can also be leveraged by the ClusterSelector.
|
||||
|
||||
``` shell
|
||||
kubectl --context=rivendell label cluster gondor key1=value1 key2=value2
|
||||
```
|
||||
-->
|
||||
## 标记集群
|
||||
|
||||
您可以使用与其它 Kubernetes 对象相同的方式标记集群，这有助于集群分组，也可以被 ClusterSelector 利用。
|
||||
|
||||
``` shell
|
||||
kubectl --context=rivendell label cluster gondor key1=value1 key2=value2
|
||||
```
|
||||
|
||||
<!--
|
||||
## ClusterSelector Annotation
|
||||
|
||||
Starting in Kubernetes 1.7, there is alpha support for directing objects across the federated clusters with the annotation `federation.alpha.kubernetes.io/cluster-selector`. The *ClusterSelector* is conceptually similar to `nodeSelector`, but instead of selecting against labels on nodes, it selects against labels on federated clusters.
|
||||
|
||||
The annotation value must be JSON formatted and must be parsable into the [ClusterSelector API type](/docs/reference/federation/v1beta1/definitions/#_v1beta1_clusterselector). For example: `[{"key": "load", "operator": "Lt", "values": ["10"]}]`. Content that doesn't parse correctly will throw an error and prevent distribution of the object to any federated clusters. Objects of type ConfigMap, Secret, Daemonset, Service and Ingress are included in the alpha implementation.
|
||||
|
||||
Here is an example ClusterSelector annotation, which will only select clusters WITH the label `pci=true` and WITHOUT the label `environment=test`:
|
||||
|
||||
``` yaml
|
||||
metadata:
|
||||
annotations:
|
||||
federation.alpha.kubernetes.io/cluster-selector: '[{"key": "pci", "operator":
|
||||
"In", "values": ["true"]}, {"key": "environment", "operator": "NotIn", "values":
|
||||
["test"]}]'
|
||||
```
|
||||
|
||||
The *key* is matched against label names on the federated clusters.
|
||||
|
||||
The *values* are matched against the label values on the federated clusters.
|
||||
|
||||
The possible *operators* are: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
|
||||
|
||||
The *values* field is expected to be empty when `Exists` or `DoesNotExist` is specified and may include more than one string when `In` or `NotIn` are used.
|
||||
|
||||
Currently, only integers are supported with `Gt` or `Lt`.
|
||||
-->
|
||||
## ClusterSelector 注解
|
||||
|
||||
从 Kubernetes 1.7 版本开始，alpha 支持通过注解 `federation.alpha.kubernetes.io/cluster-selector` 来指示跨联邦集群的对象。*ClusterSelector* 在概念上与 `nodeSelector` 类似，但不是针对节点上的标签进行选择，而是针对联邦集群上的标签进行选择。
|
||||
|
||||
注解值必须为 JSON 格式，并且必须可以解析为 [ClusterSelector API 类型](/docs/reference/federation/v1beta1/definitions/#_v1beta1_clusterselector)。例如：`[{"key": "load", "operator": "Lt", "values": ["10"]}]`。无法正确解析的内容将引发错误并阻止将对象分发到任何联邦集群。Alpha 实现中包含 ConfigMap、Secret、Daemonset、Service 和 Ingress 类型的对象。
|
||||
|
||||
下面是一个 ClusterSelector 注解的示例，它只会选择带有 `pci=true` 且没有 `environment=test` 的集群：
|
||||
|
||||
``` yaml
|
||||
metadata:
|
||||
annotations:
|
||||
federation.alpha.kubernetes.io/cluster-selector: '[{"key": "pci", "operator":
|
||||
"In", "values": ["true"]}, {"key": "environment", "operator": "NotIn", "values":
|
||||
["test"]}]'
|
||||
```
|
||||
|
||||
*key* 用于匹配联邦集群上的标签名。
|
||||
|
||||
*values* 用于匹配联邦集群上的标签值。
|
||||
|
||||
可能的 *operator* 有：`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`。
|
||||
|
||||
当指定 `Exists` 或 `DoesNotExist` 时，*values* 字段应为空。使用 `In` 或 `NotIn` 时，可能包含多个字符串。
|
||||
|
||||
目前，`Gt` 或 `Lt` 仅支持整数。
|
||||
|
||||
|
||||
<!--
|
||||
## Clusters API reference
|
||||
|
||||
The full clusters API reference is currently in `federation/v1beta1` and more details can be found in the
|
||||
[Federation API reference page](/docs/reference/federation/).
|
||||
-->
|
||||
## 集群 API 参考
|
||||
|
||||
完整的集群 API 参考在 `federation/v1beta1` 中，更多细节可以在 [联邦 API 参考页面](/docs/reference/federation/)找到。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -1,22 +1,41 @@
|
||||
---
|
||||
approvers:
|
||||
reviewers:
|
||||
- derekwaynecarr
|
||||
title: 管理巨页（HugePages）
|
||||
content_template: templates/task
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- derekwaynecarr
|
||||
title: Manage HugePages
|
||||
content_template: templates/task
|
||||
---
|
||||
--->
|
||||
|
||||
{{% capture overview %}}
|
||||
{{< feature-state state="alpha" >}}
|
||||
{{< feature-state state="stable" >}}
|
||||
|
||||
作为 **alpha** 特性，Kubernetes 支持在 Pod 应用中使用预先分配的巨页（或称“大页面”，下文统称为“巨页”）。 本文描述了用户如何使用巨页，以及当前的限制。
|
||||
<!--
|
||||
Kubernetes supports the allocation and consumption of pre-allocated huge pages
|
||||
by applications in a Pod as a **GA** feature. This page describes how users
|
||||
can consume huge pages and the current limitations.
|
||||
--->
|
||||
作为 **GA** 特性，Kubernetes 支持在 Pod 应用中使用预先分配的巨页。本文描述了用户如何使用巨页，以及当前的限制。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
1. 为了使节点能够上报巨页容量，Kubernetes 节点必须预先分配巨页。
|
||||
每个节点只能预先分配一种特定规格的巨页。
|
||||
1. 用户必须在整个系统中将专用的 **alpha** 特性开关 `HugePages` 设置为 true： `--feature-gates=HugePages=true`。
|
||||
<!--
|
||||
1. Kubernetes nodes must pre-allocate huge pages in order for the node to report
|
||||
its huge page capacity. A node may only pre-allocate huge pages for a single
|
||||
size.
|
||||
|
||||
The nodes will automatically discover and report all huge page resources as a
|
||||
schedulable resource.
|
||||
--->
|
||||
1. 为了使节点能够上报巨页容量，Kubernetes 节点必须预先分配巨页。每个节点只能预先分配一种特定规格的巨页。
|
||||
|
||||
节点会自动发现全部巨页资源，并作为可供调度的资源进行上报。
|
||||
|
||||
@@ -26,7 +45,18 @@ content_template: templates/task
|
||||
|
||||
## API
|
||||
|
||||
<!--
|
||||
Huge pages can be consumed via container level resource requirements using the
|
||||
resource name `hugepages-<size>`, where size is the most compact binary notation
|
||||
using integer values supported on a particular node. For example, if a node
|
||||
supports 2048KiB page sizes, it will expose a schedulable resource
|
||||
`hugepages-2Mi`. Unlike CPU or memory, huge pages do not support overcommit. Note
|
||||
that when requesting hugepage resources, either memory or CPU resources must
|
||||
be requested as well.
|
||||
--->
|
||||
|
||||
用户可以通过在容器级别的资源需求中使用资源名称 `hugepages-<size>` 来使用巨页，其中的 size 是特定节点上支持的以整数值表示的最小二进制单位。 例如，如果节点支持 2048KiB 的页面规格， 它将暴露可供调度的资源 `hugepages-2Mi`。 与 CPU 或内存不同，巨页不支持过量使用（overcommit）。
|
||||
注意，在请求巨页资源时，还必须请求内存或 CPU 资源。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -46,23 +76,49 @@ spec:
|
||||
resources:
|
||||
limits:
|
||||
hugepages-2Mi: 100Mi
|
||||
memory: 100Mi
|
||||
requests:
|
||||
memory: 100Mi
|
||||
volumes:
|
||||
- name: hugepage
|
||||
emptyDir:
|
||||
medium: HugePages
|
||||
```
|
||||
|
||||
- 巨页的资源需求和限制必须相等。 该条件在指定了资源限制，而没有指定需求的情况下默认成立。
|
||||
<!--
|
||||
- Huge page requests must equal the limits. This is the default if limits are
|
||||
specified, but requests are not.
|
||||
- Huge pages are isolated at a pod scope, container isolation is planned in a
|
||||
future iteration.
|
||||
- EmptyDir volumes backed by huge pages may not consume more huge page memory
|
||||
than the pod request.
|
||||
- Applications that consume huge pages via `shmget()` with `SHM_HUGETLB` must
|
||||
run with a supplemental group that matches `proc/sys/vm/hugetlb_shm_group`.
|
||||
- Huge page usage in a namespace is controllable via ResourceQuota similar
|
||||
to other compute resources like `cpu` or `memory` using the `hugepages-<size>`
|
||||
token.
|
||||
--->
|
||||
|
||||
- 巨页的资源请求值必须等于其限制值。该条件在指定了资源限制，而没有指定请求的情况下默认成立。
|
||||
- 巨页是被隔离在 pod 作用域的，计划在将来的迭代中实现容器级别的隔离。
|
||||
- 巨页对 EmptyDir 卷提供支持，EmptyDir 卷所使用的巨页，不能够超出 pod 请求的内存容量。
|
||||
- 巨页可用于 EmptyDir 卷，不过 EmptyDir 卷所使用的巨页数量不能够超出 Pod 请求的巨页数量。
|
||||
- 通过带有 `SHM_HUGETLB` 的 `shmget()` 使用巨页的应用，必须运行在一个与
|
||||
`proc/sys/vm/hugetlb_shm_group` 匹配的补充组下。
|
||||
- 通过 ResourceQuota 资源，可以使用 `hugepages-<size>` 标记控制每个命名空间下的巨页使用量，
|
||||
类似于使用 `cpu` 或 `memory` 来控制其他计算资源。
|
||||
|
||||
## （待实现的）特性
|
||||
<!--
|
||||
## Future
|
||||
|
||||
- Support container isolation of huge pages in addition to pod isolation.
|
||||
- NUMA locality guarantees as a feature of quality of service.
|
||||
- LimitRange support.
|
||||
--->
|
||||
|
||||
## 待实现的特性
|
||||
|
||||
- 在 pod 级别隔离的基础上，支持巨页在容器级别的隔离。
|
||||
- 作为服务质量特性，保证巨页的 NUMA 局部性。
|
||||
- 支持 ResourceQuota 。
|
||||
- 支持 LimitRange 。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -17,7 +17,7 @@ content_template: templates/concept
|
||||
{{% capture overview %}}
|
||||
|
||||
Kubernetes 文档的这一部分包含教程。一个教程展示了如何完成一个比单个[任务](/docs/tasks/)更大的目标。
|
||||
通常，通常一个教程有几个部分，每个部分都有一系列步骤。在浏览每个教程之前，
|
||||
通常一个教程有几个部分，每个部分都有一系列步骤。在浏览每个教程之前，
|
||||
您可能希望将[标准化术语表](/docs/reference/glossary/)页面添加到书签，供以后参考。
|
||||
|
||||
<!--
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
<!--
|
||||
Use of `Federation v1` is strongly discouraged. `Federation V1` never achieved GA status and is no longer under active development. Documentation is for historical purposes only.
|
||||
|
||||
For more information, see the intended replacement, [Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2).
|
||||
-->
|
||||
强烈建议不要使用`联邦 v1 版本`，`联邦 v1 版本`从未达到 GA 状态，且不再处于积极开发阶段。文档仅作为历史参考。
|
||||
|
||||
有关更多信息，请参阅预期的替代品 [Kubernetes 联邦 v2 版本](https://github.com/kubernetes-sigs/federation-v2)。
|
||||
Reference in New Issue
Block a user