ConfigMap
- 컨피그맵은 key-value로 보안되야 할 데이터가 아닌 데이터를 저장하는 데 사용하는 API 오브젝트다.
- 파드는 볼륨에서 환경 변수, 커맨드 라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다.
- 컨피그맵을 사용하면 컨테이너 이미지에서 환경별 구성을 분리하는게 가능하고 애플리케이션을 쉽게 이식하는게 가능하다.
- 컨피그맵은 많은 양의 데이터를 보유할 수 있도록 설계되지 않았고 1MB를 초과할 수 없다.
When to use ConfigMap
주로 사용되는 예는 자신의 로컬 컴퓨터와 클라우드에서 실행할 수 있는 애플리케이션을 개발한다고 가정했을 때 연결하는 호스트가 다를 경우 ConfigMap을 이용해서 이 호스트의 주소를 로컬에서는 localhost로 클라우드에서는 서비스를 참조하도록 설정할 수 있다.
ConfigMap Pod
다른 쿠버네티스 오브젝트와는 달리 컨피그맵에는 data 와 binaryData 필드가 있다. 이러한 필드는 키-값 싼을 값으로 허용한다. 예제를 통해 이 필드를 어떻게 사용하는지 보자.
ConfigMap: Key And File
apiVersion: v1
kind: ConfigMap
metadata:
name: game-demo
data:
# 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨
player_initial_lives: "3"
ui_properties_file_name: "user-interface.properties"
# 파일과 비슷한 키
game.properties: |
enemy.types=aliens,monsters
player.maximum-lives=5
user-interface.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true ConfigMap과 Pod
-
컨피그맵을 참조하는 파드 spec을 작성하고 컨피그맵의 데이터를 기반으로 해당 파드의 컨테이너를 구성할 수 있다.
-
파드와 컨피그맵은 동일한 네임 스페이스에 있어야한다.
-
컨피그맵은 단일 값을 가진 키와 파일 이름의 키를 사용할 수 있다.
컨피그맵을 사용해 파드 내부에 컨테이너를 구성할 수 있는 네 가지 방법이 있다.
- 컨테이너 커맨드와 인수 내
- 컨테이너에 대한 환경 변수
- 애플리케이션이 읽을 수 있도록 읽기 전용 볼륨에 파일 추가
- 쿠버네티스 API를 이용해 컨피그맵을 읽는 코드를 파드에서 작성
컨피그맵에서는 단일 라인 값과 멀티 라인 값을 구별하지 않는다. 다만 이를 어떻게 사용할지가 중요하다.
이 예제에서 volume에 items라는 배열값이 없었다면 4개의 파일이 config 디렉토리에 만들어 질 것이다.
apiVersion: v1
kind: Pod
metadata:
name: configmap-demo-pod
spec:
containers:
- name: demo
image: alpine
command: ["sleep", "3600"]
env:
# 환경 변수 정의
- name: PLAYER_INITIAL_LIVES # 참고로 여기서는 컨피그맵의 키 이름과
# 대소문자가 다르다.
valueFrom:
configMapKeyRef:
name: game-demo # 이 값의 컨피그맵.
key: player_initial_lives # 가져올 키.
- name: UI_PROPERTIES_FILE_NAME
valueFrom:
configMapKeyRef:
name: game-demo
key: ui_properties_file_name
volumeMounts:
- name: config
mountPath: "/config"
readOnly: true
volumes:
# 파드 레벨에서 볼륨을 설정한 다음, 해당 파드 내의 컨테이너에 마운트한다.
- name: config
configMap:
# 마운트하려는 컨피그맵의 이름을 제공한다.
name: game-demo
# 컨피그맵에서 파일로 생성할 키 배열
items:
- key: "game.properties"
path: "game.properties"
- key: "user-interface.properties"마운트 된 컨피그맵 자동으로 업데이트
쿠버네티스 API를 통해 컨피그맵을 업데이트 하면 주기적인 Kublet의 동기화로 인해 마운트 된 컨피그맵 볼륨도 업데이트가 된다. 그리고 애플리케이션에서 이런 변경사항을 받아들이는 hot load를 지원한다면 바뀐 설정 정보를 이용하는것도 가능하다.
동기화 과정을 좀 살펴보면 kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다. 그리고 사용할 떈 kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가지고 온다.
그러므로 kubelet의 주기 시간동안 기다리고 캐시 값을 전파하는 시간만큼만 기다리면 업데이트가 반영된 컨피그맵을 이용할 수 있다.
변경할 수 없는(immutable) 컨피그맵
쿠버네티스 베타 기능인 변경할 수 없는 시크릿과 컨피그맵은 개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다.
- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴
- 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호할 수 있다.
이 기능은 immutable 필드를 true 로 설정하여 변경할 수 없는 컨피그맵을 생성할 수 있고 이는 ImmutableEphemeralVolumes 에 의해 제어된다.
컨피그맵을 Immutable로 표시하면 data 필드나 binaryData에 있는 필드를 변경살 수 없다. 컨피그맵을 삭제하고 다시 작성해야한다.
