쿠버네티스 [컨피그맵]이란?

🧾📜컨피그맵과 시크릿이란?

컨피그맵과 시크릿은 애플리케이션 설정을 위한 쿠버네티스 API 오브젝트이다.

애플리케이션을 실행할 때 애플리케이션 자체에 포함하지 말아야하는 설정(인스턴스별로 다른 세팅, 외부 시스템 연결을 위한 자격증명 등)들이 있는데, 그러한 데이터를 보내주는 역할을 가진것이 컨피그맵과 시크릿이다.

보통의 컨테이너화된 애플리케이션 설정

• 보통 모든 설정을 앱에 포함(명령줄 인수로 설정 정보 전달)한다. 또한 MySQL같이 환경변수를 사용하기 마련인데 이런 경우 이미지에 접근하는 모든 사람이 설정 정보를 볼 수 있게 되어 보안성이 좋지 않다.
• 물론 gitRepo 볼륨과 같이 외부에서 가져와 설정 소스로 사용하는 해결방안도 있지만 버전별로 관리할 수 있도록 쿠버네테스 리소스가 제공하는 컨피그맵이 있기에 이를 사용한다. 또한 보안을 중시할 경우 시크릿이라는 오브젝트를 사용한다.

보통의 설정 예시

• Docker로 이미지를 실행해 컨테이너를 만든다면 맨 처음 DockerFile에서 ENTRYPOINT(컨테이너 시작시 호출될 명령어, 실행파일 정의)와 CMD(실행파일에 전달되는 인자)를 실행한다.
• 다음 예시와 같이 도커파일에서 ENTRYPOINT와 CMD 등을 지정해 이미지를 빌드할 때 사용한다. 또한 쿠버네티스에서 ENTRYPOINT와 CMD를 재정의하는것도 가능하다.
  
  
• 앞서 살펴본 것 외에도 애플리케이션은 종종 환경변수를 설정 옵션으로 사용했지만 지금은 이러한 옵션을 사용하지 않는다.
• 파드 정의에서 하드코딩한 환경변수를 가져오는것은 어찌보면 효율적이지만, 여러 환경에서 동일한 파드를 재사용하기 위해 설정을 분리해야하는 경우가 생겨버린다.
  

🧾ConfigMap으로 설정 분리

ConfigMap의 목적은 환경에 따라 다르거나 자주 변경되는 설정 옵션을 애플리케이션 소스 코드와 분리함에 있다.

• ConfigMap은 설정 파일에 이르는 값을 키/값 형태로 구성한 맵으로, 컨테이너에서 필요로할 때 컨테이너의 환경변수, 볼륨파일로 전달된다.
• ConfigMap은 애플리케이션과 독립적인 오브젝트로 정의되며 각 파드에서 컨피그맵을 이름으로 참조해 각 환경에서 서로 다른 설정을 사용할 수 있게 된다.
  

ConfigMap 생성

• kubectl create configmap 명령어로 생성하며 생성예시는 다음과 같다.
• $kubectl create configmap lsh-config --from-literal=awake-interval=60을 실행하면 lsh-config라는 이름을 가지며 awake-intervel=60인 단일항목을 가진 컨피그맵이 생성된다. 생성후 쿠버네티스 API에 게시한다. 외에도 다양한 옵션 설정 방법들이 존재한다.
  
  

ConfigMap을 컨테이너에 전달

• pod의 env또는 envForm 환경변수 항목에 valueForm을 통해 컨피그맵을 전달한다. 이 때 사용할 컨피그맵이 존재하지 않았다면 컨테이너 시작에 실패하고, 옵션을 통해 컨피그맵이 없어도 컨테이너를 시작하는 방법이 있다.
  
• 받아온 컨피그맵 값을 프로세스의 명령줄 인자로 전달하는 방법은 다음과 같다.
  
• 명령줄 인자같이 짧은 변숫값 외의 설정 파일을 포함시킬 때는 컨피그맵 볼륨을 사용한다. 보통 대형 설정 파일들을 컨테이너에 전달할 때 사용하는 방법이다. 생성 방법은 $kubectl create configmap lsh-config --from-file=configmap-files 로 data에 awake-interval 외에도 여러 항목들이 포함된 configmap-files(nginx의설정파일, awake-interval 등 여러 항목)을 사용한다.
  
• 기본적으로 컨피그맵 볼륨의 모든 파일 권한는 644(owner는 R/W, others는 R만 가능)로 설정된다.

애플리케이션을 재시작 없이 설정 업데이트 하는법

• 환경변수나 명령줄 인수는 프로세스가 실행되는 동안에 업데이트할 수 없다는 것이 단점인데, 컨피그맵 볼륨을 사용하면 이를 해결해준다. 컨피그맵의 업데이트 -> 컨피그맵 볼륨의 업데이트(1분 정도 걸림). 물론 ReDeploy도 방법이다.
• 만약 환경변수나 명령줄 인수를 사용해 애플리케이션에 설정을 다시 읽는 기능이 없다면 심각한 문제가 발생할 수 있으니 컨피그맵 수정에 주의해야한다.

📜Secret으로 민감한 데이터 컨테이너에 전달

Secret 오브젝트는 자격증명과 개인 암호와같은 민감한 정보를 보관하고 배포하기 위해 사용한다.

• 노드에선 시크릿의 보안을 위해 물리 저장소가 아닌 메모리에 저장해 사용한다. 또한 마스터 노드에서(etcd: 컨트롤플레인의 저장소)는 시크릿을 암호화 없이 저장하기 때문에, 권한없는 사용자가 API서버를 이용하지 못하게한다.
• 시크릿은 API서버와 통신을 위한 세가지 항목(ca.crt, namespace, token)을 가지고 있으며 kubectl describe pod를 통해 sceret 볼륨이 마운트 된것을 확인할 수 있다.
  
• 전체적인 사용방법은 컨피크맵과 유사하나 시크릿과 컨피그맵의 차이점으로는 조회할 때 DATA의 내용이 암호화(base64) 되어있는지 여부이다. 물론 시크릿에서도 stringData 항목을 추가해 base64로 인코딩 되지 않은 데이터를 담는것도 가능하다.
• secret 볼륨을 통해 컨테이너에 secret을 노출하면 자동으로 디코딩되어 파일에 기록되기 때문에 파드에서는 파일 내용을 바로 읽어 사용이 가능하다.
• 파드에서 secret 볼륨 마운트 및 사용예시)
  
• 프라이빗 리포지토리에서 자격증명을 통해 이미지를 마운트 시키는 경우 다음과 같이 이미지 풀 시크릿 항목을 사용한다. 하지만 매번 파드에서 이미지를 가져올 때 시크릿을 지정해주기 어렵기 때문에 서비스 어카운트에 추가해 추가해 모든 파드에 자동으로 추가해준다고 한다.
  

💡결론

- 컨피그맵과 시크릿은 애플리케이션 자체에 설정을 포함하지 않도록 하기 위한 쿠버네티스 API 오브젝트이다. 둘의 사용방법은 유사하며 secere의 data 항목이 base64로 인코딩되어있는것이 차이점이다.

- 파드 옵션에 명령줄인수, 환경변수, 볼륨(컨피그맵 or 시크릿)을 통해 설정 정보를 파드에 전달한다.