3.2. 웹 콘솔과 함께 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너 워크로드 배포


웹 콘솔에서 OpenShift 샌드박스 컨테이너 워크로드를 배포할 수 있습니다. 먼저 OpenShift 샌드박스 컨테이너 Operator를 설치한 다음 시크릿 오브젝트, VM 이미지 및 피어 포드 ConfigMap을 생성해야 합니다. 보안 오브젝트 및 ConfigMap은 클라우드 공급자에 따라 고유합니다. 마지막으로 KataConfig CR(사용자 정의 리소스)을 생성해야 합니다. 샌드박스 컨테이너에 워크로드를 배포할 준비가 되면 워크로드 YAML 파일에 kata-remoteruntimeClassName 으로 수동으로 추가해야 합니다.

3.2.1. 웹 콘솔을 사용하여 OpenShift 샌드박스 컨테이너 Operator 설치

OOpenShift Container Platform 웹 콘솔에서 OpenShift 샌드박스 컨테이너 Operator를 설치할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 4.15가 설치되어 있어야 합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator OperatorHub 로 이동합니다.
  2. 키워드로 필터링 필드에 OpenShift sandboxed containers를 입력합니다.
  3. OpenShift 샌드박스 컨테이너 타일을 선택합니다.
  4. Operator에 대한 정보를 확인하고 Install을 클릭합니다.
  5. Operator 설치 페이지에서 다음을 수행합니다.

    1. 사용 가능한 업데이트 채널 옵션 목록에서 stable을 선택합니다.
    2. 설치된 네임스페이스 용으로 Operator 권장 네임스페이스 가 선택되어 있는지 확인합니다. 이렇게 하면 필수 openshift-sandboxed-containers-operator 네임스페이스에 Operator가 설치됩니다. 이 네임스페이스가 아직 존재하지 않으면 자동으로 생성됩니다.

      참고

      openshift-sandboxed-containers-operator 이외의 네임스페이스에 OpenShift 샌드박스 컨테이너 Operator를 설치하려고 하면 설치가 실패합니다.

    3. 승인 전략에 대해 자동 이 선택되어 있는지 확인합니다. Automatic 은 기본값이며 새 z-stream 릴리스를 사용할 수 있을 때 OpenShift 샌드박스 컨테이너에 대한 자동 업데이트를 활성화합니다.
  6. 설치를 클릭합니다.

OpenShift 샌드박스 컨테이너 Operator가 클러스터에 설치되었습니다.

검증

  1. 웹 콘솔의 관리자 화면에서 Operator 설치된 Operator 로 이동합니다.
  2. OpenShift 샌드박스 컨테이너 Operator가 operator 목록에 나열되어 있는지 확인합니다.

3.2.2. 웹 콘솔을 사용하여 AWS의 피어 Pod 매개변수 구성

AWS에서 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 배포하려면 보안 오브젝트 및 ConfigMap 을 생성해야 합니다.

보안 오브젝트를 생성한 후에도 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 배포하기 위해 KataConfig CR(사용자 정의 리소스)을 생성해야 합니다.

사전 요구 사항

  • 클러스터에 OpenShift Container Platform 4.15를 설치했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.

3.2.2.1. 웹 콘솔을 사용하여 AWS의 보안 오브젝트 생성

AWS 액세스 키를 설정하고 secret 오브젝트에서 네트워크를 구성합니다. secret 오브젝트는 Pod VM 이미지를 생성하고 피어 Pod에서 사용하는 데 사용됩니다.

AWS의 보안 오브젝트를 생성할 때 특정 환경 값을 설정해야 합니다. 보안 오브젝트를 생성하기 전에 이러한 값 중 일부를 검색할 수 있습니다. 이러한 값 검색은 CLI를 사용하여 수행해야 합니다. 자세한 내용은 CLI를 사용하여 AWS의 보안 오브젝트 생성을 참조하십시오.

또한 AWS 웹 콘솔에서 다음 값을 생성하고 저장해야 합니다.

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator 설치된 Operator 로 이동합니다.
  2. Operator 목록에서 OpenShift 샌드박스 컨테이너 Operator를 선택합니다.
  3. 오른쪽 상단에 있는 가져오기 아이콘(+)을 클릭합니다.
  4. YAML 가져오기 창에서 다음 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
    1
    시작하기 전에 준비한 AWS_ACCESS_KEY_ID 값을 입력합니다.
    2
    시작하기 전에 준비한 AWS_SECRET_ACCESS_KEY 값을 입력합니다.
    3
    검색한 AWS_REGION 값을 입력합니다.
    4
    검색한 AWS_SUBNET_ID 값을 입력합니다.
    5
    검색한 AWS_VPC_ID 값을 입력합니다.
    6
    검색한 AWS_SG_IDS 값을 입력합니다.
  5. 생성을 클릭합니다.

보안 오브젝트가 생성됩니다. 워크로드 시크릿 아래에 나열되는 것을 확인할 수 있습니다.

참고

피어 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.2.2.2. 웹 콘솔을 사용하여 AWS의 피어 Pod ConfigMap 생성

웹 콘솔을 사용하여 AWS의 피어 Pod ConfigMap 을 생성할 수 있습니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator 설치된 Operator 로 이동합니다.
  2. Operator 목록에서 OpenShift 샌드박스 컨테이너 Operator를 선택합니다.
  3. 오른쪽 상단에 있는 가져오기 아이콘(+)을 클릭합니다.
  4. YAML 가져오기 창에서 다음 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"
    1
    유형이 워크로드에 정의되지 않은 경우 사용되는 기본 인스턴스 유형을 정의합니다.
    2
    Pod를 생성할 때 지정할 수 있는 모든 인스턴스 유형을 나열합니다. 이를 통해 더 적은 메모리와 CPU가 필요한 워크로드에 대해 더 작은 인스턴스를 정의하거나 더 큰 워크로드에 대해 더 큰 인스턴스를 정의할 수 있습니다.
  5. 생성을 클릭합니다.

ConfigMap 오브젝트가 생성됩니다. 워크로드 ConfigMaps 에서 나열되는 것을 확인할 수 있습니다.

참고

피어 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.2.3. 웹 콘솔을 사용하여 Azure의 피어 Pod 매개변수 구성

Microsoft Azure의 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 배포하려면 시크릿 오브젝트 및 ConfigMap 을 생성해야 합니다.

보안 오브젝트를 생성한 후에도 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 배포하기 위해 KataConfig CR(사용자 정의 리소스)을 생성해야 합니다.

사전 요구 사항

  • 클러스터에 OpenShift Container Platform 4.15를 설치했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.

3.2.3.1. 웹 콘솔을 사용하여 Azure의 보안 오브젝트 생성

Azure 액세스 키를 설정하고 시크릿 오브젝트에서 네트워크를 구성합니다. secret 오브젝트는 Pod VM 이미지를 생성하고 피어 Pod에서 사용하는 데 사용됩니다.

Azure의 보안 오브젝트를 생성할 때 특정 환경 값을 설정해야 합니다. 보안 오브젝트를 생성하기 전에 이러한 값을 검색할 수 있습니다. 이러한 값 검색은 CLI를 사용하여 수행해야 합니다. 자세한 내용은 CLI를 사용하여 Azure의 보안 오브젝트 생성을 참조하십시오.

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator 설치된 Operator 로 이동합니다.
  2. Operator 목록에서 OpenShift 샌드박스 컨테이너 Operator를 선택합니다.
  3. 오른쪽 상단에 있는 가져오기 아이콘(+)을 클릭합니다.
  4. YAML 가져오기 창에서 다음 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
    1
    RBAC 파일에 생성한 AZURE_CLIENT_ID 값을 입력합니다.
    2
    RBAC 파일에 생성한 AZURE_CLIENT_SECRET 값을 입력합니다.
    3
    RBAC 파일에 생성한 AZURE_TENANT_ID 값을 입력합니다.
    4
    검색한 AZURE_SUBSCRIPTION_ID 값을 입력합니다.
    5
    검색한 AZURE_REGION 값을 입력합니다.
    6
    검색한 AZURE_RESOURCE_GROUP 값을 입력합니다.
  5. 생성을 클릭합니다.

보안 오브젝트가 생성됩니다. 워크로드 시크릿 아래에 나열되는 것을 확인할 수 있습니다.

참고

피어 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.2.3.2. 웹 콘솔을 사용하여 Azure용 피어 Pod ConfigMap 생성

웹 콘솔을 사용하여 Azure의 피어 Pod ConfigMap 을 생성할 수 있습니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator 설치된 Operator 로 이동합니다.
  2. Operator 목록에서 OpenShift 샌드박스 컨테이너 Operator를 선택합니다.
  3. 오른쪽 상단에 있는 가져오기 아이콘(+)을 클릭합니다.
  4. YAML 가져오기 창에서 다음 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"
    1
    워크로드에서 인스턴스가 정의되지 않은 경우 사용되는 기본 인스턴스 크기를 정의합니다.
    2
    Pod를 생성할 때 지정할 수 있는 모든 인스턴스 크기를 나열합니다. 이를 통해 더 적은 메모리와 CPU가 필요한 워크로드에 대해 더 작은 인스턴스를 정의하거나 더 큰 워크로드에 대해 더 큰 인스턴스를 정의할 수 있습니다.
    3
    검색한 AZURE_SUBNET_ID 값을 입력합니다.
    4
    검색한 AZURE_NSG_ID 값을 입력합니다.
  5. 생성을 클릭합니다.

ConfigMap의 오브젝트가 생성됩니다. 워크로드 ConfigMaps 에서 나열되는 것을 확인할 수 있습니다.

참고

피어 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.2.3.3. 웹 콘솔을 사용하여 Azure용 SSH 키 시크릿 오브젝트 생성

Azure에서 피어 Pod를 사용하려면 SSH 키 시크릿 오브젝트를 생성해야 합니다. 오브젝트를 생성할 SSH 키가 없는 경우 CLI를 사용하여 생성해야 합니다. 자세한 내용은 다음을 참조하십시오.

프로세스

  1. 웹 콘솔의 관리자 화면에서 워크로드 시크릿 으로 이동합니다.
  2. 시크릿 창에서 왼쪽 상단 모서리에서 openshift-sandboxed-containers-operator 프로젝트에 있는지 확인합니다.
  3. 생성 을 클릭하고 목록에서 키/값 시크릿 을 선택합니다.
  4. 시크릿 이름 필드에 ssh-key-secret 을 입력합니다.
  5. 필드에 id_rsa.pub 를 입력합니다.
  6. 필드에 공개 SSH 키를 붙여넣습니다.
  7. 생성을 클릭합니다.

SSH 키 시크릿 오브젝트가 생성됩니다. 워크로드 시크릿 아래에 나열되는 것을 확인할 수 있습니다.

KataConfig CR을 생성하면 Azure에서 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너를 실행할 수 있습니다.

3.2.4. 웹 콘솔에서 KataConfig 사용자 지정 리소스 생성

클러스터 노드에서 kata-remoteRuntimeClass 로 설치하려면 하나의 KataConfig CR(사용자 정의 리소스)을 생성해야 합니다.

중요

KataConfig CR을 생성하면 작업자 노드가 자동으로 재부팅됩니다. 재부팅에는 10분에서 60분 이상 걸릴 수 있습니다. 재부팅 시간을 방해하는 요소는 다음과 같습니다.

  • 더 많은 작업자 노드가 있는 대규모 OpenShift Container Platform 배포
  • BIOS 및 Cryostat 유틸리티 활성화.
  • SSD가 아닌 하드 디스크 드라이브에 배포합니다.
  • 가상 노드가 아닌 베어 메탈과 같은 물리적 노드에 배포됩니다.
  • 느린 CPU 및 네트워크입니다.

사전 요구 사항

  • 클러스터에 OpenShift Container Platform 4.15를 설치했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.
참고

피어 Pod의 Kata는 기본적으로 모든 작업자 노드에 설치됩니다. 특정 노드에서만 kata-remote 를 설치하려면 해당 노드에 레이블을 추가한 다음, 해당 노드를 생성할 때 KataConfig CR에 레이블을 정의할 수 있습니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator 설치된 Operator 로 이동합니다.
  2. Operator 목록에서 OpenShift 샌드박스 컨테이너 Operator를 선택합니다.
  3. KataConfig 탭에서 KataConfig 만들기 를 클릭합니다.
  4. KataConfig 만들기 페이지에서 다음 세부 정보를 입력합니다.

    • Name: KataConfig 리소스의 이름을 입력합니다. 기본적으로 이름은 example-kataconfig 로 정의됩니다.
    • 레이블 (선택 사항): KataConfig 리소스에 관련 특성을 입력합니다. 각 레이블은 키-값 쌍을 나타냅니다.
    • CheckNodeEligibility (선택 사항, 피어 Pod와 관련이 없음): NFD(Node Feature Discovery Operator)를 사용하여 kataRuntimeClass 로 실행할 자격을 감지하려면 이 확인란을 선택합니다. 자세한 내용은 "클러스터 노드가 OpenShift 샌드박스 컨테이너를 실행할 수 있는지 확인"을 참조하십시오.
    • EnablePeerPods ( 피어 Pod의 경우): 이 확인란을 선택하여 피어 Pod를 활성화하고 퍼블릭 클라우드 환경에서 OpenShift 샌드박스 컨테이너를 사용합니다.
    • kataConfigPoolSelector: 기본적으로 kata-remote 는 모든 노드에 RuntimeClass 로 설치됩니다. 선택한 노드에서만 kata-remoteRuntimeClass 로 설치하려면 matchExpression:을 추가해야 합니다.

      1. kataConfigPoolSelector 영역을 확장합니다.
      2. kataConfigPoolSelector 에서 matchExpressions 를 확장합니다. 이는 라벨 선택기 요구 사항 목록입니다.
      3. matchExpressions 추가를 클릭합니다.
      4. 필드에서 선택기가 적용되는 라벨 키를 추가합니다.
      5. operator 필드에서 키 관계를 레이블 값에 추가합니다. 유효한 연산자는 In,NotIn,ExistsDoesNotExist 입니다.
      6. 영역을 확장한 다음 값 추가 를 클릭합니다.
      7. 필드에 레이블 값에 true 또는 false 를 입력합니다.
    • loglevel: kata-remote 를 런타임 클래스로 실행하는 노드에 대해 검색된 로그 데이터의 수준을 정의합니다. 자세한 내용은 "OpenShift 샌드박스 컨테이너 데이터 수집"을 참조하십시오.
  5. 생성을 클릭합니다.

새로운 KataConfig CR이 생성되고 작업자 노드에 kata-remoteRuntimeClass 로 설치하기 시작합니다. 설치가 완료되고 작업자 노드가 재부팅될 때까지 기다린 후 다음 단계를 진행합니다.

참고

CR을 실행하면 VM 이미지가 생성됩니다. 이미지 생성은 클라우드 공급자를 통해 수행되며 추가 리소스를 사용할 수 있습니다.

중요

OpenShift 샌드박스 컨테이너는 kata-remote 를 기본 런타임이 아닌 클러스터의 선택적 런타임으로만 설치합니다.

검증

  1. KataConfig 탭에서 새 KataConfig CR을 선택합니다.
  2. KataConfig 페이지에서 YAML 탭을 선택합니다.
  3. 상태 필드를 모니터링합니다.

    업데이트가 있을 때마다 메시지가 표시됩니다. Reload 를 클릭하여 업데이트된 KataConfig CR을 확인합니다.

    status 필드에는 조건kataNodes 하위 필드가 있습니다. kataNodes 하위 필드는 노드 목록의 컬렉션이며 각각 kata 설치 상태의 노드를 나열합니다.

    kataNodes 아래의 모든 작업자가 설치된 것으로 나열되고 이유를 지정하지 않고 InProgress 조건이 False 이면 클러스터에 kata 가 설치되어 있음을 나타냅니다. 자세한 내용은 "설치 및 제거 전환"을 참조하십시오.

3.2.5. 웹 콘솔을 사용하여 샌드박스 컨테이너에 피어 Pod로 워크로드 배포

OpenShift 샌드박스 컨테이너는 Kata를 기본 런타임이 아닌 클러스터에 보조 런타임으로 설치합니다.

샌드박스 컨테이너에서 피어 Pod를 사용하여 Pod 템플릿 워크로드를 배포하려면 워크로드 YAML 파일에 kata-remoteruntimeClassName 으로 수동으로 추가해야 합니다.

YAML 파일에 주석을 추가하여 기본 인스턴스 크기 또는 ConfigMap 에서 이전에 정의한 유형을 사용하여 워크로드를 배포해야 하는지도 정의해야 합니다. 인스턴스 크기 또는 인스턴스 유형을 사용하는 것은 클라우드 공급자에 따라 다릅니다. 인스턴스 크기 또는 유형을 수동으로 정의하지 않으려면 사용 가능한 메모리에 따라 자동 인스턴스 크기 또는 유형 사용을 정의하는 주석을 추가해야 합니다.

사전 요구 사항

  • 클러스터에 OpenShift Container Platform 4.15를 설치했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.
  • 클라우드 공급자 고유의 시크릿 오브젝트 및 피어-pod ConfigMap 을 생성했습니다.
  • KataConfig CR(사용자 정의 리소스)을 생성했습니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 워크로드 를 확장하고 생성할 워크로드 유형을 선택합니다.
  2. 워크로드 페이지에서 워크로드를 생성하려면 클릭합니다.
  3. 워크로드에 대한 YAML 파일의 컨테이너가 나열된 spec 필드에 runtimeClassName: kata-remote 를 추가합니다.
  4. 워크로드의 YAML 파일에서 기본 인스턴스 크기 또는 유형 또는 자동 인스턴스 크기 또는 유형을 사용할지 여부를 정의하는 주석을 추가합니다. 인스턴스 크기는 특정 클라우드 공급자에 사용되지만 인스턴스 유형은 다른 클라우드 공급자에 사용됩니다.

    • 특정 인스턴스 크기 유형의 경우 다음 주석을 추가합니다.

      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는 인스턴스 유형을 사용합니다.
  5. 저장을 클릭합니다.

OpenShift Container Platform은 워크로드를 생성하고 스케줄링을 시작합니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.