2.3. 使用命令行部署工作负载
您可以使用命令行部署 OpenShift 沙盒容器工作负载。
2.3.1. 可选:使用 Local Storage Operator 置备本地块卷
OpenShift 沙盒容器的本地块卷可以使用 Local Storage Operator (LSO)来置备。本地卷置备程序会在定义的资源中指定的路径上查找任何块设备。
先决条件
- 安装了 Local Storage Operator。
您有一个满足以下条件的本地磁盘:
- 它附加到一个节点。
- 它尚未挂载。
- 它不包含分区。
流程
创建本地卷资源。此资源必须定义本地卷的节点和路径。
注意不要在同一设备中使用不同的存储类名称。这样做可创建多个持久性卷 (PV)。
例如:Block
apiVersion: "local.storage.openshift.io/v1" kind: "LocalVolume" metadata: name: "local-disks" namespace: "openshift-local-storage" 1 spec: nodeSelector: 2 nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - ip-10-0-136-143 - ip-10-0-140-255 - ip-10-0-144-180 storageClassDevices: - storageClassName: "local-sc" 3 forceWipeDevicesAndDestroyAllData: false 4 volumeMode: Block devicePaths: 5 - /path/to/device 6
- 1
- 安装了 Local Storage Operator 的命名空间。
- 2
- 可选:包含附加了本地存储卷的节点列表的节点选择器。本例使用从
oc get node
获取的节点主机名。如果没有定义值,则 Local Storage Operator 会尝试在所有可用节点上查找匹配的磁盘。 - 3
- 创建持久性卷对象时使用的存储类的名称。
- 4
- 此设置定义是否调用
wipefs
,它会删除分区表签名(魔法字符串),使磁盘准备好用于 Local Storage Operator 置备。除了签名外,没有其它数据会被清除。默认为 "false" (不调用wipefs
)。当在需要重新使用的磁盘中,将forceWipeDevicesAndDestroyAllData
设置为 "true" 很有用。在这些情况下,将此字段设置为 true 可消除管理员手动擦除磁盘的需要。 - 5
- 包含要从中选择的本地存储设备列表的路径。在块设备上部署沙盒容器节点时,您必须使用此路径。
- 6
- 使用到
LocalVolume
资源by-id
的实际本地磁盘文件路径(如/dev/disk/by-id/wwn
)替换这个值。当置备程序已被成功部署时,会为这些本地磁盘创建 PV。
在 OpenShift Container Platform 集群中创建本地卷资源。指定您刚才创建的文件:
$ oc create -f <local-volume>.yaml
验证置备程序是否已创建并创建了相应的守护进程集:
$ oc get all -n openshift-local-storage
输出示例
NAME READY STATUS RESTARTS AGE pod/diskmaker-manager-9wzms 1/1 Running 0 5m43s pod/diskmaker-manager-jgvjp 1/1 Running 0 5m43s pod/diskmaker-manager-tbdsj 1/1 Running 0 5m43s pod/local-storage-operator-7db4bd9f79-t6k87 1/1 Running 0 14m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/local-storage-operator-metrics ClusterIP 172.30.135.36 <none> 8383/TCP,8686/TCP 14m NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/diskmaker-manager 3 3 3 3 3 <none> 5m43s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/local-storage-operator 1/1 1 1 14m NAME DESIRED CURRENT READY AGE replicaset.apps/local-storage-operator-7db4bd9f79 1 1 1 14m
请注意
所需的
和当前的
守护进程设定进程数。所需的
数量为0
表示标签选择器无效。验证持久性卷是否已创建:
$ oc get pv
输出示例
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE local-pv-1cec77cf 100Gi RWO Delete Available local-sc 88m local-pv-2ef7cd2a 100Gi RWO Delete Available local-sc 82m local-pv-3fa1c73 100Gi RWO Delete Available local-sc 48m
编辑 LocalVolume
对象不会更改现有的持久性卷,因为这样做可能会导致破坏性操作。
2.3.2. 可选:在块设备上部署节点
如果为 OpenShift 沙盒容器置备本地块卷,您可以选择在定义的卷资源中指定的路径上部署节点。
先决条件
- 已使用 Local Storage Operator 置备块设备
流程
- 对您要使用块设备部署的每个节点运行以下命令:
$ oc debug node/worker-0 -- chcon -vt container_file_t /host/path/to/device
+ /path/to/device
必须是您在创建本地存储资源时定义的相同路径。
+ .输出示例
system_u:object_r:container_file_t:s0 /host/path/to/device
2.3.3. 创建 KataConfig 自定义资源
您必须创建一个 KataConfig
自定义资源(CR)来作为 worker 节点上的运行时类安装 kata
。
创建 KataConfig
CR 会触发 OpenShift 沙盒容器 Operator 来执行以下操作:
-
在 RHCOS 节点上安装所需的 RHCOS 扩展,如 QEMU 和
kata-containers
。 - 确保 CRI-O 运行时配置了正确的运行时处理程序。
-
使用默认配置创建一个名为
kata
的RuntimeClass
CR。这可让用户在RuntimeClassName
字段中引用 CR 将工作负载配置为使用kata
作为运行时。此 CR 也指定运行时的资源开销。
OpenShift 沙盒容器将 kata
作为集群中的辅助 可选运行时安装,而不是作为主要运行时。
创建 KataConfig
CR 会自动重启 worker 节点。重启可能需要 10 到 60 分钟。妨碍重启时间的因素如下:
- 带有更多 worker 节点的大型 OpenShift Container Platform 部署。
- 激活 BIOS 和 Diagnostics 实用程序。
- 在硬盘而不是 SSD 上部署。
- 在物理节点上部署,如裸机,而不是在虚拟节点上部署。
- CPU 和网络较慢。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 - 可选:如果要启用节点资格检查,已安装了 Node Feature Discovery Operator。
流程
根据以下示例创建
cluster-kataconfig.yaml
清单文件:apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: checkNodeEligibility: false 1 logLevel: info
- 1
- 可选:将'checkNodeEligibility' 设置为
true
以运行节点资格检查。
可选: 要在所选节点上安装
kata
,请按照以下示例指定节点标签:apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: kataConfigPoolSelector: matchLabels: <label_key>: '<label_value>' 1 # ...
- 1
- 指定所选节点的标签。
创建
KataConfig
CR:$ oc create -f cluster-kataconfig.yaml
新的
KataConfig
CR 会被创建,并在 worker 节点上作为运行时类安装kata
。在验证安装前,等待
kata
安装完成,以及 worker 节点重新引导。
验证
运行以下命令监控安装进度:
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
当安装
kataNodes
下的所有 worker 的状态并且条件InProgress
为False
时,如果没有指定原因,则会在集群中安装kata
。
详情请参阅 KataConfig 状态信息。
2.3.4. 可选:修改 pod 开销
Pod 开销描述了节点上 pod 使用的系统资源量。您可以通过更改 RuntimeClass
自定义资源的 spec.overhead
字段来修改 pod 开销。例如,如果您为容器运行的配置消耗 QEMU 进程和客户机内核数据的 350Mi 内存,您可以更改 RuntimeClass
开销来满足您的需要。
在客户机中执行任何类型的文件系统 I/O 时,将在客户机内核中分配文件缓冲区。文件缓冲区也在主机上的 QEMU 进程以及 virtiofsd
进程中映射。
例如,如果您在客户机中使用 300Mi 文件缓冲区缓存,QEMU 和 virtiofsd
都显示使用 300Mi 额外内存。但是,所有三种情况下都使用相同的内存。因此,内存使用总量仅为 300Mi,映射在三个不同的位置。报告内存使用率指标时,会正确计算。
红帽支持默认值。不支持更改默认开销值,这可能会导致技术问题。
流程
运行以下命令来获取
RuntimeClass
对象:$ oc describe runtimeclass kata
更新
overhead.podFixed.memory
和cpu
值,保存为RuntimeClass.yaml
:kind: RuntimeClass apiVersion: node.k8s.io/v1 metadata: name: kata overhead: podFixed: memory: "500Mi" cpu: "500m"
2.3.5. 配置工作负载对象
您可以通过将 kata
配置为以下 pod 模板对象的运行时类来部署 OpenShift 沙盒容器工作负载:
-
Pod
对象 -
ReplicaSet
对象 -
ReplicationController
对象 -
StatefulSet
对象 -
Deployment
对象 -
deploymentConfig
对象
不要在 openshift-sandboxed-containers-operator
命名空间中部署工作负载。为这些资源创建一个专用命名空间。
先决条件
- 您已为供应商创建了 secret 对象。
- 您已为供应商创建了配置映射。
-
您已创建了
KataConfig
自定义资源 (CR)。
流程
将
spec.runtimeClassName: kata
添加到每个 pod 模板工作负载对象的清单中,如下例所示:apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata # ...
OpenShift Container Platform 创建工作负载对象并开始调度它。
验证
-
检查 pod 模板对象的
spec.runtimeClassName
字段。如果值为kata
,则工作负载在 OpenShift 沙盒容器中运行,使用对等 pod。