2장. 노드 작업

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

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

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

OpenShift Container Platform에서는 하나의 호스트에 함께 배포되는 하나 이상의 컨테이너이자 정의, 배포, 관리할 수 있는 최소 컴퓨팅 단위인 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

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 구성 예"와 같이 Pod 사양을 사용하거나 Pod 제어 오브젝트에 대한 사양을 사용하여 Pod에 대한 CPU 및 메모리 요청 및 제한을 지정할 수 있습니다.

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

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

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

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

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

Linux 워크로드의 경우 대규모 페이지 리소스를 지정할 수 있습니다. 대규모 페이지는 노드 커널이 기본 페이지 크기보다 훨씬 큰 메모리 블록을 할당하는 Linux별 기능입니다. 예를 들어 기본 페이지 크기가 4KiB인 시스템에서 더 높은 제한을 지정할 수 있습니다. Huge Page에 대한 자세한 내용은 "Huge Page"를 참조하십시오.