Edit This Page

컨피그맵(ConfigMap)

컨피그맵은 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 파드파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다. 는 볼륨데이터를 포함하고 있는 디렉토리이며, 파드의 컨테이너에서 접근 가능하다. 에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다.

컨피그맵을 사용하면 컨테이너 이미지컨테이너의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다. 에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다.

주의: 컨피그맵은 보안 또는 암호화를 제공하지 않는다. 저장하려는 데이터가 기밀인 경우, 컨피그맵 대신 시크릿(Secret)Stores sensitive information, such as passwords, OAuth tokens, and ssh keys. 또는 추가(써드파티) 도구를 사용하여 데이터를 비공개로 유지하자.

사용 동기

애플리케이션 코드와 별도로 구성 데이터를 설정하려면 컨피그맵을 사용하자.

예를 들어, 자신의 컴퓨터(개발용)와 클라우드(실제 트래픽 처리)에서 실행할 수 있는 애플리케이션을 개발한다고 가정해보자. DATABASE_HOST 라는 환경 변수를 찾기 위해 코드를 작성한다. 로컬에서는 해당 변수를 localhost 로 설정한다. 클라우드에서는, 데이터베이스 컴포넌트를 클러스터에 노출하는 쿠버네티스 서비스네트워크 서비스로 파드 집합에서 실행 중인 애플리케이션을 노출하는 방법 를 참조하도록 설정한다.

이를 통해 클라우드에서 실행 중인 컨테이너 이미지를 가져와 필요한 경우 정확히 동일한 코드를 로컬에서 디버깅할 수 있다.

컨피그맵 오브젝트

컨피그맵은 다른 오브젝트가 사용할 구성을 저장할 수 있는 API 오브젝트이다. spec 이 있는 대부분의 쿠버네티스 오브젝트와 달리, 컨피그맵에는 항목(키)과 해당 값을 저장하는 data 섹션이 있다.

컨피그맵의 이름은 유효한 DNS 서브도메인 이름이어야 한다.

컨피그맵과 파드(Pod)

컨피그맵을 참조하는 파드 spec 을 작성하고 컨피그맵의 데이터를 기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은 동일한 네임스페이스쿠버네티스에서 동일한 물리 클러스터에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화. 에 있어야 한다.

다음은 단일 값을 가진 키와, 값이 구성 형식의 일부처럼 보이는 키를 가진 컨피그맵의 예시이다.

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

컨피그맵을 사용하여 파드 내부에 컨테이너를 구성할 수 있는 네 가지 방법이 있다.

  1. 컨테이너의 엔트리포인트에 대한 커맨드 라인 인수
  2. 컨테이너에 대한 환경 변수
  3. 애플리케이션이 읽을 수 있도록 읽기 전용 볼륨에 파일 추가
  4. 쿠버네티스 API를 사용하여 컨피그맵을 읽는 파드 내에서 실행할 코드 작성

이러한 방법들은 소비되는 데이터를 모델링하는 방식에 따라 다르게 쓰인다. 처음 세 가지 방법의 경우, kubelet클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다. 은 파드의 컨테이너를 시작할 때 시크릿의 데이터를 사용한다.

네 번째 방법은 시크릿과 데이터를 읽기 위해 코드를 작성해야 한다는 것을 의미한다. 그러나, 쿠버네티스 API를 직접 사용하기 때문에, 애플리케이션은 컨피그맵이 변경될 때마다 업데이트를 받기 위해 구독할 수 있고, 업데이트가 있으면 반응한다. 쿠버네티스 API에 직접 접근하면, 이 기술을 사용하여 다른 네임스페이스의 컨피그맵에 접근할 수도 있다.

다음은 game-demo 의 값을 사용하여 파드를 구성하는 파드 예시이다.

apiVersion: v1
kind: Pod
metadata:
  name: configmap-demo-pod
spec:
  containers:
    - name: demo
      image: game.example/demo-game
      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

컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을 구분하지 않는다. 더 중요한 것은 파드와 다른 오브젝트가 이러한 값을 소비하는 방식이다. 이 예제에서, 볼륨을 정의하고 demo 컨테이너에 /config 로 마운트하면 4개의 파일이 생성된다.

  • /config/player_initial_lives
  • /config/ui_properties_file_name
  • /config/game.properties
  • /config/user-interface.properties

/config 에 .properties 확장자를 가진 파일만 포함시키려면, 두 개의 다른 컨피그맵을 사용하고, 파드에 대해서는 spec 의 두 컨피그맵을 참조한다. 첫 번째 컨피그맵은 player_initial_lives 와 ui_properties_file_name 을 정의한다. 두 번째 컨피그맵은 kubelet이 /config 에 넣는 파일을 정의한다.

참고: 컨피그맵을 사용하는 가장 일반적인 방법은 동일한 네임스페이스의 파드에서 실행되는 컨테이너에 대한 설정을 구성하는 것이다. 컨피그맵을 별도로 사용할 수도 있다. 예를 들어, 컨피그맵에 기반한 동작을 조정하는 애드온Resources that extend the functionality of Kubernetes. 이나 오퍼레이터A specialized controller used to manage a custom resource 를 사용할 수도 있다.

다음 내용