OpenShift 샌드박스 컨테이너 지원

OpenShift Container Platform 4.8

OpenShift 샌드박스 컨테이너 가이드

Red Hat OpenShift Documentation Team

초록

OpenShift Container Platform의 OpenShift 샌드박스형 컨테이너 지원은 추가 옵션 런타임으로 Kata Containers를 실행하는 데 대한 기본 지원을 제공합니다.

1장. {sandboxed-containers-first} 1.0 릴리스 노트

1.1. 릴리스 정보

이 릴리스 노트에서는 Red Hat OpenShift Container Platform에서 OpenShift 샌드박스 컨테이너의 개발을 추적합니다.

이 제품은 현재 기술 프리뷰 상태입니다. OpenShift 샌드박스 컨테이너는 프로덕션용이 아닙니다. 자세한 내용은 기술 프리뷰의 기능에 대한 Red Hat 고객 포털 지원 범위를 참조하십시오.

1.2. 새로운 기능 및 개선 사항

1.2.1. OpenShift Container Platform에서 OpenShift 샌드박스 컨테이너 지원(기술 프리뷰)

OpenShift 샌드박스 컨테이너 1.0.0 기술 프리뷰 릴리스에서는 추가 런타임으로 Kata Containers를 실행할 수 있는 기능이 기본으로 제공됩니다. OpenShift 샌드박스 컨테이너를 사용하면 추가 런타임으로 Kata Containers를 선택하여 워크로드를 추가로 격리할 수 있습니다. OpenShift 샌드박스 컨테이너 Operator는 Kata Containers 설치, 제거 및 업데이트 작업을 자동화합니다. KataConfig 사용자 지정 리소스를 설명하여 해당 작업의 상태를 추적할 수 있습니다.

OpenShift 샌드박스 컨테이너는 베어 메탈에서만 지원됩니다. RHCOS(Red Hat Enterprise Linux CoreOS)는 OpenShift 샌드박스 컨테이너 1.0.0에서 유일하게 지원되는 운영 체제입니다. OpenShift Container Platform 4.8에서는 연결이 끊긴 환경이 지원되지 않습니다.

자세한 내용은 OpenShift 샌드박스 컨테이너 이해를 참조하십시오.

1.3. 확인된 문제

  • OpenShift 샌드박스 컨테이너를 사용하는 경우 OpenShift Container Platform 클러스터의 hostPath 볼륨을 사용하여 호스트 노드 파일 시스템의 파일 또는 디렉터리를 Pod에 마운트할 수 없습니다. 또는 로컬 영구 볼륨을 사용할 수 있습니다. 자세한 내용은 로컬 볼륨을 사용한 영구저장장치를 참조하십시오. (BZ#1904609)
  • OpenShift 샌드박스 컨테이너에서 Fedora를 실행하는 경우 일부 패키지를 설치하기 위한 대안이 필요합니다. iputils와 같은 일부 패키지에는 OpenShift Container Platform에서 기본적으로 컨테이너에 부여하지 않는 파일 액세스 권한을 변경해야 합니다. 이러한 특별한 권한이 필요한 컨테이너를 실행하려면 워크로드를 설명하는 YAML 파일에 주석을 추가하여 virtiofsd가 해당 워크로드에 대해 이러한 파일 권한을 수락하도록 지시합니다. 필요한 주석은 다음과 같습니다.

    io.katacontainers.config.hypervisor.virtio_fs_extra_args: |
      [ "-o", "modcaps=+sys_admin", "-o", "xattr" ]

    (BZ#1915377)

  • 4.8 릴리스에서는 OpenShift Container Platform 웹 콘솔을 사용하여 kataConfgPoolSelector에 값을 추가하면 scheduling.nodeSelector가 빈 값으로 설정됩니다. RuntimeClasskata 값으로 사용하는 Pod는 Kata Containers 런타임이 설치되지 않은 노드에 예약할 수 있습니다.

    이 문제를 해결하려면 다음 명령을 실행하여 RuntimeClass kata에서 nodeSelector 값을 수동으로 지정합니다.

    $ oc edit runtimeclass kata

    다음은 올바른 nodeSelector문을 사용하는 RuntimeClass의 예입니다.

    apiVersion: node.k8s.io/v1
    handler: kata
    kind: RuntimeClass
    metadata:
      creationTimestamp: "2021-06-14T12:54:19Z"
      name: kata
    overhead:
      podFixed:
        cpu: 250m
        memory: 350Mi
    scheduling:
      nodeSelector:
        custom-kata-pool: "true"

    (BZ#2019384)

  • Operator Hub의 OpenShift 샌드박스 컨테이너 Operator 세부 정보 페이지에는 몇 가지 누락된 필드가 포함되어 있습니다. 누락된 필드가 있는 경우에도 OpenShift 샌드박스 컨테이너 Operator를 4.8에서 설치할 수 있습니다. (BZ#2019383)
  • 여러 KataConfig 사용자 지정 리소스를 생성하면 자동으로 실패합니다. OpenShift Container Platform 웹 콘솔에서는 여러 사용자 정의 리소스를 생성하는 데 실패했음을 사용자에게 알리는 프롬프트를 제공하지 않습니다. (BZ#2019381)
  • OpenShift Container Platform 웹 콘솔의 Operator Hub에 Operator의 아이콘이 표시되지 않는 경우가 있습니다. (BZ#2019380)

1.4. 비동기 에라타 업데이트

OpenShift 샌드박스 컨테이너 1.0의 보안, 버그 수정 및 개선 업데이트는 Red Hat Network를 통해 비동기 에라타로 릴리스됩니다. 모든 OpenShift Container Platform 4.8 에라타는 Red Hat Customer Portal을 통해 제공됩니다. 비동기 에라타에 대한 자세한 내용은 OpenShift Container Platform 라이프 사이클에서 참조하십시오.

Red Hat Customer Portal 사용자는 Red Hat 서브스크립션 관리(RHSM) 계정 설정에서 에라타 통지를 활성화할 수 있습니다. 에라타 통지가 활성화되면 사용자는 등록된 시스템과 관련된 새 에라타가 릴리스될 때마다 이메일을 통해 통지를 받습니다.

참고

Red Hat Customer Portal 사용자 계정에는 OpenShift Container Platform에서 에라타 통지 이메일을 생성하기 위해 OpenShift Container Platform을 사용할 수 있는 등록된 시스템 및 권한이 필요합니다.

이 섹션은 향후 OpenShift 샌드박스 컨테이너 1.0.0의 비동기 에라타 릴리스의 개선 사항 및 버그 수정에 대한 정보 제공을 위해 지속적으로 업데이트됩니다.

1.4.1. RHBA-2021:3751 - OpenShift 샌드박스 컨테이너 1.0.2 버그 수정 권고

출시 날짜: 2021-10-07

OpenShift 샌드박스 컨테이너 릴리스 1.0.2가 공개되었습니다. 이 권고에는 버그 수정이 포함된 OpenShift 샌드박스 컨테이너에 대한 업데이트가 포함되어 있습니다.

업데이트에 포함된 버그 수정 목록은 RHBA-2021:3751 권고에 설명되어 있습니다.

1.4.2. RHBA-2021:3552 - OpenShift 샌드박스 컨테이너 1.0.1 버그 수정 권고

출시 날짜: 2021-09-16

OpenShift 샌드박스 컨테이너 릴리스 1.0.1이 공개되었습니다. 이 권고에는 버그 수정이 포함된 OpenShift 샌드박스 컨테이너에 대한 업데이트가 포함되어 있습니다.

업데이트에 포함된 버그 수정 목록은 RHBA-2021:3552 권고에 설명되어 있습니다.

1.4.3. RHEA-2021:2546 - OpenShift 샌드박스 컨테이너 1.0.0 이미지 릴리스, 버그 수정 및 개선 사항 권고

출시 날짜: 2021-07-29

OpenShift 샌드박스 컨테이너 릴리스 1.0.0 지원에서 OpenShift Container Platform 4.8의 구성 요소를 기술 프리뷰로 사용할 수 있습니다.

업데이트에 포함된 버그 수정 목록은 RHEA-2021:3941 권고에 설명되어 있습니다.

2장. OpenShift 샌드박스 컨테이너 이해

OpenShift Container Platform의 OpenShift 샌드박스형 컨테이너 지원은 추가 옵션 런타임으로 Kata Containers를 실행하는 데 대한 기본 지원을 제공합니다. 이 기능은 다음 작업을 수행하려는 사용자에게 유용합니다.

  • 권한이 있거나 신뢰할 수 없는 워크로드 실행
  • 각 워크로드에 대해 커널 분리를 보장
  • 테넌트 간에 동일한 워크로드를 공유
  • 소프트웨어 테스트를 위한 적절한 분리 및 샌드박스 확인
  • VM 경계를 통한 기본 리소스 제약을 확인

OpenShift 샌드박스 컨테이너를 사용하면 사용자가 실행할 워크로드 유형 중에서 선택하여 다양한 사용 사례를 처리할 수 있습니다.

OpenShift 샌드박스 컨테이너 Operator를 사용하여 설치 및 제거, 업데이트 및 상태 모니터링과 같은 작업을 수행할 수 있습니다.

샌드박스 컨테이너는 베어 메탈에서만 지원됩니다.

RHCOS(Red Hat Enterprise Linux CoreOS)는 OpenShift 샌드박스 컨테이너 1.0.0에서 유일하게 지원되는 운영 체제입니다.

2.1. OpenShift 샌드박스 컨테이너 일반 용어

설명서 전반에 걸쳐 다음 용어가 사용됩니다.

샌드 박스

샌드박스는 프로그램을 실행할 수 있는 격리된 환경입니다. 샌드박스에서는 호스트 시스템이나 운영 체제에 손상을 주지 않고 테스트되지 않았거나 신뢰할 수 없는 프로그램을 실행할 수 있습니다.

OpenShift 샌드박스 컨테이너의 경우 가상화를 사용하여 다른 커널에서 워크로드를 실행하여 동일한 호스트에서 실행되는 여러 워크로드 간의 상호 작용을 보다 효과적으로 제어할 수 있습니다.

Pod

Pod는 Kubernetes 및 OpenShift Container Platform에서 상속된 구성 요소입니다. 컨테이너를 배포할 수 있는 리소스를 나타냅니다. 컨테이너는 Pod 내부에서 실행되며 Pod는 여러 컨테이너 간에 공유할 수 있는 리소스를 지정하는 데 사용됩니다.

OpenShift 샌드박스 컨테이너의 컨텍스트에서 Pod가 가상 시스템으로 구현됩니다. 동일한 가상 시스템의 동일한 Pod에서 여러 컨테이너를 실행할 수 있습니다.

OpenShift 샌드박스 컨테이너 Operator

Operator는 시스템에서 수동으로 수행할 수 있는 작업을 자동화하는 소프트웨어 구성 요소입니다.

OpenShift 샌드박스 컨테이너 Operator는 클러스터에서 샌드박스 컨테이너의 라이프사이클을 관리하는 작업을 수행합니다. 샌드박스 컨테이너 소프트웨어의 설치 및 제거 및 상태 모니터링과 같은 작업을 처리합니다.

Kata 컨테이너
Kata 컨테이너는 OpenShift 샌드박스 컨테이너를 빌드하는 데 사용되는 핵심 업스트림 프로젝트입니다. OpenShift 샌드 박스 컨테이너는 Kata Container와 OpenShift Container Platform을 통합합니다.
KataConfig
KataConfig 오브젝트는 샌드박스 컨테이너의 구성을 나타냅니다. 소프트웨어가 배포된 노드와 같이 클러스터 상태에 대한 정보를 저장합니다.
RHCOS 확장
RHCOS(Red Hat Enterprise Linux CoreOS) 확장 기능은 선택적 옵션으로 OpenShift Container Platform 소프트웨어를 설치하기 위한 메커니즘입니다. OpenShift 샌드박스된 컨테이너 Operator는 이 메커니즘을 사용하여 클러스터에 샌드박스 컨테이너를 배포합니다.
런타임 클래스
RuntimeClass 오브젝트는 지정된 워크로드를 실행하는 데 사용할 수 있는 런타임에 대해 설명합니다. kata라는 런타임 클래스가 OpenShift 샌드박스 컨테이너 Operator에 의해 설치 및 배포됩니다. 런타임 클래스에는 Pod 오버헤드와 같이 런타임에서 작동해야 하는 리소스를 설명하는 런타임에 대한 정보가 포함되어 있습니다.

2.2. OpenShift 샌드박스 컨테이너 빌딩 블록

OpenShift 샌드박스 컨테이너 Operator는 Kata 컨테이너의 모든 구성 요소를 캡슐화합니다. 설치, 라이프사이클 및 구성 작업을 관리합니다.

OpenShift 샌드박스 컨테이너 Operator는 Operator 번들 형식으로 두 개의 컨테이너 이미지로 패키지화되어 있습니다. 번들 이미지에는 Operator OLM을 준비하는데 필요한 메타데이터가 포함되어 있습니다. 두 번째 컨테이너 이미지에는 KataConfig 리소스를 모니터링하고 관리하는 실제 컨트롤러가 포함되어 있습니다.

2.3. RHCOS 확장

OpenShift 샌드박스된 컨테이너 Operator는 RHCOS(Red Hat Enterprise Linux CoreOS) 확장 개념을 기반으로 합니다. 샌드박스 컨테이너 RHCOS 확장에는 Kata, QEMU 및 종속 항목에 대한 RPM이 포함되어 있습니다. Machine Config Operator에서 제공하는 MachineConfig 리소스를 사용하여 활성화할 수 있습니다.

3장. OpenShift 샌드박스 컨테이너 워크로드 배포

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

3.1. OpenShift 샌드박스 컨테이너용 클러스터 준비

OpenShift 샌드박스 컨테이너를 설치하기 전에 OpenShift Container Platform 클러스터가 다음 요구 사항을 충족하는지 확인하십시오.

  • Red Hat Enterprise Linux CoreOS(RHCOS) 작업자가 있는 베어 메탈 인프라에 클러스터가 설치되어 있어야 합니다. 클러스터는 설치 프로그램이 프로비저닝한 인프라를 사용해야 합니다.

    중요
    • OpenShift 샌드박스 컨테이너는 RHCOS 작업자 노드만 지원합니다. RHEL 7 또는 RHEL 8 노드는 지원되지 않습니다.
    • 중첩된 가상화는 지원되지 않습니다.

3.1.1. OpenShift 샌드박스 컨테이너에 대한 기타 리소스 요구 사항

OpenShift 샌드박스 컨테이너는 Kata Containers와 같은 샌드박스 런타임 내에서 OpenShift Container Platform 클러스터에 대한 워크로드를 실행할 수 있는 제품입니다. 각 Pod는 VM(가상 머신)으로 표시됩니다. 각 VM은 qemu 프로세스에서 실행되며 해당 컨테이너에서 실행 중인 컨테이너 워크로드 및 프로세스를 관리하기 위한 감독자 역할을 하는 kata-agent 프로세스를 호스팅합니다. 오버헤드를 증가시키는 두 개의 추가 프로세스가 있습니다.

  • containerd-shim-kata-v2는 pod와 통신하는 데 사용됩니다.
  • virtiofsd는 게스트 대신 호스트 파일 시스템 액세스를 처리합니다.

각 VM은 기본 메모리 양으로 구성됩니다. 메모리를 명시적으로 요청하는 컨테이너의 경우 VM에 추가 메모리가 핫플러그됩니다.

  • 지정된 메모리 리소스 없이 컨테이너가 실행되면 사용 가능한 메모리를 사용할 수 있습니다. VM에서 사용하는 총 메모리가 기본 할당에 도달할 때까지 이 작업을 수행합니다. 게스트와 I/O 버퍼도 메모리를 소비합니다.
  • 컨테이너에 특정 양의 메모리가 제공되면 컨테이너를 시작하기 전에 해당 메모리는 VM에 핫플러그됩니다.
  • 메모리 제한을 지정하면 제한보다 많은 메모리를 사용하는 경우 워크로드가 종료됩니다. 메모리 제한이 지정되지 않은 경우 가상 시스템에서 실행 중인 커널에 메모리가 부족해질 수 있습니다. 커널 메모리가 부족하면 가상 시스템의 다른 프로세스를 종료할 수 있습니다.

기본 메모리 크기

다음 표에는 리소스 할당에 대한 기본값이 나열되어 있습니다.

리소스현재의

기본적으로 가상 머신에 할당된 메모리

2Gi

부팅 시 게스트 Linux 커널 메모리 사용량

~110Mi

QEMU 프로세스에서 사용하는 메모리 (VM 메모리 제외)

~30Mi

virtiofsd 프로세스에서 사용하는 메모리(VM I/O 버퍼 제외)

~10Mi

containerd-shim-kata-v2 프로세스에서 사용하는 메모리

~20Mi

Fedora에서 dnf install을 실행한 후 파일 버퍼 캐시 데이터

~300Mi* [1]

  1. 파일 버퍼가 나타나고 다음과 같은 여러 위치에서 고려됩니다.

    • 게스트에서 파일 버퍼 캐시로 표시
    • 허용된 사용자 공간 파일 I/O 작업을 매핑된 virtiofsd 데몬
    • 게스트 메모리로 사용되는 QEMU 프로세스
참고

총 메모리 사용량은 메모리 사용량 통계에 따라 적절히 계산되며, 이 메트릭은 해당 메모리를 한 번만 계산합니다.

Pod 오버헤드는 노드의 Pod에서 사용하는 시스템 리소스의 양을 설명합니다. 아래와 같이 oc describe runtimeclass kata를 사용하여 kata 런타임 클래스에 대한 현재 Pod 오버헤드를 가져올 수 있습니다.

예제

$ oc describe runtimeclass kata

출력 예

Name:         kata
[...]
Metadata:
[...]
Overhead:
  Pod Fixed:
    Cpu:     250m
    Memory:  350Mi
[...]

RuntimeClassspec.overhead 필드를 변경하여 Pod 오버헤드를 변경할 수 있습니다. 예를 들어 컨테이너에 대한 구성이 QEMU 프로세스 및 게스트 커널 데이터에 대해 350Mi 이상의 메모리를 사용하는 경우 필요에 맞게 RuntimeClass 오버헤드를 변경할 수 있습니다.

참고

Red Hat은 지정된 기본 오버헤드 값을 지원합니다. 기본 오버헤드 값 변경은 지원되지 않으며 값을 변경하면 기술적인 문제가 발생할 수 있습니다.

예제

kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
  name: kata
overhead:
  podFixed:
    memory: "500Mi"
    cpu: "500m"

  • 가상 시스템의 기본 할당은 2Gi입니다.
  • Linux 커널은 부팅 시 약 100Mi의 메모리를 사용합니다.
  • QEMU 프로세스는 약 30Mi 의 메모리를 사용합니다.
  • virtiofsd 프로세스는 약 10Mi의 메모리를 사용합니다.
  • shim-v2 프로세스는 약 20Mi 메모리를 사용합니다.

게스트에서 모든 유형의 파일 시스템 I/O를 수행할 때 게스트 커널에 파일 버퍼가 할당됩니다. 파일 버퍼는 호스트의 QEMU 프로세스 및 virtiofsd 프로세스에도 매핑됩니다. 예를 들어 게스트에서 300Mi 파일 버퍼 캐시를 사용하는 경우 QEMU와 virtiofsd는 모두 300Mi 추가 메모리를 사용하는 것처럼 나타납니다. 그러나 세 가지 경우 모두 동일한 메모리가 사용됩니다. 즉, 총 메모리 사용량은 300Mi에 불과하며 이 값은 서로 다른 세 위치에 매핑됩니다. 이는 메모리 사용량 메트릭을 보고할 때 올바르게 계산됩니다.

3.2. 웹 콘솔을 사용하여 OpenShift 샌드박스 컨테이너 Operator 배포

Operator를 설치하고 웹 콘솔에서 워크로드를 볼 수 있습니다.

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

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

사전 요구 사항

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

절차

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

    1. 사용 가능한 업데이트 채널 옵션 목록에서 preview-1.0을 선택합니다. 이렇게 하면 OpenShift Container Platform 버전과 호환되는 OpenShift 샌드박스 컨테이너 버전을 설치할 수 있습니다.
    2. 설치된 네임스페이스의 경우 Operator 권장 네임스페이스 옵션이 선택되어 있는지 확인합니다. 그러면 필수 openshift-sandboxed-containers-operator 네임스페이스에 Operator가 설치됩니다. 해당 네임스페이스가 존재하지 않는 경우 자동으로 생성됩니다.

      참고

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

    3. 승인 전략의 경우 기본값인 자동이 선택되어 있는지 확인합니다. OpenShift 샌드박스 컨테이너는 새로운 z-stream 릴리스가 출시되면 자동으로 업데이트됩니다.
  7. OpenShift 샌드박스 컨테이너 네임스페이스에서 Operator를 사용할 수 있도록 설치를 클릭합니다.

OpenShift 샌드박스 컨테이너 Operator가 클러스터에 설치되었습니다. 클러스터에서 런타임을 활성화하여 Operator를 트리거할 수 있습니다. OpenShift CLI(oc)를 사용하여 KataConfig 사용자 지정 리소스를 생성할 수 있습니다.

apiVersion: kataconfiguration.openshift.io/v1
kind: KataConfig
metadata:
  name: example-kataconfig

3.2.2. 웹 콘솔에서 OpenShift 샌드박스 컨테이너 워크로드 보기

OpenShift 샌드박스 컨테이너 기반 워크로드는 웹 콘솔에서 볼 때 일반적인 워크로드와 동일하게 보입니다. 두 항목의 유일한 차이점은 runtimeClassName입니다. runtimeClassName은 워크로드에 사용되는 런타임을 결정합니다. 이 컨텍스트에서 OpenShift 샌드박스 컨테이너에 의해 활성화된 런타임은 kata입니다. 워크로드에 대한 Pod가에서 사용하는 runtimeClass를 볼 수 있습니다.

사전 요구 사항

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

절차

  1. 관리워크로드로 이동합니다.
  2. 세부 정보를 확인할 워크로드 유형을 식별합니다. 예를 들어 Pod, Deployment, DeploymentConfigs 오브젝트 등이 있습니다.
  3. 목록에서 해당 워크로드를 선택합니다.
  4. 세부 정보 페이지에서 runtimeClass로 이동합니다.
  5. runtimeClass 위에 마우스를 올려 놓으면 자세한 정보를 볼 수 있습니다. kata를 런타임으로 사용한 경우 runtimeClass의 값은 kata입니다.

3.3. CLI를 사용하여 OpenShift 샌드박스 컨테이너 Operator 배포

Operator를 설치 및 배포하고 CLI에서 워크로드를 볼 수 있습니다.

3.3.1. CLI를 사용하여 OpenShift 샌드박스 컨테이너 Operator 설치

OpenShift 샌드박스 컨테이너 Operator는 OpenShift Container Platform CLI를 사용하여 설치할 수 있습니다.

사전 요구 사항

  • 클러스터에 OpenShift Container Platform 4.8을 설치합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift 샌드박스 컨테이너 카탈로그를 구독하고 있습니다.

    참고

    OpenShift 샌드박스 컨테이너 카탈로그를 구독하면 openshift-sandboxed-containers-operator 네임스페이스에서 OpenShift 샌드박스 컨테이너 Operator에 액세스할 수 있습니다.

절차

  1. 다음 매니페스트를 포함하는 YAML 파일을 만듭니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sandboxed-containers-operator
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-sandboxed-containers-kataconfig-group
      namespace: openshift-sandboxed-containers-operator
    spec:
      targetNamespaces:
        - openshift-sandboxed-containers-operator
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sandboxed-containers-operatorhub
      namespace: openshift-sandboxed-containers-operator
    spec:
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      name: sandboxed-containers-operator
      startingCSV: sandboxed-containers-operator.v1.0.0
      channel: "preview-1.0"
      approval: "Automatic"
    참고

    preview-1.0 채널을 사용하면 OpenShift Container Platform 버전과 호환되는 OpenShift 샌드박스 컨테이너 버전을 설치할 수 있습니다.

  2. 다음 명령을 실행하여 OpenShift 샌드박스 컨테이너에 필요한 Namespace, OperatorGroupSubscription 오브젝트를 생성합니다.

    $ oc create -f <file name>.yaml
  3. Operator가 올바르게 설치되었는지 확인합니다.

    $ oc get csv -n openshift-sandboxed-containers-operator

    출력 예

    NAME                             DISPLAY                                  VERSION  REPLACES                    PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.0.0    <csv-of-previous-version>   Succeeded

  4. 사용 가능한 배포를 확인합니다.

    $ oc get deployments -n openshift-sandboxed-containers-operator

    출력 예

    NAME                                        READY  UP-TO-DATE   AVAILABLE   AGE
    openshift-sandboxed-containers-operator                         1/111       9m48s

검증

  • KataConfig 리소스를 생성하여 설치를 트리거할 수 있도록 Operator가 실행 중인지 확인합니다.

    $ oc get deployments -n openshift-sandboxed-containers-operator

    출력 예

    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    openshift-sandboxed-containers-controller-manager   1/1     1            1           40d

3.3.1.1. Kata 런타임 설치 트리거

다음을 수행하려면 OpenShift 샌드박스 컨테이너 Operator를 트리거하려면 하나의 KataConfig CR( 사용자 정의 리소스)을 생성해야 합니다.

  • RHCOS 노드에 QEMU 및 kata-containers 와 같은 필요한 RHCOS 확장을 설치합니다.
  • 런타임 CRI-O가 올바른 Kata 런타임 핸들러로 구성되었는지 확인합니다.
  • 가상화로 인한 추가 오버헤드 및 필요한 추가 프로세스에 대해 필요한 구성으로 RuntimeClass 사용자 지정 리소스를 생성합니다.

사전 요구 사항

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

절차

  1. KataConfig 리소스를 생성합니다.

    $ oc create -f <file name>.yaml

    예제

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig

  2. 설치 진행 상황을 모니터링합니다.

    • KataConfig 설치를 설명할 수 있습니다.

      $ oc describe kataconfig
      • 상태에서 완료된 노드 필드를 확인합니다.
      • 완료된 노드 값이 작업자 노드 수와 일치하는 경우 설치가 완료됩니다. 상태에는 설치가 완료된 노드 목록도 포함됩니다.
    • KataConfig 리소스를 확인하여 설치 진행 상황을 확인할 수 있습니다.

      $ watch -n 10 oc describe kataconfig

      또는 KataConfig 리소스의 상태를 확인할 수 있습니다. 이 작업은 oc get KataConfig <name> -oyaml을 실행하고 출력에서 status 필드를 검사하여 수행할 수 있습니다.

이제 Kata 런타임이 클러스터에 설치되어 보조 런타임으로 사용할 수 있습니다. 클러스터에서 Kata에 대해 새로 생성된 RuntimeClass가 표시되는지 확인합니다.

중요

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

검증

  • 다음을 실행하여 KataConfig 사용자 정의 리소스의 값을 모니터링할 수 있습니다.

    $ watch oc describe KataConfig cluster-kataconfig

추가 리소스

3.3.1.2. OpenShift 샌드박스 컨테이너의 노드 선택

특정 작업자에 Kata 런타임을 선택적으로 설치할 수 있습니다.

사전 요구 사항

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

절차

  1. 노드를 선택하는 데 사용할 레이블을 확인합니다. 이 예에서는 레이블을 사용하여 OpenShift 샌드박스 컨테이너 워크로드에서 실행할 후보로 선택할 수 있습니다. 노드가 있으면 선택됩니다.

    1. 노드에 레이블을 적용하려면 다음 명령을 실행합니다.

      $ oc label node <worker_node_name> <label>=<value>

      이렇게 하면 값이 <value><label> 레이블이 있는 작업자 노드에 레이블이 지정됩니다.

  2. 레이블 선택기를 추가하려면 KataConfig CR(사용자 정의 리소스)을 편집합니다.

    $ oc edit kataconfig

    예제

      apiVersion: kataconfiguration.openshift.io/v1
      kind: KataConfig
      metadata:
        name: cluster-kataconfig
      spec:
        kataConfigPoolSelector:
          matchLabels:
             custom-kata-machine-pool: 'true'

검증

  • machine-config-pool 오브젝트의 노드가 구성 업데이트를 통해 수행하는지 확인할 수 있습니다.

    • 기본 노드를 사용하는 경우 다음을 실행하여 machine-config-pool 리소스를 모니터링할 수 있습니다.

      $ watch oc get mcp worker
    • 선택한 노드를 사용하는 경우 다음을 실행하여 machine-config-pool 리소스를 모니터링할 수 있습니다.

      $ watch oc get mcp kata-oc
  • watch oc describe kataconfig cluster-kataconfig를 실행하여 노드의 sandboxed-containers 확장 실패에 대한 정보를 표시할 수 있습니다. 정보는 machine-config-pool 오브젝트의 상태에서 수집됩니다. 다음을 실행하여 정보를 볼 수 있습니다.

    $ oc describe mcp <machine-config-pool>

3.3.1.3. OpenShift 샌드박스 컨테이너 워크로드 예약

OpenShift 샌드박스 컨테이너에서 실행되도록 워크로드를 예약할 수 있습니다.

사전 요구 사항

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

절차

  1. pod 템플릿 리소스에 runtimeClassName: kata를 추가합니다.

    • Pod 오브젝트
    • ReplicaSet 오브젝트
    • ReplicationController 오브젝트
    • StatefulSet 오브젝트
    • Deployment 오브젝트
    • DeploymentConfig 오브젝트

Pod 오브젝트의 예

  apiVersion: v1
  kind: Pod
  metadata:
   name: mypod
  spec:
    runtimeClassName: kata

Deployment 오브젝트의 예

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: mypod
    labels:
      app: mypod
  spec:
    replicas: 3
    selector:
      matchLabels:
        app: mypod
    template:
      metadata:
        labels:
          app: mypod
      spec:
        runtimeClassName: kata
        containers:
        - name: mypod
          image: myImage

pod 템플릿 리소스가 runtimeClassName: kata를 사용하여 생성된 후 OpenShift Container Platform은 OpenShift 샌드박스 컨테이너에서 활성화된 노드의 워크로드 예약을 시작합니다. 선택기를 사용하지 않으면 기본값은 모든 작업자 노드로 설정됩니다. 워크로드는 OpenShift 샌드박스 컨테이너에서 실행됩니다.

3.3.2. CLI에서 OpenShift 샌드박스 컨테이너 워크로드 보기

CLI에서 워크로드에 사용된 Pod의 runtimeClass를 볼 수 있습니다.

사전 요구 사항

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

절차

  • pod의 runtimeClassName 필드를 검사하여 일반 컨테이너와 OpenShift 샌드박스 컨테이너에서 실행되는 pod를 확인합니다.

    • 노드에서 각 pod에는 해당 qemu 프로세스가 있습니다.

검증

  • openshift-sandboxed-containers-operator 컨트롤러 Pod의 로그를 확인하여 실행 중인 단계에 대한 자세한 메시지를 확인할 수 있습니다.

    • 다음을 실행하여 컨트롤러 Pod의 이름을 검색할 수 있습니다.

      $ oc get pods -n openshift-sandboxed-containers-operator | grep openshift-sandboxed-containers-operator-controller-manager

      이를 통해 해당 pod의 컨테이너 관리자 로그를 모니터링할 수 있습니다.

4장. OpenShift 샌드박스 컨테이너 설치 제거

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

OpenShift Container Platform 웹 콘솔을 사용하여 OpenShift 샌드박스 컨테이너를 설치 제거할 수 있습니다.

4.1.1. OpenShift 샌드박스 컨테이너 리소스 삭제

OpenShift 샌드박스 컨테이너를 설치 제거하려면 먼저 OpenShift 샌드박스 컨테이너 사용자 지정 리소스 KataConfig를 삭제해야 합니다. 이렇게 하면 클러스터에서 kata 런타임 및 관련 리소스가 제거 및 설치 제거됩니다.

사전 요구 사항

  • 클러스터에 OpenShift Container Platform 4.8을 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • kataruntimeClassName으로 사용하는 실행 중인 Pod가 없습니다.

    • OpenShift CLI(oc)가 설치되어 있습니다.
    • 명령줄 JSON 프로세서(jq)가 설치되어 있어야 합니다.
    • 다음 명령을 실행하여 kataruntimeClassName으로 사용하는 실행 중인 Pod가 없는지 확인합니다.

      $ oc get pods -A -o json | jq -r '.items[] | select(.spec.runtimeClassName | test("kata")).metadata.name'

절차

  1. 값이 kataruntimeClassName을 사용하는 모든 Pod를 삭제합니다.
  2. OpenShift Container Platform 웹 콘솔의 프로젝트 목록에서 openshift-sandboxed-containers를 선택합니다.
  3. Operator설치된 Operator 페이지로 이동합니다.
  4. OpenShift 샌드박스 컨테이너를 클릭합니다.
  5. OpenShift 샌드박스 컨테이너 Operator 탭을 클릭합니다.
  6. Operator 세부 정보에서 스크롤 다운 목록을 클릭한 다음 KataConfig 삭제를 클릭합니다.
  7. 확인 창에서 삭제를 클릭합니다.

4.1.1.1. 웹 콘솔을 사용하여 네임스페이스 삭제

OpenShift Container Platform 웹 콘솔을 사용하여 네임스페이스를 삭제할 수 있습니다.

사전 요구 사항

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

절차

  1. 관리네임스페이스로 이동합니다.
  2. 네임스페이스 목록에서 삭제할 openshift-sandboxed-containers-operator 네임스페이스를 찾습니다.
  3. 네임스페이스 목록의 맨 오른쪽에 있는 옵션 메뉴에서 네임스페이스 삭제를 선택합니다.
  4. 네임스페이스 삭제 창이 열리면 필드에 openshift-sandboxed-containers-operator를 입력합니다.

    참고

    네임스페이스 삭제 옵션을 사용할 수 없으면 네임스페이스를 삭제할 수 있는 권한이 없음을 의미합니다.

  5. 삭제를 클릭합니다.

4.1.2. OpenShift 샌드박스 컨테이너 Operator 삭제

카탈로그 서브스크립션을 삭제하고 Operator에 대한 네임스페이스 액세스를 취소하여 OpenShift 샌드박스 컨테이너 Operator를 삭제할 수 있습니다.

사전 요구 사항

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

절차

  1. OperatorOperatorHub 페이지로 이동합니다.
  2. OpenShift 샌드박스 컨테이너를 검색한 다음 Operator를 선택합니다.
  3. 제거를 클릭합니다.
  4. openshift-sandboxed-containers-operator 네임스페이스를 삭제합니다.

4.2. CLI에서 Kata 런타임 설치 제거

OpenShift Container Platform CLI(명령줄 인터페이스)를 사용하여 OpenShift 샌드박스 컨테이너를 제거할 수 있습니다.

4.2.1. OpenShift 샌드박스 컨테이너 리소스 삭제

클러스터에서 kata 런타임 및 CRI-O 구성 및 RuntimeClass 와 같은 모든 관련 리소스를 제거하고 설치 제거할 수 있습니다.

사전 요구 사항

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

절차

  1. 다음 명령을 실행하여 KataConfig 사용자 지정 리소스를 삭제합니다.

    $ oc delete kataconfig <KataConfig_CR_Name>
  2. 다음 명령을 실행하여 KataConfig 사용자 지정 리소스 정의를 삭제합니다.

    $ oc delete crd kataconfigs.kataconfiguration.openshift.io

OpenShift 샌드박스된 컨테이너 Operator는 클러스터에서 런타임을 활성화하기 위해 처음 생성된 모든 리소스를 제거합니다. 이전 명령을 실행하면 클러스터가 설치 프로세스 이전의 상태로 복원됩니다. 이제 openshift-sandboxed-containers-operator 네임스페이스를 삭제할 수 있습니다.

검증

  • KataConfig 사용자 지정 리소스가 삭제되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get kataconfig <KataConfig_CR_Name>

    출력 예

    No KataConfig instances exist

  • KataConfig 사용자 지정 리소스 정의가 삭제되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get crd kataconfigs.kataconfiguration.openshift.io

    출력 예

    Unknown CR KataConfig

4.2.2. OpenShift 샌드박스 컨테이너 Operator 삭제

클러스터에서 OpenShift 샌드박스 컨테이너 Operator를 삭제할 수 있습니다.

사전 요구 사항

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

절차

  1. 다음 명령을 실행하여 OLM(Operator Lifecyle Manager)에서 OpenShift 샌드박스 컨테이너 Operator 서브스크립션을 삭제합니다.

    $ oc delete subscription openshift-sandboxed-containers-subscription -n openshift-sandboxed-containers-operator
  2. 다음 명령을 실행하여 OpenShift 샌드박스 컨테이너의 CSV(클러스터 서비스 버전) 이름을 환경 변수로 설정합니다.

    CSV_NAME=$(oc get csv -n openshift-sandboxed-containers-operator -o=custom-columns=:metadata.name)
  3. 다음 명령을 실행하여 OpenShift 샌드박스 컨테이너의 CSV 이름을 삭제합니다.

    $ oc delete csv ${CSV_NAME} -n openshift-sandboxed-containers-operator

5장. OpenShift 샌드박스 컨테이너 업그레이드

OpenShift 샌드박스 컨테이너 Operator 및 OpenShift 샌드박스 컨테이너 아티팩트를 업그레이드하여 OpenShift 샌드박스 컨테이너의 구성 요소를 업그레이드할 수 있습니다.

5.1. OpenShift 샌드박스 컨테이너 Operator 업그레이드

OLM(Operator Lifecycle Manager)을 사용하여 OpenShift 샌드박스된 컨테이너 Operator를 수동으로 또는 자동으로 업그레이드할 수 있습니다. 초기 배포 중에 수동 또는 자동 업그레이드를 선택할 수 있습니다. 수동 업그레이드의 경우 웹 콘솔에는 클러스터 관리자가 설치할 수 있는 사용 가능한 업데이트가 표시됩니다.

5.2. OpenShift 샌드박스 컨테이너 아티팩트 업그레이드

OpenShift 샌드박스 컨테이너 아티팩트는 RHCOS(Red Hat Enterprise Linux CoreOS) 확장을 사용하여 클러스터에 배포됩니다.

RHCOS 확장 sandboxed containers에는 Kata 컨테이너 런타임, 하이퍼바이저 QEMU 및 기타 종속 항목과 같은 Kata 컨테이너를 실행하는 데 필요한 구성 요소가 포함되어 있습니다. 클러스터를 새 OpenShift Container Platform 릴리스로 업그레이드하면 확장 기능이 업그레이드됩니다.

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.