[zh-cn] localize dra alpha blog
Co-Authored-By: Qiming Teng <tengqm@outlook.com> Co-Authored-By: Michael <haifeng.yao@daocloud.io>pull/38868/head
ktKongTong
parent
f6d2b10b9a
commit
90bb3ccd31
|
|
@ -0,0 +1,552 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "Kubernetes 1.26: 动态资源分配 Alpha API"
|
||||
date: 2022-12-15
|
||||
slug: dynamic-resource-allocation
|
||||
---
|
||||
<!--
|
||||
layout: blog
|
||||
title: "Kubernetes 1.26: Alpha API For Dynamic Resource Allocation"
|
||||
date: 2022-12-15
|
||||
slug: dynamic-resource-allocation
|
||||
-->
|
||||
|
||||
<!--
|
||||
**Authors:** Patrick Ohly (Intel), Kevin Klues (NVIDIA)
|
||||
-->
|
||||
**作者:** Patrick Ohly (Intel)、Kevin Klues (NVIDIA)
|
||||
|
||||
**译者：** 空桐
|
||||
|
||||
<!--
|
||||
Dynamic resource allocation is a new API for requesting resources. It is a
|
||||
generalization of the persistent volumes API for generic resources, making it possible to:
|
||||
|
||||
- access the same resource instance in different pods and containers,
|
||||
- attach arbitrary constraints to a resource request to get the exact resource
|
||||
you are looking for,
|
||||
- initialize a resource according to parameters provided by the user.
|
||||
-->
|
||||
动态资源分配是一个用于请求资源的新 API。
|
||||
它是对为通用资源所提供的持久卷 API 的泛化。它可以：
|
||||
|
||||
- 在不同的 pod 和容器中访问相同的资源实例，
|
||||
- 将任意约束附加到资源请求以获取你正在寻找的确切资源，
|
||||
- 通过用户提供的参数初始化资源。
|
||||
|
||||
<!--
|
||||
Third-party resource drivers are responsible for interpreting these parameters
|
||||
as well as tracking and allocating resources as requests come in.
|
||||
-->
|
||||
第三方资源驱动程序负责解释这些参数，并在资源请求到来时跟踪和分配资源。
|
||||
|
||||
<!--
|
||||
Dynamic resource allocation is an *alpha feature* and only enabled when the
|
||||
`DynamicResourceAllocation` [feature
|
||||
gate](/docs/reference/command-line-tools-reference/feature-gates/) and the
|
||||
`resource.k8s.io/v1alpha1` {{< glossary_tooltip text="API group"
|
||||
term_id="api-group" >}} are enabled. For details, see the
|
||||
`--feature-gates` and `--runtime-config` [kube-apiserver
|
||||
parameters](/docs/reference/command-line-tools-reference/kube-apiserver/).
|
||||
The kube-scheduler, kube-controller-manager and kubelet components all need
|
||||
the feature gate enabled as well.
|
||||
-->
|
||||
动态资源分配是一个 **alpha 特性**，只有在启用 `DynamicResourceAllocation`
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
和 `resource.k8s.io/v1alpha1` {{< glossary_tooltip text="API 组"
|
||||
term_id="api-group" >}} 时才启用。
|
||||
有关详细信息，参阅 `--feature-gates` 和 `--runtime-config`
|
||||
[kube-apiserver 参数](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)。
|
||||
kube-scheduler、kube-controller-manager 和 kubelet 也需要设置该特性门控。
|
||||
|
||||
<!--
|
||||
The default configuration of kube-scheduler enables the `DynamicResources`
|
||||
plugin if and only if the feature gate is enabled. Custom configurations may
|
||||
have to be modified to include it.
|
||||
-->
|
||||
kube-scheduler 的默认配置仅在启用特性门控时才启用 `DynamicResources` 插件。
|
||||
自定义配置可能需要被修改才能启用它。
|
||||
|
||||
<!--
|
||||
Once dynamic resource allocation is enabled, resource drivers can be installed
|
||||
to manage certain kinds of hardware. Kubernetes has a test driver that is used
|
||||
for end-to-end testing, but also can be run manually. See
|
||||
[below](#running-the-test-driver) for step-by-step instructions.
|
||||
-->
|
||||
一旦启用动态资源分配，就可以安装资源驱动程序来管理某些类型的硬件。
|
||||
Kubernetes 有一个用于端到端测试的测试驱动程序，但也可以手动运行。
|
||||
逐步说明参见[下文](#running-the-test-driver)。
|
||||
|
||||
<!--
|
||||
## API
|
||||
-->
|
||||
## API
|
||||
|
||||
<!--
|
||||
The new `resource.k8s.io/v1alpha1` {{< glossary_tooltip text="API group"
|
||||
term_id="api-group" >}} provides four new types:
|
||||
-->
|
||||
新的 `resource.k8s.io/v1alpha1`
|
||||
{{< glossary_tooltip text="API 组" term_id="api-group" >}}提供了四种新类型：
|
||||
|
||||
<!--
|
||||
ResourceClass
|
||||
: Defines which resource driver handles a certain kind of
|
||||
resource and provides common parameters for it. ResourceClasses
|
||||
are created by a cluster administrator when installing a resource
|
||||
driver.
|
||||
|
||||
ResourceClaim
|
||||
: Defines a particular resource instances that is required by a
|
||||
workload. Created by a user (lifecycle managed manually, can be shared
|
||||
between different Pods) or for individual Pods by the control plane based on
|
||||
a ResourceClaimTemplate (automatic lifecycle, typically used by just one
|
||||
Pod).
|
||||
-->
|
||||
ResourceClass
|
||||
: 定义由哪个资源驱动程序处理哪种资源，并为其提供通用参数。
|
||||
在安装资源驱动程序时，由集群管理员创建 ResourceClass。
|
||||
|
||||
ResourceClaim
|
||||
: 定义工作负载所需的特定资源实例。
|
||||
由用户创建（手动管理生命周期，可以在不同的 Pod 之间共享），
|
||||
或者由控制平面基于 ResourceClaimTemplate 为特定 Pod 创建
|
||||
（自动管理生命周期，通常仅由一个 Pod 使用）。
|
||||
|
||||
<!--
|
||||
ResourceClaimTemplate
|
||||
: Defines the spec and some meta data for creating
|
||||
ResourceClaims. Created by a user when deploying a workload.
|
||||
|
||||
PodScheduling
|
||||
: Used internally by the control plane and resource drivers
|
||||
to coordinate pod scheduling when ResourceClaims need to be allocated
|
||||
for a Pod.
|
||||
-->
|
||||
ResourceClaimTemplate
|
||||
: 定义用于创建 ResourceClaim 的 spec 和一些元数据。
|
||||
部署工作负载时由用户创建。
|
||||
|
||||
PodScheduling
|
||||
: 供控制平面和资源驱动程序内部使用，
|
||||
在需要为 Pod 分配 ResourceClaim 时协调 Pod 调度。
|
||||
|
||||
<!--
|
||||
Parameters for ResourceClass and ResourceClaim are stored in separate objects,
|
||||
typically using the type defined by a {{< glossary_tooltip
|
||||
term_id="CustomResourceDefinition" text="CRD" >}} that was created when
|
||||
installing a resource driver.
|
||||
-->
|
||||
ResourceClass 和 ResourceClaim 的参数存储在单独的对象中，
|
||||
通常使用安装资源驱动程序时创建的 {{< glossary_tooltip
|
||||
term_id="CustomResourceDefinition" text="CRD" >}} 所定义的类型。
|
||||
|
||||
<!--
|
||||
With this alpha feature enabled, the `spec` of Pod defines ResourceClaims that are needed for a Pod
|
||||
to run: this information goes into a new
|
||||
`resourceClaims` field. Entries in that list reference either a ResourceClaim
|
||||
or a ResourceClaimTemplate. When referencing a ResourceClaim, all Pods using
|
||||
this `.spec` (for example, inside a Deployment or StatefulSet) share the same
|
||||
ResourceClaim instance. When referencing a ResourceClaimTemplate, each Pod gets
|
||||
its own ResourceClaim instance.
|
||||
-->
|
||||
启用此 Alpha 特性后，Pod 的 `spec` 定义 Pod 运行所需的 ResourceClaim：
|
||||
此信息放入新的 `resourceClaims` 字段。
|
||||
该列表中的条目引用 ResourceClaim 或 ResourceClaimTemplate。
|
||||
当引用 ResourceClaim 时，使用此 `.spec` 的所有 Pod
|
||||
（例如 Deployment 或 StatefulSet 中的 Pod）共享相同的 ResourceClaim 实例。
|
||||
引用 ResourceClaimTemplate 时，每个 Pod 都有自己的实例。
|
||||
|
||||
<!--
|
||||
For a container defined within a Pod, the `resources.claims` list
|
||||
defines whether that container gets
|
||||
access to these resource instances, which makes it possible to share resources
|
||||
between one or more containers inside the same Pod. For example, an init container could
|
||||
set up the resource before the application uses it.
|
||||
-->
|
||||
对于 Pod 中定义的容器，`resources.claims` 列表定义该容器可以访问的资源实例，
|
||||
从而可以在同一 Pod 中的一个或多个容器之间共享资源。
|
||||
例如，init 容器可以在应用程序使用资源之前设置资源。
|
||||
|
||||
<!--
|
||||
Here is an example of a fictional resource driver. Two ResourceClaim objects
|
||||
will get created for this Pod and each container gets access to one of them.
|
||||
|
||||
Assuming a resource driver called `resource-driver.example.com` was installed
|
||||
together with the following resource class:
|
||||
-->
|
||||
下面是一个虚构的资源驱动程序的示例。
|
||||
此 Pod 将创建两个 ResourceClaim 对象，每个容器都可以访问其中一个。
|
||||
|
||||
假设已安装名为 `resource-driver.example.com` 的资源驱动程序和以下资源类：
|
||||
```
|
||||
apiVersion: resource.k8s.io/v1alpha1
|
||||
kind: ResourceClass
|
||||
name: resource.example.com
|
||||
driverName: resource-driver.example.com
|
||||
```
|
||||
|
||||
<!--
|
||||
An end-user could then allocate two specific resources of type
|
||||
`resource.example.com` as follows:
|
||||
-->
|
||||
这样，终端用户可以按如下方式分配两个类型为
|
||||
`resource.example.com` 的特定资源：
|
||||
```yaml
|
||||
---
|
||||
apiVersion: cats.resource.example.com/v1
|
||||
kind: ClaimParameters
|
||||
name: large-black-cats
|
||||
spec:
|
||||
color: black
|
||||
size: large
|
||||
---
|
||||
apiVersion: resource.k8s.io/v1alpha1
|
||||
kind: ResourceClaimTemplate
|
||||
metadata:
|
||||
name: large-black-cats
|
||||
spec:
|
||||
spec:
|
||||
resourceClassName: resource.example.com
|
||||
parametersRef:
|
||||
apiGroup: cats.resource.example.com
|
||||
kind: ClaimParameters
|
||||
name: large-black-cats
|
||||
–--
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pod-with-cats
|
||||
spec:
|
||||
containers: # 两个示例容器；每个容器申领一个 cat 资源
|
||||
- name: first-example
|
||||
image: ubuntu:22.04
|
||||
command: ["sleep", "9999"]
|
||||
resources:
|
||||
claims:
|
||||
- name: cat-0
|
||||
- name: second-example
|
||||
image: ubuntu:22.04
|
||||
command: ["sleep", "9999"]
|
||||
resources:
|
||||
claims:
|
||||
- name: cat-1
|
||||
resourceClaims:
|
||||
- name: cat-0
|
||||
source:
|
||||
resourceClaimTemplateName: large-black-cats
|
||||
- name: cat-1
|
||||
source:
|
||||
resourceClaimTemplateName: large-black-cats
|
||||
```
|
||||
|
||||
<!--
|
||||
## Scheduling
|
||||
-->
|
||||
## 调度 {#scheduling}
|
||||
|
||||
<!--
|
||||
In contrast to native resources (such as CPU or RAM) and
|
||||
[extended resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources)
|
||||
(managed by a
|
||||
device plugin, advertised by kubelet), the scheduler has no knowledge of what
|
||||
dynamic resources are available in a cluster or how they could be split up to
|
||||
satisfy the requirements of a specific ResourceClaim. Resource drivers are
|
||||
responsible for that. Drivers mark ResourceClaims as _allocated_ once resources
|
||||
for it are reserved. This also then tells the scheduler where in the cluster a
|
||||
claimed resource is actually available.
|
||||
-->
|
||||
与原生资源（CPU、RAM）和[扩展资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources)
|
||||
（由设备插件管理，并由 kubelet 公布）不同，调度器不知道集群中有哪些动态资源，
|
||||
也不知道如何将它们拆分以满足特定 ResourceClaim 的要求。
|
||||
资源驱动程序负责这些任务。
|
||||
资源驱动程序在为 ResourceClaim 保留资源后将其标记为**已分配（Allocated）**。
|
||||
然后告诉调度器集群中可用的 ResourceClaim 的位置。
|
||||
|
||||
<!--
|
||||
ResourceClaims can get resources allocated as soon as the ResourceClaim
|
||||
is created (_immediate allocation_), without considering which Pods will use
|
||||
the resource. The default (_wait for first consumer_) is to delay allocation until
|
||||
a Pod that relies on the ResourceClaim becomes eligible for scheduling.
|
||||
This design with two allocation options is similar to how Kubernetes handles
|
||||
storage provisioning with PersistentVolumes and PersistentVolumeClaims.
|
||||
-->
|
||||
ResourceClaim 可以在创建时就进行分配（**立即分配**），不用考虑哪些 Pod 将使用该资源。
|
||||
默认情况下采用延迟分配（**等待第一个消费者**），
|
||||
直到依赖于 ResourceClaim 的 Pod 有资格调度时再进行分配。
|
||||
这种两种分配选项的设计与 Kubernetes 处理 PersistentVolume 和
|
||||
PersistentVolumeClaim 供应的存储类似。
|
||||
|
||||
<!--
|
||||
In the wait for first consumer mode, the scheduler checks all ResourceClaims needed
|
||||
by a Pod. If the Pods has any ResourceClaims, the scheduler creates a PodScheduling
|
||||
(a special object that requests scheduling details on behalf of the Pod). The PodScheduling
|
||||
has the same name and namespace as the Pod and the Pod as its as owner.
|
||||
Using its PodScheduling, the scheduler informs the resource drivers
|
||||
responsible for those ResourceClaims about nodes that the scheduler considers
|
||||
suitable for the Pod. The resource drivers respond by excluding nodes that
|
||||
don't have enough of the driver's resources left.
|
||||
-->
|
||||
在等待第一个消费者模式下，调度器检查 Pod 所需的所有 ResourceClaim。
|
||||
如果 Pod 有 ResourceClaim，则调度器会创建一个 PodScheduling
|
||||
对象（一种特殊对象，代表 Pod 请求调度详细信息）。
|
||||
PodScheduling 的名称和命名空间与 Pod 相同，Pod 是它的所有者。
|
||||
调度器使用 PodScheduling 通知负责这些 ResourceClaim
|
||||
的资源驱动程序，告知它们调度器认为适合该 Pod 的节点。
|
||||
资源驱动程序通过排除没有足够剩余资源的节点来响应调度器。
|
||||
|
||||
<!--
|
||||
Once the scheduler has that resource
|
||||
information, it selects one node and stores that choice in the PodScheduling
|
||||
object. The resource drivers then allocate resources based on the relevant
|
||||
ResourceClaims so that the resources will be available on that selected node.
|
||||
Once that resource allocation is complete, the scheduler attempts to schedule the Pod
|
||||
to a suitable node. Scheduling can still fail at this point; for example, a different Pod could
|
||||
be scheduled to the same node in the meantime. If this happens, already allocated
|
||||
ResourceClaims may get deallocated to enable scheduling onto a different node.
|
||||
-->
|
||||
一旦调度器有了资源信息，它就会选择一个节点，并将该选择存储在 PodScheduling 对象中。
|
||||
然后，资源驱动程序分配其 ResourceClaim，以便资源可用于选中的节点。
|
||||
一旦完成资源分配，调度器尝试将 Pod 调度到合适的节点。这时候调度仍然可能失败；
|
||||
例如，不同的 Pod 可能同时被调度到同一个节点。如果发生这种情况，已分配的
|
||||
ResourceClaim 可能会被取消分配，从而让 Pod 可以被调度到不同的节点。
|
||||
|
||||
<!--
|
||||
As part of this process, ResourceClaims also get reserved for the
|
||||
Pod. Currently ResourceClaims can either be used exclusively by a single Pod or
|
||||
an unlimited number of Pods.
|
||||
-->
|
||||
作为此过程的一部分，ResourceClaim 会为 Pod 保留。
|
||||
目前，ResourceClaim 可以由单个 Pod 独占使用或不限数量的多个 Pod 使用。
|
||||
|
||||
<!--
|
||||
One key feature is that Pods do not get scheduled to a node unless all of
|
||||
their resources are allocated and reserved. This avoids the scenario where
|
||||
a Pod gets scheduled onto one node and then cannot run there, which is bad
|
||||
because such a pending Pod also blocks all other resources like RAM or CPU that were
|
||||
set aside for it.
|
||||
-->
|
||||
除非 Pod 的所有资源都已分配和保留，否则 Pod 不会被调度到节点，这是一个重要特性。
|
||||
这避免了 Pod 被调度到一个节点但无法在那里运行的情况，
|
||||
这种情况很糟糕，因为被挂起 Pod 也会阻塞为其保留的其他资源，如 RAM 或 CPU。
|
||||
|
||||
<!--
|
||||
## Limitations
|
||||
-->
|
||||
## 限制 {#limitations}
|
||||
|
||||
<!--
|
||||
The scheduler plugin must be involved in scheduling Pods which use
|
||||
ResourceClaims. Bypassing the scheduler by setting the `nodeName` field leads
|
||||
to Pods that the kubelet refuses to start because the ResourceClaims are not
|
||||
reserved or not even allocated. It may be possible to remove this
|
||||
[limitation](https://github.com/kubernetes/kubernetes/issues/114005) in the
|
||||
future.
|
||||
-->
|
||||
调度器插件必须参与调度那些使用 ResourceClaim 的 Pod。
|
||||
通过设置 `nodeName` 字段绕过调度器会导致 kubelet 拒绝启动 Pod，
|
||||
因为 ResourceClaim 没有被保留或甚至根本没有被分配。
|
||||
未来可能去除此[限制](https://github.com/kubernetes/kubernetes/issues/114005)。
|
||||
|
||||
<!--
|
||||
## Writing a resource driver
|
||||
-->
|
||||
## 编写资源驱动程序 {#writing-a-resource-driver}
|
||||
|
||||
<!--
|
||||
A dynamic resource allocation driver typically consists of two separate-but-coordinating
|
||||
components: a centralized controller, and a DaemonSet of node-local kubelet
|
||||
plugins. Most of the work required by the centralized controller to coordinate
|
||||
with the scheduler can be handled by boilerplate code. Only the business logic
|
||||
required to actually allocate ResourceClaims against the ResourceClasses owned
|
||||
by the plugin needs to be customized. As such, Kubernetes provides
|
||||
the following package, including APIs for invoking this boilerplate code as
|
||||
well as a `Driver` interface that you can implement to provide their custom
|
||||
business logic:
|
||||
- [k8s.io/dynamic-resource-allocation/controller](https://github.com/kubernetes/dynamic-resource-allocation/tree/release-1.26/controller)
|
||||
-->
|
||||
动态资源分配驱动程序通常由两个独立但相互协调的组件组成：
|
||||
一个集中控制器和一个节点本地 kubelet 插件的 DaemonSet。
|
||||
集中控制器与调度器协调所需的大部分工作都可以由样板代码处理。
|
||||
只有针对插件所拥有的 ResourceClass 实际分配 ResourceClaim 时所需的业务逻辑才需要自定义。
|
||||
因此，Kubernetes 提供了以下软件包，其中包括用于调用此样板代码的 API，
|
||||
以及可以实现自定义业务逻辑的 `Driver` 接口：
|
||||
- [k8s.io/dynamic-resource-allocation/controller](https://github.com/kubernetes/dynamic-resource-allocation/tree/release-1.26/controller)
|
||||
|
||||
<!--
|
||||
Likewise, boilerplate code can be used to register the node-local plugin with
|
||||
the kubelet, as well as start a gRPC server to implement the kubelet plugin
|
||||
API. For drivers written in Go, the following package is recommended:
|
||||
- [k8s.io/dynamic-resource-allocation/kubeletplugin](https://github.com/kubernetes/dynamic-resource-allocation/tree/release-1.26/kubeletplugin)
|
||||
-->
|
||||
同样，样板代码可用于向 kubelet 注册节点本地插件，
|
||||
也可以启动 gRPC 服务器来实现 kubelet 插件 API。
|
||||
对于用 Go 编写的驱动程序，推荐使用以下软件包：
|
||||
- [k8s.io/dynamic-resource-allocation/kubeletplugin](https://github.com/kubernetes/dynamic-resource-allocation/tree/release-1.26/kubeletplugin)
|
||||
|
||||
<!--
|
||||
It is up to the driver developer to decide how these two components
|
||||
communicate. The [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md) outlines an [approach using
|
||||
CRDs](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/3063-dynamic-resource-allocation#implementing-a-plugin-for-node-resources).
|
||||
the KEP outlines an approach using CRDs.
|
||||
-->
|
||||
驱动程序开发人员决定这两个组件如何通信。
|
||||
[KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md)
|
||||
详细介绍了[使用 CRD 的方法](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/3063-dynamic-resource-allocation#implementing-a-plugin-for-node-resources)。
|
||||
|
||||
<!--
|
||||
Within SIG Node, we also plan to provide a complete [example
|
||||
driver](https://github.com/kubernetes-sigs/dra-example-driver) that can serve
|
||||
as a template for other drivers.
|
||||
-->
|
||||
在 SIG Node 中，我们还计划提供一个完整的[示例驱动程序](https://github.com/kubernetes-sigs/dra-example-driver)，
|
||||
它可以当作其他驱动程序的模板。
|
||||
|
||||
<!--
|
||||
## Running the test driver
|
||||
-->
|
||||
## 运行测试驱动程序 {#running-the-test-driver}
|
||||
|
||||
<!--
|
||||
The following steps bring up a local, one-node cluster directly from the
|
||||
Kubernetes source code. As a prerequisite, your cluster must have nodes with a container
|
||||
runtime that supports the
|
||||
[Container Device Interface](https://github.com/container-orchestrated-devices/container-device-interface)
|
||||
(CDI). For example, you can run CRI-O [v1.23.2](https://github.com/cri-o/cri-o/releases/tag/v1.23.2) or later.
|
||||
Once containerd v1.7.0 is released, we expect that you can run that or any later version.
|
||||
In the example below, we use CRI-O.
|
||||
-->
|
||||
下面的步骤直接使用 Kubernetes 源代码启一个本地单节点集群。
|
||||
前提是，你的集群必须具有支持[容器设备接口](https://github.com/container-orchestrated-devices/container-device-interface)
|
||||
（CDI）的容器运行时。
|
||||
例如，你可以运行 CRI-O [v1.23.2](https://github.com/cri-o/cri-o/releases/tag/v1.23.2)
|
||||
或更高版本。containerd v1.7.0 发布后，我们期望你可以运行该版本或更高版本。
|
||||
在下面的示例中，我们使用 CRI-O。
|
||||
|
||||
<!--
|
||||
First, clone the Kubernetes source code. Inside that directory, run:
|
||||
-->
|
||||
首先，克隆 Kubernetes 源代码。在其目录中，运行：
|
||||
```console
|
||||
$ hack/install-etcd.sh
|
||||
...
|
||||
|
||||
$ RUNTIME_CONFIG=resource.k8s.io/v1alpha1 \
|
||||
FEATURE_GATES=DynamicResourceAllocation=true \
|
||||
DNS_ADDON="coredns" \
|
||||
CGROUP_DRIVER=systemd \
|
||||
CONTAINER_RUNTIME_ENDPOINT=unix:///var/run/crio/crio.sock \
|
||||
LOG_LEVEL=6 \
|
||||
ENABLE_CSI_SNAPSHOTTER=false \
|
||||
API_SECURE_PORT=6444 \
|
||||
ALLOW_PRIVILEGED=1 \
|
||||
PATH=$(pwd)/third_party/etcd:$PATH \
|
||||
./hack/local-up-cluster.sh -O
|
||||
...
|
||||
要使用集群，你可以打开另一个终端/选项卡并运行：
|
||||
export KUBECONFIG=/var/run/kubernetes/admin.kubeconfig
|
||||
...
|
||||
```
|
||||
|
||||
<!--
|
||||
Once the cluster is up, in another
|
||||
terminal run the test driver controller. `KUBECONFIG` must be set for all of
|
||||
the following commands.
|
||||
```console
|
||||
$ go run ./test/e2e/dra/test-driver --feature-gates ContextualLogging=true -v=5 controller
|
||||
```
|
||||
|
||||
In another terminal, run the kubelet plugin:
|
||||
```console
|
||||
$ sudo mkdir -p /var/run/cdi && \
|
||||
sudo chmod a+rwx /var/run/cdi /var/lib/kubelet/plugins_registry /var/lib/kubelet/plugins/
|
||||
$ go run ./test/e2e/dra/test-driver --feature-gates ContextualLogging=true -v=6 kubelet-plugin
|
||||
```
|
||||
-->
|
||||
集群启动后，在另一个终端运行测试驱动程序控制器。
|
||||
必须为以下所有命令设置 `KUBECONFIG`。
|
||||
```console
|
||||
$ go run ./test/e2e/dra/test-driver --feature-gates ContextualLogging=true -v=5 controller
|
||||
```
|
||||
|
||||
在另一个终端中，运行 kubelet 插件：
|
||||
```console
|
||||
$ sudo mkdir -p /var/run/cdi && \
|
||||
sudo chmod a+rwx /var/run/cdi /var/lib/kubelet/plugins_registry /var/lib/kubelet/plugins/
|
||||
$ go run ./test/e2e/dra/test-driver --feature-gates ContextualLogging=true -v=6 kubelet-plugin
|
||||
```
|
||||
|
||||
<!--
|
||||
Changing the permissions of the directories makes it possible to run and (when
|
||||
using delve) debug the kubelet plugin as a normal user, which is convenient
|
||||
because it uses the already populated Go cache. Remember to restore permissions
|
||||
with `sudo chmod go-w` when done. Alternatively, you can also build the binary
|
||||
and run that as root.
|
||||
|
||||
Now the cluster is ready to create objects:
|
||||
-->
|
||||
更改目录的权限，这样可以以普通用户身份运行和（使用 delve）调试 kubelet 插件，
|
||||
这很方便，因为它使用已填充的 Go 缓存。
|
||||
完成后，记得使用 `sudo chmod go-w` 还原权限。
|
||||
或者，你也可以构建二进制文件并以 root 身份运行该二进制文件。
|
||||
|
||||
现在集群已准备好创建对象：
|
||||
```console
|
||||
$ kubectl create -f test/e2e/dra/test-driver/deploy/example/resourceclass.yaml
|
||||
resourceclass.resource.k8s.io/example created
|
||||
|
||||
$ kubectl create -f test/e2e/dra/test-driver/deploy/example/pod-inline.yaml
|
||||
configmap/test-inline-claim-parameters created
|
||||
resourceclaimtemplate.resource.k8s.io/test-inline-claim-template created
|
||||
pod/test-inline-claim created
|
||||
|
||||
$ kubectl get resourceclaims
|
||||
NAME RESOURCECLASSNAME ALLOCATIONMODE STATE AGE
|
||||
test-inline-claim-resource example WaitForFirstConsumer allocated,reserved 8s
|
||||
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
test-inline-claim 0/2 Completed 0 21s
|
||||
```
|
||||
|
||||
<!--
|
||||
The test driver doesn't do much, it only sets environment variables as defined
|
||||
in the ConfigMap. The test pod dumps the environment, so the log can be checked
|
||||
to verify that everything worked:
|
||||
-->
|
||||
这个测试驱动程序没有做什么事情，
|
||||
它只是将 ConfigMap 中定义的变量设为环境变量。
|
||||
测试 pod 会转储环境变量，所以可以检查日志以验证是否正常：
|
||||
```console
|
||||
$ kubectl logs test-inline-claim with-resource | grep user_a
|
||||
user_a='b'
|
||||
```
|
||||
<!--
|
||||
## Next steps
|
||||
-->
|
||||
## 下一步 {#next-steps}
|
||||
|
||||
<!--
|
||||
- See the
|
||||
[Dynamic Resource Allocation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md)
|
||||
KEP for more information on the design.
|
||||
- Read [Dynamic Resource Allocation](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
|
||||
in the official Kubernetes documentation.
|
||||
- You can participate in
|
||||
[SIG Node](https://github.com/kubernetes/community/blob/master/sig-node/README.md)
|
||||
and / or the [CNCF Container Orchestrated Device Working Group](https://github.com/cncf/tag-runtime/blob/master/wg/COD.md).
|
||||
- You can view or comment on the [project board](https://github.com/orgs/kubernetes/projects/95/views/1)
|
||||
for dynamic resource allocation.
|
||||
- In order to move this feature towards beta, we need feedback from hardware
|
||||
vendors, so here's a call to action: try out this feature, consider how it can help
|
||||
with problems that your users are having, and write resource drivers…
|
||||
-->
|
||||
- 了解更多该设计的信息，
|
||||
参阅[动态资源分配 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md)。
|
||||
- 阅读 Kubernetes 官方文档的[动态资源分配](/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)。
|
||||
- 你可以参与 [SIG Node](https://github.com/kubernetes/community/blob/master/sig-node/README.md)
|
||||
和 [CNCF 容器编排设备工作组](https://github.com/cncf/tag-runtime/blob/master/wg/COD.md)。
|
||||
- 你可以查看或评论动态资源分配的[项目看板](https://github.com/orgs/kubernetes/projects/95/views/1)。
|
||||
- 为了将该功能向 beta 版本推进，我们需要来自硬件供应商的反馈，
|
||||
因此，有一个行动号召：尝试这个功能，
|
||||
考虑它如何有助于解决你的用户遇到的问题，并编写资源驱动程序…
|
||||
Loading…
Reference in New Issue