3.3. CLI와 함께 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너 워크로드 배포
CLI를 사용하여 OpenShift 샌드박스 컨테이너 워크로드를 배포할 수 있습니다. 먼저 OpenShift 샌드박스 컨테이너 Operator를 설치한 다음 KataConfig
사용자 지정 리소스를 생성해야 합니다. 샌드박스 컨테이너에 워크로드를 배포할 준비가 되면 워크로드 YAML 파일에 kata-remote
를 runtimeClassName
으로 추가해야 합니다.
3.3.1. CLI를 사용하여 OpenShift 샌드박스 컨테이너 Operator 설치
OpenShift 샌드박스 컨테이너 Operator는 OpenShift Container Platform CLI를 사용하여 설치할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 4.15가 클러스터에 설치되어 있어야 합니다.
IBM Z 또는 IBM® LinuxONE에 설치하려면 OpenShift Container Platform 4.14 이상이 설치되어 있어야 합니다.
중요피어 Pod를 사용하여 IBM Z에 OpenShift 샌드박스 컨테이너 워크로드를 배포하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. OpenShift 샌드박스 컨테이너 카탈로그를 구독하고 있습니다.
참고OpenShift 샌드박스 컨테이너 카탈로그를 구독하면
openshift-sandboxed-containers-operator
네임스페이스에서 OpenShift 샌드박스 컨테이너 Operator에 액세스할 수 있습니다.
프로세스
OpenShift 샌드박스 컨테이너 Operator의
Namespace
오브젝트를 생성합니다.다음 매니페스트를 포함하는
Namespace
오브젝트 YAML 파일을 생성합니다.apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
Namespace
오브젝트를 생성합니다.$ oc create -f Namespace.yaml
OpenShift 샌드박스 컨테이너 Operator에 대한
OperatorGroup
오브젝트를 생성합니다.다음 매니페스트가 포함된
OperatorGroup
오브젝트 YAML 파일을 생성합니다.apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-sandboxed-containers-operator namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator
OperatorGroup
개체를 생성합니다.$ oc create -f OperatorGroup.yaml
서브스크립션
오브젝트를 생성하여 OpenShift 샌드박스 컨테이너 Operator에네임스페이스
를 등록합니다.다음 매니페스트가 포함된
서브스크립션
오브젝트 YAML 파일을 생성합니다.apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-sandboxed-containers-operator namespace: openshift-sandboxed-containers-operator spec: channel: stable installPlanApproval: Automatic name: sandboxed-containers-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: sandboxed-containers-operator.v1.5.3
Subscription
오브젝트를 생성합니다.$ oc create -f Subscription.yaml
OpenShift 샌드박스 컨테이너 Operator가 클러스터에 설치되었습니다.
위에 나열된 모든 오브젝트 파일 이름은 제안 사항입니다. 다른 이름을 사용하여 오브젝트 YAML 파일을 생성할 수 있습니다.
검증
Operator가 올바르게 설치되었는지 확인합니다.
$ oc get csv -n openshift-sandboxed-containers-operator
출력 예
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.5.3 1.5.2 Succeeded
추가 리소스
3.3.2. CLI를 사용하여 AWS의 피어 Pod 설정
AWS에서 사용할 피어 Pod를 설정하려면 시크릿 오브젝트, AMI(AWS 이미지 VM) 및 피어 포드 ConfigMap
을 생성해야 합니다.
AWS의 피어 Pod를 설정한 후에도 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 배포할 KataConfig
CR(사용자 정의 리소스)을 계속 생성해야 합니다.
사전 요구 사항
- 클러스터에 OpenShift Container Platform 4.15를 설치했습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.
3.3.2.1. CLI를 사용하여 AWS의 보안 오브젝트 생성
AWS 액세스 키를 설정하고 secret 오브젝트에서 네트워크를 구성합니다. secret 오브젝트는 Pod VM 이미지를 생성하고 피어 Pod에서 사용하는 데 사용됩니다.
AWS의 보안 오브젝트를 생성할 때 특정 환경 값을 설정해야 합니다. 보안 오브젝트를 생성하기 전에 이러한 값 중 일부를 검색할 수 있습니다. 그러나 다음과 같은 값을 준비해야 합니다.
-
AWS_ACCESS_KEY_ID
-
AWS_SECRET_ACCESS_KEY
이러한 값은 AWS 콘솔에서 생성할 수 있습니다.
프로세스
secret 오브젝트에 필요한 매개변수 값을 수집합니다. 각 값을 적어 둡니다.
인스턴스 ID를 검색합니다.
$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
이 값은 보안 오브젝트 자체에 필요하지 않지만 secret 오브젝트의 다른 값을 검색하는 데 사용됩니다.
AWS 리전을 검색합니다.
$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""
AWS 서브넷 ID를 검색합니다.
$ AWS_SUBNET_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SubnetId' --region ${AWS_REGION} --output text) && echo "AWS_SUBNET_ID: \"$AWS_SUBNET_ID\""
AWS VPC ID를 검색합니다.
$ AWS_VPC_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].VpcId' --region ${AWS_REGION} --output text) && echo "AWS_VPC_ID: \"$AWS_VPC_ID\""
AWS 보안 그룹 ID를 검색합니다.
$ AWS_SG_IDS=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --region $AWS_REGION --output json | jq -r '.[][][]' | paste -sd ",") && echo "AWS_SG_IDS: \"$AWS_SG_IDS\""
다음 매니페스트를 사용하여 YAML 파일을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AWS_ACCESS_KEY_ID: "<enter value>" 1 AWS_SECRET_ACCESS_KEY: "<enter value>" 2 AWS_REGION: "<enter value>" 3 AWS_SUBNET_ID: "<enter value>" 4 AWS_VPC_ID: "<enter value>" 5 AWS_SG_IDS: "<enter value>" 6
보안 오브젝트를 적용합니다.
$ oc apply -f peer-pods-secret.yaml
secret 오브젝트가 적용됩니다.
피어 Pod 시크릿을 업데이트하는 경우 변경 사항을 적용하려면 peerpodconfig-ctrl-caa-daemon
데몬 세트를 다시 시작해야 합니다.
시크릿을 업데이트한 후 매니페스트를 적용합니다. 그런 다음 다음 명령을 실행하여 cloud-api-adaptor
Pod를 다시 시작합니다.
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset을 다시 시작하면 피어 Pod가 다시 생성되고 기존 Pod는 업데이트되지 않습니다.
3.3.2.2. CLI를 사용하여 AWS의 피어 Pod ConfigMap 생성
AWS용 ConfigMap
을 생성할 때 AMI ID를 설정해야 합니다. ConfigMap
을 생성하기 전에 이 값을 검색할 수 있습니다.
프로세스
다음 매니페스트를 사용하여 YAML 파일을 생성합니다.
apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "aws" VXLAN_PORT: "9000" PODVM_INSTANCE_TYPE: "t3.medium" 1 PODVM_INSTANCE_TYPES: "t2.small,t2.medium,t3.large" 2 PROXY_TIMEOUT: "5m"
ConfigMap
을 적용합니다.$ oc apply -f peer-pods-cm.yaml
ConfigMap
이 적용됩니다.
피어 Pod 구성 맵을 업데이트하는 경우 변경 사항을 적용하려면 peerpodconfig-ctrl-caa-daemon
데몬 세트를 다시 시작해야 합니다.
구성 맵을 업데이트한 후 매니페스트를 적용합니다. 그런 다음 다음 명령을 실행하여 cloud-api-adaptor
Pod를 다시 시작합니다.
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset을 다시 시작하면 피어 Pod가 다시 생성되고 기존 Pod는 업데이트되지 않습니다.
KataConfig
CR을 생성하면 AWS에서 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 실행할 수 있습니다.
3.3.3. CLI를 사용하여 Azure의 피어 Pod 설정
Microsoft Azure에서 사용할 피어 Pod를 설정하려면 시크릿 오브젝트, Azure 이미지 VM, 피어 포드 ConfigMap
및 SSH 키 시크릿 오브젝트를 생성해야 합니다.
Azure의 피어 Pod를 설정한 후에도 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 배포하려면 KataConfig
CR(사용자 정의 리소스)을 생성해야 합니다.
사전 요구 사항
- 클러스터에 OpenShift Container Platform 4.15를 설치했습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.
- Azure CLI 툴이 설치 및 구성되어 있어야 합니다.
3.3.3.1. CLI를 사용하여 Azure의 보안 오브젝트 생성
Azure 액세스 키를 설정하고 시크릿 오브젝트에서 네트워크를 구성합니다. secret 오브젝트는 Pod VM 이미지를 생성하고 피어 Pod에서 사용하는 데 사용됩니다.
Azure의 보안 오브젝트를 생성할 때 특정 환경 값을 설정해야 합니다. 보안 오브젝트를 생성하기 전에 이러한 값을 검색할 수 있습니다. 또한 역할 기반 액세스 제어(RBAC) 파일을 생성해야 합니다. 이 파일은 다음 값을 생성합니다.
-
AZURE_CLIENT_ID
-
AZURE_CLIENT_SECRET
-
AZURE_TENANT_ID
프로세스
Azure 서브스크립션 ID를 검색합니다.
$ AZURE_SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" -o tsv) && echo "AZURE_SUBSCRIPTION_ID: \"$AZURE_SUBSCRIPTION_ID\""
RBAC 콘텐츠를 생성합니다. 이렇게 하면 클라이언트 ID, 클라이언트 시크릿, 테넌트 ID가 생성됩니다.
$ az ad sp create-for-rbac --role Contributor --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID --query "{ client_id: appId, client_secret: password, tenant_id: tenant }
다음 출력이 표시됩니다.
{ "client_id": `AZURE_CLIENT_ID`, "client_secret": `AZURE_CLIENT_SECRET`, "tenant_id": `AZURE_TENANT_ID` }
- 보안 오브젝트에 사용할 RBAC 출력에 값을 저장합니다.
secret 오브젝트의 추가 매개변수 값을 수집합니다. 각 값을 적어 둡니다.
리소스 그룹을 검색합니다.
$ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}') && echo "AZURE_RESOURCE_GROUP: \"$AZURE_RESOURCE_GROUP\""
Azure 리전을 검색합니다.
$ AZURE_REGION=$(az group show --resource-group ${AZURE_RESOURCE_GROUP} --query "{Location:location}" --output tsv) && echo "AZURE_REGION: \"$AZURE_REGION\""
다음 매니페스트를 사용하여 YAML 파일을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: AZURE_CLIENT_ID: "<enter value>" 1 AZURE_CLIENT_SECRET: "<enter value>" 2 AZURE_TENANT_ID: "<enter value>" 3 AZURE_SUBSCRIPTION_ID: "<enter value>" 4 AZURE_REGION: "<enter value>" 5 AZURE_RESOURCE_GROUP: "<enter value>" 6
보안 오브젝트를 적용합니다.
$ oc apply -f peer-pods-secret.yaml
secret 오브젝트가 적용됩니다.
피어 Pod 시크릿을 업데이트하는 경우 변경 사항을 적용하려면 peerpodconfig-ctrl-caa-daemon
데몬 세트를 다시 시작해야 합니다.
시크릿을 업데이트한 후 매니페스트를 적용합니다. 그런 다음 다음 명령을 실행하여 cloud-api-adaptor
Pod를 다시 시작합니다.
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset을 다시 시작하면 피어 Pod가 다시 생성되고 기존 Pod는 업데이트되지 않습니다.
3.3.3.2. CLI를 사용하여 Azure용 피어 Pod ConfigMap 생성
Azure용 ConfigMap
을 생성할 때 특정 구성 값을 설정해야 합니다. ConfigMap
을 생성하기 전에 이러한 값을 검색할 수 있습니다.
프로세스
Azure 피어 포드
ConfigMap
의 구성 값을 수집합니다. 각 값을 적어 둡니다.Azure VNet 이름을 검색합니다.
$ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
이 값은
ConfigMap
에 필요하지 않지만 Azure 서브넷 ID를 검색하는 데 사용됩니다.Azure 서브넷 ID를 검색합니다.
$ AZURE_SUBNET_ID=$(az network vnet subnet list --resource-group ${AZURE_RESOURCE_GROUP} --vnet-name $AZURE_VNET_NAME --query "[].{Id:id} | [? contains(Id, 'worker')]" --output tsv) && echo "AZURE_SUBNET_ID: \"$AZURE_SUBNET_ID\""
Azure 네트워크 보안 그룹(NSG) ID를 검색합니다.
$ AZURE_NSG_ID=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Id:id}" --output tsv) && echo "AZURE_NSG_ID: \"$AZURE_NSG_ID\""
다음 매니페스트를 사용하여 YAML 파일을 생성합니다.
apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "azure" VXLAN_PORT: "9000" AZURE_INSTANCE_SIZE: "Standard_B2als_v2" 1 AZURE_INSTANCE_SIZES: "Standard_B2als_v2,Standard_D2as_v5,Standard_D4as_v5,Standard_D2ads_v5" 2 AZURE_SUBNET_ID: "<enter value>" 3 AZURE_NSG_ID: "<enter value>" 4 PROXY_TIMEOUT: "5m" DISABLECVM: "true"
ConfigMap
을 적용합니다.$ oc apply -f peer-pods-cm.yaml
ConfigMap
이 배포되었습니다.
피어 Pod 구성 맵을 업데이트하는 경우 변경 사항을 적용하려면 peerpodconfig-ctrl-caa-daemon
데몬 세트를 다시 시작해야 합니다.
구성 맵을 업데이트한 후 매니페스트를 적용합니다. 그런 다음 다음 명령을 실행하여 cloud-api-adaptor
Pod를 다시 시작합니다.
$ oc set env ds/peerpodconfig-ctrl-caa-daemon -n openshift-sandboxed-containers-operator REBOOT="$(date)"
daemonset을 다시 시작하면 피어 Pod가 다시 생성되고 기존 Pod는 업데이트되지 않습니다.
3.3.3.3. CLI를 사용하여 Azure용 SSH 키 시크릿 오브젝트 생성
Azure에서 피어 Pod를 사용하려면 SSH 키를 생성하고 SSH 키 시크릿 오브젝트를 생성해야 합니다.
프로세스
SSH 키를 생성합니다.
$ ssh-keygen -f ./id_rsa -N ""
SSH 시크릿 오브젝트를 생성합니다.
$ oc create secret generic ssh-key-secret -n openshift-sandboxed-containers-operator --from-file=id_rsa.pub=./id_rsa.pub --from-file=id_rsa=./id_rsa
SSH 키가 생성되고 SSH 키 시크릿 오브젝트가 생성됩니다. KataConfig
CR을 생성하면 Azure에서 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 실행할 수 있습니다.
3.3.4. CLI를 사용하여 IBM Z의 피어 Pod 설정
IBM Z에서 실행 중인 OpenShift Container Platform 클러스터에서 사용할 피어 Pod를 설정하려면 libvirt와 KVM 호스트 간의 통신에 필요한 인증 정보를 보유하는 secret 오브젝트, RHEL KVM 이미지 VM 및 peer-pod ConfigMap
을 생성해야 합니다.
IBM Z용 피어 Pod를 설정한 후 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 배포하려면 KataConfig
CR(사용자 정의 리소스)을 생성해야 합니다.
사전 요구 사항
- 클러스터에 OpenShift Container Platform 4.14 이상을 설치했습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.
- libvirt가 KVM 호스트에 설치되어 있으며 관리자 권한이 있습니다.
3.3.4.1. KVM 호스트에서 libvirt 설정
KVM 호스트에 libvirt를 설정해야 합니다. IBM Z의 피어 Pod는 클라우드 API Adaptor의 libvirt 공급자를 사용하여 가상 머신을 생성하고 관리합니다.
프로세스
IBM Z KVM 호스트에 로그인하고 libvirt에서 스토리지 관리를 위해 사용할 쉘 변수를 설정합니다.
다음 명령을 실행하여 libvirt 풀의 이름을 설정합니다.
$ export LIBVIRT_POOL=<name_of_libvirt_pool_to_create>
다음 명령을 실행하여 libvirt 풀의 이름을 설정합니다.
$ export LIBVIRT_VOL_NAME=<name_of_libvirt_volume_to_create>
다음 명령을 실행하여 기본 스토리지 풀 위치의 경로를 설정합니다.
$ export LIBVIRT_POOL_DIRECTORY=<name_of_target_directory> 1
- 1
- libvirt에 읽기 및 쓰기 액세스 권한이 있는지 확인하려면 libvirt의 스토리지 디렉터리의 하위 디렉터리를 사용합니다. 기본값은
/var/lib/libvirt/images/
입니다.
다음 명령을 실행하여 libvirt 풀을 생성합니다.
$ virsh pool-define-as $LIBVIRT_POOL --type dir --target "$LIBVIRT_POOL_DIRECTORY"
다음 명령을 실행하여 libvirt 풀을 시작합니다.
$ virsh pool-start $LIBVIRT_POOL
다음 명령을 실행하여 풀에 대한 libvirt 볼륨을 만듭니다.
$ virsh -c qemu:///system \ vol-create-as --pool $LIBVIRT_POOL \ --name $LIBVIRT_VOL_NAME \ --capacity 20G \ --allocation 2G \ --prealloc-metadata \ --format qcow2
3.3.4.2. IBM Z의 피어 Pod VM 이미지 생성
IBM Z에서 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 실행하려면 먼저 libvirt 공급자가 peer-pod VM을 시작하는 KVM 게스트를 생성해야 합니다.
이미지가 생성되면 이전 단계에서 생성한 볼륨에 이미지를 업로드합니다.
사전 요구 사항
- IBM z15 이상 또는 IBM® LinuxONE III 이상
- KVM을 사용하여 RHEL 9 이상에서 실행 중인 하나 이상의 LPAR.
프로세스
시스템의 RHEL
ORG_ID
및ACTIVATION_KEY
쉘 변수를 설정합니다.서브스크립션된 RHEL 시스템을 사용하는 경우 다음 명령을 실행하여 쉘 환경 변수를 조직 ID를 보유한 파일로 설정하고 Red Hat Subscription Management(RHSM)의 활성화 키를 설정합니다.
$ export ORG_ID=$(cat ~/.rh_subscription/orgid) $ export ACTIVATION_KEY=$(cat ~/.rh_subscription/activation_key)
서브스크립션이 해제된 RHEL 시스템을 사용하는 경우 다음 명령을 실행하여 적절한 서브스크립션 값을 설정합니다.
$ export ORG_ID=<RHEL_ORGID_VALUE> $ export ACTIVATION_KEY=<RHEL_ACVTIVATION_KEY>
IBM Z 시스템에 로그인하고 다음 단계를 수행합니다.
-
Red Hat 고객 포털에서 libvirt 올바른 액세스 권한을 부여하려면
s390x
RHEL KVM 게스트 이미지를 libvirt 스토리지 디렉터리로 다운로드합니다. 기본 디렉터리는/var/lib/libvirt/images
입니다. 이미지는 관련 바이너리를 포함할 피어 Pod VM 이미지를 생성하는 데 사용됩니다. 다음 명령을 실행하여 다운로드한 이미지의
IMAGE_URL
쉘 환경 변수를 설정합니다.$ export IMAGE_URL=<location_of_downloaded_KVM_guest_image> 1
- 1
- 이전 단계에서 다운로드한 KVM 게스트 이미지의 경로를 입력합니다.
다음 명령을 실행하여 게스트 KVM 이미지를 등록합니다.
$ export REGISTER_CMD="subscription-manager register --org=${ORG_ID} \ --activationkey=${ACTIVATION_KEY}"
다음 명령을 실행하여 게스트 KVM 이미지를 사용자 지정합니다.
$ virt-customize -v -x -a ${IMAGE_URL} --run-command "${REGISTER_CMD}"
다음 명령을 실행하여 이미지의 체크섬을 설정합니다.
$ export IMAGE_CHECKSUM=$(sha256sum ${IMAGE_URL} | awk '{ print $1 }')
-
Red Hat 고객 포털에서 libvirt 올바른 액세스 권한을 부여하려면
3.3.4.2.1. 피어-pod VM QCOW2 이미지 빌드
IBM Z에서 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 실행하려면 피어-pod VM QCOW2 이미지를 빌드해야 합니다.
프로세스
다음 명령을 실행하여 cloud-api-adaptor 리포지토리를 빌드 워크스테이션에 복제합니다.
$ git clone --single-branch https://github.com/confidential-containers/cloud-api-adaptor.git
다음 명령을 실행하여
podvm
디렉터리로 변경합니다.$ cd cloud-api-adaptor && git checkout 8577093
최종 QCOW2 이미지가 생성되는 빌더 이미지를 생성합니다.
서브스크립션된 RHEL 시스템을 사용하는 경우 다음 명령을 실행합니다.
$ podman build -t podvm_builder_rhel_s390x \ --build-arg ARCH="s390x" \ --build-arg GO_VERSION="1.21.3" \ --build-arg PROTOC_VERSION="25.1" \ --build-arg PACKER_VERSION="v1.9.4" \ --build-arg RUST_VERSION="1.72.0" \ --build-arg YQ_VERSION="v4.35.1" \ --build-arg YQ_CHECKSUM="sha256:4e6324d08630e7df733894a11830412a43703682d65a76f1fc925aac08268a45" \ -f podvm/Dockerfile.podvm_builder.rhel .
서브스크립션이 해제된 RHEL 시스템을 사용하는 경우 다음 명령을 실행합니다.
$ podman build -t podvm_builder_rhel_s390x \ --build-arg ORG_ID=$ORG_ID \ --build-arg ACTIVATION_KEY=$ACTIVATION_KEY \ --build-arg ARCH="s390x" \ --build-arg GO_VERSION="1.21.3" \ --build-arg PROTOC_VERSION="25.1" \ --build-arg PACKER_VERSION="v1.9.4" \ --build-arg RUST_VERSION="1.72.0" \ --build-arg YQ_VERSION="v4.35.1" \ --build-arg YQ_CHECKSUM="sha256:4e6324d08630e7df733894a11830412a43703682d65a76f1fc925aac08268a45" \ -f podvm/Dockerfile.podvm_builder.rhel .
다음 명령을 실행하여 피어 Pod를 실행하는 데 필요한 바이너리를 사용하여 중간 이미지 패키지를 생성합니다.
$ podman build -t podvm_binaries_rhel_s390x \ --build-arg BUILDER_IMG="podvm_builder_rhel_s390x:latest" \ --build-arg ARCH=s390x \ -f podvm/Dockerfile.podvm_binaries.rhel .
참고이 프로세스는 상당한 시간이 걸릴 것으로 예상됩니다.
다음 명령을 실행하여 바이너리를 추출하고 peer-pod QCOW2 이미지를 빌드합니다.
$ podman build -t podvm_rhel_s390x \ --build-arg ARCH=s390x \ --build-arg CLOUD_PROVIDER=libvirt \ --build-arg BUILDER_IMG="localhost/podvm_builder_rhel_s390x:latest" \ --build-arg BINARIES_IMG="localhost/podvm_binaries_rhel_s390x:latest" \ -v ${IMAGE_URL}:/tmp/rhel.qcow2:Z \ --build-arg IMAGE_URL="/tmp/rhel.qcow2" \ --build-arg IMAGE_CHECKSUM=${IMAGE_CHECKSUM} \ -f podvm/Dockerfile.podvm.rhel .
다음 명령을 실행하여 피어 Pod QCOW2 이미지를 선택한 디렉터리에 추출합니다.
$ export IMAGE_OUTPUT_DIR=<image_output_directory> 1 $ mkdir -p $IMAGE_OUTPUT_DIR $ podman save podvm_rhel_s390x | tar -xO --no-wildcards-match-slash '*.tar' | tar -x -C ${IMAGE_OUTPUT_DIR}
- 1
image_output_directory
를 입력하여 최종 QCOW 이미지를 추출합니다.
피어 Pod QCOW2 이미지를 libvirt 볼륨에 업로드합니다.
$ virsh -c qemu:///system vol-upload \ --vol $LIBVIRT_VOL_NAME \ $IMAGE_OUTPUT_DIR/podvm-*.qcow2 \ --pool $LIBVIRT_POOL --sparse
3.3.4.3. 피어-pod 인증 정보에 대한 RHEL 시크릿 생성
IBM Z의 보안 오브젝트를 생성할 때 특정 환경 값을 설정해야 합니다. 보안 오브젝트를 생성하기 전에 이러한 값 중 일부를 검색할 수 있습니다. 그러나 다음과 같은 값을 준비해야 합니다.
-
LIBVIRT_POOL
-
LIBVIRT_VOL_NAME
-
LIBVIRT_URI
LIBVIRT_URI
는 libvirt 네트워크의 기본 게이트웨이 IP 주소입니다. libvirt 네트워크 설정을 확인하여 이 값을 가져옵니다.
libvirt 설치에서 기본 브리지 가상 네트워크를 사용하는 경우 다음 명령을 실행하여 LIBVIRT_URI
를 가져올 수 있습니다.
$ virtint=$(bridge_line=$(virsh net-info default | grep Bridge); echo "${bridge_line//Bridge:/}" | tr -d [:blank:]) $ LIBVIRT_URI=$( ip -4 addr show $virtint | grep -oP '(?<=inet\s)\d+(\.\d+){3}')
프로세스
다음 매니페스트를 사용하여 YAML 파일
peer-pods-secret.yaml
을 생성합니다.apiVersion: v1 kind: Secret metadata: name: peer-pods-secret namespace: openshift-sandboxed-containers-operator type: Opaque stringData: CLOUD_PROVIDER: "libvirt" 1 LIBVIRT_URI: "<libvirt_gateway_uri>" 2 LIBVIRT_POOL: "<libvirt_pool>" 3 LIBVIRT_VOL_NAME: "<libvirt_volume>" 4
보안 오브젝트를 생성합니다.
$ oc apply -f peer-pods-secret.yaml
secret 오브젝트가 적용됩니다.
3.3.4.4. CLI를 사용하여 IBM Z의 피어 Pod ConfigMap 생성
IBM Z용 ConfigMap
을 생성할 때 libvirt 공급자를 사용해야 합니다.
프로세스
다음 매니페스트를 사용하여 YAML 파일
peer-pods-cm.yaml
을 생성합니다.apiVersion: v1 kind: ConfigMap metadata: name: peer-pods-cm namespace: openshift-sandboxed-containers-operator data: CLOUD_PROVIDER: "libvirt" PROXY_TIMEOUT: "15m"
ConfigMap
을 적용합니다.$ oc apply -f peer-pods-cm.yaml
ConfigMap
이 적용됩니다.
3.3.4.5. CLI를 사용하여 IBM Z의 SSH 키 시크릿 오브젝트 생성
IBM Z에서 피어 Pod를 사용하려면 SSH 키 쌍을 생성하고 SSH 키 시크릿 오브젝트를 생성해야 합니다.
프로세스
SSH 키를 생성합니다.
$ ssh-keygen -f ./id_rsa -N ""
SSH 공개 키를 KVM 호스트에 복사합니다.
$ ssh-copy-id -i ./id_rsa.pub <KVM_HOST_ADDRESS> 1
- 1
- KVM 호스트의 IP 주소를 입력합니다.
보안 오브젝트를 생성합니다.
$ oc create secret generic ssh-key-secret \ -n openshift-sandboxed-containers-operator \ --from-file=id_rsa.pub=./id_rsa.pub \ --from-file=id_rsa=./id_rsa
SSH 키를 삭제합니다.
$ shred –remove id_rsa.pub id_rsa
보안 오브젝트가 생성됩니다. KataConfig
CR을 생성하면 IBM Z에서 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 실행할 수 있습니다.
3.3.5. CLI를 사용하여 KataConfig 사용자 지정 리소스 생성
노드에 kata-remote
를 설치하려면 하나의 KataConfig
CR(사용자 정의 리소스) 을
생성해야 합니다. KataConfig
CR을 생성하면 OpenShift 샌드박스 컨테이너 Operator가 다음을 수행합니다.
-
RHCOS 노드에 QEMU 및
kata-containers
와 같은 필요한 RHCOS 확장을 설치합니다. - CRI-O 런타임이 올바른 런타임 처리기로 구성되었는지 확인합니다.
-
기본 구성을 사용하여
kata-remote
라는RuntimeClass
CR을 생성합니다. 이를 통해 사용자는RuntimeClassName
필드에서 CR을 참조하여kata-remote
를 런타임으로 사용하도록 워크로드를 구성할 수 있습니다. 이 CR은 런타임의 리소스 오버헤드도 지정합니다.
피어 Pod의 Kata는 기본적으로 모든 작업자 노드에 설치됩니다. 특정 노드에서만 kata-remote
를 설치하려면 해당 노드에 라벨을 추가한 다음 KataConfig
CR에 레이블을 생성할 때 정의할 수 있습니다.
사전 요구 사항
- 클러스터에 OpenShift Container Platform 4.15를 설치했습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.
KataConfig
CR을 생성하면 작업자 노드가 자동으로 재부팅됩니다. 재부팅에는 10분에서 60분 이상 걸릴 수 있습니다. 재부팅 시간을 방해하는 요소는 다음과 같습니다.
- 더 많은 작업자 노드가 있는 대규모 OpenShift Container Platform 배포
- BIOS 및 Cryostat 유틸리티 활성화.
- SSD가 아닌 하드 디스크 드라이브에 배포합니다.
- 가상 노드가 아닌 베어 메탈과 같은 물리적 노드에 배포됩니다.
- 느린 CPU 및 네트워크입니다.
프로세스
다음 매니페스트를 사용하여 YAML 파일을 생성합니다.
apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: enablePeerPods: true logLevel: info
(선택 사항) 선택한 노드에만
RuntimeClass
로kata-remote
를 설치하려면 매니페스트에 라벨이 포함된 YAML 파일을 생성합니다.apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: enablePeerPods: true logLevel: info kataConfigPoolSelector: matchLabels: <label_key>: '<label_value>' 1
- 1
kataConfigPoolSelector
의 라벨은 단일 값만 지원합니다.nodeSelector
구문은 지원되지 않습니다.
KataConfig
리소스를 생성합니다.$ oc create -f cluster-kataconfig.yaml
새로운 KataConfig
CR이 생성되고 작업자 노드에 kata-remote
를 RuntimeClass
로 설치하기 시작합니다. kata-remote
설치가 완료되고 작업자 노드가 재부팅될 때까지 기다린 후 다음 단계를 진행합니다.
CR을 실행하면 VM 이미지가 생성됩니다. 이미지 생성은 클라우드 공급자를 통해 수행되며 추가 리소스를 사용할 수 있습니다.
OpenShift 샌드박스 컨테이너는 kata-remote
를 기본 런타임이 아닌 클러스터의 선택적 런타임으로만 설치합니다.
검증
설치 진행 상황을 모니터링합니다.
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
kataNodes 아래의 모든 작업자가
설치된
것으로 나열되고 이유를 지정하지 않고InProgress
조건이False
이면 클러스터에kata
가 설치되어 있음을 나타냅니다. 자세한 내용은 "설치 및 제거 전환"을 참조하십시오.
추가 리소스
3.3.6. CLI를 사용하여 샌드박스 컨테이너에 피어 Pod를 사용하여 워크로드 배포
OpenShift 샌드박스 컨테이너는 Kata를 기본 런타임이 아닌 클러스터에 보조 런타임으로 설치합니다.
샌드박스 컨테이너에서 피어 Pod를 사용하여 Pod 템플릿 워크로드를 배포하려면 kata-remote
를 워크로드 YAML 파일에 runtimeClassName
으로 추가해야 합니다.
YAML 파일에 주석을 추가하여 기본 인스턴스 크기 또는 ConfigMap
에서 이전에 정의한 유형을 사용하여 워크로드를 배포해야 하는지도 정의해야 합니다. 인스턴스 크기 또는 인스턴스 유형을 사용하는 것은 클라우드 공급자에 따라 다릅니다. 인스턴스 크기 또는 유형을 수동으로 정의하지 않으려면 사용 가능한 메모리에 따라 자동 인스턴스 크기 또는 유형 사용을 정의하는 주석을 추가해야 합니다.
사전 요구 사항
- 클러스터에 OpenShift Container Platform 4.15를 설치했습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.
-
클라우드 공급자 고유의 시크릿 오브젝트 및 피어-pod
ConfigMap
을 생성했습니다. -
KataConfig
CR(사용자 정의 리소스)을 생성했습니다.
프로세스
pod 템플릿 오브젝트에
runtimeClassName: kata-remote
를 추가합니다.-
Pod
오브젝트 -
ReplicaSet
오브젝트 -
ReplicationController
오브젝트 -
StatefulSet
오브젝트 -
Deployment
오브젝트 -
DeploymentConfig
오브젝트
-
pod 템플릿 오브젝트에 주석을 추가하여 특정 인스턴스 크기 또는 유형 또는 자동 인스턴스 크기 또는 유형을 사용할지 여부를 정의합니다. 인스턴스 크기는 특정 클라우드 공급자에 사용되지만 인스턴스 유형은 다른 클라우드 공급자에 사용됩니다.
특정 인스턴스 크기 또는 유형의 경우 다음 주석을 추가합니다.
io.katacontainers.config.hypervisor.machine_type: <instance type/instance size>
워크로드에서 사용할 인스턴스 크기 또는 유형을 정의합니다. 피어 Pod에 대한
ConfigMap
을 생성할 때 이전에 이러한 기본 크기 또는 유형을 미리 정의합니다. 다음 중 하나를 선택합니다.자동 인스턴스 크기 또는 유형의 경우 다음 주석을 추가합니다.
io.katacontainers.config.hypervisor.default_vcpus: <vcpus> io.katacontainers.config.hypervisor.default_memory: <memory>
워크로드에서 사용할 수 있는 메모리 양을 정의합니다. 워크로드는 사용 가능한 메모리 양에 따라 자동 인스턴스 크기 또는 유형에서 실행됩니다.
Pod
오브젝트의 예apiVersion: v1 kind: Pod metadata: name: hello-openshift labels: app: hello-openshift annotations: io.katacontainers.config.hypervisor.machine_type: Standard_DC4as_v5 1 spec: runtimeClassName: kata-remote containers: - name: hello-openshift image: quay.io/openshift/origin-hello-openshift ports: - containerPort: 8888 securityContext: privileged: false allowPrivilegeEscalation: false runAsNonRoot: true runAsUser: 1001 capabilities: drop: - ALL seccompProfile: type: RuntimeDefault
- 1
- 이 예에서는 Azure를 사용하여 피어 Pod에 이전에 정의된 인스턴스 크기를 사용합니다. AWS를 사용하는 피어 Pod는 인스턴스 유형을 사용합니다.
OpenShift Container Platform은 워크로드를 생성하고 스케줄링을 시작합니다.
검증
-
pod 템플릿 오브젝트에서
runtimeClassName
필드를 검사합니다.runtimeClassName
이kata-remote
인 경우 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너에서 워크로드가 실행됩니다.