3장. 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너 워크로드 배포


웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 OpenShift 샌드박스 컨테이너 Operator를 설치할 수 있습니다. OpenShift 샌드박스 컨테이너 Operator를 설치하기 전에 Red Hat OpenShift 클러스터를 준비해야 합니다.

중요

피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너 워크로드를 배포하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

3.1. 사전 요구 사항

OpenShift 샌드박스 컨테이너를 설치하고 피어 Pod를 활성화하기 전에 다음 요구 사항을 충족해야 합니다.

  • AWS 또는 Azure에 Red Hat OpenShift 4.13이 설치되어 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

3.1.1. OpenShift 샌드박스 컨테이너의 피어 Pod 리소스 요구 사항 정보

피어 Pod는 다음 두 위치에서 리소스를 사용합니다.

  • 작업자 노드입니다. 작업자 노드는 메타데이터, Kata shim 리소스(containerd-shim-kata-v2), remote-hypervisor 리소스(cloud-api-adaptor) 및 작업자 노드와 VM(Peer-pod 가상 머신) 간의 터널 설정을 저장합니다.
  • 클라우드 인스턴스입니다. 클라우드에서 실행되는 실제 피어 포드 VM입니다.

Kubernetes 작업자 노드에 사용되는 CPU 및 메모리 리소스는 피어 Pod를 생성하는 데 사용되는 RuntimeClass(kata-remote) 정의에 포함된 Pod 오버헤드 에 의해 처리됩니다.

클라우드에서 실행되는 총 피어 Pod VM 수는 Kubernetes 노드 확장 리소스로 정의됩니다. 이 제한은 노드당이며 peerpodConfig CR(사용자 정의 리소스)의 limit 속성으로 설정됩니다. peerpodconfig-openshift 라는 peerpodConfig CR은 kataConfig CR을 생성하고 피어 Pod를 활성화할 때 생성되며 openshift-sandboxed-containers-operator 네임스페이스에 있습니다.

다음 peerpodConfig CR 예제에서는 기본 사양 값을 표시합니다.

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
기본 제한은 노드당 VM 10개입니다.

확장된 리소스의 이름은 kata.peerpods.io/vm 이며 Kubernetes 스케줄러에서 용량 추적 및 계정을 처리할 수 있습니다.

환경의 요구 사항에 따라 노드당 제한을 편집할 수 있습니다. 자세한 내용은 피어 Pod에서 노드당 VM 제한 수정 을 참조하십시오.

변경 웹 후크 는 확장된 리소스 kata.peerpods.io/vm 을 Pod 사양에 추가합니다. 또한 Pod 사양에서 리소스별 항목도 제거합니다(있는 경우). 이를 통해 Kubernetes 스케줄러에서 이러한 확장 리소스를 설명할 수 있으므로 리소스를 사용할 수 있는 경우에만 peer-pod를 예약할 수 있습니다.

변경 웹 후크는 다음과 같이 Kubernetes Pod를 수정합니다.

  • 변경 웹 후크는 TARGET_RUNTIME_CLASS 환경 변수에 지정된 예상 RuntimeClassName 값을 Pod에 확인합니다. Pod 사양의 값이 TARGET_RUNTIME_CLASS 의 값과 일치하지 않으면 Pod를 수정하지 않고 웹 후크가 종료됩니다.
  • RuntimeClassName 값이 일치하는 경우 Webhook에서 Pod 사양을 다음과 같이 변경합니다.

    1. Webhook는 Pod에 있는 모든 컨테이너 및 init 컨테이너의 resources 필드에서 모든 리소스 사양을 제거합니다.
    2. Webhook는 Pod의 첫 번째 컨테이너의 resources 필드를 수정하여 확장 리소스(kata.peerpods.io/vm)를 사양에 추가합니다. 확장된 리소스 kata.peerpods.io/vm 은 회계 목적으로 Kubernetes 스케줄러에서 사용합니다.
참고

변경 웹 후크에서는 Red Hat OpenShift의 특정 시스템 네임스페이스가 변경되지 않습니다. 해당 시스템 네임스페이스에 피어-포드가 생성되면 Pod 사양에 확장 리소스가 포함되지 않는 한 Kubernetes 확장 리소스를 사용하는 리소스 계정이 작동하지 않습니다.

특정 네임스페이스에서 피어 Pod 생성만 허용하도록 클러스터 전체 정책을 정의하는 것이 좋습니다.

3.1.1.1. 노드당 피어 Pod VM 제한 수정

peerpodConfig CR(사용자 정의 리소스)을 편집하여 노드당 피어 Pod VM 제한을 변경할 수 있습니다.

절차

  1. 다음 명령을 실행하여 현재 제한을 확인합니다.

    $ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \
    -o jsonpath='{.spec.limit}{"\n"}'
  2. 다음 명령을 실행하여 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를 사용하는 피어 Pod의 사전 요구 사항

AWS를 사용하여 피어 Pod를 생성하는 경우 다음 요구 사항을 확인해야 합니다.

  • Red Hat OpenShift 클러스터는 하나 이상의 작업자 노드가 있는 AWS에 설치해야 합니다.
  • AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY 인증 정보에 액세스할 수 있습니다. 이는 클러스터의 동일한 VPC(가상 프라이빗 클라우드)에 추가 클라우드 인스턴스를 생성하는 데 사용됩니다.
  • AWS CLI 툴이 설치 및 구성되어 있어야 합니다.
  • 포트 15150 및 9000에서 내부 클러스터 통신을 활성화해야 합니다.

    AWS 웹 콘솔 또는 CLI를 사용하여 이러한 포트를 활성화할 수 있습니다.

3.1.2.1. AWS의 포트 15150 및 9000 활성화

절차

  1. 인스턴스 ID를 검색합니다.

    $ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
  2. AWS 리전을 검색합니다.

    $ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')
  3. 보안 그룹을 검색합니다.

    $ SG=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --output text --region ${AWS_REGION})
  4. peer-pods shim을 인증하고 kata-agent 통신에 액세스합니다. 다음 명령을 실행합니다.

    $ aws ec2 authorize-security-group-ingress --group-id ${SG} --protocol tcp --port 15150 --source-group ${SG} --region ${AWS_REGION}
  5. 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를 사용하는 피어 Pod의 사전 요구 사항

Microsoft Azure를 사용하여 피어 Pod를 생성하는 경우 다음 요구 사항을 확인해야 합니다.

  • Red Hat OpenShift 클러스터는 하나 이상의 작업자 노드가 있는 Azure에 설치해야 합니다.
  • 다음 인증 정보 및 서브스크립션 세부 정보에 액세스할 수 있습니다.

    • AZURE_SUBSCRIPTION_ID
    • AZURE_CLIENT_ID
    • AZURE_CLIENT_SECRET
    • AZURE_TENANT_ID

    이는 클러스터의 동일한 VPC(가상 프라이빗 클라우드)에 추가 클라우드 인스턴스를 생성하는 데 사용됩니다.

  • Azure CLI 툴이 설치 및 구성되어 있어야 합니다.
  • 포트 15150 및 9000에서 클러스터 통신을 활성화해야 합니다.

    Azure에서는 이러한 포트에서 내부 통신이 허용됩니다. 그러나 통신이 차단되면 Azure 웹 콘솔 또는 CLI에서 포트를 활성화할 수 있습니다.

3.1.3.1. Azure의 포트 15150 및 9000을 활성화합니다.

절차

  1. 인스턴스 ID를 검색합니다.

    $ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')
  2. Azure 리소스 그룹을 검색합니다.

    $ AZURE_RESOURCE_GROUP=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}')
  3. Azure 네트워크 보안 그룹(NSG) 이름을 검색합니다.

    $ AZURE_NSG_NAME=$(az network nsg list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
  4. Azure VNet 이름을 검색합니다.

    $ AZURE_VNET_NAME=$(az network vnet list --resource-group ${AZURE_RESOURCE_GROUP} --query "[].{Name:name}" --output tsv)
  5. 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)
  6. 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)
  7. 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
  8. 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

이제 포트가 활성화됩니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.