3.3. Pod 및 서비스
3.3.1. Pod
OpenShift Container Platform은 하나의 호스트에 함께 배포되는 하나 이상의 컨테이너 이자 정의, 배포 및 관리할 수 있는 최소 컴퓨팅 단위인 Pod 의 Kubernetes 개념을 활용합니다.
Pod는 컨테이너에 대한 머신 인스턴스(실제 또는 가상)와 대략적으로 동일합니다. 각 Pod에는 자체 내부 IP 주소가 할당되므로 해당 Pod가 전체 포트 공간을 소유하고 Pod 내의 컨테이너는 로컬 스토리지와 네트워킹을 공유할 수 있습니다.
Pod에는 라이프사이클이 정의되어 있으며 노드에서 실행되도록 할당된 다음 컨테이너가 종료되거나 기타 이유로 제거될 때까지 실행됩니다. Pod는 정책 및 종료 코드에 따라 종료 후 제거되거나 컨테이너 로그에 대한 액세스를 활성화하기 위해 유지될 수 있습니다.
OpenShift Container Platform에서는 대체로 Pod를 변경할 수 없는 것으로 취급합니다. 실행 중에는 Pod 정의를 변경할 수 없습니다. OpenShift Container Platform은 기존 Pod를 종료한 후 수정된 구성이나 기본 이미지 또는 둘 다 사용하여 Pod를 다시 생성하는 방식으로 변경 사항을 구현합니다. Pod를 다시 생성하면 확장 가능한 것으로 취급되고 상태가 유지되지 않습니다. 따라서 일반적으로 포드는 사용자가 직접 관리하는 대신 상위 수준 컨트롤러에서 관리해야 합니다.
OpenShift Container Platform 노드 호스트당 최대 pod 수는 클러스터 최대값을 참조하십시오.
복제 컨트롤러에서 관리하지 않는 베어 Pod는 노드 중단 시 다시 예약되지 않습니다.
다음은 실제로 OpenShift Container Platform 인프라(통합 컨테이너 이미지 레지스트리)의 일부인 장기 실행 서비스를 제공하는 Pod 정의의 예입니다. 이 예제에서는 Pod의 다양한 기능을 보여줍니다. 대부분 다른 주제에서 설명하므로 여기에서는 간단히 언급합니다.
Pod 오브젝트 정의(YAML)
apiVersion: v1 kind: Pod metadata: annotations: { ... } labels: 1 deployment: docker-registry-1 deploymentconfig: docker-registry docker-registry: default generateName: docker-registry-1- 2 spec: containers: 3 - env: 4 - name: OPENSHIFT_CA_DATA value: ... - name: OPENSHIFT_CERT_DATA value: ... - name: OPENSHIFT_INSECURE value: "false" - name: OPENSHIFT_KEY_DATA value: ... - name: OPENSHIFT_MASTER value: https://master.example.com:8443 image: openshift/origin-docker-registry:v0.6.2 5 imagePullPolicy: IfNotPresent name: registry ports: 6 - containerPort: 5000 protocol: TCP resources: {} securityContext: { ... } 7 volumeMounts: 8 - mountPath: /registry name: registry-storage - mountPath: /var/run/secrets/kubernetes.io/serviceaccount name: default-token-br6yz readOnly: true dnsPolicy: ClusterFirst imagePullSecrets: - name: default-dockercfg-at06w restartPolicy: Always 9 serviceAccount: default 10 volumes: 11 - emptyDir: {} name: registry-storage - name: default-token-br6yz secret: secretName: default-token-br6yz
- 1
- Pod는 단일 작업에서 Pod 그룹을 선택하고 관리하는 데 사용할 수 있는 하나 이상의 레이블을 사용하여 "태그"할 수 있습니다. 레이블은
메타데이터
해시의 키/값 형식으로 저장됩니다. 이 예에서 하나의 레이블은 docker-registry=default 입니다. - 2
- Pod에는 네임스페이스 내에 고유한 이름이 있어야 합니다. 포드 정의는
generateName
속성이 있는 이름의 기반을 지정할 수 있으며, 고유 이름을 생성하기 위해 임의 문자가 자동으로 추가됩니다. - 3
containers
는 컨테이너 정의의 배열을 지정합니다. 이 경우 (대부분과 동일) 하나뿐입니다.- 4
- 각 컨테이너에 필요한 값을 전달하도록 환경 변수를 지정할 수 있습니다.
- 5
- 포드의 각 컨테이너는 자체 Docker 형식 컨테이너 이미지에서 인스턴스화됩니다.
- 6
- 컨테이너는 포드의 IP에서 사용할 수 있는 포트에 바인딩할 수 있습니다.
- 7
- OpenShift Container Platform은 컨테이너에 대한 보안 컨텍스트를 정의합니다. 보안 컨텍스트는 권한 있는 컨테이너로 실행하거나 선택한 사용자로 실행할 수 있는지의 여부 등을 지정합니다. 기본 컨텍스트는 매우 제한적이지만 필요에 따라 관리자가 수정할 수 있습니다.
- 8
- 컨테이너는 컨테이너 내에서 외부 스토리지 볼륨을 마운트해야 하는 위치를 지정합니다. 이 경우 레지스트리의 데이터를 저장하는 볼륨이 있으며 레지스트리에서 OpenShift Container Platform API에 요청하는 데 필요한 인증 정보에 액세스하기 위한 볼륨이 있습니다.
- 9
- Pod는 가능한 값
Always
,OnFailure
및Never
로 정책을 다시 시작합니다. 기본값은Always
입니다. - 10
- OpenShift Container Platform API에 대해 요청하는 Pod는 요청 시 포드에서 인증해야 하는 서비스 계정 사용자를 지정하는
serviceAccount
필드가 있는 일반적인 패턴입니다. 따라서 사용자 정의 인프라 구성 요소에 대한 액세스 권한을 세부적으로 제어할 수 있습니다. - 11
- Pod는 사용할 컨테이너에서 사용할 수 있는 스토리지 볼륨을 정의합니다. 이 경우 레지스트리 스토리지의 임시 볼륨과 서비스 계정 자격 증명을 포함하는
secret
볼륨을 제공합니다.
이 Pod 정의에는 Pod가 생성되고 해당 라이프사이클이 시작된 후 OpenShift Container Platform에 의해 자동으로 채워지는 특성은 포함되지 않습니다. Kubernetes Pod 설명서에는 Pod의 기능 및 용도에 대한 세부 정보가 있습니다.
3.3.1.1. Pod 재시작 정책
Pod 재시작 정책에 따라 해당 Pod의 컨테이너가 종료될 때 OpenShift Container Platform에서 응답하는 방법이 결정됩니다. 정책은 해당 포드의 모든 컨테이너에 적용됩니다.
가능한 값은 다음과 같습니다.
-
Always
- Pod를 다시 시작할 때까지 급격한 백오프 지연(10초, 20초, 40초)을 사용하여 Pod에서 성공적으로 종료된 컨테이너를 지속적으로 재시작합니다. 기본값은Always
입니다. -
OnFailure
- 급격한 백오프 지연(10초, 20초, 40초)을 5분으로 제한하여 Pod에서 실패한 컨테이너를 재시작합니다. -
Never
- Pod에서 종료되거나 실패한 컨테이너를 재시작하지 않습니다. Pod가 즉시 실패하고 종료됩니다.
노드에 바인딩되면 Pod가 다른 노드에 바인딩되지 않습니다. 따라서 노드 장애 시 Pod가 작동하려면 컨트롤러가 필요합니다.
상태 | 컨트롤러 유형 | 재시작 정책 |
---|---|---|
종료할 것으로 예상되는 Pod(예: 일괄 계산) |
| |
종료되지 않을 것으로 예상되는 Pod(예: 웹 서버) |
| |
머신당 하나씩 실행해야 하는 Pod | DaemonSet | Any |
Pod의 컨테이너가 실패하고 재시작 정책이 OnFailure
로 설정되면 Pod가 노드에 남아 있고 컨테이너가 다시 시작됩니다. 컨테이너를 재시작하지 않으려면 재시작 정책 Never
를 사용합니다.
전체 Pod가 실패하면 OpenShift Container Platform에서 새 Pod를 시작합니다. 개발자는 애플리케이션이 새 포드에서 다시 시작될 수 있는 가능성을 해결해야 합니다. 특히 애플리케이션은 이전 실행으로 발생한 임시 파일, 잠금, 불완전한 출력 등을 처리해야 합니다.
Kubernetes 아키텍처에서는 클라우드 공급자의 끝점이 안정적인 것으로 예상합니다. 클라우드 공급자가 중단되면 kubelet에서 OpenShift Container Platform이 재시작되지 않습니다.
기본 클라우드 공급자 끝점이 안정적이지 않은 경우 클라우드 공급자 통합을 사용하여 클러스터를 설치하지 마십시오. 클라우드가 아닌 환경에서처럼 클러스터를 설치합니다. 설치된 클러스터에서 클라우드 공급자 통합을 설정하거나 해제하는 것은 권장되지 않습니다.
OpenShift Container Platform에서 실패한 컨테이너에 재시작 정책을 사용하는 방법에 대한 자세한 내용은 Kubernetes 설명서의 예제 상태를 참조하십시오.