Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

노드

OpenShift Container Platform 4.6

OpenShift Container Platform에서 노드 구성 및 관리

초록

이 문서에서는 클러스터의 노드, Pod, 컨테이너를 구성하고 관리하는 방법에 대한 지침을 제공합니다. 또한 Pod 예약 및 배치 구성, 작업 및 DaemonSet를 사용하여 작업 자동화, 클러스터를 효율적으로 유지하는 기타 작업에 대한 정보도 제공합니다.

1장. 노드 개요
링크 복사

1.1. 노드 정보
링크 복사

노드는 Kubernetes 클러스터의 가상 또는 베어 메탈 시스템입니다. 작업자 노드는 포드로 그룹화된 애플리케이션 컨테이너를 호스팅합니다. 컨트롤 플레인 노드는 Kubernetes 클러스터를 제어하는 데 필요한 서비스를 실행합니다. OpenShift Container Platform에서 컨트롤 플레인 노드에는 OpenShift Container Platform 클러스터를 관리하기 위한 Kubernetes 서비스 이상의 기능이 포함되어 있습니다.

클러스터에 안정적이고 정상 노드를 보유하는 것은 호스트된 애플리케이션의 원활한 작동에 필수적입니다. OpenShift Container Platform에서는 노드를 나타내는 Node 오브젝트를 통해 노드에 액세스, 관리 및 모니터링할 수 있습니다. OpenShift CLI(oc) 또는 웹 콘솔을 사용하여 노드에서 다음 작업을 수행할 수 있습니다.

작업 읽기

읽기 작업을 통해 관리자 또는 개발자가 OpenShift Container Platform 클러스터의 노드에 대한 정보를 가져올 수 있습니다.

관리 운영

관리자는 여러 작업을 통해 OpenShift Container Platform 클러스터에서 노드를 쉽게 관리할 수 있습니다.

기능 개선 작업

OpenShift Container Platform을 사용하면 노드에 액세스하고 관리하는 것 이상의 작업을 수행할 수 있습니다. 관리자는 노드에서 다음 작업을 수행하여 클러스터가 보다 효율적이고 애플리케이션 친화적인 방식으로 개발자에게 더 나은 환경을 제공할 수 있습니다.

1.2. Pod 정보
링크 복사

포드는 노드에 함께 배포되는 하나 이상의 컨테이너입니다. 클러스터 관리자는 Pod를 정의하고 스케줄링할 준비가 된 정상 노드에서 실행되도록 할당할 수 있습니다. 포드는 컨테이너가 실행되는 동안 실행됩니다. 포드가 정의되어 있고 실행되면 변경할 수 없습니다. Pod로 작업할 때 수행할 수 있는 작업은 다음과 같습니다.

작업 읽기

관리자는 다음 작업을 통해 프로젝트의 Pod에 대한 정보를 가져올 수 있습니다.

관리 운영

다음 작업 목록은 관리자가 OpenShift Container Platform 클러스터에서 포드를 관리하는 방법에 대한 개요를 제공합니다.

기능 개선 작업

OpenShift Container Platform에서 사용할 수 있는 다양한 툴과 기능을 통해 Pod를 보다 쉽고 효율적으로 작업할 수 있습니다. 다음 작업에는 이러한 툴과 기능을 사용하여 포드를 더 효율적으로 관리할 수 있습니다.

Expand
작업사용자자세한 정보

수평 포드 자동 스케일러 생성 및 사용.

개발자

수평 Pod 자동 스케일러를 사용하여 실행할 최소 및 최대 Pod 수와 Pod에서 목표로 하는 CPU 사용률 또는 메모리 사용률을 지정할 수 있습니다. 수평 Pod 자동 스케일러를 사용하여 Pod를 자동으로 스케일링할 수 있습니다.

수직 Pod 자동 스케일러 설치 및 사용.

관리자 및 개발자

관리자는 워크로드의 리소스 및 리소스 요구 사항을 모니터링하여 클러스터 리소스를 더 잘 사용하려면 수직 Pod 자동 스케일러를 사용합니다.

개발자는 수직 Pod 자동 스케일러를 사용하여 각 Pod에 충분한 리소스가 있는 노드에 Pod를 예약하여 수요가 많은 기간에 Pod를 유지하도록 합니다.

장치 플러그인을 사용하여 외부 리소스에 대한 액세스를 제공합니다.

관리자

장치 플러그인은 노드(kubelet 외부)에서 실행되는 gRPC 서비스로, 특정 하드웨어 리소스를 관리합니다. 장치 플러그인을 배포하여 클러스터 전체에서 하드웨어 장치를 소비하는 일관되고 이식 가능한 솔루션을 제공할 수 있습니다.

Secret 오브젝트를 사용하여 포드에 중요한 데이터를 제공합니다.

관리자

일부 애플리케이션에는 암호 및 사용자 이름과 같은 중요한 정보가 필요합니다. Secret 오브젝트를 사용하여 애플리케이션 Pod에 이러한 정보를 제공할 수 있습니다.

1.3. 컨테이너 정보
링크 복사

컨테이너는 OpenShift Container Platform 애플리케이션의 기본 단위로, 종속 항목, 라이브러리 및 바이너리와 함께 패키지된 애플리케이션 코드를 구성합니다. 컨테이너에서는 물리 서버, 가상 머신(VM) 및 프라이빗 또는 퍼블릭 클라우드와 같은 환경 및 여러 배치 대상 사이에 일관성을 제공합니다.

Linux 컨테이너 기술은 실행 중인 프로세스를 격리하고 지정된 리소스에만 액세스할 수 있는 경량 메커니즘입니다. 관리자는 다음과 같은 Linux 컨테이너에서 다양한 작업을 수행할 수 있습니다.

OpenShift Container Platform은 Init 컨테이너라는 특수 컨테이너를 제공합니다. Init 컨테이너는 애플리케이션 컨테이너보다 먼저 실행되며 애플리케이션 이미지에 없는 유틸리티 또는 설정 스크립트를 포함할 수 있습니다. Init 컨테이너를 사용하여 나머지 Pod를 배포하기 전에 작업을 수행할 수 있습니다.

노드, Pod 및 컨테이너에서 특정 작업을 수행하는 것 외에도 전체 OpenShift Container Platform 클러스터에서 작업하여 클러스터의 효율성과 애플리케이션 Pod를 고가용성으로 유지할 수 있습니다.

2장. 노드 작업
링크 복사

2.1. Pod 사용
링크 복사

Pod는 하나의 호스트에 함께 배포되는 하나 이상의 컨테이너이자 정의, 배포, 관리할 수 있는 최소 컴퓨팅 단위입니다.

2.1.1. Pod 이해
링크 복사

Pod는 컨테이너에 대한 머신 인스턴스(실제 또는 가상)와 대략적으로 동일합니다. 각 Pod에는 자체 내부 IP 주소가 할당되므로 해당 Pod가 전체 포트 공간을 소유하고 Pod 내의 컨테이너는 로컬 스토리지와 네트워킹을 공유할 수 있습니다.

Pod에는 라이프사이클이 정의되어 있으며 노드에서 실행되도록 할당된 다음 컨테이너가 종료되거나 기타 이유로 제거될 때까지 실행됩니다. Pod는 정책 및 종료 코드에 따라 종료 후 제거되거나 컨테이너 로그에 대한 액세스를 활성화하기 위해 유지될 수 있습니다.

OpenShift Container Platform에서는 대체로 Pod를 변경할 수 없는 것으로 취급합니다. 실행 중에는 Pod 정의를 변경할 수 없습니다. OpenShift Container Platform은 기존 Pod를 종료한 후 수정된 구성이나 기본 이미지 또는 둘 다 사용하여 Pod를 다시 생성하는 방식으로 변경 사항을 구현합니다. Pod를 다시 생성하면 확장 가능한 것으로 취급되고 상태가 유지되지 않습니다. 따라서 일반적으로 Pod는 사용자가 직접 관리하는 대신 상위 수준의 컨트롤러에서 관리해야 합니다.

참고

OpenShift Container Platform 노드 호스트당 최대 Pod 수는 클러스터 제한을 참조하십시오.

주의

복제 컨트롤러에서 관리하지 않는 베어 Pod는 노드 중단 시 다시 예약되지 않습니다.

2.1.2. Pod 구성의 예
링크 복사

OpenShift Container Platform에서는 하나의 호스트에 함께 배포되는 하나 이상의 컨테이너이자 정의, 배포, 관리할 수 있는 최소 컴퓨팅 단위인 Pod의 Kubernetes 개념을 활용합니다.

다음은 Rails 애플리케이션의 포드 정의의 예입니다. 이 예제에서는 Pod의 다양한 기능을 보여줍니다. 대부분 다른 주제에서 설명하므로 여기에서는 간단히 언급합니다.

Pod 오브젝트 정의(YAML)

kind: Pod
apiVersion: v1
metadata:
  name: example
  namespace: default
  selfLink: /api/v1/namespaces/default/pods/example
  uid: 5cc30063-0265780783bc
  resourceVersion: '165032'
  creationTimestamp: '2019-02-13T20:31:37Z'
  labels:
    app: hello-openshift
1 

  annotations:
    openshift.io/scc: anyuid
spec:
  restartPolicy: Always
2 

  serviceAccountName: default
  imagePullSecrets:
    - name: default-dockercfg-5zrhb
  priority: 0
  schedulerName: default-scheduler
  terminationGracePeriodSeconds: 30
  nodeName: ip-10-0-140-16.us-east-2.compute.internal
  securityContext:
3 

    seLinuxOptions:
      level: 's0:c11,c10'
  containers:
4 

    - resources: {}
      terminationMessagePath: /dev/termination-log
      name: hello-openshift
      securityContext:
        capabilities:
          drop:
            - MKNOD
        procMount: Default
      ports:
        - containerPort: 8080
          protocol: TCP
      imagePullPolicy: Always
      volumeMounts:
5 

        - name: default-token-wbqsl
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
6 

      terminationMessagePolicy: File
      image: registry.redhat.io/openshift4/ose-ogging-eventrouter:v4.3
7 

  serviceAccount: default
8 

  volumes:
9 

    - name: default-token-wbqsl
      secret:
        secretName: default-token-wbqsl
        defaultMode: 420
  dnsPolicy: ClusterFirst
status:
  phase: Pending
  conditions:
    - type: Initialized
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
    - type: Ready
      status: 'False'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
      reason: ContainersNotReady
      message: 'containers with unready status: [hello-openshift]'
    - type: ContainersReady
      status: 'False'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
      reason: ContainersNotReady
      message: 'containers with unready status: [hello-openshift]'
    - type: PodScheduled
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: '2019-02-13T20:31:37Z'
  hostIP: 10.0.140.16
  startTime: '2019-02-13T20:31:37Z'
  containerStatuses:
    - name: hello-openshift
      state:
        waiting:
          reason: ContainerCreating
      lastState: {}
      ready: false
      restartCount: 0
      image: openshift/hello-openshift
      imageID: ''
  qosClass: BestEffort
Copy to Clipboard Toggle word wrap

1
Pod는 단일 작업에서 Pod 그룹을 선택하고 관리하는 데 사용할 수 있는 라벨을 하나 이상 사용하여 "태그를 지정"할 수 있습니다. 라벨은 metadata 해시의 키/값 형식으로 저장됩니다.
2
Pod는 가능한 값 Always, OnFailure, Never를 사용하여 정책을 재시작합니다. 기본값은 Always입니다.
3
OpenShift Container Platform은 컨테이너에 대한 보안 컨텍스트를 정의합니다. 보안 컨텍스트는 권한 있는 컨테이너로 실행하거나 선택한 사용자로 실행할 수 있는지의 여부 등을 지정합니다. 기본 컨텍스트는 매우 제한적이지만 필요에 따라 관리자가 수정할 수 있습니다.
4
containers는 하나 이상의 컨테이너 정의로 이루어진 배열을 지정합니다.
5
이 컨테이너는 컨테이너 내에서 외부 스토리지 볼륨이 마운트되는 위치를 지정합니다. 이 경우 레지스트리에서 OpenShift Container Platform API에 대해 요청하는 데 필요한 자격 증명 액세스 권한을 저장하는 볼륨이 있습니다.
6
Pod에 제공할 볼륨을 지정합니다. 볼륨이 지정된 경로에 마운트합니다. 컨테이너 루트, / 또는 호스트와 컨테이너에서 동일한 경로에 마운트하지 마십시오. 컨테이너가 호스트 /dev/pts 파일과 같이 충분한 권한이 있는 경우 호스트 시스템이 손상될 수 있습니다. /host를 사용하여 호스트를 마운트하는 것이 안전합니다.
7
Pod의 각 컨테이너는 자체 컨테이너 이미지에서 인스턴스화됩니다.
8
OpenShift Container Platform API에 대해 요청하는 Pod는 요청 시 Pod에서 인증해야 하는 서비스 계정 사용자를 지정하는 serviceAccount 필드가 있는 일반적인 패턴입니다. 따라서 사용자 정의 인프라 구성 요소에 대한 액세스 권한을 세부적으로 제어할 수 있습니다.
9
Pod는 사용할 컨테이너에서 사용할 수 있는 스토리지 볼륨을 정의합니다. 이 경우 기본 서비스 계정 토큰이 포함된 시크릿 볼륨에 대한 임시 볼륨을 제공합니다.

파일이 많은 영구 볼륨을 Pod에 연결하면 해당 Pod가 실패하거나 시작하는 데 시간이 오래 걸릴 수 있습니다. 자세한 내용은 OpenShift에서 파일 수가 많은 영구 볼륨을 사용하는 경우 Pod를 시작하지 못하거나 과도한 시간을 차지하여 "Ready" 상태를 얻을 수 없는 이유는 무엇입니까?

참고

이 Pod 정의에는 Pod가 생성되고 해당 라이프사이클이 시작된 후 OpenShift Container Platform에 의해 자동으로 채워지는 특성은 포함되지 않습니다. Kubernetes Pod 설명서에는 Pod의 기능 및 용도에 대한 세부 정보가 있습니다.

2.2. Pod 보기
링크 복사

관리자는 클러스터의 Pod를 보고 해당 Pod 및 클러스터의 상태를 전체적으로 확인할 수 있습니다.

2.2.1. Pod 정보
링크 복사

OpenShift Container Platform에서는 하나의 호스트에 함께 배포되는 하나 이상의 컨테이너이자 정의, 배포, 관리할 수 있는 최소 컴퓨팅 단위인 Pod의 Kubernetes 개념을 활용합니다. Pod는 컨테이너에 대한 머신 인스턴스(실제 또는 가상)와 대략적으로 동일합니다.

특정 프로젝트와 연결된 Pod 목록을 확인하거나 Pod 관련 사용량 통계를 볼 수 있습니다.

2.2.2. 프로젝트의 Pod 보기
링크 복사

Pod의 복제본 수, 현재 상태, 재시작 횟수, 수명 등을 포함하여 현재 프로젝트와 관련된 Pod 목록을 확인할 수 있습니다.

프로세스

프로젝트의 Pod를 보려면 다음을 수행합니다.

  1. 프로젝트로 변경합니다. 

    $ oc project <project-name>
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행합니다. 

    $ oc get pods
    Copy to Clipboard Toggle word wrap

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

    $ oc get pods -n openshift-console
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                       READY   STATUS    RESTARTS   AGE
console-698d866b78-bnshf   1/1     Running   2          165m
console-698d866b78-m87pm   1/1     Running   2          165m
    Copy to Clipboard Toggle word wrap

    Pod IP 주소와 Pod가 있는 노드를 보려면 -o wide 플래그를 추가합니다. 

    $ oc get pods -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                       READY   STATUS    RESTARTS   AGE    IP            NODE                           NOMINATED NODE
console-698d866b78-bnshf   1/1     Running   2          166m   10.128.0.24   ip-10-0-152-71.ec2.internal    <none>
console-698d866b78-m87pm   1/1     Running   2          166m   10.129.0.23   ip-10-0-173-237.ec2.internal   <none>
    Copy to Clipboard Toggle word wrap

2.2.3. Pod 사용량 통계 보기
링크 복사

컨테이너의 런타임 환경을 제공하는 Pod에 대한 사용량 통계를 표시할 수 있습니다. 이러한 사용량 통계에는 CPU, 메모리, 스토리지 사용량이 포함됩니다.

사전 요구 사항

  • 사용량 통계를 보려면 cluster-reader 권한이 있어야 합니다.
  • 사용량 통계를 보려면 메트릭이 설치되어 있어야 합니다.

프로세스

사용량 통계를 보려면 다음을 수행합니다.

  1. 다음 명령을 실행합니다. 

    $ oc adm top pods
    Copy to Clipboard Toggle word wrap

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

    $ oc adm top pods -n openshift-console
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                         CPU(cores)   MEMORY(bytes)
console-7f58c69899-q8c8k     0m           22Mi
console-7f58c69899-xhbgg     0m           25Mi
downloads-594fcccf94-bcxk8   3m           18Mi
downloads-594fcccf94-kv4p6   2m           15Mi
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 라벨이 있는 Pod의 사용량 통계를 확인합니다. 

    $ oc adm top pod --selector=''
    Copy to Clipboard Toggle word wrap

    필터링할 선택기(라벨 쿼리)를 선택해야 합니다. =, ==, !=가 지원됩니다.

2.2.4. 리소스 로그 보기
링크 복사

OpenShift CLI(oc) 및 웹 콘솔에서 다양한 리소스의 로그를 볼 수 있습니다. 로그는 로그의 말미 또는 끝에서 읽습니다.

사전 요구 사항

  • OpenShift CLI(oc)에 액세스합니다.

프로세스(UI)

  1. OpenShift Container Platform 콘솔에서 워크로드 → Pod로 이동하거나 조사하려는 리소스를 통해 Pod로 이동합니다.

    참고

    빌드와 같은 일부 리소스에는 직접 쿼리할 Pod가 없습니다. 이러한 인스턴스에서 리소스의 세부 정보 페이지에서 로그 링크를 찾을 수 있습니다.

  2. 드롭다운 메뉴에서 프로젝트를 선택합니다.
  3. 조사할 Pod 이름을 클릭합니다.
  4. 로그를 클릭합니다.

프로세스(CLI)

  • 특정 Pod의 로그를 확인합니다. 

    $ oc logs -f <pod_name> -c <container_name>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    -f
    선택 사항: 출력이 로그에 기록되는 내용을 따르도록 지정합니다.
    <pod_name>
    pod 이름을 지정합니다.
    <container_name>
    선택 사항: 컨테이너의 이름을 지정합니다. Pod에 여러 컨테이너가 있는 경우 컨테이너 이름을 지정해야 합니다.

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

    $ oc logs ruby-58cd97df55-mww7r
    Copy to Clipboard Toggle word wrap 
    $ oc logs -f ruby-57f7f4855b-znl92 -c ruby
    Copy to Clipboard Toggle word wrap

    로그 파일의 내용이 출력됩니다.

  • 특정 리소스의 로그를 확인합니다. 

    $ oc logs <object_type>/<resource_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    리소스 유형 및 이름을 지정합니다.

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

    $ oc logs deployment/ruby
    Copy to Clipboard Toggle word wrap

    로그 파일의 내용이 출력됩니다.

2.3. Pod에 대한 OpenShift Container Platform 클러스터 구성
링크 복사

관리자는 Pod에 효율적인 클러스터를 생성하고 유지 관리할 수 있습니다.

클러스터를 효율적으로 유지하면 Pod가 종료될 때 수행하는 작업과 같은 툴을 사용하여 개발자에게 더 나은 환경을 제공할 수 있습니다. 즉 필요한 수의 Pod가 항상 실행되고 있는지 확인하여 한 번만 실행되도록 설계된 Pod를 재시작하는 경우 Pod에 사용할 수 있는 대역폭을 제한하고, 중단 중 Pod를 계속 실행하는 방법을 제공합니다.

2.3.1. 재시작 후 Pod 작동 방식 구성
링크 복사

Pod 재시작 정책에 따라 해당 Pod의 컨테이너가 종료될 때 OpenShift Container Platform에서 응답하는 방법이 결정됩니다. 정책은 해당 Pod의 모든 컨테이너에 적용됩니다.

가능한 값은 다음과 같습니다.

  • Always - Pod가 재시작될 때까지 급격한 백오프 지연(10초, 20초, 40초)을 사용하여 Pod에서 성공적으로 종료된 컨테이너를 계속 재시작합니다. 기본값은 Always입니다.
  • OnFailure - 급격한 백오프 지연(10초, 20초, 40초)을 5분으로 제한하여 Pod에서 실패한 컨테이너를 재시작합니다.
  • Never - Pod에서 종료되거나 실패한 컨테이너를 재시작하지 않습니다. Pod가 즉시 실패하고 종료됩니다.

Pod가 특정 노드에 바인딩된 후에는 다른 노드에 바인딩되지 않습니다. 따라서 노드 장애 시 Pod가 작동하려면 컨트롤러가 필요합니다.

Expand
상태컨트롤러 유형재시작 정책

종료할 것으로 예상되는 Pod(예: 일괄 계산)

Job

OnFailure 또는 Never

종료되지 않을 것으로 예상되는 Pod(예: 웹 서버)

복제 컨트롤러

Always

머신당 하나씩 실행해야 하는 Pod

데몬 세트

Any

Pod의 컨테이너가 실패하고 재시작 정책이 OnFailure로 설정된 경우 Pod가 노드에 남아 있고 컨테이너가 재시작됩니다. 컨테이너를 재시작하지 않으려면 재시작 정책 Never를 사용하십시오.

전체 Pod가 실패하면 OpenShift Container Platform에서 새 Pod를 시작합니다. 개발자는 애플리케이션이 새 Pod에서 재시작될 수 있는 가능성을 고려해야 합니다. 특히 애플리케이션에서는 이전 실행으로 발생한 임시 파일, 잠금, 불완전한 출력 등을 처리해야 합니다.

참고

Kubernetes 아키텍처에서는 클라우드 공급자의 끝점이 안정적인 것으로 예상합니다. 클라우드 공급자가 중단되면 kubelet에서 OpenShift Container Platform이 재시작되지 않습니다.

기본 클라우드 공급자 끝점이 안정적이지 않은 경우 클라우드 공급자 통합을 사용하여 클러스터를 설치하지 마십시오. 클라우드가 아닌 환경에서처럼 클러스터를 설치합니다. 설치된 클러스터에서 클라우드 공급자 통합을 설정하거나 해제하는 것은 권장되지 않습니다.

OpenShift Container Platform에서 실패한 컨테이너에 재시작 정책을 사용하는 방법에 대한 자세한 내용은 Kubernetes 설명서의 예제 상태를 참조하십시오.

2.3.2. Pod에서 사용할 수 있는 대역폭 제한
링크 복사

Pod에 서비스 품질 트래픽 조절 기능을 적용하고 사용 가능한 대역폭을 효과적으로 제한할 수 있습니다. Pod에서 송신하는 트래픽은 구성된 속도를 초과하는 패킷을 간단히 삭제하는 정책에 따라 처리합니다. Pod에 수신되는 트래픽은 데이터를 효과적으로 처리하기 위해 대기 중인 패킷을 구성하여 처리합니다. 특정 Pod에 대한 제한 사항은 다른 Pod의 대역폭에 영향을 미치지 않습니다.

프로세스

Pod의 대역폭을 제한하려면 다음을 수행합니다.

  1. 오브젝트 정의 JSON 파일을 작성하고 kubernetes.io/ingress-bandwidth 및 kubernetes.io/egress-bandwidth 주석을 사용하여 데이터 트래픽 속도를 지정합니다. 예를 들어 Pod 송신 및 수신 대역폭을 둘 다 10M/s로 제한하려면 다음을 수행합니다.

    제한된 Pod 오브젝트 정의

    {
    "kind": "Pod",
    "spec": {
        "containers": [
            {
                "image": "openshift/hello-openshift",
                "name": "hello-openshift"
            }
        ]
    },
    "apiVersion": "v1",
    "metadata": {
        "name": "iperf-slow",
        "annotations": {
            "kubernetes.io/ingress-bandwidth": "10M",
            "kubernetes.io/egress-bandwidth": "10M"
        }
    }
}
    Copy to Clipboard Toggle word wrap

  2. 오브젝트 정의를 사용하여 Pod를 생성합니다. 

    $ oc create -f <file_or_dir_path>
    Copy to Clipboard Toggle word wrap

2.3.3. Pod 중단 예산을 사용하여 실행 중인 pod 수를 지정하는 방법
링크 복사

Pod 중단 예산은 Kubernetes API의 일부이며 다른 오브젝트 유형과 같은 oc 명령으로 관리할 수 있습니다. 유지 관리를 위해 노드를 드레이닝하는 것과 같이 작업 중에 pod 에 대한 보안 제약 조건을 지정할 수 있습니다.

PodDisruptionBudget은 동시에 작동해야 하는 최소 복제본 수 또는 백분율을 지정하는 API 오브젝트입니다. 프로젝트에서 이러한 설정은 노드 유지 관리 (예: 클러스터 축소 또는 클러스터 업그레이드) 중에 유용할 수 있으며 (노드 장애 시가 아니라) 자발적으로 제거된 경우에만 적용됩니다.

PodDisruptionBudget 오브젝트의 구성은 다음과 같은 주요 부분으로 구성되어 있습니다.

  • 일련의 pod에 대한 라벨 쿼리 기능인 라벨 선택기입니다.

  • 동시에 사용할 수 있어야 하는 최소 pod 수를 지정하는 가용성 수준입니다.

    • minAvailable은 중단 중에도 항상 사용할 수 있어야하는 pod 수입니다.
    • maxUnavailable은 중단 중에 사용할 수없는 pod 수입니다.
참고

maxUnavailable 0 % 또는 0이나 minAvailable의 100 % 혹은 복제본 수와 동일한 값은 허용되지만 이로 인해 노드가 드레인되지 않도록 차단할 수 있습니다.

다음을 사용하여 모든 프로젝트에서 pod 중단 예산을 확인할 수 있습니다. 

$ oc get poddisruptionbudget --all-namespaces
Copy to Clipboard Toggle word wrap

출력 예

NAMESPACE         NAME          MIN-AVAILABLE   SELECTOR
another-project   another-pdb   4               bar=foo
test-project      my-pdb        2               foo=bar
Copy to Clipboard Toggle word wrap

PodDisruptionBudget은 시스템에서 최소 minAvailable pod가 실행중인 경우 정상으로 간주됩니다. 이 제한을 초과하는 모든 pod는 제거할 수 있습니다.

참고

Pod 우선 순위 및 선점 설정에 따라 우선 순위가 낮은 pod는 pod 중단 예산 요구 사항을 무시하고 제거될 수 있습니다.

2.3.3.1. Pod 중단 예산을 사용하여 실행해야 할 pod 수 지정
링크 복사

PodDisruptionBudget 오브젝트를 사용하여 동시에 가동되어야 하는 최소 복제본 수 또는 백분율을 지정할 수 있습니다.

프로세스

pod 중단 예산을 구성하려면 다음을 수행합니다.

  1. 다음과 같은 오브젝트 정의를 사용하여 YAML 파일을 만듭니다. 

    apiVersion: policy/v1beta1
    1 
    
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2
    2 
    
  selector:
    3 
    
    matchLabels:
      foo: bar
    Copy to Clipboard Toggle word wrap
    1
    PodDisruptionBudget은 policy/v1beta1 API 그룹의 일부입니다.
    2
    동시에 사용할 수 필요가 있는 최소 pod 수 입니다. 정수 또는 백분율 (예: 20 %)을 지정하는 문자열을 사용할 수 있습니다.
    3
    리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다.

    또는 다음을 수행합니다. 

    apiVersion: policy/v1beta1
    1 
    
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  maxUnavailable: 25%
    2 
    
  selector:
    3 
    
    matchLabels:
      foo: bar
    Copy to Clipboard Toggle word wrap
    1
    PodDisruptionBudget은 policy/v1beta1 API 그룹의 일부입니다.
    2
    동시에 사용할 수없는 최대 pod 수입니다. 정수 또는 백분율 (예: 20 %)을 지정하는 문자열을 사용할 수 있습니다.
    3
    리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다.

  2. 다음 명령을 실행하여 오브젝트를 프로젝트에 추가합니다. 

    $ oc create -f </path/to/file> -n <project_name>
    Copy to Clipboard Toggle word wrap

2.3.4. 중요 Pod를 사용하여 Pod 제거 방지
링크 복사

완전히 작동하는 클러스터에 중요하지만 마스터가 아닌 일반 클러스터 노드에서 실행되는 다양한 핵심 구성 요소가 있습니다. 중요한 추가 기능이 제거되면 클러스터가 제대로 작동하지 않을 수 있습니다.

중요로 표시된 Pod는 제거할 수 없습니다.

프로세스

Pod를 중요로 설정하려면 다음을 수행합니다.

  1. Pod 사양을 생성하거나 system-cluster-critical 우선순위 클래스를 포함하도록 기존 Pod를 편집합니다. 

    spec:
  template:
    metadata:
      name: critical-pod
    priorityClassName: system-cluster-critical
    1
    Copy to Clipboard Toggle word wrap
    1
    노드에서 제거해서는 안 되는 Pod의 기본 우선순위 클래스입니다.

    또는 클러스터에 중요한 Pod에 대해 system-node-critical을 지정할 수 있지만 필요한 경우 제거할 수도 있습니다.

  2. Pod를 생성합니다. 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

2.4. 수평 Pod 자동 스케일러를 사용하여 Pod 자동 스케일링
링크 복사

개발자는 HPA(수평 Pod 자동 스케일러)를 사용하여 해당 복제 컨트롤러 또는 배포 구성에 속하는 Pod에서 수집한 메트릭을 기반으로 OpenShift Container Platform에서 복제 컨트롤러 또는 배포 구성의 규모를 자동으로 늘리거나 줄이는 방법을 지정할 수 있습니다.

2.4.1. 수평 Pod 자동 스케일러 이해
링크 복사

수평 Pod 자동 스케일러를 생성하여 실행하려는 최소 및 최대 Pod 수와 Pod에서 목표로 하는 CPU 사용률 또는 메모리 사용률을 지정할 수 있습니다.

중요

메모리 사용률에 대한 자동 확장은 기술 프리뷰 기능 전용입니다.

수평 Pod 자동 스케일러를 생성하면 OpenShift Container Platform에서 Pod의 CPU 및/또는 메모리 리소스 메트릭을 쿼리합니다. 이러한 메트릭을 사용할 수 있는 경우 수평 Pod 자동 스케일러에서 현재 메트릭 사용률과 원하는 메트릭 사용률의 비율을 계산하고 그에 따라 확장 또는 축소합니다. 쿼리 및 스케일링은 정기적으로 수행되지만 메트릭을 사용할 수 있을 때까지 1~2분이 걸릴 수 있습니다.

복제 컨트롤러의 경우 이러한 스케일링은 복제 컨트롤러의 복제본과 직접적으로 일치합니다. 배포 구성의 경우 스케일링은 배포 구성의 복제본 수와 직접적으로 일치합니다. 자동 스케일링은 Complete 단계에서 최신 배포에만 적용됩니다.

OpenShift Container Platform은 리소스를 자동으로 차지하여 시작하는 동안과 같이 리소스가 급증하는 동안 불필요한 자동 스케일링을 방지합니다. unready 상태의 Pod는 확장 시 CPU 사용량이 0이고, 축소 시에는 자동 스케일러에서 Pod를 무시합니다. 알려진 메트릭이 없는 Pod는 확장 시 CPU 사용량이 0%이고, 축소 시에는 100%입니다. 이를 통해 HPA를 결정하는 동안 안정성이 향상됩니다. 이 기능을 사용하려면 준비 상태 점검을 구성하여 새 Pod를 사용할 준비가 되었는지 확인해야 합니다.

수평 Pod 자동 스케일러를 사용하려면 클러스터 관리자가 클러스터 메트릭을 올바르게 구성해야 합니다.

2.4.1.1. 지원되는 메트릭
링크 복사

수평 Pod 자동 스케일러에서는 다음 메트릭을 지원합니다.

Expand
표 2.1. 메트릭
메트릭설명API 버전

CPU 사용

사용되는 CPU 코어의 수입니다. Pod에서 요청하는 CPU의 백분율을 계산하는 데 사용할 수 있습니다.

autoscaling/v1, autoscaling/v2beta2

메모리 사용률

사용되는 메모리의 양입니다. Pod에서 요청하는 메모리의 백분율을 계산하는 데 사용할 수 있습니다.

autoscaling/v2beta2

중요

메모리 기반 자동 스케일링의 경우 메모리 사용량이 복제본 수에 비례하여 증가 및 감소해야 합니다. 평균적으로 다음과 같습니다.

  • 복제본 수가 증가하면 Pod당 메모리(작업 집합) 사용량이 전반적으로 감소해야 합니다.
  • 복제본 수가 감소하면 Pod별 메모리 사용량이 전반적으로 증가해야 합니다.

메모리 기반 자동 스케일링을 사용하기 전에 OpenShift Container Platform 웹 콘솔을 사용하여 애플리케이션의 메모리 동작을 확인하고 애플리케이션이 해당 요구 사항을 충족하는지 확인하십시오.

다음 예제에서는 image-registry DeploymentConfig 오브젝트에 대한 자동 스케일링을 보여줍니다. 초기 배포에는 Pod 3개가 필요합니다. HPA 오브젝트에서 해당 최솟값을 5개로 늘렸으며 Pod의 CPU 사용량이 75%에 도달하면 7개까지 늘립니다. 

$ oc autoscale dc/image-registry --min=5 --max=7 --cpu-percent=75
Copy to Clipboard Toggle word wrap

출력 예

horizontalpodautoscaler.autoscaling/image-registry autoscaled
Copy to Clipboard Toggle word wrap

minReplicas 가 3으로 설정된 image-registry DeploymentConfig 오브젝트의 샘플 HPA

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: image-registry
  namespace: default
spec:
  maxReplicas: 7
  minReplicas: 3
  scaleTargetRef:
    apiVersion: apps.openshift.io/v1
    kind: DeploymentConfig
    name: image-registry
  targetCPUUtilizationPercentage: 75
status:
  currentReplicas: 5
  desiredReplicas: 0
Copy to Clipboard Toggle word wrap

  1. 배포의 새 상태를 확인합니다. 

    $ oc get dc image-registry
    Copy to Clipboard Toggle word wrap

    이제 배포에 Pod 5개가 있습니다.

    출력 예

    NAME             REVISION   DESIRED   CURRENT   TRIGGERED BY
image-registry   1          5         5         config
    Copy to Clipboard Toggle word wrap

2.4.1.2. 스케일링 정책
링크 복사

autoscaling/v2beta2 API를 사용하면 수평 Pod 자동 스케일러에 스케일링 정책을 추가할 수 있습니다. 스케일링 정책은 OpenShift Container Platform HPA(수평 Pod 자동 스케일러)에서 Pod를 스케일링하는 방법을 제어합니다. 스케일링 정책을 사용하면 지정된 기간에 스케일링할 특정 수 또는 특정 백분율을 설정하여 HPA에서 Pod를 확장 또는 축소하는 비율을 제한할 수 있습니다. 또한 메트릭이 계속 변동하는 경우 이전에 계산한 원하는 상태를 사용하여 스케일링을 제어하는 안정화 기간을 정의할 수 있습니다. 동일한 스케일링 방향(확장 또는 축소)에 대해 여러 정책을 생성하여 변경 정도에 따라 사용할 정책을 결정할 수 있습니다. 반복 시간을 지정하여 스케일링을 제한할 수도 있습니다. HPA는 반복 중 Pod를 스케일링한 다음 필요에 따라 추가 반복에서 스케일링을 수행합니다.

스케일링 정책이 포함된 HPA 오브젝트 샘플

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-memory
  namespace: default
spec:
  behavior:
    scaleDown:
1 

      policies:
2 

      - type: Pods
3 

        value: 4
4 

        periodSeconds: 60
5 

      - type: Percent
        value: 10
6 

        periodSeconds: 60
      selectPolicy: Min
7 

      stabilizationWindowSeconds: 300
8 

    scaleUp:
9 

      policies:
      - type: Pods
        value: 5
10 

        periodSeconds: 70
      - type: Percent
        value: 12
11 

        periodSeconds: 80
      selectPolicy: Max
      stabilizationWindowSeconds: 0
...
Copy to Clipboard Toggle word wrap

1
스케일링 정책의 방향, 즉 scaleDown 또는 scaleUp을 지정합니다. 이 예제에서는 축소 정책을 생성합니다.
2
스케일링 정책을 정의합니다.
3
정책이 각 반복에서 특정 Pod 수 또는 Pod 백분율로 스케일링하는지의 여부를 결정합니다. 기본값은 pods입니다.
4
각 반복 중에 Pod 수 또는 Pod 백분율 중 하나의 스케일링 정도를 결정합니다. Pod 수에 따라 축소할 기본값은 없습니다.
5
스케일링 반복의 길이를 결정합니다. 기본값은 15초입니다.
6
백분율로 된 축소 기본값은 100%입니다.
7
여러 정책이 정의된 경우 먼저 사용할 정책을 결정합니다. 가장 많은 변경을 허용하는 정책을 사용하려면 Max를 지정하고, 최소 변경을 허용하는 정책을 사용하려면 Min을 지정합니다. HPA에서 해당 정책 방향으로 스케일링하지 않도록 하려면 Disabled를 지정합니다. 기본값은 Max입니다.
8
HPA에서 원하는 상태를 검토해야 하는 기간을 결정합니다. 기본값은 0입니다.
9
이 예제에서는 확장 정책을 생성합니다.
10
Pod 수에 따라 확장되는 수입니다. Pod 수 확장 기본값은 4%입니다.
11
Pod 백분율에 따라 확장되는 수입니다. 백분율로 된 확장 기본값은 100%입니다.

축소 정책의 예

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-memory
  namespace: default
spec:
...
  minReplicas: 20
...
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 4
        periodSeconds: 30
      - type: Percent
        value: 10
        periodSeconds: 60
      selectPolicy: Max
    scaleUp:
      selectPolicy: Disabled
Copy to Clipboard Toggle word wrap

이 예제에서 Pod 수가 40개를 초과하면 selectPolicy에서 요구하는 대로 해당 정책으로 인해 상당한 변경이 발생하므로 축소에 백분율 기반 정책이 사용됩니다.

Pod 복제본이 80개 있는 경우 HPA는 첫 번째 반복에서 Pod를 8로 줄이며 이는 유형에 기반하여 80개의 Pod 중 10%입니다. percent 및 값: 10 매개 변수), 1분 동안 (periodSeconds: 60). 다음 반복에서는 Pod가 72개입니다. HPA는 나머지 Pod의 10%를 계산한 7.2개를 8개로 올림하여 Pod 8개를 축소합니다. 이후 반복할 때마다 나머지 Pod 수에 따라 스케일링할 Pod 수가 다시 계산됩니다. Pod 수가 40개 미만으로 줄어들면 Pod 기반 숫자가 백분율 기반 숫자보다 크기 때문에 Pod 기반 정책이 적용됩니다. HPA는 한 번에 Pod 4개를 줄입니다(type: pods 및 값: 4), 30 초 동안 (periodSeconds : 30), 20개의 복제본이 남아 있을 때까지 (minReplicas).

selectPolicy: disabled 매개변수는 HPA가 Pod를 확장하지 못하게 합니다. 필요한 경우 복제본 세트 또는 배포 세트의 복제본 수를 조정하여 수동으로 확장할 수 있습니다.

설정되어 있는 경우 oc edit 명령을 사용하여 스케일링 정책을 확인할 수 있습니다. 

$ oc edit hpa hpa-resource-metrics-memory
Copy to Clipboard Toggle word wrap

출력 예

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  annotations:
    autoscaling.alpha.kubernetes.io/behavior:\
'{"ScaleUp":{"StabilizationWindowSeconds":0,"SelectPolicy":"Max","Policies":[{"Type":"Pods","Value":4,"PeriodSeconds":15},{"Type":"Percent","Value":100,"PeriodSeconds":15}]},\
"ScaleDown":{"StabilizationWindowSeconds":300,"SelectPolicy":"Min","Policies":[{"Type":"Pods","Value":4,"PeriodSeconds":60},{"Type":"Percent","Value":10,"PeriodSeconds":60}]}}'
...
Copy to Clipboard Toggle word wrap

2.4.2. 웹 콘솔을 사용하여 수평 Pod 자동 스케일러 생성
링크 복사

웹 콘솔에서 배포에서 실행하려는 최소 및 최대 Pod 수를 지정하는 HPA(수평 Pod 자동 스케일러)를 생성할 수 있습니다. Pod에서 대상으로 하는 CPU 또는 메모리 사용량도 정의할 수 있습니다.

참고

HPA는 Operator 지원 서비스, Knative 서비스 또는 Helm 차트의 일부인 배포에 추가할 수 없습니다.

절차

웹 콘솔에서 HPA를 생성하려면 다음을 수행합니다.

  1. 토폴로지 보기에서 노드를 클릭하여 측면 창을 표시합니다.

  2. 작업 드롭다운 목록에서 HorizontalPodAutoscaler 추가 를 선택하여 HorizontalPodAutoscaler 추가 양식을 엽니다.

    그림 2.1. Add HorizontalPodAutoscaler

    HorizontalPodAutoscaler 추가 양식
    View larger image
    HorizontalPodAutoscaler 추가 양식

  3. HorizontalPodAutoscaler 추가 양식에서 이름, 최소 및 최대 Pod 제한, CPU 및 메모리 사용량을 정의하고 저장을 클릭합니다.

    참고

    CPU 및 메모리 사용량에 대한 값이 없는 경우 경고가 표시됩니다.

웹 콘솔에서 HPA를 편집하려면 다음을 수행합니다.

  1. 토폴로지 보기에서 노드를 클릭하여 측면 창을 표시합니다.
  2. 작업 드롭다운 목록에서 HorizontalPodAutoscaler 편집을 선택하여 Horizontal Pod Autoscaler 편집 양식을 엽니다.
  3. Horizontal Pod Autoscaler 편집 양식에서 최소 및 최대 Pod 제한과 CPU 및 메모리 사용량을 편집한 다음 저장을 클릭합니다.
참고

웹 콘솔에서 수평 Pod 자동 스케일러를 생성하거나 편집하는 동안 양식 보기에서 YAML 보기로 전환할 수 있습니다.

웹 콘솔에서 HPA를 제거하려면 다음을 수행합니다.

  1. 토폴로지 보기에서 노드를 클릭하여 측면 창을 표시합니다.
  2. 작업 드롭다운 목록에서 HorizontalPodAutoscaler 제거를 선택합니다.
  3. 확인 팝업 창에서 제거를 클릭하여 HPA를 제거합니다.

2.4.3. CLI를 사용하여 CPU 사용률에 대한 수평 Pod 자동 스케일러 생성
링크 복사

기존 Deployment,DeploymentConfig,ReplicaSet,ReplicationController 또는 StatefulSet 오브젝트에 HPA(수평 Pod 자동 스케일러)를 생성하여 지정하는 CPU 사용량을 유지하도록 해당 오브젝트와 연결된 Pod를 자동으로 스케일링할 수 있습니다.

HPA는 최소 및 최대 개수 사이에서 복제본 수를 늘리거나 줄여 전체 Pod에서 지정된 CPU 사용률을 유지합니다.

CPU 사용률을 자동 스케일링할 때는 oc autoscale 명령을 사용하여 언제든지 실행하려는 최소 및 최대 Pod 수와 Pod에서 목표로 하는 평균 CPU 사용률을 지정할 수 있습니다. 최솟값을 지정하지 않으면 Pod에 OpenShift Container Platform 서버의 기본값이 지정됩니다. 특정 CPU 값을 자동 스케일링하려면 대상 CPU 및 Pod 제한을 사용하여 HorizontalPodAutoscaler 오브젝트를 생성합니다.

사전 요구 사항

수평 Pod 자동 스케일러를 사용하려면 클러스터 관리자가 클러스터 메트릭을 올바르게 구성해야 합니다. oc describe PodMetrics <pod-name> 명령을 사용하여 메트릭이 구성되어 있는지 확인할 수 있습니다. 메트릭이 구성된 경우 출력이 다음과 유사하게 표시되고 Usage에 Cpu 및 Memory가 표시됩니다. 

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Copy to Clipboard Toggle word wrap

출력 예

Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  wait-for-host-port
  Usage:
    Memory:  0
  Name:      scheduler
  Usage:
    Cpu:     8m
    Memory:  45440Ki
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2019-05-23T18:47:56Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Timestamp:             2019-05-23T18:47:56Z
Window:                1m0s
Events:                <none>
Copy to Clipboard Toggle word wrap

프로세스

CPU 사용률에 대한 수평 Pod 자동 스케일러를 생성하려면 다음을 수행합니다.

  1. 다음 중 하나를 수행합니다.

    • CPU 사용률 백분율에 따라 스케일링하려면 기존 오브젝트에 대한 HorizontalPodAutoscaler 오브젝트를 생성합니다. 

      $ oc autoscale <object_type>/<name> \
      1 
      
  --min <number> \
      2 
      
  --max <number> \
      3 
      
  --cpu-percent=<percent>
      4
      Copy to Clipboard Toggle word wrap
      1
      자동 스케일링할 오브젝트의 유형과 이름을 지정합니다. 오브젝트가 존재하고 Deployment,DeploymentConfig/dc,ReplicaSet/rs,ReplicationController/rc 또는 StatefulSet 이어야 합니다.
      2
      필요한 경우 축소 시 최소 복제본 수를 지정합니다.
      3
      확장 시 최대 복제본 수를 지정합니다.
      4
      요청된 CPU의 백분율로 표시되는 모든 Pod의 목표 평균 CPU 사용량을 지정합니다. 지정하지 않거나 음수가 아닌 경우 기본 자동 스케일링 정책이 사용됩니다.

      예를 들어 다음 명령은 image-registry DeploymentConfig 오브젝트에 대한 자동 스케일링을 보여줍니다. 초기 배포에는 Pod 3개가 필요합니다. HPA 오브젝트에서 해당 최솟값을 5개로 늘렸으며 Pod의 CPU 사용량이 75%에 도달하면 7개까지 늘립니다. 

      $ oc autoscale dc/image-registry --min=5 --max=7 --cpu-percent=75
      Copy to Clipboard Toggle word wrap

    • 특정 CPU 값을 스케일링하려면 기존 오브젝트에 대해 다음과 유사한 YAML 파일을 생성합니다.

      1. 다음과 유사한 YAML 파일을 생성합니다. 

        apiVersion: autoscaling/v2beta2
        1 
        
kind: HorizontalPodAutoscaler
metadata:
  name: cpu-autoscale
        2 
        
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: v1
        3 
        
    kind: ReplicaSet
        4 
        
    name: example
        5 
        
  minReplicas: 1
        6 
        
  maxReplicas: 10
        7 
        
  metrics:
        8 
        
  - type: Resource
    resource:
      name: cpu
        9 
        
      target:
        type: AverageValue
        10 
        
        averageValue: 500m
        11
        Copy to Clipboard Toggle word wrap
        1
        autoscaling/v2beta2 API를 사용합니다.
        2
        이 수평 Pod 자동 스케일러 오브젝트의 이름을 지정합니다.
        3
        스케일링할 오브젝트의 API 버전을 지정합니다.
        • ReplicationController 의 경우 v1 을 사용합니다.
        • deploymentConfig 의 경우 apps.openshift.io/v1 을 사용합니다.
        • Deployment,ReplicaSet,Statefulset 오브젝트의 경우 apps/v1 을 사용합니다.
        4
        오브젝트 유형을 지정합니다. 오브젝트는 Deployment,DeploymentConfig/dc,ReplicaSet/rs,ReplicationController/rc 또는 StatefulSet 이어야 합니다.
        5
        스케일링할 오브젝트의 이름을 지정합니다. 오브젝트가 있어야 합니다.
        6
        축소 시 최소 복제본 수를 지정합니다.
        7
        확장 시 최대 복제본 수를 지정합니다.
        8
        메모리 사용률에 metrics 매개변수를 사용합니다.
        9
        CPU 사용률에 cpu를 지정합니다.
        10
        AverageValue로 설정합니다.
        11
        대상 CPU 값을 사용하여 averageValue로 설정합니다.

      2. 수평 Pod 자동 스케일러를 생성합니다. 

        $ oc create -f <file-name>.yaml
        Copy to Clipboard Toggle word wrap

  2. 수평 Pod 자동 스케일러가 생성되었는지 확인합니다. 

    $ oc get hpa cpu-autoscale
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME            REFERENCE                       TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
cpu-autoscale   ReplicationController/example   173m/500m       1         10        1          20m
    Copy to Clipboard Toggle word wrap

기존 DeploymentConfig 또는 ReplicationController 오브젝트에 HPA(수평 Pod 자동 스케일러)를 생성하면 지정하는 평균 메모리 사용률(직접적인 값 또는 요청 메모리의 백분율)을 유지하도록 해당 오브젝트에 연결된 Pod를 자동으로 스케일링할 수 있습니다.

HPA는 최소 및 최대 개수 사이에서 복제본 수를 늘리거나 줄여 전체 Pod에서 지정된 메모리 사용률을 유지합니다.

메모리 사용률의 경우 최소 및 최대 Pod 수와 Pod에서 목표로 해야 하는 평균 메모리 사용률을 지정할 수 있습니다. 최솟값을 지정하지 않으면 Pod에 OpenShift Container Platform 서버의 기본값이 지정됩니다.

중요

메모리 사용률에 대한 자동 확장은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

사전 요구 사항

수평 Pod 자동 스케일러를 사용하려면 클러스터 관리자가 클러스터 메트릭을 올바르게 구성해야 합니다. oc describe PodMetrics <pod-name> 명령을 사용하여 메트릭이 구성되어 있는지 확인할 수 있습니다. 메트릭이 구성된 경우 출력이 다음과 유사하게 표시되고 Usage에 Cpu 및 Memory가 표시됩니다. 

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-129-223.compute.internal -n openshift-kube-scheduler
Copy to Clipboard Toggle word wrap

출력 예

Name:         openshift-kube-scheduler-ip-10-0-129-223.compute.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  scheduler
  Usage:
    Cpu:     2m
    Memory:  41056Ki
  Name:      wait-for-host-port
  Usage:
    Memory:  0
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2020-02-14T22:21:14Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-129-223.compute.internal
Timestamp:             2020-02-14T22:21:14Z
Window:                5m0s
Events:                <none>
Copy to Clipboard Toggle word wrap

프로세스

메모리 사용률에 대한 수평 Pod 자동 스케일러를 생성하려면 다음을 수행합니다.

  1. 다음 중 하나에 대한 YAML 파일을 생성합니다.

    • 특정 메모리 값을 스케일링하려면 기존 ReplicationController 오브젝트 또는 복제 컨트롤러에 대해 다음과 유사한 HorizontalPodAutoscaler 오브젝트를 생성합니다.

      출력 예

      apiVersion: autoscaling/v2beta2
      1 
      
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-memory
      2 
      
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: v1
      3 
      
    kind: ReplicationController
      4 
      
    name: example
      5 
      
  minReplicas: 1
      6 
      
  maxReplicas: 10
      7 
      
  metrics:
      8 
      
  - type: Resource
    resource:
      name: memory
      9 
      
      target:
        type: AverageValue
      10 
      
        averageValue: 500Mi
      11 
      
  behavior:
      12 
      
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60
      - type: Percent
        value: 10
        periodSeconds: 60
      selectPolicy: Max
      Copy to Clipboard Toggle word wrap

      1
      autoscaling/v2beta2 API를 사용합니다.
      2
      이 수평 Pod 자동 스케일러 오브젝트의 이름을 지정합니다.
      3
      스케일링할 오브젝트의 API 버전을 지정합니다.
      • 복제 컨트롤러의 경우 v1을 사용합니다.
      • DeploymentConfig 오브젝트의 경우 apps.openshift.io/v1을 사용합니다.
      4
      ReplicationController 또는 DeploymentConfig 중 스케일링할 오브젝트 유형을 지정합니다.
      5
      스케일링할 오브젝트의 이름을 지정합니다. 오브젝트가 있어야 합니다.
      6
      축소 시 최소 복제본 수를 지정합니다.
      7
      확장 시 최대 복제본 수를 지정합니다.
      8
      메모리 사용률에 metrics 매개변수를 사용합니다.
      9
      메모리 사용률에 대한 메모리를 지정합니다.
      10
      유형을 AverageValue로 설정합니다.
      11
      averageValue 및 특정 메모리 값을 지정합니다.
      12
      선택 사항: 확장 또는 축소 속도를 제어하려면 스케일링 정책을 지정합니다.

    • 백분율로 스케일링하려면 다음과 유사한 HorizontalPodAutoscaler 오브젝트를 생성합니다.

      출력 예

      apiVersion: autoscaling/v2beta2
      1 
      
kind: HorizontalPodAutoscaler
metadata:
  name: memory-autoscale
      2 
      
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps.openshift.io/v1
      3 
      
    kind: DeploymentConfig
      4 
      
    name: example
      5 
      
  minReplicas: 1
      6 
      
  maxReplicas: 10
      7 
      
  metrics:
      8 
      
  - type: Resource
    resource:
      name: memory
      9 
      
      target:
        type: Utilization
      10 
      
        averageUtilization: 50
      11 
      
  behavior:
      12 
      
    scaleUp:
      stabilizationWindowSeconds: 180
      policies:
      - type: Pods
        value: 6
        periodSeconds: 120
      - type: Percent
        value: 10
        periodSeconds: 120
      selectPolicy: Max
      Copy to Clipboard Toggle word wrap

      1
      autoscaling/v2beta2 API를 사용합니다.
      2
      이 수평 Pod 자동 스케일러 오브젝트의 이름을 지정합니다.
      3
      스케일링할 오브젝트의 API 버전을 지정합니다.
      • 복제 컨트롤러의 경우 v1을 사용합니다.
      • DeploymentConfig 오브젝트의 경우 apps.openshift.io/v1을 사용합니다.
      4
      ReplicationController 또는 DeploymentConfig 중 스케일링할 오브젝트 유형을 지정합니다.
      5
      스케일링할 오브젝트의 이름을 지정합니다. 오브젝트가 있어야 합니다.
      6
      축소 시 최소 복제본 수를 지정합니다.
      7
      확장 시 최대 복제본 수를 지정합니다.
      8
      메모리 사용률에 metrics 매개변수를 사용합니다.
      9
      메모리 사용률에 대한 메모리를 지정합니다.
      10
      Utilization으로 설정합니다.
      11
      averageUtilization 및 전체 Pod에 대한 대상 평균 메모리 사용률(요청 메모리의 백분율로 표시)을 지정합니다. 대상 Pod에 메모리 요청이 구성되어 있어야 합니다.
      12
      선택 사항: 확장 또는 축소 속도를 제어하려면 스케일링 정책을 지정합니다.

  2. 수평 Pod 자동 스케일러를 생성합니다. 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

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

    $ oc create -f hpa.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created
    Copy to Clipboard Toggle word wrap

  3. 수평 Pod 자동 스케일러가 생성되었는지 확인합니다. 

    $ oc get hpa hpa-resource-metrics-memory
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                          REFERENCE                       TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
hpa-resource-metrics-memory   ReplicationController/example   2441216/500Mi   1         10        1          20m
    Copy to Clipboard Toggle word wrap 

    $ oc describe hpa hpa-resource-metrics-memory
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:                        hpa-resource-metrics-memory
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
CreationTimestamp:           Wed, 04 Mar 2020 16:31:37 +0530
Reference:                   ReplicationController/example
Metrics:                     ( current / target )
  resource memory on pods:   2441216 / 500Mi
Min replicas:                1
Max replicas:                10
ReplicationController pods:  1 current / 1 desired
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:
  Type     Reason                   Age                 From                       Message
  ----     ------                   ----                ----                       -------
  Normal   SuccessfulRescale        6m34s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
    Copy to Clipboard Toggle word wrap

2.4.5. CLI를 사용하여 수평 Pod 자동 스케일러 상태 조건 이해
링크 복사

일련의 상태 조건을 사용하여 HPA(수평 Pod 자동 스케일러)에서 스케일링할 수 있는지 그리고 HPA가 현재 제한되어 있는지의 여부를 결정할 수 있습니다.

HPA 상태 조건은 Autoscaling API의 v2beta1 버전에서 사용할 수 있습니다.

HPA는 다음과 같은 상태 조건을 통해 응답합니다.

  • AbleToScale 상태는 HPA에서 메트릭을 가져오고 업데이트할 수 있는지의 여부 및 백오프 관련 상태로 스케일링을 방지할 수 있는지의 여부를 나타냅니다.

    • True 조건은 스케일링이 허용되었음을 나타냅니다.
    • False 조건은 지정된 이유로 스케일링이 허용되지 않음을 나타냅니다.

  • ScalingActive 조건은 HPA가 활성화되어 있고(예: 대상의 복제본 수가 0이 아님) 원하는 메트릭을 계산할 수 있는지의 여부를 나타냅니다.

    • True 조건은 메트릭이 제대로 작동함을 나타냅니다.
    • False 조건은 일반적으로 메트릭을 가져오는 데 문제가 있음을 나타냅니다.

  • ScalingLimited 조건은 원하는 스케일링이 수평 Pod 자동 스케일러의 최댓값 또는 최솟값으로 제한되었음을 나타냅니다.

    • True 조건은 스케일링을 위해 최소 또는 최대 복제본 수를 늘리거나 줄여야 함을 나타냅니다.

    • False 조건은 요청된 스케일링이 허용됨을 나타냅니다. 

      $ oc describe hpa cm-test
      Copy to Clipboard Toggle word wrap

      출력 예

      Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions:
      1 
      
  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Events:
      Copy to Clipboard Toggle word wrap

      1
      수평 Pod 자동 스케일러의 상태 메시지입니다.

다음은 스케일링할 수 없는 Pod의 예입니다.

출력 예

Conditions:
  Type         Status  Reason          Message
  ----         ------  ------          -------
  AbleToScale  False   FailedGetScale  the HPA controller was unable to get the target's current scale: no matches for kind "ReplicationController" in group "apps"
Events:
  Type     Reason          Age               From                       Message
  ----     ------          ----              ----                       -------
  Warning  FailedGetScale  6s (x3 over 36s)  horizontal-pod-autoscaler  no matches for kind "ReplicationController" in group "apps"
Copy to Clipboard Toggle word wrap

다음은 스케일링에 필요한 메트릭을 가져올 수 없는 Pod의 예입니다.

출력 예

Conditions:
  Type                  Status    Reason                    Message
  ----                  ------    ------                    -------
  AbleToScale           True     SucceededGetScale          the HPA controller was able to get the target's current scale
  ScalingActive         False    FailedGetResourceMetric    the HPA was unable to compute the replica count: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API
Copy to Clipboard Toggle word wrap

다음은 요청된 자동 스케일링이 필요한 최솟값보다 적은 Pod의 예입니다.

출력 예

Conditions:
  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Copy to Clipboard Toggle word wrap

2.4.5.1. CLI를 사용하여 수평 Pod 자동 스케일러 상태 조건 보기
링크 복사

HPA(수평 Pod 자동 스케일러)를 통해 Pod에 설정된 상태 조건을 볼 수 있습니다.

참고

수평 Pod 자동 스케일러 상태 조건은 v2beta1 버전의 Autoscaling API에서 사용할 수 있습니다.

사전 요구 사항

수평 Pod 자동 스케일러를 사용하려면 클러스터 관리자가 클러스터 메트릭을 올바르게 구성해야 합니다. oc describe PodMetrics <pod-name> 명령을 사용하여 메트릭이 구성되어 있는지 확인할 수 있습니다. 메트릭이 구성된 경우 출력이 다음과 유사하게 표시되고 Usage에 Cpu 및 Memory가 표시됩니다. 

$ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Copy to Clipboard Toggle word wrap

출력 예

Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  wait-for-host-port
  Usage:
    Memory:  0
  Name:      scheduler
  Usage:
    Cpu:     8m
    Memory:  45440Ki
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2019-05-23T18:47:56Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Timestamp:             2019-05-23T18:47:56Z
Window:                1m0s
Events:                <none>
Copy to Clipboard Toggle word wrap

프로세스

Pod의 상태 조건을 보려면 Pod 이름과 함께 다음 명령을 사용합니다. 

$ oc describe hpa <pod-name>
Copy to Clipboard Toggle word wrap

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

$ oc describe hpa cm-test
Copy to Clipboard Toggle word wrap

상태가 출력의 Conditions 필드에 나타납니다.

출력 예

Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions:
1 

  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Copy to Clipboard Toggle word wrap

2.5. 수직 Pod 자동 스케일러를 사용하여 Pod 리소스 수준 자동 조정
링크 복사

OpenShift Container Platform VPA(Vertical Pod Autoscaler Operator)는 Pod의 컨테이너에 대한 과거 및 현재의 CPU 및 메모리 리소스를 자동으로 검토한 후 확인한 사용량 값에 따라 리소스 제한 및 요청을 업데이트할 수 있습니다. VPA는 개별 CR(사용자 정의 리소스)을 사용하여 Deployment, Deployment Config, StatefulSet, Job, DaemonSet, ReplicaSet 또는 ReplicationController와 같은 워크로드 오브젝트와 연결된 모든 Pod를 프로젝트에서 업데이트합니다.

VPA를 사용하면 Pod의 최적 CPU 및 메모리 사용량을 이해하고 Pod의 라이프사이클 내내 Pod 리소스를 자동으로 유지 관리할 수 있습니다.

중요

수직 Pod 자동 스케일러는 기술 프리뷰 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

2.5.1. Vertical Pod Autoscaler Operator 정보
링크 복사

VPA(Vertical Pod Autoscaler Operator)는 API 리소스 및 CR(사용자 정의 리소스)로 구현됩니다. CR에 따라 Vertical Pod Autoscaler Operator에서 데몬 세트, 복제 컨트롤러 등과 같은 특정 워크로드 오브젝트와 관련된 Pod에서 수행해야 하는 작업이 프로젝트에서 결정됩니다.

VPA는 해당 Pod의 컨테이너 및 현재 CPU 및 메모리 사용량을 자동으로 계산하고, 이 데이터를 사용하여 최적화된 리소스 제한 및 요청을 확인하여 이러한 Pod가 항상 효율적으로 작동하는지 확인할 수 있습니다. 예를 들어 VPA에서 사용 중인 리소스보다 더 많은 리소스를 요청하는 Pod의 리소스를 줄이고 리소스를 충분히 요청하지 않는 Pod의 리소스를 늘립니다.

VPA는 애플리케이션이 다운 타임 없이 요청을 계속 제공할 수 있도록 권장 사항과 일치하지 않는 모든 Pod를 한 번에 하나씩 자동으로 삭제합니다. 그런 다음 워크로드 오브젝트는 원래 리소스 제한 및 요청을 사용하여 Pod를 재배포합니다. VPA는 변경 승인 Webhook를 사용하여 Pod가 노드에 승인되기 전에 최적화된 리소스 제한 및 요청을 사용하여 Pod를 업데이트합니다. VPA에서 Pod를 삭제하지 않으려면 필요에 따라 VPA 리소스 제한 및 요청 및 수동으로 Pod를 업데이트할 수 있습니다.

예를 들어 CPU의 50%를 사용하면서 10%만 요청하는 Pod가 있는 경우, VPA는 요청하는 것보다 더 많은 CPU를 사용하고 있는 것으로 판단하고 Pod를 삭제합니다. 복제본 세트와 같은 워크로드 오브젝트는 Pod를 재시작하고 VPA는 권장 리소스로 새 Pod를 업데이트합니다.

개발자의 경우 VPA를 사용하면 각 Pod에 적절한 리소스를 제공하도록 노드에 Pod를 예약하여 수요가 많은 기간에도 Pod가 유지되도록 할 수 있습니다.

관리자는 VPA를 사용하여 Pod에서 필요 이상의 CPU 리소스를 예약하지 않도록 클러스터 리소스를 더 효율적으로 활용할 수 있습니다. VPA는 워크로드에서 실제로 사용 중인 리소스를 모니터링하고 다른 워크로드에서 용량을 사용할 수 있도록 리소스 요구 사항을 조정합니다. 또한 VPA는 초기 컨테이너 구성에 지정된 제한 및 요청 간 비율도 유지합니다.

참고

VPA 실행을 중지하거나 클러스터에서 특정 VPA CR을 삭제하는 경우 VPA에서 이미 수정한 Pod에 대한 리소스 요청은 변경되지 않습니다. 새 Pod에서는 모두 VPA에서 설정한 이전의 권장 사항 대신 워크로드 오브젝트에 정의된 리소스를 가져옵니다.

2.5.2. Vertical Pod Autoscaler Operator 설치
링크 복사

OpenShift Container Platform 웹 콘솔을 사용하여 VPA(Vertical Pod Autoscaler Operator)를 설치할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
  2. 사용 가능한 Operator 목록에서 VerticalPodAutoscaler를 선택한 다음 설치를 클릭합니다.
  3. Operator 설치 페이지에서 Operator 권장 네임스페이스 옵션이 선택되어 있는지 확인합니다. 그러면 필수 openshift-vertical-pod-autoscaler 네임스페이스에 Operator가 설치됩니다. 해당 네임스페이스가 존재하지 않는 경우 자동으로 생성됩니다.
  4. 설치를 클릭합니다.

  5. VPA Operator 구성 요소를 나열하여 설치를 확인합니다.

    1. 워크로드 → Pod로 이동합니다.
    2. 드롭다운 메뉴에서 openshift-vertical-pod-autoscaler 프로젝트를 선택하고 Pod 4개가 실행되고 있는지 확인합니다.
    3. 워크로드 → 배포로 이동하여 배포 4개가 실행되고 있는지 확인합니다.

  6. 선택 사항: 다음 명령을 사용하여 OpenShift Container Platform CLI에서 설치를 확인합니다. 

    $ oc get all -n openshift-vertical-pod-autoscaler
    Copy to Clipboard Toggle word wrap

    출력에는 Pod 4개와 및 배포 4개가 표시됩니다.

    출력 예

    NAME                                                    READY   STATUS    RESTARTS   AGE
pod/vertical-pod-autoscaler-operator-85b4569c47-2gmhc   1/1     Running   0          3m13s
pod/vpa-admission-plugin-default-67644fc87f-xq7k9       1/1     Running   0          2m56s
pod/vpa-recommender-default-7c54764b59-8gckt            1/1     Running   0          2m56s
pod/vpa-updater-default-7f6cc87858-47vw9                1/1     Running   0          2m56s

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/vpa-webhook   ClusterIP   172.30.53.206   <none>        443/TCP   2m56s

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/vertical-pod-autoscaler-operator   1/1     1            1           3m13s
deployment.apps/vpa-admission-plugin-default       1/1     1            1           2m56s
deployment.apps/vpa-recommender-default            1/1     1            1           2m56s
deployment.apps/vpa-updater-default                1/1     1            1           2m56s

NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/vertical-pod-autoscaler-operator-85b4569c47   1         1         1       3m13s
replicaset.apps/vpa-admission-plugin-default-67644fc87f       1         1         1       2m56s
replicaset.apps/vpa-recommender-default-7c54764b59            1         1         1       2m56s
replicaset.apps/vpa-updater-default-7f6cc87858                1         1         1       2m56s
    Copy to Clipboard Toggle word wrap

2.5.3. Vertical Pod Autoscaler Operator 사용 정보
링크 복사

VPA(Vertical Pod Autoscaler Operator)를 사용하려면 클러스터에서 워크로드 오브젝트에 대한 VPA CR(사용자 정의 리소스)을 생성합니다. VPA는 해당 워크로드 오브젝트와 연결된 Pod에 가장 적합한 CPU 및 메모리 리소스를 확인하고 적용합니다. 배포, 상태 저장 세트, 작업, 데몬 세트, 복제본 세트 또는 복제 컨트롤러 워크로드 오브젝트에 VPA를 사용할 수 있습니다. VPA CR은 모니터링할 Pod와 동일한 프로젝트에 있어야 합니다.

VPA CR을 사용하여 워크로드 오브젝트를 연결하고 VPA가 작동하는 모드를 지정합니다.

  • Auto 및 Recreate 모드는 Pod 수명 동안 VPA CPU 및 메모리 권장 사항을 자동으로 적용합니다. VPA는 권장 사항과 일치하지 않는 프로젝트의 모든 Pod를 삭제합니다. 워크로드 오브젝트에서 재배포하면 VPA는 새 Pod를 권장 사항으로 업데이트합니다.
  • Initial 모드는 Pod 생성 시에만 VPA 권장 사항을 자동으로 적용합니다.
  • Off 모드는 권장되는 리소스 제한 및 요청만 제공하며 권장 사항을 수동으로 적용할 수 있습니다. off 모드에서는 Pod를 업데이트하지 않습니다.

CR을 사용하여 VPA 평가 및 업데이트에서 특정 컨테이너를 옵트아웃할 수도 있습니다.

예를 들어 Pod에 다음과 같은 제한 및 요청이 있습니다. 

resources:
  limits:
    cpu: 1
    memory: 500Mi
  requests:
    cpu: 500m
    memory: 100Mi
Copy to Clipboard Toggle word wrap

auto로 설정된 VPA를 생성하면 VPA에서 리소스 사용량을 확인하고 Pod를 삭제합니다. 재배포되면 Pod는 새 리소스 제한 및 요청을 사용합니다. 

resources:
  limits:
    cpu: 50m
    memory: 1250Mi
  requests:
    cpu: 25m
    memory: 262144k
Copy to Clipboard Toggle word wrap

다음 명령을 사용하여 VPA 권장 사항을 볼 수 있습니다. 

$ oc get vpa <vpa-name> --output yaml
Copy to Clipboard Toggle word wrap

몇 분 후 출력에는 CPU 및 메모리 요청에 대한 권장 사항이 표시되며 다음과 유사합니다.

출력 예

...
status:
...
  recommendation:
    containerRecommendations:
    - containerName: frontend
      lowerBound:
        cpu: 25m
        memory: 262144k
      target:
        cpu: 25m
        memory: 262144k
      uncappedTarget:
        cpu: 25m
        memory: 262144k
      upperBound:
        cpu: 262m
        memory: "274357142"
    - containerName: backend
      lowerBound:
        cpu: 12m
        memory: 131072k
      target:
        cpu: 12m
        memory: 131072k
      uncappedTarget:
        cpu: 12m
        memory: 131072k
      upperBound:
        cpu: 476m
        memory: "498558823"
...
Copy to Clipboard Toggle word wrap

출력에는 권장 리소스(target), 최소 권장 리소스(lowerBound), 최고 권장 리소스(upperBound), 최신 리소스 권장 사항(uncappedTarget)이 표시됩니다.

VPA는 lowerBound 및 upperBound 값을 사용하여 Pod를 업데이트해야 하는지 확인합니다. Pod에 lowerBound 값보다 작거나 upperBound 값을 초과하는 리소스 요청이 있는 경우 VPA는 Pod를 종료하고 target 값을 사용하여 Pod를 다시 생성합니다.

2.5.3.1. VPA 권장 사항 자동 적용
링크 복사

VPA를 사용하여 Pod를 자동으로 업데이트하려면 updateMode를 Auto 또는 Recreate로 설정하여 특정 워크로드 오브젝트에 대한 VPA CR을 생성합니다.

워크로드 오브젝트에 대한 Pod가 생성되면 VPA에서 컨테이너를 지속적으로 모니터링하여 CPU 및 메모리 요구 사항을 분석합니다. VPA는 CPU 및 메모리에 대한 VPA 권장 사항을 충족하지 않는 모든 Pod를 삭제합니다. 재배포되면 Pod는 VPA 권장 사항에 따라 새 리소스 제한 및 요청을 사용하여 애플리케이션에 대해 설정된 모든 Pod 중단 예산을 준수합니다. 권장 사항은 참조를 위해 VPA CR의 status 필드에 추가되어 있습니다.

참고

워크로드 오브젝트에서 Pod를 모니터링하고 업데이트하려면 최소 두 개의 복제본을 지정해야 합니다. 워크로드 오브젝트에서 하나의 복제본을 지정하면 VPA에서 애플리케이션 다운타임을 방지하기 위해 Pod를 삭제하지 않습니다. 권장 리소스를 사용하도록 Pod를 수동으로 삭제할 수 있습니다.

Auto 모드 VPA CR의 예

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
1 

    name:       frontend
2 

  updatePolicy:
    updateMode: "Auto"
3
Copy to Clipboard Toggle word wrap

1 1
이 VPA CR에서 관리할 워크로드 오브젝트의 유형입니다.
2
이 VPA CR에서 관리할 워크로드 오브젝트의 이름입니다.
3
모드를 Auto 또는 Recreate로 설정합니다.
  • Auto. VPA는 Pod 생성 시 리소스 요청을 할당하고 요청된 리소스가 새 권장 사항과 크게 다른 경우 기존 Pod를 종료하여 업데이트합니다.
  • Recreate. VPA는 Pod 생성 시 리소스 요청을 할당하고 요청된 리소스가 새 권장 사항과 크게 다른 경우 기존 Pod를 종료하여 업데이트합니다. 이 모드는 리소스 요청이 변경될 때마다 Pod를 재시작해야 하는 경우에만 사용해야 합니다.
참고

VPA에서 권장 리소스를 결정하고 권장 사항을 새 Pod에 적용하려면 프로젝트에 작동 중인 Pod가 있어야 합니다.

2.5.3.2. Pod 생성에 VPA 권장 사항 자동 적용
링크 복사

VPA를 사용하여 Pod를 처음 배포할 때만 권장 리소스를 적용하려면 updateMode를 Initial로 설정하여 특정 워크로드 오브젝트에 대한 VPA CR을 생성합니다.

그런 다음 VPA 권장 사항을 사용하려는 워크로드 오브젝트와 연결된 모든 Pod를 수동으로 삭제합니다. Initial 모드에서 VPA는 새 리소스 권장 사항을 확인할 때 Pod를 삭제하지 않고 Pod을 업데이트하지도 않습니다.

Initial 모드 VPA CR의 예

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
1 

    name:       frontend
2 

  updatePolicy:
    updateMode: "Initial"
3
Copy to Clipboard Toggle word wrap

1
이 VPA CR에서 관리할 워크로드 오브젝트의 유형입니다.
2
이 VPA CR에서 관리할 워크로드 오브젝트의 이름입니다.
3
모드를 Initial로 설정합니다. Pod가 생성되면 VPA에서 리소스를 할당하고 Pod 수명 동안 리소스를 변경하지 않습니다.
참고

VPA에서 권장 리소스를 결정하고 권장 사항을 새 Pod에 적용하려면 프로젝트에 작동 중인 Pod가 있어야 합니다.

2.5.3.3. VPA 권장 사항 수동 적용
링크 복사

VPA를 권장 CPU 및 메모리 값을 확인하는 데에만 사용하려면 updateMode를 off로 설정하여 특정 워크로드 오브젝트에 대한 VPA CR을 생성합니다.

해당 워크로드 오브젝트에 대한 Pod가 생성되면 VPA는 컨테이너의 CPU 및 메모리 요구 사항을 분석하고 VPA CR의 status 필드에 해당 권장 사항을 기록합니다. VPA는 새 리소스 권장 사항을 확인할 때 Pod를 업데이트하지 않습니다.

Off 모드 VPA CR의 예

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
1 

    name:       frontend
2 

  updatePolicy:
    updateMode: "Off"
3
Copy to Clipboard Toggle word wrap

1
이 VPA CR에서 관리할 워크로드 오브젝트의 유형입니다.
2
이 VPA CR에서 관리할 워크로드 오브젝트의 이름입니다.
3
모드를 Off로 설정합니다.

다음 명령을 사용하여 권장 사항을 볼 수 있습니다. 

$ oc get vpa <vpa-name> --output yaml
Copy to Clipboard Toggle word wrap

권장 사항에 따라 워크로드 오브젝트를 편집하여 CPU 및 메모리 요청을 추가한 다음 권장 리소스를 사용하여 Pod를 삭제하고 재배포할 수 있습니다.

참고

VPA에서 권장 리소스를 결정하려면 프로젝트에 작동 중인 Pod가 있어야 합니다.

2.5.3.4. VPA 권장 사항 적용에서 컨테이너 제외
링크 복사

워크로드 오브젝트에 컨테이너가 여러 개 있고 VPA에서 모든 컨테이너를 평가하고 해당 컨테이너에 대해 작동하지 않도록 하려면 특정 워크로드 오브젝트에 대한 VPA CR을 생성하고 resourcePolicy를 추가하여 특정 컨테이너를 옵트아웃합니다.

VPA에서 권장 리소스를 사용하여 Pod를 업데이트하면 resourcePolicy가 포함된 모든 컨테이너가 업데이트되지 않으며 VPA는 Pod의 해당 컨테이너에 대한 권장 사항을 제공하지 않습니다. 

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
1 

    name:       frontend
2 

  updatePolicy:
    updateMode: "Auto"
3 

  resourcePolicy:
4 

    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"
Copy to Clipboard Toggle word wrap
1
이 VPA CR에서 관리할 워크로드 오브젝트의 유형입니다.
2
이 VPA CR에서 관리할 워크로드 오브젝트의 이름입니다.
3
모드를 Auto, Recreate 또는 Off로 설정합니다. Recreate 모드는 리소스 요청이 변경될 때마다 Pod를 재시작해야 하는 경우에만 사용해야 합니다.
4
옵트아웃할 컨테이너를 지정하고 mode를 Off로 설정합니다.

예를 들면 Pod에 다음과 같이 리소스 요청 및 제한이 동일한 두 개의 컨테이너가 있습니다. 

# ...
spec:
  containers:
  - name: frontend
    resources:
      limits:
        cpu: 1
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
  - name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
# ...
Copy to Clipboard Toggle word wrap

backend 컨테이너를 옵트아웃으로 설정하여 VPA CR을 시작하면 VPA에서 Pod를 종료한 후 frontend 컨테이너에만 적용되는 권장 리소스를 사용하여 Pod를 다시 생성합니다. 

...
spec:
  containers:
    name: frontend
    resources:
      limits:
        cpu: 50m
        memory: 1250Mi
      requests:
        cpu: 25m
        memory: 262144k
...
    name: backend
    resources:
      limits:
        cpu: "1"
        memory: 500Mi
      requests:
        cpu: 500m
        memory: 100Mi
...
Copy to Clipboard Toggle word wrap

2.5.4. Vertical Pod Autoscaler Operator 사용
링크 복사

VPA(Vertical Pod Autoscaler Operator) CR(사용자 정의 리소스)을 생성하여 VPA를 사용할 수 있습니다. CR은 VPA에서 해당 Pod에 수행할 작업을 분석하고 결정해야 하는 Pod를 나타냅니다.

프로세스

특정 워크로드 오브젝트에 대한 VPA CR을 생성하려면 다음을 수행합니다.

  1. 스케일링할 워크로드 오브젝트가 있는 프로젝트로 변경합니다.

    1. VPA CR YAML 파일을 생성합니다. 

      apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: vpa-recommender
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
      1 
      
    name:       frontend
      2 
      
  updatePolicy:
    updateMode: "Auto"
      3 
      
  resourcePolicy:
      4 
      
    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"
      Copy to Clipboard Toggle word wrap
      1
      이 VPA에서 관리할 워크로드 오브젝트 유형을 지정합니다. Deployment,StatefulSet,Job,DaemonSet,ReplicaSet 또는 ReplicationController.
      2
      이 VPA에서 관리할 기존 워크로드 오브젝트의 이름을 지정합니다.
      3
      다음과 같이 VPA 모드를 지정합니다.
      • auto: 컨트롤러와 연결된 Pod에 권장 리소스를 자동으로 적용합니다. VPA는 기존 Pod를 종료하고 권장 리소스 제한 및 요청을 사용하여 새 Pod를 생성합니다.
      • recreate: 워크로드 오브젝트와 연결된 Pod에 권장 리소스를 자동으로 적용합니다. VPA는 기존 Pod를 종료하고 권장 리소스 제한 및 요청을 사용하여 새 Pod를 생성합니다. recreate 모드는 리소스 요청이 변경될 때마다 Pod를 재시작해야 하는 경우에만 사용해야 합니다.
      • initial: 워크로드 오브젝트와 연결된 Pod가 생성될 때 권장 리소스를 자동으로 적용합니다. VPA는 새 리소스 권장 사항을 확인할 때 Pod를 업데이트하지 않습니다.
      • off: 워크로드 오브젝트와 연결된 Pod의 리소스 권장 사항만 생성합니다. VPA는 새 리소스 권장 사항을 확인할 때 Pod를 업데이트하지 않고 해당 권장 사항을 새 Pod에 적용하지도 않습니다.
      4
      선택 사항입니다. 옵트아웃할 컨테이너를 지정하고 모드를 Off로 설정합니다.

    2. VPA CR을 생성합니다. 

      $ oc create -f <file-name>.yaml
      Copy to Clipboard Toggle word wrap

      잠시 후 VPA는 워크로드 오브젝트와 연결된 Pod에서 컨테이너의 리소스 사용량을 확인합니다.

      다음 명령을 사용하여 VPA 권장 사항을 볼 수 있습니다. 

      $ oc get vpa <vpa-name> --output yaml
      Copy to Clipboard Toggle word wrap

      출력에는 CPU 및 메모리 요청에 대한 권장 사항이 표시되며 다음과 유사합니다.

      출력 예

      ...
status:

...

  recommendation:
    containerRecommendations:
    - containerName: frontend
      lowerBound:
      1 
      
        cpu: 25m
        memory: 262144k
      target:
      2 
      
        cpu: 25m
        memory: 262144k
      uncappedTarget:
      3 
      
        cpu: 25m
        memory: 262144k
      upperBound:
      4 
      
        cpu: 262m
        memory: "274357142"
    - containerName: backend
      lowerBound:
        cpu: 12m
        memory: 131072k
      target:
        cpu: 12m
        memory: 131072k
      uncappedTarget:
        cpu: 12m
        memory: 131072k
      upperBound:
        cpu: 476m
        memory: "498558823"

...
      Copy to Clipboard Toggle word wrap

      1
      lowerBound는 최소 권장 리소스 수준은 입니다.
      2
      target은 권장 리소스 수준입니다.
      3
      upperBound는 권장되는 최고 리소스 수준입니다.
      4
      uncappedTarget은 최신 리소스 권장 사항입니다.

2.5.5. Vertical Pod Autoscaler Operator 설치 제거
링크 복사

OpenShift Container Platform 클러스터에서 VPA(Vertical Pod Autoscaler Operator)를 제거할 수 있습니다. 설치 제거해도 기존 VPA CR에 의해 이미 수정된 Pod의 리소스 요청은 변경되지 않습니다. 새 Pod에서는 모두 Vertical Pod Autoscaler Operator에서 설정한 권장 사항 대신 워크로드 오브젝트에 정의된 리소스를 가져옵니다.

참고

oc delete vpa <vpa-name> 명령을 사용하여 특정 VPA를 제거할 수 있습니다. 리소스 요청에는 수직 Pod 자동 스케일러를 설치 제거할 때와 동일한 작업이 적용됩니다.

VPA Operator를 제거한 후 잠재적인 문제를 방지하려면 Operator와 연결된 다른 구성 요소를 제거하는 것이 좋습니다.

사전 요구 사항

  • Vertical Pod Autoscaler Operator를 설치해야 합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator를 클릭합니다.
  2. openshift-vertical-pod-autoscaler 프로젝트로 전환합니다.
  3. VerticalPodAutoscaler Operator를 찾아 옵션 메뉴를 클릭합니다. Operator 설치 제거를 선택합니다.
  4. 대화 상자에서 설치 제거를 클릭합니다.
  5. 선택 사항: Operator와 연결된 모든 피연산자를 제거하려면 대화 상자에서 이 연산자의 모든 피연산자 인스턴스 삭제를 선택합니다.
  6. 제거를 클릭합니다.

  7. 선택 사항: OpenShift CLI를 사용하여 VPA 구성 요소를 제거합니다.

    1. VPA 변경 Webhook 구성을 삭제합니다. 

      $ oc delete mutatingwebhookconfigurations/vpa-webhook-config
      Copy to Clipboard Toggle word wrap

    2. 모든 VPA 사용자 정의 리소스를 나열합니다. 

      $ oc get verticalpodautoscalercheckpoints.autoscaling.k8s.io,verticalpodautoscalercontrollers.autoscaling.openshift.io,verticalpodautoscalers.autoscaling.k8s.io -o wide --all-namespaces
      Copy to Clipboard Toggle word wrap

      출력 예

      NAMESPACE      NAME                                                                       AGE
my-project     verticalpodautoscalercheckpoint.autoscaling.k8s.io/vpa-recommender-httpd   5m46s

NAMESPACE                           NAME                                                               AGE
openshift-vertical-pod-autoscaler   verticalpodautoscalercontroller.autoscaling.openshift.io/default   11m

NAMESPACE      NAME                                                       MODE   CPU   MEM       PROVIDED   AGE
my-project     verticalpodautoscaler.autoscaling.k8s.io/vpa-recommender   Auto   93m   262144k   True       9m15s
      Copy to Clipboard Toggle word wrap

    3. 나열된 VPA 사용자 정의 리소스를 삭제합니다. 예를 들면 다음과 같습니다. 

      $ oc delete verticalpodautoscalercheckpoint.autoscaling.k8s.io/vpa-recommender-httpd -n my-project
      Copy to Clipboard Toggle word wrap 
      $ oc delete verticalpodautoscalercontroller.autoscaling.openshift.io/default -n openshift-vertical-pod-autoscaler
      Copy to Clipboard Toggle word wrap 
      $ oc delete verticalpodautoscaler.autoscaling.k8s.io/vpa-recommender -n my-project
      Copy to Clipboard Toggle word wrap

    4. VPA CRD(사용자 정의 리소스 정의)를 나열합니다. 

      $ oc get crd
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                                              CREATED AT
 ...
verticalpodautoscalercheckpoints.autoscaling.k8s.io               2022-02-07T14:09:20Z
verticalpodautoscalercontrollers.autoscaling.openshift.io         2022-02-07T14:09:20Z
verticalpodautoscalers.autoscaling.k8s.io                         2022-02-07T14:09:20Z
 ...
      Copy to Clipboard Toggle word wrap

    5. 나열된 VPA CRD를 삭제합니다. 

      $ oc delete crd verticalpodautoscalercheckpoints.autoscaling.k8s.io verticalpodautoscalercontrollers.autoscaling.openshift.io verticalpodautoscalers.autoscaling.k8s.io
      Copy to Clipboard Toggle word wrap

      CRD를 삭제하면 관련 역할, 클러스터 역할, 역할 바인딩이 제거됩니다. 그러나 수동으로 삭제해야 하는 몇 가지 클러스터 역할이 있을 수 있습니다.

    6. 모든 VPA 클러스터 역할을 나열합니다. 

      $ oc get clusterrole | grep openshift-vertical-pod-autoscaler
      Copy to Clipboard Toggle word wrap

      출력 예

      openshift-vertical-pod-autoscaler-6896f-admin        2022-02-02T15:29:55Z
openshift-vertical-pod-autoscaler-6896f-edit         2022-02-02T15:29:55Z
openshift-vertical-pod-autoscaler-6896f-view         2022-02-02T15:29:55Z
      Copy to Clipboard Toggle word wrap

    7. 나열된 VPA 클러스터 역할을 삭제합니다. 예를 들면 다음과 같습니다. 

      $ oc delete clusterrole openshift-vertical-pod-autoscaler-6896f-admin openshift-vertical-pod-autoscaler-6896f-edit openshift-vertical-pod-autoscaler-6896f-view
      Copy to Clipboard Toggle word wrap

    8. VPA Operator를 삭제합니다. 

      $ oc delete operator/vertical-pod-autoscaler.openshift-vertical-pod-autoscaler
      Copy to Clipboard Toggle word wrap

2.6. Pod에 민감한 데이터 제공
링크 복사

일부 애플리케이션에는 개발자에게 제공하길 원하지 않는 민감한 정보(암호 및 사용자 이름 등)가 필요합니다.

관리자는 Secret 오브젝트를 사용하여 이러한 정보를 명확한 텍스트로 공개하지 않고도 제공할 수 있습니다.

2.6.1. 보안 이해
링크 복사

Secret 오브젝트 유형에서는 암호, OpenShift Container Platform 클라이언트 구성 파일, 개인 소스 리포지토리 자격 증명 등과 같은 중요한 정보를 보유하는 메커니즘을 제공합니다. 보안은 Pod에서 중요한 콘텐츠를 분리합니다. 볼륨 플러그인을 사용하여 컨테이너에 보안을 마운트하거나 시스템에서 보안을 사용하여 Pod 대신 조치를 수행할 수 있습니다.

주요 속성은 다음과 같습니다.

  • 보안 데이터는 정의와는 별도로 참조할 수 있습니다.
  • 보안 데이터 볼륨은 임시 파일 저장 기능(tmpfs)에 의해 지원되며 노드에 저장되지 않습니다.
  • 보안 데이터는 네임스페이스 내에서 공유할 수 있습니다.

YAML Secret 오브젝트 정의

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque
1 

data:
2 

  username: dmFsdWUtMQ0K
3 

  password: dmFsdWUtMg0KDQo=
stringData:
4 

  hostname: myapp.mydomain.com
5
Copy to Clipboard Toggle word wrap

1
보안의 키 이름과 값의 구조를 나타냅니다.
2
data 필드에서 허용되는 키 형식은 Kubernetes 구분자 용어집의 DNS_SUBDOMAIN 값에 있는 지침을 충족해야 합니다.
3
data 맵의 키와 관련된 값은 base64로 인코딩되어야 합니다.
4
stringData 맵의 항목이 base64로 변환된 후 해당 항목이 자동으로 data 맵으로 이동합니다. 이 필드는 쓰기 전용이며 값은 data 필드를 통해서만 반환됩니다.
5
stringData 맵의 키와 관련된 값은 일반 텍스트 문자열로 구성됩니다.

먼저 보안을 생성한 후 해당 보안을 사용하는 Pod를 생성해야 합니다.

보안 생성 시 다음을 수행합니다.

  • 보안 데이터를 사용하여 보안 오브젝트를 생성합니다.
  • Pod 서비스 계정을 업데이트하여 보안에 대한 참조를 허용합니다.
  • 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.
2.6.1.1. 보안 유형
링크 복사

type 필드의 값은 보안의 키 이름과 값의 구조를 나타냅니다. 유형을 사용하면 보안 오브젝트에 사용자 이름과 키를 적용할 수 있습니다. 검증을 수행하지 않으려면 기본값인 opaque 유형을 사용합니다.

보안 데이터에 특정 키 이름이 있는지 확인하기 위해 서버 측 최소 검증을 트리거하려면 다음 유형 중 하나를 지정합니다.

  • kubernetes.io/service-account-token. 서비스 계정 토큰을 사용합니다.
  • kubernetes.io/basic-auth. 기본 인증에 사용합니다.
  • kubernetes.io/ssh-auth. SSH 키 인증에 사용합니다.
  • kubernetes.io/tls. TLS 인증 기관에 사용합니다.

유형을 지정합니다. opaque 검증을 수행하지 않으려면 시크릿에서 키 이름 또는 값에 대한 규칙을 준수하도록 요청하지 않습니다. opaque 보안에는 임의의 값을 포함할 수 있는 비정형 key:value 쌍을 사용할 수 있습니다.

참고

example.com/my-secret-type과 같은 다른 임의의 유형을 지정할 수 있습니다. 이러한 유형은 서버 측에 적용되지 않지만 보안 생성자가 해당 유형의 키/값 요구 사항을 준수하도록 의도했음을 나타냅니다.

다양한 시크릿 유형의 예는 보안 사용의 코드 샘플을 참조하십시오.

2.6.1.2. 보안 데이터 키
링크 복사

보안키는 DNS 하위 도메인에 있어야 합니다.

2.6.2. 보안 생성 방법 이해
링크 복사

관리자는 개발자가 해당 보안을 사용하는 Pod를 생성하기 전에 보안을 생성해야 합니다.

보안 생성 시 다음을 수행합니다.

  1. 시크릿을 유지하려는 데이터가 포함된 보안 오브젝트를 생성합니다. 각 시크릿 유형에 필요한 특정 데이터는 다음 섹션에서 확인할 수 있습니다.

    불투명 보안을 생성하는 YAML 오브젝트의 예

    apiVersion: v1
kind: Secret
metadata:
  name: test-secret
type: Opaque
    1 
    
data:
    2 
    
  username: dmFsdWUtMQ0K
  password: dmFsdWUtMQ0KDQo=
stringData:
    3 
    
  hostname: myapp.mydomain.com
  secret.properties: |
    property1=valueA
    property2=valueB
    Copy to Clipboard Toggle word wrap

    1
    보안 유형을 지정합니다.
    2
    인코딩된 문자열 및 데이터를 지정합니다.
    3
    디코딩된 문자열 및 데이터를 지정합니다.

    둘 다 아닌 data 또는 stringdata 필드를 사용합니다.

  2. Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.

    보안을 사용하는 서비스 계정의 YAML

    apiVersion: v1
kind: ServiceAccount
 ...
secrets:
- name: test-secret
    Copy to Clipboard Toggle word wrap

  3. 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.

    보안 데이터로 볼륨의 파일을 채우는 Pod의 YAML

    apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts:
    1 
    
          - name: secret-volume
            mountPath: /etc/secret-volume
    2 
    
            readOnly: true
    3 
    
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret
    4 
    
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap

    1
    보안이 필요한 각 컨테이너에 volumeMounts 필드를 추가합니다.
    2
    보안을 표시할 미사용 디렉터리 이름을 지정합니다. 시크릿 데이터 맵의 각 키는 mountPath 아래의 파일 이름이 됩니다.
    3
    true 로 설정합니다. true인 경우 드라이버에 읽기 전용 볼륨을 제공하도록 지시합니다.
    4
    시크릿 이름을 지정합니다.

    보안 데이터로 환경 변수를 채우는 Pod의 YAML

    apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef:
    1 
    
              name: test-secret
              key: username
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap

    1
    secret 키를 사용하는 환경 변수를 지정합니다.

    보안 데이터로 환경 변수를 채우는 빌드 구성의 YAML

    apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef:
    1 
    
            name: test-secret
            key: username
    Copy to Clipboard Toggle word wrap

    1
    secret 키를 사용하는 환경 변수를 지정합니다.
2.6.2.1. 보안 생성 제한 사항
링크 복사

보안을 사용하려면 Pod에서 보안을 참조해야 합니다. 보안은 다음 세 가지 방법으로 Pod에서 사용할 수 있습니다.

  • 컨테이너에 환경 변수를 채우기 위해 사용.
  • 하나 이상의 컨테이너에 마운트된 볼륨에서 파일로 사용.
  • Pod에 대한 이미지를 가져올 때 kubelet으로 사용.

볼륨 유형 보안은 볼륨 메커니즘을 사용하여 데이터를 컨테이너에 파일로 작성합니다. 이미지 가져오기 보안은 서비스 계정을 사용하여 네임스페이스의 모든 Pod에 보안을 자동으로 삽입합니다.

템플릿에 보안 정의가 포함된 경우 템플릿에 제공된 보안을 사용할 수 있는 유일한 방법은 보안 볼륨 소스를 검증하고 지정된 오브젝트 참조가 Secret 오브젝트를 실제로 가리키는 것입니다. 따라서 보안을 생성한 후 해당 보안을 사용하는 Pod를 생성해야 합니다. 가장 효과적인 방법은 서비스 계정을 사용하여 자동으로 삽입되도록 하는 것입니다.

Secret API 오브젝트는 네임스페이스에 있습니다. 동일한 네임스페이스에 있는 Pod만 참조할 수 있습니다.

개별 보안은 1MB로 제한됩니다. 이는 대규모 보안이 생성되어 apiserver 및 kubelet 메모리가 소모되는 것을 막기 위한 것입니다. 그러나 작은 보안을 많이 생성해도 메모리가 소모될 수 있습니다.

2.6.2.2. 불투명 보안 생성
링크 복사

관리자는 임의의 값을 포함할 수 있는 비정형 key:value 쌍을 저장할 수 있는 불투명 보안을 생성할 수 있습니다.

프로세스

  1. 컨트롤 플레인 노드의 YAML 파일에 Secret 오브젝트를 생성합니다.

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

    apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
    1 
    
data:
  username: dXNlci1uYW1l
  password: cGFzc3dvcmQ=
    Copy to Clipboard Toggle word wrap
    1
    불투명 보안을 지정합니다.

  2. 다음 명령을 사용하여 Secret 오브젝트를 생성합니다. 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  3. Pod에서 보안을 사용하려면 다음을 수행합니다.

    1. "보안 생성 방법" 섹션에 표시된 대로 Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.
    2. "secret을 보안 생성 방법" 섹션에 설명된 대로 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.
2.6.2.3. 서비스 계정 토큰 시크릿 생성
링크 복사

관리자는 API에 인증해야 하는 애플리케이션에 서비스 계정 토큰을 배포할 수 있는 서비스 계정 토큰 시크릿을 생성할 수 있습니다.

참고

서비스 계정 토큰 시크릿을 사용하는 대신 TokenRequest API를 사용하여 바인딩된 서비스 계정 토큰을 얻는 것이 좋습니다. TokenRequest API에서 얻은 토큰은 바인딩된 수명을 가지며 다른 API 클라이언트에서 읽을 수 없기 때문에 시크릿에 저장된 토큰보다 더 안전합니다.

TokenRequest API를 사용할 수 없고 읽을 수 없는 API 오브젝트에서의 보안 노출이 허용 가능한 경우에만 서비스 계정 토큰 시크릿을 생성해야 합니다.

바인딩된 서비스 계정 토큰 생성에 대한 정보는 다음 추가 리소스 섹션을 참조하십시오.

절차

  1. 컨트롤 플레인 노드의 YAML 파일에 Secret 오브젝트를 생성합니다.

    보안 오브젝트 의 예:

    apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name"
    1 
    
type: kubernetes.io/service-account-token
    2
    Copy to Clipboard Toggle word wrap

    1
    기존 서비스 계정 이름을 지정합니다. ServiceAccount 및 Secret 오브젝트를 모두 생성하는 경우 ServiceAccount 오브젝트를 먼저 생성합니다.
    2
    서비스 계정 토큰 보안을 지정합니다.

  2. 다음 명령을 사용하여 Secret 오브젝트를 생성합니다. 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  3. Pod에서 보안을 사용하려면 다음을 수행합니다.

    1. "보안 생성 방법" 섹션에 표시된 대로 Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.
    2. "secret을 보안 생성 방법" 섹션에 설명된 대로 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.
2.6.2.4. 기본 인증 보안 생성
링크 복사

관리자는 기본 인증에 필요한 자격 증명을 저장할 수 있는 기본 인증 보안을 생성할 수 있습니다. 이 시크릿 유형을 사용하는 경우 Secret 오브젝트의 data 매개변수에 base64 형식으로 인코딩된 다음 키가 포함되어야 합니다.

  • Username: 인증을 위한 사용자 이름
  • password: 인증이 필요한 암호 또는 토큰
참고

stringData 매개변수를 사용하여 일반 텍스트 콘텐츠를 사용할 수 있습니다.

절차

  1. 컨트롤 플레인 노드의 YAML 파일에 Secret 오브젝트를 생성합니다.

    보안 오브젝트 의 예

    apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth
    1 
    
data:
stringData:
    2 
    
  username: admin
  password: t0p-Secret
    Copy to Clipboard Toggle word wrap

    1
    기본 인증 보안을 지정합니다.
    2
    사용할 기본 인증 값을 지정합니다.

  2. 다음 명령을 사용하여 Secret 오브젝트를 생성합니다. 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  3. Pod에서 보안을 사용하려면 다음을 수행합니다.

    1. "보안 생성 방법" 섹션에 표시된 대로 Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.
    2. "secret을 보안 생성 방법" 섹션에 설명된 대로 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.
2.6.2.5. SSH 인증 보안 생성
링크 복사

관리자는 SSH 인증에 사용되는 데이터를 저장할 수 있는 SSH 인증 시크릿을 생성할 수 있습니다. 이 시크릿 유형을 사용하는 경우 Secret 오브젝트의 data 매개변수에 사용할 SSH 자격 증명이 포함되어야 합니다.

절차

  1. 컨트롤 플레인 노드의 YAML 파일에 Secret 오브젝트를 생성합니다.

    보안 오브젝트 의 예:

    apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth
    1 
    
data:
  ssh-privatekey: |
    2 
    
          MIIEpQIBAAKCAQEAulqb/Y ...
    Copy to Clipboard Toggle word wrap

    1
    SSH 인증 보안을 지정합니다.
    2
    SSH 키/값 쌍을 사용할 SSH 자격 증명으로 지정합니다.

  2. 다음 명령을 사용하여 Secret 오브젝트를 생성합니다. 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  3. Pod에서 보안을 사용하려면 다음을 수행합니다.

    1. "보안 생성 방법" 섹션에 표시된 대로 Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.
    2. "secret을 보안 생성 방법" 섹션에 설명된 대로 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.
2.6.2.6. Docker 구성 보안 생성
링크 복사

관리자는 컨테이너 이미지 레지스트리에 액세스하기 위한 인증 정보를 저장할 수 있는 Docker 구성 시크릿을 생성할 수 있습니다.

  • kubernetes.io/dockercfg. 이 시크릿 유형을 사용하여 로컬 Docker 구성 파일을 저장합니다. secret 오브젝트의 data 매개변수에 base64 형식으로 인코딩된 .dockercfg 파일의 콘텐츠가 포함되어야 합니다.
  • kubernetes.io/dockerconfigjson. 이 시크릿 유형을 사용하여 로컬 Docker 구성 JSON 파일을 저장합니다. secret 오브젝트의 data 매개변수에 base64 형식으로 인코딩된 .docker/config.json 파일의 내용이 포함되어야 합니다.

절차

  1. 컨트롤 플레인 노드의 YAML 파일에 Secret 오브젝트를 생성합니다.

    Docker 구성 보안 오브젝트 의 예

    apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-cfg
  namespace: my-project
type: kubernetes.io/dockerconfig
    1 
    
data:
  .dockerconfig:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
    2
    Copy to Clipboard Toggle word wrap

    1
    시크릿이 Docker 구성 파일을 사용하도록 지정합니다.
    2
    base64로 인코딩된 Docker 구성 파일의 출력

    Docker 구성 JSON 시크릿 오브젝트의 예

    apiVersion: v1
kind: Secret
metadata:
  name: secret-docker-json
  namespace: my-project
type: kubernetes.io/dockerconfig
    1 
    
data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
    2
    Copy to Clipboard Toggle word wrap

    1
    시크릿이 Docker 구성 JSONfile을 사용하도록 지정합니다.
    2
    base64로 인코딩된 Docker 구성 JSON 파일의 출력

  2. 다음 명령을 사용하여 Secret 오브젝트를 생성합니다. 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

  3. Pod에서 보안을 사용하려면 다음을 수행합니다.

    1. "보안 생성 방법" 섹션에 표시된 대로 Pod의 서비스 계정을 업데이트하여 보안을 참조합니다.
    2. "secret을 보안 생성 방법" 섹션에 설명된 대로 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.

2.6.3. 보안 업데이트 방법 이해
링크 복사

보안 값을 수정해도 이미 실행 중인 Pod에서 사용하는 값은 동적으로 변경되지 않습니다. 보안을 변경하려면 원래 Pod를 삭제하고 새 Pod를 생성해야 합니다(대개 동일한 PodSpec 사용).

보안 업데이트 작업에서는 새 컨테이너 이미지를 배포하는 것과 동일한 워크플로를 따릅니다. kubectl rolling-update 명령을 사용할 수 있습니다.

보안의 resourceVersion 값은 참조 시 지정되지 않습니다. 따라서 Pod가 시작되는 동시에 보안이 업데이트되는 경우 Pod에 사용되는 보안의 버전이 정의되지 않습니다.

참고

현재는 Pod가 생성될 때 사용된 보안 오브젝트의 리소스 버전을 확인할 수 없습니다. 컨트롤러에서 이전 resourceVersion 을 사용하여 재시작할 수 있도록 Pod에서 이 정보를 보고하도록 계획되어 있습니다. 그동안 기존 보안 데이터를 업데이트하지 말고 고유한 이름으로 새 보안을 생성하십시오.

2.6.4. 보안이 포함된 서명된 인증서 사용 정보
링크 복사

서비스에 대한 통신을 보호하려면 프로젝트의 보안에 추가할 수 있는 서명된 제공 인증서/키 쌍을 생성하도록 OpenShift Container Platform을 구성하면 됩니다.

서비스 제공 인증서 보안은 즉시 사용 가능한 인증서가 필요한 복잡한 미들웨어 애플리케이션을 지원하기 위한 것입니다. 해당 설정은 관리자 툴에서 노드 및 마스터에 대해 생성하는 서버 인증서와 동일합니다.

서비스 Pod 사양은 서비스 제공 인증서 보안에 대해 구성됩니다.

apiVersion: v1
kind: Service
metadata:
  name: registry
  annotations:
    service.beta.openshift.io/serving-cert-secret-name: registry-cert
1 

# ...
Copy to Clipboard Toggle word wrap

1
인증서 이름을 지정합니다.

기타 Pod는 해당 Pod에 자동으로 마운트되는 /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt 파일의 CA 번들을 사용하여 내부 DNS 이름에만 서명되는 클러스터 생성 인증서를 신뢰할 수 있습니다.

이 기능의 서명 알고리즘은 x509.SHA256WithRSA입니다. 직접 교대하려면 생성된 보안을 삭제합니다. 새 인증서가 생성됩니다.

2.6.4.1. 보안과 함께 사용할 서명된 인증서 생성
링크 복사

Pod와 함께 서명된 제공 인증서/키 쌍을 사용하려면 서비스를 생성하거나 편집하여 service.beta.openshift.io/serving-cert-secret-name 주석을 추가한 다음 포드에 보안을 추가합니다.

절차

서비스 제공 인증서 보안을 생성하려면 다음을 수행합니다.

  1. 서비스에 대한 Pod 사양을 편집합니다.

  2. 보안에 사용할 이름으로 service.beta.openshift.io/serving-cert-secret-name 주석을 추가합니다. 

    kind: Service
apiVersion: v1
metadata:
  name: my-service
  annotations:
      service.beta.openshift.io/serving-cert-secret-name: my-cert
    1 
    
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
    Copy to Clipboard Toggle word wrap

    인증서 및 키는 PEM 형식이며 각각 tls.crt 및 tls.key에 저장됩니다.

  3. 서비스를 생성합니다. 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

  4. 보안이 생성되었는지 확인합니다.

    1. 모든 보안 목록을 확인합니다. 

      $ oc get secrets
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                     TYPE                                  DATA      AGE
my-cert                  kubernetes.io/tls                     2         9m
      Copy to Clipboard Toggle word wrap

    2. 보안에 대한 세부 정보를 확인합니다. 

      $ oc describe secret my-cert
      Copy to Clipboard Toggle word wrap

      출력 예

      Name:         my-cert
Namespace:    openshift-console
Labels:       <none>
Annotations:  service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
              service.beta.openshift.io/originating-service-name: my-service
              service.beta.openshift.io/originating-service-uid: 640f0ec3-afc2-4380-bf31-a8c784846a11
              service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z

Type:  kubernetes.io/tls

Data
====
tls.key:  1679 bytes
tls.crt:  2595 bytes
      Copy to Clipboard Toggle word wrap

  5. 해당 보안을 사용하여 Pod 사양을 편집합니다. 

    apiVersion: v1
kind: Pod
metadata:
  name: my-service-pod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: my-cert
      items:
      - key: username
        path: my-group/my-username
        mode: 511
    Copy to Clipboard Toggle word wrap

    사용 가능한 경우 Pod가 실행됩니다. 인증서는 내부 서비스 DNS 이름인 <service.name>.<service.namespace>.svc에 적합합니다.

    인증서/키 쌍은 만료 시기가 다가오면 자동으로 교체됩니다. 보안의 service.beta.openshift.io/expiry 주석에서 RFC3339 형식으로 된 만료 날짜를 확인합니다.

    참고

    대부분의 경우 서비스 DNS 이름 <service.name>.<service.namespace>.svc는 외부에서 라우팅할 수 없습니다. <service.name>.<service.namespace>.svc는 주로 클러스터 내 또는 서비스 내 통신과 경로 재암호화에 사용됩니다.

2.6.5. 보안 문제 해결
링크 복사

와 함께 서비스 인증서 생성이 실패하는 경우 (서비스의 service.beta.openshift.io/serving-cert-generation-error 주석에는 다음이 포함됩니다). 

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60
Copy to Clipboard Toggle word wrap

인증서를 생성한 서비스가 더 이상 존재하지 않거나 serviceUID가 다릅니다. 이전 보안을 제거하고 서비스 service.beta.openshift.io/serving-cert-generation- error,service.beta.openshift.io/serving-cert-generation-error -num 주석을 지워 인증서를 강제로 다시 생성해야 합니다.

  1. 보안을 삭제합니다. 

    $ oc delete secret <secret_name>
    Copy to Clipboard Toggle word wrap

  2. 주석을 지웁니다. 

    $ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-
    Copy to Clipboard Toggle word wrap 
    $ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-
    Copy to Clipboard Toggle word wrap
참고

주석을 제거하는 명령에는 제거할 주석 이름 뒤에 -가 있습니다.

2.7. 구성 맵 생성 및 사용
링크 복사

다음 섹션에서는 구성 맵과 이를 생성하고 사용하는 방법을 정의합니다.

2.7.1. 구성 맵 이해
링크 복사

많은 애플리케이션에서는 구성 파일, 명령줄 인수 및 환경 변수를 조합한 구성이 필요합니다. OpenShift Container Platform에서 컨테이너화된 애플리케이션을 이식하기 위해 이러한 구성 아티팩트는 이미지 콘텐츠와 분리됩니다.

ConfigMap 오브젝트는 컨테이너를 OpenShift Container Platform과 무관하게 유지하면서 구성 데이터를 사용하여 컨테이너를 삽입하는 메커니즘을 제공합니다. 구성 맵은 개별 속성 또는 전체 구성 파일 또는 JSON Blob과 같은 세분화된 정보를 저장하는 데 사용할 수 있습니다.

ConfigMap API 오브젝트에는 Pod에서 사용하거나 컨트롤러와 같은 시스템 구성 요소의 구성 데이터를 저장하는 데 사용할 수 있는 구성 데이터의 키-값 쌍이 있습니다. 예를 들면 다음과 같습니다.

ConfigMap 오브젝트 정의

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: default
data:
1 

  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3
binaryData:
  bar: L3Jvb3QvMTAw
2
Copy to Clipboard Toggle word wrap

1 1
구성 데이터를 포함합니다.
2
UTF8이 아닌 데이터를 포함한 파일을 가리킵니다(예: 바이너리 Java 키 저장소 파일). Base 64에 파일 데이터를 입력합니다.
참고

이미지와 같은 바이너리 파일에서 구성 맵을 생성할 때 binaryData 필드를 사용할 수 있습니다.

다양한 방법으로 Pod에서 구성 데이터를 사용할 수 있습니다. 구성 맵을 다음과 같이 사용할 수 있습니다.

  • 컨테이너에서 환경 변수 값 채우기
  • 컨테이너에서 명령줄 인수 설정
  • 볼륨에 구성 파일 채우기

사용자 및 시스템 구성 요소는 구성 데이터를 구성 맵에 저장할 수 있습니다.

구성 맵은 보안과 유사하지만 민감한 정보가 포함되지 않은 문자열 작업을 더 편리하게 지원하도록 설계되었습니다.

구성 맵 제한 사항

Pod에서 콘텐츠를 사용하기 전에 구성 맵을 생성해야 합니다.

컨트롤러는 누락된 구성 데이터를 허용하도록 작성할 수 있습니다. 상황에 따라 구성 맵을 사용하여 구성된 개별 구성 요소를 참조하십시오.

ConfigMap 오브젝트는 프로젝트에 있습니다.

동일한 프로젝트의 Pod에서만 참조할 수 있습니다.

Kubelet은 API 서버에서 가져오는 Pod에 대한 구성 맵만 지원합니다.

여기에는 CLI를 사용하거나 복제 컨트롤러에서 간접적으로 생성되는 모든 Pod가 포함됩니다. OpenShift Container Platform 노드의 --manifest-url 플래그, --config 플래그 또는 해당 REST API를 사용하여 생성한 Pod를 포함하지 않으며 이는 Pod를 생성하는 일반적인 방법이 아니기 때문입니다.

2.7.2. OpenShift Container Platform 웹 콘솔에서 구성 맵 생성
링크 복사

OpenShift Container Platform 웹 콘솔에서 구성 맵을 생성할 수 있습니다.

절차

  • 클러스터 관리자로 구성 맵을 생성하려면 다음을 수행합니다.

    1. 관리자 관점에서 Workloads → Config Maps을 선택합니다.
    2. 페이지 오른쪽 상단에서 구성 맵 생성을 선택합니다.
    3. 구성 맵의 콘텐츠를 입력합니다.
    4. 생성을 선택합니다.

  • 개발자로 구성 맵을 생성하려면 다음을 수행합니다.

    1. 개발자 관점에서 Config Maps을 선택합니다.
    2. 페이지 오른쪽 상단에서 구성 맵 생성을 선택합니다.
    3. 구성 맵의 콘텐츠를 입력합니다.
    4. 생성을 선택합니다.

2.7.3. CLI를 사용하여 구성 맵 생성
링크 복사

다음 명령을 사용하여 디렉토리, 특정 파일 또는 리터럴 값에서 구성 맵을 생성할 수 있습니다.

절차

  • 구성 맵 생성: 

    $ oc create configmap <configmap_name> [options]
    Copy to Clipboard Toggle word wrap
2.7.3.1. 디렉토리에서 구성 맵 생성
링크 복사

디렉토리에서 구성 맵을 생성할 수 있습니다. 이 방법을 사용하면 디렉토리 내 여러 파일을 사용하여 구성 맵을 생성할 수 있습니다.

절차

다음 예제 절차에서는 디렉토리에서 구성 맵을 생성하는 방법을 간략하게 설명합니다.

  1. 구성 맵을 채우려는 데이터가 이미 포함된 일부 파일이 있는 디렉토리로 시작합니다. 

    $ ls example-files
    Copy to Clipboard Toggle word wrap

    출력 예

    game.properties
ui.properties
    Copy to Clipboard Toggle word wrap 

    $ cat example-files/game.properties
    Copy to Clipboard Toggle word wrap

    출력 예

    enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
    Copy to Clipboard Toggle word wrap 

    $ cat example-files/ui.properties
    Copy to Clipboard Toggle word wrap

    출력 예

    color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 이 디렉토리에 각 파일의 내용을 보관하는 구성 맵을 생성합니다. 

    $ oc create configmap game-config \
    --from-file=example-files/
    Copy to Clipboard Toggle word wrap

    --from-file 옵션이 디렉터리를 가리키는 경우 해당 디렉터리의 각 파일은 구성 맵에 키를 채우는 데 사용됩니다. 여기서 키 이름은 파일 이름이고 키의 값은 파일의 내용입니다.

    예를 들어 이전 명령은 다음 구성 맵을 생성합니다. 

    $ oc describe configmaps game-config
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:           game-config
Namespace:      default
Labels:         <none>
Annotations:    <none>

Data

game.properties:        158 bytes
ui.properties:          83 bytes
    Copy to Clipboard Toggle word wrap

    맵의 두 키가 명령에 지정된 디렉토리의 파일 이름에서 생성되는 것을 확인할 수 있습니다. 해당 키의 콘텐츠가 커질 수 있으므로 oc describe의 출력은 키와 크기의 이름만 표시합니다.

  3. 키 값을 보려면 -o 옵션을 사용하여 오브젝트에 대한 oc get 명령을 입력합니다. 

    $ oc get configmaps game-config -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:34:05Z
  name: game-config
  namespace: default
  resourceVersion: "407"
  selflink: /api/v1/namespaces/default/configmaps/game-config
  uid: 30944725-d66e-11e5-8cd0-68f728db1985
    Copy to Clipboard Toggle word wrap

2.7.3.2. 파일에서 구성 맵 생성
링크 복사

파일에서 구성 맵을 생성할 수 있습니다.

절차

다음 예제 절차에서는 파일에서 구성 맵을 생성하는 방법을 간략하게 설명합니다.

참고

파일에서 구성 맵을 생성하는 경우 UTF8이 아닌 데이터를 손상시키지 않고 이 필드에 배치된 UTF8이 아닌 데이터가 포함된 파일을 포함할 수 있습니다. OpenShift Container Platform에서는 바이너리 파일을 감지하고 파일을 MIME로 투명하게 인코딩합니다. 서버에서 MIME 페이로드는 데이터 손상 없이 디코딩되어 저장됩니다.

--from-file 옵션을 CLI에 여러 번 전달할 수 있습니다. 다음 예제에서는 디렉토리 예제에서 생성되는 것과 동일한 결과를 보여줍니다.

  1. 특정 파일을 지정하여 구성 맵을 생성합니다. 

    $ oc create configmap game-config-2 \
    --from-file=example-files/game.properties \
    --from-file=example-files/ui.properties
    Copy to Clipboard Toggle word wrap

  2. 결과 확인: 

    $ oc get configmaps game-config-2 -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:52:05Z
  name: game-config-2
  namespace: default
  resourceVersion: "516"
  selflink: /api/v1/namespaces/default/configmaps/game-config-2
  uid: b4952dc3-d670-11e5-8cd0-68f728db1985
    Copy to Clipboard Toggle word wrap

파일에서 가져온 콘텐츠의 구성 맵에 설정할 키를 지정할 수 있습니다. 이는 key=value 표현식을 --from-file 옵션에 전달하여 설정할 수 있습니다. 예를 들면 다음과 같습니다.

  1. 키-값 쌍을 지정하여 구성 맵을 생성합니다. 

    $ oc create configmap game-config-3 \
    --from-file=game-special-key=example-files/game.properties
    Copy to Clipboard Toggle word wrap

  2. 결과 확인: 

    $ oc get configmaps game-config-3 -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
data:
  game-special-key: |-
    1 
    
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:54:22Z
  name: game-config-3
  namespace: default
  resourceVersion: "530"
  selflink: /api/v1/namespaces/default/configmaps/game-config-3
  uid: 05f8da22-d671-11e5-8cd0-68f728db1985
    Copy to Clipboard Toggle word wrap

    1
    이전 단계에서 설정한 키입니다.
2.7.3.3. 리터럴 값에서 구성 맵 생성
링크 복사

구성 맵에 리터럴 값을 제공할 수 있습니다.

절차

--from-literal 옵션은 명령줄에서 직접 리터럴 값을 제공할 수 있는 key=value 구문을 사용합니다.

  1. 리터럴 값을 지정하여 구성 맵을 생성합니다. 

    $ oc create configmap special-config \
    --from-literal=special.how=very \
    --from-literal=special.type=charm
    Copy to Clipboard Toggle word wrap

  2. 결과 확인: 

    $ oc get configmaps special-config -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
data:
  special.how: very
  special.type: charm
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: special-config
  namespace: default
  resourceVersion: "651"
  selflink: /api/v1/namespaces/default/configmaps/special-config
  uid: dadce046-d673-11e5-8cd0-68f728db1985
    Copy to Clipboard Toggle word wrap

2.7.4. 사용 사례: Pod에서 구성 맵 사용
링크 복사

다음 섹션에서는 Pod에서 ConfigMap 오브젝트를 사용할 때 몇 가지 사용 사례에 대해 설명합니다.

2.7.4.1. 구성 맵을 사용하여 컨테이너에서 환경 변수 채우기
링크 복사

구성 맵은 컨테이너의 개별 환경 변수를 채우거나 유효한 환경 변수 이름을 형성하는 모든 키에서 컨테이너에 있는 환경 변수를 채우는 데 사용할 수 있습니다.

예를 들어 다음 구성 맵을 고려하십시오.

두 개의 환경 변수가 있는 ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
1 

  namespace: default
2 

data:
  special.how: very
3 

  special.type: charm
4
Copy to Clipboard Toggle word wrap

1
구성 맵의 이름입니다.
2
구성 맵이 있는 프로젝트입니다. 구성 맵은 동일한 프로젝트의 Pod에서만 참조할 수 있습니다.
3 4
삽입할 환경 변수입니다.

하나의 환경 변수가 있는 ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
1 

  namespace: default
data:
  log_level: INFO
2
Copy to Clipboard Toggle word wrap

1
구성 맵의 이름입니다.
2
삽입할 환경 변수입니다.

절차

  • configMapKeyRef 섹션을 사용하여 Pod에서 이 ConfigMap의 키를 사용할 수 있습니다.

    특정 환경 변수를 삽입하도록 구성된 샘플 Pod 사양

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
    1 
    
        - name: SPECIAL_LEVEL_KEY
    2 
    
          valueFrom:
            configMapKeyRef:
              name: special-config
    3 
    
              key: special.how
    4 
    
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
    5 
    
              key: special.type
    6 
    
              optional: true
    7 
    
      envFrom:
    8 
    
        - configMapRef:
            name: env-config
    9 
    
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap

    1
    ConfigMap에서 지정된 환경 변수를 가져오는 스탠자입니다.
    2
    키 값을 삽입하는 Pod 환경 변수의 이름입니다.
    3 5
    특정 환경 변수를 끌어올 ConfigMap의 이름입니다.
    4 6
    ConfigMap에서 가져올 환경 변수입니다.
    7
    환경 변수를 선택적으로 만듭니다. 선택적으로 지정된 ConfigMap 및 키가 없는 경우에도 Pod가 시작됩니다.
    8
    ConfigMap에서 모든 환경 변수를 가져오는 스탠자입니다.
    9
    모든 환경 변수를 가져올 ConfigMap의 이름입니다.

    이 Pod가 실행되면 Pod 로그에 다음 출력이 포함됩니다. 

    SPECIAL_LEVEL_KEY=very
log_level=INFO
    Copy to Clipboard Toggle word wrap
참고

SPECIAL_TYPE_KEY=charm은 예제 출력에 나열되지 않습니다. optional: true가 설정되어 있기 때문입니다.

2.7.4.2. 구성 맵을 사용하여 컨테이너 명령에 대한 명령줄 인수 설정
링크 복사

구성 맵을 사용하여 컨테이너에서 명령 또는 인수 값을 설정할 수도 있습니다. 이는 Kubernetes 대체 구문 $(VAR_NAME)을 사용하여 수행됩니다. 다음 구성 맵을 고려하십시오. 

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm
Copy to Clipboard Toggle word wrap

절차

  • 컨테이너의 명령에 값을 삽입하려면 환경 변수 사용 사례에서 ConfigMap을 사용하는 것처럼 환경 변수로 사용할 키를 사용해야 합니다. 그런 다음 $(VAR_NAME) 구문을 사용하여 컨테이너의 명령에서 참조할 수 있습니다.

    특정 환경 변수를 삽입하도록 구성된 샘플 Pod 사양

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
    1 
    
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap

    1
    환경 변수로 사용할 키를 사용하여 컨테이너의 명령에 값을 삽입합니다.

    이 Pod가 실행되면 test-container 컨테이너에서 실행되는 echo 명령의 출력은 다음과 같습니다. 

    very charm
    Copy to Clipboard Toggle word wrap
2.7.4.3. 구성 맵을 사용하여 볼륨에 콘텐츠 삽입
링크 복사

구성 맵을 사용하여 볼륨에 콘텐츠를 삽입할 수 있습니다.

ConfigMap CR(사용자 정의 리소스)의 예

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm
Copy to Clipboard Toggle word wrap

절차

구성 맵을 사용하여 볼륨에 콘텐츠를 삽입하는 몇 가지 다른 옵션이 있습니다.

  • 구성 맵을 사용하여 콘텐츠를 볼륨에 삽입하는 가장 기본적인 방법은 키가 파일 이름이고 파일의 콘텐츠가 키의 값인 파일로 볼륨을 채우는 것입니다. 

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/special.how" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
    1 
    
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap
    1
    키가 포함된 파일입니다.

    이 Pod가 실행되면 cat 명령의 출력은 다음과 같습니다. 

    very
    Copy to Clipboard Toggle word wrap

  • 구성 맵 키가 프로젝션되는 볼륨 내 경로를 제어할 수도 있습니다. 

    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/path/to/special-key" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: special.how
          path: path/to/special-key
    1 
    
  restartPolicy: Never
    Copy to Clipboard Toggle word wrap
    1
    구성 맵 키의 경로입니다.

    이 Pod가 실행되면 cat 명령의 출력은 다음과 같습니다. 

    very
    Copy to Clipboard Toggle word wrap

2.8. 장치 플러그인을 사용하여 Pod가 있는 외부 리소스에 액세스
링크 복사

장치 플러그인을 사용하면 사용자 정의 코드를 작성하지 않고 OpenShift Container Platform Pod에서 특정 장치 유형(GPU, InfiniBand 또는 벤더별 초기화 및 설정이 필요한 기타 유사한 컴퓨팅 리소스)을 사용할 수 있습니다.

2.8.1. 장치 플러그인 이해
링크 복사

장치 플러그인은 클러스터 전체에서 하드웨어 장치를 소비할 수 있는 일관되고 이식 가능한 솔루션을 제공합니다. 장치 플러그인은 확장 메커니즘을 통해 이러한 장치를 지원하여 컨테이너에서 이러한 장치를 사용할 수있게 하고 장치의 상태 점검을 제공하며 안전하게 공유합니다.

중요

OpenShift Container Platform은 장치 플러그인 API를 지원하지만 장치 플러그인 컨테이너는 개별 공급 업체에 의해 지원됩니다.

장치 플러그인은 특정 하드웨어 리소스를 관리하는 노드 (kubelet 외부)에서 실행되는 gRPC 서비스입니다. 모든 장치 플러그인은 다음 원격 프로 시저 호출 (RPC)을 지원해야합니다. 

service DevicePlugin {
      // GetDevicePluginOptions returns options to be communicated with Device
      // Manager
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}

      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plug-in can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}

      // PreStartcontainer is called, if indicated by Device Plug-in during
      // registration phase, before each container start. Device plug-in
      // can run device specific operations such as reseting the device
      // before making devices available to the container
      rpc PreStartcontainer(PreStartcontainerRequest) returns (PreStartcontainerResponse) {}
}
Copy to Clipboard Toggle word wrap
장치 플러그인의 예
참고

간편한 장치 플러그인 참조 구현을 위해 장치 관리자 (Device Manager) 코드에 vendor/k8s.io/kubernetes/pkg/kubelet/cm/deviceplugin/device_plugin_stub.go 스텁 장치 플러그인을 사용할 수 있습니다.

2.8.1.1. 장치 플러그인을 배포하는 방법
링크 복사
  • 장치 플러그인 배포에는 데몬 세트 접근 방식을 사용하는 것이 좋습니다.
  • 시작할 때 장치 플러그인은 노드의 /var/lib/kubelet/device-plugin/에 UNIX 도메인 소켓을 만들어 장치 관리자의 RPC를 제공하려고 합니다.
  • 장치 플러그인은 하드웨어 리소스, 호스트 파일 시스템에 대한 액세스 및 소켓 생성을 관리해야 하므로 권한이 부여된 보안 컨텍스트에서 실행해야합니다.
  • 배포 단계에 대한 보다 구체적인 세부 사항은 각 장치 플러그인 구현에서 확인할 수 있습니다.

2.8.2. 장치 관리자 이해
링크 복사

장치 관리자(Device Manager)는 장치 플러그인이라는 플러그인을 사용하여 특수 노드 하드웨어 리소스를 알리기 위한 메커니즘을 제공합니다.

업스트림 코드 변경없이 특수 하드웨어를 공개할 수 있습니다.

중요

OpenShift Container Platform은 장치 플러그인 API를 지원하지만 장치 플러그인 컨테이너는 개별 공급 업체에 의해 지원됩니다.

장치 관리자는 장치를 확장 리소스(Extended Resources)으로 공개합니다. 사용자 pod는 다른 확장 리소스 를 요청하는 데 사용되는 동일한 제한/요청 메커니즘을 사용하여 장치 관리자에 의해 공개된 장치를 사용할 수 있습니다.

시작시 장치 플러그인은 /var/lib/kubelet/device-plugins/kubelet.sock에서에서 Register를 호출하는 장치 관리자에 직접 등록하고 장치 관리자의 요구를 제공하기 위해 /var/lib/kubelet/device-plugins/<plugin>.sock에서 gRPC 서비스를 시작합니다.

장치 관리자는 새 등록 요청을 처리하는 동안 장치 플러그인 서비스에서 ListAndWatch 원격 프로 시저 호출 (RPC)을 시작합니다. 이에 대한 응답으로 장치 관리자는 플러그인에서 gRPC 스트림을 통해 장치 오브젝트 목록을 가져옵니다. 장치 관리자는 플러그인에서 새 업데이트의 유무에 대해 스트림을 모니터링합니다. 플러그인 측에서도 플러그인은 스트림을 열린 상태로 유지하고 장치 상태가 변경될 때마다 동일한 스트리밍 연결을 통해 새 장치 목록이 장치 관리자로 전송됩니다.

새로운 pod 승인 요청을 처리하는 동안 Kubelet은 장치 할당을 위해 요청된 Extended Resources를 장치 관리자에게 전달합니다. 장치 관리자는 데이터베이스에서 해당 플러그인이 존재하는지 확인합니다. 플러그인이 존재하고 로컬 캐시로 할당 가능한 디바이스가 있는 경우 Allocate RPC가 특정 디바이스 플러그인에서 호출됩니다.

또한 장치 플러그인은 드라이버 설치, 장치 초기화 및 장치 재설정과 같은 몇 가지 다른 장치 별 작업을 수행할 수 있습니다. 이러한 기능은 구현마다 다릅니다.

2.8.3. 장치 관리자 활성화
링크 복사

장치 관리자는 장치 플러그인을 구현하여 업스트림 코드 변경없이 특수 하드웨어를 사용할 수 있습니다.

장치 관리자(Device Manager)는 장치 플러그인이라는 플러그인을 사용하여 특수 노드 하드웨어 리소스를 알리기 위한 메커니즘을 제공합니다.

  1. 구성하려는 노드 유형의 정적 MachineConfigPool CRD와 연관된 라벨을 가져옵니다. 다음 중 하나를 실행합니다.

    1. Machine config를 표시합니다: 

      # oc describe machineconfig <name>
      Copy to Clipboard Toggle word wrap

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

      # oc describe machineconfig 00-worker
      Copy to Clipboard Toggle word wrap

      출력 예

      Name:         00-worker
Namespace:
Labels:       machineconfiguration.openshift.io/role=worker
      1
      Copy to Clipboard Toggle word wrap

      1
      장치 관리자에 필요한 라벨입니다.

프로세스

  1. 구성 변경을 위한 사용자 정의 리소스 (CR)를 만듭니다.

    장치 관리자 CR의 설정 예

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: devicemgr
    1 
    
spec:
  machineConfigPoolSelector:
    matchLabels:
       machineconfiguration.openshift.io: devicemgr
    2 
    
  kubeletConfig:
    feature-gates:
      - DevicePlugins=true
    3
    Copy to Clipboard Toggle word wrap

    1
    CR에 이름을 지정합니다.
    2
    Machine Config Pool에서 라벨을 입력합니다.
    3
    DevicePlugins를 'true'로 설정합니다.

  2. 장치 관리자를 만듭니다. 

    $ oc create -f devicemgr.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    kubeletconfig.machineconfiguration.openshift.io/devicemgr created
    Copy to Clipboard Toggle word wrap

  3. 노드에서 /var/lib/kubelet/device-plugins/kubelet.sock이 작성되었는지 확인하여 장치 관리자가 실제로 사용 가능한지 확인합니다. 이는 장치 관리자의 gRPC 서버가 새 플러그인 등록을 수신하는 UNIX 도메인 소켓입니다. 이 소켓 파일은 장치 관리자가 활성화된 경우에만 Kubelet을 시작할 때 생성됩니다.

2.9. Pod 예약 결정에 Pod 우선순위 포함
링크 복사

클러스터에서 Pod 우선순위 및 선점을 활성화할 수 있습니다. Pod 우선순위는 다른 Pod와 관련된 Pod의 중요성을 나타내며 해당 우선순위를 기반으로 Pod를 대기열에 넣습니다. Pod 선점을 통해 클러스터에서 우선순위가 낮은 Pod를 제거하거나 선점할 수 있으므로 적절한 노드 Pod 우선순위에 사용 가능한 공간이 없는 경우 우선순위가 높은 Pod를 예약할 수 있습니다. Pod Pod 우선순위는 Pod의 스케줄링 순서에도 영향을 미치지 않습니다.

우선순위 및 선점 기능을 사용하려면 Pod의 상대적 가중치를 정의하는 우선순위 클래스를 생성합니다. 그런 다음 Pod 사양의 우선순위 클래스를 참조하여 예약에 해당 값을 적용합니다.

2.9.1. Pod 우선순위 이해
링크 복사

Pod 우선순위 및 선점 기능을 사용하면 스케줄러에서 보류 중인 Pod를 우선순위에 따라 정렬하고, 보류 중인 Pod는 예약 큐에서 우선순위가 더 낮은 다른 대기 중인 Pod보다 앞에 배치됩니다. 그 결과 예약 요구 사항이 충족되는 경우 우선순위가 높은 Pod가 우선순위가 낮은 Pod보다 더 빨리 예약될 수 있습니다. Pod를 예약할 수 없는 경우에는 스케줄러에서 우선순위가 낮은 다른 Pod를 계속 예약합니다.

2.9.1.1. Pod 우선순위 클래스
링크 복사

네임스페이스가 지정되지 않은 오브젝트로서 이름에서 우선순위 정수 값으로의 매핑을 정의하는 우선순위 클래스를 Pod에 할당할 수 있습니다. 값이 클수록 우선순위가 높습니다.

우선순위 클래스 오브젝트에는 1000000000(10억)보다 작거나 같은 32비트 정수 값을 사용할 수 있습니다. 선점하거나 제거해서는 안 되는 중요한 Pod의 경우 10억보다 큰 숫자를 예약합니다. 기본적으로 OpenShift Container Platform에는 중요한 시스템 Pod의 예약을 보장하기 위해 우선순위 클래스가 2개 예약되어 있습니다. 

$ oc get priorityclasses
Copy to Clipboard Toggle word wrap

출력 예

NAME                      VALUE        GLOBAL-DEFAULT   AGE
cluster-logging           1000000      false            29s
system-cluster-critical   2000000000   false            72m
system-node-critical      2000001000   false            72m
Copy to Clipboard Toggle word wrap

  • system-node-critical - 이 우선순위 클래스의 값은 2000001000이며 노드에서 제거해서는 안 되는 모든 Pod에 사용합니다. 이 우선순위 클래스가 있는 Pod의 예로는 sdn-ovs, sdn 등이 있습니다. 대다수의 중요한 구성 요소에는 기본적으로 system-node-critical 우선순위 클래스가 포함됩니다. 예를 들면 다음과 같습니다.

    • master-api
    • master-controller
    • master-etcd
    • sdn
    • sdn-ovs
    • sync

  • system-cluster-critical - 이 우선순위 클래스의 값은 2000000000(10억)이며 클러스터에 중요한 Pod에 사용합니다. 이 우선순위 클래스가 있는 Pod는 특정 상황에서 노드에서 제거할 수 있습니다. 예를 들어 system-node-critical 우선순위 클래스를 사용하여 구성한 Pod가 우선할 수 있습니다. 그러나 이 우선순위 클래스는 예약을 보장합니다. 이 우선순위 클래스를 사용할 수 있는 Pod의 예로는 fluentd, Descheduler와 같은 추가 기능 구성 요소 등이 있습니다. 대다수의 중요한 구성 요소에는 기본적으로 system-cluster-critical 우선순위 클래스가 포함됩니다. 예를 들면 다음과 같습니다.

    • fluentd
    • metrics-server
    • Descheduler
  • cluster-logging - 이 우선순위는 Fluentd에서 Fluentd Pod가 다른 앱보다 먼저 노드에 예약되도록 하는 데 사용합니다.
2.9.1.2. Pod 우선순위 이름
링크 복사

우선순위 클래스가 한 개 이상 있으면 Pod 사양에서 우선순위 클래스 이름을 지정하는 Pod를 생성할 수 있습니다. 우선순위 승인 컨트롤러는 우선순위 클래스 이름 필드를 사용하여 정수 값으로 된 우선순위를 채웁니다. 이름이 지정된 우선순위 클래스가 없는 경우 Pod가 거부됩니다.

2.9.2. Pod 선점 이해
링크 복사

개발자가 Pod를 생성하면 Pod가 큐로 들어갑니다. 개발자가 Pod에 Pod 우선순위 또는 선점을 구성한 경우 스케줄러는 큐에서 Pod를 선택하고 해당 Pod를 노드에 예약하려고 합니다. 스케줄러가 노드에서 Pod의 지정된 요구 사항을 모두 충족하는 적절한 공간을 찾을 수 없는 경우 보류 중인 Pod에 대한 선점 논리가 트리거됩니다.

스케줄러가 노드에서 Pod를 하나 이상 선점하면 우선순위가 높은 Pod 사양의 nominatedNodeName 필드가 nodename 필드와 함께 노드의 이름으로 설정됩니다. 스케줄러는 nominatedNodeName 필드를 사용하여 Pod용으로 예약된 리소스를 계속 추적하고 클러스터의 선점에 대한 정보도 사용자에게 제공합니다.

스케줄러에서 우선순위가 낮은 Pod를 선점한 후에는 Pod의 정상 종료 기간을 따릅니다. 스케줄러에서 우선순위가 낮은 Pod가 종료되기를 기다리는 동안 다른 노드를 사용할 수 있게 되는 경우 스케줄러는 해당 노드에서 우선순위가 더 높은 Pod를 예약할 수 있습니다. 따라서 Pod 사양의 nominatedNodeName 필드 및 nodeName 필드가 다를 수 있습니다.

또한 스케줄러가 노드의 Pod를 선점하고 종료되기를 기다리고 있는 상태에서 보류 중인 Pod보다 우선순위가 높은 Pod를 예약해야 하는 경우, 스케줄러는 우선순위가 더 높은 Pod를 대신 예약할 수 있습니다. 이러한 경우 스케줄러는 보류 중인 Pod의 nominatedNodeName을 지워 해당 Pod를 다른 노드에 사용할 수 있도록 합니다.

선점을 수행해도 우선순위가 낮은 Pod가 노드에서 모두 제거되는 것은 아닙니다. 스케줄러는 우선순위가 낮은 Pod의 일부를 제거하여 보류 중인 Pod를 예약할 수 있습니다.

스케줄러는 노드에서 보류 중인 Pod를 예약할 수 있는 경우에만 해당 노드에서 Pod 선점을 고려합니다.

2.9.2.1. Pod 선점 및 기타 스케줄러 설정
링크 복사

Pod 우선순위 및 선점 기능을 활성화하는 경우 다른 스케줄러 설정을 고려하십시오.

Pod 우선순위 및 Pod 중단 예산
Pod 중단 예산은 동시에 작동해야 하는 최소 복제본 수 또는 백분율을 지정합니다. Pod 중단 예산을 지정하면 Pod를 최적의 노력 수준에서 선점할 때 OpenShift Container Platform에서 해당 예산을 준수합니다. 스케줄러는 Pod 중단 예산을 위반하지 않고 Pod를 선점하려고 합니다. 이러한 Pod를 찾을 수 없는 경우 Pod 중단 예산 요구 사항과 관계없이 우선순위가 낮은 Pod를 선점할 수 있습니다.
Pod 우선순위 및 Pod 유사성
Pod 유사성을 위해서는 동일한 라벨이 있는 다른 Pod와 같은 노드에서 새 Pod를 예약해야 합니다.

노드에서 우선순위가 낮은 하나 이상의 Pod와 보류 중인 Pod에 Pod 간 유사성이 있는 경우 스케줄러는 선호도 요구 사항을 위반하지 않고 우선순위가 낮은 Pod를 선점할 수 없습니다. 이 경우 스케줄러는 보류 중인 Pod를 예약할 다른 노드를 찾습니다. 그러나 스케줄러에서 적절한 노드를 찾을 수 있다는 보장이 없고 보류 중인 Pod가 예약되지 않을 수 있습니다.

이러한 상황을 방지하려면 우선순위가 같은 Pod를 사용하여 Pod 유사성을 신중하게 구성합니다.

2.9.2.2. 선점된 Pod의 정상 종료
링크 복사

Pod를 선점할 때 스케줄러는 Pod의 정상 종료 기간이 만료될 때까지 대기하여 Pod가 작동을 완료하고 종료할 수 있도록 합니다. 기간이 지난 후에도 Pod가 종료되지 않으면 스케줄러에서 Pod를 종료합니다. 이러한 정상 종료 기간으로 인해 스케줄러에서 Pod를 선점하는 시점과 노드에서 보류 중인 Pod를 예약할 수 있는 시간 사이에 시차가 발생합니다.

이 간격을 최소화하려면 우선순위가 낮은 Pod의 정상 종료 기간을 짧게 구성하십시오.

2.9.3. 우선순위 및 선점 구성
링크 복사

우선순위 클래스 오브젝트를 생성하고 Pod 사양에 priorityClassName을 사용하여 Pod를 우선순위에 연결하여 우선순위 및 선점을 적용합니다.

우선순위 클래스 오브젝트 샘플

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
1 

value: 1000000
2 

globalDefault: false
3 

description: "This priority class should be used for XYZ service pods only."
4
Copy to Clipboard Toggle word wrap

1
우선순위 클래스 오브젝트의 이름입니다.
2
오브젝트의 우선순위 값입니다.
3
우선순위 클래스 이름이 지정되지 않은 Pod에 이 우선순위 클래스를 사용해야 하는지의 여부를 나타내는 선택적 필드입니다. 이 필드는 기본적으로 false입니다. globalDefault가 true로 설정된 하나의 우선순위 클래스만 클러스터에 존재할 수 있습니다. globalDefault:true가 설정된 우선순위 클래스가 없는 경우 우선순위 클래스 이름이 없는 Pod의 우선순위는 0입니다. globalDefault:true를 사용하여 우선순위 클래스를 추가하면 우선순위 클래스를 추가한 후 생성된 Pod에만 영향을 미치고 기존 Pod의 우선순위는 변경되지 않습니다.
4
개발자가 이 우선순위 클래스와 함께 사용해야 하는 Pod를 설명하는 임의의 텍스트 문자열(선택 사항)입니다.

프로세스

우선순위 및 선점을 사용하도록 클러스터를 구성하려면 다음을 수행합니다.

  1. 우선순위 클래스를 한 개 이상 생성합니다.

    1. 우선순위의 이름과 값을 지정합니다.
    2. 필요한 경우 우선순위 클래스 및 설명에 globalDefault 필드를 지정합니다.

  2. Pod 사양을 생성하거나 다음과 같이 우선순위 클래스의 이름을 포함하도록 기존 Pod를 편집합니다.

    우선순위 클래스 이름이 있는 샘플 Pod 사양

    apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority
    1
    Copy to Clipboard Toggle word wrap

    1
    이 Pod에 사용할 우선순위 클래스를 지정합니다.

  3. Pod를 생성합니다. 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

    Pod 구성 또는 Pod 템플릿에 우선순위 이름을 직접 추가할 수 있습니다.

2.10. 노드 선택기를 사용하여 특정 노드에 Pod 배치
링크 복사

노드 선택기는 키-값 쌍으로 구성된 맵을 지정합니다. 규칙은 노드의 사용자 정의 라벨과 Pod에 지정된 선택기를 사용하여 정의합니다.

Pod를 노드에서 실행하려면 Pod에 노드의 라벨로 표시된 키-값 쌍이 있어야 합니다.

동일한 Pod 구성에서 노드 유사성 및 노드 선택기를 사용하는 경우 아래의 중요 고려 사항을 참조하십시오.

2.10.1. 노드 선택기를 사용하여 Pod 배치 제어
링크 복사

Pod의 노드 선택기와 노드의 라벨을 사용하여 Pod가 예약되는 위치를 제어할 수 있습니다. 노드 선택기를 사용하면 OpenShift Container Platform에서 일치하는 라벨이 포함된 노드에 Pod를 예약합니다.

노드, 머신 세트 또는 머신 구성에 라벨을 추가합니다. 머신 세트에 라벨을 추가하면 노드 또는 머신이 중단되는 경우 새 노드에 라벨이 지정됩니다. 노드 또는 머신이 중단된 경우 노드 또는 머신 구성에 추가된 라벨이 유지되지 않습니다.

기존 Pod에 노드 선택기를 추가하려면 ReplicaSet 오브젝트, DaemonSet 오브젝트, StatefulSet 오브젝트, Deployment 오브젝트 또는 DeploymentConfig 오브젝트와 같이 해당 Pod의 제어 오브젝트에 노드 선택기를 추가합니다. 이 제어 오브젝트 아래의 기존 Pod는 라벨이 일치하는 노드에서 재생성됩니다. 새 Pod를 생성하는 경우 Pod 사양에 노드 선택기를 직접 추가할 수 있습니다.

참고

예약된 기존 Pod에 노드 선택기를 직접 추가할 수 없습니다.

사전 요구 사항

기존 Pod에 노드 선택기를 추가하려면 해당 Pod의 제어 오브젝트를 결정하십시오. 예를 들어 router-default-66d5cf9464-m2g75 Pod는 router-default-66d5cf9464 복제본 세트에서 제어합니다. 

$ oc describe pod router-default-66d5cf9464-7pwkc

Name:               router-default-66d5cf9464-7pwkc
Namespace:          openshift-ingress

....

Controlled By:      ReplicaSet/router-default-66d5cf9464
Copy to Clipboard Toggle word wrap

웹 콘솔에서 Pod YAML의 ownerReferences 아래에 제어 오브젝트가 나열됩니다. 

  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: router-default-66d5cf9464
      uid: d81dd094-da26-11e9-a48a-128e7edf0312
      controller: true
      blockOwnerDeletion: true
Copy to Clipboard Toggle word wrap

절차

  1. 머신 세트를 사용하거나 노드를 직접 편집하여 노드에 라벨을 추가합니다.

    • 노드를 생성할 때 머신 세트에서 관리하는 노드에 라벨을 추가하려면 MachineSet 오브젝트를 사용합니다.

      1. 다음 명령을 실행하여 MachineSet 오브젝트에 라벨을 추가합니다. 

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

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

        $ oc patch MachineSet abc612-msrtw-worker-us-east-1c  --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

      2. oc edit 명령을 사용하여 라벨이 MachineSet 오브젝트에 추가되었는지 확인합니다.

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

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api
        Copy to Clipboard Toggle word wrap

        MachineSet 오브젝트의 예

        apiVersion: machine.openshift.io/v1beta1
kind: MachineSet

....

spec:
...
  template:
    metadata:
...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
....
        Copy to Clipboard Toggle word wrap

    • 라벨을 노드에 직접 추가합니다.

      1. 노드의 Node 오브젝트를 편집합니다. 

        $ oc label nodes <name> <key>=<value>
        Copy to Clipboard Toggle word wrap

        예를 들어 노드에 라벨을 지정하려면 다음을 수행합니다. 

        $ oc label nodes ip-10-0-142-25.ec2.internal type=user-node region=east
        Copy to Clipboard Toggle word wrap

      2. 라벨이 노드에 추가되었는지 확인합니다. 

        $ oc get nodes -l type=user-node,region=east
        Copy to Clipboard Toggle word wrap

        출력 예

        NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-142-25.ec2.internal   Ready    worker   17m   v1.18.3+002a51f
        Copy to Clipboard Toggle word wrap

  2. Pod에 일치하는 노드 선택기를 추가합니다.

    • 기존 및 향후 Pod에 노드 선택기를 추가하려면 Pod의 제어 오브젝트에 노드 선택기를 추가합니다.

      라벨이 있는 ReplicaSet 오브젝트의 예

      kind: ReplicaSet

....

spec:

....

  template:
    metadata:
      creationTimestamp: null
      labels:
        ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        pod-template-hash: 66d5cf9464
    spec:
      nodeSelector:
        kubernetes.io/os: linux
        node-role.kubernetes.io/worker: ''
        type: user-node
      1
      Copy to Clipboard Toggle word wrap

      1
      노드 선택기를 추가합니다.

    • 특정 새 Pod에 노드 선택기를 추가하려면 선택기를 Pod 오브젝트에 직접 추가합니다.

      노드 선택기가 있는 Pod 오브젝트의 예

      apiVersion: v1
kind: Pod

....

spec:
  nodeSelector:
    region: east
    type: user-node
      Copy to Clipboard Toggle word wrap

      참고

      예약된 기존 Pod에 노드 선택기를 직접 추가할 수 없습니다.

3장. 노드에 대한 Pod 배치 제어(예약)
링크 복사

3.1. 스케줄러를 사용하여 Pod 배치 제어
링크 복사

Pod 예약은 클러스터 내 노드에 대한 새 Pod 배치를 결정하는 내부 프로세스입니다.

스케줄러 코드는 새 Pod가 생성될 때 해당 Pod를 감시하고 이를 호스팅하는 데 가장 적합한 노드를 확인할 수 있도록 깔끔하게 분리되어 있습니다. 그런 다음 마스터 API를 사용하여 Pod에 대한 바인딩(Pod와 노드의 바인딩)을 생성합니다.

기본 Pod 예약
OpenShift Container Platform에는 대부분의 사용자 요구 사항을 충족하는 기본 스케줄러가 제공됩니다. 기본 스케줄러는 고유 툴과 사용자 정의 툴을 모두 사용하여 Pod에 가장 적합한 항목을 결정합니다.
고급 Pod 예약

새 Pod가 배치되는 위치를 추가로 제어해야 하는 상황에서는 OpenShift Container Platform 고급 예약 기능을 사용하여 Pod를 요청하거나 특정 노드에서 또는 특정 Pod와 함께 실행하도록 하는 기본 설정을 포함하도록 Pod를 구성할 수 있습니다.

3.1.1. 스케줄러 사용 사례
링크 복사

OpenShift Container Platform 내에서 예약하는 중요 사용 사례 중 하나는 유연한 유사성 및 유사성 방지 정책을 지원하는 것입니다.

3.1.1.1. 인프라 토폴로지 수준
링크 복사

관리자는 노드에 라벨을 지정하여 인프라(노드)에 다양한 토폴로지 수준을 정의할 수 있습니다. 예를 들면 region=r1, zone=z1, rack=s1과 같습니다.

이러한 라벨 이름에는 특별한 의미가 없으며 관리자는 도시/빌딩/방과 같은 인프라 수준의 이름을 자유롭게 지정할 수 있습니다. 또한 관리자는 인프라 토폴로지에 원하는 수의 수준을 정의할 수 있으며 일반적으로 세 가지 수준이 적합합니다(예: region → zones → racks). 관리자는 모든 조합에 유사성 및 유사성 방지 규칙을 지정할 수 있습니다.

3.1.1.2. 유사성
링크 복사

관리자는 임의의 토폴로지 수준 또는 여러 수준에도 유사성을 지정하도록 스케줄러를 구성할 수 있어야 합니다. 특정 수준의 유사성은 동일한 서비스에 속하는 모든 Pod가 동일한 수준에 속하는 노드에 예약됨을 나타냅니다. 이렇게 하면 관리자가 피어 Pod가 지리적으로 너무 멀리 떨어져 있지 않도록 할 수 있어 애플리케이션의 대기 시간 요구 사항이 처리됩니다. 동일한 유사성 그룹 내에서 Pod를 호스팅할 수 있는 노드가 없는 경우 Pod를 예약하지 않습니다.

Pod를 예약할 위치를 더 잘 제어해야 하는 경우 노드 유사성 규칙을 사용하여 노드에 대한 Pod 배치 제어 및 유사성 및 유사성 방지 규칙을 사용하여 기타 Pod와 관련된 Pod 배치를 참조하십시오.

관리자는 이러한 고급 예약 기능을 사용하여 Pod를 예약할 수 있는 노드를 지정하고 기타 Pod와 관련된 예약을 강제 적용하거나 거부할 수 있습니다.

3.1.1.3. 유사성 방지
링크 복사

관리자는 임의의 토폴로지 수준 또는 여러 수준에도 유사성 방지를 지정하도록 스케줄러를 구성할 수 있어야 합니다. 특정 수준의 유사성 방지(또는 '분배')는 동일한 서비스에 속하는 모든 Pod가 해당 수준에 속하는 노드에 분배되어 있음을 나타냅니다. 이 경우 고가용성을 위해 애플리케이션이 잘 분배됩니다. 스케줄러는 적용 가능한 모든 노드에서 가능한 한 균등하게 서비스 Pod의 균형을 맞추려고 합니다.

Pod를 예약할 위치를 더 잘 제어해야 하는 경우 노드 유사성 규칙을 사용하여 노드에 대한 Pod 배치 제어 및 유사성 및 유사성 방지 규칙을 사용하여 기타 Pod와 관련된 Pod 배치를 참조하십시오.

관리자는 이러한 고급 예약 기능을 사용하여 Pod를 예약할 수 있는 노드를 지정하고 기타 Pod와 관련된 예약을 강제 적용하거나 거부할 수 있습니다.

3.2. Pod 배치를 제어하도록 기본 스케줄러 구성
링크 복사

기본 OpenShift Container Platform Pod 스케줄러는 클러스터 내의 노드에 대한 새 Pod 배치를 결정합니다. Pod에서 데이터를 읽고 구성된 정책에 따라 적합한 노드를 찾으려고 합니다. 이 스케줄러는 완전히 독립적이며 독립형/플러그형 솔루션으로 존재합니다. Pod를 수정하지 않고 Pod를 특정 노드에 연결하는 Pod 바인딩만 생성합니다.

서술자 및 우선순위를 선택하면 스케줄러에 대한 정책이 정의됩니다. 서술자 및 우선순위 목록은 스케줄러 정책 수정을 참조하십시오.

기본 스케줄러 오브젝트 샘플

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  annotations:
    release.openshift.io/create-only: "true"
  creationTimestamp: 2019-05-20T15:39:01Z
  generation: 1
  name: cluster
  resourceVersion: "1491"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: 6435dd99-7b15-11e9-bd48-0aec821b8e34
spec:
  policy:
1 

    name: scheduler-policy
  defaultNodeSelector: type=user-node,region=east
2
Copy to Clipboard Toggle word wrap

1
사용자 정의 스케줄러 정책 파일의 이름을 지정할 수 있습니다.
2
선택 사항: Pod 배치를 특정 노드로 제한하려면 기본 노드 선택기를 지정합니다. 기본 노드 선택기는 모든 네임스페이스에서 생성된 Pod에 적용됩니다. 기본 노드 선택기 및 기존의 Pod 노드 선택기와 일치하는 라벨을 사용하여 노드에 Pod를 예약할 수 있습니다. 이 필드가 설정되어 있어도 프로젝트 수준 노드 선택기가 있는 네임스페이스에는 영향을 미치지 않습니다.

3.2.1. 기본 예약 이해
링크 복사

기존 일반 스케줄러는 3단계 작업에서 Pod를 호스팅할 노드를 선택하는 기본 플랫폼 제공 스케줄러 엔진에 해당합니다.

노드 필터링
사용 가능한 노드를 지정된 제약 조건 또는 요구 사항에 따라 필터링합니다. 이 작업은 서술자라는 필터링 함수 목록을 통해 각 노드를 실행하는 방식으로 수행됩니다.
필터링된 노드 목록 우선순위 지정
이 작업은 0~10 사이의 점수를 지정하는 일련의 priority_ 함수를 통해 수행되는데, 0은 Pod를 호스팅하는 데 적합하지 않음을 나타내고 10은 적합함을 나타냅니다. 스케줄러 구성은 각 우선순위 함수에 간단한 가중치(양의 숫자 값)를 사용할 수도 있습니다. 각 우선순위 함수에서 제공하는 노드 점수에 가중치(대부분의 우선순위에 대한 기본 가중치는 1임)를 곱한 다음 모든 우선순위에서 제공하는 각 노드의 점수를 더하여 결합합니다. 관리자는 이러한 가중치 특성을 사용하여 일부 우선순위에 높은 중요성을 부여할 수 있습니다.
최적의 노드 선택
노드는 해당 점수에 따라 정렬되며 점수가 가장 높은 노드가 Pod를 호스팅하도록 선택됩니다. 여러 노드의 점수가 동일한 경우 해당 노드 중 하나가 무작위로 선택됩니다.
3.2.1.1. 스케줄러 정책 이해
링크 복사

서술자 및 우선순위를 선택하면 스케줄러에 대한 정책이 정의됩니다.

스케줄러 구성 파일은 스케줄러에서 고려할 서술자 및 우선순위를 지정하는 policy.cfg라는 JSON 파일입니다.

스케줄러 정책 파일이 없는 경우 기본 스케줄러 동작이 사용됩니다.

중요

스케줄러 구성 파일에 정의된 서술자 및 우선순위는 기본 스케줄러 정책을 완전히 덮어씁니다. 기본 서술자 및 우선순위 중 하나라도 필요한 경우 정책 구성에서 함수를 명시적으로 지정해야 합니다.

스케줄러 구성 맵 샘플

apiVersion: v1
data:
  policy.cfg: |
    {
        "kind" : "Policy",
        "apiVersion" : "v1",
        "predicates" : [
                {"name" : "MaxGCEPDVolumeCount"},
                {"name" : "GeneralPredicates"},
1 

                {"name" : "MaxAzureDiskVolumeCount"},
                {"name" : "MaxCSIVolumeCountPred"},
                {"name" : "CheckVolumeBinding"},
                {"name" : "MaxEBSVolumeCount"},
                {"name" : "MatchInterPodAffinity"},
                {"name" : "CheckNodeUnschedulable"},
                {"name" : "NoDiskConflict"},
                {"name" : "NoVolumeZoneConflict"},
                {"name" : "PodToleratesNodeTaints"}
                ],
        "priorities" : [
                {"name" : "LeastRequestedPriority", "weight" : 1},
                {"name" : "BalancedResourceAllocation", "weight" : 1},
                {"name" : "ServiceSpreadingPriority", "weight" : 1},
                {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
                {"name" : "NodeAffinityPriority", "weight" : 1},
                {"name" : "TaintTolerationPriority", "weight" : 1},
                {"name" : "ImageLocalityPriority", "weight" : 1},
                {"name" : "SelectorSpreadPriority", "weight" : 1},
                {"name" : "InterPodAffinityPriority", "weight" : 1},
                {"name" : "EqualPriority", "weight" : 1}
                ]
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2019-09-17T08:42:33Z"
  name: scheduler-policy
  namespace: openshift-config
  resourceVersion: "59500"
  selfLink: /api/v1/namespaces/openshift-config/configmaps/scheduler-policy
  uid: 17ee8865-d927-11e9-b213-02d1e1709840`
Copy to Clipboard Toggle word wrap

1
GeneralPredicates 서술자는 PodFitsResources, HostName, PodFitsHostPorts, MatchNodeSelector 서술자를 나타냅니다. 동일한 서술자를 여러 번 구성할 수 없기 때문에 GeneralPredicates 서술어를 표시된 4개의 서술자와 함께 사용할 수 없습니다.

3.2.2. 스케줄러 정책 파일 생성
링크 복사

원하는 서술자 및 우선순위로 JSON 파일을 생성하여 기본 예약 동작을 변경할 수 있습니다. 그런 다음 JSON 파일에서 구성 맵을 생성하고 이 구성 맵을 사용하도록 cluster 스케줄러 오브젝트를 가리킵니다.

프로세스

스케줄러 일정을 구성하려면 다음을 수행합니다.

  1. 원하는 서술자 및 우선순위를 사용하여 policy.cfg라는 JSON 파일을 생성합니다.

    스케줄러 JSON 파일 샘플

    {
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [
    1 
    
        {"name" : "MaxGCEPDVolumeCount"},
        {"name" : "GeneralPredicates"},
        {"name" : "MaxAzureDiskVolumeCount"},
        {"name" : "MaxCSIVolumeCountPred"},
        {"name" : "CheckVolumeBinding"},
        {"name" : "MaxEBSVolumeCount"},
        {"name" : "MatchInterPodAffinity"},
        {"name" : "CheckNodeUnschedulable"},
        {"name" : "NoDiskConflict"},
        {"name" : "NoVolumeZoneConflict"},
        {"name" : "PodToleratesNodeTaints"}
        ],
"priorities" : [
    2 
    
        {"name" : "LeastRequestedPriority", "weight" : 1},
        {"name" : "BalancedResourceAllocation", "weight" : 1},
        {"name" : "ServiceSpreadingPriority", "weight" : 1},
        {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
        {"name" : "NodeAffinityPriority", "weight" : 1},
        {"name" : "TaintTolerationPriority", "weight" : 1},
        {"name" : "ImageLocalityPriority", "weight" : 1},
        {"name" : "SelectorSpreadPriority", "weight" : 1},
        {"name" : "InterPodAffinityPriority", "weight" : 1},
        {"name" : "EqualPriority", "weight" : 1}
        ]
}
    Copy to Clipboard Toggle word wrap

    1
    필요한 경우 서술자를 추가합니다.
    2
    필요한 경우 우선순위를 추가합니다.

  2. 스케줄러 JSON 파일을 기반으로 구성 맵을 생성합니다. 

    $ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name>
    1
    Copy to Clipboard Toggle word wrap
    1
    구성 맵의 이름을 입력합니다.

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

    $ oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policy
    Copy to Clipboard Toggle word wrap

    출력 예

    configmap/scheduler-policy created
    Copy to Clipboard Toggle word wrap

  3. Scheduler Operator 사용자 정의 리소스를 편집하여 구성 맵을 추가합니다. 

    $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"<configmap-name>"}}}' --type=merge
    1
    Copy to Clipboard Toggle word wrap
    1
    구성 맵 이름을 지정합니다.

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

    $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"scheduler-policy"}}}' --type=merge
    Copy to Clipboard Toggle word wrap

    Scheduler 구성 리소스를 변경한 후 openshift-kube-apiserver Pod가 재배포될 때까지 기다립니다. 이 작업은 몇 분 정도 걸릴 수 있습니다. Pod가 재배포될 때까지 새 스케줄러가 적용되지 않습니다.

  4. openshift-kube-scheduler 네임스페이스에서 스케줄러 Pod의 로그를 확인하여 스케줄러 정책이 구성되었는지 확인합니다. 다음 명령은 스케줄러에서 등록하는 서술자 및 우선순위가 있는지 확인합니다. 

    $ oc logs <scheduler-pod> | grep predicates
    Copy to Clipboard Toggle word wrap

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

    $ oc logs openshift-kube-scheduler-ip-10-0-141-29.ec2.internal | grep predicates
    Copy to Clipboard Toggle word wrap

    출력 예

    Creating scheduler with fit predicates 'map[MaxGCEPDVolumeCount:{} MaxAzureDiskVolumeCount:{} CheckNodeUnschedulable:{} NoDiskConflict:{} NoVolumeZoneConflict:{} GeneralPredicates:{} MaxCSIVolumeCountPred:{} CheckVolumeBinding:{} MaxEBSVolumeCount:{} MatchInterPodAffinity:{} PodToleratesNodeTaints:{}]' and priority functions 'map[InterPodAffinityPriority:{} LeastRequestedPriority:{} ServiceSpreadingPriority:{} ImageLocalityPriority:{} SelectorSpreadPriority:{} EqualPriority:{} BalancedResourceAllocation:{} NodePreferAvoidPodsPriority:{} NodeAffinityPriority:{} TaintTolerationPriority:{}]'
    Copy to Clipboard Toggle word wrap

3.2.3. 스케줄러 정책 수정
링크 복사

openshift-config 프로젝트에서 스케줄러 정책 구성 맵을 생성하거나 편집하여 예약 동작을 변경합니다. 구성 맵에 서술자 및 우선순위를 추가하고 제거하여 스케줄러 정책을 생성합니다.

프로세스

현재 사용자 정의 예약을 수정하려면 다음 방법 중 하나를 사용합니다.

  • 스케줄러 정책 구성 맵을 편집합니다. 

    $ oc edit configmap <configmap-name>  -n openshift-config
    Copy to Clipboard Toggle word wrap

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

    $ oc edit configmap scheduler-policy -n openshift-config
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
data:
  policy.cfg: |
    {
        "kind" : "Policy",
        "apiVersion" : "v1",
        "predicates" : [
    1 
    
                {"name" : "MaxGCEPDVolumeCount"},
                {"name" : "GeneralPredicates"},
                {"name" : "MaxAzureDiskVolumeCount"},
                {"name" : "MaxCSIVolumeCountPred"},
                {"name" : "CheckVolumeBinding"},
                {"name" : "MaxEBSVolumeCount"},
                {"name" : "MatchInterPodAffinity"},
                {"name" : "CheckNodeUnschedulable"},
                {"name" : "NoDiskConflict"},
                {"name" : "NoVolumeZoneConflict"},
                {"name" : "PodToleratesNodeTaints"}
                ],
        "priorities" : [
    2 
    
                {"name" : "LeastRequestedPriority", "weight" : 1},
                {"name" : "BalancedResourceAllocation", "weight" : 1},
                {"name" : "ServiceSpreadingPriority", "weight" : 1},
                {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
                {"name" : "NodeAffinityPriority", "weight" : 1},
                {"name" : "TaintTolerationPriority", "weight" : 1},
                {"name" : "ImageLocalityPriority", "weight" : 1},
                {"name" : "SelectorSpreadPriority", "weight" : 1},
                {"name" : "InterPodAffinityPriority", "weight" : 1},
                {"name" : "EqualPriority", "weight" : 1}
                ]
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2019-09-17T17:44:19Z"
  name: scheduler-policy
  namespace: openshift-config
  resourceVersion: "15370"
  selfLink: /api/v1/namespaces/openshift-config/configmaps/scheduler-policy
    Copy to Clipboard Toggle word wrap

    1
    필요한 경우 서술자를 추가하거나 제거합니다.
    2
    필요한 경우 서술자를 추가, 제거 또는 변경합니다.

    스케줄러에서 업데이트된 정책을 사용하여 Pod를 재시작하는 데 몇 분 정도 걸릴 수 있습니다.

  • 사용 중인 정책 및 서술자를 변경합니다.

    1. 스케줄러 정책 구성 맵을 제거합니다. 

      $ oc delete configmap -n openshift-config <name>
      Copy to Clipboard Toggle word wrap

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

      $ oc delete configmap -n openshift-config  scheduler-policy
      Copy to Clipboard Toggle word wrap

    2. 필요한 경우 policy.cfg 파일을 편집하여 정책과 서술자를 추가 및 제거합니다.

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

      $ vi policy.cfg
      Copy to Clipboard Toggle word wrap

      출력 예

      apiVersion: v1
data:
  policy.cfg: |
    {
    "kind" : "Policy",
    "apiVersion" : "v1",
    "predicates" : [
            {"name" : "MaxGCEPDVolumeCount"},
            {"name" : "GeneralPredicates"},
            {"name" : "MaxAzureDiskVolumeCount"},
            {"name" : "MaxCSIVolumeCountPred"},
            {"name" : "CheckVolumeBinding"},
            {"name" : "MaxEBSVolumeCount"},
            {"name" : "MatchInterPodAffinity"},
            {"name" : "CheckNodeUnschedulable"},
            {"name" : "NoDiskConflict"},
            {"name" : "NoVolumeZoneConflict"},
            {"name" : "PodToleratesNodeTaints"}
            ],
    "priorities" : [
            {"name" : "LeastRequestedPriority", "weight" : 1},
            {"name" : "BalancedResourceAllocation", "weight" : 1},
            {"name" : "ServiceSpreadingPriority", "weight" : 1},
            {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
            {"name" : "NodeAffinityPriority", "weight" : 1},
            {"name" : "TaintTolerationPriority", "weight" : 1},
            {"name" : "ImageLocalityPriority", "weight" : 1},
            {"name" : "SelectorSpreadPriority", "weight" : 1},
            {"name" : "InterPodAffinityPriority", "weight" : 1},
            {"name" : "EqualPriority", "weight" : 1}
            ]
    }
      Copy to Clipboard Toggle word wrap

    3. 스케줄러 JSON 파일을 기반으로 스케줄러 정책 구성 맵을 다시 생성합니다. 

      $ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name>
      1
      Copy to Clipboard Toggle word wrap
      1
      구성 맵의 이름을 입력합니다.

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

      $ oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policy
      Copy to Clipboard Toggle word wrap

      출력 예

      configmap/scheduler-policy created
      Copy to Clipboard Toggle word wrap

3.2.3.1. 스케줄러 서술자 이해
링크 복사

서술자는 정규화되지 않은 노드를 필터링하는 규칙입니다.

OpenShift Container Platform에는 기본적으로 제공되는 몇 가지 서술자가 있습니다. 이러한 서술자 중 일부는 특정 매개변수를 제공하여 사용자 정의할 수 있습니다. 여러 개의 서술자를 결합하여 노드 필터링을 추가로 제공할 수도 있습니다.

3.2.3.1.1. 정적 서술자
링크 복사

이러한 서술자에는 구성 매개변수 또는 사용자 입력이 사용되지 않습니다. 대신 정확한 이름을 사용하여 스케줄러 구성에 지정됩니다.

3.2.3.1.1.1. 기본 서술자
링크 복사

기본 스케줄러 정책에는 다음과 같은 서술자가 포함됩니다.

NoVolumeZoneConflict 서술자는 Pod에서 요청하는 볼륨을 해당 영역에서 사용할 수 있는지 확인합니다. 

{"name" : "NoVolumeZoneConflict"}
Copy to Clipboard Toggle word wrap

MaxEBSVolumeCount 서술자는 AWS 인스턴스에 연결할 수 있는 최대 볼륨 수를 확인합니다. 

{"name" : "MaxEBSVolumeCount"}
Copy to Clipboard Toggle word wrap

MaxAzureDiskVolumeCount 서술자는 최대 Azure Disk 볼륨 수를 확인합니다. 

{"name" : "MaxAzureDiskVolumeCount"}
Copy to Clipboard Toggle word wrap

PodToleratesNodeTaints 서술자는 Pod에서 노드 테인트를 허용할 수 있는지 확인합니다. 

{"name" : "PodToleratesNodeTaints"}
Copy to Clipboard Toggle word wrap

CheckNodeUnschedulable 서술자는 Unschedulable 사양을 사용하여 노드에서 Pod를 예약할 수 있는지 확인합니다. 

{"name" : "CheckNodeUnschedulable"}
Copy to Clipboard Toggle word wrap

CheckVolumeBinding 서술자는 바인딩된 PVC 및 바인딩되지 않은 PVC 모두에 대해 요청하는 볼륨에 따라 Pod를 맞출 수 있는지 평가합니다.

  • 바인딩된 PVC의 경우 서술자는 해당 PV의 노드 유사성이 지정된 노드로 충족되는지 확인합니다.
  • 바인딩되지 않은 PVC의 경우 서술자는 PVC 요구 사항을 충족할 수 있는 사용 가능한 PV 및 지정된 노드로 PV 노드 유사성을 충족하는 사용 가능한 PV가 있는지 검색합니다.

서술자는 바인딩된 모든 PVC에 노드와 호환되는 PV가 있고 바인딩되지 않은 모든 PVC를 사용 가능하고 노드와 호환되는 PV와 연결할 수 있는 경우 True를 반환합니다. 

{"name" : "CheckVolumeBinding"}
Copy to Clipboard Toggle word wrap

NoDiskConflict 서술자는 Pod에서 요청한 볼륨을 사용할 수 있는지 확인합니다. 

{"name" : "NoDiskConflict"}
Copy to Clipboard Toggle word wrap

MaxGCEPDVolumeCount 서술자는 최대 GCE(Google Compute Engine) PD(영구 디스크) 수를 확인합니다. 

{"name" : "MaxGCEPDVolumeCount"}
Copy to Clipboard Toggle word wrap

MaxCSIVolumeCountPred 서술자는 노드에 연결해야 하는 CSI(Container Storage Interface) 볼륨 수와 해당 수가 구성된 제한을 초과하는지 여부를 결정합니다. 

{"name" : "MaxCSIVolumeCountPred"}
Copy to Clipboard Toggle word wrap

MatchInterPodAffinity 서술자는 Pod 유사성/유사성 방지 규칙에서 해당 Pod를 허용하는지 확인합니다. 

{"name" : "MatchInterPodAffinity"}
Copy to Clipboard Toggle word wrap
3.2.3.1.1.2. 기타 정적 서술자
링크 복사

OpenShift Container Platform에서는 다음과 같은 서술자도 지원합니다.

참고

조건별 노드 테인트 기능이 활성화된 경우 CheckNode-* 서술자를 사용할 수 없습니다. 조건별 노드 테인트 기능은 기본적으로 활성화되어 있습니다.

CheckNodeCondition 서술자는 디스크 없음, 네트워크 사용 불가 또는 준비되지 않음 상태를 보고하는 노드에 Pod를 예약할 수 있는지 확인합니다. 

{"name" : "CheckNodeCondition"}
Copy to Clipboard Toggle word wrap

CheckNodeLabelPresence 서술자는 해당 값과 관계없이 지정된 라벨이 모두 노드에 존재하는지 확인합니다. 

{"name" : "CheckNodeLabelPresence"}
Copy to Clipboard Toggle word wrap

checkServiceAffinity 서술자는 노드에 예약된 Pod에서 ServiceAffinity 라벨이 동종인지 확인합니다. 

{"name" : "checkServiceAffinity"}
Copy to Clipboard Toggle word wrap

PodToleratesNodeNoExecuteTaints 서술자는 Pod 허용 오차에서 노드 NoExecute 테인트를 허용할 수 있는지 확인합니다. 

{"name" : "PodToleratesNodeNoExecuteTaints"}
Copy to Clipboard Toggle word wrap
3.2.3.1.2. 일반 서술자
링크 복사

다음 일반 서술자는 중요하지 않은 서술자 및 필수 서술자의 전달 여부를 확인합니다. 중요하지 않은 서술자는 중요하지 않은 Pod에서만 전달해야 하는 서술자이고 필수 서술자는 모든 Pod에서 전달해야 하는 서술자입니다.

기본 스케줄러 정책에는 일반 서술자가 포함됩니다.

심각하지 않은 일반 서술자

PodFitsResources 서술자는 리소스 가용성(CPU, 메모리, GPU 등)에 따라 적합성을 결정합니다. 노드는 해당 리소스 용량을 선언할 수 있으며 Pod는 필요한 리소스를 지정할 수 있습니다. 적합성은 사용된 리소스가 아닌 요청된 리소스를 기반으로 합니다. 

{"name" : "PodFitsResources"}
Copy to Clipboard Toggle word wrap
필수 일반 서술자

PodFitsHostPorts 서술자는 노드에 요청된 Pod 포트에 사용할 수 있는 포트가 있는지 확인합니다(포트 충돌 없음). 

{"name" : "PodFitsHostPorts"}
Copy to Clipboard Toggle word wrap

HostName 서술자는 Host 매개변수의 존재 여부 및 호스트 이름과 일치하는 문자열에 따라 적합성을 결정합니다. 

{"name" : "HostName"}
Copy to Clipboard Toggle word wrap

MatchNodeSelector 서술자는 Pod에 정의된 노드 선택기(nodeSelector) 쿼리에 따라 적합성을 결정합니다. 

{"name" : "MatchNodeSelector"}
Copy to Clipboard Toggle word wrap
3.2.3.2. 스케줄러 우선순위 이해
링크 복사

우선순위는 기본 설정에 따라 노드의 순위를 정하는 규칙입니다.

스케줄러를 구성하기 위해 사용자 정의 우선순위 집합을 지정할 수 있습니다. OpenShift Container Platform에는 기본적으로 제공되는 몇 가지 우선순위가 있습니다. 특정 매개변수를 제공하여 기타 우선순위를 사용자 정의할 수 있습니다. 여러 우선순위를 결합하고 각각 서로 다른 가중치를 부여하여 우선순위 지정에 영향을 미칠 수 있습니다.

3.2.3.2.1. 정적 우선순위
링크 복사

정적 우선순위에는 가중치를 제외하고 사용자의 구성 매개변수가 사용되지 않습니다. 가중치를 지정해야 하며 0 또는 음수를 사용할 수 없습니다.

해당 값은 openshift-config 프로젝트의 스케줄러 정책 구성 맵에 지정됩니다.

3.2.3.2.1.1. 기본 우선순위
링크 복사

기본 스케줄러 정책에는 다음과 같은 우선순위가 포함됩니다. 가중치가 10000인 NodePreferAvoidPodsPriority를 제외하고 각 우선순위 함수의 가중치는 1입니다.

NodeAffinityPriority 우선순위는 노드 유사성 예약 설정에 따라 노드에 우선순위를 지정합니다. 

{"name" : "NodeAffinityPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

TaintTolerationPriority 우선순위는 Pod에 대해 허용 불가 테인트 수가 적은 노드에 우선순위를 지정합니다. 허용 불가 테인트에는 주요 PreferNoSchedule이 있습니다. 

{"name" : "TaintTolerationPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

ImageLocalityPriority 우선순위는 요청된 Pod 컨테이너의 이미지가 이미 있는 노드에 우선순위를 지정합니다. 

{"name" : "ImageLocalityPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

SelectorSpreadPriority 우선순위는 서비스, RC(복제 컨트롤러), RS(복제 세트), Pod와 일치하는 상태 저장 세트를 찾은 다음 해당 선택기와 일치하는 기존 Pod를 찾습니다. 스케줄러에서는 일치하는 기존 Pod가 적은 노드를 선호합니다. 그런 다음 Pod를 예약할 때 해당 선택기와 일치하는 Pod 수가 가장 적은 노드에 Pod를 예약합니다. 

{"name" : "SelectorSpreadPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

InterPodAffinityPriority 우선순위는 weightedPodAffinityTerm의 요소를 반복하고 해당 PodAffinityTerm이 해당 노드에서 충족되는 경우 합계에 가중치를 더하여 합계를 계산합니다. 합계가 가장 많은 노드를 가장 우선적으로 고려합니다. 

{"name" : "InterPodAffinityPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

LeastRequestedPriority 우선순위는 요청된 리소스가 적은 노드를 우선 고려합니다. 노드에 예약된 Pod에서 요청한 메모리 및 CPU의 백분율을 계산하고 사용 가능한/남은 용량이 가장 많은 노드에 우선순위를 부여합니다. 

{"name" : "LeastRequestedPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

BalancedResourceAllocation 우선순위는 리소스 사용률이 분산된 노드에 우선순위를 부여합니다. 사용한 CPU와 메모리 간의 차이를 용량의 일부로 계산하고 두 메트릭이 서로 얼마나 비슷한지에 따라 노드에 우선순위를 부여합니다. 이 우선순위는 항상 LeastRequestedPriority와 함께 사용해야 합니다. 

{"name" : "BalancedResourceAllocation", "weight" : 1}
Copy to Clipboard Toggle word wrap

NodePreferAvoidPodsPriority 우선순위는 복제 컨트롤러 이외의 컨트롤러에서 보유하는 Pod를 무시합니다. 

{"name" : "NodePreferAvoidPodsPriority", "weight" : 10000}
Copy to Clipboard Toggle word wrap
3.2.3.2.1.2. 기타 정적 우선순위
링크 복사

OpenShift Container Platform에서는 다음과 같은 우선순위도 지원합니다.

EqualPriority 우선순위는 우선순위 구성이 제공되지 않는 경우 모든 노드에 동일한 가중치인 1을 부여합니다. 이 우선순위는 테스트 환경에만 사용하는 것이 좋습니다. 

{"name" : "EqualPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

MostRequestedPriority 우선순위는 요청된 리소스가 가장 많은 노드에 우선순위를 부여합니다. 노드에 예약된 Pod에서 요청한 메모리와 CPU의 백분율을 계산하고 평균 용량 대비 요청 비율의 최댓값에 따라 우선순위를 부여합니다. 

{"name" : "MostRequestedPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap

ServiceSpreadingPriority 우선순위는 동일한 서비스에 속하는 Pod 수를 최소화하여 동일한 머신에 Pod를 분배합니다. 

{"name" : "ServiceSpreadingPriority", "weight" : 1}
Copy to Clipboard Toggle word wrap
3.2.3.2.2. 구성 가능한 우선순위
링크 복사

openshift-config 네임스페이스의 스케줄러 정책 구성 맵에 이러한 우선순위를 구성하여 우선순위가 작동하는 방식에 영향을 주는 라벨을 추가할 수 있습니다.

우선순위 함수의 유형은 사용하는 인수로 확인됩니다. 이러한 우선순위는 구성 가능하므로 사용자 정의 이름이 다른 경우 유형은 동일하지만 구성 매개변수는 다른 우선순위 여러 개를 결합할 수 있습니다.

이러한 우선순위 사용법에 대한 자세한 내용은 스케줄러 정책 수정을 참조하십시오.

ServiceAntiAffinity 우선순위는 라벨을 사용하며 해당 라벨 값에 따라 동일한 서비스에 속하는 Pod를 노드 그룹 전체에 적절하게 분배합니다. 지정된 라벨에 동일한 값이 있는 모든 노드에 동일한 점수를 부여합니다. Pod 밀도가 가장 낮은 그룹 내의 노드에 더 높은 점수를 부여합니다. 

{
"kind": "Policy",
"apiVersion": "v1",

"priorities":[
    {
        "name":"<name>",
1 

        "weight" : 1
2 

        "argument":{
            "serviceAntiAffinity":{
                "label": "<label>"
3 

                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap
1
우선순위의 이름을 지정합니다.
2
가중치를 지정합니다. 0이 아닌 양의 값을 입력합니다.
3
일치해야 하는 라벨을 지정합니다.

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

{
"kind": "Policy",
"apiVersion": "v1",
"priorities": [
    {
        "name":"RackSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "rack"
                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap
참고

일부 상황에서는 사용자 정의 라벨에 따라 ServiceAntiAffinity 매개변수를 사용해도 Pod가 예상대로 분배되지 않습니다. 이 Red Hat 솔루션을 참조하십시오.

labelPreference 매개변수는 지정된 라벨에 따라 우선순위를 지정합니다. 라벨이 노드에 있으면 해당 노드에 우선순위가 부여됩니다. 라벨이 지정되지 않은 경우 라벨이 없는 노드에 우선순위가 부여됩니다. labelPreference 매개변수를 사용하여 여러 개의 우선순위를 설정한 경우 모든 우선순위의 가중치가 같아야 합니다. 

{
"kind": "Policy",
"apiVersion": "v1",
"priorities":[
    {
        "name":"<name>",
1 

        "weight" : 1
2 

        "argument":{
            "labelPreference":{
                "label": "<label>",
3 

                "presence": true
4 

                }
            }
        }
    ]
}
Copy to Clipboard Toggle word wrap
1
우선순위의 이름을 지정합니다.
2
가중치를 지정합니다. 0이 아닌 양의 값을 입력합니다.
3
일치해야 하는 라벨을 지정합니다.
4
라벨이 필요한지의 여부를 true 또는 false 중 하나로 지정합니다.

3.2.4. 정책 구성 샘플
링크 복사

아래 구성에서는 스케줄러 정책 파일을 사용하여 지정한 것처럼 기본 스케줄러 구성을 지정합니다. 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RegionZoneAffinity",
1 

        "argument": {
            "serviceAffinity": {
2 

              "labels": ["region, zone"]
3 

           }
        }
     }
  ],
"priorities": [
    {
        "name":"RackSpread",
4 

        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
5 

                "label": "rack"
6 

                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap
1
서술자 이름입니다.
2
서술자 유형입니다.
3
서술자 라벨입니다.
4
우선순위 이름입니다.
5
우선순위 유형입니다.
6
우선순위 라벨입니다.

아래의 모든 샘플 구성에서 서술자 및 우선순위 함수 목록은 지정된 사용 사례와 관련된 항목만 포함하도록 잘립니다. 실제로 완료된/유의미한 스케줄러 정책에는 위에 나열된 기본 서술자 및 우선순위 전부는 아니더라도 대부분이 포함되어야 합니다.

다음 예제에서는 세 가지 토폴로지 수준, 즉 region(유사성) → zone(유사성) → rack(유사성 방지)을 정의합니다. 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RegionZoneAffinity",
        "argument": {
            "serviceAffinity": {
              "labels": ["region, zone"]
           }
        }
     }
  ],
"priorities": [
    {
        "name":"RackSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "rack"
                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap

다음 예제에서는 세 가지 토폴로지 수준, 즉 city(유사성) → building(유사성 방지) → room(유사성 방지)을 정의합니다. 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "CityAffinity",
        "argument": {
            "serviceAffinity": {
              "label": "city"
           }
        }
     }
  ],
"priorities": [
    {
        "name":"BuildingSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "building"
                }
           }
       },
    {
        "name":"RoomSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "room"
                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap

다음 예제에서는 'region' 라벨이 정의된 노드만 사용하고 'zone' 라벨이 정의된 노드를 선호하는 정책을 정의합니다. 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RequireRegion",
        "argument": {
            "labelPreference": {
                "labels": ["region"],
                "presence": true
           }
        }
     }
  ],
"priorities": [
    {
        "name":"ZonePreferred",
        "weight" : 1,
        "argument": {
            "labelPreference": {
                "label": "zone",
                "presence": true
                }
           }
       }
   ]
}
Copy to Clipboard Toggle word wrap

다음 예제에서는 정적 및 구성 가능 서술자와 우선순위를 둘 다 결합합니다. 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RegionAffinity",
        "argument": {
            "serviceAffinity": {
                "labels": ["region"]
           }
        }
     },
    {
        "name": "RequireRegion",
        "argument": {
            "labelsPresence": {
                "labels": ["region"],
                "presence": true
           }
        }
     },
    {
        "name": "BuildingNodesAvoid",
        "argument": {
            "labelsPresence": {
                "label": "building",
                "presence": false
           }
        }
     },
     {"name" : "PodFitsPorts"},
     {"name" : "MatchNodeSelector"}
     ],
"priorities": [
    {
        "name": "ZoneSpread",
        "weight" : 2,
        "argument": {
            "serviceAntiAffinity":{
                "label": "zone"
                }
           }
       },
    {
        "name":"ZonePreferred",
        "weight" : 1,
        "argument": {
            "labelPreference":{
                "label": "zone",
                "presence": true
                }
           }
       },
    {"name" : "ServiceSpreadingPriority", "weight" : 1}
    ]
}
Copy to Clipboard Toggle word wrap

유사성은 예약할 노드를 제어하는 Pod의 속성입니다. 유사성 방지는 Pod가 노드에서 예약되지 않도록 하는 Pod의 속성입니다.

OpenShift Container Platform에서 Pod 유사성 및 Pod 유사성 방지를 사용하면 다른 Pod의 키/값 라벨에 따라 Pod를 예약할 수 있는 노드를 제한할 수 있습니다.

3.3.1. Pod 유사성 이해
링크 복사

Pod 유사성 및 Pod 유사성 방지를 사용하면 다른 Pod의 키/값 라벨에 따라 Pod를 예약할 수 있는 노드를 제한할 수 있습니다.

  • Pod 유사성을 사용하면 새 Pod의 라벨 선택기가 현재 Pod의 라벨과 일치하는 경우 다른 Pod와 동일한 노드에서 새 Pod를 찾도록 스케줄러에 지시할 수 있습니다.
  • Pod 유사성 방지를 사용하면 새 Pod의 라벨 선택기가 현재 Pod의 라벨과 일치하는 경우 스케줄러에서 동일한 라벨을 사용하여 Pod와 동일한 노드에서 새 Pod를 찾지 않도록 할 수 있습니다.

예를 들어 유사성 규칙을 사용하여 서비스 내에서 또는 다른 서비스의 Pod와 관련하여 Pod를 분배하거나 패키징할 수 있습니다. 유사성 방지 규칙을 사용하면 특정 서비스의 Pod가 첫 번째 서비스의 Pod 성능을 방해하는 것으로 알려진 다른 서비스의 Pod와 동일한 노드에 예약되지 않도록 할 수 있습니다. 또는 서비스의 Pod를 노드 또는 가용성 영역에 분배하여 관련 오류를 줄일 수 있습니다.

Pod 유사성 규칙에는 필수 및 기본 두 가지의 유형이 있습니다.

노드에 Pod를 예약하려면 먼저 필수 규칙을 충족해야 합니다. 기본 규칙은 규칙이 충족되는 경우 스케줄러가 규칙을 적용하려고 하지만 반드시 적용되는 것은 아닙니다.

참고

Pod 우선순위 및 선점 설정에 따라 유사성 요구 사항을 위반하지 않으면 스케줄러에서 Pod에 적절한 노드를 찾지 못하는 경우가 있습니다. 이 경우 Pod를 예약하지 못할 수 있습니다.

이러한 상황을 방지하려면 우선순위가 같은 Pod를 사용하여 Pod 유사성을 신중하게 구성합니다.

Pod 사양 파일을 통해 Pod 유사성/유사성 방지를 구성합니다. 필수 규칙, 기본 규칙 또는 둘 다 지정할 수 있습니다. 둘 다 지정하는 경우 노드는 먼저 필수 규칙을 충족한 다음 기본 규칙을 충족하려고 합니다.

다음 예제에서는 Pod 유사성 및 유사성 방지를 위해 구성된 Pod 사양을 보여줍니다.

이 예제에서 Pod 유사성 규칙은 노드에 이미 실행 중인 Pod가 한 개 이상 있고 키가 security이고 값이 S1인 라벨이 있는 경우에만 노드에 Pod를 예약할 수 있음을 나타냅니다. Pod 유사성 방지 규칙은 노드에서 이미 Pod를 실행 중이고 키가 security이고 값이 S2인 라벨이 있는 경우 Pod를 노드에 예약하지 않는 것을 선호함을 나타냅니다.

Pod 유사성이 포함된 샘플 Pod 구성 파일

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
1 

      requiredDuringSchedulingIgnoredDuringExecution:
2 

      - labelSelector:
          matchExpressions:
          - key: security
3 

            operator: In
4 

            values:
            - S1
5 

        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod
Copy to Clipboard Toggle word wrap

1
Pod 유사성을 구성하는 스탠자입니다.
2
필요한 규칙을 정의합니다.
3 5
규칙을 적용하려면 일치해야 하는 키 및 값(라벨)입니다.
4
이 연산자는 기존 Pod의 라벨과 새 Pod 사양에 있는 matchExpression 매개변수의 값 집합 간의 관계를 나타냅니다. In, NotIn, Exists 또는 DoesNotExist일 수 있습니다.

Pod 유사성 방지가 포함된 샘플 Pod 구성 파일

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity:
1 

      preferredDuringSchedulingIgnoredDuringExecution:
2 

      - weight: 100
3 

        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
4 

              operator: In
5 

              values:
              - S2
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod
Copy to Clipboard Toggle word wrap

1
Pod 유사성 방지를 구성하는 스탠자입니다.
2
기본 규칙을 정의합니다.
3
기본 규칙의 가중치를 지정합니다. 가중치가 가장 높은 노드가 우선합니다.
4
유사성 방지 규칙이 적용되는 시기를 결정하는 Pod 라벨에 대한 설명입니다. 라벨의 키와 값을 지정합니다.
5
이 연산자는 기존 Pod의 라벨과 새 Pod 사양에 있는 matchExpression 매개변수의 값 집합 간의 관계를 나타냅니다. In, NotIn, Exists 또는 DoesNotExist일 수 있습니다.
참고

런타임 시 노드의 라벨이 변경되어 Pod의 유사성 규칙이 더 이상 충족되지 않는 경우 Pod가 노드에서 계속 실행됩니다.

3.3.2. Pod 유사성 규칙 구성
링크 복사

다음 단계에서는 라벨이 있는 Pod 및 유사성을 사용하여 해당 Pod에 예약할 수 있는 Pod를 생성하는 간단한 2-Pod 구성을 보여줍니다.

프로세스

  1. Pod 사양의 특정 라벨을 사용하여 Pod를 생성합니다. 

    $ cat team4.yaml
apiVersion: v1
kind: Pod
metadata:
  name: security-s1
  labels:
    security: S1
spec:
  containers:
  - name: security-s1
    image: docker.io/ocpqe/hello-pod
    Copy to Clipboard Toggle word wrap

  2. 다른 Pod를 생성할 때 Pod 사양을 다음과 같이 편집합니다.

    1. podAffinity 스탠자를 사용하여 requiredDuringSchedulingIgnoredDuringExecution 매개변수 또는 preferredDuringSchedulingIgnoredDuringExecution 매개변수를 구성합니다.

    2. 충족해야 하는 키와 값을 지정합니다. 새 Pod를 다른 Pod와 함께 예약하려면 첫 번째 Pod의 라벨과 동일한 key 및 value 매개변수를 사용합니다. 

          podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
      Copy to Clipboard Toggle word wrap
    3. operator를 지정합니다. 연산자는 In, NotIn, Exists 또는 DoesNotExist일 수 있습니다. 예를 들어 노드에 라벨이 있어야 하는 경우 연산자 In을 사용합니다.
    4. 이러한 토폴로지 도메인을 나타내기 위해 사용하며 미리 채워져 있는 Kubernetes 라벨인 topologyKey를 지정합니다.

  3. Pod를 생성합니다. 

    $ oc create -f <pod-spec>.yaml
    Copy to Clipboard Toggle word wrap

3.3.3. Pod 유사성 방지 규칙 구성
링크 복사

다음 단계에서는 라벨이 있는 Pod 및 유사성 방지 기본 규칙을 사용하여 해당 Pod에 예약하지 않는 Pod를 생성하는 간단한 2-Pod 구성을 보여줍니다.

프로세스

  1. Pod 사양의 특정 라벨을 사용하여 Pod를 생성합니다. 

    $ cat team4.yaml
apiVersion: v1
kind: Pod
metadata:
  name: security-s2
  labels:
    security: S2
spec:
  containers:
  - name: security-s2
    image: docker.io/ocpqe/hello-pod
    Copy to Clipboard Toggle word wrap
  2. 다른 Pod를 생성할 때 Pod 사양을 편집하여 다음 매개변수를 설정합니다.

  3. podAntiAffinity 스탠자를 사용하여 requiredDuringSchedulingIgnoredDuringExecution 매개변수 또는 preferredDuringSchedulingIgnoredDuringExecution 매개변수를 구성합니다.

    1. 노드의 가중치를 1~100으로 지정합니다. 가중치가 높은 노드가 우선합니다.

    2. 충족해야 하는 키와 값을 지정합니다. 새 Pod를 다른 Pod와 함께 예약하지 않으려면 첫 번째 Pod의 라벨과 동일한 key 및 value 매개변수를 사용합니다. 

          podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: kubernetes.io/hostname
      Copy to Clipboard Toggle word wrap
    3. 기본 규칙의 경우 1~100의 가중치를 지정합니다.
    4. operator를 지정합니다. 연산자는 In, NotIn, Exists 또는 DoesNotExist일 수 있습니다. 예를 들어 노드에 라벨이 있어야 하는 경우 연산자 In을 사용합니다.
  4. 이러한 토폴로지 도메인을 나타내기 위해 사용하며 미리 채워져 있는 Kubernetes 라벨인 topologyKey를 지정합니다.

  5. Pod를 생성합니다. 

    $ oc create -f <pod-spec>.yaml
    Copy to Clipboard Toggle word wrap

3.3.4. 샘플 Pod 유사성 및 유사성 방지 규칙
링크 복사

다음 예제에서는 Pod 유사성 및 Pod 유사성 방지를 보여줍니다.

3.3.4.1. Pod 유사성
링크 복사

다음 예제에서는 일치하는 라벨 및 라벨 선택기가 있는 Pod의 Pod 유사성을 보여줍니다.

  • Pod team4에는 라벨 team:4가 있습니다. 

    $ cat team4.yaml
apiVersion: v1
kind: Pod
metadata:
  name: team4
  labels:
     team: "4"
spec:
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod
    Copy to Clipboard Toggle word wrap

  • Pod team4a에는 podAffinity 아래에 라벨 선택기 team:4가 있습니다. 

    $ cat pod-team4a.yaml
apiVersion: v1
kind: Pod
metadata:
  name: team4a
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: team
            operator: In
            values:
            - "4"
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-affinity
    image: docker.io/ocpqe/hello-pod
    Copy to Clipboard Toggle word wrap
  • team4a Pod는 team4 Pod와 동일한 노드에 예약됩니다.
3.3.4.2. Pod 유사성 방지
링크 복사

다음 예제에서는 일치하는 라벨 및 라벨 선택기가 있는 Pod의 Pod 유사성 방지를 보여줍니다.

  • Pod pod-s1에는 라벨 security:s1이 있습니다. 

    cat pod-s1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
  labels:
    security: s1
spec:
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod
    Copy to Clipboard Toggle word wrap

  • Pod pod-s2에는 podAntiAffinity 아래에 라벨 선택기 security:s1이 있습니다. 

    cat pod-s2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s2
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - s1
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-antiaffinity
    image: docker.io/ocpqe/hello-pod
    Copy to Clipboard Toggle word wrap
  • Pod pod-s2는 pod-s1과 동일한 노드에 예약할 수 없습니다.
3.3.4.3. 일치하는 라벨이 없는 Pod 유사성
링크 복사

다음 예제에서는 일치하는 라벨 및 라벨 선택기가 없는 Pod의 Pod 유사성을 보여줍니다.

  • Pod pod-s1에는 라벨 security:s1이 있습니다. 

    $ cat pod-s1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
  labels:
    security: s1
spec:
  containers:
  - name: ocp
    image: docker.io/ocpqe/hello-pod
    Copy to Clipboard Toggle word wrap

  • Pod pod-s2에는 라벨 선택기 security:s2가 있습니다. 

    $ cat pod-s2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-s2
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - s2
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod-affinity
    image: docker.io/ocpqe/hello-pod
    Copy to Clipboard Toggle word wrap

  • security:s2 라벨이 있는 Pod가 포함된 노드가 없는 경우 Pod pod-s2는 예약되지 않습니다. 해당 라벨이 있는 기타 Pod가 없는 경우 새 Pod는 보류 중인 상태로 유지됩니다.

    출력 예

    NAME      READY     STATUS    RESTARTS   AGE       IP        NODE
pod-s2    0/1       Pending   0          32s       <none>
    Copy to Clipboard Toggle word wrap

3.4. 노드 유사성 규칙을 사용하여 노드에 대한 Pod 배치 제어
링크 복사

유사성은 예약할 노드를 제어하는 Pod의 속성입니다.

OpenShift Container Platform 노드 유사성은 스케줄러에서 Pod를 배치할 수 있는 위치를 결정하는 데 사용하는 규칙 집합입니다. 규칙은 노드의 사용자 정의 라벨과 Pod에 지정된 라벨 선택기를 사용하여 정의합니다.

3.4.1. 노드 유사성 이해
링크 복사

노드 유사성을 사용하면 Pod에서 Pod를 배치할 수 있는 노드 그룹에 대한 유사성을 지정할 수 있습니다. 노드는 배치를 제어할 수 없습니다.

예를 들어 특정 CPU 또는 특정 가용성 영역이 있는 노드에서만 실행하도록 Pod를 구성할 수 있습니다.

노드 유사성 규칙에는 필수 및 기본 두 가지의 유형이 있습니다.

노드에 Pod를 예약하려면 먼저 필수 규칙을 충족해야 합니다. 기본 규칙은 규칙이 충족되는 경우 스케줄러가 규칙을 적용하려고 하지만 반드시 적용되는 것은 아닙니다.

참고

노드의 라벨이 런타임에 변경되어 Pod에 대한 노드 유사성 규칙이 더 이상 충족되지 않으면 Pod가 해당 노드에서 계속 실행됩니다.

노드 유사성은 Pod 사양 파일을 통해 구성합니다. 필수 규칙, 기본 규칙 또는 둘 다 지정할 수 있습니다. 둘 다 지정하는 경우 노드는 먼저 필수 규칙을 충족한 다음 기본 규칙을 충족하려고 합니다.

다음 예제는 키가 e2e-az-NorthSouth이고 값이 e2e-az-North 또는 e2e-az-South인 라벨이 있는 노드에 Pod를 배치해야 하는 규칙이 있는 Pod 사양입니다.

노드 유사성 필수 규칙이 있는 Pod 구성 파일의 예

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
1 

      requiredDuringSchedulingIgnoredDuringExecution:
2 

        nodeSelectorTerms:
        - matchExpressions:
          - key: e2e-az-NorthSouth
3 

            operator: In
4 

            values:
            - e2e-az-North
5 

            - e2e-az-South
6 

  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod
Copy to Clipboard Toggle word wrap

1
노드 유사성을 구성하는 스탠자입니다.
2
필요한 규칙을 정의합니다.
3 5 6
규칙을 적용하려면 일치해야 하는 키/값(라벨)입니다.
4
연산자는 노드의 라벨과 Pod 사양에 있는 matchExpression 매개변수의 값 집합 간의 관계를 나타냅니다. 이 값은 In, NotIn, Exists, DoesNotExist, Lt 또는 Gt일 수 있습니다.

다음 예제는 Pod에 대해 키가 e2e-az-EastWest이고 값이 e2e-az-East 또는 e2e-az-West인 라벨이 있는 노드를 선호하는 기본 규칙이 있는 노드 사양입니다.

노드 유사성 기본 규칙이 있는 Pod 구성 파일의 예

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
1 

      preferredDuringSchedulingIgnoredDuringExecution:
2 

      - weight: 1
3 

        preference:
          matchExpressions:
          - key: e2e-az-EastWest
4 

            operator: In
5 

            values:
            - e2e-az-East
6 

            - e2e-az-West
7 

  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod
Copy to Clipboard Toggle word wrap

1
노드 유사성을 구성하는 스탠자입니다.
2
기본 규칙을 정의합니다.
3
기본 규칙의 가중치를 지정합니다. 가중치가 높은 노드가 우선합니다.
4 6 7
규칙을 적용하려면 일치해야 하는 키/값(라벨)입니다.
5
연산자는 노드의 라벨과 Pod 사양에 있는 matchExpression 매개변수의 값 집합 간의 관계를 나타냅니다. 이 값은 In, NotIn, Exists, DoesNotExist, Lt 또는 Gt일 수 있습니다.

명시적인 노드 유사성 방지 개념은 없지만 NotIn 또는 DoesNotExist 연산자를 사용하여 해당 동작을 복제합니다.

참고

노드 유사성 및 노드 선택기를 동일한 Pod 구성으로 사용하는 경우 다음 사항에 유의하십시오.

  • nodeSelector와 nodeAffinity를 둘 다 구성하는 경우 Pod를 후보 노드에 예약하기 위해서는 두 상태를 모두 충족해야 합니다.
  • nodeAffinity 유형과 연결된 nodeSelectorTerms를 여러 개 지정하는 경우 nodeSelectorTerms 중 하나를 충족하면 Pod를 노드에 예약할 수 있습니다.
  • nodeSelectorTerms와 연결된 matchExpressions를 여러 개 지정하는 경우 모든 matchExpressions를 충족할 때만 Pod를 노드에 예약할 수 있습니다.

3.4.2. 필수 노드 유사성 규칙 구성
링크 복사

노드에 Pod를 예약하려면 먼저 필수 규칙을 충족해야 합니다.

프로세스

다음 단계에서는 하나의 노드 및 스케줄러에서 해당 노드에 배치해야 하는 하나의 Pod를 생성하는 간단한 구성을 보여줍니다.

  1. oc label node 명령을 사용하여 노드에 라벨을 추가합니다. 

    $ oc label node node1 e2e-az-name=e2e-az1
    Copy to Clipboard Toggle word wrap

  2. Pod 사양에서 nodeAffinity 스탠자를 사용하여 requiredDuringSchedulingIgnoredDuringExecution 매개변수를 구성합니다.

    1. 충족해야 하는 키와 값을 지정합니다. 편집한 노드에 새 Pod를 예약하려면 노드의 라벨과 동일한 key 및 value 매개변수를 사용합니다.

    2. operator를 지정합니다. 연산자는 In, NotIn, Exists, DoesNotExist, Lt 또는 Gt일 수 있습니다. 예를 들어 노드에 라벨이 있어야 하는 경우 연산자 In을 사용합니다.

      출력 예

      spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      Copy to Clipboard Toggle word wrap

  3. Pod를 생성합니다. 

    $ oc create -f e2e-az2.yaml
    Copy to Clipboard Toggle word wrap

3.4.3. 기본 노드 유사성 규칙 구성
링크 복사

기본 규칙은 규칙이 충족되는 경우 스케줄러가 규칙을 적용하려고 하지만 반드시 적용되는 것은 아닙니다.

프로세스

다음 단계에서는 하나의 노드 및 스케줄러에서 해당 노드에 배치하려고 하는 하나의 Pod를 생성하는 간단한 구성을 보여줍니다.

  1. oc label node 명령을 사용하여 노드에 라벨을 추가합니다. 

    $ oc label node node1 e2e-az-name=e2e-az3
    Copy to Clipboard Toggle word wrap

  2. Pod 사양에서 nodeAffinity 스탠자를 사용하여 preferredDuringSchedulingIgnoredDuringExecution 매개변수를 구성합니다.

    1. 노드의 가중치를 숫자 1~100으로 지정합니다. 가중치가 높은 노드가 우선합니다.

    2. 충족해야 하는 키와 값을 지정합니다. 편집한 노드에 새 Pod를 예약하려면 노드의 라벨과 동일한 key 및 value 매개변수를 사용합니다. 

      spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: e2e-az-name
            operator: In
            values:
            - e2e-az3
      Copy to Clipboard Toggle word wrap
    3. operator를 지정합니다. 연산자는 In, NotIn, Exists, DoesNotExist, Lt 또는 Gt일 수 있습니다. 예를 들어 노드에 라벨이 있어야 하는 경우 연산자 In을 사용합니다.

  3. Pod를 생성합니다. 

    $ oc create -f e2e-az3.yaml
    Copy to Clipboard Toggle word wrap

3.4.4. 노드 유사성 규칙 샘플
링크 복사

다음 예제에서는 노드 유사성을 보여줍니다.

3.4.4.1. 일치하는 라벨이 있는 노드 유사성
링크 복사

다음 예제에서는 일치하는 라벨이 있는 노드 및 Pod의 노드 유사성을 보여줍니다.

  • Node1 노드에는 라벨 zone:us가 있습니다. 

    $ oc label node node1 zone=us
    Copy to Clipboard Toggle word wrap

  • pod-s1 Pod에는 필수 노드 유사성 규칙에 따라 zone 및 us 키/값 쌍이 있습니다. 

    $ cat pod-s1.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
spec:
  containers:
    - image: "docker.io/ocpqe/hello-pod"
      name: hello-pod
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
            - key: "zone"
              operator: In
              values:
              - us
    Copy to Clipboard Toggle word wrap

  • pod-s1 Pod를 Node1에 예약할 수 있습니다. 

    $ oc get pod -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME     READY     STATUS       RESTARTS   AGE      IP      NODE
pod-s1   1/1       Running      0          4m       IP1     node1
    Copy to Clipboard Toggle word wrap

3.4.4.2. 일치하는 라벨이 없는 노드 유사성
링크 복사

다음 예제에서는 일치하는 라벨이 없는 노드 및 Pod의 노드 유사성을 보여줍니다.

  • Node1 노드에는 라벨 zone:emea가 있습니다. 

    $ oc label node node1 zone=emea
    Copy to Clipboard Toggle word wrap

  • pod-s1 Pod에는 필수 노드 유사성 규칙에 따라 zone 및 us 키/값 쌍이 있습니다. 

    $ cat pod-s1.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
kind: Pod
metadata:
  name: pod-s1
spec:
  containers:
    - image: "docker.io/ocpqe/hello-pod"
      name: hello-pod
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
            - key: "zone"
              operator: In
              values:
              - us
    Copy to Clipboard Toggle word wrap

  • pod-s1 Pod는 Node1에 예약할 수 없습니다. 

    $ oc describe pod pod-s1
    Copy to Clipboard Toggle word wrap

    출력 예

    ...

Events:
 FirstSeen LastSeen Count From              SubObjectPath  Type                Reason
 --------- -------- ----- ----              -------------  --------            ------
 1m        33s      8     default-scheduler Warning        FailedScheduling    No nodes are available that match all of the following predicates:: MatchNodeSelector (1).
    Copy to Clipboard Toggle word wrap

3.5. 과다 할당된 노드에 Pod 배치
링크 복사

과다 할당 상태에서는 컨테이너 컴퓨팅 리소스 요청과 제한의 합이 시스템에서 사용 가능한 리소스를 초과합니다. 용량에 맞게 보장된 성능을 절충할 수 있는 개발 환경에서는 과다 할당이 바람직할 수 있습니다.

관리자는 요청 및 제한을 통해 노드의 리소스 과다 할당을 허용하고 관리할 수 있습니다. 스케줄러는 요청을 사용하여 컨테이너를 예약하고 최소 서비스 보장 기능을 제공합니다. 제한은 노드에서 사용할 수 있는 컴퓨팅 리소스의 양을 제한합니다.

3.5.1. 과다 할당 이해
링크 복사

관리자는 요청 및 제한을 통해 노드의 리소스 과다 할당을 허용하고 관리할 수 있습니다. 스케줄러는 요청을 사용하여 컨테이너를 예약하고 최소 서비스 보장 기능을 제공합니다. 제한은 노드에서 사용할 수 있는 컴퓨팅 리소스의 양을 제한합니다.

OpenShift Container Platform 관리자는 개발자 컨테이너에 설정된 요청과 제한 사이의 비율을 덮어쓰도록 마스터를 구성하여 노드에서 과다 할당 수준을 제어하고 컨테이너 밀도를 관리할 수 있습니다. 제한 및 기본값을 지정하는 프로젝트별 LimitRange 오브젝트와 함께 컨테이너 제한 및 요청을 조정하여 원하는 수준의 과다 할당을 구현합니다.

참고

컨테이너에 제한이 설정되어 있지 않은 경우 이러한 덮어쓰기가 적용되지 않습니다. 덮어쓰기를 적용하려면 개별 프로젝트별로 또는 프로젝트 템플릿에 기본 제한을 사용하여 LimitRange 오브젝트를 생성합니다.

이러한 덮어쓰기 이후에도 프로젝트의 모든 LimitRange 오브젝트에서 컨테이너 제한 및 요청의 유효성을 검사해야 합니다. 예를 들어 개발자가 최소 제한에 가까운 제한을 지정하고 요청에서 최소 제한 미만을 덮어쓰도록 하여 Pod를 금지할 수 있습니다. 이처럼 잘못된 사용자 경험은 향후 작업에서 해결해야 하지만 현재는 이 기능과 LimitRange 오브젝트를 주의해서 구성하십시오.

3.5.2. 노드 과다 할당 이해
링크 복사

오버 커밋된 환경에서는 최상의 시스템 동작을 제공하도록 노드를 올바르게 구성하는 것이 중요합니다.

노드가 시작되면 메모리 관리를 위한 커널 조정 가능한 플래그가 올바르게 설정됩니다. 커널은 실제 메모리가 소진되지 않는 한 메모리 할당에 실패해서는 안됩니다.

이 동작을 확인하기 위해 OpenShift Container Platform은 vm.overcommit_memory 매개변수를 1로 설정하여 기본 운영 체제 설정을 재정의하여 커널이 항상 메모리를 오버 커밋하도록 구성합니다.

OpenShift Container Platform은 vm.panic_on_oom 매개변수를 0으로 설정하여 메모리 부족시 커널이 패닉 상태가되지 않도록 구성합니다. 0으로 설정하면 커널에서 OOM (메모리 부족) 상태일 때 oom_killer를 호출하여 우선 순위에 따라 프로세스를 종료합니다.

노드에서 다음 명령을 실행하여 현재 설정을 볼 수 있습니다. 

$ sysctl -a |grep commit
Copy to Clipboard Toggle word wrap

출력 예

vm.overcommit_memory = 1
Copy to Clipboard Toggle word wrap 

$ sysctl -a |grep panic
Copy to Clipboard Toggle word wrap

출력 예

vm.panic_on_oom = 0
Copy to Clipboard Toggle word wrap

참고

위의 플래그는 이미 노드에 설정되어 있어야하며 추가 조치가 필요하지 않습니다.

각 노드에 대해 다음 구성을 수행할 수도 있습니다.

  • CPU CFS 할당량을 사용하여 CPU 제한 비활성화 또는 실행
  • 시스템 프로세스의 리소스 예약
  • Quality of Service (QoS) 계층에서의 메모리 예약

3.6. 노드 테인트를 사용하여 Pod 배치 제어
링크 복사

테인트 및 허용 오차를 사용하면 노드에서 예약해야 하는 (또는 예약해서는 안 되는) Pod를 제어할 수 있습니다.

3.6.1. 테인트(Taints) 및 톨러레이션(Tolerations)의 이해
링크 복사

테인트를 사용하면 Pod에 일치하는 허용 오차가 없는 경우 노드에서 Pod 예약을 거부할 수 있습니다.

Node 사양(NodeSpec)을 통해 노드에 테인트를 적용하고 Pod 사양(PodSpec)을 통해 Pod에 허용 오차를 적용합니다. 노드에 테인트를 적용할 때 Pod에서 테인트를 허용할 수 없는 경우 스케줄러에서 해당 노드에 Pod를 배치할 수 없습니다.

노드 사양의 테인트 예

spec:
....
  template:
....
    spec:
      taints:
      - effect: NoExecute
        key: key1
        value: value1
....
Copy to Clipboard Toggle word wrap

Pod 사양의 허용 오차 예

spec:
....
  template:
....
    spec:
      tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoExecute"
        tolerationSeconds: 3600
....
Copy to Clipboard Toggle word wrap

테인트 및 톨러레이션은 key, value 및 effect로 구성되어 있습니다.

Expand
표 3.1. 테인트 및 톨러레이션 구성 요소
매개변수설명

key

key는 최대 253 자의 문자열입니다. 키는 문자 또는 숫자로 시작해야 하며 문자, 숫자, 하이픈, 점, 밑줄을 포함할 수 있습니다.

value

value는 최대 63 자의 문자열입니다. 값은 문자 또는 숫자로 시작해야 하며 문자, 숫자, 하이픈, 점, 밑줄을 포함할 수 있습니다.

effect

다음 명령 중 하나를 실행합니다.

Expand

NoSchedule [1]

  • 테인트에 일치하지 않는 새 pod는 해당 노드에 예약되지 않습니다.
  • 노드의 기존 pod는 그대로 유지됩니다.

PreferNoSchedule

  • 테인트와 일치하지 않는 새 pod는 해당 노드에 예약할 수 있지만 스케줄러는 그렇게하지 않습니다.
  • 노드의 기존 pod는 그대로 유지됩니다.

NoExecute

  • 테인트에 일치하지 않는 새 pod는 해당 노드에 예약할 수 없습니다.
  • 일치하는 톨러레이션이 없는 노드의 기존 pod는 제거됩니다.

operator

Expand

Equal

key/value/effect 매개변수가 일치해야합니다. 이는 기본값입니다.

Exists

key/effect 매개변수가 일치해야합니다. 일치하는 빈 value 매개변수를 남겨 두어야합니다.

  1. 컨트롤 플레인 노드 (마스터 노드라고도 함)에 NoSchedule 테인트를 추가하는 경우 노드에 기본적으로 추가되는 node-role.kubernetes.io/master=:NoSchedule 테인트가 있어야 합니다.

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

    apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
...
    Copy to Clipboard Toggle word wrap

톨러레이션은 테인트와 일치합니다.

  • operator 매개변수가 Equal로 설정된 경우:

    • key 매개변수는 동일합니다.
    • value 매개변수는 동일합니다.
    • effect 매개변수는 동일합니다.

  • operator 매개변수가 Exists로 설정된 경우:

    • key 매개변수는 동일합니다.
    • effect 매개변수는 동일합니다.

다음 테인트는 OpenShift Container Platform에 빌드됩니다.

  • node.kubernetes.io/not-ready: 노드가 준비되지 않았습니다. 이는 노드 조건 Ready=False에 해당합니다.
  • node.kubernetes.io/unreachable: 노드 컨트롤러에서 노드에 연결할 수 없습니다. 이는 노드 조건 Ready=Unknown에 해당합니다.
  • node.kubernetes.io/memory-pressure: 노드에는 메모리 부족 문제가 있습니다. 이는 노드 조건 MemoryPressure=True에 해당합니다.
  • node.kubernetes.io/disk-pressure: 노드에는 디스크 부족 문제가 있습니다. 이는 노드 조건 DiskPressure=True에 해당합니다.
  • node.kubernetes.io/network-unavailable: 노드 네트워크를 사용할 수 없습니다.
  • node.kubernetes.io/unschedulable: 노드를 예약할 수 없습니다.
  • node.cloudprovider.kubernetes.io/uninitialized: 노드 컨트롤러가 외부 클라우드 공급자로 시작되면 이 테인트는 노드에 설정되어 이를 사용할 수 없음으로 표시합니다. cloud-controller-manager의 컨트롤러가 이 노드를 초기화하면 kubelet이 이 테인트를 제거합니다.

  • node.kubernetes.io/pid-pressure: 노드에는 pid 부하가 있습니다. 이는 노드 조건 PIDPressure=True 에 해당합니다.

    중요

    OpenShift Container Platform은 기본 pid.available evictionHard 를 설정하지 않습니다.

3.6.1.1. tolerationSeconds를 사용하여 pod 제거를 지연하는 방법
링크 복사

Pod 사양 또는 MachineSet 오브젝트에 tolerationSeconds 매개변수를 지정하면 Pod를 제거하기 전에 노드에 바인딩되는 시간을 지정할 수 있습니다. NoExecute 효과가 있는 테인트가 tolerationSeconds 매개변수가 있는 테인트를 허용하는 Pod인 노드에 추가되면 해당 기간이 만료될 때까지 Pod가 제거되지 않습니다.

출력 예

spec:
....
  template:
....
    spec:
      tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoExecute"
        tolerationSeconds: 3600
Copy to Clipboard Toggle word wrap

여기에서 이 Pod가 실행 중이지만 일치하는 허용 오차가 없으면 Pod는 3,600초 동안 노드에 바인딩된 후 제거됩니다. 이 시간 이전에 테인트가 제거되면 pod가 제거되지 않습니다.

3.6.1.2. 여러 테인트를 사용하는 방법
링크 복사

동일한 노드에 여러 테인트를 배치하고 동일한 pod에 여러 톨러레이션을 배치할 수 있습니다. OpenShift Container Platform은 다음과 같이 여러 테인트 및 톨러레이션을 처리합니다.

  1. Pod에 일치하는 톨러레이션이 있는 테인트를 처리합니다.

  2. 나머지 일치하지 테인트는 pod에서 다음 effect를 갖습니다.

    • effect가 NoSchedule인 일치하지 않는 테인트가 하나 이상있는 경우 OpenShift Container Platform은 해당 노드에 pod를 예약할 수 없습니다.
    • effect가 NoSchedule인 일치하지 않는 테인트가 없지만 effect가 PreferNoSchedule인 일치하지 않는 테인트가 하나 이상있는 경우, OpenShift 컨테이너 플랫폼은 노드에 pod를 예약 시도하지 않습니다.

    • 효과가 NoExecute인 일치하지 않는 테인트가 하나 이상 있는 경우 OpenShift Container Platform은 Pod가 노드에서 이미 실행되고 있으면 노드에서 Pod를 제거합니다. Pod가 노드에서 아직 실행되고 있지 않으면 Pod가 노드에 예약되지 않습니다.

      • 테인트를 허용하지 Pod는 즉시 제거됩니다.
      • Pod 사양에 tolerationSeconds를 지정하지 않은 테인트를 허용하는 Pod는 영구적으로 바인딩된 상태를 유지합니다.
      • tolerationSeconds가 지정된 테인트를 허용하는 Pod는 지정된 시간 동안 바인딩된 상태로 유지됩니다.

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

  • 노드에 다음 테인트를 추가합니다. 

    $ oc adm taint nodes node1 key1=value1:NoSchedule
    Copy to Clipboard Toggle word wrap 
    $ oc adm taint nodes node1 key1=value1:NoExecute
    Copy to Clipboard Toggle word wrap 
    $ oc adm taint nodes node1 key2=value2:NoSchedule
    Copy to Clipboard Toggle word wrap

  • Pod에는 다음과 같은 톨러레이션이 있습니다. 

    spec:
....
  template:
....
    spec:
      tolerations:
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoExecute"
    Copy to Clipboard Toggle word wrap

이 경우 세 번째 테인트와 일치하는 톨러레이션이 없기 때문에 pod를 노드에 예약할 수 없습니다. 세 번째 테인트는 pod에서 허용되지 않는 세 번째 테인트 중 하나이기 때문에 테인트가 추가될 때 노드에서 이미 실행되고 있는 경우 pod가 계속 실행됩니다.

3.6.1.3. Pod 예약 및 노드 상태 (taint node by condition)
링크 복사

상태별 노드 테인트 기능은 기본적으로 활성화되어 있으며 메모리 부족 및 디스크 부족과 같은 상태를 보고하는 노드를 자동으로 테인트합니다. 노드가 상태를 보고하면 상태가 해제될 때까지 테인트가 추가됩니다. 테인트에는 NoSchedule effect가 있습니다. 즉, pod에 일치하는 톨러레이션이 없으면 노드에서 pod를 예약할 수 없습니다.

스케줄러는 pod를 예약하기 전에 노드에서 이러한 테인트를 확인합니다. 테인트가 있는 경우 pod는 다른 노드에 예약됩니다. 스케줄러는 실제 노드 상태가 아닌 테인트를 확인하기 때문에 적절한 pod 톨러레이션을 추가하여 이러한 노드 상태 중 일부를 무시하도록 스케줄러를 구성합니다.

이전 버전과의 호환성을 보장하기 위해 데몬 세트 컨트롤러는 모든 데몬에 다음과 같은 허용 오차를 자동으로 추가합니다.

  • node.kubernetes.io/memory-pressure
  • node.kubernetes.io/disk-pressure
  • node.kubernetes.io/unschedulable (1.10 이상)
  • node.kubernetes.io/network-unavailable (호스트 네트워크 만)

데몬 세트에 임의의 허용 오차를 추가할 수 있습니다.

참고

컨트롤 플레인은 QoS 클래스가 있는 Pod에 node.kubernetes.io/memory-pressure 허용 오차를 추가합니다. 이는 Kubernetes가 Guaranteed 또는 Burstable QoS 클래스에서 Pod를 관리하기 때문입니다. 새 BestEffort Pod가 영향을 받는 노드에 예약되지 않습니다.

3.6.1.4. 상태 별 pod 제거 (taint-based evictions)
링크 복사

기본적으로 활성화된 Taint-Based Evictions 기능은 not-ready 및 unreachable과 같은 특정 상태에 있는 노드에서 Pod를 제거합니다. 노드에 이러한 상태 중 하나가 발생하면 OpenShift Container Platform은 자동으로 노드에 테인트를 추가하고 pod를 제거하여 다른 도드에서 다시 예약하기 시작합니다.

Taint Based Evictions에는 NoExecute 효과가 있으며, 여기서 테인트를 허용하지 않는 Pod는 즉시 제거되고 테인트를 허용하는 모든 Pod는 tolerationSeconds 매개변수를 사용하지 않는 한 제거되지 않습니다.

tolerationSeconds 매개변수를 사용하면 노드 조건이 설정된 노드에 Pod가 바인딩되는 기간을 지정할 수 있습니다. tolerationSeconds 기간 후에도 이 상태가 계속되면 테인트가 노드에 남아 있고 허용 오차가 일치하는 Pod가 제거됩니다. tolerationSeconds 기간 전에 상태 조건이 지워지면 허용 오차가 일치하는 Pod가 제거되지 않습니다.

값이 없는 tolerationSeconds 매개변수를 사용하는 경우 준비되지 않고 연결할 수 없는 노드 상태로 인해 Pod가 제거되지 않습니다.

참고

OpenShift Container Platform은 속도가 제한된 방식으로 pod를 제거하여 마스터가 노드에서 분할되는 등의 시나리오에서 대규모 pod 제거를 방지합니다.

기본적으로 지정된 영역에서 노드의 55% 이상이 비정상이면 노드 라이프사이클 컨트롤러는 해당 영역의 상태를 PartialDisruption 으로 변경하고 Pod 제거 속도가 줄어듭니다. 이 상태에서 소규모 클러스터(기본값 50개 이하)의 경우 이 영역의 노드가 테인트되지 않고 제거가 중지됩니다.

자세한 내용은 Kubernetes 문서 의 제거 요금 제한을 참조하십시오.

Pod 구성에서 허용 오차를 지정하지 않는 경우 OpenShift Container Platform은 자동으로 node.kubernetes.io/not-ready 및 node.kubernetes.io/unreachable의 허용 오차를 tolerationSeconds=300으로 추가합니다. 

spec:
....
  template:
....
    spec:
      tolerations:
      - key: node.kubernetes.io/not-ready
        operator: Exists
        effect: NoExecute
        tolerationSeconds: 300
1 

      - key: node.kubernetes.io/unreachable
        operator: Exists
        effect: NoExecute
        tolerationSeconds: 300
Copy to Clipboard Toggle word wrap
1
이러한 톨러레이션은 이러한 노드 상태 문제 중 하나가 감지된 후 기본 pod 동작을 5 분 동안 바인딩된 상태로 유지할 수 있도록 합니다.

필요에 따라 이러한 톨러레이션을 구성할 수 있습니다. 예를 들어 애플리케이션에 다수의 로컬 상태가 있는 경우 네트워크 파티션 등에 따라 pod를 노드에 더 오래 바인딩하여 파티션을 복구하고 pod 제거를 방지할 수 있습니다.

데몬 세트에 의해 생성된 Pod는 tolerationSeconds가 없는 다음 테인트의 NoExecute 허용 오차를 사용하여 생성됩니다.

  • node.kubernetes.io/unreachable
  • node.kubernetes.io/not-ready

결과적으로 이러한 노드 상태로 인해 데몬 세트 Pod가 제거되지 않습니다.

3.6.1.5. 모든 테인트 허용
링크 복사

operator를 추가하여 모든 테인트를 허용하도록 Pod를 구성할 수 있습니다. "exists" key 및 value 매개변수가 없는 허용 오차. 이 허용 오차가 있는 Pod는 테인트가 있는 노드에서 제거되지 않습니다.

모든 테인트를 허용하는 Pod 사양

spec:
....
  template:
....
    spec:
      tolerations:
      - operator: "Exists"
Copy to Clipboard Toggle word wrap

3.6.2. 테인트 및 톨러레이션 추가
링크 복사

Pod에 허용 오차를 추가하고 노드에 테인트를 추가하면 노드에 예약하거나 예약하지 않아야 하는 Pod를 노드에서 제어할 수 있습니다. 기존 Pod 및 노드의 경우 먼저 Pod에 허용 오차를 추가한 다음 노드에 테인트를 추가하여 허용 오차를 추가하기 전에 노드에서 Pod가 제거되지 않도록 합니다.

프로세스

  1. tolerations 스탠자를 포함하도록 Pod 사양을 편집하여 Pod에 허용 오차를 추가합니다.

    Equal 연산자가 있는 Pod 구성 파일 샘플

    spec:
....
  template:
....
    spec:
      tolerations:
      - key: "key1"
    1 
    
        value: "value1"
        operator: "Equal"
        effect: "NoExecute"
        tolerationSeconds: 3600
    2
    Copy to Clipboard