노드

읽기 작업을 사용하면 관리자 또는 개발자가 OpenShift Dedicated 클러스터의 노드에 대한 정보를 가져올 수 있습니다.

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

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

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

OpenShift Dedicated에서 사용할 수 있는 다양한 툴 및 기능의 도움을 통해 Pod를 보다 쉽고 효율적으로 사용할 수 있습니다. 다음 작업에는 Pod를 더 잘 관리하기 위해 해당 툴과 기능을 사용하는 작업이 포함됩니다.

OpenShift Dedicated에서 애플리케이션 컨테이너를 실행하고 관리하려면 pod를 사용해야 합니다. Pod를 사용하면 여러 컨테이너가 단일 호스트에서 동일한 네트워크 및 스토리지 리소스를 공유할 수 있습니다.

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

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

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

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

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

kind: Pod
apiVersion: v1
metadata:
  name: example
  labels:
    environment: production
    app: abc
spec:
  restartPolicy: Always
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: abc
      args:
      - sleep
      - "1000000"
      volumeMounts:
       - name: cache-volume
         mountPath: /cache
      image: registry.access.redhat.com/ubi7/ubi-init:latest
      securityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          memory: "100Mi"
          cpu: "1"
        requests:
          memory: "100Mi"
          cpu: "1"
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi

다음과 같습니다.

애플리케이션에서 컴퓨팅 리소스를 사용하는 방법을 관리하려면 Pod 사양에서 CPU 및 메모리 요청 및 제한을 정의할 수 있습니다. 요청에서는 예약에 필요한 최소 리소스 양을 보장합니다. 여기서 제한으로 인해 컨테이너가 노드의 다른 Pod에 영향을 줄 수 있는 과도한 리소스를 사용하지 못하게 합니다.

CPU 및 메모리 요청 은 Pod를 실행해야 하는 최소한의 리소스를 지정하여 OpenShift Dedicated에서 충분한 리소스가 있는 노드에서 Pod를 예약할 수 있도록 지원합니다.

CPU 및 메모리 제한은 Pod에서 사용할 수 있는 최대 리소스 양을 정의하여 Pod에서 과도한 리소스를 소비하지 않고 동일한 노드의 다른 Pod에 영향을 미칠 수 있습니다.

CPU 및 메모리 요청 및 제한은 다음 원칙을 사용하여 처리됩니다.

Pod가 실행 중인 노드에 사용 가능한 리소스가 충분한 경우 컨테이너에서 요청한 것보다 더 많은 CPU 또는 메모리 리소스를 사용할 수 있습니다. 그러나 컨테이너는 해당 제한을 초과할 수 없습니다. 예를 들어 컨테이너 메모리 요청을 256MiB 로 설정하고 해당 컨테이너가 8GiB 메모리가 있는 노드에 예약되고 다른 Pod가 없는 Pod에 있는 경우 컨테이너에서 요청된 256MiB 보다 많은 메모리를 사용하려고 시도할 수 있습니다.

이 동작은 CPU 및 메모리 제한에는 적용되지 않습니다. 이러한 제한은 kubelet 및 컨테이너 런타임에 의해 적용되며 커널에 의해 적용됩니다. Linux 노드에서 커널은 cgroup을 사용하여 제한을 적용합니다.

CPU, 메모리, 스토리지 사용량과 같은 Pod 사용량 통계를 표시하여 컨테이너 런타임 환경을 모니터링하고 리소스 효율적인 사용을 보장할 수 있습니다.

Pod 문제를 해결하고 OpenShift Dedicated에서 Pod에 대한 자세한 정보를 보려면 oc describe pod 명령을 사용하여 Pod를 설명할 수 있습니다. 출력의 Events 섹션에서는 Pod 및 컨테이너 내부의 컨테이너에 대한 자세한 정보를 제공합니다.

CPU, 메모리 및 스토리지 사용을 포함하여 Pod에 대한 사용량 통계를 표시할 수 있습니다. Pod 사용량 수준을 모니터링하면 효율적인 리소스 사용을 보장할 수 있습니다.

OpenShift CLI(oc) 또는 웹 콘솔에서 리소스의 로그를 볼 수 있습니다. 리소스의 로그를 보면 문제를 해결하고 리소스 동작을 모니터링할 수 있습니다.

로그는 기본적으로 끝(또는 tail)에서 표시됩니다.

해당 Pod의 컨테이너가 종료될 때 OpenShift Dedicated가 응답하는 방식을 결정하도록 Pod 재시작 정책을 구성할 수 있습니다. 적절한 재시작 정책을 사용하면 클러스터를 효율적으로 실행할 수 있습니다.

정책은 해당 Pod의 모든 컨테이너에 적용됩니다.

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

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

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

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

OpenShift Dedicated에서 실패한 컨테이너와 함께 재시작 정책을 사용하는 방법에 대한 자세한 내용은 Kubernetes 문서의 "예"를 참조하십시오.

Pod에 서비스 품질 트래픽 조절 기능을 적용하고 사용 가능한 대역폭을 효과적으로 제한할 수 있습니다.

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

다음 절차에서는 Pod의 대역폭을 제한합니다.

노드 유지보수 또는 클러스터 업데이트와 같은 자발적으로 중단되는 동안 Pod 가용성을 보장하기 위해 Pod 중단 예산을 사용하여 애플리케이션의 안전 제약 조건을 정의할 수 있습니다.

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

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

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

$ oc get poddisruptionbudget --all-namespaces

NAMESPACE                              NAME                                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
openshift-apiserver                    openshift-apiserver-pdb                 N/A             1                 1                     121m
openshift-cloud-controller-manager     aws-cloud-controller-manager            1               N/A               1                     125m
openshift-cloud-credential-operator    pod-identity-webhook                    1               N/A               1                     117m
openshift-cluster-csi-drivers          aws-ebs-csi-driver-controller-pdb       N/A             1                 1                     121m
openshift-cluster-storage-operator     csi-snapshot-controller-pdb             N/A             1                 1                     122m
openshift-cluster-storage-operator     csi-snapshot-webhook-pdb                N/A             1                 1                     122m
openshift-console                      console                                 N/A             1                 1                     116m
#...

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

볼륨 플러그인을 사용하여 컨테이너에 보안을 마운트하거나 시스템에서 보안을 사용하여 Pod 대신 작업을 수행할 수 있습니다.

Secret 오브젝트 유형은 암호, OpenShift Dedicated 클라이언트 구성 파일, 개인 소스 리포지토리 자격 증명 등과 같은 중요한 정보를 보유하는 메커니즘을 제공합니다. 보안은 Pod에서 중요한 콘텐츠를 분리합니다.

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

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque
data:
  username: <username>
  password: <password>
stringData:
  hostname: myapp.mydomain.com

다음과 같습니다.

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

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

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

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

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

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

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

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

시크릿의 값을 업데이트하려면 해당 보안을 사용하는 Pod를 다시 생성해야 합니다. 실행 중인 Pod는 보안 데이터에 대한 변경 사항을 자동으로 감지하지 않으므로 Pod를 다시 시작하면 업데이트된 구성을 사용할 수 있습니다.

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

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

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

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

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

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

registry-cert 를 인증서의 이름으로 교체

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

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

보안 작업에 대한 문제 해결 팁은 다음 정보를 검토하십시오.

서비스 인증서 생성에 실패하는 경우 (서비스의 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

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

다음 섹션을 검토하여 구성 맵을 사용하여 애플리케이션 코드와 별도로 Pod에 구성 값을 사용할 수 있도록 하는 방법을 확인할 수 있습니다.

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

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

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

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: my-namespace
data:
  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

다음과 같습니다.

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

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

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

Pod에 구성 데이터를 제공하기 위해 OpenShift Dedicated 웹 콘솔을 사용하여 구성 맵을 생성할 수 있습니다. 구성 맵을 사용하여 애플리케이션에 대한 정보가 포함된 키-값 쌍을 정의할 수 있습니다.

Pod에 구성 데이터를 제공하려면 OpenShift CLI(oc)를 사용하여 디렉터리, 특정 파일 또는 리터럴 값에서 구성 맵을 생성할 수 있습니다.

$ oc create configmap game-config --from-file=example-files/

$ oc describe configmaps game-config

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

Data

game.properties:        158 bytes
ui.properties:          83 bytes

$ oc create configmap game-config-3 --from-file=game-special-key=example-files/game.properties

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
  namespace: default
data:
  log_level: INFO

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

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

$ oc get priorityclasses

NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-node-critical      2000001000   false            72m
system-cluster-critical   2000000000   false            72m
openshift-user-critical   1000000000   false            3d13h
cluster-logging           1000000      false            29s

개발자가 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 선점을 고려합니다.

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

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

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

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

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

출력은 다음 예와 유사합니다.

kind: Pod
apiVersion: v1
metadata:
# ...
Name:               router-default-66d5cf9464-7pwkc
Namespace:          openshift-ingress
# ...
Controlled By:      ReplicaSet/router-default-66d5cf9464
# ...

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

apiVersion: v1
kind: Pod
metadata:
  name: router-default-66d5cf9464-7pwkc
# ...
  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: router-default-66d5cf9464
      uid: d81dd094-da26-11e9-a48a-128e7edf0312
      controller: true
      blockOwnerDeletion: true
# ...

다음 릴리스 노트를 검토하여 Custom Metrics Autoscaler Operator 버전 2.18.1-2의 변경 사항을 확인할 수 있습니다. Custom Metrics Autoscaler Operator for Red Hat OpenShift의 릴리스 노트는 새로운 기능 및 개선 사항, 더 이상 사용되지 않는 기능 및 알려진 문제에 대해 설명합니다.

Custom Metrics Autoscaler Operator는 Kubernetes 기반 이벤트 기반 자동 스케일러(KEDA)를 사용하며 OpenShift Dedicated HPA(Horizontal Pod Autoscaler) 상단에 빌드됩니다.

다음 릴리스 노트를 검토하여 이전 버전의 Custom Metrics Autoscaler Operator의 변경 사항을 확인할 수 있습니다.

현재 버전의 경우 Custom Metrics Autoscaler Operator 릴리스 노트를 참조하십시오.

기본적으로 Custom Metrics Autoscaler Operator는 자동으로 생성된 서비스 CA 인증서를 사용하여 클러스터 내 서비스에 연결합니다.

사용자 정의 CA 인증서가 필요한 클러스터 외부 서비스를 사용하려면 구성 맵에 필요한 인증서를 추가할 수 있습니다. 그런 다음 사용자 정의 지표 자동 스케일러 설치에 설명된 대로 구성 맵을 KedaController 사용자 정의 리소스에 추가합니다. Operator는 시작 시 해당 인증서를 로드하고 Operator에서 신뢰할 수 있는 인증서로 등록합니다.

구성 맵에는 하나 이상의 PEM 인코딩 CA 인증서가 포함된 인증서 파일이 하나 이상 포함될 수 있습니다. 또는 각 인증서 파일에 대해 별도의 구성 맵을 사용할 수 있습니다.

다음 절차를 사용하여 Custom Metrics Autoscaler Operator를 설치할 수 있습니다.

다음 절차에 따라 Custom Metrics Autoscaler Operator를 설치하는 동안 자동으로 설치된 KedaController CR(사용자 정의 리소스)을 수정할 수 있습니다.

설치된 OpenShift Dedicated 모니터링 또는 외부 Prometheus 서버를 메트릭 소스로 사용할 수 있는 Prometheus 메트릭을 기반으로 Pod를 확장할 수 있습니다. OpenShift Dedicated 모니터링을 메트릭 소스로 사용하는 데 필요한 구성에 대한 정보는 "사용자 정의 메트릭 자동 스케일러가 OpenShift Dedicated 모니터링을 사용하도록 구성"을 참조하십시오.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prom-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: prometheus 

    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 

      namespace: kedatest 

      metricName: http_requests_total 

      threshold: '5' 

      query: sum(rate(http_requests_total{job="test-app"}[1m])) 

      authModes: basic 

      cortexOrgID: my-org 

      ignoreNullValues: "false" 

      unsafeSsl: "false" 

      timeout: 1000 

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: gpu-scaledobject
  namespace: my-namespace
spec:
  scaleTargetRef:
    kind: Deployment
    name: gpu-deployment
  minReplicaCount: 1 

  maxReplicaCount: 5 

  triggers:
  - type: prometheus
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: my-namespace
      metricName: gpu_utilization
      threshold: '90' 

      query: SUM(DCGM_FI_DEV_GPU_UTIL{instance=~".+", gpu=~".+"}) 

      authModes: bearer
    authenticationRef:
      name: keda-trigger-auth-prometheus

CPU 메트릭을 기반으로 Pod를 확장할 수 있습니다. 이 트리거는 클러스터 메트릭을 지표 소스로 사용합니다.

사용자 정의 메트릭 자동 스케일러는 오브젝트와 연결된 Pod를 스케일링하여 사용자가 지정하는 CPU 사용량을 유지합니다. 자동 스케일러는 최소 및 최대 수 간에 복제본 수를 늘리거나 줄여 모든 Pod에서 지정된 CPU 사용률을 유지합니다. 메모리 트리거는 전체 Pod의 메모리 사용률을 고려합니다. Pod에 컨테이너가 여러 개 있는 경우 메모리 트리거는 Pod에 있는 모든 컨테이너의 총 메모리 사용률을 고려합니다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cpu-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: cpu 

    metricType: Utilization 

    metadata:
      value: '60' 

  minReplicaCount: 1 

메모리 메트릭을 기반으로 Pod를 확장할 수 있습니다. 이 트리거는 클러스터 메트릭을 지표 소스로 사용합니다.

사용자 정의 메트릭 자동 스케일러는 오브젝트와 연결된 Pod를 스케일링하여 사용자가 지정하는 평균 메모리 사용량을 유지합니다. 자동 스케일러는 최소 및 최대 수 간에 복제본 수를 늘리거나 줄여 모든 Pod에서 지정된 메모리 사용률을 유지합니다. 메모리 트리거는 전체 Pod의 메모리 사용률을 고려합니다. Pod에 컨테이너가 여러 개 있는 경우 메모리 사용률은 모든 컨테이너의 합계입니다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: memory-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: memory 

    metricType: Utilization 

    metadata:
      value: '60' 

      containerName: api 

Apache Kafka 주제 또는 Kafka 프로토콜을 지원하는 기타 서비스를 기반으로 Pod를 확장할 수 있습니다. 확장된 오브젝트 또는 확장 작업에서 allowIdleConsumers 매개변수를 true 로 설정하지 않는 한 사용자 정의 지표 자동 스케일러는 Kafka 파티션 수보다 확장되지 않습니다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: kafka 

    metadata:
      topic: my-topic 

      bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092 

      consumerGroup: my-group 

      lagThreshold: '10' 

      activationLagThreshold: '5' 

      offsetResetPolicy: latest 

      allowIdleConsumers: true 

      scaleToZeroOnInvalidOffset: false 

      excludePersistentLag: false 

      version: '1.0.0' 

      partitionLimitation: '1,2,10-20,31' 

      tls: enable 

시간 범위를 기반으로 Pod를 확장할 수 있습니다.

시간 범위가 시작되면 사용자 정의 지표 자동 스케일러는 구성된 최소 Pod 수에서 지정된 Pod 수로 오브젝트와 연결된 Pod를 스케일링합니다. 시간 범위가 끝나면 Pod가 구성된 최소로 다시 확장됩니다. 시간 기간은 cron 형식으로 구성해야 합니다.

다음 예제에서는 이 확장 오브젝트와 연결된 Pod를 오전 6시부터 오후 6 시 30분에서 오후 6시 30분으로 스케일링합니다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    name: my-deployment
  minReplicaCount: 0 

  maxReplicaCount: 100 

  cooldownPeriod: 300
  triggers:
  - type: cron 

    metadata:
      timezone: Asia/Kolkata 

      start: "0 6 * * *" 

      end: "30 18 * * *" 

      desiredReplicas: "100" 

특정 라벨 선택기와 일치하는 Pod 수에 따라 Pod를 스케일링할 수 있습니다.

Custom Metrics Autoscaler Operator는 동일한 네임스페이스에 있는 특정 라벨이 있는 Pod 수를 추적한 다음 확장된 오브젝트의 Pod에 대해 레이블이 지정된 Pod 수를 기반으로 관계를 계산합니다. 이 관계를 사용하여 Custom Metrics Autoscaler Operator는 scaled Object 또는 scaled Job 사양의 스케일링 정책에 따라 오브젝트를 스케일링 합니다.

Pod 수에는 성공 또는 실패 단계가 있는 Pod가 포함됩니다.

예를 들어 프런트 엔드 배포 및 백엔드 배포가 있는 경우입니다. kubernetes-workload 트리거를 사용하여 프런트 엔드 Pod 수에 따라 백엔드 배포를 스케일링할 수 있습니다. 프런트 엔드 Pod 수가 증가하면 Operator에서 백엔드 Pod를 확장하여 지정된 비율을 유지합니다. 이 예에서는 app=frontend Pod 선택기가 있는 10개의 Pod가 있는 경우 Operator는 확장된 오브젝트에 0.5 비율을 유지하기 위해 백엔드 Pod를 5로 스케일링합니다.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: workload-scaledobject
  namespace: my-namespace
spec:
  triggers:
  - type: kubernetes-workload 

    metadata:
      podSelector: 'app=frontend' 

      value: '0.5' 

      activationValue: '3.1'