2.3. 명령줄을 사용하여 OpenShift 샌드박스 컨테이너 배포


CLI(명령줄 인터페이스)를 사용하여 다음 작업을 수행하여 베어 메탈에 OpenShift 샌드박스 컨테이너를 배포할 수 있습니다.

  1. OpenShift 샌드박스 컨테이너 Operator를 설치합니다.
  2. Operator를 설치한 후 다음 옵션을 구성할 수 있습니다.

  3. KataConfig 사용자 지정 리소스를 생성합니다.
  4. 선택 사항: Pod 오버헤드를 수정합니다.
  5. OpenShift 샌드박스 컨테이너 워크로드 오브젝트를 구성합니다.

2.3.1. OpenShift 샌드박스 컨테이너 Operator 설치

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

사전 요구 사항

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

프로세스

  1. osc-namespace.yaml 매니페스트 파일을 생성합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sandboxed-containers-operator
  2. 다음 명령을 실행하여 네임스페이스를 생성합니다.

    $ oc apply -f osc-namespace.yaml
  3. osc-operatorgroup.yaml 매니페스트 파일을 생성합니다.

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sandboxed-containers-operator-group
      namespace: openshift-sandboxed-containers-operator
    spec:
      targetNamespaces:
      - openshift-sandboxed-containers-operator
  4. 다음 명령을 실행하여 operator 그룹을 생성합니다.

    $ oc apply -f osc-operatorgroup.yaml
  5. osc-subscription.yaml 매니페스트 파일을 생성합니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sandboxed-containers-operator
      namespace: openshift-sandboxed-containers-operator
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: sandboxed-containers-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: sandboxed-containers-operator.v1.8.0
  6. 다음 명령을 실행하여 서브스크립션을 생성합니다.

    $ oc apply -f osc-subscription.yaml
  7. 다음 명령을 실행하여 Operator가 올바르게 설치되었는지 확인합니다.

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

    이 명령을 완료하는 데 몇 분이 걸릴 수 있습니다.

  8. 다음 명령을 실행하여 프로세스를 확인합니다.

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

    출력 예

    NAME                             DISPLAY                                  VERSION             REPLACES                   PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.8.0    1.7.0        Succeeded

2.3.2. 선택적 구성

OpenShift 샌드박스 컨테이너 Operator를 설치한 후 다음 옵션을 구성할 수 있습니다.

2.3.2.1. 로컬 블록 볼륨 프로비저닝

OpenShift 샌드박스 컨테이너와 함께 로컬 블록 볼륨을 사용할 수 있습니다. 먼저 LSO(Local Storage Operator)를 사용하여 로컬 블록 볼륨을 프로비저닝해야 합니다. 그런 다음 로컬 블록 볼륨이 있는 노드를 활성화해야 OpenShift 샌드박스 컨테이너 워크로드를 실행해야 합니다.

LSO(Local Storage Operator)를 사용하여 OpenShift 샌드박스 컨테이너의 로컬 블록 볼륨을 프로비저닝할 수 있습니다. 로컬 볼륨 프로비저너는 정의된 리소스에 지정된 경로에서 블록 볼륨 장치를 찾습니다.

사전 요구 사항

  • Local Storage Operator가 설치되어 있습니다.
  • 다음 조건을 충족하는 로컬 디스크가 있습니다.

    • 노드에 연결되어 있습니다.
    • 마운트되지 않았습니다.
    • 파티션이 포함되어 있지 않습니다.

프로세스

  1. 로컬 볼륨 리소스를 생성합니다. 이 리소스는 로컬 볼륨에 대한 노드 및 경로를 정의해야 합니다.

    참고

    동일한 장치에 다른 스토리지 클래스 이름을 사용하지 마십시오. 이렇게 하면 여러 PV(영구 볼륨)가 생성됩니다.

    예: 블록

    apiVersion: "local.storage.openshift.io/v1"
    kind: "LocalVolume"
    metadata:
      name: "local-disks"
      namespace: "openshift-local-storage" 1
    spec:
      nodeSelector: 2
        nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-136-143
              - ip-10-0-140-255
              - ip-10-0-144-180
      storageClassDevices:
        - storageClassName: "local-sc" 3
          forceWipeDevicesAndDestroyAllData: false 4
          volumeMode: Block
          devicePaths: 5
            - /path/to/device 6

    1
    Local Storage Operator가 설치된 네임스페이스입니다.
    2
    선택 사항: 로컬 스토리지 볼륨이 연결된 노드 목록이 포함된 노드 선택기입니다. 이 예에서는 oc get node에서 가져온 노드 호스트 이름을 사용합니다. 값을 정의하지 않으면 Local Storage Operator에서 사용 가능한 모든 노드에서 일치하는 디스크를 찾습니다.
    3
    영구 볼륨 오브젝트를 생성할 때 사용할 스토리지 클래스의 이름입니다.
    4
    이 설정은 wipefs 를 호출할지 여부를 정의합니다. 즉, 파티션 테이블 서명(마이크 문자열)을 제거하여 Local Storage Operator 프로비저닝에 디스크를 사용할 준비가 되었습니다. 서명 이외의 다른 데이터는 삭제되지 않습니다. 기본값은 "false"입니다(wipefs 가 호출되지 않음). forceWipeDevicesAndDestroyAllData 를 "true"로 설정하면 이전 데이터를 다시 사용해야 하는 디스크에 남아 있을 수 있는 시나리오에서 유용할 수 있습니다. 이러한 시나리오에서는 이 필드를 true로 설정하면 관리자가 디스크를 수동으로 지울 필요가 없습니다.
    5
    선택할 로컬 스토리지 장치 목록이 포함된 경로입니다. 로컬 블록 장치가 있는 노드를 활성화하여 OpenShift 샌드박스 컨테이너 워크로드를 실행할 때 이 경로를 사용해야 합니다.
    6
    이 값을 LocalVolume 리소스의 filepath로 바꿉니다(예: /dev/disk/ by-id /wwn ). 프로비저너가 배포되면 이러한 로컬 디스크에 PV가 생성됩니다.
  2. OpenShift Container Platform 클러스터에 로컬 볼륨 리소스를 생성합니다. 방금 생성한 파일을 지정합니다.

    $ oc apply -f <local-volume>.yaml
  3. 프로비저너가 생성되었고 해당 데몬 세트가 생성되었는지 확인합니다.

    $ oc get all -n openshift-local-storage

    출력 예

    NAME                                          READY   STATUS    RESTARTS   AGE
    pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
    pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
    pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
    pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m
    
    NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
    service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m
    
    NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s
    
    NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/local-storage-operator   1/1     1            1           14m
    
    NAME                                                DESIRED   CURRENT   READY   AGE
    replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m

    원하는 데몬 세트 프로세스 및 현재 개수를 기록해 둡니다. 원하는 개수가 0 이면 라벨 선택기가 유효하지 않음을 나타냅니다.

  4. 영구 볼륨이 생성되었는지 확인합니다.

    $ oc get pv

    출력 예

    NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
    local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
    local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
    local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

중요

LocalVolume 오브젝트를 편집해도 안전하지 않은 작업이 발생할 수 있으므로 기존 영구 볼륨이 변경되지 않습니다.

2.3.2.2. 노드가 로컬 블록 장치를 사용하도록 활성화

로컬 블록 장치로 노드를 구성하여 정의된 볼륨 리소스에 지정된 경로에서 OpenShift 샌드박스 컨테이너 워크로드를 실행할 수 있습니다.

사전 요구 사항

  • LSO(Local Storage Operator)를 사용하여 블록 장치를 프로비저닝합니다.

프로세스

  • 로컬 블록 장치가 있는 각 노드를 활성화하여 다음 명령을 실행하여 OpenShift 샌드박스 컨테이너 워크로드를 실행합니다.

    $ oc debug node/worker-0 -- chcon -vt container_file_t /host/path/to/device

    /path/to/device 는 로컬 스토리지 리소스를 생성할 때 정의한 경로와 동일해야 합니다.

    출력 예

    system_u:object_r:container_file_t:s0 /host/path/to/device

2.3.2.3. NodeFeatureDiscovery 사용자 정의 리소스 생성

NodeFeatureDiscovery CR(사용자 정의 리소스)을 생성하여 NFD(Node Feature Discovery) Operator에서 작업자 노드에서 OpenShift 샌드박스 컨테이너를 지원할 수 있는지 확인하는 구성 매개변수를 정의합니다.

참고

사용자가 알고 있는 선택된 작업자 노드에만 kata 런타임을 설치하려면 feature.node.kubernetes.io/runtime.kata=true 레이블을 선택한 노드에 적용하고 KataConfig CR에서 checkNodeEligibility: true 를 설정합니다.

모든 작업자 노드에 kata 런타임을 설치하려면 KataConfig CR에 checkNodeEligibility: false 를 설정합니다.

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

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

사전 요구 사항

  • NFD Operator가 설치되어 있습니다.

프로세스

  1. 다음 예에 따라 nfd.yaml 매니페스트 파일을 생성합니다.

    apiVersion: nfd.openshift.io/v1
    kind: NodeFeatureDiscovery
    metadata:
      name: nfd-kata
      namespace: openshift-nfd
    spec:
      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. NodeFeatureDiscovery CR을 생성합니다.

    $ oc create -f nfd.yaml

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

  1. 다음 예에 따라 kata-config.yaml 매니페스트 파일을 생성합니다.

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: example-kataconfig
    spec:
      checkNodeEligibility: true
  2. KataConfig CR을 생성합니다.

    $ oc create -f kata-config.yaml

검증

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

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

    출력 예

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

2.3.3. KataConfig 사용자 지정 리소스 생성

작업자 노드에 kata 를 런타임 클래스로 설치하려면 KataConfig CR(사용자 정의 리소스)을 생성해야 합니다.

KataConfig CR을 생성하면 OpenShift 샌드박스 컨테이너 Operator가 다음을 수행합니다.

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

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

중요

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

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

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 선택 사항: 노드 자격 검사를 활성화하려면 Node Feature Discovery Operator를 설치했습니다.

프로세스

  1. 다음 예에 따라 example-kataconfig.yaml 매니페스트 파일을 생성합니다.

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: example-kataconfig
    spec:
      checkNodeEligibility: false 1
      logLevel: info
    #  kataConfigPoolSelector:
    #    matchLabels:
    #      <label_key>: '<label_value>' 2
    1
    선택 사항: 노드 자격 검사를 실행하려면'checkNodeEligibility'를 true 로 설정합니다.
    2
    선택 사항: 노드 레이블을 적용하여 특정 노드에 OpenShift 샌드박스 컨테이너를 설치한 경우 키와 값을 지정합니다.
  2. 다음 명령을 실행하여 KataConfig CR을 생성합니다.

    $ oc apply -f example-kataconfig.yaml

    새로운 KataConfig CR이 생성되고 작업자 노드에 kata 를 런타임 클래스로 설치합니다.

    kata 설치가 완료되고 설치를 확인하기 전에 작업자 노드가 재부팅될 때까지 기다립니다.

  3. 다음 명령을 실행하여 설치 진행 상황을 모니터링합니다.

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

    kataNodes 아래의 모든 작업자의 상태가 설치되고 이유를 지정하지 않고 InProgress 조건이 False 이면 클러스터에 kata 가 설치됩니다.

2.3.4. Pod 오버헤드 수정

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

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

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

참고

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

프로세스

  1. 다음 명령을 실행하여 RuntimeClass 오브젝트를 가져옵니다.

    $ oc describe runtimeclass kata
  2. overhead.podFixed.memorycpu 값을 업데이트하고 파일로 runtimeclass.yaml 로 저장합니다.

    kind: RuntimeClass
    apiVersion: node.k8s.io/v1
    metadata:
      name: kata
    overhead:
      podFixed:
        memory: "500Mi"
        cpu: "500m"
  3. 다음 명령을 실행하여 변경 사항을 적용합니다.

    $ oc apply -f runtimeclass.yaml

2.3.5. 워크로드 오브젝트 구성

kata 를 다음 pod 템플릿 오브젝트의 런타임 클래스로 설정하여 OpenShift 샌드박스 컨테이너 워크로드 오브젝트를 구성해야 합니다.

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

Operator 네임스페이스에 워크로드를 배포하지 마십시오. 이러한 리소스에 대한 전용 네임스페이스를 생성합니다.

사전 요구 사항

  • KataConfig CR(사용자 정의 리소스)을 생성했습니다.

프로세스

  1. 다음 예와 같이 spec.runtimeClassName: kata 를 각 pod 템플릿 워크로드 오브젝트의 매니페스트에 추가합니다.

    apiVersion: v1
    kind: <object>
    # ...
    spec:
      runtimeClassName: kata
    # ...

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

검증

  • pod-templated 오브젝트의 spec.runtimeClassName 필드를 검사합니다. 값이 kata 이면 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너에서 워크로드가 실행됩니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.