아래의 연습문제를 풀다보니 configmap에 대한 개념이 필요했다. 공부해보자
일단 쿠버네티스 configmap이란 뭘까?
공식 사이트의 내용을 인용하면 기밀의 아닌 정보를 key-value 쌍으로 저장하는 API 오브젝트라고 한다. 민감한 데이터는 secret으로 저장하고 그렇지 않은 env 환경설정 값등을 넣기위한 쿠버네티스 서비스인거 같다.
또한 동일한 의미로 컨테이너에서 필요한 환경설정 내용을 컨테이너와 분리해서 제공해 주기 위한 기능을 많이 쓰인다.
예를들어서 개발/운영에 동일한 container는 동일한 것을 써야하지만, 개발은 개발DB, 운영은 운영DB 접속등과 같이 일부 Config를 달리해줘야하는 부분이 있다. 이때 configmap에 개발/운영에 대한 DB정보를 저장하고 pod를 생성할 때 해당 configmap을 참조하면 된다.
- 근데 configmap은 중요정보가 아닌것을 일반적으로 저장하기때문에 DB 접속 정보는 적절하지 않다.
configmap 생성은 어떻게할까?
아래와 같이 yaml의 형식을 같는다. apiVersion, kind, metadata까지는 여느 다른 yaml과 동일하다.
configmap은 위에서도 말했듯이 key-value 쌍으로 데이터를 저장하는 서비스이다. 그렇기에 yaml 파일에 내가 저장할 data:를 넣는다.
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
위 yaml로 configmap을 만들면, "game-demo"의 configmap이 저장하고 데이터는 아래와 같이 저장된다.
저장되는 데이터는 Data 하위에 저장되며 ---을 기점으로 key, value가 구분된다.
그리고 configmap에 저장할 key-value를 --from-file을 파라미터를 통해서 파일의 형태로 전달받을 수도 있다.
파일로 전달받으면 key는 파일명이 되고, value는 해당 파일의 데이터가 된다.
kubectl create -n kube-system configmap my-scheduler-config --from-file=/root/my-scheduler-config.yaml
[/root/my-scheduler-config.yaml]
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: my-scheduler
leaderElection:
leaderElect: false
아래 configmap을 보면 value 부분에 custom scheduler을 생성하기 위한 yaml 정보를 가지고 있다.
configmap은 어떻게 사용할까?
구글링해서 찾아본 이미지중에 한눈에 와닿는 이미지는 아래의 이미지이다. pod를 배포할 때 configmap에 저장된 값을 불러온다.
pod를 생성할 때 envFrom: -configMapref: name으로 configmap 정보를 불러올 수 있다. 아래 예시는 special-config name으로 저장되어 있는 configmap 를 불러와서 사용하는 예시이다.
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: registry.k8s.io/busybox
command: [ "/bin/sh", "-c", "env" ]
envFrom:
- configMapRef:
name: special-config
또는 Deployment를 만들때 아래와 같이 만들 수 있다. 아래와 같이 하게되면 실제 운영에 배포할 때는 configMapRef의 name만 운영의 이름으로 변경해서 배포하면 큰 변화없이 개발/운영을 구분하여 배포할 수 있다!!!
apiVersion: apps/v1
kind: Deployment
metadata:
name: configapp
labels:
app: configapp
spec:
replicas: 1
selector:
matchLabels:
app: configapp
template:
metadata:
labels:
app: configapp
spec:
containers:
- name: testapp
image: arisu1000/simple-container-app:latest
ports:
- containerPort: 8080
envFrom:
- configMapRef:
name: config-dev
'기술 이모저모 > [K8s] Kubernetes' 카테고리의 다른 글
[k8s] Kubernetes DaemonSet vs StaticPod 개념[2/2] (0) | 2022.10.22 |
---|---|
[k8s] Kubernetes DaemonSet vs StaticPod 개념[1/2] (0) | 2022.10.22 |
[k8s] KodeKloud Practice test - Static pod (0) | 2022.10.20 |
[k8s] Kubernetes Container Resources request, limit 방법 (0) | 2022.10.10 |
[k8s] KodeKloud Practice test - Resouce Limis (0) | 2022.10.10 |