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 노드는 지원되지 않습니다.
    • 중첩된 가상화는 지원되지 않습니다.

  • AWS(Amazon Web Services) 베어 메탈 인스턴스에 OpenShift 샌드박스 컨테이너를 설치할 수 있습니다. 다른 클라우드 공급자가 제공하는 베어 메탈 인스턴스는 지원되지 않습니다.

    중요

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

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

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"

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

참고

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

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

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

추가 리소스

3.1.2. 클러스터 노드가 OpenShift 샌드박스 컨테이너를 실행할 수 있는지 확인

OpenShift 샌드박스 컨테이너를 실행하기 전에 클러스터의 노드가 Kata 컨테이너를 실행할 수 있는지 확인할 수 있습니다. 일부 클러스터 노드는 샌드박스 컨테이너의 최소 요구 사항을 준수하지 않을 수 있습니다. 노드가 불안정한 가장 일반적인 이유는 노드에서 가상화 지원이 부족하기 때문입니다. 자격이 없는 노드에서 샌드박스 워크로드를 실행하려고 하면 오류가 발생합니다. NFD(Node Feature Discovery) Operator 및 NodeFeatureDiscovery 리소스를 사용하여 노드 자격을 자동으로 확인할 수 있습니다.

참고

확인된 작업자 노드에만 Kata 런타임을 설치하려면 feature.node.kubernetes.io/runtime.kata=true 라벨을 선택한 노드에 적용하고 KataConfig 리소스에서 checkNodeEligibility: true 를 설정합니다.

또는 모든 작업자 노드에 Kata 런타임을 설치하려면 KataConfig 리소스에서 checkNodeEligibility: false 를 설정합니다.

이러한 두 시나리오에서는 NodeFeatureDiscovery 리소스를 생성할 필요가 없습니다. 노드에서 Kata 컨테이너를 실행할 수 있는지 확인하는 경우 feature.node.kubernetes.io/runtime.kata=true 라벨만 수동으로 적용해야 합니다.

다음 절차에서는 feature.node.kubernetes.io/runtime.kata=true 라벨을 모든 적격 노드에 적용하고 KataConfig 리소스를 구성하여 노드 자격을 확인합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • NFD(Node Feature Discovery) Operator를 설치합니다.

절차

  1. NodeFeatureDiscovery 리소스를 생성하여 Kata 컨테이너 실행에 적합한 노드 기능을 감지합니다.

    1. nfd.yaml 파일에 다음 YAML을 저장합니다. 

      apiVersion: nfd.openshift.io/v1
kind: NodeFeatureDiscovery
metadata:
  name: nfd-kata
  namespace: openshift-nfd
spec:
  operand:
    image: quay.io/openshift/origin-node-feature-discovery:4.10
    imagePullPolicy: Always
    servicePort: 12000
  workerConfig:
    configData: |
      sources:
         custom:
           - name: "feature.node.kubernetes.io/runtime.kata"
             matchOn:
               - cpuId: ["SSE4", "VMX"]
                 loadedKMod: ["kvm", "kvm_intel"]
               - cpuId: ["SSE4", "SVM"]
                 loadedKMod: ["kvm", "kvm_amd"]

    2. NodeEnatureDiscovery CR (사용자 정의 리소스)을 만듭니다. 

      $ oc create -f nfd.yaml

      출력 예

      nodefeaturediscovery.nfd.openshift.io/nfd-kata created

      feature.node.kubernetes.io/runtime.kata=true 레이블이 모든 적격 작업자 노드에 적용됩니다.

  2. 다음과 같이 KataConfig 리소스에서 checkNodeEligibility 필드를 true 로 설정합니다.

    1. kata-config.yaml 파일에 다음 YAML을 저장합니다. 

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

    2. KataConfig CR을 생성합니다. 

      $ oc create -f kata-config.yaml

      출력 예

      kataconfig.kataconfiguration.openshift.io/example-kataconfig created

검증

  • 클러스터의 적격 노드에 올바른 레이블이 적용되었는지 확인합니다. 

    $ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'

    출력 예

    NAME                           STATUS                     ROLES    AGE     VERSION
compute-3.example.com          Ready                      worker   4h38m   v1.23.3+e419edf
compute-2.example.com          Ready                      worker   4h35m   v1.23.3+e419edf

추가 리소스

  • NFD(Node Feature Discovery) Operator 설치에 대한 자세한 내용은 NFD 설치를 참조하십시오.