4장. 관리자 작업

4.1. 클러스터에 Operator 추가

OLM(Operator Lifecycle Manager)을 사용하면 클러스터 관리자가 OLM 기반 Operator를 OpenShift Container Platform 클러스터에 설치할 수 있습니다.

참고

OLM에서 동일한 네임스페이스에 배치된 설치된 Operator에 대한 업데이트를 처리하는 방법과 사용자 정의 글로벌 Operator 그룹을 사용하여 Operator를 설치하는 대체 방법은 Multitenancy 및 Operator colocation 을 참조하십시오.

4.1.1. OperatorHub를 통한 Operator 설치 정보

OperatorHub는 Operator를 검색하는 사용자 인터페이스입니다. 이는 클러스터에 Operator를 설치하고 관리하는 OLM(Operator Lifecycle Manager)과 함께 작동합니다.

적절한 권한이 있는 사용자는 OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 OperatorHub에서 Operator를 설치할 수 있습니다.

설치하는 동안 Operator의 다음 초기 설정을 결정해야합니다.

설치 모드
Operator를 설치할 특정 네임스페이스를 선택합니다.
업데이트 채널
여러 채널을 통해 Operator를 사용할 수있는 경우 구독할 채널을 선택할 수 있습니다. 예를 들어, stable 채널에서 배치하려면 (사용 가능한 경우) 목록에서 해당 채널을 선택합니다.
승인 전략

자동 또는 수동 업데이트를 선택할 수 있습니다.

설치된 Operator에 대해 자동 업데이트를 선택하는 경우 선택한 채널에 해당 Operator의 새 버전이 제공되면 OLM(Operator Lifecycle Manager)에서 Operator의 실행 중인 인스턴스를 개입 없이 자동으로 업그레이드합니다.

수동 업데이트를 선택하면 최신 버전의 Operator가 사용 가능할 때 OLM이 업데이트 요청을 작성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.

추가 리소스

4.1.2. 웹 콘솔을 사용하여 OperatorHub에서 설치

OpenShift Container Platform 웹 콘솔을 사용하여 OperatorHub에서 Operator를 설치하고 구독할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.

프로세스

  1. 웹 콘솔에서 Operators → OperatorHub 페이지로 이동합니다.
  2. 원하는 Operator를 찾으려면 키워드를 Filter by keyword 상자에 입력하거나 스크롤합니다. 예를 들어 Kubernetes Operator의 고급 클러스터 관리 기능을 찾으려면 advanced를 입력합니다.

    인프라 기능에서 옵션을 필터링할 수 있습니다. 예를 들어, 연결이 끊긴 환경 (제한된 네트워크 환경이라고도 함)에서 작업하는 Operator를 표시하려면 Disconnected를 선택합니다.

  3. Operator를 선택하여 추가 정보를 표시합니다.

    참고

    커뮤니티 Operator를 선택하면 Red Hat이 커뮤니티 Operator를 인증하지 않는다고 경고합니다. 계속하기 전에 경고를 확인해야합니다.

  4. Operator에 대한 정보를 확인하고 Install을 클릭합니다.
  5. Operator 설치 페이지에서 다음을 수행합니다.

    1. 다음 명령 중 하나를 선택합니다.

      • All namespaces on the cluster (default)에서는 기본 openshift-operators 네임스페이스에 Operator가 설치되므로 Operator가 클러스터의 모든 네임스페이스를 모니터링하고 사용할 수 있습니다. 이 옵션을 항상 사용할 수있는 것은 아닙니다.
      • A specific namespace on the cluster를 사용하면 Operator를 설치할 특정 단일 네임 스페이스를 선택할 수 있습니다. Operator는 이 단일 네임 스페이스에서만 모니터링 및 사용할 수 있게 됩니다.
    2. Operator를 설치할 특정 단일 네임스페이스를 선택합니다. Operator는 이 단일 네임 스페이스에서만 모니터링 및 사용할 수 있게 됩니다.
    3. Update Channe을 선택합니다 (하나 이상이 사용 가능한 경우).
    4. 앞에서 설명한 대로 자동 또는 수동 승인 전략을 선택합니다.
  6. 이 OpenShift Container Platform 클러스터에서 선택한 네임스페이스에서 Operator를 사용할 수 있도록 하려면 설치를 클릭합니다.

    1. 수동 승인 전략을 선택한 경우 설치 계획을 검토하고 승인할 때까지 서브스크립션의 업그레이드 상태가 업그레이드 중으로 유지됩니다.

      Install Plan 페이지에서 승인 한 후 subscription 업그레이드 상태가 Up to date로 이동합니다.

    2. 자동 승인 전략을 선택한 경우 업그레이드 상태가 개입 없이 최신 상태로 확인되어야 합니다.
  7. 서브스크립션의 업그레이드 상태가 최신이면 Operator → 설치된 Operator를 선택하여 설치된 Operator의 CSV(클러스터 서비스 버전)가 최종적으로 표시되는지 확인합니다. 상태는 최종적으로 관련 네임스페이스에서 InstallSucceeded로 확인되어야 합니다.

    참고

    모든 네임스페이스…​ 설치 모드의 경우, openshift-operators 네임스페이스에서 상태가 InstallSucceeded로 확인되지만 다른 네임스페이스에서 확인하면 상태가 복사됨입니다.

    그렇지 않은 경우 다음을 수행합니다.

    1. 워크로드 → Pod 페이지의 openshift-operators 프로젝트(또는 특정 네임스페이스…​설치 모드가 선택된 경우 기타 관련 네임스페이스)에서 문제를 보고하는 모든 Pod의 로그를 확인하여 문제를 추가로 해결합니다.

4.1.3. CLI를 사용하여 OperatorHub에서 설치

OpenShift Container Platform 웹 콘솔을 사용하는 대신 CLI를 사용하여 OperatorHub에서 Operator를 설치할 수 있습니다. oc 명령을 사용하여 Subscription 개체를 만들거나 업데이트합니다.

사전 요구 사항

  • Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • 로컬 시스템에 oc 명령을 설치합니다.

프로세스

  1. OperatorHub에서 클러스터에 사용 가능한 Operator의 목록을 표시합니다.

    $ oc get packagemanifests -n openshift-marketplace

    출력 예

    NAME                               CATALOG               AGE
    3scale-operator                    Red Hat Operators     91m
    advanced-cluster-management        Red Hat Operators     91m
    amq7-cert-manager                  Red Hat Operators     91m
    ...
    couchbase-enterprise-certified     Certified Operators   91m
    crunchy-postgres-operator          Certified Operators   91m
    mongodb-enterprise                 Certified Operators   91m
    ...
    etcd                               Community Operators   91m
    jaeger                             Community Operators   91m
    kubefed                            Community Operators   91m
    ...

    필요한 Operator의 카탈로그를 기록해 둡니다.

  2. 필요한 Operator를 검사하여 지원되는 설치 모드 및 사용 가능한 채널을 확인합니다.

    $ oc describe packagemanifests <operator_name> -n openshift-marketplace
  3. OperatorGroup 오브젝트로 정의되는 Operator group에서 Operator group과 동일한 네임스페이스에 있는 모든 Operator에 대해 필요한 RBAC 액세스 권한을 생성할 대상 네임스페이스를 선택합니다.

    Operator를 서브스크립션하는 네임스페이스에는 Operator의 설치 모드, 즉 AllNamespaces 또는 SingleNamespace 모드와 일치하는 Operator group이 있어야 합니다. 설치하려는 Operator에서 AllNamespaces를 사용하는 경우 openshift-operators 네임스페이스에 적절한 Operator group이 이미 있습니다.

    그러나 Operator에서 SingleNamespace 모드를 사용하고 적절한 Operator group이 없는 경우 이를 생성해야 합니다.

    참고

    이 프로세스의 웹 콘솔 버전에서는 SingleNamespace 모드를 선택할 때 자동으로 OperatorGroupSubscription 개체 생성을 자동으로 처리합니다.

    1. OperatorGroup 개체 YAML 파일을 만듭니다 (예: operatorgroup.yaml).

      OperatorGroup 오브젝트의 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

      주의

      OLM(Operator Lifecycle Manager)은 각 Operator 그룹에 대해 다음 클러스터 역할을 생성합니다.

      • <operatorgroup_name>-admin
      • <operatorgroup_name>-edit
      • <operatorgroup_name>-view

      Operator group을 수동으로 생성할 때 클러스터의 기존 클러스터 역할 또는 기타 Operator 그룹과 충돌하지 않는 고유한 이름을 지정해야 합니다.

    2. OperatorGroup 개체를 생성합니다.

      $ oc apply -f operatorgroup.yaml
  4. Subscription 개체 YAML 파일을 생성하여 OpenShift Pipelines Operator에 네임스페이스를 등록합니다(예: sub.yaml).

    Subscription 개체 예

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: <subscription_name>
      namespace: openshift-operators 1
    spec:
      channel: <channel_name> 2
      name: <operator_name> 3
      source: redhat-operators 4
      sourceNamespace: openshift-marketplace 5
      config:
        env: 6
        - name: ARGS
          value: "-v=10"
        envFrom: 7
        - secretRef:
            name: license-secret
        volumes: 8
        - name: <volume_name>
          configMap:
            name: <configmap_name>
        volumeMounts: 9
        - mountPath: <directory_name>
          name: <volume_name>
        tolerations: 10
        - operator: "Exists"
        resources: 11
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        nodeSelector: 12
          foo: bar

    1
    기본 AllNamespaces 설치 모드 사용량의 경우 openshift-operators 네임스페이스를 지정합니다. 또는 사용자 지정 글로벌 네임스페이스를 생성한 경우 지정할 수 있습니다. 그 외에는 SingleNamespace 설치 모드를 사용하도록 관련 단일 네임스페이스를 지정합니다.
    2
    등록할 채널의 이름입니다.
    3
    등록할 Operator의 이름입니다.
    4
    Operator를 제공하는 카탈로그 소스의 이름입니다.
    5
    카탈로그 소스의 네임스페이스입니다. 기본 OperatorHub 카탈로그 소스에는 openshift-marketplace를 사용합니다.
    6
    env 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 있어야 하는 환경 변수 목록을 정의합니다.
    7
    envFrom 매개 변수는 컨테이너에서 환경 변수를 채울 소스 목록을 정의합니다.
    8
    volumes 매개변수는 OLM에서 생성한 Pod에 있어야 하는 볼륨 목록을 정의합니다.
    9
    volumeMounts 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 있어야 하는 VolumeMounts 목록을 정의합니다. volumeMount 가 존재하지 않는 볼륨을 참조하는 경우 OLM은 Operator를 배포하지 못합니다.
    10
    tolerations 매개변수는 OLM에서 생성한 Pod의 Tolerations 목록을 정의합니다.
    11
    resources 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 대한 리소스 제약 조건을 정의합니다.
    12
    nodeSelector 매개변수는 OLM에서 생성한 Pod에 대한 NodeSelector 를 정의합니다.
  5. Subscription 오브젝트를 생성합니다.

    $ oc apply -f sub.yaml

    이 시점에서 OLM은 이제 선택한 Operator를 인식합니다. Operator의 CSV(클러스터 서비스 버전)가 대상 네임스페이스에 표시되고 Operator에서 제공하는 API를 생성에 사용할 수 있어야 합니다.

추가 리소스

4.1.4. 특정 버전의 Operator 설치

Subscription 오브젝트에 CSV(클러스터 서비스 버전)를 설정하면 특정 버전의 Operator를 설치할 수 있습니다.

사전 요구 사항

  • Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치됨

프로세스

  1. startingCSV 필드를 설정하여 특정 버전의 Operator에 네임스페이스를 서브스크립션하는 Subscription 오브젝트 YAML 파일을 생성합니다. 카탈로그에 이후 버전이 있는 경우 Operator가 자동으로 업그레이드되지 않도록 installPlanApproval 필드를 Manual로 설정합니다.

    예를 들어 다음 sub.yaml 파일을 사용하여 특별히 3.4.0 버전에 Red Hat Quay Operator를 설치할 수 있습니다.

    특정 시작 Operator 버전이 있는 서브스크립션

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: quay-operator
      namespace: quay
    spec:
      channel: quay-v3.4
      installPlanApproval: Manual 1
      name: quay-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: quay-operator.v3.4.0 2

    1
    지정된 버전이 카탈로그의 이후 버전으로 대체될 경우 승인 전략을 Manual로 설정합니다. 이 계획에서는 이후 버전으로 자동 업그레이드할 수 없으므로 시작 CSV에서 설치를 완료하려면 수동 승인이 필요합니다.
    2
    Operator CSV의 특정 버전을 설정합니다.
  2. Subscription 오브젝트를 생성합니다.

    $ oc apply -f sub.yaml
  3. 보류 중인 설치 계획을 수동으로 승인하여 Operator 설치를 완료합니다.

4.1.5. 다중 테넌트 클러스터에 대한 Operator의 여러 인스턴스 준비

클러스터 관리자는 다중 테넌트 클러스터에서 사용할 Operator의 여러 인스턴스를 추가할 수 있습니다. 이는 표준 모든 네임스페이스 설치 모드를 사용하는 대체 솔루션으로, 최소 권한 원칙을 위반하거나 널리 채택되지 않는 Multinamespace 모드를 위반하는 것으로 간주될 수 있습니다. 자세한 내용은 " 다중 테넌트 클러스터의 Operator"를 참조하십시오.

다음 절차에서는 배포된 워크로드 집합에 대한 공통 액세스 및 권한을 공유하는 사용자 또는 사용자 그룹입니다. 테넌트 Operator 는 해당 테넌트에서만 사용하도록 설계된 Operator의 인스턴스입니다.

사전 요구 사항

  • 설치하려는 Operator의 모든 인스턴스는 지정된 클러스터에서 버전이 동일해야 합니다.

    중요

    이 제한 사항 및 기타 제한 사항에 대한 자세한 내용은 " 다중 테넌트 클러스터의 Operator"를 참조하십시오.

절차

  1. Operator를 설치하기 전에 테넌트의 네임스페이스와 별도의 테넌트 Operator의 네임스페이스를 생성합니다. 예를 들어 테넌트 네임스페이스가 team1 인 경우 team1-operator 네임스페이스를 생성할 수 있습니다.

    1. Namespace 리소스를 정의하고 YAML 파일을 저장합니다(예: team1-operator.yaml ).

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

      $ oc create -f team1-operator.yaml
  2. spec.targetNamespaces 목록에 있는 하나의 namespace 항목만 사용하여 테넌트 Operator 범위에 대한 Operator group을 생성합니다.

    1. OperatorGroup 리소스를 정의하고 YAML 파일을 저장합니다(예: team1-operatorgroup.yaml ).

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: team1-operatorgroup
        namespace: team1-operator
      spec:
        targetNamespaces:
        - team1 1
      1
      spec.targetNamespaces 목록에서 테넌트의 네임스페이스만 정의합니다.
    2. 다음 명령을 실행하여 Operator 그룹을 생성합니다.

      $ oc create -f team1-operatorgroup.yaml

다음 단계

  • 테넌트 Operator 네임스페이스에 Operator를 설치합니다. 이 작업은 CLI 대신 웹 콘솔에서 OperatorHub를 사용하여 더 쉽게 수행합니다. 자세한 절차는 웹 콘솔을 사용하여 OperatorHub에서 설치를 참조하십시오.

    참고

    Operator 설치를 완료한 후 Operator는 테넌트 Operator 네임스페이스에 상주하고 테넌트 네임스페이스를 감시하지만, 테넌트에서 Operator와 해당 서비스 계정을 보거나 사용할 수 없습니다.

4.1.6. 사용자 지정 네임스페이스에 글로벌 Operator 설치

OpenShift Container Platform 웹 콘솔을 사용하여 Operator 를 설치할 때 기본 동작은 모든 네임스페이스 설치 모드를 지원하는 Operator를 기본 openshift-operators 글로벌 네임스페이스에 설치합니다. 이로 인해 공유 설치 계획 및 네임스페이스의 모든 Operator 간의 정책 업데이트와 관련된 문제가 발생할 수 있습니다. 이러한 제한 사항에 대한 자세한 내용은 "Multitenancy and Operator colocation"을 참조하십시오.

클러스터 관리자는 사용자 정의 글로벌 네임스페이스를 생성하고 해당 네임스페이스를 사용하여 Operator 및 해당 종속 항목을 개별적으로 설치하거나 범위가 지정된 종속 항목을 설치하여 이 기본 동작을 수동으로 바이패스할 수 있습니다.

절차

  1. Operator를 설치하기 전에 원하는 Operator를 설치할 네임스페이스를 생성합니다. 이 설치 네임스페이스는 사용자 지정 글로벌 네임스페이스가 됩니다.

    1. 네임스페이스 리소스를 정의하고 YAML 파일을 저장합니다(예: global-operators.yaml ).

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

      $ oc create -f global-operators.yaml
  2. 모든 네임스페이스를 감시하는 Operator group인 사용자 정의 글로벌 Operator group을 생성합니다.

    1. OperatorGroup 리소스를 정의하고 YAML 파일(예: global-operatorgroup.yaml )을 저장합니다. spec.selectorspec.targetNamespaces 필드를 모두 생략하여 모든 네임스페이스를 선택하는 글로벌 Operator group 으로 설정합니다.

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: global-operatorgroup
        namespace: global-operators
      참고

      생성된 글로벌 Operator group의 status.namespaces 에는 사용 중인 Operator에 모든 네임스페이스를 조사해야 함을 알리는 빈 문자열("")이 포함되어 있습니다.

    2. 다음 명령을 실행하여 Operator 그룹을 생성합니다.

      $ oc create -f global-operatorgroup.yaml

다음 단계

  • 사용자 정의 글로벌 네임스페이스에 원하는 Operator를 설치합니다. Operator 설치 중에 웹 콘솔은 사용자 정의 글로벌 네임스페이스로 설치된 네임스페이스 메뉴를 채우지 않으므로 이 작업은 OpenShift CLI(oc)로만 수행할 수 있습니다. 자세한 절차는 CLI를 사용하여 OperatorHub에서 설치를 참조하십시오.

    참고

    Operator 설치를 시작할 때 Operator에 종속 항목이 있으면 종속 항목도 사용자 지정 글로벌 네임스페이스에 자동으로 설치됩니다. 결과적으로 종속성 Operator에 동일한 업데이트 정책 및 공유 설치 계획이 있는 것이 유효합니다.

4.1.7. Operator 워크로드의 Pod 배치

기본적으로 OLM(Operator Lifecycle Manager)은 Operator를 설치하거나 Operand 워크로드를 배포할 때 임의의 작업자 노드에 Pod를 배치합니다. 관리자는 노드 선택기, 테인트 및 허용 오차가 결합된 프로젝트를 사용하여 특정 노드에 Operator 및 Operand 배치를 제어할 수 있습니다.

Operator 및 Operand 워크로드의 Pod 배치 제어에는 다음과 같은 사전 요구 사항이 있습니다.

  1. 요구 사항에 따라 Pod를 대상으로 할 노드 또는 노드 집합을 결정합니다. 사용 가능한 경우 노드 또는 노드를 식별하는 node-role.kubernetes.io/app과 같은 기존 레이블을 확인합니다. 또는 컴퓨팅 머신 세트를 사용하거나 노드를 직접 편집하여 myoperator 와 같은 레이블을 추가합니다. 이후 단계에서 이 레이블을 프로젝트의 노드 선택기로 사용합니다.
  2. 특정 레이블이 있는 Pod만 노드에서 실행되도록 허용하지만 관련이 없는 워크로드를 다른 노드에 추가하려면 컴퓨팅 머신 세트를 사용하거나 노드를 직접 편집하여 노드 또는 노드에 테인트를 추가합니다. 테인트와 일치하지 않는 새 Pod를 노드에서 예약할 수 없도록 하는 효과를 사용합니다. 예를 들어 myoperator:NoSchedule 테인트를 사용하면 테인트와 일치하지 않는 새 Pod가 해당 노드에 예약되지 않지만 노드의 기존 Pod는 그대로 유지됩니다.
  3. 기본 노드 선택기와 테인트를 추가한 경우 일치하는 허용 오차로 구성된 프로젝트를 만듭니다.

이 시점에서 생성한 프로젝트를 사용하여 다음 시나리오에서 지정된 노드로 Pod를 이동할 수 있습니다.

Operator Pod의 경우
관리자는 다음 섹션에 설명된 대로 프로젝트에 Subscription 오브젝트를 생성할 수 있습니다. 결과적으로 Operator Pod가 지정된 노드에 배치됩니다.
Operand Pod의 경우
설치된 Operator를 사용하여 프로젝트에 애플리케이션을 생성할 수 있습니다. 그러면 Operator가 프로젝트에 소유한 CR(사용자 정의 리소스)이 배치됩니다. 결과적으로 Operator가 다른 네임스페이스에 클러스터 수준 오브젝트 또는 리소스를 배포하지 않는 한 피연산자 Pod가 지정된 노드에 배치됩니다. 이 경우 사용자 정의 Pod 배치가 적용되지 않습니다.

4.1.8. Operator가 설치된 위치 제어

기본적으로 Operator를 설치할 때 OpenShift Container Platform은 Operator Pod를 작업자 노드 중 하나에 무작위로 설치합니다. 그러나 해당 Pod를 특정 노드 또는 노드 세트에 예약하려는 경우가 있을 수 있습니다.

다음 예제에서는 Operator Pod를 특정 노드 또는 노드 세트에 예약할 수 있는 상황을 설명합니다.

  • Operator에 amd64 또는 ARM64와 같은 특정 플랫폼이 필요한 경우
  • Operator에 Linux 또는 Windows와 같은 특정 운영 체제가 필요한 경우
  • 동일한 호스트 또는 동일한 랙에 있는 호스트에서 함께 작동하는 Operator가 필요한 경우
  • 네트워크 또는 하드웨어 문제로 인해 다운타임을 방지하기 위해 Operator가 인프라 전체에 분산되도록 하려면

Operator의 Subscription 오브젝트에 노드 유사성, Pod 유사성 또는 Pod 유사성 방지 제약 조건을 추가하여 Operator Pod 설치 위치를 제어할 수 있습니다. 노드 유사성은 스케줄러에서 Pod를 배치할 수 있는 위치를 결정하는 데 사용하는 규칙 집합입니다. Pod 유사성을 사용하면 관련 Pod가 동일한 노드에 예약되도록 할 수 있습니다. Pod 유사성 방지를 사용하면 노드에서 Pod를 예약하지 못하도록 할 수 있습니다.

다음 예제에서는 노드 유사성 또는 Pod 유사성 방지를 사용하여 Custom Metrics Autoscaler Operator 인스턴스를 클러스터의 특정 노드에 설치하는 방법을 보여줍니다.

특정 노드에 Operator Pod를 배치하는 노드 유사성 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity: 1
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-163-94.us-west-2.compute.internal
#...

1
ip-10-0-163-94.us-west-2.compute.internal 노드에 Operator Pod를 예약해야 하는 노드 유사성입니다.

특정 플랫폼이 있는 노드에 Operator Pod를 배치하는 노드 유사성 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity: 1
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/arch
              operator: In
              values:
              - arm64
            - key: kubernetes.io/os
              operator: In
              values:
              - linux
#...

1
kubernetes.io/arch=arm64kubernetes.io/os=linux 라벨을 사용하여 노드에 Operator Pod를 예약해야 하는 노드 유사성입니다.

Operator Pod를 하나 이상의 특정 노드에 배치하는 Pod 유사성 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAffinity: 1
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - test
          topologyKey: kubernetes.io/hostname
#...

1
app=test 라벨이 있는 Pod가 있는 노드에 Operator의 Pod를 배치하는 Pod 유사성입니다.

Operator Pod가 하나 이상의 특정 노드에서 방지되는 Pod 유사성 방지 예제

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAntiAffinity: 1
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: cpu
              operator: In
              values:
              - high
          topologyKey: kubernetes.io/hostname
#...

1
cpu=high 라벨이 있는 Pod가 있는 노드에서 Operator의 Pod를 예약하지 못하도록 하는 Pod 유사성 방지입니다.

절차

Operator Pod 배치를 제어하려면 다음 단계를 완료합니다.

  1. Operator를 정상적으로 설치합니다.
  2. 필요한 경우 노드에 유사성에 올바르게 응답하도록 레이블이 지정되어 있는지 확인합니다.
  3. Operator Subscription 오브젝트를 편집하여 유사성을 추가합니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-custom-metrics-autoscaler-operator
      namespace: openshift-keda
    spec:
      name: my-package
      source: my-operators
      sourceNamespace: operator-registries
      config:
        affinity: 1
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                  - ip-10-0-185-229.ec2.internal
    #...
    1
    nodeAffinity,podAffinity 또는 podAntiAffinity 를 추가합니다. 선호도 생성에 대한 자세한 내용은 다음 추가 리소스 섹션을 참조하십시오.

검증

  • Pod가 특정 노드에 배포되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get pods -o wide

    출력 예

    NAME                                                  READY   STATUS    RESTARTS   AGE   IP            NODE                           NOMINATED NODE   READINESS GATES
    custom-metrics-autoscaler-operator-5dcc45d656-bhshg   1/1     Running   0          50s   10.131.0.20   ip-10-0-185-229.ec2.internal   <none>           <none>