第 3 章 使用对等 pod 部署 OpenShift 沙盒容器工作负载
您可以使用 Web 控制台或 OpenShift CLI(oc
)安装 OpenShift 沙盒容器 Operator。在安装 OpenShift 沙盒容器 Operator 之前,您必须准备 Red Hat OpenShift 集群。
使用对等 pod 部署 OpenShift 沙盒容器工作负载只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
3.1. 先决条件
在安装 OpenShift 沙盒容器并启用对等 pod 之前,您必须满足以下要求:
- 您已在 AWS 或 Azure 上安装 Red Hat OpenShift 4.13。
-
已安装 OpenShift CLI(
oc
)。 - 您可以使用具有 cluster-admin 角色的用户访问集群。
3.1.1. 关于 OpenShift 沙盒容器中的对等 pod 资源要求
对等 pod 使用两个位置的资源:
-
worker 节点。worker 节点存储元数据、Kata shim 资源(
containerd-shim-kata-v2
)、remote-hypervisor 资源(cloud-api-adaptor
),以及 worker 节点和 peer-pod 虚拟机(VM)之间的隧道设置。 - 云实例。这是在云中运行的实际 peer-pod 虚拟机。
Kubernetes worker 节点中使用的 CPU 和内存资源由用于创建对等 pod 的 RuntimeClass (kata-remote
)定义中的 pod 开销 处理。
云中运行的 peer-pod 虚拟机总数定义为 Kubernetes 节点扩展资源。这个限制是每个节点,由 peerpodConfig
自定义资源(CR)中的 limit
属性设置。在创建 kataConfig
CR 并启用对等 pod 时,会创建名为 peerpodconfig-openshift
的 peerpodConfig
CR,并位于 openshift-sandboxed-containers-operator
命名空间中。
以下 peerpodConfig
CR 示例显示默认的 spec
值:
apiVersion: confidentialcontainers.org/v1alpha1
kind: PeerPodConfig
metadata:
name: peerpodconfig-openshift
namespace: openshift-sandboxed-containers-operator
spec:
cloudSecretName: peer-pods-secret
configMapName: peer-pods-cm
limit: "10" 1
nodeSelector:
node-role.kubernetes.io/kata-oc: ""
- 1
- 默认限制为每个节点 10 个虚拟机。
扩展资源名为 kata.peerpods.io/vm
,并允许 Kubernetes 调度程序处理容量跟踪和核算。
您可以根据环境的要求编辑每个节点的限制。如需更多信息 ,请参阅修改对等 pod 中的每个节点的虚拟机限制。
变异 Webhook 将扩展的资源 kata.peerpods.io/vm
添加到 pod 规格中。如果存在,它还会从 pod 规格中删除任何特定于资源的条目。这可让 Kubernetes 调度程序考虑这些扩展资源,确保仅在资源可用时调度 peer-pod。
变异 Webhook 修改 Kubernetes pod,如下所示:
-
变异 Webhook 会检查 pod 是否有预期的
RuntimeClassName
值,在TARGET_RUNTIME_CLASS
环境变量中指定。如果 pod 规格中的值与TARGET_RUNTIME_CLASS
的值不匹配,则 Webhook 会在不修改 pod 的情况下退出。 如果
RuntimeClassName
值匹配,webhook 会对 pod 规格进行以下更改:-
Webhook 从 pod 中所有容器和 init 容器的
resources
字段中删除每个资源规格。 -
Webhook 通过修改 pod 中第一个容器的 resources 字段,将扩展资源(
kata.peerpods.io/vm
)添加到 spec。Kubernetes 调度程序使用扩展资源kata.peerpods.io/vm
用于核算目的。
-
Webhook 从 pod 中所有容器和 init 容器的
变异 Webhook 排除了 Red Hat OpenShift 中的特定系统命名空间。如果在这些系统命名空间中创建了一个 peer-pod,则使用 Kubernetes 扩展资源的资源核算无法正常工作,除非 pod 规格包含扩展的资源。
作为最佳实践,请定义一个集群范围的策略,仅允许在特定命名空间中创建对等 pod。
3.1.1.1. 修改每个节点的对等 pod VM 限制
您可以通过编辑 peerpodConfig
自定义资源(CR)来更改每个节点的对等 pod 虚拟机限制。
流程
运行以下命令检查当前的限制:
$ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \ -o jsonpath='{.spec.limit}{"\n"}'
运行以下命令,修改
peerpodConfig
CR 的limit
属性:$ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \ --type merge --patch '{"spec":{"limit":"<value>"}}' 1
- 1
- 将 <value> 替换为您要定义的限制。
3.1.2. 使用 AWS 的 peer-pods 的先决条件
如果使用 AWS 创建对等 pod,您必须确保以下要求:
- 您的 Red Hat OpenShift 集群必须安装在 AWS 上,至少有一个 worker 节点。
-
您可以访问
AWS_ACCESS_KEY_ID
和AWS_SECRET_ACCESS_KEY
凭据。它们用于在集群的同一虚拟私有云(VPC)中创建额外的云实例。 - 您必须安装并配置 AWS CLI 工具。
您必须在端口 15150 和 9000 上启用内部集群通信。
您可以在 AWS Web 控制台或使用 CLI 中启用这些端口。
3.1.2.1. 为 AWS 启用端口 15150 和 9000
流程
检索实例 ID:
$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
检索 AWS 区域:
$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')
检索安全组:
$ SG=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --output text --region ${AWS_REGION})
授权 peer-pods shim 并访问 kata-agent 通信。运行以下命令:
$ aws ec2 authorize-security-group-ingress --group-id ${SG} --protocol tcp --port 15150 --source-group ${SG} --region ${AWS_REGION}
设置 peer-pods 隧道。运行以下命令:
$ aws ec2 authorize-security-group-ingress --group-id ${SG} --protocol tcp --port 9000 --source-group ${SG} --region ${AWS_REGION}
现在启用这些端口。
3.1.3. 使用 Azure 的 peer-pods 的先决条件
如果使用 Microsoft Azure 创建对等 pod,您必须确保以下要求:
- 您的 Red Hat OpenShift 集群必须安装在 Azure 上,至少有一个 worker 节点。
您可以访问以下凭证和订阅详情:
-
AZURE_SUBSCRIPTION_ID
-
AZURE_CLIENT_ID
-
AZURE_CLIENT_SECRET
-
AZURE_TENANT_ID
它们用于在集群的同一虚拟私有云(VPC)中创建额外的云实例。
-
- 已安装并配置了 Azure CLI 工具。
您必须在端口 15150 和 9000 上启用集群通信。
在 Azure 中,这些端口上允许内部通信。但是,如果通信被阻止,您可以在 Azure web 控制台中或使用 CLI 启用端口。
3.1.3.1. 为 Azure 启用端口 15150 和 9000
流程
检索实例 ID:
$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
检索 Azure 资源组:
$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}')
检索 Azure 网络安全组(NSG)名称:
$ AZURE_NSG_NAME=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
检索 Azure VNet 名称:
$ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
检索 Azure 子网名称:
$ AZURE_SUBNET_NAME=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name ${AZURE_VNET_NAME} --query "[].{Name:name} | [? contains(Name, 'worker')]" --output tsv)
检索 Azure 子网前缀:
$ AZURE_SUBNET_PREFIX=$(az network vnet subnet show --name ${AZURE_SUBNET_NAME} --vnet-name ${AZURE_VNET_NAME} --resource-group ${AZURE_RESOURCE_GROUP} --query "addressPrefix" --output tsv)
授权 peer-pods shim 访问 kata-agent 通信。运行以下命令:
$ az network nsg rule create \ --resource-group $AZURE_RESOURCE_GROUP \ --nsg-name $AZURE_NSG_NAME \ --name Allow-Kata-Agent-Internal \ --access Allow \ --protocol Tcp \ --direction Inbound \ --priority 112 \ --source-address-prefixes $AZURE_SUBNET_PREFIX \ --source-port-range "*" \ --destination-address-prefixes $AZURE_SUBNET_PREFIX \ --destination-port-range 15150
设置 peer-pods 隧道。运行以下命令:
$ az network nsg rule create \ --resource-group $AZURE_RESOURCE_GROUP \ --nsg-name $AZURE_NSG_NAME \ --name Allow-VXLAN-Internal \ --access Allow \ --protocol Tcp \ --direction Inbound \ --priority 111 \ --source-address-prefixes $AZURE_SUBNET_PREFIX \ --source-port-range "*" \ --destination-address-prefixes $AZURE_SUBNET_PREFIX \ --destination-port-range 9000
现在启用这些端口。