Merge remote-tracking branch 'upstream/master' into dev-1.19
This commit is contained in:
Savitha Raghunathan
@@ -17,7 +17,7 @@ about your *desired state*. The actual room temperature is the
|
||||
closer to the desired state, by turning equipment on or off.
|
||||
-->
|
||||
|
||||
在机器人技术和自动化中，控制环是一个控制系统状态的不终止的循环。
|
||||
在机器人技术和自动化中，控制回路是一个非终止回路，用于调节系统状态。
|
||||
|
||||
这是一个控制环的例子：房间里的温度自动调节器。
|
||||
|
||||
|
||||
@@ -4,14 +4,12 @@ content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- caesarxuchao
|
||||
- dchen1107
|
||||
title: Nodes
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
@@ -26,18 +24,11 @@ architecture design doc for more details.
|
||||
-->
|
||||
在 Kubernetes 中，节点（Node）是执行工作的机器，以前叫做 `minion`。根据你的集群环境，节点可以是一个虚拟机或者物理机器。每个节点都包含用于运行 [pods](/docs/concepts/workloads/pods/pod/) 的必要服务，并由主控组件管理。节点上的服务包括 [容器运行时](/docs/concepts/overview/components/#node-components)、kubelet 和 kube-proxy。查阅架构设计文档中 [Kubernetes 节点](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 一节获取更多细节。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Node Status
|
||||
-->
|
||||
## 节点状态
|
||||
|
||||
<!--
|
||||
A node's status contains the following information:
|
||||
|
||||
* [Addresses](#addresses)
|
||||
@@ -45,6 +36,9 @@ A node's status contains the following information:
|
||||
* [Capacity and Allocatable](#capacity)
|
||||
* [Info](#info)
|
||||
-->
|
||||
|
||||
## 节点状态
|
||||
|
||||
一个节点的状态包含以下信息:
|
||||
|
||||
* [地址](#addresses)
|
||||
@@ -52,11 +46,11 @@ A node's status contains the following information:
|
||||
* [容量与可分配](#capacity)
|
||||
* [信息](#info)
|
||||
|
||||
|
||||
<!--
|
||||
Node status and other details about a node can be displayed using below command:
|
||||
-->
|
||||
可以使用以下命令显示节点状态和有关节点的其他详细信息：
|
||||
|
||||
```shell
|
||||
kubectl describe node <insert-node-name-here>
|
||||
```
|
||||
@@ -67,32 +61,29 @@ Each section is described in detail below.
|
||||
|
||||
<!--
|
||||
### Addresses
|
||||
|
||||
The usage of these fields varies depending on your cloud provider or bare metal configuration.
|
||||
-->
|
||||
### 地址
|
||||
|
||||
<!--
|
||||
The usage of these fields varies depending on your cloud provider or bare metal configuration.
|
||||
-->
|
||||
这些字段组合的用法取决于你的云服务商或者裸机配置。
|
||||
|
||||
<!--
|
||||
* HostName: The as reported by the node's kernel. Can be overridden via the kubelet `--hostname-override` parameter.
|
||||
* HostName: The as reported by the node's kernel. Can be overridden via the kubelet `-hostname-override` parameter.
|
||||
* ExternalIP: Typically the IP address of the node that is externally routable (available from outside the cluster).
|
||||
* InternalIP: Typichostnameally the IP address of the node that is routable only within the cluster.
|
||||
-->
|
||||
* HostName：由节点的内核指定。可以通过 kubelet 的 `--hostname-override` 参数覆盖。
|
||||
* ExternalIP：通常是可以外部路由的节点 IP 地址（从集群外可访问）。
|
||||
* InternalIP：通常是仅可在集群内部路由的节点 IP 地址。
|
||||
|
||||
* HostName：由节点的内核设置。可以通过 kubelet 的 `--hostname-override` 参数覆盖。
|
||||
* ExternalIP：通常是节点的可以外部路由（从集群外可访问）的 IP 地址。
|
||||
* InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。
|
||||
|
||||
<!--
|
||||
### Conditions {#condition}
|
||||
|
||||
The `conditions` field describes the status of all `Running` nodes. Examples of conditions include:
|
||||
-->
|
||||
### 条件 {#condition}
|
||||
|
||||
<!--
|
||||
The `conditions` field describes the status of all `Running` nodes. Examples of conditions include:
|
||||
-->
|
||||
`conditions` 字段描述了所有 `Running` 节点的状态。条件的示例包括：
|
||||
|
||||
<!--
|
||||
@@ -100,24 +91,24 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
|
||||
|----------------|-------------|
|
||||
| `OutOfDisk` | `True` if there is insufficient free space on the node for adding new pods, otherwise `False` |
|
||||
| `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) |
|
||||
| `MemoryPressure` | `True` if pressure exists on the node memory -- that is, if the node memory is low; otherwise `False` |
|
||||
| `PIDPressure` | `True` if pressure exists on the processes -- that is, if there are too many processes on the node; otherwise `False` |
|
||||
| `DiskPressure` | `True` if pressure exists on the disk size -- that is, if the disk capacity is low; otherwise `False` |
|
||||
| `MemoryPressure` | `True` if pressure exists on the node memory - that is, if the node memory is low; otherwise `False` |
|
||||
| `PIDPressure` | `True` if pressure exists on the processes - that is, if there are too many processes on the node; otherwise `False` |
|
||||
| `DiskPressure` | `True` if pressure exists on the disk size - that is, if the disk capacity is low; otherwise `False` |
|
||||
| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
|
||||
-->
|
||||
| 节点条件 | 描述 |
|
||||
| 节点条件 | 描述 |
|
||||
|----------------|-------------|
|
||||
| `OutOfDisk` | `True` 表示节点的空闲空间不足以用于添加新 pods, 否则为 `False` |
|
||||
| `Ready` | 表示节点是健康的并已经准备好接受 pods；`False` 表示节点不健康而且不能接受 pods；`Unknown` 表示节点控制器在最近 40 秒内没有收到节点的消息 |
|
||||
| `MemoryPressure` | `True` 表示节点存在内存压力 -- 即节点内存用量低，否则为 `False` |
|
||||
| `PIDPressure` | `True` 表示节点存在进程压力 -- 即进程过多；否则为 `False` |
|
||||
| `DiskPressure` | `True` 表示节点存在磁盘压力 -- 即磁盘可用量低，否则为 `False` |
|
||||
| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` |
|
||||
| `OutOfDisk` | `True` 表示节点的空闲空间不足以用于添加新 Pods, 否则为 `False` |
|
||||
| `Ready` | 表示节点是健康的并已经准备好接收 Pods；`False` 表示节点不健康而且不能接收 Pods；`Unknown` 表示节点控制器在最近 `node-monitor-grace-period` 期间（默认 40 秒）没有收到节点的消息 |
|
||||
| `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` |
|
||||
| `PIDPressure` | `True` 表示节点存在进程压力，即进程过多；否则为 `False` |
|
||||
| `DiskPressure` | `True` 表示节点存在磁盘压力，即磁盘可用量低，否则为 `False` |
|
||||
| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` |
|
||||
|
||||
<!--
|
||||
The node condition is represented as a JSON object. For example, the following response describes a healthy node.
|
||||
-->
|
||||
节点条件使用一个 JSON 对象表示。例如，下面的响应描述了一个健康的节点。
|
||||
节点条件使用 JSON 对象表示。例如，下面的响应描述了一个健康的节点。
|
||||
|
||||
```json
|
||||
"conditions": [
|
||||
@@ -135,8 +126,12 @@ The node condition is represented as a JSON object. For example, the following r
|
||||
<!--
|
||||
If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout`, an argument is passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/) and all the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the apiserver is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
|
||||
-->
|
||||
如果 Ready 条件处于状态 `Unknown` 或者 `False` 的时间超过了 `pod-eviction-timeout`（一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数），节点上的所有 Pods 都会被节点控制器计划删除。默认的删除超时时长为**5 分钟**。某些情况下，当节点不可访问时，apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。与此同时，被计划删除的 pods 可能会继续在分区节点上运行。
|
||||
|
||||
如果 Ready 条件处于状态 `Unknown` 或者 `False` 的时间超过了 `pod-eviction-timeout`
|
||||
（一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数），
|
||||
节点上的所有 Pods 都会被节点控制器计划删除。默认的逐出超时时长为 **5 分钟**。
|
||||
某些情况下，当节点不可访问时，apiserver 不能和其上的 kubelet 通信。
|
||||
删除 Pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。
|
||||
与此同时，被计划删除的 Pods 可能会继续在游离的节点上运行。
|
||||
|
||||
<!--
|
||||
In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
|
||||
@@ -146,8 +141,12 @@ the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce fr
|
||||
permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from
|
||||
Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names.
|
||||
-->
|
||||
在 1.5 版本之前的 Kubernetes 里，节点控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里，在节点控制器确认这些 pods 已经在集群停止运行前不会强制删除它们。你可以看到这些处于 `Terminating` 或者 `Unknown` 状态的 pods 可能在无法访问的节点上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个节点是否已经永久的离开了集群，集群管理员可能需要手动删除这个节点对象。从 Kubernetes 删除节点对象将导致 apiserver 删除节点上所有运行的 Pod 对象并释放它们的名字。
|
||||
|
||||
在 1.5 版本之前的 Kubernetes 上，节点控制器会将不能访问的 Pods 从 apiserver 中
|
||||
[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。
|
||||
但在 1.5 或更高的版本里，在节点控制器确认这些 Pods 在集群中已经停止运行前，不会强制删除它们。
|
||||
你可以看到这些可能在无法访问的节点上运行的 Pods 处于 `Terminating` 或者 `Unknown` 状态。
|
||||
如果 kubernetes 不能基于下层基础设施推断出某节点是否已经永久离开了集群，集群管理员可能需要手动删除该节点对象。
|
||||
从 Kubernetes 删除节点对象将导致 apiserver 删除节点上所有运行的 Pod 对象并释放它们的名字。
|
||||
|
||||
<!--
|
||||
The node lifecycle controller automatically creates
|
||||
@@ -156,18 +155,17 @@ When the scheduler is assigning a Pod to a Node, the scheduler takes the Node's
|
||||
into account, except for any taints that the Pod tolerates.
|
||||
-->
|
||||
节点生命周期控制器会自动创建代表条件的[污点](/docs/concepts/configuration/taint-and-toleration/)。
|
||||
当调度器将 Pod 分配给节点时，调度器会考虑节点上的污点，但是 Pod 可以容忍的污点除外。
|
||||
当调度器将 Pod 指派给某节点时，调度器会考虑节点上的污点，但是 Pod 可以容忍的污点除外。
|
||||
|
||||
<!--
|
||||
### Capacity and Allocatable {#capacity}
|
||||
-->
|
||||
### 容量与可分配 {#capacity}
|
||||
|
||||
<!--
|
||||
Describes the resources available on the node: CPU, memory and the maximum
|
||||
number of pods that can be scheduled onto the node.
|
||||
-->
|
||||
描述节点上的可用资源：CPU、内存和可以调度到节点上的 pods 的最大数量。
|
||||
### 容量与可分配 {#capacity}
|
||||
|
||||
描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pods 的个数上限。
|
||||
|
||||
<!--
|
||||
The fields in the capacity block indicate the total amount of resources that a
|
||||
@@ -180,25 +178,24 @@ capacity 块中的字段指示节点拥有的资源总量。allocatable 块指
|
||||
You may read more about capacity and allocatable resources while learning how
|
||||
to [reserve compute resources](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) on a Node.
|
||||
-->
|
||||
可以在学习如何在节点上[保留计算资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)的同时阅读有关容量和可分配资源的更多信息。
|
||||
可以在学习如何在节点上[保留计算资源](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
|
||||
的同时阅读有关容量和可分配资源的更多信息。
|
||||
|
||||
<!--
|
||||
### Info
|
||||
-->
|
||||
### 信息
|
||||
|
||||
<!--
|
||||
Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name.
|
||||
This information is gathered by Kubelet from the node.
|
||||
-->
|
||||
关于节点的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。
|
||||
|
||||
### 信息 {#info}
|
||||
|
||||
关于节点的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本
|
||||
（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。
|
||||
|
||||
<!--
|
||||
## Management
|
||||
-->
|
||||
## 管理
|
||||
|
||||
<!--
|
||||
Unlike [pods](/docs/concepts/workloads/pods/pod/) and [services](/docs/concepts/services-networking/service/),
|
||||
a node is not inherently created by Kubernetes: it is created externally by cloud
|
||||
providers like Google Compute Engine, or it exists in your pool of physical or virtual
|
||||
@@ -207,8 +204,13 @@ an object that represents the node. After creation, Kubernetes
|
||||
checks whether the node is valid or not. For example, if you try to create
|
||||
a node from the following content:
|
||||
-->
|
||||
与 [pods](/docs/concepts/workloads/pods/pod/) 和 [services](/docs/concepts/services-networking/service/) 不同，节点并不是在 Kubernetes 内部创建的：它是被外部的云服务商创建，例如 Google Compute Engine 或者你的集群中的物理或者虚拟机。这意味着当 Kubernetes 创建一个节点时，它其实仅仅创建了一个对象来代表这个节点。创建以后，Kubernetes 将检查这个节点是否可用。例如，如果你尝试使用如下内容创建一个节点：
|
||||
|
||||
## 管理
|
||||
与 [Pods](/docs/concepts/workloads/pods/pod/) 和 [Services](/docs/concepts/services-networking/service/) 不同，
|
||||
节点并不是在 Kubernetes 中从头创建的：它们由外部的云服务商（例如 Google Compute Engine）创建，或者是来自你的资源池
|
||||
中的物理机或者虚拟机。
|
||||
这意味着当 Kubernetes 创建一个节点时，它其实仅仅创建了一个对象来代表这个节点。
|
||||
创建以后，Kubernetes 将检查这个节点是否可用。例如，如果你尝试使用如下内容创建一个节点：
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -229,12 +231,19 @@ validates the node by health checking based on the `metadata.name` field. If the
|
||||
services are running -- it is eligible to run a pod. Otherwise, it is
|
||||
ignored for any cluster activity until it becomes valid.
|
||||
-->
|
||||
Kubernetes 会在内部创一个 Node 对象（用以表示节点），并基于 `metadata.name` 字段执行健康检查，对节点进行验证。如果节点可用，意即所有必要服务都已运行，它就符合了运行一个 pod 的条件；否则它将被所有的集群动作忽略直到变为可用。
|
||||
Kubernetes 会在内部创一个 Node 对象（用以表示节点），并基于 `metadata.name` 字段执行健康检查，
|
||||
如果节点合法，即所有必要服务都处于运行状态，它就有资格运行 Pod；否则它将被所有的集群活动忽略直到其变为合法为止。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid.
|
||||
You must explicitly delete the Node object to stop this process.
|
||||
{{< /note >}}
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid.
|
||||
You must explicitly delete the Node object to stop this process.--> Kubernetes 保留无效节点的对象，并继续检查它是否有效。必须显式删除 Node 对象以停止此过程。
|
||||
Kubernetes 保留无效节点所对应的对象，并持续检查它是否合法。
|
||||
若要停止这种检查，必须显式删除 Node 对象。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
@@ -245,20 +254,18 @@ interface: node controller, kubelet, and kubectl.
|
||||
|
||||
<!--
|
||||
### Node Controller
|
||||
-->
|
||||
### 节点控制器
|
||||
|
||||
<!--
|
||||
The node controller is a Kubernetes master component which manages various
|
||||
aspects of nodes.
|
||||
-->
|
||||
节点控制器是一个 Kubernetes master 组件，管理节点的方方面面。
|
||||
|
||||
<!--
|
||||
The node controller has multiple roles in a node's life. The first is assigning a
|
||||
CIDR block to the node when it is registered (if CIDR assignment is turned on).
|
||||
-->
|
||||
节点控制器在节点的生命周期中扮演了多个角色。第一个是当节点注册时为它分配一个 CIDR block（如果打开了 CIDR 分配）。
|
||||
### 节点控制器
|
||||
|
||||
节点控制器是一个 Kubernetes 控制面组件，管理节点的方方面面。
|
||||
|
||||
节点控制器在节点的生命周期中扮演多个角色。第一个是当节点注册时为它分配一个 CIDR 区间（如果启用了 CIDR 分配）。
|
||||
|
||||
<!--
|
||||
The second is keeping the node controller's internal list of nodes up to date with
|
||||
@@ -267,7 +274,9 @@ environment, whenever a node is unhealthy, the node controller asks the cloud
|
||||
provider if the VM for that node is still available. If not, the node
|
||||
controller deletes the node from its list of nodes.
|
||||
-->
|
||||
第二个是使用云服务商提供了可用节点列表保持节点控制器内部的节点列表更新。如果在云环境下运行，任何时候当一个节点不健康时节点控制器将询问云服务节点的虚拟机是否可用。如果不可用，节点控制器会将这个节点从它的节点列表删除。
|
||||
第二个保持节点控制器内部的节点列表与云服务商所提供的可用机器列表同步。
|
||||
如果在云环境下运行，当某节点不健康时，节点控制器将询问云服务是否节点的虚拟机可用。
|
||||
如果不可用，节点控制器会将该节点从它的节点列表删除。
|
||||
|
||||
<!--
|
||||
The third is monitoring the nodes' health. The node controller is
|
||||
@@ -277,16 +286,18 @@ receiving heartbeats for some reason, e.g. due to the node being down), and then
|
||||
all the pods from the node (using graceful termination) if the node continues
|
||||
to be unreachable. (The default timeouts are 40s to start reporting
|
||||
ConditionUnknown and 5m after that to start evicting pods.) The node controller
|
||||
checks the state of each node every `--node-monitor-period` seconds.
|
||||
checks the state of each node every `-node-monitor-period` seconds.
|
||||
-->
|
||||
第三个是监控节点的健康情况。节点控制器负责在节点不能访问时（也即是节点控制器因为某些原因没有收到心跳，例如节点宕机）将它的 NodeStatus 的 NodeReady 状态更新为 ConditionUnknown。后续如果节点持续不可访问，节点控制器将删除节点上的所有 pods（使用优雅终止）。（默认情况下 40s 开始报告 ConditionUnknown，在那之后 5m 开始删除 pods。）节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。
|
||||
第三个是监控节点的健康情况。节点控制器负责在节点不可达
|
||||
（即，节点控制器因为某些原因没有收到心跳，例如节点宕机）时，
|
||||
将它的 NodeStatus 的 NodeReady 条件更新为 ConditionUnknown。
|
||||
后续如果节点持续不可达，节点控制器将逐出节点上的所有 Pods（使用体面终止）。
|
||||
（默认情况下 40s 后开始报告 ConditionUnknown，在那之后 5m 开始逐出 Pods。）
|
||||
节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。
|
||||
|
||||
<!--
|
||||
#### Heartbeats
|
||||
-->
|
||||
#### 心跳机制
|
||||
|
||||
<!--
|
||||
Heartbeats, sent by Kubernetes nodes, help determine the availability of a node.
|
||||
There are two forms of heartbeats: updates of `NodeStatus` and the
|
||||
[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io).
|
||||
@@ -295,6 +306,8 @@ Each Node has an associated Lease object in the `kube-node-lease`
|
||||
Lease is a lightweight resource, which improves the performance
|
||||
of the node heartbeats as the cluster scales.
|
||||
-->
|
||||
#### 心跳机制
|
||||
|
||||
Kubernetes 节点发送的心跳有助于确定节点的可用性。
|
||||
心跳有两种形式：`NodeStatus` 和 [`Lease` 对象](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io)。
|
||||
每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="命名空间">}} 中都有一个关联的 `Lease` 对象。
|
||||
@@ -316,57 +329,69 @@ kubelet 负责创建和更新 `NodeStatus` 和 `Lease` 对象。
|
||||
`NodeStatus` updates.
|
||||
-->
|
||||
- 当状态发生变化时，或者在配置的时间间隔内没有更新时，kubelet 会更新 `NodeStatus`。
|
||||
`NodeStatus` 更新的默认间隔为 5 分钟（比无法访问的节点的 40 秒默认超时时间长很多）。
|
||||
`NodeStatus` 更新的默认间隔为 5 分钟（比不可达节点的 40 秒默认超时时间长很多）。
|
||||
- kubelet 会每 10 秒（默认更新间隔时间）创建并更新其 `Lease` 对象。`Lease` 更新独立于 `NodeStatus` 更新而发生。
|
||||
|
||||
<!--
|
||||
#### Reliability
|
||||
-->
|
||||
#### 可靠性
|
||||
|
||||
<!--
|
||||
In Kubernetes 1.4, we updated the logic of the node controller to better handle
|
||||
cases when a large number of nodes have problems with reaching the master
|
||||
(e.g. because the master has networking problem). Starting with 1.4, the node
|
||||
controller looks at the state of all nodes in the cluster when making a
|
||||
decision about pod eviction.
|
||||
-->
|
||||
在 Kubernetes 1.4 中我们更新了节点控制器逻辑以更好地处理大批量节点访问 master 出问题的情况（例如 master 的网络出了问题）。从 1.4 开始，节点控制器在决定删除 pod 之前会检查集群中所有节点的状态。
|
||||
#### 可靠性
|
||||
|
||||
在 Kubernetes 1.4 中我们更新了节点控制器逻辑以更好地处理大批量节点访问控制面而出问题的情况
|
||||
（例如，控制面节点的网络出了问题）。从 1.4 开始，节点控制器在决定逐出 Pod 之前
|
||||
会检查集群中所有节点的状态。
|
||||
|
||||
<!--
|
||||
In most cases, node controller limits the eviction rate to
|
||||
`--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
|
||||
`-node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
|
||||
from more than 1 node per 10 seconds.
|
||||
-->
|
||||
大部分情况下，节点控制器把驱逐频率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。这表示它每 10 秒钟内至多从一个节点驱逐 Pods。
|
||||
|
||||
大部分情况下，节点控制器把驱逐速率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。
|
||||
这表示它每 10 秒钟内至多从一个节点驱逐 Pods。
|
||||
|
||||
<!--
|
||||
The node eviction behavior changes when a node in a given availability zone
|
||||
becomes unhealthy. The node controller checks what percentage of nodes in the zone
|
||||
are unhealthy (NodeReady condition is ConditionUnknown or ConditionFalse) at
|
||||
the same time. If the fraction of unhealthy nodes is at least
|
||||
`--unhealthy-zone-threshold` (default 0.55) then the eviction rate is reduced:
|
||||
`-unhealthy-zone-threshold` (default 0.55) then the eviction rate is reduced:
|
||||
if the cluster is small (i.e. has less than or equal to
|
||||
`--large-cluster-size-threshold` nodes - default 50) then evictions are
|
||||
`-large-cluster-size-threshold` nodes - default 50) then evictions are
|
||||
stopped, otherwise the eviction rate is reduced to
|
||||
`--secondary-node-eviction-rate` (default 0.01) per second. The reason these
|
||||
`-secondary-node-eviction-rate` (default 0.01) per second. The reason these
|
||||
policies are implemented per availability zone is because one availability zone
|
||||
might become partitioned from the master while the others remain connected. If
|
||||
your cluster does not span multiple cloud provider availability zones, then
|
||||
there is only one availability zone (the whole cluster).
|
||||
-->
|
||||
当一个可用区域中的节点变为不健康时，它的驱逐行为将发生改变。节点控制器会同时检查可用区域中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse）的节点的百分比。如果不健康节点的部分超过 `--unhealthy-zone-threshold` （默认为 0.55），驱逐速率将会减小：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个 节点 - 默认为 50），驱逐操作将会停止，否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。在单个可用区域实施这些策略的原因是当一个可用区域可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个可用区域，那就只有一个可用区域整个集群）。
|
||||
当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。
|
||||
节点控制器会同时检查可用区域中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse）
|
||||
的节点的百分比。如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55），
|
||||
驱逐速率将会降低：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个节点 - 默认为 50），
|
||||
驱逐操作将会停止，否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。
|
||||
在单个可用区域实施这些策略的原因是当一个可用区域可能从控制面脱离时其它可用区域可能仍然保持连接。
|
||||
如果你的集群没有跨越云服务商的多个可用区域，那（整个集群）就只有一个可用区域。
|
||||
|
||||
<!--
|
||||
A key reason for spreading your nodes across availability zones is so that the
|
||||
workload can be shifted to healthy zones when one entire zone goes down.
|
||||
Therefore, if all nodes in a zone are unhealthy then node controller evicts at
|
||||
the normal rate `--node-eviction-rate`. The corner case is when all zones are
|
||||
the normal rate `-node-eviction-rate`. The corner case is when all zones are
|
||||
completely unhealthy (i.e. there are no healthy nodes in the cluster). In such
|
||||
case, the node controller assumes that there's some problem with master
|
||||
connectivity and stops all evictions until some connectivity is restored.
|
||||
-->
|
||||
在多个可用区域分布你的节点的一个关键原因是当整个可用区域故障时，工作负载可以转移到健康的可用区域。因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率 `--node-eviction-rate` 进行驱逐操作。在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，节点控制器将假设 master 的连接出了某些问题，它将停止所有驱逐动作直到一些连接恢复。
|
||||
跨多个可用区域部署你的节点的一个关键原因是当某个可用区域整体出现故障时，工作负载可以转移到健康的可用区域。
|
||||
因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率 `--node-eviction-rate` 进行驱逐操作。
|
||||
在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，节点控制器将假设控制面节点的连接出了某些问题，
|
||||
它将停止所有驱逐动作直到一些连接恢复。
|
||||
|
||||
<!--
|
||||
Starting in Kubernetes 1.6, the NodeController is also responsible for evicting
|
||||
@@ -376,8 +401,10 @@ NodeController is responsible for adding taints corresponding to node problems l
|
||||
node unreachable or not ready. See [this documentation](/docs/concepts/configuration/taint-and-toleration/)
|
||||
for details about `NoExecute` taints and the alpha feature.
|
||||
-->
|
||||
从 Kubernetes 1.6 开始，NodeController 还负责驱逐运行在拥有 `NoExecute` 污点的节点上的 pods，如果这些 pods 没有容忍这些污点。此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据节点故障（例如节点不可访问或没有 ready）添加污点。请查看[这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` 污点和这个 alpha 特性。
|
||||
|
||||
从 Kubernetes 1.6 开始，NodeController 还负责驱逐运行在拥有 `NoExecute` 污点的节点上的 Pods，如果这些 Pods 没有容忍这些污点。
|
||||
此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据节点故障（例如节点不可访问或没有就绪）为其添加污点。
|
||||
请查看[这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解 `NoExecute` 污点
|
||||
和这个 alpha 特性。
|
||||
|
||||
<!--
|
||||
Starting in version 1.8, the node controller can be made responsible for creating taints that represent
|
||||
@@ -387,71 +414,72 @@ Node conditions. This is an alpha feature of version 1.8.
|
||||
|
||||
<!--
|
||||
### Self-Registration of Nodes
|
||||
|
||||
When the kubelet flag `-register-node` is true (the default), the kubelet will attempt to
|
||||
register itself with the API server. This is the preferred pattern, used by most distros.
|
||||
-->
|
||||
### 节点自注册
|
||||
|
||||
<!--
|
||||
When the kubelet flag `--register-node` is true (the default), the kubelet will attempt to
|
||||
register itself with the API server. This is the preferred pattern, used by most distros.
|
||||
-->
|
||||
当 kubelet 标志 `--register-node` 为 true （默认）时，它会尝试向 API 服务注册自己。这是首选模式，被绝大多数发行版选用。
|
||||
当 kubelet 标志 `--register-node` 为 true （默认）时，它会尝试向 API 服务注册自己。
|
||||
这是首选模式，被绝大多数发行版选用。
|
||||
|
||||
<!--
|
||||
For self-registration, the kubelet is started with the following options:
|
||||
-->
|
||||
对于自注册模式，kubelet 使用下列参数启动：
|
||||
对于自注册模式，kubelet 使用下列参数启动：
|
||||
|
||||
<!--
|
||||
- `--kubeconfig` - Path to credentials to authenticate itself to the apiserver.
|
||||
- `--cloud-provider` - How to talk to a cloud provider to read metadata about itself.
|
||||
- `--register-node` - Automatically register with the API server.
|
||||
- `--register-with-taints` - Register the node with the given list of taints (comma separated `<key>=<value>:<effect>`). No-op if `register-node` is false.
|
||||
- `--node-ip` - IP address of the node.
|
||||
- `--node-labels` - Labels to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) in 1.13+).
|
||||
- `--node-status-update-frequency` - Specifies how often kubelet posts node status to master.
|
||||
- `-kubeconfig` - Path to credentials to authenticate itself to the apiserver.
|
||||
- `-cloud-provider` - How to talk to a cloud provider to read metadata about itself.
|
||||
- `-register-node` - Automatically register with the API server.
|
||||
- `-register-with-taints` - Register the node with the given list of taints (comma separated `<key>=<value>:<effect>`). No-op if `register-node` is false.
|
||||
- `-node-ip` - IP address of the node.
|
||||
- `-node-labels` - Labels to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) in 1.13+).
|
||||
- `-node-status-update-frequency` - Specifies how often kubelet posts node status to master.
|
||||
-->
|
||||
- `--kubeconfig` - 用于向 apiserver 验证自己的凭据路径。
|
||||
- `--kubeconfig` - 用于向 apiserver 表明身份的凭据路径。
|
||||
- `--cloud-provider` - 如何从云服务商读取关于自己的元数据。
|
||||
- `--register-node` - 自动向 API 服务注册。
|
||||
- `--register-with-taints` - 使用 taints 列表（逗号分隔的 `<key>=<value>:<effect>`）注册节点。当 `register-node` 为 false 时无效。
|
||||
- `--register-with-taints` - 使用污点列表（逗号分隔的 `<key>=<value>:<effect>`）注册节点。当 `register-node` 为 false 时无效。
|
||||
- `--node-ip` - 节点 IP 地址。
|
||||
- `--node-labels` - 在集群中注册节点时要添加的标签（请参阅 [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 在 1.13+ 中实施的标签限制）。
|
||||
- `--node-status-update-frequency` - 指定 kubelet 向 master 发送状态的频率。
|
||||
- `--node-labels` - 在集群中注册节点时要添加的标签（请参阅
|
||||
[NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 在 1.13+ 中实施的标签限制）。
|
||||
- `--node-status-update-frequency` - 指定 kubelet 向控制面组件发送状态的频率。
|
||||
|
||||
<!--
|
||||
When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
|
||||
kubelets are only authorized to create/modify their own Node resource.
|
||||
-->
|
||||
启用[节点授权模式](/docs/reference/access-authn-authz/node/) 和 [NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时，仅授权小组件创建或修改其自己的节点资源。
|
||||
启用[节点授权模式](/docs/reference/access-authn-authz/node/) 和
|
||||
[NodeRestriction 准入插件](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时，
|
||||
仅授权 kubelet 创建或修改其自己的节点资源。
|
||||
|
||||
<!--
|
||||
#### Manual Node Administration
|
||||
A cluster administrator can create and modify node objects.
|
||||
-->
|
||||
#### 手动节点管理
|
||||
|
||||
<!--
|
||||
A cluster administrator can create and modify node objects.
|
||||
-->
|
||||
集群管理员可以创建及修改节点对象。
|
||||
|
||||
<!--
|
||||
If the administrator wishes to create node objects manually, set the kubelet flag
|
||||
`--register-node=false`.
|
||||
If the administrator wishes to create node objects manually, set the kubelet flag `-register-node=false`.
|
||||
-->
|
||||
如果管理员希望手动创建节点对象，请设置 kubelet 标记 `--register-node=false`。
|
||||
如果管理员希望手动创建节点对象，请设置 kubelet 标志 `--register-node=false`。
|
||||
|
||||
<!--
|
||||
The administrator can modify node resources (regardless of the setting of `--register-node`).
|
||||
The administrator can modify node resources (regardless of the setting of `-register-node`).
|
||||
Modifications include setting labels on the node and marking it unschedulable.
|
||||
-->
|
||||
管理员可以修改节点资源（忽略 `--register-node` 设置）。修改包括在节点上设置 labels 及标记它为不可调度。
|
||||
管理员可以修改节点资源（忽略 `--register-node` 设置）。修改包括在节点上设置标签及
|
||||
标记它为不可调度。
|
||||
|
||||
<!--
|
||||
Labels on nodes can be used in conjunction with node selectors on pods to control scheduling,
|
||||
e.g. to constrain a pod to only be eligible to run on a subset of the nodes.
|
||||
-->
|
||||
节点上的 labels 可以和 pods 的节点 selectors 一起使用来控制调度，例如限制一个 pod 只能在一个符合要求的节点子集上运行。
|
||||
节点上的标签可以和 Pods 的节点选择算符一起使用来控制调度，例如限制某 pod 只能在符合要求的节点子集上运行。
|
||||
|
||||
<!--
|
||||
Marking a node as unschedulable prevents new pods from being scheduled to that
|
||||
@@ -459,47 +487,55 @@ node, but does not affect any existing pods on the node. This is useful as a
|
||||
preparatory step before a node reboot, etc. For example, to mark a node
|
||||
unschedulable, run this command:
|
||||
-->
|
||||
标记一个节点为不可调度的将防止新建 pods 调度到那个节点之上，但不会影响任何已经在它之上的 pods。这是重启节点等操作之前的一个有用的准备步骤。例如，标记一个节点为不可调度的，执行以下命令：
|
||||
|
||||
如果标记节点为不可调度的（unschedulable），将阻止新 Pods 调度到该节点之上，但不会影响任何已经在其上的 Pods。
|
||||
这是重启节点等操作之前的一个有用的准备步骤。例如，要标记一个节点为不可调度的，执行以下命令：
|
||||
|
||||
```shell
|
||||
kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
{{< note >}}
|
||||
Pods created by a DaemonSet controller bypass the Kubernetes scheduler
|
||||
and do not respect the unschedulable attribute on a node. This assumes that daemons belong on
|
||||
the machine even if it is being drained of applications while it prepares for a reboot
|
||||
{{< /note >}}
|
||||
-->
|
||||
请注意，被 daemonSet 控制器创建的 pods 将忽略 Kubernetes 调度器，且不会遵照节点上不可调度的属性。这个假设基于守护程序属于节点机器，即使在准备重启而隔离应用的时候。
|
||||
|
||||
{{< note >}}
|
||||
请注意，被 DaemonSet 控制器创建的 Pods 将忽略 Kubernetes 调度器，且不会遵照节点上不可调度的属性。
|
||||
这个假设基于守护程序属于节点机器，即使在准备重启而隔离应用的时候。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Node capacity
|
||||
-->
|
||||
### 节点容量
|
||||
|
||||
<!--
|
||||
The capacity of the node (number of cpus and amount of memory) is part of the node object.
|
||||
Normally, nodes register themselves and report their capacity when creating the node object. If
|
||||
you are doing [manual node administration](#manual-node-administration), then you need to set node
|
||||
capacity when adding a node.
|
||||
-->
|
||||
节点的容量（cpu 数量和内存容量）是节点对象的一部分。通常情况下，在创建节点对象时，它们会注册自己并报告自己的容量。如果你正在执行[手动节点管理](#manual-node-administration)，那么你需要在添加节点时手动设置节点容量。
|
||||
### 节点容量
|
||||
|
||||
节点的容量（cpu 数量和内存容量）是节点对象的一部分。
|
||||
通常情况下，在创建节点对象时，它们会注册自己并报告自己的容量。
|
||||
如果你正在执行[手动节点管理](#manual-node-administration)，那么你需要在添加节点时手动设置节点容量。
|
||||
|
||||
<!--
|
||||
The Kubernetes scheduler ensures that there are enough resources for all the pods on a node. It
|
||||
checks that the sum of the requests of containers on the node is no greater than the node capacity. It
|
||||
includes all containers started by the kubelet, but not containers started directly by the [container runtime](/docs/concepts/overview/components/#node-components) nor any process running outside of the containers.
|
||||
-->
|
||||
Kubernetes 调度器保证一个节点上有足够的资源供其上的所有 pods 使用。它会检查节点上所有容器要求的总和不会超过节点的容量。这包括由 kubelet 启动的所有容器，但不包括由 [container runtime](/docs/concepts/overview/components/#node-components) 直接启动的容器，也不包括在容器外部运行的任何进程。
|
||||
Kubernetes 调度器保证一个节点上有足够的资源供其上的所有 Pods 使用。
|
||||
它会检查节点上所有容器的请求的总和不会超过节点的容量。
|
||||
这包括由 kubelet 启动的所有容器，但不包括由[容器运行时](/docs/concepts/overview/components/#node-components)
|
||||
直接启动的容器，也不包括在容器外部运行的任何进程。
|
||||
|
||||
<!--
|
||||
If you want to explicitly reserve resources for non-Pod processes, follow this tutorial to
|
||||
[reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
|
||||
-->
|
||||
如果要为非 Pod 进程显式保留资源。请按照本教程[为系统守护程序保留资源](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。
|
||||
如果要为非 Pod 进程显式保留资源。请参考[为系统守护程序保留资源](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)教程。
|
||||
|
||||
<!--
|
||||
## Node topology
|
||||
@@ -513,20 +549,20 @@ If you have enabled the `TopologyManager`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then
|
||||
the kubelet can use topology hints when making resource assignment decisions.
|
||||
-->
|
||||
如果启用了 `TopologyManager` [功能开关](/docs/reference/command-line-tools-reference/feature-gates/)，则 kubelet 可以在做出资源分配决策时使用拓扑提示。
|
||||
如果启用了 `TopologyManager` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)，
|
||||
则 kubelet 可以在做出资源分配决策时使用拓扑提示。
|
||||
|
||||
<!--
|
||||
## API Object
|
||||
-->
|
||||
## API 对象
|
||||
|
||||
<!--
|
||||
Node is a top-level resource in the Kubernetes REST API. More details about the
|
||||
API object can be found at:
|
||||
[Node API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
-->
|
||||
节点是 Kubernetes REST API 的顶级资源。更多关于 API 对象的细节可以在这里找到：[节点 API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。
|
||||
## API 对象
|
||||
|
||||
节点是 Kubernetes REST API 的顶级资源。
|
||||
更多关于 API 对象的细节可以在这里找到：[节点 API 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
@@ -534,6 +570,6 @@ API object can be found at:
|
||||
* Read about [node components](https://kubernetes.io/docs/concepts/overview/components/#node-components)
|
||||
* Read about node-level topology: [Control Topology Management Policies on a node](/docs/tasks/administer-cluster/topology-manager/)
|
||||
-->
|
||||
* 了解有关[节点组件](https://kubernetes.io/docs/concepts/overview/components/#node-components)的信息。
|
||||
* 了解有关[节点组件](/docs/concepts/overview/components/#node-components)的信息。
|
||||
* 阅读有关节点级拓扑的信息：[控制节点上的拓扑管理策略](/docs/tasks/administer-cluster/topology-manager/)。
|
||||
|
||||
|
||||
@@ -94,7 +94,7 @@ Add-ons 扩展了 Kubernetes 的功能。
|
||||
|
||||
## 基础设施
|
||||
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes 运行虚拟机的 add-ons。通常运行在裸机群集上。
|
||||
* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) 是可以让 Kubernetes 运行虚拟机的 add-ons。通常运行在裸机集群上。
|
||||
|
||||
<!--
|
||||
## Legacy Add-ons
|
||||
|
||||
@@ -27,7 +27,7 @@ Before choosing a guide, here are some considerations:
|
||||
|
||||
## 规划集群
|
||||
|
||||
查阅 [安装](/docs/setup/) 中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。
|
||||
查阅[安装](/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。
|
||||
|
||||
在选择一个指南前，有一些因素需要考虑：
|
||||
|
||||
@@ -46,12 +46,12 @@ Before choosing a guide, here are some considerations:
|
||||
|
||||
- 你是打算在你的电脑上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。
|
||||
- **如果你正在设计一个高可用集群**，请了解[在多个 zones 中配置集群](/docs/concepts/cluster-administration/federation/)。
|
||||
- 您正在使用 类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的**被托管的Kubernetes集群**, 还是**管理您自己的集群**?
|
||||
- 你的集群是在**本地**还是 **云（IaaS）** 上？ Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。
|
||||
- 您正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的 **被托管的Kubernetes集群**, 还是 **管理您自己的集群**？
|
||||
- 你的集群是在 **本地** 还是 **云（IaaS）** 上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。
|
||||
- **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/docs/concepts/cluster-administration/networking/)最适合。
|
||||
- 你的 Kubernetes 在 **裸金属硬件** 还是 **虚拟机（VMs）** 上运行？
|
||||
- 你**只想运行一个集群**，还是打算**活动开发 Kubernetes 项目代码**？如果是后者，请选择一个活动开发的发行版。某些发行版只提供二进制发布版，但提供更多的选择。
|
||||
- 让你自己熟悉运行一个集群所需的[组件](/docs/admin/cluster-components) 。
|
||||
- 你 **只想运行一个集群**，还是打算 **活动开发 Kubernetes 项目代码**？如果是后者，请选择一个活动开发的发行版。某些发行版只提供二进制发布版，但提供更多的选择。
|
||||
- 让你自己熟悉运行一个集群所需的[组件](/docs/admin/cluster-components)。
|
||||
|
||||
<!--
|
||||
Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
|
||||
@@ -73,9 +73,9 @@ Note: Not all distros are actively maintained. Choose distros which have been te
|
||||
|
||||
* [管理集群](/docs/concepts/cluster-administration/cluster-management/)叙述了和集群生命周期相关的几个主题：创建一个新集群、升级集群的 master 和 worker 节点、执行节点维护（例如内核升级）以及升级活动集群的 Kubernetes API 版本。
|
||||
|
||||
* 学习如何 [管理节点](/docs/concepts/nodes/node/).
|
||||
* 学习如何[管理节点](/docs/concepts/nodes/node/)。
|
||||
|
||||
* 学习如何设定和管理集群共享的 [资源配额](/docs/concepts/policy/resource-quotas/) 。
|
||||
* 学习如何设定和管理集群共享的[资源配额](/docs/concepts/policy/resource-quotas/) 。
|
||||
|
||||
<!--
|
||||
## Securing a cluster
|
||||
@@ -101,7 +101,7 @@ Note: Not all distros are actively maintained. Choose distros which have been te
|
||||
|
||||
* [Certificates](/docs/concepts/cluster-administration/certificates/) 描述了使用不同的工具链生成证书的步骤。
|
||||
|
||||
* [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
|
||||
* [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
|
||||
|
||||
* [控制到 Kubernetes API 的访问](/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。
|
||||
|
||||
|
||||
@@ -186,7 +186,7 @@ that do not run in a container. For example:
|
||||
* The kubelet and container runtime, for example Docker, do not run in containers.
|
||||
-->
|
||||
* 在容器中运行的 kube-scheduler 和 kube-proxy。
|
||||
* 不在容器中运行的 kubelet 和容器运行时（例如 Docker。
|
||||
* 不在容器中运行的 kubelet 和容器运行时（例如 Docker）。
|
||||
|
||||
<!--
|
||||
On machines with systemd, the kubelet and container runtime write to journald. If
|
||||
|
||||
@@ -631,7 +631,7 @@ Let's say you were running version 1.7.9 of nginx:
|
||||
假设您正运行的是 1.7.9 版本的 nginx：
|
||||
|
||||
```shell
|
||||
kubectl run my-nginx --image=nginx:1.7.9 --replicas=3
|
||||
kubectl create deployment my-nginx --image=nginx:1.7.9
|
||||
```
|
||||
```shell
|
||||
deployment.apps/my-nginx created
|
||||
|
||||
@@ -6,7 +6,7 @@ weight: 20
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< glossary_definition term_id="configmap" prepend="ConfigMap 是" length="all" >}}
|
||||
{{< glossary_definition term_id="configmap" length="all" >}}
|
||||
|
||||
{{< caution >}}
|
||||
<!--
|
||||
@@ -84,10 +84,10 @@ format.
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
Name: game-demo
|
||||
name: game-demo
|
||||
data:
|
||||
# 类属性键；每一个键都映射到一个简单的值
|
||||
player_initial_lives: 3
|
||||
player_initial_lives: "3"
|
||||
ui_properties_file_name: "user-interface.properties"
|
||||
#
|
||||
# 类文件键
|
||||
|
||||
@@ -1,972 +0,0 @@
|
||||
---
|
||||
title: 为容器管理计算资源
|
||||
content_type: concept
|
||||
weight: 20
|
||||
feature:
|
||||
title: 自动装箱
|
||||
description: >
|
||||
根据资源需求和其他约束自动放置容器，同时不会牺牲可用性，将任务关键工作负载和尽力服务工作负载进行混合放置，以提高资源利用率并节省更多资源。
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Managing Compute Resources for Containers
|
||||
content_type: concept
|
||||
weight: 20
|
||||
feature:
|
||||
title: Automatic binpacking
|
||||
description: >
|
||||
Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources.
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
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)。
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- 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.
|
||||
|
||||
If you're using Kubernetes v1.14 or newer, you can specify _huge page_ resources.
|
||||
Huge pages are a Linux-specific feature where the node kernel allocates blocks of memory
|
||||
that are much larger than the default page size.
|
||||
|
||||
For example, on a system where the default page size is 4KiB, you could specify a limit,
|
||||
`hugepages-2Mi: 80Mi`. If the container tries allocating over 40 2MiB huge pages (a
|
||||
total of 80 MiB), that allocation fails.
|
||||
|
||||
{{< note >}}
|
||||
You cannot overcommit `hugepages-*` resources.
|
||||
This is different from the `memory` and `cpu` resources.
|
||||
{{< /note >}}
|
||||
|
||||
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 的单位是核心数，内存的单位是字节。
|
||||
|
||||
如果您使用的是 Kubernetes v1.14 或更高版本，则可以指定巨页资源。巨页是 Linux 特有的功能，节点内核在其中分配的内存块比默认页大小大得多。
|
||||
|
||||
例如，在默认页面大小为 4KiB 的系统上，您可以指定一个限制，`hugepages-2Mi: 80Mi`。如果容器尝试分配 40 个 2MiB 大页面（总共 80 MiB ），则分配失败。
|
||||
|
||||
{{< note >}}
|
||||
您不能过量使用`hugepages- *`资源。
|
||||
这与`memory`和`cpu`资源不同。
|
||||
{{< /note >}}
|
||||
|
||||
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 和 容器的资源请求和限制
|
||||
|
||||
Pod 中的每个容器都可以指定以下的一个或者多个值：
|
||||
|
||||
- `spec.containers[].resources.limits.cpu`
|
||||
- `spec.containers[].resources.limits.memory`
|
||||
- `spec.containers[].resources.requests.cpu`
|
||||
- `spec.containers[].resources.requests.memory`
|
||||
|
||||
尽管只能在个别容器上指定请求和限制，但是我们可以方便地计算出 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* 为单位。
|
||||
|
||||
Kubernetes 中的一个 cpu 等于：
|
||||
|
||||
- 1 AWS vCPU
|
||||
- 1 GCP Core
|
||||
- 1 Azure vCore
|
||||
- 1 *Hyperthread* 在带有超线程的裸机 Intel 处理器上
|
||||
|
||||
允许浮点数请求。具有 `spec.containers[].resources.requests.cpu` 为 0.5 的容器保证了一半 CPU 要求 1 CPU的一半。表达式 `0.1` 等价于表达式 `100m`，可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。具有小数点（如 `0.1`）的请求由 API 转换为`100m`，精度不超过 `1m`。因此，可能会优先选择 `100m` 的形式。
|
||||
|
||||
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。例如，以下代表大致相同的值：
|
||||
|
||||
```shell
|
||||
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 的内存。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: frontend
|
||||
spec:
|
||||
containers:
|
||||
- name: db
|
||||
image: mysql
|
||||
env:
|
||||
- name: MYSQL_ROOT_PASSWORD
|
||||
value: "password"
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
cpu: "250m"
|
||||
limits:
|
||||
memory: "128Mi"
|
||||
cpu: "500m"
|
||||
- name: wp
|
||||
image: wordpress
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
cpu: "250m"
|
||||
limits:
|
||||
memory: "128Mi"
|
||||
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 时：
|
||||
|
||||
<!--
|
||||
- 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` 先被转换为可能是小数的 core 值，再乘以 1024，这个数字和 2 的较大者用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。
|
||||
|
||||
- `spec.containers[].resources.limits.cpu` 先被转换为 millicore 值，再乘以 100，结果就是每 100ms 内 container 可以使用的 CPU 总时间。在此时间间隔（100ms）内，一个 container 使用的 CPU 时间不会超过它被分配的时间。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.
|
||||
{{</ note >}}
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
默认的配额（quota）周期为 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) 部分。
|
||||
|
||||
<!--
|
||||
## Monitoring compute resource usage
|
||||
|
||||
The resource usage of a Pod is reported as part of the Pod status.
|
||||
|
||||
If optional [tools for monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
are available in your cluster, then Pod resource usage can be retrieved either
|
||||
from the [Metrics API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)
|
||||
directly or from your monitoring tools.
|
||||
-->
|
||||
|
||||
## 监控计算资源使用
|
||||
|
||||
Pod 的资源使用情况被报告为 Pod 状态的一部分。
|
||||
|
||||
如果为集群配置了可选 [监控工具](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，则可以直接从
|
||||
[指标 API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) 或者监控工具检索 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
|
||||
|
||||
如果调度器找不到任何该 Pod 可以匹配的节点，则该 Pod 将保持不可调度状态，直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时，会产生一个事件，如下所示：
|
||||
|
||||
```shell
|
||||
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-node-pool-4lw4
|
||||
```
|
||||
```
|
||||
Name: e2e-test-node-pool-4lw4
|
||||
[ ... lines removed for clarity ...]
|
||||
Capacity:
|
||||
cpu: 2
|
||||
memory: 7679792Ki
|
||||
pods: 110
|
||||
Allocatable:
|
||||
cpu: 1800m
|
||||
memory: 7474992Ki
|
||||
pods: 110
|
||||
[ ... lines removed for clarity ...]
|
||||
Non-terminated Pods: (5 in total)
|
||||
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
|
||||
--------- ---- ------------ ---------- --------------- -------------
|
||||
kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%)
|
||||
kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%)
|
||||
kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%)
|
||||
kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%)
|
||||
kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%)
|
||||
Allocated resources:
|
||||
(Total limits may be over 100 percent, i.e., overcommitted.)
|
||||
CPU Requests CPU Limits Memory Requests Memory Limits
|
||||
------------ ---------- --------------- -------------
|
||||
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)。
|
||||
|
||||
可以将 [资源配额](/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
|
||||
kubectl describe pod simmemleak-hra99
|
||||
```
|
||||
```
|
||||
Name: simmemleak-hra99
|
||||
Namespace: default
|
||||
Image(s): saadali/simmemleak
|
||||
Node: kubernetes-node-tf0f/10.240.216.66
|
||||
Labels: name=simmemleak
|
||||
Status: Running
|
||||
Reason:
|
||||
Message:
|
||||
IP: 10.244.2.75
|
||||
Replication Controllers: simmemleak (1/1 replicas created)
|
||||
Containers:
|
||||
simmemleak:
|
||||
Image: saadali/simmemleak
|
||||
Limits:
|
||||
cpu: 100m
|
||||
memory: 50Mi
|
||||
State: Running
|
||||
Started: Tue, 07 Jul 2015 12:54:41 -0700
|
||||
Last Termination State: Terminated
|
||||
Exit Code: 1
|
||||
Started: Fri, 07 Jul 2015 12:54:30 -0700
|
||||
Finished: Fri, 07 Jul 2015 12:54:33 -0700
|
||||
Ready: False
|
||||
Restart Count: 5
|
||||
Conditions:
|
||||
Type Status
|
||||
Ready False
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Reason Message
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d
|
||||
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
|
||||
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。
|
||||
|
||||
<!--
|
||||
## Local ephemeral storage
|
||||
{{< feature-state state="beta" >}}
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
{{< note >}}
|
||||
If an optional runtime partition is used, root partition will not hold any image layer or writable layers.
|
||||
{{< /note >}}
|
||||
-->
|
||||
|
||||
## 本地临时存储
|
||||
|
||||
Kubernetes版本1.8引入了新资源_ephemeral-storage_，用于管理本地临时存储。
|
||||
在每个Kubernetes节点中，kubelet的根目录（默认为 /var/lib/kubelet）和日志目录（ /var/log ）存储在节点的根分区上。
|
||||
Pods还通过emptyDir卷，容器日志，镜像层和容器可写层共享和使用此分区。
|
||||
|
||||
该分区是“临时”分区，应用程序无法从该分区获得任何性能SLA（例如磁盘IOPS）。 本地临时存储管理仅适用于根分区。 图像层和可写层的可选分区超出范围。
|
||||
|
||||
{{< note >}}
|
||||
如果使用可选的运行时分区，则根分区将不保存任何镜像层或可写层。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Requests and limits setting for local ephemeral storage
|
||||
Each Container of a Pod can specify one or more of the following:
|
||||
-->
|
||||
|
||||
### 本地临时存储的请求和限制设置
|
||||
Pod 的每个容器可以指定以下一项或多项：
|
||||
|
||||
* `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/example.com~1foo", "value": "5"}]' \
|
||||
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
|
||||
```
|
||||
|
||||
<!--
|
||||
### 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
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: my-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: my-container
|
||||
image: myimage
|
||||
resources:
|
||||
requests:
|
||||
cpu: 2
|
||||
example.com/foo: 1
|
||||
limits:
|
||||
example.com/foo: 1
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!--
|
||||
* 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)
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,22 +1,12 @@
|
||||
---
|
||||
reviewers:
|
||||
- bsalamat
|
||||
- k82cn
|
||||
- ahg-g
|
||||
title: 扩展资源的资源箱打包
|
||||
title: 扩展资源的资源装箱
|
||||
content_type: concept
|
||||
weight: 10
|
||||
weight: 50
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- bsalamat
|
||||
- k82cn
|
||||
- ahg-g
|
||||
title: Resource Bin Packing for Extended Resources
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
weight: 50
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
@@ -26,46 +16,48 @@ weight: 10
|
||||
<!--
|
||||
The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs.
|
||||
-->
|
||||
可以将 kube-scheduler 配置为使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数启用资源箱打包以及扩展资源。
|
||||
|
||||
使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数，可以将 kube-scheduler
|
||||
配置为支持包含扩展资源在内的资源装箱操作。
|
||||
优先级函数可用于根据自定义需求微调 kube-scheduler 。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
|
||||
-->
|
||||
## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱
|
||||
|
||||
<!--
|
||||
Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
|
||||
consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource.
|
||||
-->
|
||||
在 Kubernetes 1.15 之前，Kube-scheduler 用于允许根据主要资源，如 CPU 和内存对容量之比的请求对节点进行评分。
|
||||
Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每个资源的权重，以便根据容量之比的请求为节点评分。
|
||||
这允许用户通过使用适当的参数来打包扩展资源，从而提高了大型集群中稀缺资源的利用率。
|
||||
`RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为 `requestedToCapacityRatioArguments` 的配置选项进行控制。
|
||||
这个论证由两个参数 `shape` 和 `resources` 组成。
|
||||
Shape 允许用户根据 `utilization` 和 `score` 值将功能调整为要求最少或要求最高的功能。
|
||||
资源由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。
|
||||
|
||||
## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱
|
||||
|
||||
在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）的请求数量和可用容量
|
||||
之比率对节点评分。
|
||||
Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每类资源的权重，
|
||||
以便根据请求数量与可用容量之比率为节点评分。
|
||||
这就使得用户可以通过使用适当的参数来对扩展资源执行装箱操作，从而提高了大型集群中稀缺资源的利用率。
|
||||
`RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为
|
||||
`requestedToCapacityRatioArguments` 的配置选项进行控制。
|
||||
该标志由两个参数 `shape` 和 `resources` 组成。
|
||||
shape 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求（least requested）或
|
||||
最多请求（most requested）计算。
|
||||
resources 由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源，`weight` 指定每种资源的权重。
|
||||
|
||||
<!--
|
||||
Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
|
||||
-->
|
||||
以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为扩展资源 `intel.com/foo` 和 `intel.com/bar` 的装箱行为
|
||||
|
||||
以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为对扩展资源
|
||||
`intel.com/foo` 和 `intel.com/bar` 的装箱行为
|
||||
|
||||
```json
|
||||
{
|
||||
"kind" : "Policy",
|
||||
"apiVersion" : "v1",
|
||||
|
||||
...
|
||||
|
||||
"priorities" : [
|
||||
|
||||
...
|
||||
|
||||
{
|
||||
"name": "RequestedToCapacityRatioPriority",
|
||||
"weight": 2,
|
||||
@@ -89,16 +81,17 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`
|
||||
<!--
|
||||
**This feature is disabled by default**
|
||||
-->
|
||||
**默认情况下禁用此功能**
|
||||
|
||||
**默认情况下此功能处于被禁用状态**
|
||||
|
||||
<!--
|
||||
### Tuning RequestedToCapacityRatioResourceAllocation Priority Function
|
||||
-->
|
||||
### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数
|
||||
|
||||
<!--
|
||||
`shape` is used to specify the behavior of the `RequestedToCapacityRatioPriority` function.
|
||||
-->
|
||||
|
||||
### 调整 RequestedToCapacityRatioResourceAllocation 优先级函数
|
||||
|
||||
`shape` 用于指定 `RequestedToCapacityRatioPriority` 函数的行为。
|
||||
|
||||
```yaml
|
||||
@@ -109,8 +102,9 @@ Below is an example configuration that sets `requestedToCapacityRatioArguments`
|
||||
<!--
|
||||
The above arguments give the node a score of 0 if utilization is 0% and 10 for utilization 100%, thus enabling bin packing behavior. To enable least requested the score value must be reversed as follows.
|
||||
-->
|
||||
上面的参数在利用率为 0% 时给节点评分为0，在利用率为 100% 时给节点评分为10，因此启用了装箱行为。
|
||||
要启用最少请求，必须按如下方式反转得分值。
|
||||
|
||||
上面的参数在 utilization 为 0% 时给节点评分为 0，在 utilization 为 100% 时给节点评分为 10，
|
||||
因此启用了装箱行为。要启用最少请求（least requested）模式，必须按如下方式反转得分值。
|
||||
|
||||
```yaml
|
||||
{"utilization": 0, "score": 100},
|
||||
@@ -124,9 +118,9 @@ The above arguments give the node a score of 0 if utilization is 0% and 10 for u
|
||||
|
||||
``` yaml
|
||||
"resources": [
|
||||
{"name": "CPU", "weight": 1},
|
||||
{"name": "Memory", "weight": 1}
|
||||
]
|
||||
{"name": "CPU", "weight": 1},
|
||||
{"name": "Memory", "weight": 1}
|
||||
]
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -136,66 +130,65 @@ It can be used to add extended resources as follows:
|
||||
|
||||
```yaml
|
||||
"resources": [
|
||||
{"name": "intel.com/foo", "weight": 5},
|
||||
{"name": "CPU", "weight": 3},
|
||||
{"name": "Memory", "weight": 1}
|
||||
]
|
||||
{"name": "intel.com/foo", "weight": 5},
|
||||
{"name": "CPU", "weight": 3},
|
||||
{"name": "Memory", "weight": 1}
|
||||
]
|
||||
```
|
||||
|
||||
<!--
|
||||
The weight parameter is optional and is set to 1 if not specified. Also, the weight cannot be set to a negative value.
|
||||
-->
|
||||
weight 参数是可选的，如果未指定，则设置为1。
|
||||
同样， weight 不能设置为负值。
|
||||
weight 参数是可选的，如果未指定，则设置为 1。
|
||||
同时，weight 不能设置为负值。
|
||||
|
||||
<!--
|
||||
### How the RequestedToCapacityRatioResourceAllocation Priority Function Scores Nodes
|
||||
-->
|
||||
### RequestedToCapacityRatioResourceAllocation 优先级函数如何对节点评分
|
||||
|
||||
<!--
|
||||
This section is intended for those who want to understand the internal details
|
||||
of this feature.
|
||||
Below is an example of how the node score is calculated for a given set of values.
|
||||
-->
|
||||
本部分适用于希望了解此功能的内部细节的人员。
|
||||
以下是如何针对给定的一组值计算节点得分的示例。
|
||||
|
||||
### RequestedToCapacityRatioResourceAllocation 优先级函数如何对节点评分
|
||||
|
||||
本节适用于希望了解此功能的内部细节的人员。
|
||||
以下是如何针对给定的一组值来计算节点得分的示例。
|
||||
|
||||
```
|
||||
Requested Resources
|
||||
请求的资源
|
||||
|
||||
intel.com/foo : 2
|
||||
intel.com/foo: 2
|
||||
Memory: 256MB
|
||||
CPU: 2
|
||||
|
||||
Resource Weights
|
||||
资源权重
|
||||
|
||||
intel.com/foo : 5
|
||||
intel.com/foo: 5
|
||||
Memory: 1
|
||||
CPU: 3
|
||||
|
||||
FunctionShapePoint {{0, 0}, {100, 10}}
|
||||
|
||||
Node 1 Spec
|
||||
节点 Node 1 配置
|
||||
|
||||
Available:
|
||||
intel.com/foo : 4
|
||||
Memory : 1 GB
|
||||
CPU: 8
|
||||
可用：
|
||||
intel.com/foo : 4
|
||||
Memory : 1 GB
|
||||
CPU: 8
|
||||
|
||||
Used:
|
||||
intel.com/foo: 1
|
||||
Memory: 256MB
|
||||
CPU: 1
|
||||
已用：
|
||||
intel.com/foo: 1
|
||||
Memory: 256MB
|
||||
CPU: 1
|
||||
|
||||
|
||||
Node Score:
|
||||
节点得分：
|
||||
|
||||
intel.com/foo = resourceScoringFunction((2+1),4)
|
||||
= (100 - ((4-3)*100/4)
|
||||
= (100 - 25)
|
||||
= 75
|
||||
= rawScoringFunction(75)
|
||||
= (100 - ((4-3)*100/4)
|
||||
= (100 - 25)
|
||||
= 75
|
||||
= rawScoringFunction(75)
|
||||
= 7
|
||||
|
||||
Memory = resourceScoringFunction((256+256),1024)
|
||||
@@ -214,27 +207,25 @@ NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
|
||||
= 5
|
||||
|
||||
|
||||
Node 2 Spec
|
||||
节点 Node 2 配置
|
||||
|
||||
Available:
|
||||
intel.com/foo: 8
|
||||
Memory: 1GB
|
||||
CPU: 8
|
||||
可用：
|
||||
intel.com/foo: 8
|
||||
Memory: 1GB
|
||||
CPU: 8
|
||||
|
||||
Used:
|
||||
已用：
|
||||
intel.com/foo: 2
|
||||
Memory: 512MB
|
||||
CPU: 6
|
||||
|
||||
intel.com/foo: 2
|
||||
Memory: 512MB
|
||||
CPU: 6
|
||||
|
||||
|
||||
Node Score:
|
||||
节点得分：
|
||||
|
||||
intel.com/foo = resourceScoringFunction((2+2),8)
|
||||
= (100 - ((8-4)*100/8)
|
||||
= (100 - 25)
|
||||
= 50
|
||||
= rawScoringFunction(50)
|
||||
= (100 - ((8-4)*100/8)
|
||||
= (100 - 25)
|
||||
= 50
|
||||
= rawScoringFunction(50)
|
||||
= 5
|
||||
|
||||
Memory = resourceScoringFunction((256+512),1024)
|
||||
@@ -251,8 +242,5 @@ CPU = resourceScoringFunction((2+6),8)
|
||||
|
||||
NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
|
||||
= 7
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -154,9 +154,9 @@ effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod ont
|
||||
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，则 Kubernetes 不会将 pod 分配到该节点。
|
||||
* 如果未被过滤的 taint 中不存在 effect 值为 `NoSchedule` 的 taint，但是存在 effect 值为 `PreferNoSchedule` 的 taint，则 Kubernetes 会 *尝试* 将 pod 分配到该节点。
|
||||
* 如果未被过滤的 taint 中存在一个以上 effect 值为 `NoExecute` 的 taint，则 Kubernetes 不会将 pod 分配到该节点（如果 pod 还未在节点上运行），或者将 pod 从该节点驱逐（如果 pod 已经在节点上运行）。
|
||||
* 如果未被过滤的 taint 中存在至少一个 effect 值为 `NoExecute` 的 taint，则 Kubernetes 不会将 pod 分配到该节点（如果 pod 还未在节点上运行），或者将 pod 从该节点驱逐（如果 pod 已经在节点上运行）。
|
||||
|
||||
<!--
|
||||
For example, imagine you taint a node like this
|
||||
|
||||
@@ -322,7 +322,7 @@ Here are some examples of device plugin implementations:
|
||||
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
|
||||
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
|
||||
* The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
|
||||
* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices
|
||||
* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices
|
||||
-->
|
||||
## 设备插件示例 {#examples}
|
||||
|
||||
@@ -337,7 +337,7 @@ Here are some examples of device plugin implementations:
|
||||
* [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
|
||||
* [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
|
||||
* [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
|
||||
* [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk)
|
||||
* [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin)
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
@@ -21,7 +21,7 @@ card:
|
||||
|
||||
<!--
|
||||
When you deploy Kubernetes, you get a cluster.
|
||||
{{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}}
|
||||
{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}}
|
||||
|
||||
This document outlines the various components you need to have
|
||||
a complete and working Kubernetes cluster.
|
||||
|
||||
@@ -213,6 +213,5 @@ Kubernetes：
|
||||
* Take a look at the [Kubernetes Components](/docs/concepts/overview/components/)
|
||||
* Ready to [Get Started](/docs/setup/)?
|
||||
-->
|
||||
* 查阅 [Kubernetes 组件](/docs/concepts/overview/components/)
|
||||
* 开始 [Kubernetes 入门](/docs/setup/)?
|
||||
|
||||
* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/)
|
||||
* 开始 [Kubernetes 入门](/zh/docs/setup/)?
|
||||
@@ -3,7 +3,7 @@ title: 理解 Kubernetes 对象
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: 概念
|
||||
name: concepts
|
||||
weight: 40
|
||||
---
|
||||
|
||||
|
||||
@@ -77,6 +77,13 @@ for namespaces](/docs/admin/namespaces).
|
||||
-->
|
||||
命名空间的创建和删除已在[命名空间的管理指南文档](/docs/admin/namespaces)中进行了描述。
|
||||
|
||||
<!--
|
||||
Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
|
||||
-->
|
||||
{{< note >}}
|
||||
避免使用前缀 `kube-` 创建命名空间，因为它是为 Kubernetes 系统命名空间保留的。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Viewing namespaces
|
||||
-->
|
||||
|
||||
@@ -150,7 +150,7 @@ The following resource types are supported:
|
||||
In addition to the resources mentioned above, in release 1.10, quota support for
|
||||
[extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added.
|
||||
-->
|
||||
除上述资源外，在 Kubernetes 1.10 版本中，还添加了对[扩展资源](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)的支持。
|
||||
除上述资源外，在 Kubernetes 1.10 版本中，还添加了对[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#扩展资源-extended-resources)的支持。
|
||||
|
||||
<!--
|
||||
As overcommit is not allowed for extended resources, it makes no sense to specify both `requests`
|
||||
@@ -729,7 +729,7 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl run nginx --image=nginx --replicas=2 --namespace=myspace
|
||||
kubectl create deployment nginx --image=nginx --namespace=myspace
|
||||
```
|
||||
|
||||
```shell
|
||||
@@ -820,7 +820,7 @@ plugins:
|
||||
limitedResources:
|
||||
- resource: pods
|
||||
matchScopes:
|
||||
- scopeName: PriorityClass
|
||||
- scopeName: PriorityClass
|
||||
operator: In
|
||||
values: ["cluster-services"]
|
||||
```
|
||||
@@ -839,7 +839,7 @@ plugins:
|
||||
limitedResources:
|
||||
- resource: pods
|
||||
matchScopes:
|
||||
- scopeName: PriorityClass
|
||||
- scopeName: PriorityClass
|
||||
operator: In
|
||||
values: ["cluster-services"]
|
||||
```
|
||||
@@ -888,5 +888,3 @@ See a [detailed example for how to use resource quota](/docs/tasks/administer-cl
|
||||
See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
|
||||
-->
|
||||
查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)了解更多信息。
|
||||
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ title: Services
|
||||
feature:
|
||||
title: 服务发现与负载均衡
|
||||
description: >
|
||||
无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载平衡。
|
||||
无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载均衡。
|
||||
|
||||
content_type: concept
|
||||
weight: 10
|
||||
@@ -328,6 +328,27 @@ Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的
|
||||
|
||||
Endpoint 切片提供了附加的属性和功能，这些属性和功能在 [Endpoint 切片](/docs/concepts/services-networking/endpoint-slices/)中进行了详细描述。
|
||||
|
||||
<!--
|
||||
### Application protocol
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
|
||||
|
||||
The AppProtocol field provides a way to specify an application protocol to be
|
||||
used for each Service port.
|
||||
|
||||
As an alpha feature, this field is not enabled by default. To use this field,
|
||||
enable the `ServiceAppProtocol` [feature
|
||||
gate](/docs/reference/command-line-tools-reference/feature-gates/).
|
||||
-->
|
||||
### 应用程序协议
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
|
||||
|
||||
AppProtocol 字段提供了一种为每个 Service 端口指定应用程序协议的方式。
|
||||
|
||||
作为一个 alpha 特性，该字段默认未启用。要使用该字段，请启用 `ServiceAppProtocol` [特性开关]
|
||||
(/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
|
||||
<!--
|
||||
## Virtual IPs and service proxies
|
||||
|
||||
@@ -868,6 +889,25 @@ to just expose one or more nodes' IPs directly.
|
||||
|
||||
Note that this Service is visible as `<NodeIP>:spec.ports[*].nodePort`
|
||||
and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, <NodeIP> would be filtered NodeIP(s).)
|
||||
|
||||
For example:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: my-service
|
||||
spec:
|
||||
type: NodePort
|
||||
selector:
|
||||
app: MyApp
|
||||
ports:
|
||||
# By default and for convenience, the `targetPort` is set to the same value as the `port` field.
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
# Optional field
|
||||
# By default and for convenience, the Kubernetes control plane will allocate a port from a range (default: 30000-32767)
|
||||
nodePort: 30007
|
||||
```
|
||||
-->
|
||||
|
||||
### NodePort 类型
|
||||
@@ -891,6 +931,25 @@ and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in
|
||||
|
||||
需要注意的是，Service 能够通过 `<NodeIP>:spec.ports[*].nodePort` 和 `spec.clusterIp:spec.ports[*].port` 而对外可见。
|
||||
|
||||
例如：
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: my-service
|
||||
spec:
|
||||
type: NodePort
|
||||
selector:
|
||||
app: MyApp
|
||||
ports:
|
||||
# 默认情况下，为了方便起见，`targetPort` 被设置为与 `port` 字段相同的值。
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
# 可选字段
|
||||
# 默认情况下，为了方便起见，Kubernetes 控制平面会从某个范围内分配一个端口号（默认：30000-32767）
|
||||
nodePort: 30007
|
||||
```
|
||||
|
||||
<!--
|
||||
### Type LoadBalancer {#loadbalancer}
|
||||
|
||||
@@ -1032,6 +1091,16 @@ metadata:
|
||||
[...]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="IBM Cloud" %}}
|
||||
```yaml
|
||||
[...]
|
||||
metadata:
|
||||
name: my-service
|
||||
annotations:
|
||||
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
|
||||
[...]
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="OpenStack" %}}
|
||||
```yaml
|
||||
[...]
|
||||
@@ -1561,7 +1630,7 @@ worth understanding.
|
||||
One of the primary philosophies of Kubernetes is that you should not be
|
||||
exposed to situations that could cause your actions to fail through no fault
|
||||
of your own. For the design of the Service resource, this means not making
|
||||
you choose your own port number for a if that choice might collide with
|
||||
you choose your own port number if that choice might collide with
|
||||
someone else's choice. That is an isolation failure.
|
||||
|
||||
In order to allow you to choose a port number for your Services, we must
|
||||
@@ -1576,7 +1645,7 @@ fail with a message indicating an IP address could not be allocated.
|
||||
|
||||
In the control plane, a background controller is responsible for creating that
|
||||
map (needed to support migrating from older versions of Kubernetes that used
|
||||
in-memory locking). Kubernetes also uses controllers to checking for invalid
|
||||
in-memory locking). Kubernetes also uses controllers to check for invalid
|
||||
assignments (eg due to administrator intervention) and for cleaning up allocated
|
||||
IP addresses that are no longer used by any Services.
|
||||
|
||||
@@ -1585,15 +1654,16 @@ IP addresses that are no longer used by any Services.
|
||||
### 避免冲突
|
||||
|
||||
Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致他们操作失败、但又不是他们的过错的场景。
|
||||
这种场景下，让我们来看一下网络端口 —— 用户不应该必须选择一个端口号，而且该端口还有可能与其他用户的冲突。
|
||||
这就是说，在彼此隔离状态下仍然会出现失败。
|
||||
对于 Service 资源的设计，这意味着如果用户的选择有可能与他人冲突，那就不要让用户自行选择端口号。
|
||||
这是一个隔离性的失败。
|
||||
|
||||
为了使用户能够为他们的 `Service` 选择一个端口号，我们必须确保不能有2个 `Service` 发生冲突。
|
||||
我们可以通过为每个 `Service` 分配它们自己的 IP 地址来实现。
|
||||
为了使用户能够为他们的 Service 选择一个端口号，我们必须确保不能有2个 Service 发生冲突。
|
||||
Kubernetes 通过为每个 Service 分配它们自己的 IP 地址来实现。
|
||||
|
||||
为了保证每个 `Service` 被分配到一个唯一的 IP，需要一个内部的分配器能够原子地更新 etcd 中的一个全局分配映射表，这个更新操作要先于创建每一个 `Service`。
|
||||
为了使 `Service` 能够获取到 IP，这个映射表对象必须在注册中心存在，否则创建 `Service` 将会失败，指示一个 IP 不能被分配。
|
||||
一个后台 Controller 的职责是创建映射表（从 Kubernetes 的旧版本迁移过来，旧版本中是通过在内存中加锁的方式实现），并检查由于管理员干预和清除任意 IP 造成的不合理分配，这些 IP 被分配了但当前没有 `Service` 使用它们。
|
||||
为了保证每个 Service 被分配到一个唯一的 IP，需要一个内部的分配器能够原子地更新 {{< glossary_tooltip term_id="etcd" >}} 中的一个全局分配映射表，这个更新操作要先于创建每一个 Service。
|
||||
为了使 Service 能够获取到 IP，这个映射表对象必须在注册中心存在，否则创建 Service 将会失败，指示一个 IP 不能被分配。
|
||||
|
||||
在控制平面中，一个后台 Controller 的职责是创建映射表（需要支持从使用了内存锁的 Kubernetes 的旧版本迁移过来）。同时 Kubernetes 会通过控制器检查不合理的分配（如管理员干预导致的）以及清理已被分配但不再被任何 Service 使用的 IP 地址。
|
||||
|
||||
<!--
|
||||
### Service IP addresses {#ips-and-vips}
|
||||
|
||||
@@ -176,7 +176,7 @@ can enable this behavior by:
|
||||
is enabled on the API server.
|
||||
-->
|
||||
- 标记一个 `StorageClass` 为 *默认*；
|
||||
- 确保 [`DefaultStorageClass` 准入控制器](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。
|
||||
- 确保 [`DefaultStorageClass` 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。
|
||||
|
||||
<!--
|
||||
An administrator can mark a specific `StorageClass` as default by adding the
|
||||
@@ -211,5 +211,3 @@ Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
|
||||
在[多区域](/docs/setup/multiple-zones)集群中，Pod 可以被分散到多个区域。
|
||||
单区域存储后端应该被供应到 Pod 被调度到的区域。
|
||||
这可以通过设置[卷绑定模式](/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。
|
||||
|
||||
|
||||
|
||||
@@ -63,11 +63,11 @@ StorageClass 对象的命名很重要，用户使用这个命名来请求生成
|
||||
<!--
|
||||
Administrators can specify a default StorageClass just for PVCs that don't
|
||||
request any particular class to bind to: see the
|
||||
[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#class-1)
|
||||
[PersistentVolumeClaim section](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
|
||||
for details.
|
||||
-->
|
||||
管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ：
|
||||
更多详情请参阅 [PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#class-1)。
|
||||
更多详情请参阅 [PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
|
||||
|
||||
```yaml
|
||||
apiVersion: storage.k8s.io/v1
|
||||
|
||||
@@ -135,6 +135,6 @@ The result is a new PVC with the name `clone-of-pvc-1` that has the exact same c
|
||||
Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone.
|
||||
-->
|
||||
|
||||
一旦新的 PVC 可用，被克隆的 PVC 项其他 PVC 一样被使用。可以预期的是，新创建的 PVC 是一个独立的对象。可以独立使用，克隆，快照或删除它，而不需要考虑它的原始数据源 PVC。这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。
|
||||
一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。可以预期的是，新创建的 PVC 是一个独立的对象。可以独立使用，克隆，快照或删除它，而不需要考虑它的原始数据源 PVC。这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。
|
||||
|
||||
|
||||
|
||||
@@ -109,7 +109,7 @@ The following are typical use cases for Deployments:
|
||||
* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore.
|
||||
|
||||
-->
|
||||
* [清理较旧的 ReplicaSets ](#clean-up-policy) ，那些不在需要的。
|
||||
* [清理较旧的 ReplicaSets ](#clean-up-policy) ，那些不再需要的。
|
||||
|
||||
<!--
|
||||
## Creating a Deployment
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Pod 概览
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: 概念
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
|
||||
|
||||
@@ -209,9 +209,11 @@ has signed the CLA.
|
||||
-->
|
||||
如果 PR 拥有来自 Kubernetes 社区的任何人的 `/lgtm` 评论和来自 `sig-docs-maintainers` 组的 `/approve` 评论，只要它没有被 hold 并且作者已签署了 CLA，PR 就会被合并。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The ["Participating"](/docs/contribute/participating/#approvers) section contains more information for reviewers and approvers, including specific responsibilities for approvers. -->
|
||||
The ["Participating"](/docs/contribute/participating/#approvers) section contains more information for reviewers and approvers, including specific responsibilities for approvers.
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
["参与"](/docs/contribute/participating/#approvers)部分包含有关 reviewers 和 approvers 的更多信息，包括 approvers 的具体职责。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -256,10 +256,12 @@ SIG Docs 团队交流采用如下机制：
|
||||
- 参与 [SIG Docs 视频周例会](https://github.com/kubernetes/community/tree/master/sig-docs)，会通过 Slack 频道和邮件列表通知。
|
||||
目前通过 Zoom 进行会议，所以您需要下载 [Zoom 客户端](https://zoom.us/download)，或者通过手机拨入。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
You can also check the SIG Docs weekly meeting on the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles).
|
||||
-->您也可以查看 [Kubernetes 社区会议日历](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)。
|
||||
You can also check the SIG Docs weekly meeting on the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles).
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
您也可以查看 [Kubernetes 社区会议日历](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
@@ -277,13 +279,15 @@ need more background in Git terminology.
|
||||
要改进现有的内容，您可以在创建 _fork_ 之后起草一个 _拉取请求（PR）_ 。这两个术语是 [Github 专用的](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/)。
|
||||
出于本主题的目的，您无需了解有关它们的所有信息，因为您可以通过浏览器做所有的事情。当您继续阅读[贡献者中级指南](/docs/contribute/intermediate/)，您会需要更多 Git 术语的背景知识。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
**Kubernetes code developers**: If you are documenting a new feature for an
|
||||
upcoming Kubernetes release, your process is a bit different. See
|
||||
[Document a feature](/docs/contribute/intermediate/#sig-members-documenting-new-features) for
|
||||
process guidelines and information about deadlines.
|
||||
-->**Kubernetes 代码开发者**：如果您在撰写 Kubernetes 新版本的新功能文档，流程会稍有不同。
|
||||
process guidelines and information about deadlines.
|
||||
-->
|
||||
|
||||
{{< note >}}
|
||||
**Kubernetes 代码开发者**：如果您在撰写 Kubernetes 新版本的新功能文档，流程会稍有不同。
|
||||
关于流程指南和最后期限的信息，请参阅[编写功能文档](/docs/contribute/intermediate/#sig-members-documenting-new-features)。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -13,47 +13,59 @@ menu:
|
||||
title: "文档"
|
||||
weight: 20
|
||||
post: >
|
||||
<p>通过演练，示例和参考文档了解如何使用 Kubernetes。你甚至可以<a href="/editdocs/" data-auto-burger-exclude>帮助贡献文档</a>！</p>
|
||||
overview: >
|
||||
<!-- Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>). -->
|
||||
Kubernetes 是一个开源容器编排引擎，用于容器化应用的自动化部署、扩展和管理。该项目托管在 <a href="https://www.cncf.io/about">CNCF</a>。
|
||||
<!-- cards:
|
||||
- name: concepts
|
||||
title: "Understand the basics"
|
||||
description: "Learn about Kubernetes and its fundamental concepts."
|
||||
button: "Learn Concepts"
|
||||
button_path: "/docs/concepts"
|
||||
- name: tutorials
|
||||
title: "Try Kubernetes"
|
||||
description: "Follow tutorials to learn how to deploy applications in Kubernetes."
|
||||
button: "View Tutorials"
|
||||
button_path: "/docs/tutorials"
|
||||
- name: setup
|
||||
title: "Set up a cluster"
|
||||
description: "Get Kubernetes running based on your resources and needs."
|
||||
button: "Set up Kubernetes"
|
||||
button_path: "/docs/setup"
|
||||
- name: tasks
|
||||
title: "Learn how to use Kubernetes"
|
||||
description: "Look up common tasks and how to perform them using a short sequence of steps."
|
||||
button: "View Tasks"
|
||||
button_path: "/docs/tasks"
|
||||
- name: reference
|
||||
title: Look up reference information
|
||||
description: Browse terminology, command line syntax, API resource types, and setup tool documentation.
|
||||
button: View Reference
|
||||
button_path: /docs/reference
|
||||
- name: contribute
|
||||
title: Contribute to the docs
|
||||
description: Anyone can contribute, whether you’re new to the project or you’ve been around a long time.
|
||||
button: Contribute to the docs
|
||||
button_path: /docs/contribute
|
||||
- name: release-notes
|
||||
title: Release Notes
|
||||
description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes.
|
||||
- name: about
|
||||
title: About the documentation
|
||||
description: This website contains documentation for the current and previous 4 versions of Kubernetes. -->
|
||||
<p>通过概念、教程和参考文档了解如何使用 Kubernetes。你甚至可以<a href="/editdocs/" data-auto-burger-exclude>帮助贡献文档</a>！</p>
|
||||
# description: >
|
||||
# Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation.
|
||||
description: >
|
||||
Kubernetes 是一个开源的容器编排引擎，用来对容器化应用进行自动部署、 扩缩和管理。此开源项目由云原生计算基金会（CNCF）托管。
|
||||
# overview:
|
||||
# Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>).
|
||||
overview:
|
||||
Kubernetes 是一个开源的容器编排引擎，用来对容器化应用进行自动化部署、 扩缩和管理。该项目托管在 <a href="https://www.cncf.io/about">CNCF</a>。
|
||||
# cards:
|
||||
# - name: concepts
|
||||
# title: "Understand the basics"
|
||||
# description: "Learn about Kubernetes and its fundamental concepts."
|
||||
# button: "Learn Concepts"
|
||||
# button_path: "/docs/concepts"
|
||||
# - name: tutorials
|
||||
# title: "Try Kubernetes"
|
||||
# description: "Follow tutorials to learn how to deploy applications in Kubernetes."
|
||||
# button: "View Tutorials"
|
||||
# button_path: "/docs/tutorials"
|
||||
# - name: setup
|
||||
# title: "Set up a cluster"
|
||||
# description: "Get Kubernetes running based on your resources and needs."
|
||||
# button: "Set up Kubernetes"
|
||||
# button_path: "/docs/setup"
|
||||
# - name: tasks
|
||||
# title: "Learn how to use Kubernetes"
|
||||
# description: "Look up common tasks and how to perform them using a short sequence of steps."
|
||||
# button: "View Tasks"
|
||||
# button_path: "/docs/tasks"
|
||||
# - name: training
|
||||
# title: "Training"
|
||||
# description: "Get certified in Kubernetes and make your cloud native projects successful!"
|
||||
# button: "View training"
|
||||
# button_path: "/training"
|
||||
# - name: reference
|
||||
# title: Look up reference information
|
||||
# description: Browse terminology, command line syntax, API resource types, and setup tool documentation.
|
||||
# button: View Reference
|
||||
# button_path: /docs/reference
|
||||
# - name: contribute
|
||||
# title: Contribute to the docs
|
||||
# description: Anyone can contribute, whether you’re new to the project or you’ve been around a long time.
|
||||
# button: Contribute to the docs
|
||||
# button_path: /docs/contribute
|
||||
# - name: release-notes
|
||||
# title: Release Notes
|
||||
# description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes.
|
||||
# button: "Download Kubernetes"
|
||||
# button_path: "/zh/docs/setup/release/notes"
|
||||
# - name: about
|
||||
# title: About the documentation
|
||||
# description: This website contains documentation for the current and previous 4 versions of Kubernetes.
|
||||
cards:
|
||||
- name: concepts
|
||||
title: "了解基本知识"
|
||||
@@ -75,20 +87,27 @@ cards:
|
||||
description: "查看常见任务以及如何使用简单步骤执行它们。"
|
||||
button: "查看任务"
|
||||
button_path: "/zh/docs/tasks"
|
||||
- name: training
|
||||
title: "培训"
|
||||
description: "通过 Kubernetes 认证，助你的云原生项目成功！"
|
||||
button: "查看培训"
|
||||
button_path: "/zh/training"
|
||||
- name: reference
|
||||
title: 参考
|
||||
description: 术语、命令行语法、API 资源类型和设置工具文档。
|
||||
title: 查阅参考信息
|
||||
description: 浏览术语、命令行语法、API 资源类型和安装工具文档。
|
||||
button: 查看参考
|
||||
button_path: /zh/docs/reference
|
||||
- name: contribute
|
||||
title: 为该文档作出贡献
|
||||
title: 为文档作贡献
|
||||
description: 任何人，无论对该项目熟悉与否，都能贡献自己的力量。
|
||||
button: 参与贡献
|
||||
button: 为文档作贡献
|
||||
button_path: /zh/docs/contribute
|
||||
- name: download
|
||||
title: 下载 Kubernetes
|
||||
description: 如果你正在安装或升级 Kubernetes 的话，最好参考最新的发行版说明。
|
||||
- name: release-notes
|
||||
title: 发布说明
|
||||
description: 如果你正在安装或升级 Kubernetes，最好参考最新的发布说明。
|
||||
button: "下载 Kubernetes"
|
||||
button_path: "/zh/docs/setup/release/notes"
|
||||
- name: about
|
||||
title: 关于文档
|
||||
description: 该网站包含了当前版本以及前 4 个版本的 Kubernetes 文档。
|
||||
description: 本网站包含了当前及前 4 个版本的 Kubernetes 文档。
|
||||
---
|
||||
|
||||
@@ -631,9 +631,9 @@ Example of a minimal response from a webhook to allow a request:
|
||||
* `allowed`，设置为 `true` 或 `false`
|
||||
|
||||
<!--
|
||||
Example of a minimal response from a webhook to forbid a request:
|
||||
Example of a minimal response from a webhook to allow a request:
|
||||
-->
|
||||
Webhook 禁止请求的最简单响应示例：
|
||||
Webhook 允许请求的最简单响应示例：
|
||||
|
||||
{{< tabs name="AdmissionReview_response_allow" >}}
|
||||
{{% tab name="admission.k8s.io/v1" %}}
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: 附加组件
|
||||
id: addons
|
||||
date: 2019-12-15
|
||||
full_link: /docs/concepts/cluster-administration/addons/
|
||||
short_description: >
|
||||
扩展 Kubernetes 功能的资源。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
扩展 Kubernetes 功能的资源。
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Add-ons
|
||||
id: addons
|
||||
date: 2019-12-15
|
||||
full_link: /docs/concepts/cluster-administration/addons/
|
||||
short_description: >
|
||||
Resources that extend the functionality of Kubernetes.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
---
|
||||
Resources that extend the functionality of Kubernetes.
|
||||
-->
|
||||
|
||||
|
||||
<!--more-->
|
||||
|
||||
<!--
|
||||
[Installing addons](/docs/concepts/cluster-administration/addons/) explains more about using add-ons with your cluster, and lists some popular add-ons.
|
||||
-->
|
||||
[安装附加组件](/docs/concepts/cluster-administration/addons/) 阐释了更多关于如何在集群内使用附加组件，并列出了一些流行的附加组件。
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: CIDR
|
||||
id: cidr
|
||||
date: 2019-11-12
|
||||
full_link:
|
||||
short_description: >
|
||||
CIDR 是一种描述 IP 地址块的符号，被广泛使用于各种网络配置中。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- networking
|
||||
---
|
||||
CIDR (无类域间路由) 是一种描述 IP 地址块的符号，被广泛使用于各种网络配置中。
|
||||
|
||||
<!--
|
||||
---
|
||||
title: CIDR
|
||||
id: cidr
|
||||
date: 2019-11-12
|
||||
full_link:
|
||||
short_description: >
|
||||
CIDR is a notation for describing blocks of IP addresses and is used heavily in various networking configurations.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- networking
|
||||
---
|
||||
CIDR (Classless Inter-Domain Routing) is a notation for describing blocks of IP addresses and is used heavily in various networking configurations.
|
||||
-->
|
||||
|
||||
<!--more-->
|
||||
|
||||
<!--
|
||||
In the context of Kubernetes, each {{< glossary_tooltip text="Node" term_id="node" >}} is assigned a range of IP addresses through the start address and a subnet mask using CIDR. This allows Nodes to assign each {{< glossary_tooltip text="Pod" term_id="pod" >}} a unique IP address. Although originally a concept for IPv4, CIDR has also been expanded to include IPv6.
|
||||
-->
|
||||
在 Kubernetes 的上下文中，每个 {{< glossary_tooltip text="节点" term_id="node" >}} 以 CIDR 形式（含起始地址和子网掩码）获得一个 IP 地址段，从而能够为每个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 分配一个独一无二的 IP 地址。虽然其概念最初源自 IPv4，CIDR 已经被扩展为涵盖 IPv6。
|
||||
@@ -1,14 +1,11 @@
|
||||
---
|
||||
approvers:
|
||||
- chenopis
|
||||
- abiogenesis-now
|
||||
title: 标准化词汇表
|
||||
layout: glossary
|
||||
noedit: true
|
||||
default_active_tag: fundamental
|
||||
weight: 5
|
||||
card:
|
||||
name: 参考
|
||||
name: reference
|
||||
weight: 10
|
||||
title: 词汇表
|
||||
---
|
||||
|
||||
@@ -1,9 +1,5 @@
|
||||
---
|
||||
title: kubectl 备忘单
|
||||
reviewers:
|
||||
- erictune
|
||||
- krousey
|
||||
- clove
|
||||
content_type: concept
|
||||
card:
|
||||
name: reference
|
||||
@@ -23,34 +19,42 @@ card:
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!-- See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath). -->
|
||||
也可以看下: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。
|
||||
<!--
|
||||
See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath).
|
||||
|
||||
This page is an overview of the `kubectl` command.
|
||||
-->
|
||||
另见: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。
|
||||
|
||||
<!-- This page is an overview of the `kubectl` command. -->
|
||||
本页面是 `kubectl` 命令的概述。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!-- # kubectl - Cheat Sheet -->
|
||||
## kubectl - 备忘单
|
||||
<!--
|
||||
# kubectl - Cheat Sheet
|
||||
|
||||
## Kubectl Autocomplete
|
||||
-->
|
||||
# kubectl - 备忘单
|
||||
|
||||
<!-- ## Kubectl Autocomplete -->
|
||||
## Kubectl 自动补全
|
||||
|
||||
### BASH
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
source <(kubectl completion bash) # setup autocomplete in bash into the current shell, bash-completion package should be installed first.
|
||||
echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.
|
||||
``` -->
|
||||
```
|
||||
|
||||
You can also use a shorthand alias for `kubectl` that also works with completion:
|
||||
-->
|
||||
```bash
|
||||
source <(kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全，要先安装 bash-completion 包。
|
||||
echo "source <(kubectl completion bash)" >> ~/.bashrc # 在您的 bash shell 中永久的添加自动补全
|
||||
```
|
||||
|
||||
<!-- You can also use a shorthand alias for `kubectl` that also works with completion: -->
|
||||
您还可以为 `kubectl` 使用一个速记别名，该别名也可以与 completion 一起使用：
|
||||
|
||||
```bash
|
||||
@@ -60,25 +64,32 @@ complete -F __start_kubectl k
|
||||
|
||||
### ZSH
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
source <(kubectl completion zsh) # setup autocomplete in zsh into the current shell
|
||||
echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # add autocomplete permanently to your zsh shell
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
source <(kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全
|
||||
echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全
|
||||
```
|
||||
|
||||
<!-- ## Kubectl Context and Configuration
|
||||
<!--
|
||||
## Kubectl Context and Configuration
|
||||
|
||||
Set which Kubernetes cluster `kubectl` communicates with and modifies configuration
|
||||
information. See [Authenticating Across Clusters with kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation for
|
||||
detailed config file information. -->
|
||||
detailed config file information.
|
||||
-->
|
||||
## Kubectl 上下文和配置
|
||||
|
||||
设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 [使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档获取详情配置文件信息。
|
||||
设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看
|
||||
[使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
文档获取配置文件详细信息。
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
``bash
|
||||
kubectl config view # Show Merged kubeconfig settings.
|
||||
|
||||
# use multiple kubeconfig files at the same time and view merged config
|
||||
@@ -89,9 +100,10 @@ kubectl config view
|
||||
# get the password for the e2e user
|
||||
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
|
||||
|
||||
kubectl config view -o jsonpath='{.users[].name}' # get a list of users
|
||||
kubectl config view -o jsonpath='{.users[].name}' # display the first user
|
||||
kubectl config view -o jsonpath='{.users[*].name}' # get a list of users
|
||||
kubectl config get-contexts # display list of contexts
|
||||
kubectl config current-context # display the current-context
|
||||
kubectl config current-context # display the current-context
|
||||
kubectl config use-context my-cluster-name # set the default context to my-cluster-name
|
||||
|
||||
# add a new cluster to your kubeconf that supports basic auth
|
||||
@@ -105,7 +117,8 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \
|
||||
&& kubectl config use-context gce
|
||||
|
||||
kubectl config unset users.foo # delete user foo
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl config view # 显示合并的 kubeconfig 配置。
|
||||
|
||||
@@ -115,36 +128,54 @@ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view
|
||||
# 获取 e2e 用户的密码
|
||||
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
|
||||
|
||||
kubectl config current-context # 展示当前所处的上下文
|
||||
kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name
|
||||
kubectl config view -o jsonpath='{.users[].name}' # 显示第一个用户
|
||||
kubectl config view -o jsonpath='{.users[*].name}' # 获取用户列表
|
||||
kubectl config get-contexts # 显示上下文列表
|
||||
kubectl config current-context # 展示当前所处的上下文
|
||||
kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name
|
||||
|
||||
# 添加新的集群配置到 kubeconf 中，使用 basic auth 进行鉴权
|
||||
# 添加新的集群配置到 kubeconf 中，使用 basic auth 进行身份认证
|
||||
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
|
||||
|
||||
# 使用特定的用户名和命名空间设置上下文。
|
||||
# 在指定上下文中持久性地保存名字空间，供所有后续 kubectl 命令使用
|
||||
kubectl config set-context --current --namespace=ggckad-s2
|
||||
|
||||
# 使用特定的用户名和名字空间设置上下文
|
||||
kubectl config set-context gce --user=cluster-admin --namespace=foo \
|
||||
&& kubectl config use-context gce
|
||||
|
||||
kubectl config unset users.foo # 删除用户 foo
|
||||
```
|
||||
|
||||
<!-- ## Apply
|
||||
`apply` manages applications through files defining Kubernetes resources. It creates and updates resources in a cluster through running `kubectl apply`. This is the recommended way of managing Kubernetes applications on production. See [Kubectl Book](https://kubectl.docs.kubernetes.io). -->
|
||||
<!--
|
||||
## Apply
|
||||
`apply` 通过定义 Kubernetes 资源的文件管理应用程序。它通过运行 `kubectl apply` 在集群中创建和更新资源。这是在生产中管理 Kubernetes 应用程序的推荐方法。查阅 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。
|
||||
`apply` manages applications through files defining Kubernetes resources. It creates and updates resources in a cluster through running `kubectl apply`. This is the recommended way of managing Kubernetes applications on production. See [Kubectl Book](https://kubectl.docs.kubernetes.io).
|
||||
-->
|
||||
## Apply
|
||||
`apply` 通过定义 Kubernetes 资源的文件来管理应用。它通过运行
|
||||
`kubectl apply` 在集群中创建和更新资源。
|
||||
这是在生产中管理 Kubernetes 应用的推荐方法。
|
||||
参见 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。
|
||||
|
||||
<!-- ## Creating Objects -->
|
||||
## 创建对象
|
||||
<!--
|
||||
## Creating Objects
|
||||
|
||||
<!-- Kubernetes manifests can be defined in json or yaml. The file extension `.yaml`,
|
||||
`.yml`, and `.json` can be used. -->
|
||||
Kubernetes 配置可以用 json 或 yaml 定义。可以使用的文件扩展名有 `.yaml`，`.yml` 和 `.json`。
|
||||
Kubernetes manifests can be defined in YAML or JSON. The file extension `.yaml`,
|
||||
`.yml`, and `.json` can be used.
|
||||
-->
|
||||
## 创建对象 {#creating-objects}
|
||||
|
||||
<!-- ```bash
|
||||
Kubernetes 配置可以用 YAML 或 JSON 定义。可以使用的文件扩展名有
|
||||
`.yaml`、`.yml` 和 `.json`。
|
||||
|
||||
<!--
|
||||
```bash
|
||||
kubectl apply -f ./my-manifest.yaml # create resource(s)
|
||||
kubectl apply -f ./my1.yaml -f ./my2.yaml # create from multiple files
|
||||
kubectl apply -f ./dir # create resource(s) in all manifest files in dir
|
||||
kubectl apply -f https://git.io/vPieo # create resource(s) from url
|
||||
kubectl create deployment nginx --image=nginx # start a single instance of nginx
|
||||
kubectl explain pods,svc # get the documentation for pod and svc manifests
|
||||
kubectl create deployment nginx --image=nginx # start a single instance of nginx
|
||||
kubectl explain pods # get the documentation for pod and svc manifests
|
||||
|
||||
# Create multiple YAML objects from stdin
|
||||
cat <<EOF | kubectl apply -f -
|
||||
@@ -184,17 +215,17 @@ data:
|
||||
password: $(echo -n "s33msi4" | base64 -w0)
|
||||
username: $(echo -n "jane" | base64 -w0)
|
||||
EOF
|
||||
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl apply -f ./my-manifest.yaml # 创建资源
|
||||
kubectl apply -f ./my1.yaml -f ./my2.yaml # 使用多个文件创建
|
||||
kubectl apply -f ./dir # 从目录下的全部配置文件创建资源
|
||||
kubectl apply -f https://git.io/vPieo # 从 url 中创建资源
|
||||
kubectl create deployment nginx --image=nginx # 启动单实例 nginx
|
||||
kubectl explain pods,svc # 获取 pod，svc 配置的文档说明
|
||||
kubectl apply -f ./dir # 基于目录下的所有清单文件创建资源
|
||||
kubectl apply -f https://git.io/vPieo # 从 URL 中创建资源
|
||||
kubectl create deployment nginx --image=nginx # 启动单实例 nginx
|
||||
kubectl explain pods,svc # 获取 pod 清单的文档说明
|
||||
|
||||
# 从标准输入中的多个 YAML 对象中创建
|
||||
# 从标准输入创建多个 YAML 对象
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -232,34 +263,35 @@ data:
|
||||
password: $(echo -n "s33msi4" | base64 -w0)
|
||||
username: $(echo -n "jane" | base64 -w0)
|
||||
EOF
|
||||
|
||||
```
|
||||
|
||||
<!-- ## Viewing, Finding Resources -->
|
||||
## 获取和查找资源
|
||||
<!--
|
||||
## Viewing, Finding Resources
|
||||
-->
|
||||
## 查看和查找资源
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
# Get commands with basic output
|
||||
kubectl get services # List all services in the namespace
|
||||
kubectl get pods --all-namespaces # List all pods in all namespaces
|
||||
kubectl get pods -o wide # List all pods in the namespace, with more details
|
||||
kubectl get deployment my-dep # List a particular deployment
|
||||
kubectl get pods --include-uninitialized # List all pods in the namespace, including uninitialized ones
|
||||
kubectl get pods # List all pods in the namespace
|
||||
kubectl get pod my-pod -o yaml # Get a pod's YAML
|
||||
kubectl get pod my-pod -o yaml --export # Get a pod's YAML without cluster specific information
|
||||
|
||||
# Describe commands with verbose output
|
||||
kubectl describe nodes my-node
|
||||
kubectl describe pods my-pod
|
||||
|
||||
kubectl get services --sort-by=.metadata.name # List Services Sorted by Name
|
||||
# List Services Sorted by Name
|
||||
kubectl get services --sort-by=.metadata.name
|
||||
|
||||
# List pods Sorted by Restart Count
|
||||
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
|
||||
|
||||
# List pods in test namespace sorted by capacity
|
||||
|
||||
kubectl get pods -n test --sort-by=.spec.capacity.storage
|
||||
# List PersistentVolumes sorted by capacity
|
||||
kubectl get pv --sort-by=.spec.capacity.storage
|
||||
|
||||
# Get the version label of all pods with label app=cassandra
|
||||
kubectl get pods --selector=app=cassandra -o \
|
||||
@@ -281,10 +313,6 @@ sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries
|
||||
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
|
||||
|
||||
# Show labels for all pods (or any other Kubernetes object that supports labelling)
|
||||
# Also uses "jq"
|
||||
for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done
|
||||
|
||||
# Or this command can be used as well to get all the labels associated with pods
|
||||
kubectl get pods --show-labels
|
||||
|
||||
# Check which nodes are ready
|
||||
@@ -294,86 +322,91 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty
|
||||
# List all Secrets currently in use by a pod
|
||||
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
|
||||
|
||||
# List all containerIDs of initContainer of all pods
|
||||
# Helpful when cleaning up stopped containers, while avoiding removal of initContainers.
|
||||
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
|
||||
|
||||
# List Events sorted by timestamp
|
||||
kubectl get events --sort-by=.metadata.creationTimestamp
|
||||
``` -->
|
||||
```bash
|
||||
# 使用 get 命令获取基本输出
|
||||
kubectl get services # 列出当前命名空间下的所有 services
|
||||
kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 pods
|
||||
kubectl get pods -o wide # 列出当前命名空间下的全部 pods，有更多的详细信息
|
||||
kubectl get deployment my-dep # 列出某个特定的 deployment
|
||||
kubectl get pods --include-uninitialized # 列出当前命名空间下的全部 pods，包含未初始化的
|
||||
kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML
|
||||
kubectl get pod my-pod -o yaml --export # 获取一个没有集群特定信息的 YAML
|
||||
|
||||
# 使用 describe 命令获取详细输出
|
||||
# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied.
|
||||
kubectl diff -f ./my-manifest.yaml
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
# get 命令的基本输出
|
||||
kubectl get services # 列出当前命名空间下的所有 services
|
||||
kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 Pods
|
||||
kubectl get pods -o wide # 列出当前命名空间下的全部 Pods，并显示更详细的信息
|
||||
kubectl get deployment my-dep # 列出某个特定的 Deployment
|
||||
kubectl get pods # 列出当前命名空间下的全部 Pods
|
||||
kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML
|
||||
|
||||
# describe 命令的详细输出
|
||||
kubectl describe nodes my-node
|
||||
kubectl describe pods my-pod
|
||||
|
||||
kubectl get services --sort-by=.metadata.name # 列出当前命名空间下所有 services，按照名称排序
|
||||
# 列出当前名字空间下所有 Services，按名称排序
|
||||
kubectl get services --sort-by=.metadata.name
|
||||
|
||||
# 列出 pods 按照重启次数进行排序
|
||||
# 列出 Pods，按重启次数排序
|
||||
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
|
||||
|
||||
# 列出测试命名空间中的 Pod，按容量排序
|
||||
kubectl get pods -n test --sort-by=.spec.capacity.storage
|
||||
# 列举所有 PV 持久卷，按容量排序
|
||||
kubectl get pv --sort-by=.spec.capacity.storage
|
||||
|
||||
# 获取包含 app=cassandra 标签全部 pods 的 version 标签
|
||||
# 获取包含 app=cassandra 标签的所有 Pods 的 version 标签
|
||||
kubectl get pods --selector=app=cassandra -o \
|
||||
jsonpath='{.items[*].metadata.labels.version}'
|
||||
|
||||
# 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果)
|
||||
# 获取所有工作节点（使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果）
|
||||
kubectl get node --selector='!node-role.kubernetes.io/master'
|
||||
|
||||
# 获取当前命名空间中正在运行的 pods
|
||||
# 获取当前命名空间中正在运行的 Pods
|
||||
kubectl get pods --field-selector=status.phase=Running
|
||||
|
||||
# 获取全部 node 的 ExternalIP 地址
|
||||
# 获取全部节点的 ExternalIP 地址
|
||||
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
|
||||
|
||||
# 列出属于某个特定 RC 的 pods 的名称
|
||||
# "jq" 命令对于 jsonpath 过于复杂的转换非常有用，可以在 https://stedolan.github.io/jq/ 找到它。
|
||||
# 列出属于某个特定 RC 的 Pods 的名称
|
||||
# 在转换对于 jsonpath 过于复杂的场合，"jq" 命令很有用；可以在 https://stedolan.github.io/jq/ 找到它。
|
||||
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
|
||||
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
|
||||
|
||||
# 显示所有 Pod 的标签(或任何其他支持标签的 Kubernetes 对象)
|
||||
# 也可以使用 "jq"
|
||||
for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done
|
||||
|
||||
# 或也可以使用此命令来获取与容器关联的所有标签
|
||||
# 显示所有 Pods 的标签（或任何其他支持标签的 Kubernetes 对象）
|
||||
kubectl get pods --show-labels
|
||||
|
||||
# 检查哪些节点处于 ready
|
||||
# 检查哪些节点处于就绪状态
|
||||
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
|
||||
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
|
||||
|
||||
# 列出被一个 pod 使用的全部 secret
|
||||
# 列出被一个 Pod 使用的全部 Secret
|
||||
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
|
||||
|
||||
# 列出 events，按照创建时间排序
|
||||
# 列举所有 Pods 中初始化容器的容器 ID（containerID）
|
||||
# Helpful when cleaning up stopped containers, while avoiding removal of initContainers.
|
||||
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
|
||||
|
||||
# 列出事件（Events），按时间戳排序
|
||||
kubectl get events --sort-by=.metadata.creationTimestamp
|
||||
|
||||
# 比较当前的集群状态和假定某清单被应用之后的集群状态
|
||||
kubectl diff -f ./my-manifest.yaml
|
||||
```
|
||||
|
||||
<!-- ## Updating Resources -->
|
||||
<!--
|
||||
## Updating Resources
|
||||
-->
|
||||
## 更新资源
|
||||
|
||||
<!-- As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)), use `rollout` instead. -->
|
||||
从版本 1.11 开始，`rolling-update` 已被弃用（参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md))，请使用 `rollout` 代替。
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image
|
||||
kubectl rollout history deployment/frontend # Check the history of deployments including the revision
|
||||
kubectl rollout undo deployment/frontend # Rollback to the previous deployment
|
||||
kubectl rollout undo deployment/frontend --to-revision=2 # Rollback to a specific revision
|
||||
kubectl rollout status -w deployment/frontend # Watch rolling update status of "frontend" deployment until completion
|
||||
|
||||
|
||||
# deprecated starting version 1.11
|
||||
kubectl rolling-update frontend-v1 -f frontend-v2.json # (deprecated) Rolling update pods of frontend-v1
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (deprecated) Change the name of the resource and update the image
|
||||
kubectl rolling-update frontend --image=image:v2 # (deprecated) Update the pods image of frontend
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --rollback # (deprecated) Abort existing rollout in progress
|
||||
kubectl rollout restart deployment/frontend # Rolling restart of the "frontend" deployment
|
||||
|
||||
cat pod.json | kubectl replace -f - # Replace a pod based on the JSON passed into std
|
||||
|
||||
@@ -389,41 +422,39 @@ kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl
|
||||
kubectl label pods my-pod new-label=awesome # Add a Label
|
||||
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Add an annotation
|
||||
kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a deployment "foo"
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" deployment 的 "www" 容器镜像
|
||||
kubectl rollout history deployment/frontend # 检查部署的历史记录，包括版本
|
||||
kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" Deployment 的 "www" 容器镜像
|
||||
kubectl rollout history deployment/frontend # 检查 Deployment 的历史记录，包括版本
|
||||
kubectl rollout undo deployment/frontend # 回滚到上次部署版本
|
||||
kubectl rollout undo deployment/frontend --to-revision=2 # 回滚到特定部署版本
|
||||
kubectl rollout status -w deployment/frontend # Watch "frontend" deployment 的滚动升级状态直到完成
|
||||
kubectl rollout status -w deployment/frontend # 监视 "frontend" Deployment 的滚动升级状态直到完成
|
||||
kubectl rollout restart deployment/frontend # 轮替重启 "frontend" Deployment
|
||||
|
||||
# 从 1.11 版本开始弃用
|
||||
kubectl rolling-update frontend-v1 -f frontend-v2.json # (弃用) 滚动升级 frontend-v1 的 pods
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (弃用) 修改资源的名称并更新镜像
|
||||
kubectl rolling-update frontend --image=image:v2 # (弃用) 更新 frontend 的 pods 的镜像
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --rollback # (弃用) 终止已经进行中的 rollout
|
||||
cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 Pod
|
||||
|
||||
cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 pod
|
||||
|
||||
# 强制进行替换，会删除然后再创建资源，会导致服务不可用。
|
||||
# 强制替换，删除后重建资源。会导致服务不可用。
|
||||
kubectl replace --force -f ./pod.json
|
||||
|
||||
# 为多副本的 nginx 创建服务，使用 80 端口提供服务，连接到容器的 8000 端口。
|
||||
kubectl expose rc nginx --port=80 --target-port=8000
|
||||
|
||||
# 更新单容器 pod 的镜像标签到 v4
|
||||
# 将某单容器 Pod 的镜像版本（标签）更新到 v4
|
||||
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
|
||||
|
||||
kubectl label pods my-pod new-label=awesome # 添加标签
|
||||
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 添加注解
|
||||
kubectl autoscale deployment foo --min=2 --max=10 # 使 "foo" deployment 自动伸缩容
|
||||
kubectl autoscale deployment foo --min=2 --max=10 # 对 "foo" Deployment 自动伸缩容
|
||||
```
|
||||
|
||||
<!-- ## Patching Resources -->
|
||||
## 局部更新资源
|
||||
## 部分更新资源
|
||||
|
||||
<!-- ```bash
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # Partially update a node
|
||||
<!--
|
||||
```bash
|
||||
# Partially update a node
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
|
||||
|
||||
# Update a container's image; spec.containers[*].name is required because it's a merge key
|
||||
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
|
||||
@@ -436,38 +467,48 @@ kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "
|
||||
|
||||
# Add a new element to a positional array
|
||||
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 部分更新 node
|
||||
# 部分更新某节点
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
|
||||
|
||||
#更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并 key。
|
||||
# 更新容器的镜像；spec.containers[*].name 是必须的。因为它是一个合并性质的主键。
|
||||
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
|
||||
|
||||
# 使用带位置数组的 json patch 更新容器的镜像
|
||||
# 使用带位置数组的 JSON patch 更新容器的镜像
|
||||
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
|
||||
|
||||
# 使用带位置数组的 json patch 禁用 deployment 的 livenessProbe
|
||||
# 使用带位置数组的 JSON patch 禁用某 Deployment 的 livenessProbe
|
||||
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
|
||||
|
||||
# 在带位置数组中添加元素
|
||||
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
|
||||
```
|
||||
|
||||
<!-- ## Editing Resources -->
|
||||
## 编辑资源
|
||||
<!-- The edit any API resource in an editor. -->
|
||||
在编辑器中编辑任何 API 资源
|
||||
<!--
|
||||
## Editing Resources
|
||||
|
||||
<!-- ```bash
|
||||
The edit any API resource in an editor.
|
||||
-->
|
||||
## 编辑资源
|
||||
|
||||
使用你偏爱的编辑器编辑 API 资源。
|
||||
|
||||
<!--
|
||||
```bash
|
||||
kubectl edit svc/docker-registry # Edit the service named docker-registry
|
||||
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Use an alternative editor
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl edit svc/docker-registry # 编辑名为 docker-registry 的 service
|
||||
kubectl edit svc/docker-registry # 编辑名为 docker-registry 的服务
|
||||
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使用其他编辑器
|
||||
```
|
||||
|
||||
<!-- ## Scaling Resources -->
|
||||
<!--
|
||||
## Scaling Resources
|
||||
-->
|
||||
## 对资源进行伸缩
|
||||
|
||||
<!-- ```bash
|
||||
@@ -475,40 +516,47 @@ kubectl scale --replicas=3 rs/foo # Scale a repl
|
||||
kubectl scale --replicas=3 -f foo.yaml # Scale a resource specified in "foo.yaml" to 3
|
||||
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deployment named mysql's current size is 2, scale mysql to 3
|
||||
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl scale --replicas=3 rs/foo # 将名为 'foo' 的副本集伸缩到 3 副本
|
||||
kubectl scale --replicas=3 -f foo.yaml # 将在 "foo.yaml" 中的特定资源伸缩到 3 个副本
|
||||
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 deployment 的副本当前是 2，那么将它伸缩到 3
|
||||
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个 replication controllers
|
||||
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 Deployment 的副本当前是 2，那么将它伸缩到 3
|
||||
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个副本控制器
|
||||
```
|
||||
|
||||
<!-- ## Deleting Resources -->
|
||||
<!--
|
||||
## Deleting Resources
|
||||
-->
|
||||
## 删除资源
|
||||
|
||||
<!-- ```bash
|
||||
kubectl delete -f ./pod.json # Delete a pod using the type and name specified in pod.json
|
||||
kubectl delete pod,service baz foo # Delete pods and services with same names "baz" and "foo"
|
||||
kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel
|
||||
kubectl delete pods,services -l name=myLabel --include-uninitialized # Delete pods and services, including uninitialized ones, with label name=myLabel
|
||||
kubectl -n my-ns delete po,svc --all # Delete all pods and services, including uninitialized ones, in namespace my-ns,
|
||||
kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel
|
||||
kubectl -n my-ns delete po,svc --all # Delete all pods and services in namespace my-ns,
|
||||
# Delete all pods matching the awk pattern1 or pattern2
|
||||
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 pod
|
||||
kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 pod 和 service
|
||||
kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和 services
|
||||
kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 pods 和 services，包括未初始化的
|
||||
kubectl -n my-ns delete po,svc --all # 删除在 my-ns 命名空间中全部的 pods 和 services ，包括未初始化的
|
||||
# 删除所有与 pattern1 或 pattern2 匹配的 pod
|
||||
kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 Pod
|
||||
kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 Pod 和服务
|
||||
kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和服务
|
||||
kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 Pods 和服务
|
||||
kubectl -n my-ns delete po,svc --all # 删除在 my-ns 名字空间中全部的 Pods 和服务
|
||||
# 删除所有与 pattern1 或 pattern2 awk 模式匹配的 Pods
|
||||
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
|
||||
```
|
||||
|
||||
<!-- ## Interacting with running Pods -->
|
||||
<!--
|
||||
## Interacting with running Pods
|
||||
-->
|
||||
## 与运行中的 Pods 进行交互
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
kubectl logs my-pod # dump pod logs (stdout)
|
||||
kubectl logs -l name=myLabel # dump pod logs, with label name=myLabel (stdout)
|
||||
kubectl logs my-pod --previous # dump pod logs (stdout) for a previous instantiation of a container
|
||||
@@ -519,34 +567,47 @@ kubectl logs -f my-pod # stream pod logs (stdout)
|
||||
kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)
|
||||
kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout)
|
||||
kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
|
||||
kubectl run nginx --image=nginx -n
|
||||
mynamespace # Run pod nginx in a specific namespace
|
||||
kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml
|
||||
--dry-run=client -o yaml > pod.yaml
|
||||
|
||||
kubectl attach my-pod -i # Attach to Running Container
|
||||
kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod
|
||||
kubectl exec my-pod -- ls / # Run command in existing pod (1 container case)
|
||||
kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case)
|
||||
kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl logs my-pod # 获取 pod 日志(标准输出)
|
||||
kubectl logs -l name=myLabel # 获取 pod label name=myLabel 日志(标准输出)
|
||||
kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志(标准输出)
|
||||
kubectl logs my-pod -c my-container # 获取 pod 的容器日志 (标准输出, 多容器的场景)
|
||||
kubectl logs -l name=myLabel -c my-container # 获取 label name=myLabel pod 的容器日志 (标准输出, 多容器的场景)
|
||||
kubectl logs my-pod -c my-container --previous # 获取 pod 的上个容器实例日志 (标准输出, 多容器的场景)
|
||||
kubectl logs -f my-pod # 流式输出 pod 的日志 (标准输出)
|
||||
kubectl logs -f my-pod -c my-container # 流式输出 pod 容器的日志 (标准输出, 多容器的场景)
|
||||
kubectl logs -f -l name=myLabel --all-containers # 流式输出 label name=myLabel pod 的日志 (标准输出)
|
||||
kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 shell 运行 pod
|
||||
kubectl attach my-pod -i # 进入到一个运行中的容器中
|
||||
kubectl logs my-pod # 获取 pod 日志（标准输出）
|
||||
kubectl logs -l name=myLabel # 获取含 name=myLabel 标签的 Pods 的日志（标准输出）
|
||||
kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志（标准输出）
|
||||
kubectl logs my-pod -c my-container # 获取 Pod 容器的日志（标准输出, 多容器场景）
|
||||
kubectl logs -l name=myLabel -c my-container # 获取含 name=myLabel 标签的 Pod 容器日志（标准输出, 多容器场景）
|
||||
kubectl logs my-pod -c my-container --previous # 获取 Pod 中某容器的上个实例的日志（标准输出, 多容器场景）
|
||||
kubectl logs -f my-pod # 流式输出 Pod 的日志（标准输出）
|
||||
kubectl logs -f my-pod -c my-container # 流式输出 Pod 容器的日志（标准输出, 多容器场景）
|
||||
kubectl logs -f -l name=myLabel --all-containers # 流式输出含 name=myLabel 标签的 Pod 的所有日志（标准输出）
|
||||
kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 Shell 运行 Pod
|
||||
kubectl run nginx --image=nginx -n mynamespace # 在指定名字空间中运行 nginx Pod
|
||||
kubectl run nginx --image=nginx # 运行 ngins Pod 并将其规约写入到名为 pod.yaml 的文件
|
||||
--dry-run=client -o yaml > pod.yaml
|
||||
|
||||
kubectl attach my-pod -i # 挂接到一个运行的容器中
|
||||
kubectl port-forward my-pod 5000:6000 # 在本地计算机上侦听端口 5000 并转发到 my-pod 上的端口 6000
|
||||
kubectl exec my-pod -- ls / # 在已有的 pod 中运行命令(单容器的场景)
|
||||
kubectl exec my-pod -c my-container -- ls / # 在已有的 pod 中运行命令(多容器的场景)
|
||||
kubectl top pod POD_NAME --containers # 显示给定 pod 和容器的监控数据
|
||||
kubectl exec my-pod -- ls / # 在已有的 Pod 中运行命令（单容器场景）
|
||||
kubectl exec my-pod -c my-container -- ls / # 在已有的 Pod 中运行命令（多容器场景）
|
||||
kubectl top pod POD_NAME --containers # 显示给定 Pod 和其中容器的监控数据
|
||||
```
|
||||
|
||||
<!-- ## Interacting with Nodes and Cluster -->
|
||||
<!--
|
||||
## Interacting with Nodes and Cluster
|
||||
-->
|
||||
## 与节点和集群进行交互
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
kubectl cordon my-node # Mark my-node as unschedulable
|
||||
kubectl drain my-node # Drain my-node in preparation for maintenance
|
||||
kubectl uncordon my-node # Mark my-node as schedulable
|
||||
@@ -557,57 +618,70 @@ kubectl cluster-info dump --output-directory=/path/to/cluster-state # Dump cur
|
||||
|
||||
# If a taint with that key and effect already exists, its value is replaced as specified.
|
||||
kubectl taint nodes foo dedicated=special-user:NoSchedule
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl cordon my-node # 设置 my-node 节点为不可调度
|
||||
kubectl drain my-node # 对 my-node 节点进行驱逐操作，为节点维护做准备
|
||||
kubectl uncordon my-node # 设置 my-node 节点为可以调度
|
||||
kubectl top node my-node # 显示给定 node 的指标
|
||||
kubectl cluster-info # 显示 master 和 services 的地址
|
||||
kubectl cluster-info dump # 将当前集群状态输出到标准输出
|
||||
kubectl cordon my-node # 标记 my-node 节点为不可调度
|
||||
kubectl drain my-node # 对 my-node 节点进行清空操作，为节点维护做准备
|
||||
kubectl uncordon my-node # 标记 my-node 节点为可以调度
|
||||
kubectl top node my-node # 显示给定节点的度量值
|
||||
kubectl cluster-info # 显示主控节点和服务的地址
|
||||
kubectl cluster-info dump # 将当前集群状态转储到标准输出
|
||||
kubectl cluster-info dump --output-directory=/path/to/cluster-state # 将当前集群状态输出到 /path/to/cluster-state
|
||||
|
||||
# 如果已存在具有该键和效果的污点，则其值将按指定替换
|
||||
# 如果已存在具有指定键和效果的污点，则替换其值为指定值
|
||||
kubectl taint nodes foo dedicated=special-user:NoSchedule
|
||||
```
|
||||
|
||||
<!-- ### Resource types -->
|
||||
<!--
|
||||
### Resource types
|
||||
-->
|
||||
### 资源类型
|
||||
|
||||
<!-- List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects): -->
|
||||
列出全部支持的资源类型和它们的简称, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), 无论它们是否是 [namespaced](/docs/concepts/overview/working-with-objects/namespaces), [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。
|
||||
<!--
|
||||
List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
|
||||
-->
|
||||
列出所支持的全部资源类型和它们的简称、[API 组](/docs/concepts/overview/kubernetes-api/#api-groups), 是否是[名字空间作用域](/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。
|
||||
|
||||
```bash
|
||||
kubectl api-resources
|
||||
```
|
||||
|
||||
<!-- Other operations for exploring API resources: -->
|
||||
<!--
|
||||
Other operations for exploring API resources:
|
||||
-->
|
||||
用于探索 API 资源的其他操作：
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
kubectl api-resources --namespaced=true # All namespaced resources
|
||||
kubectl api-resources --namespaced=false # All non-namespaced resources
|
||||
kubectl api-resources -o name # All resources with simple output (just the resource name)
|
||||
kubectl api-resources -o wide # All resources with expanded (aka "wide") output
|
||||
kubectl api-resources --verbs=list,get # All resources that support the "list" and "get" request verbs
|
||||
kubectl api-resources --api-group=extensions # All resources in the "extensions" API group
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl api-resources --namespaced=true # 所有在命名空间中的资源
|
||||
kubectl api-resources --namespaced=false # 所有不在命名空间中的资源
|
||||
kubectl api-resources -o name # 输出简单的所有资源（只是资源名称）
|
||||
kubectl api-resources -o wide # 具有扩展（又称 "wide"）输出的所有资源
|
||||
kubectl api-resources --namespaced=true # 所有命名空间作用域的资源
|
||||
kubectl api-resources --namespaced=false # 所有非命名空间作用域的资源
|
||||
kubectl api-resources -o name # 用简单格式列举所有资源（仅显示资源名称）
|
||||
kubectl api-resources -o wide # 用扩展格式列举所有资源（又称 "wide" 格式）
|
||||
kubectl api-resources --verbs=list,get # 支持 "list" 和 "get" 请求动词的所有资源
|
||||
kubectl api-resources --api-group=extensions # "extensions" API 组中的所有资源
|
||||
```
|
||||
|
||||
<!-- ### Formatting output -->
|
||||
<!--
|
||||
### Formatting output
|
||||
|
||||
To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command.
|
||||
-->
|
||||
### 格式化输出
|
||||
|
||||
<!-- To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command. -->
|
||||
要以特定格式将详细信息输出到终端窗口，可以将 `-o` 或 `--output` 参数添加到支持的 `kubectl` 命令。
|
||||
|
||||
<!-- Output format | Description
|
||||
<!--O
|
||||
utput format | Description
|
||||
--------------| -----------
|
||||
`-o=custom-columns=<spec>` | Print a table using a comma separated list of custom columns
|
||||
`-o=custom-columns-file=<filename>` | Print a table using the custom columns template in the `<filename>` file
|
||||
@@ -616,25 +690,63 @@ kubectl api-resources --api-group=extensions # "extensions" API 组中的所有
|
||||
`-o=jsonpath-file=<filename>` | Print the fields defined by the [jsonpath](/docs/reference/kubectl/jsonpath) expression in the `<filename>` file
|
||||
`-o=name` | Print only the resource name and nothing else
|
||||
`-o=wide` | Output in the plain-text format with any additional information, and for pods, the node name is included
|
||||
`-o=yaml` | Output a YAML formatted API object -->
|
||||
输出格式 | 描述
|
||||
`-o=yaml` | Output a YAML formatted API object
|
||||
-->
|
||||
输出格式 | 描述
|
||||
--------------| -----------
|
||||
`-o=custom-columns=<spec>` | 使用逗号分隔的自定义列列表打印表格
|
||||
`-o=custom-columns=<spec>` | 使用逗号分隔的自定义列来打印表格
|
||||
`-o=custom-columns-file=<filename>` | 使用 `<filename>` 文件中的自定义列模板打印表格
|
||||
`-o=json` | 输出 JSON 格式的 API 对象
|
||||
`-o=jsonpath=<template>` | 打印 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式中定义的字段
|
||||
`-o=jsonpath-file=<filename>` | 在 `<filename>` 文件中打印由 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式定义的字段。
|
||||
`-o=name` | 仅打印资源名称而不打印任何其他内容
|
||||
`-o=wide` | 使用任何其他信息以纯文本格式输出，对于 pod 来说，包含了节点名称
|
||||
`-o=jsonpath-file=<filename>` | 打印在 `<filename>` 文件中定义的 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式所指定的字段。
|
||||
`-o=name` | 仅打印资源名称而不打印其他内容
|
||||
`-o=wide` | 以纯文本格式输出额外信息，对于 Pod 来说，输出中包含了节点名称
|
||||
`-o=yaml` | 输出 YAML 格式的 API 对象
|
||||
|
||||
<!-- ### Kubectl output verbosity and debugging -->
|
||||
<!--
|
||||
Examples using `-o=custom-columns`:
|
||||
|
||||
```bash
|
||||
# All images running in a cluster
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
|
||||
|
||||
# All images excluding "k8s.gcr.io/coredns:1.6.2"
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
|
||||
|
||||
# All fields under metadata regardless of name
|
||||
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
|
||||
|
||||
More examples in the kubectl [reference documentation](/docs/reference/kubectl/overview/#custom-columns).
|
||||
```
|
||||
-->
|
||||
使用 `-o=custom-columns` 的示例：
|
||||
|
||||
```bash
|
||||
# 集群中运行着的所有镜像
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
|
||||
|
||||
# 除 "k8s.gcr.io/coredns:1.6.2" 之外的所有镜像
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
|
||||
|
||||
# 输出 metadata 下面的所有字段，无论 Pod 名字为何
|
||||
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
|
||||
```
|
||||
|
||||
有关更多示例，请参看 kubectl [参考文档](/docs/reference/kubectl/overview/#custom-columns)。
|
||||
|
||||
<!--
|
||||
### Kubectl output verbosity and debugging
|
||||
|
||||
Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
|
||||
-->
|
||||
### Kubectl 日志输出详细程度和调试
|
||||
|
||||
<!-- Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md). -->
|
||||
Kubectl 日志输出详细程度是通过 `-v` 或者 `--v` 来控制的，参数后跟了一个数字表示日志的级别。Kubernetes 通用的日志习惯和相关的日志级别在 [这里](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 有相应的描述。
|
||||
Kubectl 日志输出详细程度是通过 `-v` 或者 `--v` 来控制的，参数后跟一个数字表示日志的级别。
|
||||
Kubernetes 通用的日志习惯和相关的日志级别在
|
||||
[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 有相应的描述。
|
||||
|
||||
<!-- Verbosity | Description
|
||||
<!--
|
||||
Verbosity | Description
|
||||
--------------| -----------
|
||||
`--v=0` | Generally useful for this to *always* be visible to a cluster operator.
|
||||
`--v=1` | A reasonable default log level if you don't want verbosity.
|
||||
@@ -644,37 +756,30 @@ Kubectl 日志输出详细程度是通过 `-v` 或者 `--v` 来控制的，参
|
||||
`--v=6` | Display requested resources.
|
||||
`--v=7` | Display HTTP request headers.
|
||||
`--v=8` | Display HTTP request contents.
|
||||
`--v=9` | Display HTTP request contents without truncation of contents. -->
|
||||
详细程度 | 描述
|
||||
`--v=9` | Display HTTP request contents without truncation of contents.
|
||||
-->
|
||||
详细程度 | 描述
|
||||
--------------| -----------
|
||||
`--v=0` | 通常对此有用，*始终*对运维人员可见。
|
||||
`--v=1` | 如果您不想要详细程度，则为合理的默认日志级别。
|
||||
`--v=2` | 有关服务的有用稳定状态信息以及可能与系统中的重大更改相关的重要日志消息。这是大多数系统的建议默认日志级别。
|
||||
`--v=3` | 有关更改的扩展信息。
|
||||
`--v=4` | Debug 级别。
|
||||
`--v=6` | 显示请求的资源。
|
||||
`--v=0` | 用于那些应该 *始终* 对运维人员可见的信息，因为这些信息一般很有用。
|
||||
`--v=1` | 如果您不想要看到冗余信息，此值是一个合理的默认日志级别。
|
||||
`--v=2` | 输出有关服务的稳定状态的信息以及重要的日志消息，这些信息可能与系统中的重大变化有关。这是建议大多数系统设置的默认日志级别。
|
||||
`--v=3` | 包含有关系统状态变化的扩展信息。
|
||||
`--v=4` | 包含调试级别的冗余信息。
|
||||
`--v=6` | 显示所请求的资源。
|
||||
`--v=7` | 显示 HTTP 请求头。
|
||||
`--v=8` | 显示 HTTP 请求内容。
|
||||
`--v=9` | 显示 HTTP 请求内容而不截断内容。
|
||||
|
||||
|
||||
`--v=9` | 显示 HTTP 请求内容而且不截断内容。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!-- * Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/).
|
||||
|
||||
<!--
|
||||
* Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/).
|
||||
* See [kubectl](/docs/reference/kubectl/kubectl/) options.
|
||||
|
||||
* Also [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use it in reusable scripts.
|
||||
|
||||
* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4). -->
|
||||
* 学习更多关于 [kubectl 概述](/docs/reference/kubectl/overview/)。
|
||||
|
||||
* 查看 [kubectl](/docs/reference/kubectl/kubectl/) 选项.
|
||||
|
||||
* 也可以查看 [kubectl 使用约定](/docs/reference/kubectl/conventions/) 来理解如果在可以复用的脚本中使用它。
|
||||
|
||||
* 查看更多社区 [kubectl 备忘单](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。
|
||||
|
||||
* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
|
||||
-->
|
||||
* 进一步了解 [kubectl 概述](/docs/reference/kubectl/overview/)。
|
||||
* 参阅 [kubectl](/docs/reference/kubectl/kubectl/) 选项.
|
||||
* 参阅 [kubectl 使用约定](/docs/reference/kubectl/conventions/)来理解如果在可复用的脚本中使用它。
|
||||
* 查看社区中其他的 [kubectl 备忘单](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。
|
||||
|
||||
|
||||
@@ -25,11 +25,10 @@ You can use the Kubernetes command line tool kubectl to interact with the API Se
|
||||
<!-- body -->
|
||||
## docker run
|
||||
|
||||
<!--
|
||||
To run an nginx Deployment and expose the Deployment, see [kubectl run](/docs/reference/generated/kubectl/kubectl-commands/#run).
|
||||
<!--
|
||||
To run an nginx Deployment and expose the Deployment, see [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-).
|
||||
-->
|
||||
要运行 nginx 部署并将其暴露，请参见 [kubectl 运行](/docs/reference/generated/kubectl/kubectl-commands/#run)。
|
||||
|
||||
要运行 nginx 部署并将其暴露，请参见[kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-)
|
||||
docker:
|
||||
|
||||
```shell
|
||||
@@ -57,10 +56,18 @@ kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster"
|
||||
-->
|
||||
```shell
|
||||
# 启动运行 nginx 的 Pod
|
||||
kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster"
|
||||
kubectl create deployment --image=nginx nginx-app
|
||||
```
|
||||
```
|
||||
deployment "nginx-app" created
|
||||
deployment.apps/nginx-app created
|
||||
```
|
||||
|
||||
```
|
||||
# add env to nginx-app
|
||||
kubectl set env deployment/nginx-app DOMAIN=cluster
|
||||
```
|
||||
```
|
||||
deployment.apps/nginx-app env updated
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
@@ -89,10 +96,10 @@ By using kubectl, you can create a [Deployment](/docs/concepts/workloads/control
|
||||
-->
|
||||
在 kubectl 命令中，我们创建了一个 [Deployment](/docs/concepts/workloads/controllers/deployment/)，这将保证有 N 个运行 nginx 的 pod(N 代表 spec 中声明的 replica 数，默认为 1)。我们还创建了一个 [service](/docs/concepts/services-networking/service/)，其选择器与容器标签匹配。查看[使用服务访问群集中的应用程序](/docs/tasks/access-application-cluster/service-access-application-cluster) 获取更多信息。
|
||||
|
||||
<!--
|
||||
By default images run in the background, similar to `docker run -d ...`. To run things in the foreground, use:
|
||||
<!--
|
||||
By default images run in the background, similar to `docker run -d ...`. To run things in the foreground, use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to create pod:
|
||||
-->
|
||||
默认情况下镜像会在后台运行，与 `docker run -d ...` 类似，如果您想在前台运行，使用:
|
||||
默认情况下镜像会在后台运行，与 `docker run -d ...` 类似，如果您想在前台运行，使用 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) 在前台运行 Pod:
|
||||
|
||||
```shell
|
||||
kubectl run [-i] [--tty] --attach <name> --image=<image>
|
||||
|
||||
@@ -1,33 +1,63 @@
|
||||
---
|
||||
# title: Overview of kubeadm
|
||||
title: kubeadm 概述
|
||||
weight: 10
|
||||
card:
|
||||
name: reference
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- luxas
|
||||
- jbeda
|
||||
title: Overview of kubeadm
|
||||
weight: 10
|
||||
card:
|
||||
name: reference
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">
|
||||
<!-- Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters. -->
|
||||
<!--
|
||||
Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters.
|
||||
-->
|
||||
Kubeadm 是一个工具，它提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令作为快速创建 kubernetes 集群的最佳实践。
|
||||
|
||||
<!-- kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope. -->
|
||||
<!--
|
||||
kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.
|
||||
-->
|
||||
kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群。它被故意设计为只关心启动集群，而不是准备节点环境的工作。同样的，诸如安装各种各样的可有可无的插件，例如 Kubernetes 控制面板、监控解决方案以及特定云提供商的插件，这些都不在它负责的范围。
|
||||
|
||||
<!-- Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters. -->
|
||||
<!--
|
||||
Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
|
||||
-->
|
||||
相反，我们期望由一个基于 kubeadm 从更高层设计的更加合适的工具来做这些事情；并且，理想情况下，使用 kubeadm 作为所有部署的基础将会使得创建一个符合期望的集群变得容易。
|
||||
|
||||
<!--
|
||||
## How to install
|
||||
|
||||
To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
|
||||
-->
|
||||
## 如何安装
|
||||
要安装 kubeadm，请参考[安装指南](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)。
|
||||
|
||||
## 接下可以做什么
|
||||
|
||||
<!-- * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes master node -->
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动一个 Kubernetes 主节点
|
||||
<!-- * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster -->
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动一个 Kubernetes 工作节点并且将其加入到集群
|
||||
<!-- * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version -->
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新一个 Kubernetes 集群到新版本
|
||||
<!-- * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` -->
|
||||
<!--
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes master node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
|
||||
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join`
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
|
||||
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
|
||||
-->
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动引导一个 Kubernetes 主节点
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动引导一个 Kubernetes 工作节点并且将其加入到集群
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新 Kubernetes 集群到新版本
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用 kubeadm v1.7.x 或者更低版本，你需要对你的集群做一些配置以便使用 `kubeadm upgrade` 命令
|
||||
<!-- * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` -->
|
||||
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 使用 `kubeadm join` 来管理令牌
|
||||
<!-- * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` -->
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原之前使用 `kubeadm init` 或者 `kubeadm join` 对节点产生的改变
|
||||
<!-- * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version -->
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原之前使用 `kubeadm init` 或者 `kubeadm join` 对节点所作改变
|
||||
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印出 kubeadm 版本
|
||||
<!-- * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community -->
|
||||
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) 预览一组可用的新功能以便从社区搜集反馈
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ main_menu: true
|
||||
weight: 20
|
||||
content_type: concept
|
||||
card:
|
||||
name: 设置
|
||||
name: setup
|
||||
weight: 20
|
||||
anchors:
|
||||
- anchor: "#learning-environment"
|
||||
@@ -15,7 +15,6 @@ card:
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- brendandburns
|
||||
- erictune
|
||||
@@ -33,7 +32,6 @@ card:
|
||||
title: Learning environment
|
||||
- anchor: "#production-environment"
|
||||
title: Production environment
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -373,9 +373,8 @@ Kubernetes 版本对应的 DEB 和 RPM 软件包是：
|
||||
| Package name | Description |
|
||||
|--------------|-------------|
|
||||
| `kubeadm` | 给 kubelet 安装 `/usr/bin/kubeadm` CLI 工具和 [kubelet 插件](#the-kubelet-drop-in-file-for-systemd)。 |
|
||||
| `kubelet` | 安装 `/usr/bin/kubelet` 二进制文件。 |
|
||||
| `kubelet` | 安装 `/usr/bin/kubelet` 二进制文件和 `/opt/cni/bin` CNI 二进制文件。 |
|
||||
| `kubectl` | 安装 `/usr/bin/kubectl` 二进制文件。 |
|
||||
| `kubernetes-cni` | 将官方的 CNI 二进制文件安装到 `/opt/cni/bin` 目录中 |
|
||||
| `cri-tools` | 从 [cri-tools git 仓库](https://github.com/kubernetes-incubator/cri-tools)中安装 `/usr/bin/crictl` 二进制文件。 |
|
||||
|
||||
|
||||
|
||||
+1
-1
@@ -486,7 +486,7 @@ CoreDNS 处于 `CrashLoopBackOff` 时的另一个原因是当 Kubernetes 中部
|
||||
Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
|
||||
the security of your cluster.
|
||||
-->
|
||||
**警告**：禁用 SELinux 或设置 `allowPrivilegeEscalation` 为 `true` 可能会损害集群的安全性。
|
||||
禁用 SELinux 或设置 `allowPrivilegeEscalation` 为 `true` 可能会损害集群的安全性。
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
|
||||
@@ -48,14 +48,9 @@ To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secr
|
||||
* [Kubernetes Operations](https://github.com/kubernetes/kops) - 生产级 K8s 的安装、升级和管理。支持在 AWS 运行 Debian、Ubuntu、CentOS 和 RHEL。
|
||||
|
||||
<!--
|
||||
* [CoreOS Tectonic](https://coreos.com/tectonic/) includes the open-source [Tectonic Installer](https://github.com/coreos/tectonic-installer) that creates Kubernetes clusters with Container Linux nodes on AWS.
|
||||
* [kube-aws](https://github.com/kubernetes-incubator/kube-aws), creates and manages Kubernetes clusters with [Flatcar Linux](https://www.flatcar-linux.org/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
|
||||
-->
|
||||
* [CoreOS Tectonic](https://coreos.com/tectonic/) 包括开源的 [Tectonic 安装程序](https://github.com/coreos/tectonic-installer)，它用于在 AWS 上创建带有 Container Linux 节点的 Kubernetes 集群。
|
||||
|
||||
<!--
|
||||
* CoreOS originated and the Kubernetes Incubator maintains [a CLI tool, kube-aws](https://github.com/kubernetes-incubator/kube-aws), that creates and manages Kubernetes clusters with [Container Linux](https://coreos.com/why/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
|
||||
-->
|
||||
* 起源于 CoreOS，Kubernetes Incubator 维护的 [CLI 工具， kube-aws ](https://github.com/kubernetes-incubator/kube-aws)，该工具使用 [Container Linux](https://coreos.com/why/) 节点创建和管理 Kubernetes 集群，它使用了 AWS 工具：EC2、CloudFormation 和 Autoscaling。
|
||||
* [kube-aws](https://github.com/kubernetes-incubator/kube-aws) 使用 [Flatcar Linux](https://www.flatcar-linux.org/) 节点创建和管理 Kubernetes 集群，它使用了 AWS 工具：EC2、CloudFormation 和 Autoscaling。
|
||||
|
||||
<!--
|
||||
* [KubeOne](https://github.com/kubermatic/kubeone) is an open source cluster lifecycle management tool that creates, upgrades and manages Kubernetes Highly-Available clusters.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -22,7 +22,10 @@ Specific cluster deployment tools may place additional restrictions on version s
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Supported versions
|
||||
-->
|
||||
## 版本支持策略
|
||||
|
||||
<!--
|
||||
Kubernetes versions are expressed as **x.y.z**,
|
||||
@@ -54,11 +57,16 @@ Minor releases occur approximately every 3 months, so each minor release branch
|
||||
-->
|
||||
小版本大约每3个月发布一个，所以每个小版本分支会维护9个月。
|
||||
|
||||
<!--
|
||||
## Supported version skew
|
||||
-->
|
||||
## 版本倾斜策略
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
<!--
|
||||
In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
|
||||
-->
|
||||
在 [高可用（HA）集群](/docs/setup/production-environment/tools/kubeadm/high-availability/) 中，
|
||||
多个 `kube-apiserver` 实例小版本号最多差1。
|
||||
|
||||
@@ -109,7 +117,10 @@ Example:
|
||||
* 如果 `kube-apiserver` 的多个实例同时存在 **1.13** 和 **1.12**
|
||||
* `kubelet` 只能是 **1.12** 或 **1.11**（**1.13** 不再支持，因为它比**1.12**版本的 `kube-apiserver` 更新）
|
||||
|
||||
<!--
|
||||
### kube-controller-manager, kube-scheduler, and cloud-controller-manager
|
||||
-->
|
||||
### kube-controller-manager、 kube-scheduler 和 cloud-controller-manager
|
||||
|
||||
<!--
|
||||
`kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` must not be newer than the `kube-apiserver` instances they communicate with. They are expected to match the `kube-apiserver` minor version, but may be up to one minor version older (to allow live upgrades).
|
||||
@@ -232,7 +243,10 @@ require `kube-apiserver` to not skip minor versions when upgrading, even in sing
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### kube-controller-manager, kube-scheduler, and cloud-controller-manager
|
||||
-->
|
||||
### kube-controller-manager、 kube-scheduler 和 cloud-controller-manager
|
||||
|
||||
<!--
|
||||
Pre-requisites:
|
||||
|
||||
+254
-31
@@ -1,29 +1,67 @@
|
||||
---
|
||||
title: 配置对多集群的访问
|
||||
content_type: task
|
||||
card:
|
||||
name: tasks
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Configure Access to Multiple Clusters
|
||||
content_type: task
|
||||
weight: 30
|
||||
card:
|
||||
name: tasks
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page shows how to configure access to multiple clusters by using
|
||||
configuration files. After your clusters, users, and contexts are defined in
|
||||
one or more configuration files, you can quickly switch between clusters by using the
|
||||
`kubectl config use-context` command.
|
||||
-->
|
||||
本文展示如何使用配置文件来配置对多个集群的访问。 在将集群、用户和上下文定义在一个或多个配置文件中之后，用户可以使用 `kubectl config use-context` 命令快速地在集群之间进行切换。
|
||||
|
||||
<!--
|
||||
A file that is used to configure access to a cluster is sometimes 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 >}}
|
||||
用于配置集群访问的文件有时被称为 *kubeconfig 文件*。
|
||||
这是一种引用配置文件的通用方式，并不意味着存在一个名为 `kubeconfig` 的文件。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
需要安装 [`kubectl`](/docs/tasks/tools/install-kubectl/) 命令行工具。
|
||||
|
||||
|
||||
<!--
|
||||
To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed,
|
||||
run `kubectl version --client`. The kubectl version should be
|
||||
[within one minor version](/docs/setup/release/version-skew-policy/#kubectl) of your
|
||||
cluster's API server.
|
||||
-->
|
||||
要检查 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 是否安装，
|
||||
执行 `kubectl version --client` 命令。
|
||||
kubectl 的版本应该与集群的 API 服务器
|
||||
[使用同一次版本号](/docs/setup/release/version-skew-policy/#kubectl)。
|
||||
|
||||
<!-- steps -->
|
||||
<!--
|
||||
## Define clusters, users, and contexts
|
||||
|
||||
Suppose you have two clusters, one for development work and one for scratch work.
|
||||
In the `development` cluster, your frontend developers work in a namespace called `frontend`,
|
||||
and your storage developers work in a namespace called `storage`. In your `scratch` cluster,
|
||||
developers work in the default namespace, or they create auxiliary namespaces as they
|
||||
see fit. Access to the development cluster requires authentication by certificate. Access
|
||||
to the scratch cluster requires authentication by username and password.
|
||||
|
||||
Create a directory named `config-exercise`. In your
|
||||
`config-exercise` directory, create a file named `config-demo` with this content:
|
||||
-->
|
||||
## 定义集群、用户和上下文
|
||||
|
||||
假设用户有两个集群，一个用于正式开发工作，一个用于其它临时用途（scratch）。
|
||||
@@ -58,6 +96,14 @@ contexts:
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
<!--
|
||||
A configuration file describes clusters, users, and contexts. Your `config-demo` file
|
||||
has the framework to describe two clusters, two users, and three contexts.
|
||||
|
||||
Go to your `config-exercise` directory. Enter these commands to add cluster details to
|
||||
your configuration file:
|
||||
-->
|
||||
|
||||
配置文件描述了集群、用户名和上下文。 `config-demo` 文件中含有描述两个集群、两个用户和三个上下文的框架。
|
||||
|
||||
进入 `config-exercise` 目录。 输入以下命令，将群集详细信息添加到配置文件中：
|
||||
@@ -67,6 +113,9 @@ kubectl config --kubeconfig=config-demo set-cluster development --server=https:/
|
||||
kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify
|
||||
```
|
||||
|
||||
<!--
|
||||
Add user details to your configuration file:
|
||||
-->
|
||||
将用户详细信息添加到配置文件中：
|
||||
|
||||
```shell
|
||||
@@ -74,6 +123,20 @@ kubectl config --kubeconfig=config-demo set-credentials developer --client-certi
|
||||
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password
|
||||
```
|
||||
|
||||
<!--
|
||||
- To delete a user you can run `kubectl --kubeconfig=config-demo config unset users.<name>`
|
||||
- To remove a cluster, you can run `kubectl --kubeconfig=config-demo config unset clusters.<name>`
|
||||
- To remove a context, you can run `kubectl --kubeconfig=config-demo config unset contexts.<name>`
|
||||
-->
|
||||
|
||||
注意：
|
||||
- 要删除用户，可以运行 `kubectl --kubeconfig=config-demo config unset users.<name>`
|
||||
- 要删除集群，可以运行 `kubectl --kubeconfig=config-demo config unset clusters.<name>`
|
||||
- 要删除上下文，可以运行 `kubectl --kubeconfig=config-demo config unset contexts.<name>`
|
||||
|
||||
<!--
|
||||
Add context details to your configuration file:
|
||||
-->
|
||||
将上下文详细信息添加到配置文件中：
|
||||
|
||||
```shell
|
||||
@@ -82,12 +145,19 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo
|
||||
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
|
||||
```
|
||||
|
||||
<!--
|
||||
Open your `config-demo` file to see the added details. As an alternative to opening the
|
||||
`config-demo` file, you can use the `config view` command.
|
||||
-->
|
||||
打开 `config-demo` 文件查看添加的详细信息。 也可以使用 `config view` 命令进行查看：
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows the two clusters, two users, and three contexts:
|
||||
-->
|
||||
输出展示了两个集群、两个用户和三个上下文：
|
||||
|
||||
```yaml
|
||||
@@ -131,8 +201,32 @@ users:
|
||||
username: exp
|
||||
```
|
||||
|
||||
<!--
|
||||
The `fake-ca-file`, `fake-cert-file` and `fake-key-file` above are the placeholders
|
||||
for the pathnames of the certificate files. You need change these to the actual pathnames
|
||||
of certificate files in your environment.
|
||||
|
||||
Sometimes you may want to use Base64-encoded data embedded here instead of separate
|
||||
certificate files; in that case you need add the suffix `-data` to the keys, for example,
|
||||
`certificate-authority-data`, `client-certificate-data`, `client-key-data`.
|
||||
-->
|
||||
其中的 `fake-ca-file`、`fake-cert-file` 和 `fake-key-file` 是证书文件路径名的占位符。
|
||||
你需要更改这些值，使之对应你的环境中证书文件的实际路径名。
|
||||
|
||||
有时你可能希望在这里使用 BASE64 编码的数据而不是一个个独立的证书文件。
|
||||
如果是这样，你需要在键名上添加 `-data` 后缀。例如，
|
||||
`certificate-authority-data`、`client-certificate-data` 和 `client-key-data`。
|
||||
|
||||
<!--
|
||||
Each context is a triple (cluster, user, namespace). For example, the
|
||||
`dev-frontend` context says, "Use the credentials of the `developer`
|
||||
user to access the `frontend` namespace of the `development` cluster".
|
||||
|
||||
Set the current context:
|
||||
-->
|
||||
每个上下文包含三部分（集群、用户和名字空间），例如，
|
||||
`dev-frontend` 上下文表明：使用 `developer` 用户的凭证来访问 `development` 集群的 `frontend` 名字空间。
|
||||
`dev-frontend` 上下文表明：使用 `developer` 用户的凭证来访问 `development` 集群的
|
||||
`frontend` 名字空间。
|
||||
|
||||
设置当前上下文：
|
||||
|
||||
@@ -140,7 +234,16 @@ users:
|
||||
kubectl config --kubeconfig=config-demo use-context dev-frontend
|
||||
```
|
||||
|
||||
现在当输入 `kubectl` 命令时，相应动作会应用于 `dev-frontend` 上下文中所列的集群和名字空间，同时，命令会使用 `dev-frontend` 上下文中所列用户的凭证。
|
||||
<!--
|
||||
Now whenever you enter a `kubectl` command, the action will apply to the cluster,
|
||||
and namespace listed in the `dev-frontend` context. And the command will use
|
||||
the credentials of the user listed in the `dev-frontend` context.
|
||||
|
||||
To see only the configuration information associated with
|
||||
the current context, use the `--minify` flag.
|
||||
-->
|
||||
现在当输入 `kubectl` 命令时，相应动作会应用于 `dev-frontend` 上下文中所列的集群和名字空间，
|
||||
同时，命令会使用 `dev-frontend` 上下文中所列用户的凭证。
|
||||
|
||||
使用 `--minify` 参数，来查看与当前上下文相关联的配置信息。
|
||||
|
||||
@@ -148,6 +251,9 @@ kubectl config --kubeconfig=config-demo use-context dev-frontend
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows configuration information associated with the `dev-frontend` context:
|
||||
-->
|
||||
输出结果展示了 `dev-frontend` 上下文相关的配置信息：
|
||||
|
||||
```yaml
|
||||
@@ -173,6 +279,11 @@ users:
|
||||
client-key: fake-key-file
|
||||
```
|
||||
|
||||
<!--
|
||||
Now suppose you want to work for a while in the scratch cluster.
|
||||
|
||||
Change the current context to `exp-scratch`:
|
||||
-->
|
||||
现在假设用户希望在其它临时用途集群中工作一段时间。
|
||||
|
||||
将当前上下文更改为 `exp-scratch`：
|
||||
@@ -181,7 +292,16 @@ users:
|
||||
kubectl config --kubeconfig=config-demo use-context exp-scratch
|
||||
```
|
||||
|
||||
现在用户 `kubectl` 下达的任何命令都将应用于 `scratch` 集群的默认名字空间。 同时，命令会使用 `exp-scratch` 上下文中所列用户的凭证。
|
||||
<!--
|
||||
Now any `kubectl` command you give will apply to the default namespace of
|
||||
the `scratch` cluster. And the command will use the credentials of the user
|
||||
listed in the `exp-scratch` context.
|
||||
|
||||
View configuration associated with the new current context, `exp-scratch`.
|
||||
-->
|
||||
|
||||
现在你发出的所有 `kubectl` 命令都将应用于 `scratch` 集群的默认名字空间。
|
||||
同时，命令会使用 `exp-scratch` 上下文中所列用户的凭证。
|
||||
|
||||
查看更新后的当前上下文 `exp-scratch` 相关的配置：
|
||||
|
||||
@@ -189,6 +309,12 @@ kubectl config --kubeconfig=config-demo use-context exp-scratch
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
<!--
|
||||
Finally, suppose you want to work for a while in the `storage` namespace of the
|
||||
`development` cluster.
|
||||
|
||||
Change the current context to `dev-storage`:
|
||||
-->
|
||||
最后，假设用户希望在 `development` 集群中的 `storage` 名字空间下工作一段时间。
|
||||
|
||||
将当前上下文更改为 `dev-storage`：
|
||||
@@ -197,13 +323,21 @@ kubectl config --kubeconfig=config-demo view --minify
|
||||
kubectl config --kubeconfig=config-demo use-context dev-storage
|
||||
```
|
||||
|
||||
<!--
|
||||
View configuration associated with the new current context, `dev-storage`.
|
||||
-->
|
||||
查看更新后的当前上下文 `dev-storage` 相关的配置：
|
||||
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
<!--
|
||||
## Create a second configuration file
|
||||
|
||||
In your `config-exercise` directory, create a file named `config-demo-2` with this content:
|
||||
-->
|
||||
|
||||
## 创建第二个配置文件
|
||||
|
||||
在 `config-exercise` 目录中，创建名为 `config-demo-2` 的文件，其中包含以下内容：
|
||||
@@ -221,32 +355,77 @@ contexts:
|
||||
name: dev-ramp-up
|
||||
```
|
||||
|
||||
<!--
|
||||
The preceding configuration file defines a new context named `dev-ramp-up`.
|
||||
-->
|
||||
上述配置文件定义了一个新的上下文，名为 `dev-ramp-up`。
|
||||
|
||||
<!--
|
||||
## Set the KUBECONFIG environment variable
|
||||
|
||||
See whether you have an environment variable named `KUBECONFIG`. If so, save the
|
||||
current value of your `KUBECONFIG` environment variable, so you can restore it later.
|
||||
For example:
|
||||
-->
|
||||
## 设置 KUBECONFIG 环境变量
|
||||
|
||||
查看是否有名为 `KUBECONFIG` 的环境变量。 如有，保存 `KUBECONFIG` 环境变量当前的值，以便稍后恢复。
|
||||
例如，在 Linux 中：
|
||||
例如：
|
||||
|
||||
### Linux
|
||||
```shell
|
||||
export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
```
|
||||
|
||||
`KUBECONFIG` 环境变量是配置文件路径的列表，该列表在 Linux 和 Mac 中以冒号分隔，在 Windows 中以分号分隔。 如果有 `KUBECONFIG` 环境变量，请熟悉列表中的配置文件。
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
|
||||
```
|
||||
|
||||
临时添加两条路径到 `KUBECONFIG` 环境变量中。 例如，在 Linux 中：
|
||||
<!--
|
||||
The `KUBECONFIG` environment variable is a list of paths to configuration files. The list is
|
||||
colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you have
|
||||
a `KUBECONFIG` environment variable, familiarize yourself with the configuration files
|
||||
in the list.
|
||||
|
||||
Temporarily append two paths to your `KUBECONFIG` environment variable. For example:
|
||||
-->
|
||||
`KUBECONFIG` 环境变量是配置文件路径的列表，该列表在 Linux 和 Mac 中以冒号分隔，
|
||||
在 Windows 中以分号分隔。
|
||||
如果有 `KUBECONFIG` 环境变量，请熟悉列表中的配置文件。
|
||||
|
||||
临时添加两条路径到 `KUBECONFIG` 环境变量中。 例如：
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
|
||||
```shell
|
||||
$Env:KUBECONFIG=("config-demo;config-demo-2")
|
||||
```
|
||||
|
||||
<!--
|
||||
In your `config-exercise` directory, enter this command:
|
||||
-->
|
||||
在 `config-exercise` 目录中输入以下命令：
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
输出展示了 `KUBECONFIG` 环境变量中所列举的所有文件合并后的信息。 特别地， 注意合并信息中包含来自 `config-demo-2` 文件的 `dev-ramp-up` 上下文和来自 `config-demo` 文件的三个上下文：
|
||||
<!--
|
||||
The output shows merged information from all the files listed in your `KUBECONFIG`
|
||||
environment variable. In particular, notice that the merged information has the
|
||||
`dev-ramp-up` context from the `config-demo-2` file and the three contexts from
|
||||
the `config-demo` file:
|
||||
-->
|
||||
输出展示了 `KUBECONFIG` 环境变量中所列举的所有文件合并后的信息。
|
||||
特别地，注意合并信息中包含来自 `config-demo-2` 文件的 `dev-ramp-up` 上下文和来自
|
||||
`config-demo` 文件的三个上下文：
|
||||
|
||||
```yaml
|
||||
contexts:
|
||||
@@ -272,49 +451,93 @@ contexts:
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
更多关于 kubeconfig 文件如何合并的信息，请参考
|
||||
[使用 kubeconfig 文件组织集群访问](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
<!--
|
||||
For more information about how kubeconfig files are merged, see
|
||||
[Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
-->
|
||||
关于 kubeconfig 文件如何合并的更多信息，请参考
|
||||
[使用 kubeconfig 文件组织集群访问](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
|
||||
<!--
|
||||
## Explore the $HOME/.kube directory
|
||||
|
||||
If you already have a cluster, and you can use `kubectl` to interact with
|
||||
the cluster, then you probably have a file named `config` in the `$HOME/.kube`
|
||||
directory.
|
||||
|
||||
Go to `$HOME/.kube`, and see what files are there. Typically, there is a file named
|
||||
`config`. There might also be other configuration files in this directory. Briefly
|
||||
familiarize yourself with the contents of these files.
|
||||
-->
|
||||
## 探索 $HOME/.kube 目录
|
||||
|
||||
如果用户已经拥有一个集群，可以使用 `kubectl` 与集群进行交互。 那么很可能在 `$HOME/.kube` 目录下有一个名为 `config` 的文件。
|
||||
如果用户已经拥有一个集群，可以使用 `kubectl` 与集群进行交互，
|
||||
那么很可能在 `$HOME/.kube` 目录下有一个名为 `config` 的文件。
|
||||
|
||||
进入 `$HOME/.kube` 目录， 看看那里有什么文件。 通常会有一个名为
|
||||
`config` 的文件，目录中可能还有其他配置文件。 请简单地熟悉这些文件的内容。
|
||||
进入 `$HOME/.kube` 目录，看看那里有什么文件。通常会有一个名为
|
||||
`config` 的文件，目录中可能还有其他配置文件。请简单地熟悉这些文件的内容。
|
||||
|
||||
<!--
|
||||
## Append $HOME/.kube/config to your KUBECONFIG environment variable
|
||||
|
||||
If you have a `$HOME/.kube/config` file, and it's not already listed in your
|
||||
`KUBECONFIG` environment variable, append it to your `KUBECONFIG` environment variable now.
|
||||
For example:
|
||||
-->
|
||||
## 将 $HOME/.kube/config 追加到 KUBECONFIG 环境变量中
|
||||
|
||||
如果有 `$HOME/.kube/config` 文件，并且还未列在 `KUBECONFIG` 环境变量中，
|
||||
那么现在将它追加到 `KUBECONFIG` 环境变量中。
|
||||
例如，在 Linux 中：
|
||||
例如：
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
|
||||
```
|
||||
|
||||
在配置练习目录中输入以下命令，来查看当前 `KUBECONFIG` 环境变量中列举的所有文件合并后的配置信息：
|
||||
### Windows Powershell
|
||||
|
||||
```shell
|
||||
$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
|
||||
```
|
||||
|
||||
<!--
|
||||
View configuration information merged from all the files that are now listed
|
||||
in your `KUBECONFIG` environment variable. In your config-exercise directory, enter:
|
||||
-->
|
||||
在配置练习目录中输入以下命令，查看当前 `KUBECONFIG` 环境变量中列举的所有文件合并后的配置信息：
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
<!--
|
||||
## Clean up
|
||||
|
||||
Return your `KUBECONFIG` environment variable to its original value. For example:
|
||||
-->
|
||||
## 清理
|
||||
|
||||
将 `KUBECONFIG` 环境变量还原为原始值。 例如，在 Linux 中：
|
||||
将 `KUBECONFIG` 环境变量还原为原始值。 例如：
|
||||
|
||||
### Linux
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
-->
|
||||
|
||||
* [使用 kubeconfig 文件组织集群访问](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl 配置](/docs/user-guide/kubectl/{{< param "version" >}}/)
|
||||
|
||||
|
||||
|
||||
|
||||
* [使用 kubeconfig 文件组织集群访问](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: "扩展 Kubernetes"
|
||||
weight: 90
|
||||
---
|
||||
@@ -37,7 +37,7 @@ content_type: task
|
||||
为了查看 Kubernetes 网络策略是怎样工作的，可以从创建一个`nginx` deployment 并且通过服务将其暴露开始
|
||||
|
||||
```console
|
||||
$ kubectl run nginx --image=nginx --replicas=2
|
||||
$ kubectl create deployment nginx --image=nginx
|
||||
deployment "nginx" created
|
||||
$ kubectl expose deployment nginx --port=80
|
||||
service "nginx" exposed
|
||||
@@ -54,7 +54,6 @@ svc/nginx 10.100.0.16 <none> 80/TCP 33s
|
||||
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
po/nginx-701339712-e0qfq 1/1 Running 0 35s
|
||||
po/nginx-701339712-o00ef 1/1 Running 0 35s
|
||||
```
|
||||
|
||||
|
||||
|
||||
@@ -1,51 +1,27 @@
|
||||
---
|
||||
translator:
|
||||
- nicksu
|
||||
reviewers:
|
||||
- bowei
|
||||
- zihongz
|
||||
title: Debug DNS 方案
|
||||
title: 调试 DNS 问题
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!--
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This page provides hints on diagnosing DNS problems.
|
||||
|
||||
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
这篇文章提供了一些关于 DNS 问题诊断的方法。
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* Kubernetes version 1.6 and above.
|
||||
* The cluster must be configured to use the `coredns` (or `kube-dns`) addons.
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
-->
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!-- ZH: The following include shortcode misbehaves even when inside a HTML
|
||||
comment. This may be a generic problem to be fixed.-->
|
||||
|
||||
- {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
- Kubernetes 1.6 或者以上版本。
|
||||
- 集群必须使用了 `coredns` (或者 `kube-dns`)插件。
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
<!--
|
||||
|
||||
### Create a simple Pod to use as a test environment
|
||||
|
||||
Create a file named busybox.yaml with the following contents:
|
||||
@@ -62,7 +38,6 @@ kubectl get pods busybox
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
busybox 1/1 Running 0 <some-time>
|
||||
```
|
||||
|
||||
-->
|
||||
|
||||
### 创建一个简单的 Pod 作为测试环境
|
||||
@@ -134,7 +109,6 @@ search default.svc.cluster.local svc.cluster.local cluster.local google.internal
|
||||
nameserver 10.0.0.10
|
||||
options ndots:5
|
||||
```
|
||||
|
||||
-->
|
||||
|
||||
### 先检查本地的 DNS 配置
|
||||
|
||||
@@ -127,6 +127,13 @@ See the [design doc](https://git.k8s.io/community/contributors/design-proposals/
|
||||
|
||||
## 创建命名空间
|
||||
|
||||
<!--
|
||||
Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
|
||||
-->
|
||||
{{< note >}}
|
||||
避免使用前缀 `kube-` 创建命名空间，因为它是为 Kubernetes 系统命名空间保留的。
|
||||
{{< /note >}}
|
||||
|
||||
<!-- 1. Create a new YAML file called `my-namespace.yaml` with the contents: -->
|
||||
|
||||
1. 新建一个名为 `my-namespace.yaml` 的 YAML 文件，并写入下列内容：
|
||||
|
||||
+2
-2
@@ -457,7 +457,7 @@ to 1 second. Minimum value is 1.
|
||||
* `successThreshold`: Minimum consecutive successes for the probe to be
|
||||
considered successful after having failed. Defaults to 1. Must be 1 for
|
||||
liveness. Minimum value is 1.
|
||||
* `failureThreshold`: When a Pod starts and the probe fails, Kubernetes will
|
||||
* `failureThreshold`: When a probe fails, Kubernetes will
|
||||
try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready.
|
||||
Defaults to 3. Minimum value is 1.
|
||||
-->
|
||||
@@ -465,7 +465,7 @@ Defaults to 3. Minimum value is 1.
|
||||
* `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
|
||||
* `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
|
||||
* `successThreshold`：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。存活探测的这个值必须是 1。最小值是 1。
|
||||
* `failureThreshold`：当 Pod 启动了并且探测到失败，Kubernetes 的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
|
||||
* `failureThreshold`：当探测失败时，Kubernetes 的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
|
||||
|
||||
<!--
|
||||
[HTTP probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
|
||||
|
||||
@@ -6,14 +6,14 @@ card:
|
||||
name: tasks
|
||||
weight: 50
|
||||
---
|
||||
<!-- ---
|
||||
<!--
|
||||
title: Configure a Pod to Use a ConfigMap
|
||||
content_type: task
|
||||
weight: 150
|
||||
card:
|
||||
name: tasks
|
||||
weight: 50
|
||||
--- -->
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!-- ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps. -->
|
||||
|
||||
@@ -234,6 +234,6 @@ For further details, see [Kubernetes Audit Events][falco_ka_docs] in the Falco d
|
||||
[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml
|
||||
[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit
|
||||
[falco_installation]: https://falco.org/docs/installation
|
||||
[falco_helm_chart]: https://github.com/helm/charts/tree/master/stable/falco
|
||||
[falco_helm_chart]: https://github.com/falcosecurity/charts/tree/master/falco
|
||||
|
||||
|
||||
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "扩展 Kubernetes"
|
||||
description: 了解针对工作环境需要来调整 Kubernetes 集群的进阶方法
|
||||
weight: 90
|
||||
---
|
||||
@@ -35,8 +35,7 @@ on general patterns for running stateful applications in Kubernetes. -->
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
<!-- * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
* {{< include "default-storage-class-prereqs.md" >}}
|
||||
<!--
|
||||
* This tutorial assumes you are familiar with
|
||||
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
|
||||
and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
|
||||
|
||||
@@ -1,20 +1,24 @@
|
||||
---
|
||||
reviewers:
|
||||
- mikedanese
|
||||
title: 安装并设置 kubectl
|
||||
title: 安装并配置 kubectl
|
||||
content_type: task
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 20
|
||||
title: 安装 kubectl
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- bgrant0607
|
||||
- mikedanese
|
||||
title: Install and Set Up kubectl
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
card:
|
||||
name: tasks
|
||||
weight: 20
|
||||
title: Install kubectl
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
Use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), to deploy and manage applications on Kubernetes. Using kubectl, you can inspect cluster resources; create, delete, and update components; look at your new cluster; and bring up example apps.
|
||||
@@ -104,7 +108,7 @@ If you are on Ubuntu or one of other Linux distributions that support [snap](htt
|
||||
2. Test to ensure the version you installed is sufficiently up-to-date:
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
-->
|
||||
## 在 Ubuntu 上使用 snap 安装 kubectl
|
||||
@@ -120,7 +124,7 @@ If you are on Ubuntu or one of other Linux distributions that support [snap](htt
|
||||
2. 测试以确保您安装的版本是最新的：
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -137,7 +141,7 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you
|
||||
2. Test to ensure the version you installed is sufficiently up-to-date:
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
-->
|
||||
## <span id = "jump"> 在 macOS 上用 Homebrew 安装 kubectl </span>
|
||||
@@ -153,7 +157,7 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you
|
||||
2. 测试以确保您安装的版本是最新的：
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
|
||||
@@ -171,7 +175,7 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
|
||||
2. Test to ensure the version you installed is sufficiently up-to-date:
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
-->
|
||||
|
||||
@@ -188,7 +192,7 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
|
||||
2. 测试以确保您安装的版本是最新的：
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -212,7 +216,7 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
|
||||
2. Test to ensure the version you installed is sufficiently up-to-date:
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
@@ -238,7 +242,7 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
|
||||
|
||||
2. 测试以确保您安装的版本是最新的：
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
@@ -259,7 +263,7 @@ If you are on Windows and using [Chocolatey](https://chocolatey.org) package man
|
||||
2. Test to ensure the version you installed is sufficiently up-to-date:
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
3. Change to your %HOME% directory:
|
||||
|
||||
@@ -300,7 +304,7 @@ If you are on Windows and using [Chocolatey](https://chocolatey.org) package man
|
||||
2. 测试以确保您安装的版本是最新的：
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
3. 切换到 %HOME% 目录：
|
||||
|
||||
@@ -343,7 +347,7 @@ You can install kubectl as part of the Google Cloud SDK.
|
||||
3. Test to ensure the version you installed is sufficiently up-to-date:
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
-->
|
||||
## 将 kubectl 作为 Google Cloud SDK 的一部分下载
|
||||
@@ -360,7 +364,7 @@ kubectl 可以作为 Google Cloud SDK 的一部分进行安装。
|
||||
3. 测试以确保您安装的版本是最新的：
|
||||
|
||||
```
|
||||
kubectl version
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
@@ -393,18 +393,23 @@ To confirm successful installation of both a hypervisor and Minikube, you can ru
|
||||
|
||||
要确认 hypervisor 和 Minikube 均已成功安装，可以运行以下命令来启动本地 Kubernetes 集群：
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
For setting the `--vm-driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--vm-driver` values is available in [specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
|
||||
-->
|
||||
|
||||
通过 `minikube start` 设置 `--vm-driver`。在下面提到 `<driver_name>` 的地方，用小写字母，输入你安装的 hypervisor 的名称。
|
||||
[指定 VM 驱动程序](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver) 列举了 `--vm-driver` 值的完整列表
|
||||
{{< note >}}
|
||||
若要为 `minikube start` 设置 `--vm-driver`，在下面提到 `<driver_name>` 的地方，用小写字母输入你安装的 hypervisor 的名称。
|
||||
[指定 VM 驱动程序](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver) 列举了 `--vm-driver` 值的完整列表。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
由于国内无法直接连接 k8s.gcr.io，推荐使用阿里云镜像仓库，在 `minikube start` 中添加 `--image-repository` 参数。
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
minikube start --vm-driver=<driver_name>
|
||||
# Or when you need
|
||||
minikube start --vm-driver=<driver_name> --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers
|
||||
```
|
||||
|
||||
<!--
|
||||
@@ -482,4 +487,3 @@ minikube delete
|
||||
-->
|
||||
|
||||
* [使用 Minikube 在本地运行 Kubernetes](/docs/setup/learning-environment/minikube/)
|
||||
|
||||
|
||||
@@ -136,7 +136,7 @@ the configuration was correctly applied:
|
||||
使用 `kubectl exec` 进入 pod 并运行 `redis-cli` 工具来验证配置已正确应用：
|
||||
|
||||
```shell
|
||||
kubectl exec -it redis redis-cli
|
||||
kubectl exec -it redis -- redis-cli
|
||||
127.0.0.1:6379> CONFIG GET maxmemory
|
||||
1) "maxmemory"
|
||||
2) "2097152"
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 交互式教程 - 部署应用程序
|
||||
title: 交互式教程 - 部署应用
|
||||
weight: 20
|
||||
---
|
||||
|
||||
@@ -42,4 +42,4 @@ weight: 20
|
||||
</div>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
</html>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 交互式教程-探索您的应用程序
|
||||
title: 交互式教程-了解你的应用
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 交互式教程 - 发布您的应用程序
|
||||
title: 交互式教程 - 暴露你的应用
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: Using a Service to Expose Your App
|
||||
<!--title: Using a Service to Expose Your App-->
|
||||
title: 使用 Service 暴露您的应用
|
||||
weight: 10
|
||||
---
|
||||
|
||||
@@ -17,42 +18,61 @@ weight: 10
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<h3>Objectives</h3>
|
||||
<!-- <h3>Objectives</h3>-->
|
||||
<h3>目标</h3>
|
||||
<ul>
|
||||
<li>Learn about a Service in Kubernetes</li>
|
||||
<li>Understand how labels and LabelSelector objects relate to a Service</li>
|
||||
<li>Expose an application outside a Kubernetes cluster using a Service</li>
|
||||
<!-- <li>Learn about a Service in Kubernetes</li>-->
|
||||
<!-- <li>Understand how labels and LabelSelector objects relate to a Service</li>-->
|
||||
<!-- <li>Expose an application outside a Kubernetes cluster using a Service</li>-->
|
||||
<li>了解 Kubernetes 中的 Service </li>
|
||||
<li>了解 标签(Label) 和 标签选择器(Label Selector) 对象如何与 Service 关联</li>
|
||||
<li>在 Kubernetes 集群外用 Service 暴露应用</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="col-md-8">
|
||||
<h3>Overview of Kubernetes Services</h3>
|
||||
<!-- <h3>Overview of Kubernetes Services</h3>-->
|
||||
<h3>Kubernetes Service 总览</h3>
|
||||
|
||||
<p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>
|
||||
<!-- <p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>-->
|
||||
<p> Kubernetes <a href="/zh/docs/concepts/workloads/pods/pod-overview/">Pod</a> 是转瞬即逝的。 Pod 实际上拥有 <a href="/zh/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 <a href="/zh/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。</p>
|
||||
|
||||
<p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>
|
||||
<!-- <p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>-->
|
||||
<p> Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML <a href="/zh/docs/concepts/configuration/overview/#general-configuration-tips">(更推荐)</a> 或者 JSON 来定义. Service 下的一组 Pod 通常由 <i>LabelSelector</i> (请参阅下面的说明为什么您可能想要一个 spec 中不包含<code>selector</code>的服务)来标记。</p>
|
||||
|
||||
<p>Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>
|
||||
<!-- <p>Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>-->
|
||||
<p>尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service ，这些 IP 不会暴露在群集外部。Service 允许您的应用程序接收流量。Service 也可以用在 ServiceSpec 标记<code>type</code>的方式暴露</p>
|
||||
<ul>
|
||||
<li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>
|
||||
<li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code><NodeIP>:<NodePort></code>. Superset of ClusterIP.</li>
|
||||
<li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>
|
||||
<li><i>ExternalName</i> - Exposes the Service using an arbitrary name (specified by <code>externalName</code> in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of <code>kube-dns</code>.</li>
|
||||
<!-- <li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>-->
|
||||
<!-- <li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code><NodeIP>:<NodePort></code>. Superset of ClusterIP.</li>-->
|
||||
<!-- <li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>-->
|
||||
<!-- <li><i>ExternalName</i> - Exposes the Service using an arbitrary name (specified by <code>externalName</code> in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of <code>kube-dns</code>.</li>-->
|
||||
<li><i>ClusterIP</i> (默认) - 在集群的内部 IP 上公开 Service 。这种类型使得 Service 只能从集群内访问。</li>
|
||||
<li><i>NodePort</i> - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用<code><NodeIP>:<NodePort></code> 从集群外部访问 Service。是 ClusterIP 的超集。</li>
|
||||
<li><i>LoadBalancer</i> - 在当前云中创建一个外部负载均衡器(如果支持的话)，并为 Service 分配一个固定的外部IP。是 NodePort 的超集。</li>
|
||||
<li><i>ExternalName</i> - 通过返回带有该名称的 CNAME 记录，使用任意名称(由 spec 中的<code>externalName</code>指定)公开 Service。不使用代理。这种类型需要<code>kube-dns</code>的v1.7或更高版本。</li>
|
||||
</ul>
|
||||
<p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>
|
||||
<p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>
|
||||
<!-- <p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>-->
|
||||
<p>更多关于不同 Service 类型的信息可以在<a href="/zh/docs/tutorials/services/source-ip/">使用源 IP </a> 教程。 也请参阅 <a href="/zh/docs/concepts/services-networking/connect-applications-service">连接应用程序和 Service </a>。</p>
|
||||
<!-- <p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>-->
|
||||
<p>另外，需要注意的是有一些 Service 的用例没有在 spec 中定义<code>selector</code>。 一个没有<code>selector</code>创建的 Service 也不会创建相应的端点对象。这允许用户手动将服务映射到特定的端点。没有 selector 的另一种可能是您严格使用<code>type: ExternalName</code>来标记。</p>
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
<div class="content__box content__box_lined">
|
||||
<h3>Summary</h3>
|
||||
<!-- <h3>Summary</h3>-->
|
||||
<h3>总结</h3>
|
||||
<ul>
|
||||
<li>Exposing Pods to external traffic</li>
|
||||
<li>Load balancing traffic across multiple Pods</li>
|
||||
<li>Using labels</li>
|
||||
<!-- <li>Exposing Pods to external traffic</li>-->
|
||||
<!-- <li>Load balancing traffic across multiple Pods</li>-->
|
||||
<!-- <li>Using labels</li>-->
|
||||
<li>将 Pod 暴露给外部通信</li>
|
||||
<li>跨多个 Pod 的负载均衡</li>
|
||||
<li>使用标签(Label)</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="content__box content__box_fill">
|
||||
<p><i>A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</i></p>
|
||||
<!-- <p><i>A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</i></p>-->
|
||||
<p><i>Kubernetes 的 Service 是一个抽象层，它定义了一组 Pod 的逻辑集，并为这些 Pod 支持外部流量暴露、负载平衡和服务发现。</i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -60,7 +80,7 @@ weight: 10
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<h3>Services and Labels</h3>
|
||||
<h3>Service 和 Label</h3>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -72,18 +92,24 @@ weight: 10
|
||||
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p>A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.</p>
|
||||
<p>Services match a set of Pods using <a href="/docs/concepts/overview/working-with-objects/labels">labels and selectors</a>, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:</p>
|
||||
<!-- <p>A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.</p>-->
|
||||
<p>Service 通过一组 Pod 路由通信。Service 是一种抽象，它允许 Pod 死亡并在 Kubernetes 中复制，而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。</p>
|
||||
<!-- <p>Services match a set of Pods using <a href="/docs/concepts/overview/working-with-objects/labels">labels and selectors</a>, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:</p>-->
|
||||
<p>Service 匹配一组 Pod 是使用 <a href="/zh/docs/concepts/overview/working-with-objects/labels">标签(Label)和选择器(Selector)</a>, 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对，可以以多种方式使用:</p>
|
||||
<ul>
|
||||
<li>Designate objects for development, test, and production</li>
|
||||
<li>Embed version tags</li>
|
||||
<li>Classify an object using tags</li>
|
||||
<!-- <li>Designate objects for development, test, and production</li>-->
|
||||
<!-- <li>Embed version tags</li>-->
|
||||
<!-- <li>Classify an object using tags</li>-->
|
||||
<li>指定用于开发，测试和生产的对象</li>
|
||||
<li>嵌入版本标签</li>
|
||||
<li>使用 Label 将对象进行分类</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
<div class="content__box content__box_fill">
|
||||
<p><i>You can create a Service at the same time you create a Deployment by using<br><code>--expose</code> in kubectl.</i></p>
|
||||
<!-- <p><i>You can create a Service at the same time you create a Deployment by using<br><code>--expose</code> in kubectl.</i></p>-->
|
||||
<p><i>你也可以在创建 Deployment 的同时用 <code>--expose</code>创建一个 Service 。</i></p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -98,13 +124,15 @@ weight: 10
|
||||
<br>
|
||||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p>Labels can be attached to objects at creation time or later on. They can be modified at any time. Let's expose our application now using a Service and apply some labels.</p>
|
||||
<!-- <p>Labels can be attached to objects at creation time or later on. They can be modified at any time. Let's expose our application now using a Service and apply some labels.</p>-->
|
||||
<p> 标签(Label)可以在创建时或之后附加到对象上。他们可以随时被修改。现在使用 Service 发布我们的应用程序并添加一些 Label 。</p>
|
||||
</div>
|
||||
</div>
|
||||
<br>
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">Start Interactive Tutorial<span class="btn__next">›</span></a>
|
||||
<!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">Start Interactive Tutorial<span class="btn__next">›</span></a>-->
|
||||
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">开始交互式教程<span class="btn__next">›</span></a>
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
---
|
||||
title: 伸缩您的应用
|
||||
title: 缩放你的应用
|
||||
weight: 50
|
||||
---
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 交互教程 - 缩放你的应用程序
|
||||
title: 交互教程 - 缩放你的应用
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 交互式教程 - 更新应用
|
||||
title: 交互式教程 - 更新你的应用
|
||||
weight: 20
|
||||
---
|
||||
<!--
|
||||
|
||||
@@ -97,19 +97,19 @@ weight: 10
|
||||
<li data-target="#myCarousel" data-slide-to="3"></li>
|
||||
</ol>
|
||||
<div class="carousel-inner" role="listbox">
|
||||
<div class="item active">
|
||||
<div class="item carousel-item active">
|
||||
<img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg" >
|
||||
</div>
|
||||
|
||||
<div class="item">
|
||||
<div class="item carousel-item">
|
||||
<img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg">
|
||||
</div>
|
||||
|
||||
<div class="item">
|
||||
<div class="item carousel-item">
|
||||
<img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg">
|
||||
</div>
|
||||
|
||||
<div class="item">
|
||||
<div class="item carousel-item">
|
||||
<img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg">
|
||||
</div>
|
||||
</div>
|
||||
|
||||
+12
-4
@@ -1,15 +1,23 @@
|
||||
---
|
||||
title: 示例：使用 Persistent Volumes 部署 WordPress 和 MySQL
|
||||
reviewers:
|
||||
- ahmetb
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 40
|
||||
title: "Stateful 示例: Wordpress with Persistent Volumes"
|
||||
title: "有状态应用示例: 带持久卷的 Wordpress"
|
||||
---
|
||||
|
||||
<!--
|
||||
title: "Example: Deploying WordPress and MySQL with Persistent Volumes"
|
||||
reviewers:
|
||||
- ahmetb
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 40
|
||||
title: "Stateful Example: Wordpress with Persistent Volumes"
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
|
||||
@@ -1,19 +1,23 @@
|
||||
---
|
||||
title: "示例：使用 Redis 部署 PHP 留言板应用程序"
|
||||
reviewers:
|
||||
- ahmetb
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 30
|
||||
title: "无状态应用示例：基于 Redis 的 PHP Guestbook"
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Example: Deploying PHP Guestbook application with Redis"
|
||||
reviewers:
|
||||
- ahmetb
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
---
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 30
|
||||
title: "Stateless Example: PHP Guestbook with Redis"
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Reference in New Issue
Block a user