2.3. Pod에 대한 OpenShift Container Platform 클러스터 구성
관리자는 Pod에 효율적인 클러스터를 생성하고 유지 관리할 수 있습니다.
클러스터를 효율적으로 유지하면 Pod가 종료될 때 수행하는 작업과 같은 툴을 사용하여 개발자에게 더 나은 환경을 제공할 수 있습니다. 즉 필요한 수의 Pod가 항상 실행되고 있는지 확인하여 한 번만 실행되도록 설계된 Pod를 재시작하는 경우 Pod에 사용할 수 있는 대역폭을 제한하고, 중단 중 Pod를 계속 실행하는 방법을 제공합니다.
2.3.1. 재시작 후 Pod 작동 방식 구성
Pod 재시작 정책에 따라 해당 Pod의 컨테이너가 종료될 때 OpenShift Container Platform에서 응답하는 방법이 결정됩니다. 정책은 해당 Pod의 모든 컨테이너에 적용됩니다.
가능한 값은 다음과 같습니다.
-
Always- 급격한 백오프 지연(10초, 20초, 40초)을 5분으로 제한하여 Pod에서 성공적으로 종료된 컨테이너를 지속적으로 재시작합니다. 기본값은Always입니다. -
OnFailure- 급격한 백오프 지연(10초, 20초, 40초)을 5분으로 제한하여 Pod에서 실패한 컨테이너를 재시작합니다. -
Never- Pod에서 종료되거나 실패한 컨테이너를 재시작하지 않습니다. Pod가 즉시 실패하고 종료됩니다.
Pod가 특정 노드에 바인딩된 후에는 다른 노드에 바인딩되지 않습니다. 따라서 노드 장애 시 Pod가 작동하려면 컨트롤러가 필요합니다.
| 상태 | 컨트롤러 유형 | 재시작 정책 |
|---|---|---|
| 종료할 것으로 예상되는 Pod(예: 일괄 계산) | Job |
|
| 종료되지 않을 것으로 예상되는 Pod(예: 웹 서버) | 복제 컨트롤러 |
|
| 머신당 하나씩 실행해야 하는 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의 대역폭을 제한하려면 다음을 수행합니다.
오브젝트 정의 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" } } }오브젝트 정의를 사용하여 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 은 condition Ready=True 가 있는 Pod 수를 나타냅니다. ready=True 는 요청을 처리할 수 있는 Pod를 참조하며 일치하는 모든 서비스의 부하 분산 풀에 추가해야 합니다.
maxUnavailable 0 % 또는 0이나 minAvailable의 100 % 혹은 복제본 수와 동일한 값은 허용되지만 이로 인해 노드가 드레인되지 않도록 차단할 수 있습니다.
다음을 사용하여 모든 프로젝트에서 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 중단 예산을 구성하려면 다음을 수행합니다.
다음과 같은 오브젝트 정의를 사용하여 YAML 파일을 만듭니다.
apiVersion: policy/v1 1 kind: PodDisruptionBudget metadata: name: my-pdb spec: minAvailable: 2 2 selector: 3 matchLabels: name: my-pod
또는 다음을 수행합니다.
apiVersion: policy/v1 1 kind: PodDisruptionBudget metadata: name: my-pdb spec: maxUnavailable: 25% 2 selector: 3 matchLabels: name: my-pod
다음 명령을 실행하여 오브젝트를 프로젝트에 추가합니다.
$ oc create -f </path/to/file> -n <project_name>
2.3.4. 중요 Pod를 사용하여 Pod 제거 방지
완전히 작동하는 클러스터에 중요하지만 마스터가 아닌 일반 클러스터 노드에서 실행되는 다양한 핵심 구성 요소가 있습니다. 중요한 추가 기능이 제거되면 클러스터가 제대로 작동하지 않을 수 있습니다.
중요로 표시된 Pod는 제거할 수 없습니다.
프로세스
Pod를 중요로 설정하려면 다음을 수행합니다.
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을 지정할 수 있지만 필요한 경우 제거할 수도 있습니다.Pod를 생성합니다.
$ oc create -f <file-name>.yaml
2.3.5. 파일 수가 많은 영구 볼륨을 사용할 때 Pod 타임아웃 감소
스토리지 볼륨에 많은 파일(~1,000,000개 이상)이 포함된 경우 Pod 시간 초과가 발생할 수 있습니다.
이는 볼륨이 마운트될 때 Pod의 securityContext 에 지정된 fsGroup 과 일치하도록 OpenShift Container Platform에서 각 볼륨의 컨텐츠의 소유권 및 권한을 재귀적으로 변경하기 때문에 발생할 수 있습니다. 대규모 볼륨의 경우 소유권 및 권한을 확인하고 변경하는 데 시간이 오래 걸리므로 Pod 시작 속도가 매우 느려질 수 있습니다.
다음 해결 방법 중 하나를 적용하여 이 지연을 줄일 수 있습니다.
- SCC(보안 컨텍스트 제약 조건)를 사용하여 볼륨의 SELinux 재레이블을 건너뜁니다.
-
SCC 내에서
fsGroupChangePolicy필드를 사용하여 OpenShift Container Platform에서 볼륨의 소유권 및 권한을 확인하고 관리하는 방법을 제어합니다. - 런타임 클래스를 사용하여 볼륨의 SELinux 재레이블을 건너뜁니다.
자세한 내용은 OpenShift에서 파일 수가 많은 영구 볼륨을 사용할 때 Pod가 시작되지 않거나 "Ready" 상태를 달성하는 데 과도한 시간이 걸리는 이유는 무엇입니까?
