Merge release1.14 into master (#16543)
* initial commit * promote AWS-NLB Support from alpha to beta (#14451) (#16459) (#16484) * 1. Sync release-1.15 into master 2. Sync with en version * 1. Add the lost yaml file. * Update he cluster administration folder of concepts 1. Sync with 1.14 branch 2. Sync with en version * Add yaml files which are used * 1. Sync the configuration folder from 1.14 version 2. Sync the configuration folder files with en version 3. Changed some files structure for easily review 4. Add glossary folder for fixup build error
This commit is contained in:
成臣 Chengchen
Kubernetes Prow Robot
parent
94efd836f8
commit
648baf13ad
|
|
@ -14,7 +14,9 @@ weight: 40
|
|||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!-- The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your cluster, and helps you obtain a deeper understanding of how Kubernetes works. -->
|
||||
<!--
|
||||
The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}, and helps you obtain a deeper understanding of how Kubernetes works.
|
||||
-->
|
||||
|
||||
概念部分可以帮助你了解 Kubernetes 的各个组成部分以及 Kubernetes 用来表示集群的一些抽象概念，并帮助你更加深入的理解 Kubernetes 是如何工作的。
|
||||
|
||||
|
|
@ -22,37 +24,51 @@ weight: 40
|
|||
|
||||
{{% capture body %}}
|
||||
|
||||
<!-- ## Overview -->
|
||||
<!--
|
||||
## Overview
|
||||
-->
|
||||
|
||||
## 概述
|
||||
|
||||
<!-- To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state. -->
|
||||
<!--
|
||||
To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
|
||||
-->
|
||||
|
||||
要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的*预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl` 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。
|
||||
要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的 *预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl` 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。
|
||||
|
||||
<!-- Once you've set your desired state, the *Kubernetes Control Plane* works to make the cluster's current state match the desired state. To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster: -->
|
||||
<!--
|
||||
Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator (PLEG). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
|
||||
-->
|
||||
|
||||
一旦你设置了你所需的目标状态，*Kubernetes 控制面（control plane）* 会促成集群的当前状态符合其预期状态。为此，Kubernetes 会自动执行各类任务，比如运行或者重启容器、调整给定应用的副本数等等。Kubernetes 控制面由一组运行在集群上的进程组成：
|
||||
一旦你设置了你所需的目标状态，*Kubernetes 控制面（control plane）* 会通过 Pod 生命周期事件生成器( PLEG )，促成集群的当前状态符合其预期状态。为此，Kubernetes 会自动执行各类任务，比如运行或者重启容器、调整给定应用的副本数等等。Kubernetes 控制面由一组运行在集群上的进程组成：
|
||||
|
||||
<!-- * The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
|
||||
<!--
|
||||
* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
|
||||
* Each individual non-master node in your cluster runs two processes:
|
||||
* **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node. -->
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
|
||||
-->
|
||||
|
||||
* **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节上，通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/)和[kube-scheduler](/docs/admin/kube-scheduler/)。
|
||||
* **Kubernetes 主控组件（Master）** 包含三个进程，都运行在集群中的某个节上，通常这个节点被称为 master 节点。这些进程包括：[kube-apiserver](/docs/admin/kube-apiserver/)、[kube-controller-manager](/docs/admin/kube-controller-manager/) 和 [kube-scheduler](/docs/admin/kube-scheduler/)。
|
||||
* 集群中的每个非 master 节点都运行两个进程：
|
||||
* **[kubelet](/docs/admin/kubelet/)**，和 master 节点进行通信。
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。
|
||||
|
||||
<!-- ## Kubernetes Objects -->
|
||||
<!--
|
||||
## Kubernetes Objects
|
||||
-->
|
||||
|
||||
## Kubernetes 对象
|
||||
|
||||
<!-- Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details. -->
|
||||
<!--
|
||||
Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details.
|
||||
-->
|
||||
|
||||
Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。
|
||||
Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes 对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。
|
||||
|
||||
<!-- The basic Kubernetes objects include: -->
|
||||
<!--
|
||||
The basic Kubernetes objects include:
|
||||
-->
|
||||
|
||||
基本的 Kubernetes 对象包括：
|
||||
|
||||
|
|
@ -61,7 +77,9 @@ Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容
|
|||
* [Volume](/docs/concepts/storage/volumes/)
|
||||
* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
<!-- In addition, Kubernetes contains a number of higher-level abstractions called Controllers. Controllers build upon the basic objects, and provide additional functionality and convenience features. They include: -->
|
||||
<!--
|
||||
In addition, Kubernetes contains a number of higher-level abstractions called Controllers. Controllers build upon the basic objects, and provide additional functionality and convenience features. They include:
|
||||
-->
|
||||
|
||||
另外，Kubernetes 包含大量的被称作*控制器（controllers）* 的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括：
|
||||
|
||||
|
|
@ -71,52 +89,75 @@ Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容
|
|||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
|
||||
<!-- ## Kubernetes Control Plane -->
|
||||
<!--
|
||||
## Kubernetes Control Plane
|
||||
-->
|
||||
|
||||
## Kubernetes 控制面
|
||||
|
||||
<!-- The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided. -->
|
||||
<!--
|
||||
The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided.
|
||||
-->
|
||||
|
||||
关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程，管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任一的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。
|
||||
关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程），管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任意的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。
|
||||
|
||||
<!-- For example, when you use the Kubernetes API to create a Deployment object, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state. -->
|
||||
<!--
|
||||
For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state.
|
||||
-->
|
||||
|
||||
比如， 当你通过 Kubernetes API 创建一个 Deployment 对象，你就为系统增加了一个新的目标状态。Kubernetes 控制平面记录着对象的创建，并启动必要的应用然后将它们调度至集群某个节点上来执行你的指令，以此来保持集群的实际状态和目标状态的匹配。
|
||||
|
||||
<!-- ### Kubernetes Master -->
|
||||
<!--
|
||||
### Kubernetes Master
|
||||
-->
|
||||
|
||||
### Kubernetes Master 节点
|
||||
|
||||
<!-- The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master. -->
|
||||
<!--
|
||||
The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master.
|
||||
-->
|
||||
|
||||
Kubernetes master 节点负责维护集群的目标状态。当你要与 Kubernetes 通信时，使用如 `kubectl` 的命令行工具，就可以直接与 Kubernetes master 节点进行通信。
|
||||
|
||||
<!-- > The "master" refers to a collection of processes managing the cluster state. Typically these processes are all run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy. -->
|
||||
<!--
|
||||
> The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy.
|
||||
-->
|
||||
|
||||
> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的性能及冗余。
|
||||
> "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的可用性及冗余。
|
||||
|
||||
<!-- ### Kubernetes Nodes -->
|
||||
<!--
|
||||
### Kubernetes Nodes
|
||||
-->
|
||||
|
||||
### Kubernetes Node 节点
|
||||
|
||||
<!-- The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly. -->
|
||||
<!--
|
||||
The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
|
||||
-->
|
||||
|
||||
集群中的 node 节点（虚拟机、物理机等等）都是用来运行你的应用和云工作流的机器。Kubernetes master 节点控制所有 node 节点；你很少需要和 node 节点进行直接通信。
|
||||
|
||||
<!-- #### Object Metadata -->
|
||||
<!--
|
||||
#### Object Metadata
|
||||
|
||||
|
||||
* [Annotations](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
-->
|
||||
|
||||
#### 对象元数据
|
||||
|
||||
|
||||
* [注释](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
* [注解](/docs/concepts/overview/working-with-objects/annotations/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!-- If you would like to write a concept page, see
|
||||
<!--
|
||||
If you would like to write a concept page, see
|
||||
[Using Page Templates](/docs/home/contribute/page-templates/)
|
||||
for information about the concept page type and the concept template. -->
|
||||
for information about the concept page type and the concept template.
|
||||
-->
|
||||
|
||||
如果你想编写一个概念页面，请参阅[使用页面模板](/docs/home/contribute/page-templates/)获取更多有关概念页面类型和概念模板的信息。
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
title: "配置"
|
||||
weight: 70
|
||||
---
|
||||
|
|
@ -1,22 +1,67 @@
|
|||
---
|
||||
title: Managing Compute Resources for Containers
|
||||
title: 为容器管理计算资源
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
feature:
|
||||
title: 自动装箱
|
||||
description: >
|
||||
根据资源需求和其他约束自动放置容器，同时不会牺牲可用性，将任务关键工作负载和尽力服务工作负载进行混合放置，以提高资源利用率并节省更多资源。
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，节点上的资源就可以按照指定的方式做竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。
|
||||
<!--
|
||||
When you specify a [Pod](/docs/concepts/workloads/pods/pod/), you can optionally specify how
|
||||
much CPU and memory (RAM) each Container needs. When Containers have resource
|
||||
requests specified, the scheduler can make better decisions about which nodes to
|
||||
place Pods on. And when Containers have their limits specified, contention for
|
||||
resources on a node can be handled in a specified manner. For more details about
|
||||
the difference between requests and limits, see
|
||||
[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md).
|
||||
-->
|
||||
当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，Kubernetes 就可以按照指定的方式来处理节点上的资源竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Resource types
|
||||
|
||||
*CPU* and *memory* are each a *resource type*. A resource type has a base unit.
|
||||
CPU is specified in units of cores, and memory is specified in units of bytes.
|
||||
|
||||
CPU and memory are collectively referred to as *compute resources*, or just
|
||||
*resources*. Compute
|
||||
resources are measurable quantities that can be requested, allocated, and
|
||||
consumed. They are distinct from
|
||||
[API resources](/docs/concepts/overview/kubernetes-api/). API resources, such as Pods and
|
||||
[Services](/docs/concepts/services-networking/service/) are objects that can be read and modified
|
||||
through the Kubernetes API server.
|
||||
-->
|
||||
|
||||
## 资源类型
|
||||
|
||||
*CPU* 和 *内存* 都是 *资源类型* 。资源类型具有基本单位。CPU 的单位是 core，内存的单位是 byte。
|
||||
*CPU* 和*内存*都是*资源类型*。资源类型具有基本单位。CPU 的单位是核心数，内存的单位是字节。
|
||||
|
||||
CPU和内存统称为*计算资源* ，也可以称为*资源* 。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/api/) 不同。 API 资源（如 Pod 和 [Service](/docs/user-guide/services)）是可通过 Kubernetes API server 读取和修改的对象。
|
||||
CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/concepts/overview/kubernetes-api/) 不同。 API 资源（如 Pod 和 [Service](/docs/concepts/services-networking/service/)）是可通过 Kubernetes API server 读取和修改的对象。
|
||||
|
||||
<!--
|
||||
## Resource requests and limits of Pod and Container
|
||||
|
||||
Each Container of a Pod can specify one or more of the following:
|
||||
|
||||
* `spec.containers[].resources.limits.cpu`
|
||||
* `spec.containers[].resources.limits.memory`
|
||||
* `spec.containers[].resources.requests.cpu`
|
||||
* `spec.containers[].resources.requests.memory`
|
||||
|
||||
Although requests and limits can only be specified on individual Containers, it
|
||||
is convenient to talk about Pod resource requests and limits. A
|
||||
*Pod resource request/limit* for a particular resource type is the sum of the
|
||||
resource requests/limits of that type for each Container in the Pod.
|
||||
-->
|
||||
|
||||
## Pod 和 容器的资源请求和限制
|
||||
|
||||
|
|
@ -29,6 +74,31 @@ Pod 中的每个容器都可以指定以下的一个或者多个值：
|
|||
|
||||
尽管只能在个别容器上指定请求和限制，但是我们可以方便地计算出 Pod 资源请求和限制。特定资源类型的Pod 资源请求/限制是 Pod 中每个容器的该类型的资源请求/限制的总和。
|
||||
|
||||
<!--
|
||||
## Meaning of CPU
|
||||
|
||||
Limits and requests for CPU resources are measured in *cpu* units.
|
||||
One cpu, in Kubernetes, is equivalent to:
|
||||
|
||||
- 1 AWS vCPU
|
||||
- 1 GCP Core
|
||||
- 1 Azure vCore
|
||||
- 1 IBM vCPU
|
||||
- 1 *Hyperthread* on a bare-metal Intel processor with Hyperthreading
|
||||
|
||||
Fractional requests are allowed. A Container with
|
||||
`spec.containers[].resources.requests.cpu` of `0.5` is guaranteed half as much
|
||||
CPU as one that asks for 1 CPU. The expression `0.1` is equivalent to the
|
||||
expression `100m`, which can be read as "one hundred millicpu". Some people say
|
||||
"one hundred millicores", and this is understood to mean the same thing. A
|
||||
request with a decimal point, like `0.1`, is converted to `100m` by the API, and
|
||||
precision finer than `1m` is not allowed. For this reason, the form `100m` might
|
||||
be preferred.
|
||||
|
||||
CPU is always requested as an absolute quantity, never as a relative quantity;
|
||||
0.1 is the same amount of CPU on a single-core, dual-core, or 48-core machine.
|
||||
-->
|
||||
|
||||
## CPU 的含义
|
||||
|
||||
CPU 资源的限制和请求以 *cpu* 为单位。
|
||||
|
|
@ -44,6 +114,15 @@ Kubernetes 中的一个 cpu 等于：
|
|||
|
||||
CPU 总是要用绝对数量，不可以使用相对数量；0.1 的 CPU 在单核、双核、48核的机器中的意义是一样的。
|
||||
|
||||
<!--
|
||||
## Meaning of memory
|
||||
|
||||
Limits and requests for `memory` are measured in bytes. You can express memory as
|
||||
a plain integer or as a fixed-point integer using one of these suffixes:
|
||||
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
|
||||
Mi, Ki. For example, the following represent roughly the same value:
|
||||
-->
|
||||
|
||||
## 内存的含义
|
||||
|
||||
内存的限制和请求以字节为单位。您可以使用以下后缀之一作为平均整数或定点整数表示内存：E，P，T，G，M，K。您还可以使用两个字母的等效的幂数：Ei，Pi，Ti ，Gi，Mi，Ki。例如，以下代表大致相同的值：
|
||||
|
|
@ -52,6 +131,14 @@ CPU 总是要用绝对数量，不可以使用相对数量；0.1 的 CPU 在单
|
|||
128974848, 129e6, 129M, 123Mi
|
||||
```
|
||||
|
||||
<!--
|
||||
Here's an example.
|
||||
The following Pod has two Containers. Each Container has a request of 0.25 cpu
|
||||
and 64MiB (2<sup>26</sup> bytes) of memory. Each Container has a limit of 0.5
|
||||
cpu and 128MiB of memory. You can say the Pod has a request of 0.5 cpu and 128
|
||||
MiB of memory, and a limit of 1 cpu and 256MiB of memory.
|
||||
-->
|
||||
|
||||
下面是个例子。
|
||||
|
||||
以下 Pod 有两个容器。每个容器的请求为 0.25 cpu 和 64MiB（2<sup>26</sup> 字节）内存，每个容器的限制为 0.5 cpu 和 128MiB 内存。您可以说该 Pod 请求 0.5 cpu 和 128 MiB 的内存，限制为 1 cpu 和 256MiB 的内存。
|
||||
|
|
@ -65,6 +152,9 @@ spec:
|
|||
containers:
|
||||
- name: db
|
||||
image: mysql
|
||||
env:
|
||||
- name: MYSQL_ROOT_PASSWORD
|
||||
value: "password"
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
|
|
@ -83,27 +173,107 @@ spec:
|
|||
cpu: "500m"
|
||||
```
|
||||
|
||||
<!--
|
||||
## How Pods with resource requests are scheduled
|
||||
|
||||
When you create a Pod, the Kubernetes scheduler selects a node for the Pod to
|
||||
run on. Each node has a maximum capacity for each of the resource types: the
|
||||
amount of CPU and memory it can provide for Pods. The scheduler ensures that,
|
||||
for each resource type, the sum of the resource requests of the scheduled
|
||||
Containers is less than the capacity of the node. Note that although actual memory
|
||||
or CPU resource usage on nodes is very low, the scheduler still refuses to place
|
||||
a Pod on a node if the capacity check fails. This protects against a resource
|
||||
shortage on a node when resource usage later increases, for example, during a
|
||||
daily peak in request rate.
|
||||
-->
|
||||
|
||||
## 具有资源请求的 Pod 如何调度
|
||||
|
||||
当您创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。每个节点具有每种资源类型的最大容量：可为 Pod 提供的 CPU 和内存量。调度程序确保对于每种资源类型，调度的容器的资源请求的总和小于节点的容量。请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，但如果容量检查失败，则调度程序仍然拒绝在该节点上放置 Pod。当资源使用量稍后增加时，例如在请求率的每日峰值期间，这可以防止节点上的资源短缺。
|
||||
|
||||
<!--
|
||||
## How Pods with resource limits are run
|
||||
|
||||
When the kubelet starts a Container of a Pod, it passes the CPU and memory limits
|
||||
to the container runtime.
|
||||
|
||||
When using Docker:
|
||||
-->
|
||||
|
||||
## 具有资源限制的 Pod 如何运行
|
||||
|
||||
当 kubelet 启动一个 Pod 的容器时，它会将 CPU 和内存限制传递到容器运行时。
|
||||
|
||||
当使用 Docker 时：
|
||||
|
||||
- `spec.containers[].resources.requests.cpu` 的值将转换成 millicore 值，这是个浮点数，并乘以1024，这个数字中的较大者或2用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。
|
||||
<!--
|
||||
- The `spec.containers[].resources.requests.cpu` is converted to its core value,
|
||||
which is potentially fractional, and multiplied by 1024. The greater of this number
|
||||
or 2 is used as the value of the
|
||||
[`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint)
|
||||
flag in the `docker run` command.
|
||||
|
||||
- The `spec.containers[].resources.limits.cpu` is converted to its millicore value and
|
||||
multiplied by 100. The resulting value is the total amount of CPU time that a container can use
|
||||
every 100ms. A container cannot use more than its share of CPU time during this interval.
|
||||
-->
|
||||
|
||||
- `spec.containers[].resources.requests.cpu` 的值将转换成 millicore 值，这是个浮点数，并乘以 1024，这个数字中的较大者或 2 用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。
|
||||
|
||||
- `spec.containers[].resources.limits.cpu` 被转换成 millicore 值。被乘以 100000 然后 除以 1000。这个数字用作 `docker run` 命令中的 [`--cpu-quota`](https://docs.docker.com/engine/reference/run/#/cpu-quota-constraint) 标志的值。[`--cpu-quota` ] 标志被设置成了 100000，表示测量配额使用的默认100ms 周期。如果 [`--cpu-cfs-quota`] 标志设置为 true，则 kubelet 会强制执行 cpu 限制。从 Kubernetes 1.2 版本起，此标志默认为 true。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.
|
||||
{{</ note >}}
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
默认配额限制为 100 毫秒。 CPU配额的最小单位为 1 毫秒。
|
||||
{{</ note >}}
|
||||
|
||||
<!--
|
||||
- The `spec.containers[].resources.limits.memory` is converted to an integer, and
|
||||
used as the value of the
|
||||
[`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints)
|
||||
flag in the `docker run` command.
|
||||
-->
|
||||
|
||||
- `spec.containers[].resources.limits.memory` 被转换为整型，作为 `docker run` 命令中的 [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) 标志的值。
|
||||
|
||||
<!--
|
||||
If a Container exceeds its memory limit, it might be terminated. If it is
|
||||
restartable, the kubelet will restart it, as with any other type of runtime
|
||||
failure.
|
||||
|
||||
If a Container exceeds its memory request, it is likely that its Pod will
|
||||
be evicted whenever the node runs out of memory.
|
||||
|
||||
A Container might or might not be allowed to exceed its CPU limit for extended
|
||||
periods of time. However, it will not be killed for excessive CPU usage.
|
||||
|
||||
To determine whether a Container cannot be scheduled or is being killed due to
|
||||
resource limits, see the
|
||||
[Troubleshooting](#troubleshooting) section.
|
||||
-->
|
||||
|
||||
如果容器超过其内存限制，则可能会被终止。如果可重新启动，则与所有其他类型的运行时故障一样，kubelet 将重新启动它。
|
||||
|
||||
如果一个容器超过其内存请求，那么当节点内存不足时，它的 Pod 可能被逐出。
|
||||
|
||||
容器可能被允许也可能不被允许超过其 CPU 限制时间。但是，由于 CPU 使用率过高，不会被杀死。
|
||||
|
||||
要确定容器是否由于资源限制而无法安排或被杀死，请参阅 [疑难解答](#troubleshooting) 部分。
|
||||
要确定容器是否由于资源限制而无法安排或被杀死，请参阅[疑难解答](#troubleshooting) 部分。
|
||||
|
||||
<!--
|
||||
## Monitoring compute resource usage
|
||||
|
||||
The resource usage of a Pod is reported as part of the Pod status.
|
||||
|
||||
If [optional monitoring](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/README.md)
|
||||
is configured for your cluster, then Pod resource usage can be retrieved from
|
||||
the monitoring system.
|
||||
-->
|
||||
|
||||
## 监控计算资源使用
|
||||
|
||||
|
|
@ -111,6 +281,16 @@ Pod 的资源使用情况被报告为 Pod 状态的一部分。
|
|||
|
||||
如果为集群配置了 [可选监控](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/README.md)，则可以从监控系统检索 Pod 资源的使用情况。
|
||||
|
||||
<!--
|
||||
## Troubleshooting
|
||||
|
||||
### My Pods are pending with event message failedScheduling
|
||||
|
||||
If the scheduler cannot find any node where a Pod can fit, the Pod remains
|
||||
unscheduled until a place can be found. An event is produced each time the
|
||||
scheduler fails to find a place for the Pod, like this:
|
||||
-->
|
||||
|
||||
## 疑难解答
|
||||
|
||||
### 我的 Pod 处于 pending 状态且事件信息显示 failedScheduling
|
||||
|
|
@ -118,25 +298,50 @@ Pod 的资源使用情况被报告为 Pod 状态的一部分。
|
|||
如果调度器找不到任何该 Pod 可以匹配的节点，则该 Pod 将保持不可调度状态，直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时，会产生一个事件，如下所示：
|
||||
|
||||
```shell
|
||||
$ kubectl describe pod frontend | grep -A 3 Events
|
||||
kubectl describe pod frontend | grep -A 3 Events
|
||||
```
|
||||
```
|
||||
Events:
|
||||
FirstSeen LastSeen Count From Subobject PathReason Message
|
||||
36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others
|
||||
```
|
||||
|
||||
<!--
|
||||
In the preceding example, the Pod named "frontend" fails to be scheduled due to
|
||||
insufficient CPU resource on the node. Similar error messages can also suggest
|
||||
failure due to insufficient memory (PodExceedsFreeMemory). In general, if a Pod
|
||||
is pending with a message of this type, there are several things to try:
|
||||
|
||||
- Add more nodes to the cluster.
|
||||
- Terminate unneeded Pods to make room for pending Pods.
|
||||
- Check that the Pod is not larger than all the nodes. For example, if all the
|
||||
nodes have a capacity of `cpu: 1`, then a Pod with a request of `cpu: 1.1` will
|
||||
never be scheduled.
|
||||
|
||||
You can check node capacities and amounts allocated with the
|
||||
`kubectl describe nodes` command. For example:
|
||||
-->
|
||||
|
||||
在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 将无法调度。由于内存不足（PodExceedsFreeMemory），类似的错误消息也可能会导致失败。一般来说，如果有这种类型的消息而处于 pending 状态，您可以尝试如下几件事情：
|
||||
|
||||
- 向集群添加更多节点。
|
||||
- 终止不需要的 Pod，为待处理的 Pod 腾出空间。
|
||||
- 检查 Pod 所需的资源是否大于所有节点的资源。 例如，如果全部节点的容量为`cpu：1`，那么一个请求为 `cpu：1.1`的 Pod 永远不会被调度。
|
||||
|
||||
您可以使用 `kubectl describe nodes` 命令检查节点容量和分配的数量。 例如：
|
||||
|
||||
|
||||
```shell
|
||||
$ kubectl describe nodes e2e-test-minion-group-4lw4
|
||||
Name: e2e-test-minion-group-4lw4
|
||||
kubectl describe nodes e2e-test-node-pool-4lw4
|
||||
```
|
||||
```
|
||||
Name: e2e-test-node-pool-4lw4
|
||||
[ ... lines removed for clarity ...]
|
||||
Capacity:
|
||||
alpha.kubernetes.io/nvidia-gpu: 0
|
||||
cpu: 2
|
||||
memory: 7679792Ki
|
||||
pods: 110
|
||||
Allocatable:
|
||||
alpha.kubernetes.io/nvidia-gpu: 0
|
||||
cpu: 1800m
|
||||
memory: 7474992Ki
|
||||
pods: 110
|
||||
|
|
@ -156,20 +361,50 @@ Allocated resources:
|
|||
680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%)
|
||||
```
|
||||
|
||||
<!--
|
||||
In the preceding output, you can see that if a Pod requests more than 1120m
|
||||
CPUs or 6.23Gi of memory, it will not fit on the node.
|
||||
|
||||
By looking at the `Pods` section, you can see which Pods are taking up space on
|
||||
the node.
|
||||
|
||||
The amount of resources available to Pods is less than the node capacity, because
|
||||
system daemons use a portion of the available resources. The `allocatable` field
|
||||
[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)
|
||||
gives the amount of resources that are available to Pods. For more information, see
|
||||
[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
|
||||
|
||||
The [resource quota](/docs/concepts/policy/resource-quotas/) feature can be configured
|
||||
to limit the total amount of resources that can be consumed. If used in conjunction
|
||||
with namespaces, it can prevent one team from hogging all the resources.
|
||||
-->
|
||||
|
||||
在上面的输出中，您可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。
|
||||
|
||||
通过查看 `Pods` 部分，您将看到哪些 Pod 占用的节点上的资源。
|
||||
|
||||
Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。 [NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) 的 `allocatable` 字段给出了可用于 Pod 的资源量。有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。
|
||||
Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。
|
||||
[NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) 的 `allocatable` 字段给出了可用于 Pod 的资源量。
|
||||
有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。
|
||||
|
||||
可以将 [资源配额](/docs/concepts/policy/resource-quotas/) 功能配置为限制可以使用的资源总量。如果与 namespace 配合一起使用，就可以防止一个团队占用所有资源。
|
||||
|
||||
<!--
|
||||
### My Container is terminated
|
||||
|
||||
Your Container might get terminated because it is resource-starved. To check
|
||||
whether a Container is being killed because it is hitting a resource limit, call
|
||||
`kubectl describe pod` on the Pod of interest:
|
||||
-->
|
||||
|
||||
## 我的容器被终止了
|
||||
|
||||
您的容器可能因为资源枯竭而被终止了。要查看容器是否因为遇到资源限制而被杀死，请在相关的 Pod 上调用 `kubectl describe pod`：
|
||||
|
||||
```shell
|
||||
[12:54:41] $ kubectl describe pod simmemleak-hra99
|
||||
kubectl describe pod simmemleak-hra99
|
||||
```
|
||||
```
|
||||
Name: simmemleak-hra99
|
||||
Namespace: default
|
||||
Image(s): saadali/simmemleak
|
||||
|
|
@ -206,59 +441,466 @@ Events:
|
|||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a
|
||||
```
|
||||
|
||||
<!--
|
||||
In the preceding example, the `Restart Count: 5` indicates that the `simmemleak`
|
||||
Container in the Pod was terminated and restarted five times.
|
||||
|
||||
You can call `kubectl get pod` with the `-o go-template=...` option to fetch the status
|
||||
of previously terminated Containers:
|
||||
-->
|
||||
|
||||
在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。
|
||||
|
||||
您可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。
|
||||
|
||||
|
||||
```shell
|
||||
[13:59:01] $ kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-60xbc
|
||||
kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99
|
||||
```
|
||||
```
|
||||
Container Name: simmemleak
|
||||
LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]
|
||||
```
|
||||
|
||||
<!--
|
||||
You can see that the Container was terminated because of `reason:OOM Killed`, where `OOM` stands for Out Of Memory.
|
||||
-->
|
||||
|
||||
您可以看到容器因为 `reason:OOM killed` 被终止，`OOM` 表示 Out Of Memory。
|
||||
|
||||
## 不透明整型资源（Alpha功能）
|
||||
<!--
|
||||
## Local ephemeral storage
|
||||
{{< feature-state state="beta" >}}
|
||||
|
||||
Kubernetes 1.5 版本中引入不透明整型资源。不透明的整数资源允许集群运维人员发布新的节点级资源，否则系统将不了解这些资源。
|
||||
Kubernetes version 1.8 introduces a new resource, _ephemeral-storage_ for managing local ephemeral storage. In each Kubernetes node, kubelet's root directory (/var/lib/kubelet by default) and log directory (/var/log) are stored on the root partition of the node. This partition is also shared and consumed by Pods via emptyDir volumes, container logs, image layers and container writable layers.
|
||||
|
||||
用户可以在 Pod 的 spec 中消费这些资源，就像 CPU 和内存一样。调度器负责资源计量，以便在不超过可用量的同时分配给 Pod。
|
||||
This partition is “ephemeral” and applications cannot expect any performance SLAs (Disk IOPS for example) from this partition. Local ephemeral storage management only applies for the root partition; the optional partition for image layer and writable layer is out of scope.
|
||||
|
||||
**注意：** 不透明整型资源在 kubernetes 1.5 中还是 Alpha 版本。只实现了资源计量，节点级别的隔离还处于积极的开发阶段。
|
||||
{{< note >}}
|
||||
If an optional runtime partition is used, root partition will not hold any image layer or writable layers.
|
||||
{{< /note >}}
|
||||
-->
|
||||
|
||||
不透明整型资源是以 `pod.alpha.kubernetes.io/opaque-int-resource-` 为前缀的资源。API server 将限制这些资源的数量为整数。*有效* 数量的例子有 `3`、`3000m` 和 `3Ki`。*无效* 数量的例子有 `0.5` 和 `1500m`。
|
||||
## 本地临时存储
|
||||
|
||||
申请使用不透明整型资源需要两步。首先，集群运维人员必须在一个或多个节点上通告每个节点不透明的资源。然后，用户必须在 Pod 中请求不透明资源。
|
||||
Kubernetes版本1.8引入了新资源_ephemeral-storage_，用于管理本地临时存储。
|
||||
在每个Kubernetes节点中，kubelet的根目录（默认为 /var/lib/kubelet）和日志目录（ /var/log ）存储在节点的根分区上。
|
||||
Pods还通过emptyDir卷，容器日志，镜像层和容器可写层共享和使用此分区。
|
||||
|
||||
要发布新的不透明整型资源，集群运维人员应向 API server 提交 `PATCH` HTTP请求，以指定集群中节点的`status.capacity` 的可用数量。在此操作之后，节点的 `status.capacity` 将包括一个新的资源。 `status.allocatable` 字段由 kubelet 异步地使用新资源自动更新。请注意，由于调度器在评估 Pod 适应度时使用节点 `status.allocatable` 值，所以在使用新资源修补节点容量和请求在该节点上调度资源的第一个 pod 之间可能会有短暂的延迟。
|
||||
该分区是“临时”分区，应用程序无法从该分区获得任何性能SLA（例如磁盘IOPS）。 本地临时存储管理仅适用于根分区。 图像层和可写层的可选分区超出范围。
|
||||
|
||||
**示例**
|
||||
{{< note >}}
|
||||
如果使用可选的运行时分区，则根分区将不保存任何镜像层或可写层。
|
||||
{{< /note >}}
|
||||
|
||||
这是一个 HTTP 请求，master 节点是 k8s-master，在 k8s-node-1 节点上通告 5 个 “foo” 资源。
|
||||
<!--
|
||||
### Requests and limits setting for local ephemeral storage
|
||||
Each Container of a Pod can specify one or more of the following:
|
||||
-->
|
||||
|
||||
```http
|
||||
PATCH /api/v1/nodes/k8s-node-1/status HTTP/1.1
|
||||
Accept: application/json
|
||||
Content-Type: application/json-patch+json
|
||||
Host: k8s-master:8080
|
||||
### 本地临时存储的请求和限制设置
|
||||
Pod 的每个容器可以指定以下一项或多项：
|
||||
|
||||
[
|
||||
{
|
||||
"op": "add",
|
||||
"path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-foo",
|
||||
"value": "5"
|
||||
}
|
||||
]
|
||||
* `spec.containers[].resources.limits.ephemeral-storage`
|
||||
* `spec.containers[].resources.requests.ephemeral-storage`
|
||||
|
||||
<!--
|
||||
Limits and requests for `ephemeral-storage` are measured in bytes. You can express storage as
|
||||
a plain integer or as a fixed-point integer using one of these suffixes:
|
||||
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
|
||||
Mi, Ki. For example, the following represent roughly the same value:
|
||||
-->
|
||||
|
||||
对“临时存储”的限制和请求以字节为单位。您可以使用以下后缀之一将存储表示为纯整数或小数形式：E，P，T，G，M，K。您还可以使用2的幂次方：Ei，Pi，Ti，Gi，Mi，Ki。例如，以下内容表示的值其实大致相同：
|
||||
|
||||
```shell
|
||||
128974848, 129e6, 129M, 123Mi
|
||||
```
|
||||
|
||||
<!--
|
||||
For example, the following Pod has two Containers. Each Container has a request of 2GiB of local ephemeral storage. Each Container has a limit of 4GiB of local ephemeral storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and a limit of 8GiB of storage.
|
||||
-->
|
||||
|
||||
例如，以下Pod具有两个容器。每个容器都有一个2GiB的本地临时存储请求。每个容器的本地临时存储限制为4GiB。因此，该Pod要求本地临时存储空间为4GiB，存储空间限制为8GiB。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: db
|
||||
image: mysql
|
||||
env:
|
||||
- name: MYSQL_ROOT_PASSWORD
|
||||
value: "password"
|
||||
resources:
|
||||
requests:
|
||||
ephemeral-storage: "2Gi"
|
||||
limits:
|
||||
ephemeral-storage: "4Gi"
|
||||
- name: wp
|
||||
image: wordpress
|
||||
resources:
|
||||
requests:
|
||||
ephemeral-storage: "2Gi"
|
||||
limits:
|
||||
ephemeral-storage: "4Gi"
|
||||
```
|
||||
|
||||
<!--
|
||||
### How Pods with ephemeral-storage requests are scheduled
|
||||
|
||||
When you create a Pod, the Kubernetes scheduler selects a node for the Pod to
|
||||
run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see ["Node Allocatable"](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable).
|
||||
|
||||
The scheduler ensures that the sum of the resource requests of the scheduled Containers is less than the capacity of the node.
|
||||
-->
|
||||
|
||||
### 如何调度临时存储请求的 Pod
|
||||
|
||||
创建Pod时，Kubernetes调度程序会选择一个节点来运行Pod。每个节点都可以为Pod提供最大数量的本地临时存储。
|
||||
有关更多信息，请参见[节点可分配](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)。
|
||||
|
||||
调度程序会确保调度的容器的资源请求的总和小于节点的容量。
|
||||
|
||||
<!--
|
||||
### How Pods with ephemeral-storage limits run
|
||||
|
||||
For container-level isolation, if a Container's writable layer and logs usage exceeds its storage limit, the Pod will be evicted. For pod-level isolation, if the sum of the local ephemeral storage usage from all containers and also the Pod's emptyDir volumes exceeds the limit, the Pod will be evicted.
|
||||
-->
|
||||
|
||||
### 具有临时存储限制的 Pod 如何运行
|
||||
|
||||
对于容器级隔离，如果容器的可写层和日志使用量超出其存储限制，则将驱逐Pod。对于 pod 级别的隔离，如果来自所有容器的本地临时存储使用量以及 Pod 的 emptyDir 卷的总和超过限制，则将驱逐Pod。
|
||||
|
||||
<!--
|
||||
### Monitoring ephemeral-storage consumption
|
||||
|
||||
When local ephemeral storage is used, it is monitored on an ongoing
|
||||
basis by the kubelet. The monitoring is performed by scanning each
|
||||
emptyDir volume, log directories, and writable layers on a periodic
|
||||
basis. Starting with Kubernetes 1.15, emptyDir volumes (but not log
|
||||
directories or writable layers) may, at the cluster operator's option,
|
||||
be managed by use of [project
|
||||
quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html).
|
||||
Project quotas were originally implemented in XFS, and have more
|
||||
recently been ported to ext4fs. Project quotas can be used for both
|
||||
monitoring and enforcement; as of Kubernetes 1.15, they are available
|
||||
as alpha functionality for monitoring only.
|
||||
-->
|
||||
|
||||
### 监控临时存储消耗
|
||||
|
||||
使用本地临时存储时，kubelet 会持续对本地临时存储时进行监视。
|
||||
通过定期扫描，来监视每个 emptyDir 卷，日志目录和可写层。
|
||||
从Kubernetes 1.15开始，作为集群操作员的一个选项，可以通过[项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 来管理 emptyDir 卷（但是不包括日志目录或可写层）。
|
||||
项目配额最初是在XFS中实现的，最近又被移植到ext4fs中。 项目配额可用于监视和执行； 从Kubernetes 1.15开始，它们可用作Alpha功能仅用于监视。
|
||||
|
||||
<!--
|
||||
Quotas are faster and more accurate than directory scanning. When a
|
||||
directory is assigned to a project, all files created under a
|
||||
directory are created in that project, and the kernel merely has to
|
||||
keep track of how many blocks are in use by files in that project. If
|
||||
a file is created and deleted, but with an open file descriptor, it
|
||||
continues to consume space. This space will be tracked by the quota,
|
||||
but will not be seen by a directory scan.
|
||||
-->
|
||||
|
||||
配额比目录扫描更快，更准确。
|
||||
将目录分配给项目时，在该目录下创建的所有文件都将在该项目中创建，内核仅需跟踪该项目中的文件正在使用多少块。
|
||||
如果创建并删除了文件，但是文件描述符已打开，它将继续占用空间。 该空间将由配额跟踪，但目录扫描不会检查。
|
||||
|
||||
<!--
|
||||
Kubernetes uses project IDs starting from 1048576. The IDs in use are
|
||||
registered in `/etc/projects` and `/etc/projid`. If project IDs in
|
||||
this range are used for other purposes on the system, those project
|
||||
IDs must be registered in `/etc/projects` and `/etc/projid` to prevent
|
||||
Kubernetes from using them.
|
||||
-->
|
||||
|
||||
Kubernetes使用从1048576开始的项目ID。正在使用的ID注册于 `/etc/projects` 和 `/etc/projid`。
|
||||
如果此范围内的项目ID用于系统上的其他目的，则这些项目ID必须在 `/etc/projects` 和 `/etc/projid` 中注册，以防止Kubernetes使用它们。
|
||||
|
||||
<!--
|
||||
To enable use of project quotas, the cluster operator must do the
|
||||
following:
|
||||
|
||||
* Enable the `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
|
||||
feature gate in the kubelet configuration. This defaults to `false`
|
||||
in Kubernetes 1.15, so must be explicitly set to `true`.
|
||||
|
||||
* Ensure that the root partition (or optional runtime partition) is
|
||||
built with project quotas enabled. All XFS filesystems support
|
||||
project quotas, but ext4 filesystems must be built specially.
|
||||
|
||||
* Ensure that the root partition (or optional runtime partition) is
|
||||
mounted with project quotas enabled.
|
||||
-->
|
||||
|
||||
要启用项目配额，集群操作员必须执行以下操作：
|
||||
|
||||
* 在kubelet配置中启用 `LocalStorageCapacityIsolationFSQuotaMonitoring = true` 功能。 在Kubernetes 1.15中默认为 false，因此必须显式设置为 true。
|
||||
|
||||
* 确保根分区（或可选的运行时分区）是在启用项目配额的情况下构建的。 所有 XFS 文件系统都支持项目配额，但是 ext4 文件系统必须专门构建。
|
||||
|
||||
* 确保在启用了项目配额的情况下挂载了根分区（或可选的运行时分区）。
|
||||
|
||||
<!--
|
||||
#### Building and mounting filesystems with project quotas enabled
|
||||
|
||||
XFS filesystems require no special action when building; they are
|
||||
automatically built with project quotas enabled.
|
||||
|
||||
Ext4fs filesystems must be built with quotas enabled, then they must
|
||||
be enabled in the filesystem:
|
||||
-->
|
||||
|
||||
#### 在启用项目配额的情况下构建和挂载文件系统
|
||||
|
||||
XFS文件系统在构建时不需要任何特殊操作; 它们是在启用项目配额的情况下自动构建的。
|
||||
|
||||
Ext4fs文件系统必须在启用了配额的情况下构建，然后必须在文件系统中启用它们：
|
||||
|
||||
```
|
||||
% sudo mkfs.ext4 other_ext4fs_args... -E quotatype=prjquota /dev/block_device
|
||||
% sudo tune2fs -O project -Q prjquota /dev/block_device
|
||||
|
||||
```
|
||||
|
||||
<!--
|
||||
To mount the filesystem, both ext4fs and XFS require the `prjquota`
|
||||
option set in `/etc/fstab`:
|
||||
-->
|
||||
|
||||
要挂载文件系统，ext4fs 和 XFS 都需要在 `/etc/fstab` 中设置 `prjquota` 选项：
|
||||
|
||||
```
|
||||
/dev/block_device /var/kubernetes_data defaults,prjquota 0 0
|
||||
```
|
||||
|
||||
|
||||
<!--
|
||||
## Extended resources
|
||||
|
||||
Extended resources are fully-qualified resource names outside the
|
||||
`kubernetes.io` domain. They allow cluster operators to advertise and users to
|
||||
consume the non-Kubernetes-built-in resources.
|
||||
|
||||
There are two steps required to use Extended Resources. First, the cluster
|
||||
operator must advertise an Extended Resource. Second, users must request the
|
||||
Extended Resource in Pods.
|
||||
-->
|
||||
|
||||
## 拓展资源
|
||||
|
||||
拓展资源是 `kubernetes.io` 域名之外的标准资源名称。它们允许集群管理员做分发，而且用户可以使用非Kubernetes内置资源。
|
||||
使用扩展资源需要两个步骤。 首先，集群管理员必须分发拓展资源。 其次，用户必须在 Pod 中请求拓展资源。
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "add", "path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-foo", "value": "5"}]' \
|
||||
--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
|
||||
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
|
||||
```
|
||||
|
||||
**注意：** 在前面的请求中，`~1` 是 patch 路径中 `/` 字符的编码。JSON-Patch 中的操作路径值被解释为 JSON-Pointer。更多详细信息请参阅 [IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3)。
|
||||
<!--
|
||||
### Managing extended resources
|
||||
|
||||
#### Node-level extended resources
|
||||
|
||||
Node-level extended resources are tied to nodes.
|
||||
-->
|
||||
|
||||
### 管理拓展资源
|
||||
|
||||
#### 节点级拓展资源
|
||||
|
||||
节点级拓展资源绑定到节点。
|
||||
|
||||
<!--
|
||||
##### Device plugin managed resources
|
||||
See [Device
|
||||
Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
|
||||
for how to advertise device plugin managed resources on each node.
|
||||
-->
|
||||
|
||||
##### 设备插件托管资源
|
||||
|
||||
有关如何在每个节点上分发设备插件托管资源的信息，请参阅[设备插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)。
|
||||
|
||||
<!--
|
||||
##### Other resources
|
||||
To advertise a new node-level extended resource, the cluster operator can
|
||||
submit a `PATCH` HTTP request to the API server to specify the available
|
||||
quantity in the `status.capacity` for a node in the cluster. After this
|
||||
operation, the node's `status.capacity` will include a new resource. The
|
||||
`status.allocatable` field is updated automatically with the new resource
|
||||
asynchronously by the kubelet. Note that because the scheduler uses the node
|
||||
`status.allocatable` value when evaluating Pod fitness, there may be a short
|
||||
delay between patching the node capacity with a new resource and the first Pod
|
||||
that requests the resource to be scheduled on that node.
|
||||
-->
|
||||
|
||||
##### 其他资源
|
||||
为了发布新的节点级拓展资源，集群操作员可以向API服务器提交 `PATCH` HTTP 请求，
|
||||
以在 `status.capacity` 中为集群中的节点指定可用数量。
|
||||
完成此操作后，节点的 `status.capacity` 将包含新资源。
|
||||
由kubelet异步使用新资源自动更新 `status.allocatable` 字段。
|
||||
请注意，由于调度程序在评估Pod适合性时使用节点的状态 `status.allocatable` 值，
|
||||
因此在用新资源修补节点容量和请求在该节点上调度资源的第一个Pod之间可能会有短暂的延迟。
|
||||
|
||||
<!--
|
||||
**Example:**
|
||||
|
||||
Here is an example showing how to use `curl` to form an HTTP request that
|
||||
advertises five "example.com/foo" resources on node `k8s-node-1` whose master
|
||||
is `k8s-master`.
|
||||
-->
|
||||
|
||||
**示例:**
|
||||
|
||||
这是一个示例，显示了如何使用 `curl` 进行HTTP请求，该请求在主节点为 `k8s-master` 的子节点 `k8s-node-1`
|
||||
上通告五个 `example.com/foo` 资源。
|
||||
|
||||
```shell
|
||||
curl --header "Content-Type: application/json-patch+json" \
|
||||
--request PATCH \
|
||||
--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
|
||||
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
<!--
|
||||
In the preceding request, `~1` is the encoding for the character `/`
|
||||
in the patch path. The operation path value in JSON-Patch is interpreted as a
|
||||
JSON-Pointer. For more details, see
|
||||
-->
|
||||
|
||||
在前面的请求中，`~1` 是 Patch 路径中字符 `/` 的编码。 JSON-Patch中的操作路径值被解释为JSON-Pointer。
|
||||
有关更多详细信息，请参见
|
||||
[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3).
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
#### Cluster-level extended resources
|
||||
|
||||
Cluster-level extended resources are not tied to nodes. They are usually managed
|
||||
by scheduler extenders, which handle the resource consumption and resource quota.
|
||||
|
||||
You can specify the extended resources that are handled by scheduler extenders
|
||||
in [scheduler policy
|
||||
configuration](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31).
|
||||
-->
|
||||
|
||||
#### 集群级扩展资源
|
||||
|
||||
群集级扩展资源不绑定到节点。 它们通常由调度程序扩展程序管理，这些程序处理资源消耗和资源配额。
|
||||
|
||||
您可以在[调度程序策略配置](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)中指定由调度程序扩展程序处理的扩展资源。
|
||||
|
||||
<!--
|
||||
**Example:**
|
||||
|
||||
The following configuration for a scheduler policy indicates that the
|
||||
cluster-level extended resource "example.com/foo" is handled by the scheduler
|
||||
extender.
|
||||
|
||||
- The scheduler sends a Pod to the scheduler extender only if the Pod requests
|
||||
"example.com/foo".
|
||||
- The `ignoredByScheduler` field specifies that the scheduler does not check
|
||||
the "example.com/foo" resource in its `PodFitsResources` predicate.
|
||||
-->
|
||||
|
||||
**示例:**
|
||||
|
||||
通过调度程序策略的以下配置，指示群集级扩展资源 "example.com/foo" 由调度程序扩展程序处理。
|
||||
|
||||
- 仅当Pod请求 "example.com/foo" 时，调度程序才会将 Pod 发送到调度程序扩展程序。
|
||||
- `ignoredByScheduler` 字段指定调度程序不在其 `PodFitsResources` 字段中检查 "example.com/foo" 资源。
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Policy",
|
||||
"apiVersion": "v1",
|
||||
"extenders": [
|
||||
{
|
||||
"urlPrefix":"<extender-endpoint>",
|
||||
"bindVerb": "bind",
|
||||
"managedResources": [
|
||||
{
|
||||
"name": "example.com/foo",
|
||||
"ignoredByScheduler": true
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
### Consuming extended resources
|
||||
|
||||
Users can consume extended resources in Pod specs just like CPU and memory.
|
||||
The scheduler takes care of the resource accounting so that no more than the
|
||||
available amount is simultaneously allocated to Pods.
|
||||
|
||||
The API server restricts quantities of extended resources to whole numbers.
|
||||
Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of
|
||||
_invalid_ quantities are `0.5` and `1500m`.
|
||||
-->
|
||||
|
||||
### 消耗扩展资源
|
||||
|
||||
就像 CPU 和内存一样，用户可以使用 Pod 的扩展资源。
|
||||
调度程序负责核算资源，因此不会同时将过多的可用资源分配给 Pod。
|
||||
|
||||
{{< note >}}
|
||||
|
||||
<!--
|
||||
Extended resources replace Opaque Integer Resources.
|
||||
Users can use any domain name prefix other than `kubernetes.io` which is reserved.
|
||||
-->
|
||||
|
||||
扩展资源取代了 Opaque 整数资源。 用户可以使用保留字 `kubernetes.io` 以外的任何域名前缀。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
To consume an extended resource in a Pod, include the resource name as a key
|
||||
in the `spec.containers[].resources.limits` map in the container spec.
|
||||
-->
|
||||
|
||||
要在Pod中使用扩展资源，请在容器规范的 `spec.containers[].resources.limits` 映射中包含资源名称作为键。
|
||||
|
||||
{{< note >}}
|
||||
|
||||
<!--
|
||||
Extended resources cannot be overcommitted, so request and limit
|
||||
must be equal if both are present in a container spec.
|
||||
-->
|
||||
|
||||
扩展资源不能过量使用，因此如果容器规范中存在请求和限制，则它们必须一致。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
A Pod is scheduled only if all of the resource requests are satisfied, including
|
||||
CPU, memory and any extended resources. The Pod remains in the `PENDING` state
|
||||
as long as the resource request cannot be satisfied.
|
||||
|
||||
**Example:**
|
||||
|
||||
The Pod below requests 2 CPUs and 1 "example.com/foo" (an extended resource).
|
||||
-->
|
||||
|
||||
仅当满足所有资源请求(包括 CPU ，内存和任何扩展资源)时，才能调度 Pod。 只要资源请求无法满足，则 Pod 保持在 `PENDING` 状态。
|
||||
|
||||
**示例:**
|
||||
|
||||
下面的 Pod 请求2个 CPU 和1个"example.com/foo"(扩展资源)。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -272,14 +914,42 @@ spec:
|
|||
resources:
|
||||
requests:
|
||||
cpu: 2
|
||||
pod.alpha.kubernetes.io/opaque-int-resource-foo: 1
|
||||
example.com/foo: 1
|
||||
limits:
|
||||
example.com/foo: 1
|
||||
```
|
||||
|
||||
<!--
|
||||
## Planned Improvements
|
||||
|
||||
Kubernetes version 1.5 only allows resource quantities to be specified on a
|
||||
Container. It is planned to improve accounting for resources that are shared by
|
||||
all Containers in a Pod, such as
|
||||
[emptyDir volumes](/docs/concepts/storage/volumes/#emptydir).
|
||||
|
||||
Kubernetes version 1.5 only supports Container requests and limits for CPU and
|
||||
memory. It is planned to add new resource types, including a node disk space
|
||||
resource, and a framework for adding custom
|
||||
[resource types](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/scheduling/resources.md).
|
||||
|
||||
Kubernetes supports overcommitment of resources by supporting multiple levels of
|
||||
[Quality of Service](http://issue.k8s.io/168).
|
||||
|
||||
In Kubernetes version 1.5, one unit of CPU means different things on different
|
||||
cloud providers, and on different machine types within the same cloud providers.
|
||||
For example, on AWS, the capacity of a node is reported in
|
||||
[ECUs](http://aws.amazon.com/ec2/faqs/), while in GCE it is reported in logical
|
||||
cores. We plan to revise the definition of the cpu resource to allow for more
|
||||
consistency across providers and platforms.
|
||||
-->
|
||||
|
||||
## 计划改进
|
||||
|
||||
在 kubernetes 1.5 版本中仅允许在容器上指定资源量。计划改进对所有容器在 Pod 中共享资源的计量，如 [emptyDir volume](/docs/concepts/storage/volumes/#emptydir)。
|
||||
在 kubernetes 1.5 版本中仅允许在容器上指定资源量。计划改进对所有容器在 Pod 中共享资源的计量，
|
||||
如 [emptyDir volume](/docs/concepts/storage/volumes/#emptydir)。
|
||||
|
||||
在 kubernetes 1.5 版本中仅支持容器对 CPU 和内存的申请和限制。计划增加新的资源类型，包括节点磁盘空间资源和一个可支持自定义 [资源类型](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/resources.md) 的框架。
|
||||
在 kubernetes 1.5 版本中仅支持容器对 CPU 和内存的申请和限制。计划增加新的资源类型，包括节点磁盘空间资源和一个可支持自定义
|
||||
[资源类型](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/resources.md) 的框架。
|
||||
|
||||
Kubernetes 通过支持通过多级别的 [服务质量](http://issue.k8s.io/168) 来支持资源的过度使用。
|
||||
|
||||
|
|
@ -287,13 +957,25 @@ Kubernetes 通过支持通过多级别的 [服务质量](http://issue.k8s.io/168
|
|||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
- 获取将 [CPU 和内存资源分配给容器](/docs/tasks/configure-pod-container/assign-cpu-ram-container/) 的实践经验
|
||||
- [容器](/docs/api-reference/{{< param "version" >}}/#container-v1-core)
|
||||
- [ResourceRequirements](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core)
|
||||
<!--
|
||||
* Get hands-on experience [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
|
||||
|
||||
* Get hands-on experience [assigning CPU resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
|
||||
|
||||
* [Container API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
|
||||
* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core)
|
||||
-->
|
||||
|
||||
* 获取将 [分配内存资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验
|
||||
|
||||
* 获取将 [分配 CPU 资源给容器和 Pod ](/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验
|
||||
|
||||
* [容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
|
||||
* [资源需求](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,275 @@
|
|||
---
|
||||
title: 使用 kubeconfig 文件组织集群访问
|
||||
content_template: templates/concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
<!--
|
||||
Use kubeconfig files to organize information about clusters, users, namespaces, and
|
||||
authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to
|
||||
find the information it needs to choose a cluster and communicate with the API server
|
||||
of a cluster.
|
||||
--->
|
||||
使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。`kubectl` 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
A file that is used to configure access to clusters is called
|
||||
a *kubeconfig file*. This is a generic way of referring to configuration files.
|
||||
It does not mean that there is a file named `kubeconfig`.
|
||||
{{< /note >}}
|
||||
--->
|
||||
{{< note >}}
|
||||
注意：用于配置集群访问的文件称为 *kubeconfig 文件*。这是引用配置文件的通用方法。这并不意味着有一个名为 `kubeconfig` 的文件
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
By default, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
|
||||
You can specify other kubeconfig files by setting the `KUBECONFIG` environment
|
||||
variable or by setting the
|
||||
[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) flag.
|
||||
--->
|
||||
默认情况下，`kubectl` 在 `$HOME/.kube` 目录下查找名为 `config` 的文件。您可以通过设置 `KUBECONFIG` 环境变量或者设置[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)参数来指定其他 kubeconfig 文件。
|
||||
|
||||
<!--
|
||||
For step-by-step instructions on creating and specifying kubeconfig files, see
|
||||
[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
|
||||
--->
|
||||
有关创建和指定 kubeconfig 文件的分步说明，请参阅[配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
<!--
|
||||
## Supporting multiple clusters, users, and authentication mechanisms
|
||||
--->
|
||||
## 支持多集群、用户和身份认证机制
|
||||
|
||||
<!--
|
||||
Suppose you have several clusters, and your users and components authenticate
|
||||
in a variety of ways. For example:
|
||||
--->
|
||||
假设您有多个集群，并且您的用户和组件以多种方式进行身份认证。比如：
|
||||
|
||||
<!--
|
||||
- A running kubelet might authenticate using certificates.
|
||||
- A user might authenticate using tokens.
|
||||
- Administrators might have sets of certificates that they provide to individual users.
|
||||
--->
|
||||
- 正在运行的 kubelet 可能使用证书在进行认证。
|
||||
- 用户可能通过令牌进行认证。
|
||||
- 管理员可能拥有多个证书集合提供给各用户。
|
||||
|
||||
<!--
|
||||
With kubeconfig files, you can organize your clusters, users, and namespaces.
|
||||
You can also define contexts to quickly and easily switch between
|
||||
clusters and namespaces.
|
||||
--->
|
||||
使用 kubeconfig 文件，您可以组织集群、用户和命名空间。您还可以定义上下文，以便在集群和命名空间之间快速轻松地切换。
|
||||
|
||||
<!--
|
||||
## Context
|
||||
--->
|
||||
## 上下文（Context）
|
||||
|
||||
<!--
|
||||
A *context* element in a kubeconfig file is used to group access parameters
|
||||
under a convenient name. Each context has three parameters: cluster, namespace, and user.
|
||||
By default, the `kubectl` command-line tool uses parameters from
|
||||
the *current context* to communicate with the cluster.
|
||||
--->
|
||||
通过 kubeconfig 文件中的 *context* 元素，使用简便的名称来对访问参数进行分组。每个上下文都有三个参数：cluster、namespace 和 user。默认情况下，`kubectl` 命令行工具使用 *当前上下文* 中的参数与集群进行通信。
|
||||
|
||||
<!--
|
||||
To choose the current context:
|
||||
--->
|
||||
选择当前上下文
|
||||
```
|
||||
kubectl config use-context
|
||||
```
|
||||
|
||||
<!--
|
||||
## The KUBECONFIG environment variable
|
||||
--->
|
||||
## KUBECONFIG 环境变量
|
||||
|
||||
<!--
|
||||
The `KUBECONFIG` environment variable holds a list of kubeconfig files.
|
||||
For Linux and Mac, the list is colon-delimited. For Windows, the list
|
||||
is semicolon-delimited. The `KUBECONFIG` environment variable is not
|
||||
required. If the `KUBECONFIG` environment variable doesn't exist,
|
||||
`kubectl` uses the default kubeconfig file, `$HOME/.kube/config`.
|
||||
--->
|
||||
`KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。对于 Linux 和 Mac，列表以冒号分隔。对于 Windows，列表以分号分隔。`KUBECONFIG` 环境变量不是必要的。如果 `KUBECONFIG` 环境变量不存在，`kubectl` 使用默认的 kubeconfig 文件，`$HOME/.kube/config`。
|
||||
|
||||
<!--
|
||||
If the `KUBECONFIG` environment variable does exist, `kubectl` uses
|
||||
an effective configuration that is the result of merging the files
|
||||
listed in the `KUBECONFIG` environment variable.
|
||||
--->
|
||||
如果 `KUBECONFIG` 环境变量存在，`kubectl` 使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。
|
||||
|
||||
<!--
|
||||
## Merging kubeconfig files
|
||||
--->
|
||||
## 合并 kubeconfig 文件
|
||||
|
||||
<!--
|
||||
To see your configuration, enter this command:
|
||||
--->
|
||||
|
||||
要查看配置，输入以下命令：
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
<!--
|
||||
As described previously, the output might be from a single kubeconfig file,
|
||||
or it might be the result of merging several kubeconfig files.
|
||||
--->
|
||||
如前所述，输出可能来自 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。
|
||||
|
||||
<!--
|
||||
Here are the rules that `kubectl` uses when it merges kubeconfig files:
|
||||
--->
|
||||
以下是 `kubectl` 在合并 kubeconfig 文件时使用的规则。
|
||||
|
||||
<!--
|
||||
1. If the `--kubeconfig` flag is set, use only the specified file. Do not merge.
|
||||
Only one instance of this flag is allowed.
|
||||
|
||||
Otherwise, if the `KUBECONFIG` environment variable is set, use it as a
|
||||
list of files that should be merged.
|
||||
Merge the files listed in the `KUBECONFIG` environment variable
|
||||
according to these rules:
|
||||
|
||||
* Ignore empty filenames.
|
||||
* Produce errors for files with content that cannot be deserialized.
|
||||
* The first file to set a particular value or map key wins.
|
||||
* Never change the value or map key.
|
||||
Example: Preserve the context of the first file to set `current-context`.
|
||||
Example: If two files specify a `red-user`, use only values from the first file's `red-user`.
|
||||
Even if the second file has non-conflicting entries under `red-user`, discard them.
|
||||
--->
|
||||
1. 如果设置了 `--kubeconfig` 参数，则仅使用指定的文件。不进行合并。此参数只能使用一次。
|
||||
|
||||
否则，如果设置了 `KUBECONFIG` 环境变量，将它用作应合并的文件列表。根据以下规则合并 `KUBECONFIG` 环境变量中列出的文件：
|
||||
|
||||
* 忽略空文件名。
|
||||
* 对于内容无法反序列化的文件，产生错误信息。
|
||||
* 第一个设置特定值或者映射键的文件将生效。
|
||||
* 永远不会更改值或者映射键。示例：保留第一个文件的上下文以设置 `current-context`。示例：如果两个文件都指定了 `red-user`，则仅使用第一个文件的 `red-user` 中的值。即使第二个文件在 `red-user` 下有非冲突条目，也要丢弃它们。
|
||||
|
||||
<!--
|
||||
For an example of setting the `KUBECONFIG` environment variable, see
|
||||
[Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
|
||||
--->
|
||||
有关设置 `KUBECONFIG` 环境变量的示例，请参阅[设置 KUBECONFIG 环境变量](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。
|
||||
|
||||
<!--
|
||||
Otherwise, use the default kubeconfig file, `$HOME/.kube/config`, with no merging.
|
||||
--->
|
||||
否则，使用默认的 kubeconfig 文件， `$HOME/.kube/config`，不进行合并。
|
||||
|
||||
<!--
|
||||
1. Determine the context to use based on the first hit in this chain:
|
||||
|
||||
1. Use the `--context` command-line flag if it exists.
|
||||
1. Use the `current-context` from the merged kubeconfig files.
|
||||
--->
|
||||
1. 根据此链中的第一个匹配确定要使用的上下文。
|
||||
|
||||
1. 如果存在，使用 `--context` 命令行参数。
|
||||
1. 使用合并的 kubeconfig 文件中的 `current-context`。
|
||||
|
||||
<!--
|
||||
An empty context is allowed at this point.
|
||||
--->
|
||||
这种场景下允许空上下文。
|
||||
|
||||
<!--
|
||||
1. Determine the cluster and user. At this point, there might or might not be a context.
|
||||
Determine the cluster and user based on the first hit in this chain,
|
||||
which is run twice: once for user and once for cluster:
|
||||
|
||||
1. Use a command-line flag if it exists: `--user` or `--cluster`.
|
||||
1. If the context is non-empty, take the user or cluster from the context.
|
||||
--->
|
||||
1. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户，这将运行两次：一次用于用户，一次用于集群。
|
||||
|
||||
1. 如果存在，使用命令行参数：`--user` 或者 `--cluster`。
|
||||
1. 如果上下文非空，从上下文中获取用户或集群。
|
||||
|
||||
<!--
|
||||
The user and cluster can be empty at this point.
|
||||
--->
|
||||
这种场景下用户和集群可以为空。
|
||||
|
||||
<!--
|
||||
1. Determine the actual cluster information to use. At this point, there might or
|
||||
might not be cluster information.
|
||||
Build each piece of the cluster information based on this chain; the first hit wins:
|
||||
|
||||
1. Use command line flags if they exist: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`.
|
||||
1. If any cluster information attributes exist from the merged kubeconfig files, use them.
|
||||
1. If there is no server location, fail.
|
||||
--->
|
||||
1. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。基于此链构建每个集群信息；第一个匹配项会被采用：
|
||||
|
||||
1. 如果存在：`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`，使用命令行参数。
|
||||
1. 如果合并的 kubeconfig 文件中存在集群信息属性，则使用它们。
|
||||
1. 如果没有 server 配置，则配置无效。
|
||||
|
||||
<!--
|
||||
1. Determine the actual user information to use. Build user information using the same
|
||||
rules as cluster information, except allow only one authentication
|
||||
technique per user:
|
||||
|
||||
1. Use command line flags if they exist: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`.
|
||||
1. Use the `user` fields from the merged kubeconfig files.
|
||||
1. If there are two conflicting techniques, fail.
|
||||
--->
|
||||
1. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但每个用户只允许一种身份认证技术：
|
||||
|
||||
1. 如果存在：`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`，使用命令行参数。
|
||||
1. 使用合并的 kubeconfig 文件中的 `user` 字段。
|
||||
1. 如果存在两种冲突技术，则配置无效。
|
||||
|
||||
<!--
|
||||
1. For any information still missing, use default values and potentially
|
||||
prompt for authentication information.
|
||||
--->
|
||||
1. 对于仍然缺失的任何信息，使用其对应的默认值，并可能提示输入身份认证信息。
|
||||
|
||||
<!--
|
||||
## File references
|
||||
--->
|
||||
## 文件引用
|
||||
|
||||
<!--
|
||||
File and path references in a kubeconfig file are relative to the location of the kubeconfig file.
|
||||
File references on the command line are relative to the current working directory.
|
||||
In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths
|
||||
are stored absolutely.
|
||||
--->
|
||||
kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。命令行上的文件引用是相当对于当前工作目录的。在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
<!--
|
||||
* [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
--->
|
||||
* [配置对多集群的访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,263 @@
|
|||
---
|
||||
reviewers:
|
||||
- mikedanese
|
||||
title: 配置最佳实践
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
<!--
|
||||
This document highlights and consolidates configuration best practices that are introduced throughout the user guide, Getting Started documentation, and examples.
|
||||
-->
|
||||
本文档重点介绍并整合了整个用户指南、入门文档和示例中介绍的配置最佳实践。
|
||||
|
||||
<!--
|
||||
This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
|
||||
-->
|
||||
这是一份活文件。
|
||||
如果您认为某些内容不在此列表中但可能对其他人有用，请不要犹豫，提交问题或提交 PR。
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
<!--
|
||||
## General Configuration Tips
|
||||
-->
|
||||
## 一般配置提示
|
||||
|
||||
<!--
|
||||
- When defining configurations, specify the latest stable API version.
|
||||
-->
|
||||
- 定义配置时，请指定最新的稳定 API 版本。
|
||||
|
||||
<!--
|
||||
- Configuration files should be stored in version control before being pushed to the cluster. This allows you to quickly roll back a configuration change if necessary. It also aids cluster re-creation and restoration.
|
||||
-->
|
||||
- 在推送到集群之前，配置文件应存储在版本控制中。
|
||||
这允许您在必要时快速回滚配置更改。
|
||||
它还有助于集群重新创建和恢复。
|
||||
|
||||
<!--
|
||||
- Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly.
|
||||
-->
|
||||
- 使用 YAML 而不是 JSON 编写配置文件。虽然这些格式几乎可以在所有场景中互换使用，但 YAML 往往更加用户友好。
|
||||
|
||||
<!--
|
||||
- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
|
||||
-->
|
||||
- 只要有意义，就将相关对象分组到一个文件中。
|
||||
一个文件通常比几个文件更容易管理。
|
||||
请参阅[guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 文件作为此语法的示例。
|
||||
|
||||
<!--
|
||||
- Note also that many `kubectl` commands can be called on a directory. For example, you can call `kubectl apply` on a directory of config files.
|
||||
-->
|
||||
- 另请注意，可以在目录上调用许多`kubectl`命令。
|
||||
例如，你可以在配置文件的目录中调用`kubectl apply`。
|
||||
|
||||
<!--
|
||||
- Don't specify default values unnecessarily: simple, minimal configuration will make errors less likely.
|
||||
-->
|
||||
- 不要不必要地指定默认值：简单的最小配置会降低错误的可能性。
|
||||
|
||||
<!--
|
||||
- Put object descriptions in annotations, to allow better introspection.
|
||||
-->
|
||||
- 将对象描述放在注释中，以便更好地进行内省。
|
||||
|
||||
|
||||
<!--
|
||||
## "Naked" Pods vs ReplicaSets, Deployments, and Jobs
|
||||
-->
|
||||
## “Naked”Pods 与 ReplicaSet，Deployment 和 Jobs
|
||||
|
||||
<!--
|
||||
- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
|
||||
-->
|
||||
- 如果您能避免，不要使用 naked Pods（即，Pod 未绑定到[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 或[Deployment](/docs/concepts/workloads/controllers/deployment/)）。
|
||||
如果节点发生故障，将不会重新安排 Naked Pods。
|
||||
|
||||
<!--
|
||||
A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) may also be appropriate.
|
||||
-->
|
||||
部署，它创建一个 ReplicaSet 以确保所需数量的 Pod 始终可用，并指定替换 Pod 的策略(例如 [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment))，除了一些显式的[`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)场景之外，几乎总是优先考虑直接创建 Pod。
|
||||
[Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 也可能是合适的。
|
||||
|
||||
|
||||
<!--
|
||||
## Services
|
||||
-->
|
||||
## 服务
|
||||
|
||||
<!--
|
||||
- Create a [Service](/docs/concepts/services-networking/service/) before its corresponding backend workloads (Deployments or ReplicaSets), and before any workloads that need to access it. When Kubernetes starts a container, it provides environment variables pointing to all the Services which were running when the container was started. For example, if a Service named `foo` exists, all containers will get the following variables in their initial environment:
|
||||
-->
|
||||
- 在其相应的后端工作负载（Deployment 或 ReplicaSet）之前，以及在需要访问它的任何工作负载之前创建[服务](/docs/concepts/services-networking/service/)。
|
||||
当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。
|
||||
例如，如果存在名为`foo`当服务，则所有容器将在其初始环境中获取以下变量。
|
||||
|
||||
```shell
|
||||
FOO_SERVICE_HOST=<the host the Service is running on>
|
||||
FOO_SERVICE_PORT=<the port the Service is running on>
|
||||
```
|
||||
|
||||
<!--
|
||||
*This does imply an ordering requirement* - any `Service` that a `Pod` wants to access must be created before the `Pod` itself, or else the environment variables will not be populated. DNS does not have this restriction.
|
||||
-->
|
||||
*这确实意味着订购要求* - 必须在`Pod`本身之前创建`Pod`想要访问的任何`Service`，否则将不会填充环境变量。
|
||||
DNS没有此限制。
|
||||
|
||||
<!--
|
||||
- An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The
|
||||
DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically.
|
||||
-->
|
||||
- 一个可选（尽管强烈推荐）[cluster add-on](/docs/concepts/cluster-administration/addons/)是 DNS 服务器。DNS 服务器为新的`Services`监视 Kubernetes API，并为每个创建一组 DNS 记录。
|
||||
如果在整个集群中启用了 DNS，则所有`Pods`应该能够自动对`Services`进行名称解析。
|
||||
|
||||
<!--
|
||||
- Don't specify a `hostPort` for a Pod unless it is absolutely necessary. When you bind a Pod to a `hostPort`, it limits the number of places the Pod can be scheduled, because each <`hostIP`, `hostPort`, `protocol`> combination must be unique. If you don't specify the `hostIP` and `protocol` explicitly, Kubernetes will use `0.0.0.0` as the default `hostIP` and `TCP` as the default `protocol`.
|
||||
-->
|
||||
- 除非绝对必要，否则不要为 Pod 指定`hostPort`。
|
||||
将 Pod 绑定到`hostPort`时，它会限制 Pod 可以调度的位置数，因为每个<`hostIP`, `hostPort`, `protocol`>组合必须是唯一的。如果您没有明确指定`hostIP`和`protocol`，Kubernetes将使用`0.0.0.0`作为默认`hostIP`和`TCP`作为默认`protocol`。
|
||||
|
||||
<!--
|
||||
If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
|
||||
-->
|
||||
如果您只需要访问端口以进行调试，则可以使用[apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或[`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。
|
||||
|
||||
<!--
|
||||
If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#nodeport) Service before resorting to `hostPort`.
|
||||
-->
|
||||
如果您明确需要在节点上公开 Pod 的端口，请在使用`hostPort`之前考虑使用[NodePort](/docs/concepts/services-networking/service/#nodeport) 服务。
|
||||
|
||||
<!--
|
||||
- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
|
||||
-->
|
||||
- 避免使用`hostNetwork`，原因与`hostPort`相同。
|
||||
|
||||
<!--
|
||||
- Use [headless Services](/docs/concepts/services-networking/service/#headless-
|
||||
services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing.
|
||||
-->
|
||||
- 当您不需要`kube-proxy`负载平衡时，使用 [无头服务](/docs/concepts/services-networking/service/#headless-
|
||||
services) (具有`None`的`ClusterIP`)以便于服务发现。
|
||||
|
||||
<!--
|
||||
## Using Labels
|
||||
-->
|
||||
## 使用标签
|
||||
|
||||
<!--
|
||||
- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) app for examples of this approach.
|
||||
-->
|
||||
- 定义并使用[标签](/docs/concepts/overview/working-with-objects/labels/)来识别应用程序或部署的__semantic attributes__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。
|
||||
您可以使用这些标签为其他资源选择合适的 Pod；例如，一个选择所有`tier: frontend` Pod 的服务，或者`app: myapp`的所有`phase: test`组件。
|
||||
有关此方法的示例，请参阅[留言板](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 。
|
||||
|
||||
<!--
|
||||
A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime.
|
||||
-->
|
||||
通过从选择器中省略特定发行版的标签，可以使服务跨越多个部署。
|
||||
[部署](/docs/concepts/workloads/controllers/deployment/)可以在不停机的情况下轻松更新正在运行的服务。
|
||||
|
||||
<!--
|
||||
A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate.
|
||||
-->
|
||||
部署描述了对象的期望状态，并且如果对该规范的更改是_applied_，则部署控制器以受控速率将实际状态改变为期望状态。
|
||||
|
||||
<!--
|
||||
- You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and Services match to Pods using selector labels, removing the relevant labels from a Pod will stop it from being considered by a controller or from being served traffic by a Service. If you remove the labels of an existing Pod, its controller will create a new Pod to take its place. This is a useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
|
||||
-->
|
||||
- 您可以操纵标签进行调试。
|
||||
- 由于 Kubernetes 控制器（例如 ReplicaSet）和服务使用选择器标签与 Pod 匹配，因此从 Pod 中删除相关标签将阻止其被控制器考虑或由服务提供服务流量。
|
||||
如果删除现有 Pod 的标签，其控制器将创建一个新的 Pod 来取代它。
|
||||
这是在"隔离"环境中调试先前"实时"Pod 的有用方法。
|
||||
要以交互方式删除或添加标签，请使用[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)。
|
||||
|
||||
<!--
|
||||
## Container Images
|
||||
-->
|
||||
## 容器镜像
|
||||
|
||||
<!--
|
||||
The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/admin/kubelet/) attempts to pull the specified image.
|
||||
-->
|
||||
当 [kubelet](/docs/admin/kubelet/)尝试拉取指定的镜像时，[imagePullPolicy]（/ docs / concepts / containers / images / #updating-images）和镜像的标签会生效。
|
||||
|
||||
<!--
|
||||
- `imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally.
|
||||
-->
|
||||
- `imagePullPolicy: IfNotPresent`：仅当镜像在本地不存在时镜像才被拉取。
|
||||
|
||||
<!--
|
||||
- `imagePullPolicy: Always`: the image is pulled every time the pod is started.
|
||||
-->
|
||||
- `imagePullPolicy: Always`：每次启动 pod 的时候都会拉取镜像。
|
||||
|
||||
<!--
|
||||
- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `Always` is applied.
|
||||
-->
|
||||
- 省略`imagePullPolicy`，镜像标签为`:latest`或被省略，`Always`被应用。
|
||||
|
||||
<!--
|
||||
- `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `IfNotPresent` is applied.
|
||||
-->
|
||||
- `imagePullPolicy`被省略，并且镜像的标签被指定且不是`:latest`，`IfNotPresent`被应用。
|
||||
|
||||
<!--
|
||||
- `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.
|
||||
-->
|
||||
- `imagePullPolicy: Never`：镜像被假设存在于本地。
|
||||
没有尝试拉取镜像。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
|
||||
-->
|
||||
|
||||
要确保容器始终使用相同版本的镜像，你可以指定其 [摘要](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), 例如`sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`。
|
||||
摘要唯一地标识出镜像的指定版本，因此除非您更改摘要值，否则 Kubernetes 永远不会更新它。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
|
||||
-->
|
||||
|
||||
在生产中部署容器时应避免使用 `:latest` 标记，因为更难跟踪正在运行的镜像版本，并且更难以正确回滚。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
|
||||
-->
|
||||
底层镜像提供程序的缓存语义甚至使 `imagePullPolicy: Always`变得高效。
|
||||
例如，对于 Docker，如果镜像已经存在，则拉取尝试很快，因为镜像层都被缓存并且不需要镜像下载。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## Using kubectl
|
||||
-->
|
||||
## 使用 kubectl
|
||||
|
||||
<!--
|
||||
- Use `kubectl apply -f <directory>`. This looks for Kubernetes configuration in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes it to `apply`.
|
||||
-->
|
||||
- 使用`kubectl apply -f <directory>`。
|
||||
它在`<directory>`中的所有`.yaml`，`.yml`和`.json`文件中查找 Kubernetes 配置，并将其传递给`apply`。
|
||||
|
||||
<!--
|
||||
- Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
|
||||
-->
|
||||
- 使用标签选择器进行`get`和`delete`操作，而不是特定的对象名称。
|
||||
- 请参阅[标签选择器](/docs/concepts/overview/working-with-objects/labels/#label-selectors)和[有效使用标签](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。
|
||||
|
||||
<!--
|
||||
- Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
|
||||
-->
|
||||
- 使用`kubectl run`和`kubectl expose`来快速创建单容器部署和服务。
|
||||
有关示例，请参阅[使用服务访问集群中的应用程序](/docs/tasks/access-application-cluster/service-access-application-cluster/)。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,28 +1,9 @@
|
|||
---
|
||||
approvers:
|
||||
- davidopp
|
||||
- kevin-wangzefeng
|
||||
- bsalamat
|
||||
cn-approvers:
|
||||
- linyouchong
|
||||
title: Taint 和 Toleration
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
approvers:
|
||||
- davidopp
|
||||
- kevin-wangzefeng
|
||||
- bsalamat
|
||||
title: Taints and Tolerations
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
-->
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture overview %}}
|
||||
<!--
|
||||
|
|
@ -78,9 +59,18 @@ To remove the taint added by the command above, you can run:
|
|||
-->
|
||||
想删除上述命令添加的 taint ，您可以运行：
|
||||
```shell
|
||||
kubectl taint nodes kube11 key:NoSchedule-
|
||||
kubectl taint nodes node1 key:NoSchedule-
|
||||
```
|
||||
|
||||
<!--
|
||||
You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the
|
||||
taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able
|
||||
to schedule onto `node1`:
|
||||
-->
|
||||
|
||||
您可以在PodSpec中为容器设定容忍标签。以下两个容忍标签都与上面的 `kubectl taint` 创建的污点“匹配”，
|
||||
因此具有任一容忍标签的Pod都可以将其调度到“ node1”上：
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
- key: "key"
|
||||
|
|
@ -111,13 +101,13 @@ A toleration "matches" a taint if the keys are the same and the effects are the
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Note:** There are two special cases:
|
||||
There are two special cases:
|
||||
|
||||
* An empty `key` with operator `Exists` matches all keys, values and effects which means this
|
||||
will tolerate everything.
|
||||
-->
|
||||
will tolerate everything.
|
||||
-->
|
||||
|
||||
**注意：** 存在两种特殊情况：
|
||||
存在两种特殊情况：
|
||||
|
||||
* 如果一个 toleration 的 `key` 为空且 operator 为 `Exists` ，表示这个 toleration 与任意的 key 、 value 和 effect 都匹配，即这个 toleration 能容忍任意 taint。
|
||||
|
||||
|
|
@ -127,9 +117,8 @@ tolerations:
|
|||
```
|
||||
|
||||
<!--
|
||||
|
||||
* An empty `effect` matches all effects with key `key`.
|
||||
-->
|
||||
-->
|
||||
* 如果一个 toleration 的 `effect` 为空，则 `key` 值与之相同的相匹配 taint 的 `effect` 可以是任意值。
|
||||
|
||||
```yaml
|
||||
|
|
@ -158,13 +147,13 @@ remaining un-ignored taints have the indicated effects on the pod. In particular
|
|||
<!--
|
||||
|
||||
* if there is at least one un-ignored taint with effect `NoSchedule` then Kubernetes will not schedule
|
||||
the pod onto that node
|
||||
the pod onto that node
|
||||
* if there is no un-ignored taint with effect `NoSchedule` but there is at least one un-ignored taint with
|
||||
effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod onto the node
|
||||
effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod onto the node
|
||||
* if there is at least one un-ignored taint with effect `NoExecute` then the pod will be evicted from
|
||||
the node (if it is already running on the node), and will not be
|
||||
scheduled onto the node (if it is not yet running on the node).
|
||||
-->
|
||||
the node (if it is already running on the node), and will not be
|
||||
scheduled onto the node (if it is not yet running on the node).
|
||||
-->
|
||||
* 如果未被过滤的 taint 中存在一个以上 effect 值为 `NoSchedule` 的 taint，则 Kubernetes 不会将 pod 分配到该节点。
|
||||
* 如果未被过滤的 taint 中不存在 effect 值为 `NoSchedule` 的 taint，但是存在 effect 值为 `PreferNoSchedule` 的 taint，则 Kubernetes 会*尝试*将 pod 分配到该节点。
|
||||
* 如果未被过滤的 taint 中存在一个以上 effect 值为 `NoExecute` 的 taint，则 Kubernetes 不会将 pod 分配到该节点（如果 pod 还未在节点上运行），或者将 pod 从该节点驱逐（如果 pod 已经在节点上运行）。
|
||||
|
|
@ -247,52 +236,52 @@ pods that shouldn't be running. A few of the use cases are
|
|||
<!--
|
||||
|
||||
* **Dedicated Nodes**: If you want to dedicate a set of nodes for exclusive use by
|
||||
a particular set of users, you can add a taint to those nodes (say,
|
||||
`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding
|
||||
toleration to their pods (this would be done most easily by writing a custom
|
||||
[admission controller](/docs/reference/access-authn-authz/admission-controllers/)).
|
||||
The pods with the tolerations will then be allowed to use the tainted (dedicated) nodes as
|
||||
well as any other nodes in the cluster. If you want to dedicate the nodes to them *and*
|
||||
ensure they *only* use the dedicated nodes, then you should additionally add a label similar
|
||||
to the taint to the same set of nodes (e.g. `dedicated=groupName`), and the admission
|
||||
controller should additionally add a node affinity to require that the pods can only schedule
|
||||
onto nodes labeled with `dedicated=groupName`.
|
||||
-->
|
||||
a particular set of users, you can add a taint to those nodes (say,
|
||||
`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding
|
||||
toleration to their pods (this would be done most easily by writing a custom
|
||||
[admission controller](/docs/reference/access-authn-authz/admission-controllers/)).
|
||||
The pods with the tolerations will then be allowed to use the tainted (dedicated) nodes as
|
||||
well as any other nodes in the cluster. If you want to dedicate the nodes to them *and*
|
||||
ensure they *only* use the dedicated nodes, then you should additionally add a label similar
|
||||
to the taint to the same set of nodes (e.g. `dedicated=groupName`), and the admission
|
||||
controller should additionally add a node affinity to require that the pods can only schedule
|
||||
onto nodes labeled with `dedicated=groupName`.
|
||||
-->
|
||||
* **专用节点**：如果您想将某些节点专门分配给特定的一组用户使用，您可以给这些节点添加一个 taint（即，
|
||||
`kubectl taint nodes nodename dedicated=groupName:NoSchedule`），然后给这组用户的 pod 添加一个相对应的 toleration（通过编写一个自定义的[admission controller](/docs/admin/admission-controllers/)，很容易就能做到）。拥有上述 toleration 的 pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。如果您希望这些 pod 只能被分配到上述专用节点，那么您还需要给这些专用节点另外添加一个和上述 taint 类似的 label （例如：`dedicated=groupName`），同时 还要在上述 admission controller 中给 pod 增加节点亲和性要求上述 pod 只能被分配到添加了 `dedicated=groupName` 标签的节点上。
|
||||
|
||||
<!--
|
||||
|
||||
* **Nodes with Special Hardware**: In a cluster where a small subset of nodes have specialized
|
||||
hardware (for example GPUs), it is desirable to keep pods that don't need the specialized
|
||||
hardware off of those nodes, thus leaving room for later-arriving pods that do need the
|
||||
specialized hardware. This can be done by tainting the nodes that have the specialized
|
||||
hardware (e.g. `kubectl taint nodes nodename special=true:NoSchedule` or
|
||||
`kubectl taint nodes nodename special=true:PreferNoSchedule`) and adding a corresponding
|
||||
toleration to pods that use the special hardware. As in the dedicated nodes use case,
|
||||
it is probably easiest to apply the tolerations using a custom
|
||||
[admission controller](/docs/eference/access-authn-authz/admission-controllers/)).
|
||||
For example, it is recommended to use [Extended
|
||||
Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
|
||||
to represent the special hardware, taint your special hardware nodes with the
|
||||
extended resource name and run the
|
||||
[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration)
|
||||
admission controller. Now, because the nodes are tainted, no pods without the
|
||||
toleration will schedule on them. But when you submit a pod that requests the
|
||||
extended resource, the `ExtendedResourceToleration` admission controller will
|
||||
automatically add the correct toleration to the pod and that pod will schedule
|
||||
on the special hardware nodes. This will make sure that these special hardware
|
||||
nodes are dedicated for pods requesting such hardware and you don't have to
|
||||
manually add tolerations to your pods.
|
||||
-->
|
||||
hardware (for example GPUs), it is desirable to keep pods that don't need the specialized
|
||||
hardware off of those nodes, thus leaving room for later-arriving pods that do need the
|
||||
specialized hardware. This can be done by tainting the nodes that have the specialized
|
||||
hardware (e.g. `kubectl taint nodes nodename special=true:NoSchedule` or
|
||||
`kubectl taint nodes nodename special=true:PreferNoSchedule`) and adding a corresponding
|
||||
toleration to pods that use the special hardware. As in the dedicated nodes use case,
|
||||
it is probably easiest to apply the tolerations using a custom
|
||||
[admission controller](/docs/reference/access-authn-authz/admission-controllers/).
|
||||
For example, it is recommended to use [Extended
|
||||
Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
|
||||
to represent the special hardware, taint your special hardware nodes with the
|
||||
extended resource name and run the
|
||||
[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration)
|
||||
admission controller. Now, because the nodes are tainted, no pods without the
|
||||
toleration will schedule on them. But when you submit a pod that requests the
|
||||
extended resource, the `ExtendedResourceToleration` admission controller will
|
||||
automatically add the correct toleration to the pod and that pod will schedule
|
||||
on the special hardware nodes. This will make sure that these special hardware
|
||||
nodes are dedicated for pods requesting such hardware and you don't have to
|
||||
manually add tolerations to your pods.
|
||||
-->
|
||||
* **配备了特殊硬件的节点**：在部分节点配备了特殊硬件（比如 GPU）的集群中，我们希望不需要这类硬件的 pod 不要被分配到这些特殊节点，以便为后继需要这类硬件的 pod 保留资源。要达到这个目的，可以先给配备了特殊硬件的节点添加 taint（例如 `kubectl taint nodes nodename special=true:NoSchedule` or `kubectl taint nodes nodename special=true:PreferNoSchedule`)，然后给使用了这类特殊硬件的 pod 添加一个相匹配的 toleration。和专用节点的例子类似，添加这个 toleration 的最简单的方法是使用自定义 [admission controller](/docs/reference/access-authn-authz/admission-controllers/)。比如，我们推荐使用 [Extended Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) 来表示特殊硬件，给配置了特殊硬件的节点添加 taint 时包含 extended resource 名称，然后运行一个 [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) admission controller。此时，因为节点已经被 taint 了，没有对应 toleration 的 Pod 会被调度到这些节点。但当你创建一个使用了 extended resource 的 Pod 时，`ExtendedResourceToleration` admission controller 会自动给 Pod 加上正确的 toleration ，这样 Pod 就会被自动调度到这些配置了特殊硬件件的节点上。这样就能够确保这些配置了特殊硬件的节点专门用于运行 需要使用这些硬件的 Pod，并且您无需手动给这些 Pod 添加 toleration。
|
||||
|
||||
<!--
|
||||
|
||||
* **Taint based Evictions (alpha feature)**: A per-pod-configurable eviction behavior
|
||||
when there are node problems, which is described in the next section.
|
||||
-->
|
||||
* **基于 taint 的驱逐 （alpha 特性）**: 这是在每个 pod 中配置的在节点出现问题时的驱逐行为，接下来的章节会描述这个特性
|
||||
* **Taint based Evictions (beta feature)**: A per-pod-configurable eviction behavior
|
||||
when there are node problems, which is described in the next section.
|
||||
-->
|
||||
* **基于 taint 的驱逐 （beta 特性）**: 这是在每个 pod 中配置的在节点出现问题时的驱逐行为，接下来的章节会描述这个特性
|
||||
|
||||
<!--
|
||||
|
||||
|
|
@ -308,10 +297,10 @@ running on the node as follows
|
|||
|
||||
* pods that do not tolerate the taint are evicted immediately
|
||||
* pods that tolerate the taint without specifying `tolerationSeconds` in
|
||||
their toleration specification remain bound forever
|
||||
their toleration specification remain bound forever
|
||||
* pods that tolerate the taint with a specified `tolerationSeconds` remain
|
||||
bound for the specified amount of time
|
||||
-->
|
||||
-->
|
||||
前文我们提到过 taint 的 effect 值 `NoExecute` ，它会影响已经在节点上运行的 pod
|
||||
* 如果 pod 不能忍受effect 值为 `NoExecute` 的 taint，那么 pod 将马上被驱逐
|
||||
* 如果 pod 能够忍受effect 值为 `NoExecute` 的 taint，但是在 toleration 定义中没有指定 `tolerationSeconds`，则 pod 还会一直在这个节点上运行。
|
||||
|
|
@ -337,6 +326,7 @@ certain condition is true. The following taints are built in:
|
|||
this node, the kubelet removes this taint.
|
||||
-->
|
||||
此外，Kubernetes 1.6 已经支持（alpha阶段）节点问题的表示。换句话说，当某种条件为真时，node controller会自动给节点添加一个 taint。当前内置的 taint 包括：
|
||||
|
||||
* `node.kubernetes.io/not-ready`：节点未准备好。这相当于节点状态 `Ready` 的值为 "`False`"。
|
||||
* `node.kubernetes.io/unreachable`：node controller 访问不到节点. 这相当于节点状态 `Ready` 的值为 "`Unknown`"。
|
||||
* `node.kubernetes.io/out-of-disk`：节点磁盘耗尽。
|
||||
|
|
@ -347,13 +337,11 @@ certain condition is true. The following taints are built in:
|
|||
* `node.cloudprovider.kubernetes.io/uninitialized`：如果 kubelet 启动时指定了一个 "外部" cloud provider，它将给当前节点添加一个 taint 将其标志为不可用。在 cloud-controller-manager 的一个 controller 初始化这个节点后，kubelet 将删除这个 taint。
|
||||
|
||||
<!--
|
||||
When the `TaintBasedEvictions` alpha feature is enabled (you can do this by
|
||||
including `TaintBasedEvictions=true` in `--feature-gates` for Kubernetes controller manager,
|
||||
such as `--feature-gates=FooBar=true,TaintBasedEvictions=true`), the taints are automatically
|
||||
In version 1.13, the `TaintBasedEvictions` feature is promoted to beta and enabled by default, hence the taints are automatically
|
||||
added by the NodeController (or kubelet) and the normal logic for evicting pods from nodes
|
||||
based on the Ready NodeCondition is disabled.
|
||||
-->
|
||||
在启用了 `TaintBasedEvictions` 这个 alpha 功能特性后（在 Kubernetes controller manager 的 `--feature-gates` 参数中包含`TaintBasedEvictions=true` 开启这个功能特性，例如：`--feature-gates=FooBar=true,TaintBasedEvictions=true`），NodeController (或 kubelet)会自动给节点添加这类 taint，上述基于节点状态 Ready 对 pod 进行驱逐的逻辑会被禁用。
|
||||
在版本1.13中，`TaintBasedEvictions` 功能已升级为Beta，并且默认启用，因此污点会自动给节点添加这类 taint，上述基于节点状态 Ready 对 pod 进行驱逐的逻辑会被禁用。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
|
|
@ -366,10 +354,10 @@ as the master becoming partitioned from the nodes.
|
|||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
This alpha feature, in combination with `tolerationSeconds`, allows a pod
|
||||
This beta feature, in combination with `tolerationSeconds`, allows a pod
|
||||
to specify how long it should stay bound to a node that has one or both of these problems.
|
||||
-->
|
||||
使用这个 alpha 功能特性，结合 `tolerationSeconds` ，pod 就可以指定当节点出现一个或全部上述问题时还将在这个节点上运行多长的时间。
|
||||
使用这个 beta 功能特性，结合 `tolerationSeconds` ，pod 就可以指定当节点出现一个或全部上述问题时还将在这个节点上运行多长的时间。
|
||||
|
||||
<!--
|
||||
For example, an application with a lot of local state might want to stay
|
||||
|
|
@ -381,7 +369,7 @@ The toleration the pod would use in that case would look like
|
|||
|
||||
```yaml
|
||||
tolerations:
|
||||
- key: "node.alpha.kubernetes.io/unreachable"
|
||||
- key: "node.kubernetes.io/unreachable"
|
||||
operator: "Exists"
|
||||
effect: "NoExecute"
|
||||
tolerationSeconds: 6000
|
||||
|
|
@ -393,9 +381,9 @@ Note that Kubernetes automatically adds a toleration for
|
|||
unless the pod configuration provided
|
||||
by the user already has a toleration for `node.kubernetes.io/not-ready`.
|
||||
Likewise it adds a toleration for
|
||||
`node.alpha.kubernetes.io/unreachable` with `tolerationSeconds=300`
|
||||
`node.kubernetes.io/unreachable` with `tolerationSeconds=300`
|
||||
unless the pod configuration provided
|
||||
by the user already has a toleration for `node.alpha.kubernetes.io/unreachable`.
|
||||
by the user already has a toleration for `node.kubernetes.io/unreachable`.
|
||||
-->
|
||||
注意，Kubernetes 会自动给 pod 添加一个 key 为 `node.kubernetes.io/not-ready` 的 toleration 并配置 `tolerationSeconds=300`，除非用户提供的 pod 配置中已经已存在了 key 为 `node.kubernetes.io/not-ready` 的 toleration。同样，Kubernetes 会给 pod 添加一个 key 为 `node.kubernetes.io/unreachable` 的 toleration 并配置 `tolerationSeconds=300`，除非用户提供的 pod 配置中已经已存在了 key 为 `node.kubernetes.io/unreachable` 的 toleration。
|
||||
|
||||
|
|
@ -413,7 +401,7 @@ admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/default
|
|||
[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with
|
||||
`NoExecute` tolerations for the following taints with no `tolerationSeconds`:
|
||||
|
||||
* `node.alpha.kubernetes.io/unreachable`
|
||||
* `node.kubernetes.io/unreachable`
|
||||
* `node.kubernetes.io/not-ready`
|
||||
|
||||
This ensures that DaemonSet pods are never evicted due to these problems,
|
||||
|
|
@ -421,23 +409,22 @@ which matches the behavior when this feature is disabled.
|
|||
-->
|
||||
[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 中的 pod 被创建时，针对以下 taint 自动添加的 `NoExecute` 的 toleration 将不会指定 `tolerationSeconds`：
|
||||
|
||||
* `node.alpha.kubernetes.io/unreachable`
|
||||
* `node.kubernetes.io/unreachable`
|
||||
* `node.kubernetes.io/not-ready`
|
||||
|
||||
这保证了出现上述问题时 DaemonSet 中的 pod 永远不会被驱逐，这和 `TaintBasedEvictions` 这个特性被禁用后的行为是一样的。
|
||||
|
||||
<!--
|
||||
|
||||
## Taint Nodes by Condition
|
||||
|
||||
-->
|
||||
|
||||
## 基于节点状态添加 taint
|
||||
|
||||
<!--
|
||||
Version 1.8 introduces an alpha feature that causes the node controller to create taints corresponding to
|
||||
Node conditions. When this feature is enabled (you can do this by including `TaintNodesByCondition=true` in the `--feature-gates` command line flag to the scheduler, such as
|
||||
`--feature-gates=FooBar=true,TaintNodesByCondition=true`), the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations.
|
||||
In version 1.12, `TaintNodesByCondition` feature is promoted to beta, so node lifecycle controller automatically creates taints corresponding to
|
||||
Node conditions.
|
||||
Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations.
|
||||
Note that `TaintNodesByCondition` only taints nodes with `NoSchedule` effect. `NoExecute` effect is controlled by `TaintBasedEviction` which is a beta feature and enabled by default since version 1.13.
|
||||
|
||||
Starting in Kubernetes 1.8, the DaemonSet controller automatically adds the
|
||||
following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from
|
||||
|
|
@ -448,9 +435,12 @@ breaking.
|
|||
* `node.kubernetes.io/out-of-disk` (*only for critical pods*)
|
||||
* `node.kubernetes.io/unschedulable` (1.10 or later)
|
||||
* `node.kubernetes.io/network-unavailable` (*host network only*)
|
||||
-->
|
||||
1.8 版本引入了一个 alpha 特性，让 node controller 根据节点的状态创建 taint。当开启了这个特性时（通过给 scheduler 的 `--feature-gates` 添加 `TaintNodesByCondition=true` 参数，例如：`--feature-gates=FooBar=true,TaintNodesByCondition=true`），scheduler不会去检查节点的状态，而是检查节点的 taint。这确保了节点的状态不影响应该调度哪些 Pod 到节点上。用户可以通过给 Pod 添加 toleration 来选择忽略节点的一些问题（节点状态的形式表示）。
|
||||
从 Kubernetes 1.8 开始，DaemonSet controller 会自动添加如下 `NoSchedule` toleration，以防止 DaemonSet 中断。
|
||||
-->
|
||||
在版本1.12中，`TaintNodesByCondition` 功能已升级为Beta，因此节点生命周期控制器会自动创建与Node条件相对应的污点。
|
||||
同样，调度程序不检查节点条件。 而是调度程序检查污点。 这确保了节点条件不会影响调度到节点上的内容。 用户可以通过添加适当的 Pod 容忍来选择忽略某些Node的问题(表示为 Node 的调度条件)。
|
||||
注意，`TaintNodesByCondition` 只会污染具有 `NoSchedule` 设定的节点。 `NoExecute` 效应由 `TaintBasedEviction` 控制，
|
||||
`TaintBasedEviction` 是 Beta 版功能，自1.13版起默认启用。
|
||||
|
||||
* `node.kubernetes.io/memory-pressure`
|
||||
* `node.kubernetes.io/disk-pressure`
|
||||
* `node.kubernetes.io/out-of-disk` (*只适合 critical pod*)
|
||||
|
|
@ -461,4 +451,5 @@ breaking.
|
|||
Adding these tolerations ensures backward compatibility. You can also add
|
||||
arbitrary tolerations to DaemonSets.
|
||||
-->
|
||||
|
||||
添加上述 toleration 确保了向后兼容，您也可以选择自由的向 DaemonSet 添加 toleration。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
title: 标准化词汇表
|
||||
layout: glossary
|
||||
noedit: true
|
||||
default_active_tag: fundamental
|
||||
weight: 5
|
||||
card:
|
||||
name: 参考
|
||||
weight: 10
|
||||
title: 词汇表
|
||||
---
|
||||
|
||||
Loading…
Reference in New Issue