컨테이너의 런타임 요구사항을 알아야 하는 2가지 중요한 이유가 있다. 첫째, 모든 런타임 의존성이 정의되고 자원 요구사항이 계산되면, 쿠버네티스는 가장 효율적인 하드웨어 사용을 위해 클러스터 내에 컨테이너 실행 위치를 지능적으로 결정할 수 있다.

우선순위가 다른 프로세스들이 자원을 공유하면서 사용하는 환경에서는 사전에 각 프로세스의 요구사항을 알아야 프로세스가 성공적으로 공존할 수 있다. 그러나 지능적인 배치가 전부는 아니다.

컨테이너 자원 프로파일이 필수적인 두 번째 이유로 용량 계획을 들 수 있는데, 특별한 서비스 요구사항과 총 서비스 수에 근거해 다양한 환경에 대한 용량 계획을 세우고, 전체 클러스터에 대한 요구사항을 충족하는 비용 효율이 높은 최적의 호스트 프로파일을 만들 수 있다.

성공적인 클러스터 관리를 위해 서비스 자원 프로파일과 용량 계획은 장기적으로 함께 진행해야 한다.

런타임 의존성

가장 일반적인 런타임 의존성은 애플리케이션 상태를 저장하는데 쓰이는 파일 스토리지다. 컨테이너 파일 시스템은 일시적이며 컨테이너가 종료되면 삭제된다. 쿠버네티스는 컨테이너 재시작에도 삭제되지 않고 유지되는 다용도의 파드 레벨 스토리지로서 볼륨을 제공한다.

가장 간단한 볼륨 타입음 empty이며 파드가 살아 있는 동안만 존재하고 파드를 제거하면 볼륨과 그 안의 내용도 삭제된다. 파드를 다시 시작한 후에도 볼륨을 유지하려면 다른 종류의 스토리지 매커니즘을 지원하는 볼륨이 필요하다. 여러분이 만든 애플리케이션이 오랫동안 스토리지에 파일을 읽거나 써야 하는 경우라면, 아래 예제에 표시된 것처럼 불륨을 사용하는 컨테이너 정의 안에 명시적으로 의존성을 선언해야 한다.

apiVersion: v1
kind: Pod
metadata:
	name: random-generator
spec:
	containers:
	- image: k8spatterns/random-generator:1.0
		name: random-generator
		volumeMounts:
		- mountPath: "/logs"
			name: log-volume
	volumes:
	- name: log-volume
		persistentVolumeClaim:
			claimName: random-generator-log #이미 생성된 PVC에 연결하기 위한 의존성

스케쥴러는 파드가 요청한 불륨 종류를 판단하며, 이는 파드가 실행될 위치에 영향을 미친다. 만약 클러스터 노드가 제공하지 않는 불륨을 파드가 필요로 한다면, 파드는 결코 스케쥴링이 되지 않는다. 불륨은 런타임 의존성의 한 예로 파드가 실행될 수 있는 인프라스트럭처가 무엇인지, 그리고 파드가 스케쥴링될 수 있는지 여부에 영향을 준다.

쿠버네티스에 hostPort를 통해서 호스트 시스템의 특정 포트로 컨테이너 포트 노출을 요청할 때도 비슷한 의존성이 발생한다. hostPort를 사용하면 노드에 또 다른 런타임 의존성이 생성되고 파드를 스케쥴링할 수 있는 위치가 제한된다.

hostPort는 클러스터에서 각 노드에 해당 포트를 예약하고 노드 하나당 최대 하나의 파드만 스케쥴링되게 제한한다. 포트 충돌 때문에 쿠버네티스 클러스터 노드 수만큼만 파드를 확장할 수 있다.

또 다른 타입의 의존성으로는 설정이 있다. 거의 모든 애플리케이션에는 몇 가지 설정 정보가 필요하며 쿠버네티스에서 제공하는 권장 솔루션은 컨피그맵이다. 애플리케이션 설정에는 환경 변수를 통한 설정과 파일시스템을 통한 설정, 2 가지 방법이 있다.

2가지 경우 모두 컨피그맵으로 명명된 컨테이너 런타임 의존성을 적용한다. 요청한 모든 컨피그맵이 생성되지 않으면, 컨테이너는 노드에 스케쥴링 될 수 있지만 시작되지 않는다. 컨피그맵과 시크릿은 추후 자원 설정에서 좀 더 자세히 설명한 예정이다.

아래 예제는 이러한 자원이 어떻게 런타임 의존성으로 사용되는지를 보여준다.

apiVersion: v1
kind: Pod
metadata:
	name: random-generator
spec:
	containers:
	- image: k8spatterns/random-generator:1.0
		name: random-generator
		env:
		- name: PATTERN
			valueFrom:
				configMapKeyRef:
					name: random-generator-config #컨피그맵의 의존성 생성
					key: pattern

컨피그맵과 비슷한 개념으로는 시크릿이 있고, 환경 특화된 설정을 컨테이너에 적용하는 좀 더 안전한 방법을 제공한다. 시크릿을 사용하는 방법은 컨피그맵 사용방법과 동일하며, 컨테이너부터 네임스페이스까지 시크릿은 컨피그맵과 같은 종류의 의존성이라 할 수 있다.

스토리지와 포트 번호는 클러스터 노드가 제공하지만, 컨피그맵과 시크릿 객체 생성은 우리가 수행해야 하는 단순한 관리 작업이다. 스토리지와 포트 번호 의존성은 파드가 스케쥴링되는 위치를 제한하며, 컨피그맵과 시크릿 의존성은 파드가 시작하는 것을 막을 수도 있다.

이런 의존성을 갖는 컨테이너화된 애플리케이션을 설계할 때는 향후 발생하게 될 런타임 제약사항을 항상 고려해야 한다.

자원 프로파일

컨피그맵, 시크릿, 불륨 같은 컨테이너 의존성을 지정하는 방법은 간단하다. 컨테이너의 자원 요구사항을 알기 위해서는 더 많은 고민과 실험이 필요하다. 쿠버네티스 컨텍스트 내에서의 컴퓨팅 자원이라 함은 컨테이너에 의해 요청되고, 컨테이너에 할당괴고, 컨테이너가 소비할 수 있는 무언가로 정의된다.