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

2.3. Pod에 대한 OpenShift Container Platform 클러스터 구성

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

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

2.3.1. 재시작 후 Pod 작동 방식 구성

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

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

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

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

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

종료할 것으로 예상되는 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"
        }
    }
}

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

    $ oc create -f <file_or_dir_path>

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

Pod 중단 예산을 사용하면 유지보수를 위해 노드를 드레이닝하는 등 작업 중에 Pod에 대한 보안 제약 조건을 지정할 수 있습니다.

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

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

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

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

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

available 은 조건이 Ready=True 인 Pod 수를 나타냅니다. ready=True 는 요청을 제공할 수 있는 Pod를 나타내며 일치하는 모든 서비스의 로드 밸런싱 풀에 추가해야 합니다.

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

주의

maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1 입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3 으로 변경하지 마십시오.

다음을 사용하여 모든 프로젝트에서 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 우선 순위 및 선점 설정에 따라 우선 순위가 낮은 pod는 pod 중단 예산 요구 사항을 무시하고 제거될 수 있습니다.

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

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

프로세스

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

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

    apiVersion: policy/v1 1
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2  2
  selector:  3
    matchLabels:
      name: my-pod
    1
    PodDisruptionBudget 은 policy/v1 API 그룹의 일부입니다.
    2
    동시에 사용할 수 필요가 있는 최소 pod 수 입니다. 정수 또는 백분율 (예: 20 %)을 지정하는 문자열을 사용할 수 있습니다.
    3
    리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다. 프로젝트의 모든 포드를 선택하려면 이 매개변수(예: selector {} )를 비워 둡니다.

    또는 다음을 수행합니다. 

    apiVersion: policy/v1 1
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  maxUnavailable: 25% 2
  selector: 3
    matchLabels:
      name: my-pod
    1
    PodDisruptionBudget 은 policy/v1 API 그룹의 일부입니다.
    2
    동시에 사용할 수없는 최대 pod 수입니다. 정수 또는 백분율 (예: 20 %)을 지정하는 문자열을 사용할 수 있습니다.
    3
    리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다. 프로젝트의 모든 포드를 선택하려면 이 매개변수(예: selector {} )를 비워 둡니다.

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

    $ oc create -f </path/to/file> -n <project_name>

2.3.3.2. 비정상 Pod의 제거 정책 지정

PDB(Pod 중단 예산)를 사용하여 동시에 사용할 수 있는 Pod 수를 지정하는 경우 비정상 Pod를 제거로 간주하는 방법에 대한 기준을 정의할 수도 있습니다.

다음 정책 중 하나를 선택할 수 있습니다.

IfHealthyBudget
아직 정상이 아닌 실행 중인 Pod는 보호된 애플리케이션이 중단되지 않는 경우에만 제거할 수 있습니다.
AlwaysAllow

아직 정상이 아닌 Pod 실행은 Pod 중단 예산의 기준이 충족되었는지 여부와 관계없이 제거할 수 있습니다. 이 정책은 CrashLoopBackOff 상태에 있거나 Ready 상태를 보고하지 못하는 Pod와 같은 오작동 애플리케이션을 제거하는 데 도움이 될 수 있습니다.

참고

노드 드레이닝 중 잘못된 애플리케이션 제거를 지원하기 위해 PodDisruptionBudget 오브젝트에서 unhealthyPodEvictionPolicy 필드를 AlwaysAllow 로 설정하는 것이 좋습니다. 기본 동작은 드레이닝을 진행하기 전에 애플리케이션 Pod가 정상 상태가 될 때까지 기다리는 것입니다.

프로세스

  1. PodDisruptionBudget 오브젝트를 정의하는 YAML 파일을 생성하고 비정상 Pod 제거 정책을 지정합니다.

    pod-disruption-budget.yaml 파일의 예

    apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      name: my-pod
  unhealthyPodEvictionPolicy: AlwaysAllow 1

    1
    비정상 Pod 제거 정책으로 IfHealthyBudget 또는 AlwaysAllow 중 하나를 선택합니다. unhealthyPodEvictionPolicy 필드가 비어 있는 경우 기본값은 IfHealthyBudget 입니다.

  2. 다음 명령을 실행하여 PodDisruptionBudget 오브젝트를 생성합니다. 

    $ oc create -f pod-disruption-budget.yaml

AlwaysAllow 비정상적인 Pod 제거 정책이 설정된 PDB를 사용하면 노드를 드레이닝하고 이 PDB에 의해 보호되는 오작동 애플리케이션에 대한 Pod를 제거할 수 있습니다.

추가 리소스

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

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

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

프로세스

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

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

    apiVersion: v1
kind: Pod
metadata:
  name: my-pdb
spec:
  template:
    metadata:
      name: critical-pod
    priorityClassName: system-cluster-critical 1
    1
    노드에서 제거해서는 안 되는 Pod의 기본 우선순위 클래스입니다.

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

  2. Pod를 생성합니다. 

    $ oc create -f <file-name>.yaml

2.3.5. 파일 수가 많은 영구 볼륨을 사용할 때 Pod 시간 초과 감소

스토리지 볼륨에 여러 파일(~1,000,000 이상)이 포함된 경우 Pod 시간 초과가 발생할 수 있습니다.

이는 볼륨이 마운트되면 OpenShift Container Platform에서 Pod의 securityContext 에 지정된 fsGroup 과 일치하도록 각 볼륨의 내용의 소유권과 권한을 재귀적으로 변경하기 때문에 발생할 수 있습니다. 대규모 볼륨의 경우 소유권 및 권한을 확인하고 변경하는 데 시간이 오래 걸릴 수 있으므로 Pod 시작 속도가 매우 느려집니다.

다음 해결 방법 중 하나를 적용하여 이 지연을 줄일 수 있습니다.

  • SCC(보안 컨텍스트 제약 조건)를 사용하여 볼륨의 SELinux 레이블 재지정을 건너뜁니다.
  • SCC 내에서 fsGroupChangePolicy 필드를 사용하여 OpenShift Container Platform이 볼륨에 대한 소유권 및 권한을 확인하고 관리하는 방법을 제어합니다.
  • Cluster Resource Override Operator를 사용하여 SELinux 레이블 재지정을 건너뛰도록 SCC를 자동으로 적용합니다.
  • 런타임 클래스를 사용하여 볼륨의 SELinux 레이블 재레이블을 건너뜁니다.

자세한 내용은 OpenShift에서 파일 수가 많은 영구 볼륨을 사용하는 경우 Pod를 시작하지 못하거나 "Ready" 상태를 달성하는 데 과도한 시간이 걸리는 이유를 참조하십시오.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.