OpenShift 샌드박스 컨테이너 지원

OpenShift Container Platform 4.9

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

Red Hat OpenShift Documentation Team

초록

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

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

1.1. 릴리스 정보

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

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

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

1.2.1. FIPS 호환성

이제 OpenShift 샌드박스 컨테이너에 대해 FIPS 모드가 자동으로 활성화됩니다. FIPS 모드에 설치된 OpenShift Container Platform 클러스터에 배포된 OpenShift 샌드박스 컨테이너는 클러스터의 FIPS 지원에 영향을 미치지 않습니다. 자세한 내용은 컴플라이언스 및 위험 관리 이해를 참조하십시오.

1.2.2. must-gather로 리소스 수집

OpenShift 샌드박스 컨테이너 Operator에 must-gather 이미지가 포함되어 진단 목적으로 이 Operator 및 기본 런타임 구성 요소와 관련된 사용자 정의 리소스 및 로그 파일을 수집할 수 있습니다. 자세한 내용은 Red Hat 지원에 대한 OpenShift 샌드박스 컨테이너 데이터 수집을 참조하십시오.

1.2.3. 연결이 끊긴 환경

이제 연결이 끊긴 환경에 OpenShift 샌드박스 컨테이너 Operator를 설치할 수 있습니다. 자세한 내용은 OpenShift 샌드박스 컨테이너 워크로드 배포에 대한 추가 리소스를 참조하십시오.

1.3. 버그 수정

  • 이전 버전에서는 OpenShift 샌드박스 컨테이너에서 Fedora를 실행할 때 일부 패키지에는 OpenShift Container Platform에서 기본적으로 컨테이너에 부여하지 않은 파일 액세스 권한 변경 사항이 필요했습니다. 이번 릴리스에서는 이러한 권한은 기본적으로 부여됩니다. (BZ#1915377)
  • 이전 버전에서는 OpenShift Container Platform 웹 콘솔의 kataConfgPoolSelector 에 값을 추가하면 scheduling.nodeSelector 가 빈 값으로 채워집니다. 결과적으로 kata 값으로 RuntimeClass 오브젝트를 사용하는 Pod를 Kata Containers 런타임을 설치하지 않은 상태로 예약할 수 있었습니다. 이번 릴리스에서는 kataConfgPoolSelector 에 정의된 것과 동일한 레이블이 지정된 노드만 Kata Containers 런타임을 설치합니다. (BZ#2019384)
  • 이전 버전에서는 Operator Hub의 OpenShift 샌드박스 컨테이너 Operator 세부 정보 페이지에 필드가 누락되었습니다. 이번 릴리스에서는 이러한 필드가 더 이상 누락되지 않습니다. (BZ#2019383)
  • 이전 버전에서는 여러 KataConfig 사용자 지정 리소스를 생성하면 자동으로 실패하고 OpenShift Container Platform 웹 콘솔에서 사용자가 두 개 이상의 사용자 정의 리소스를 생성하는 것을 알리는 오류가 발생하지 않았습니다. 이번 릴리스에서는 여러 사용자 정의 리소스를 생성하려고 할 때 오류가 발생합니다. (BZ#2019381)
  • 이전에는 OpenShift Container Platform 웹 콘솔의 Operator Hub에 Operator에 대한 아이콘을 표시하지 않은 인스턴스가 있었습니다. 이번 릴리스에서는 항상 아이콘이 표시됩니다. (BZ#9019380)

1.4. 확인된 문제

  • OpenShift 샌드박스 컨테이너를 사용하는 경우 OpenShift Container Platform 클러스터의 hostPath 볼륨에서 마운트된 파일 또는 디렉터리에 액세스하는 SELinux 거부가 표시될 수 있습니다. 권한 있는 샌드박스 컨테이너를 실행할 때 권한 있는 샌드박스 컨테이너가 SELinux 검사를 비활성화하지 않으므로 이러한 거부가 발생할 수 있습니다.

    호스트의 SELinux 정책을 따라 기본적으로 샌드박스 워크로드에서 호스트 파일 시스템을 완전히 분리할 수 있으며 virtiofsd 또는 QEMU의 잠재적인 보안 결함에 대해 보다 강력한 보호 기능을 제공합니다.

    마운트된 파일 또는 디렉터리에 호스트에 특정 SELinux 요구 사항이 없는 경우 대신 로컬 영구 볼륨을 사용할 수 있습니다. 컨테이너 런타임에 대한 SELinux 정책에 따라 파일이 container_file_t 로 자동 레이블이 다시 지정됩니다. 자세한 내용은 로컬 볼륨을 사용한 영구저장장치를 참조하십시오.

    자동 레이블 지정은 마운트된 파일 또는 디렉터리가 호스트에 특정 SELinux 레이블이 있을 것으로 예상되는 경우 옵션이 아닙니다. 대신 virtiofsd가 이러한 특정 라벨에 액세스할 수 있도록 호스트에서 사용자 지정 SELinux 규칙을 설정할 수 있습니다. (BZ#1904609)

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

OpenShift 샌드박스 컨테이너 4.9의 보안, 버그 수정 및 개선 업데이트는 Red Hat Network를 통해 비동기 에라타로 릴리스됩니다. 모든 OpenShift Container Platform 4.9 에라타는 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.1.0과 관련된 비동기 에라타 릴리스의 개선 사항 및 버그 수정에 대한 정보 제공을 위해 지속적으로 업데이트됩니다.

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

출시 날짜: 2021-10-21

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

업데이트에 포함된 버그 수정 목록은 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 리소스를 사용하여 활성화할 수 있습니다.

2.4. 컴플라이언스 및 위험 관리 이해

OpenShift 샌드박스 컨테이너는 FIPS가 활성화된 클러스터에서 사용할 수 있습니다.

FIPS 모드에서 실행되는 경우 OpenShift 샌드박스 컨테이너 구성 요소, VM 및 VM 이미지가 FIPS를 준수하도록 조정됩니다.

FIPS 컴플라이언스는 보안 수준이 높은 환경에서 요구되는 가장 중요한 구성요소 중 하나로, 지원되는 암호화 기술만 노드에서 허용합니다.

중요

FIPS 검증 / 진행중인 모듈 암호화 라이브러리 사용은 x86_64 아키텍처의 OpenShift Container Platform 배포에서만 지원됩니다.

OpenShift Container Platform 컴플라이언스 프레임워크에 대한 Red Hat의 관점을 이해하려면 OpenShift 보안 가이드의 위험 관리 및 규제 준비 장을 참조하십시오.

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

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

3.1. 사전 요구 사항

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

  • Red Hat Enterprise Linux CoreOS (RHCOS) 작업자를 사용하여 온프레미스에 베어 메탈 인프라에 클러스터가 설치되어 있어야 합니다.

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

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

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

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

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

메모리 리소스 없이 실행되는 컨테이너는 VM에서 사용하는 총 메모리가 기본 할당에 도달할 때까지 사용 가능한 메모리를 사용합니다. 게스트와 I/O 버퍼도 메모리를 소비합니다.

컨테이너에 특정 양의 메모리가 제공되면 컨테이너를 시작하기 전에 해당 메모리는 VM에 핫플러그됩니다.

메모리 제한을 지정하면 제한보다 많은 메모리를 사용하는 경우 워크로드가 종료됩니다. 메모리 제한을 지정하지 않으면 VM에서 실행 중인 커널에 메모리가 부족해질 수 있습니다. 커널이 메모리가 부족하면 VM의 다른 프로세스를 종료할 수 있습니다.

기본 메모리 크기

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

리소스현재의

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

2Gi

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

~110Mi

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

~30Mi

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

~10Mi

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

~20Mi

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

~300Mi* [1]

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

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

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

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

예제

$ oc describe runtimeclass kata

출력 예

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

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

참고

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

게스트에서 모든 유형의 파일 시스템 I/O를 수행할 때 게스트 커널에 파일 버퍼가 할당됩니다. 파일 버퍼는 호스트의 QEMU 프로세스 및 virtiofsd 프로세스에도 매핑됩니다.

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

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

웹 콘솔에서 OpenShift 샌드박스 컨테이너 워크로드를 배포할 수 있습니다. 먼저 OpenShift 샌드박스 컨테이너 Operator를 설치한 다음 KataConfig CR(사용자 정의 리소스)을 생성해야 합니다. 샌드박스 컨테이너에 워크로드를 배포할 준비가 되면 kata 를 워크로드 YAML 파일에 runtimeClassName 으로 수동으로 추가해야 합니다.

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

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

사전 요구 사항

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

절차

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

    1. 사용 가능한 업데이트 채널 옵션 목록에서 preview-1.1 을 선택합니다.
    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. 웹 콘솔에서 KataConfig 사용자 지정 리소스 생성

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

사전 요구 사항

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

Kata는 기본적으로 모든 작업자 노드에 설치됩니다. kata 를 특정 노드에만 RuntimeClass 로 설치하려면 해당 노드에 라벨을 추가한 다음 이를 생성할 때 KataConfig CR에 라벨을 정의할 수 있습니다.

절차

  1. 웹 콘솔의 관리자 화면에서 Operator → 설치된 Operator 로 이동합니다.
  2. Operator 목록에서 OpenShift 샌드박스 컨테이너 Operator를 선택합니다.
  3. KataConfig 탭에서 KataConfig 만들기를 클릭합니다.
  4. KataConfig 생성 페이지에서 YAML 보기를 통해 KataConfig CR을 구성하려면 선택합니다.
  5. 다음 매니페스트를 복사하여 YAML 보기에 붙여넣습니다.

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

    kata 를 선택한 노드에만 RuntimeClass 로 설치하려면 매니페스트에 라벨을 포함합니다.

     apiVersion: kataconfiguration.openshift.io/v1
     kind: KataConfig
     metadata:
       name: cluster-kataconfig
     spec:
       kataConfigPoolSelector:
         matchLabels:
          <label_key>: '<label_value>' 1
    1
    kataConfigPoolSelector 의 라벨은 단일 값만 지원합니다. nodeSelector 구문은 지원되지 않습니다.
  6. 생성을 클릭합니다.

KataConfig CR이 생성되고 작업자 노드에 kataRuntimeClass 로 설치합니다.

중요

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

검증

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

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

    완료된 노드 값이 작업자 또는 라벨이 지정된 노드 수와 같으면 설치가 완료됩니다. 상태에는 설치가 완료된 노드 목록도 포함됩니다.

3.2.3. 웹 콘솔을 사용하여 샌드박스 컨테이너에서 워크로드 배포

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

샌드박스 컨테이너에 pod 템플릿 워크로드를 배포하려면 kata 를 워크로드 YAML 파일에 runtimeClassName 으로 수동으로 추가해야 합니다.

사전 요구 사항

  • 클러스터에 OpenShift Container Platform 4.9를 설치했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.
  • KataConfig CR(사용자 정의 리소스)을 생성했습니다.

절차

  1. 웹 콘솔의 관리자 화면에서 워크로드를 확장하고 생성할 워크로드 유형을 선택합니다.
  2. 워크로드 페이지에서 워크로드를 생성하려면 클릭합니다.
  3. 워크로드의 YAML 파일에서 컨테이너가 나열된 spec 필드에서 runtimeClassName: kata 를 추가합니다.

    Pod의 예

        apiVersion: v1
        kind: Pod
        metadata:
          name: example
          labels:
            app: httpd
          namespace: openshift-sandboxed-containers-operator
        spec:
          runtimeClassName: kata
          containers:
            - name: httpd
              image: 'image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest'
              ports:
                - containerPort: 8080

    배포 예

        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: example
          namespace: openshift-sandboxed-containers-operator
        spec:
          selector:
            matchLabels:
              app: httpd
          replicas: 3
          template:
            metadata:
              labels:
                app: httpd
            spec:
              runtimeClassName: kata
              containers:
                - name: httpd
                  image: >-
                    image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest
                  ports:
                    - containerPort: 8080

  4. 저장을 클릭합니다.

OpenShift Container Platform은 워크로드를 생성하고 예약하기 시작합니다.

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

CLI를 사용하여 OpenShift 샌드박스 컨테이너 워크로드를 배포할 수 있습니다. 먼저 OpenShift 샌드박스 컨테이너 Operator를 설치한 다음 KataConfig 사용자 정의 리소스를 생성해야 합니다. 샌드박스 컨테이너에 워크로드를 배포할 준비가 되면 kata 를 워크로드 YAML 파일에 runtimeClassName 으로 추가해야 합니다.

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

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

사전 요구 사항

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

    참고

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

절차

  1. OpenShift 샌드박스 컨테이너 Operator의 Namespace 오브젝트를 생성합니다.

    1. 다음 매니페스트가 포함된 Namespace 오브젝트 YAML 파일을 생성합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-sandboxed-containers-operator
    2. Namespace 오브젝트를 생성합니다.

      $ oc create -f Namespace.yaml
  2. OpenShift 샌드박스 컨테이너 Operator의 OperatorGroup 오브젝트를 생성합니다.

    1. 다음 매니페스트가 포함된 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
    2. OperatorGroup 개체를 생성합니다.

      $ oc create -f OperatorGroup.yaml
  3. Subscription 오브젝트를 생성하여 OpenShift 샌드박스 컨테이너 Operator에 네임스페이스 를 등록합니다.

    1. 다음 매니페스트를 포함하는 Subscription 오브젝트 YAML 파일을 생성합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-sandboxed-containers-operator
        namespace: openshift-sandboxed-containers-operator
      spec:
        channel: "preview-1.1"
        installPlanApproval: Automatic
        name: sandboxed-containers-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        startingCSV: sandboxed-containers-operator.v1.1.0
    2. 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.1.0    1.0.2        Succeeded

3.3.2. CLI를 사용하여 KataConfig 사용자 지정 리소스 생성

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

  • RHCOS 노드에 QEMU 및 kata-containers 와 같은 필요한 RHCOS 확장을 설치합니다.
  • CRI-O 런타임이 올바른 kata 런타임 처리기로 구성되었는지 확인합니다.
  • 기본 구성으로 kata 라는 RuntimeClass CR을 생성합니다. 이를 통해 사용자는 RuntimeClassName 필드의 CR을 참조하여 kata 를 런타임으로 사용하도록 워크로드를 구성할 수 있습니다. 이 CR은 런타임의 리소스 오버헤드도 지정합니다.
참고

Kata는 기본적으로 모든 작업자 노드에 설치됩니다. kata 를 특정 노드에만 RuntimeClass 로 설치하려면 해당 노드에 라벨을 추가한 다음 이를 생성할 때 KataConfig CR에 라벨을 정의할 수 있습니다.

사전 요구 사항

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

절차

  1. 다음 매니페스트를 사용하여 YAML 파일을 생성합니다.

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
  2. (선택 사항) 선택한 노드에만 kataRuntimeClass 로 설치하려면 매니페스트에 라벨이 포함된 YAML 파일을 생성합니다.

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      kataConfigPoolSelector:
        matchLabels:
          <label_key>: '<label_value>' 1
    1
    kataConfigPoolSelector 의 라벨은 단일 값만 지원합니다. nodeSelector 구문은 지원되지 않습니다.
  3. KataConfig 리소스를 생성합니다.

    $ oc create -f <file name>.yaml

KataConfig CR이 생성되고 작업자 노드에 kataRuntimeClass 로 설치합니다.

중요

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

검증

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

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

    Is In Progress 의 값이 false 로 표시되면 설치가 완료됩니다.

3.3.3. CLI를 사용하여 샌드박스 컨테이너에서 워크로드 배포

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

샌드박스 컨테이너에 pod 템플릿 워크로드를 배포하려면 kata 를 워크로드 YAML 파일에 runtimeClassName 으로 추가해야 합니다.

사전 요구 사항

  • 클러스터에 OpenShift Container Platform 4.9를 설치했습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift 샌드박스 컨테이너 Operator가 설치되어 있습니다.
  • KataConfig CR(사용자 정의 리소스)을 생성했습니다.

절차

  • 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

OpenShift Container Platform은 워크로드를 생성하고 예약하기 시작합니다.

검증

  • Pod 템플릿 오브젝트에서 runtimeClassName 필드를 검사합니다. runtimeClassNamekata 인 경우 워크로드는 OpenShift 샌드박스 컨테이너에서 실행됩니다.

3.4. 추가 리소스

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

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

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

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

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

사전 요구 사항

  • OpenShift Container Platform 4.9가 클러스터에 설치되어 있어야 합니다.
  • 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.9가 클러스터에 설치되어 있어야 합니다.
  • 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.9가 클러스터에 설치되어 있어야 합니다.
  • 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.9가 클러스터에 설치되어 있어야 합니다.
  • 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.9가 클러스터에 설치되어 있어야 합니다.
  • 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 릴리스로 업그레이드하면 확장 기능이 업그레이드됩니다.

6장. Red Hat 지원을 위한 OpenShift 샌드박스 컨테이너 데이터 수집

지원 사례를 여는 경우 클러스터에 대한 디버깅 정보를 Red Hat 지원에 제공하면 도움이 됩니다.

must-gather 툴을 사용하면 가상 머신 및 OpenShift 샌드박스 컨테이너 관련 기타 데이터를 포함하여 OpenShift Container Platform 클러스터에 대한 진단 정보를 수집할 수 있습니다.

즉각 지원을 받을 수 있도록 OpenShift Container Platform 및 OpenShift 샌드박스 컨테이너 둘 다에 대한 진단 정보를 제공하십시오.

6.1. must-gather 툴 정보

oc adm must-gather CLI 명령은 다음을 포함하여 문제를 디버깅하는 데 필요할 가능성이 높은 클러스터에서 정보를 수집합니다.

  • 리소스 정의
  • 서비스 로그

기본적으로 oc adm must-gather 명령은 기본 플러그인 이미지를 사용하고 ./must-gather.local 에 씁니다.

또는 다음 섹션에 설명된 대로 적절한 인수로 명령을 실행하여 특정 정보를 수집할 수 있습니다.

  • 하나 이상의 특정 기능과 관련된 데이터를 수집하려면 다음 섹션에 나열된 대로 이미지와 함께 --image 인수를 사용합니다.

    예를 들면 다음과 같습니다.

    $ oc adm must-gather  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.9.0
  • 감사 로그를 수집하려면 다음 섹션에 설명된 대로 -- /usr/bin/gather_audit_logs 인수를 사용하십시오.

    예를 들면 다음과 같습니다.

    $ oc adm must-gather -- /usr/bin/gather_audit_logs
    참고

    감사 로그는 파일 크기를 줄이기 위해 기본 정보 세트의 일부로 수집되지 않습니다.

oc adm must-gather 를 실행하면 클러스터의 새 프로젝트에 임의의 이름이 있는 새 Pod가 생성됩니다. 해당 Pod에 대한 데이터가 수집되어 must-gather.local로 시작하는 새 디렉터리에 저장됩니다. 이 디렉터리는 현재 작업 중인 디렉터리에 생성되어 있습니다.

예를 들면 다음과 같습니다.

NAMESPACE                      NAME                 READY   STATUS      RESTARTS      AGE
...
openshift-must-gather-5drcj    must-gather-bklx4    2/2     Running     0             72s
openshift-must-gather-5drcj    must-gather-s8sdh    2/2     Running     0             72s
...

6.2. OpenShift 샌드박스 컨테이너 데이터 수집 정보

oc adm must-gather CLI 명령을 사용하여 클러스터에 대한 정보를 수집할 수 있습니다. 다음 기능 및 오브젝트는 OpenShift 샌드박스 컨테이너와 연결됩니다.

  • OpenShift 샌드박스 컨테이너 리소스에 속하는 모든 네임스페이스 및 하위 오브젝트
  • 모든 OpenShift 샌드박스 컨테이너 CRD(사용자 정의 리소스 정의)

oc adm must-gather CLI 명령은 다음 구성 요소 로그를 수집합니다.

  • QEMU 로그
  • 감사 로그
  • OpenShift 샌드박스 컨테이너 로그
  • CRI-O 로그

이러한 구성 요소 로그는 kata 런타임을 사용하여 하나 이상의 Pod가 실행되는 동안 수집됩니다.

must-gather 를 사용하여 OpenShift 샌드박스 컨테이너 데이터를 수집하려면 OpenShift 샌드박스 컨테이너 이미지를 지정해야 합니다.

--image=registry.redhat.io/openshift-sandboxed-containers-tech-preview/osc-must-gather-rhel8:1.1.0

6.3. 추가 리소스

법적 공지

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.