Configmap

• 어플리케이션에 필요한 환경 변수들을 별도로 관리할 수 있는 파일 오브젝트
• namespace별로 구분지어 사용, Pod나 Deployment 파일을 환경별로도 분리할 수 있겠지만, 환경 변수 같은 경우엔 별도 Configmap로 관리할 수 있다
• Configmap도 YAML 파일로 간단히 생성할 수 있고, Pod, 컨테이너에선 YAML에 같이 적용시켜주면 된다

...
spec:
	containters:
	- name: test-container
		image: busybox
		envFrom:
		- configMapRef:
				name: test-configMap

• 위 예시에선 Container 아래 envFrom, configMapRef로 선언하여 test-configMap이란 네임의 Configmap을 참조하도록 설정한 것
• 파일뿐만 아니라 환경 변수만으로도 직접 YAML에 추가해 사용할 순 있지만, 별로 효율적인거 같진 않다
• 그 외 Pod의 환경 변수 참조 뿐만 아니라 Pod 내 Volume에 마운트하여 저장소에서 참조할 수 있게 설정도 가능

Secret

• Configmap과 비슷하지만 어플리케이션에 있어서 노출되면 안되는 정보를 넣어주는 설정 파일 오브젝트
• YAML로 적용하는 방식은 Congifmap이랑 거의 동일하다, envFrom에서 secretRef만 다를뿐

...
spec:
	containters:
	- name: test-container
		image: busybox
		envFrom:
		- secretRef:
				name: my-test-secret

• 다만 Secret은 Configmap과 다르게 다른 용도로도 사용할 수 있다

  • 어플리케이션 내 도커 이미지를 사설 레지스트리에서 가져오기 위해 인증 정보가 필요할 때
  • 어플리케이션이 TLS 연결을 위한 인증 정보가 필요할 때

• Configmap도 그렇고 Secret도 내용이 많아지면 그만큼 YAML 파일도 커지게 되는데, 이는 YAML 파일의 본 내용과 실제 설정할 데이터들과 관리가 안될 수 있다

  • 그래서 쿠버네티스에선 설정 데이터를 YAML로 분리할 수 있는 kustomize 기능을 제공한다고 한다
  • 아래는 Secret 관련 데이터를 따로 YAML로 작성을 하였는데

  secretGenerator:
  - name: kustomize-test-secret
  	type: kubernetes.io/tls
  	files:
  	- tls.crt=cert.crt
  	- tls.key=cert.key
  

  • YAML 작성 후 apply를 하면 바로 Secret을 생성할 수 있다, 이때 디렉토리는 Secret 관련 데이터를 작성한 파일의 디렉토리에 위치해야 한다

  $ kubectl apply -k ./