[kubernetes] 쿠버네티스 패턴 - 예측 범위 내의 요구사항

박원균·2021년 11월 8일

Kubernetes

목록 보기

11/24

이 글은 "쿠버네티스 패턴 2020빌긴 이브리안,롤란트 후스지음, 안승규,서한배 옮김 책만, 9791189909123" 책을 기반으로 작성되었습니다.

문제점

컨테이너 안에서 애플리케이션을 실행할 수만 있다면 k8s는 다른 프로그래밍 언어로 작성된 애플리케이션도 관리할 수 있습니다 하지만 언어 따라 각기 다른 요구사항이 생기기 마련입니다.

컨테이너가 최적의 기능을 수행하는데 필요한 자원량을 예측하기란 어려워서, 개발자가 테스트를 수행한 후에야 비로서 서비스 구현을 위한 자원 필요량을 알 수 있습니다.

모든 애플리케이션 특성을 정의하고 이를 관리 플래폼으로 전달하는 것은 클라우드 네이티브 애플리케이션의 기본 전제조건입니다.
자원 요구사항 외에도 애플리케이션 런타임은 데이터 스토리지 또는 애플리케이션 설정 같은 플랫폼 관리 기능이 필요합니다.

해결책

컨테이너의 런타임 요구사항을 알아야 하는 2가지 중요한 이유가 있습니다.

모든 런타임 의존성이 정의되고 자원 요구사항이 계산되면, 쿠버네티스는 가장 효율적인 하드웨어 사용을 위해 클러스터 내에 컨테이너 실행 위치를 지능적으로 결정할 수 있습니다.
용량 계획
특별한 서비스 요구사항과 총 서비스 수에 근거해 다양한 환경에 대한 용량 계획을 세우고, 전체 클러스터에 대한 요구사항을 충족하는 비용 효율이 높은 최적의 호스트 프로파일을 만들 수 있습니다. 성공적인 클러스터 관리를 위해 서비스 자원 프로파일과 용량 계획은 장기적으로 함께 진행해야 합니다.

런타임 의존성

파일 스토리지
hostPort
설정 Configuration - 컨피그맵

위 3개의 항목이 대표적인 런타임 의존성을 가지고 있습니다.

파일 스토리지

애플리케이션 상태를 저장하는데 쓰이는 파일 스토리지

파일 시스템은 일시적이며 컨테이너가 종료되면 삭제됩니다.쿠버네티스는 컨테이너 재시작에도 삭제되지 않고 유지되는 다용도의 파드 레벨 스토리지로서 볼륨을 제공합니다.

가장 간단한 볼륨 타입은 emptyDir이며 파드가 살아 있는 동안만 존재하고 파드를 제거하면 볼륨과 그 안의 내용도 삭제됩니다. 파드를 다시 시작한 후에도 볼륨을 유지하려면 다른 종류의 스토리지 메커니즘을 지원하는 볼륨이 필요합니다.

# PersistentVolume의 의존성
apiVersion: v1
kind: Pod
metadata:
	name: nginx
spec:
	containers:
    - images: nginx
      name: nginx
      volumeMounts:
      - mountPath: "/webdata"
        name: web-volume
	volumes:
    - name: web-volume
    persistentVolumeClaim:  # 이미 생성된 PVC에 연결하기 위한 의존성
    	claimName: nginx-webdata

스케줄러는 파드가 요청한 볼륨 종류를 판단하며 이는 파드가 실행될 위치에 영향을 미칩니다.

만약 클러스터 노드가 제공하지 않는 볼륨을 파드가 필요호 한다면 파드는 결코 스케줄링되지 않습니다. 볼륨은 런타임 의존성의 한 예로서 파드가 실행될수 있는 인프라스트럭처가 무엇인지 그리고 파드가 스케줄링될 수 있는지 여부에 영향을 줍니다.

hostPort

쿠버네티스에 hostPort를 통해서 호스트 시스템의 특정 포트로 컨테이너 포트 노출을 요청할 때도 비슷한 의존성이 발생합니다. hostPort는 클러스터에서 각 노드의 해당 포트를 예약하고 노드 하나당 최대 하나의 파드만 스케줄링되게 제한합니다. 포트 충돌 대문에 쿠버네티스 클러스터 노드 수만큼만 파드를 확장할 수 있습니다.

설정 Configuration

거의 모든 애플리케이션에는 몇 가지 설정 정보가 필요하며 쿠버네티스에서 제공하는 권장 솔류션은 컨피그맵입니다. 애플리케이션 설정에는 환경 변수를 통한 설정과 파일 시스템을 통한 설정이 있습니다

위에 소개된 2개의 방법 모두 컨피그맵으로 명명된 컨테이너 런타임 의존성을 적용합니다. 요청한 모든 컨피그 맵이 생성되지 않으면, 컨테이너는 노드에 스케줄링될 수 있지만 시작되지 않습니다.

# 컨피그맵에 대한 의존성
apiVersion: v1
kind: Pod
metadata:
	name: nginx
spec:
	containers:
    - images: nginx
      name: nginx
      env: 
      -name: PATTERN
      valueFrom:
      	configMapKeyRef:  # 컨피그맵의 의존성 생성
        	name: nginx-config
            key: pattern