네임스페이스(Namespace)
컨테이너와 그와 관련된 리소스를 구분지어 관리할 수 있는 일종의 논리적 그룹
기본 개념
쿠버네티스 설치시 기본적으로 3개의 네임스페이스 존재
•
default : 별도로 지정하지 않았을때 기본적으로 사용됨 (--namespace 옵션 명시 하지 않으면)
•
kube-system: 쿠버네티스 클러스터 구성하는 필수 컴포넌트와 설정값 존재 (kube-dns, kube-proxy 등 )
•
kube-public: 모든 사용자에게 읽기 가능한 네임스페이스. 보통 클러스터 내부 공용 정보 공유용
네임스페이스는 서로 다른 프로젝트, 팀, 환경(개발, 스테이징, 운영 등) 간 리소스를 논리적으로 격리할 수 있어 대규모 클러스터 운영에 유용하다.
사용
# 네임스페이스 생성
kubectl create namespace production
# 생성된 네임스페이스들 확인
kubectl get namespaces
# 삭제
kubectl delete namespace production
Bash
복사
네임스페이스의 서비스 접근
쿠버네티스 내부에서 다른 네임스페이스에 있는 서비스를 호출할 때는 다음과 같이 DNS 형식을 사용한다:
<서비스이름>.<네임스페이스이름>.svc.cluster.local
# production 네임스페이스에 있는 db-service에 연결한다면
db-service.production.svc.cluster.local
Bash
복사
컨피그맵 (Configmap), 시크릿 (Secret)
YAML 파일과 환경 설정값을 분리해 관리할 수 있도록 도와주는 오브젝트
컨피그 맵을 왜 사용할까?
# 1. deployment_production.yaml
spec:
containers:
- name: my-webserver
env:
- name: LOG_LEVEL
value: INFO
# 2. deployment_development.yaml
spec:
containers:
- name: my-webserver
env:
- name: LOG_LEVEL
value: DEBUG
YAML
복사
위와같이 운영과 개발 환경의 yaml 파일에 환경변수 각각 정의해 사용하면 두개의 파일이 존재하게 된다.
하지만 아래와 같이 컨피그맵 사용하면 1개의 yaml 파일만을 사용해 환경에 따라 다른 컨피그맵 생성해 사용가능하다.
spec:
containers:
- name: my-webserver
env:
valueFrom:
configMapKeyRef:
name: log-level-configmap# (production 일때 INFO, develop 일때 DEBUG)
key: LOG_LEVEL
YAML
복사
컨피그맵
•
애플리케이션이 필요로 하는 환경 변수, 설정 파일 등을 키-값 쌍으로 저장
•
네임스페이스 별로 컨피그맵 존재하며, 하나의 컨피그맵을 여러 pod에서 참조
•
컨피그 맵은 두가지 방식으로 사용 할 수 있음
1. 컨피그맵 값을 컨테이너의 환경변수로 사용
•
컨피그 맵에 저장된 키-값 데이터가 컨테이너 환경 변수의 키-값으로 그대로 사용.
•
애플리케이션에서 시스템 환경변수로부터 설정값을 가져온다면 이 방법이 좋음
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: production
data:
LOG_LEVEL: debug
APP_MODE: production
YAML
복사
•
data: 키-값으로 설정값을 저장
◦
LOG_LEVEL: 로그 수준을 나타내는 환경변수 (예: debug, info)
◦
APP_MODE: 애플리케이션의 동작 모드를 정의 (예: production, development)
apiVersion: v1
kind: Pod
metadata:
name: sample-pod
namespace: production
spec:
containers:
- name: app-container
image: my-app:latest
envFrom:
- configMapRef:
name: app-config
YAML
복사
•
envFrom: 컨피그맵의 모든 키-값 데이터를 컨테이너 환경변수로 주입해줌.
•
즉, 컨테이너가 시작되면 환경변수 LOG_LEVEL=debug, APP_MODE=production을 갖게됨.
2. 컨피그맵의 값을 pod 내부의 파일로 마운트해 사용
•
컨피그맵 값을 pod 컨테이너 내부의 특정 파일로 마운트해 사용 (ex. etc/config/log_level)
•
애플리케이션이 nginx.conf 같은 파일을 통해 설정값을 읽는다면 이 방법이 좋음
apiVersion: v1
kind: ConfigMap
metadata:
name: log-config
namespace: production
data:
log_level: debug
log_format: json
YAML
복사
apiVersion: v1
kind: Pod
metadata:
name: log-reader
namespace: production
spec:
containers:
- name: reader
image: log-reader:latest
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: log-config
items:
- key: log_level
path: log_level.txt
YAML
복사
•
volumeMounts: 컨테이너 내부의 /etc/config 경로에 볼륨을 마운트함
•
volumes: 실제 볼륨 정의 부분
◦
configMap.name: 연결할 컨피그맵 이름
◦
configMap.items:
▪
컨피그맵의 특정 키만 파일로 노출할 때 사용
▪
여기서는 컨피그맵 내의 log_level이라는 키의 값을 컨테이너 내부에서 log_level.txt 파일로 마운트하는 예제
▪
위 pod 실행시 /etc/config/log_level.txt 파일을 갖게됨
시크릿
•
비밀번호, API 키, 인증서 등 민감한 정보를 저장하기 위한 용도로 사용하는 오브젝트
•
컨피그맵과 다르게 모든 값을 base64 인코딩해 저장
apiVersion: v1
kind: Secret
metadata:
name: db-secret
type: Opaque
data:
username: YWRtaW4=# admin을 base64 인코딩한 값
password: c2VjcmV0MTIz# secret123을 base64 인코딩한 값
YAML
복사
apiVersion: v1
kind: Pod
metadata:
name: secret-pod
spec:
containers:
- name: app
image: my-app:latest
env:
- name: DB_USER
valueFrom:
secretKeyRef:
name: db-secret
key: username
- name: DB_PASS
valueFrom:
secretKeyRef:
name: db-secret
key: password
YAML
복사
•
컨테이너가 시작하면 DB_USER=admin, DB_PASS=secret123 환경변수를 가지게 됨
•
valueFrom.secretKeyRef로 시크릿에 저장된 키 값을 직접 참조해 사용하는 방식
이미지 레지스트리 접근을 위한 시크릿(docker-registry 타입)
•
비공개 레지스트리(ECR, Docker Hub 등..) 접근할때 사용하는 인증정보를 시크릿으로 저장하고 이를 imagePullSecrets 필드에서 사용하는 방식
apiVersion: v1
kind: Pod
metadata:
name: private-registry-pod
spec:
containers:
- name: private-app
image: myuser/private-app:latest
imagePullSecrets:
- name: registry-auth-secret
YAML
복사
컨피그맵이나 시크릿 업데이트 시 애플리케이션 설정 변경
컨피그맵이나 시크릿을 수정해도 기존 파드는 자동으로 반영되지 않기 때문에 직접 pod을 재시작 하던지, 시크릿 데이터의 변경에 대한 알림을 받아 자동으로 리로드하는 로직을 추가할 수도 있음