Cloud Architect/Kubernetes

Kubernetes Object [Part 04]

"Everything about infra" 2025. 7. 18. 18:30

지난 포스팅에 이어 Object에 대해 마지막 포스팅이 될 것 같습니다.

이 외에도 여러 Object가 있지만 대표적인 것들을 기본적으로 다루어보았고,

추 후에는 이 Object들을 묶어서

하나의 Side Project를 진행하려고 합니다 :)

 

01. ConfigMap

  • 워크로드에 필요한 설정 정보를 key-value 형태로 저장할 수 있는 데이터 오브젝트
  • 간단한 환경변수 부터 nginx.conf 와 같은 설정 파일도 저장 가능.

ConfigMap을 작성하여 Pods에 적용할 수도 있고, 일부 설정값만 적용할 수 있다.

 

💁‍♂️ 주요 특징

 

1. 설정 데이터 저장

  • 환경 변수, 명령줄 인자, 설정 파일 등 다양한 형태의 설정 정보를 저장할 수 있다.

2. 애플리케이션과 분리

  • 설정을 코드와 분리하여 관리함으로써 동일한 App의 Image를 여러 환경(prod, dev, stg)에서 다르게 설정 O

3. 네임스페이스 단위 관리

  • ConfigMap은 특정 네임스페이스에 속하며, 같은 namespace내의 Pods에서 참조 가능.

 

■ ConfigMap 생성

# 직접 cli 형태로 값을 지정하여 생성
kubectl create configmap --save-config test2-config --from-literal=app=blue --from-literal=connection.max=100
kubectl get configmap test2-config -o yaml | yq .data

# file에서 값을 참고하여 생성 (nginx.conf 파일이 존재했을 때 가정)
kubectl create configmap --save-config test3-config --from-file=nginx.conf
kubectl get configmap test3-config -o yaml | yq .data

 

위 이미지를 참고하였을때, ConfigMap을 생성 후 Pods에 Mount하여 사용할 수 있다.

 

02. Secret

  • 워크로드에 필요한 민감 정보를 key-value 형태로 저장할 수 있는 데이터 오브젝트
    • 예) DB정보, 인증서, API token 등.
  • base64 incording 상태로 저장한다.

ConfigMap과 동일하게 Pods 내부에 적용 가능하다.

 

💁‍♂️ 사용하는 이유

애플리케이션 개발에서 민감한 정보를 Source code에 직접 하드코딩 하거나, Container Image에 포함하는 것은

보안상 매우 위험하다. Secret은 이러한 취약점을 해결해준다 !!!

 

  • 보안 강화: 민감한 데이터가 코드나 설정 파일에 노출되는 것을 방지합니다.
  • 재사용성: 동일한 Secret을 여러 파드에서 재사용할 수 있습니다.
  • 관리 용이성: 모든 민감한 정보를 중앙 집중식으로 관리할 수 있어 보안 정책 적용 및 감사에 용이합니다.
  • 개발/운영 분리: 개발자는 애플리케이션 로직에 집중하고, 민감한 정보는 Secret을 통해 운영 환경에서 관리

 

■ 데이터 저장 방식

Base64 방식으로 incording 되어 저장되며, 완전한 암호화 방식이 아니라 단순히 사람이 읽을 수 없는 형태임.

echo -n 'my-secret-password' | base64
# 결과: 'bXktdGlwb2RrLXVhc3N3b3Jk'

 

💁‍♂️ 보안 관리 필요!

 

1. etcd 암호화

  • 쿠버네티스 클러스터의 상태 정보가 저장되는 etcd는 기본적으로 암호화되지 않습니다. etcd 데이터를 안전하게 보호하려면 etcd 스토리지를 암호화하거나, 데이터를 안전하게 저장하는 방법을 구현해야 한다.

2. 권한 관리 (RBAC 방식)

  • Secret은 Pod와 마찬가지로 쿠버네티스 RBAC(Role-Based Access Control)에 의해 보호됩니다. 특정 사용자나 서비스 계정만이 Secret에 접근할 수 있도록 적절한 권한을 부여해야 한다.

3. 외부 서드파티 솔루션 활용

  • Sealed Secrets, HashiCorp Vault와 같은 서드파티 솔루션을 사용하여 Secret에 대해 생성, 회전(Rotation), 감사(Audit) 등 더욱 강력하게 암호화하고 관리하는 것이 좋다.

 

■ Secret 생성

# 직접 cli 형태로 값을 입력하여 생성
kubectl create secret generic --save-config test2-secret --from-literal password=test123
kubectl get secret test2-secret -o yaml | yq .data

# 디코딩
echo -n '<인코딩 된 secret>' | base64 -d

# file에서 값을 참고하여 생성
vi db-secret.txt

data:
	DB_HOST: test
	DB_PASSWORD: test123

kubectl create secret generic --save-config test3-secret --from-env-file db-secret.txt
kubectl get secret test3-secret -o yaml | yq .data

 

03. Volume

  • 스토리지 볼륨을 추상화하여 pod와 느슨하게 결합시킨 Resource
  • 미리 생성이 되어있는 사용가능한 볼륨을 Pod에서 정적으로 정의하여 사용한다.
  • Container-Level 에서 사용된다.

💁‍♂️ Volume 이란?

Kubernetes에서 Container는 임시적이다. 즉, Container가 재시작될 때마다 새로운 상태로 시작되며,

내부에 있는 모든 데이터가 사라지게 됩니다. 이런 Container의 휘발성 때문에 영구적인 Data 저장 공간이 필요하며

이 목적 달성을 위해 Kubernetes에서 Volume 이라는 추상화 개념을 제공하게 되었다.

 

또한, 동일한 Pod내에 여러 Container들이 동일한 file이나 data를 공유해야할 때가 있다.

예를들어 웹서버와 로그 수집 Agent가 같은 Volume을 공유하여 서로간에 접근 및 공유가 가능하다 !!

 

■ 주요 Volume Type

 

1. emptyDir

  • Pod가 생성될 때 함께 생성되는 빈 Directory.
  • Pod가 존재할때만 유효하며, Pod가 종료되면 emptyDir의 내용도 함께 사라진다.
  • 주로 Pod내 Container간 임시 데이터 공유 공간으로 사용됨.

 

2. hostPath

  • Node의 file system 경로를 Pod에 Mount하여 사용된다.
  • Pod내의 Container는 Node의 특정 Directory에 접근 가능하다.
  • Pod가 다른 Node로 스케줄링되면 이전에 저장했던 데이터에 접근할 수 없으므로 주의해야함.

운영 환경에서는 많이 쓰이지 않는 방식이긴 하다.

 

■ Volume의 한계

  • 컨테이너 자신만 접근 가능한 비영구적 볼륨이기 때문에 컨테이너가 재시작할때 유지할 수 없다.
  • kubernetes 클러스터 레벨에서 볼륨을 관리하기 어려움
  • volume이 변경될때마다 해당 volume을 사용하는 모든 파드의 설정 변경이 필요함

 

3-1. Persistent Volume (PV)

  • Kubernetes에서 영구 스토리지를 사용하는 표준적인 방법.
  • 추상화된 가상의 Volume Object로 별도로 정의 및 생성하여 Pod와 연결한다.
  • Pods-Level에서 사용된다.

 

💁‍♂️ PV 란?

Cluster 관리자가 프로비저닝 하거나, StorageClass를 통해 동적으로 프로비저닝되는 Cluster Storage Resource.

예시로 AWS EBS, Azure Disk, NFS 등이 있다고 참고하자.

 

💁‍♂️ PVC 란?

  • Persistent Volume Claim이라고 하며 사용자가 PV를 요청하고 binding 하기 위한 Resource.
  • Pod가 Storage를 필요로할 때 PVC를 통해 원하는 스토리지 용량, 접근모드 등을 선언하여 요청한다.
    • 접근 모드에는 ReadWriteOnce, ReadOnlyMany, ReadWriteMany가 있음.

 

■ 동작 방식

사용자가 PVC를 생성 → Kubernetes는 해당 요구사항을 만족하는 PV를 찾아 자동으로 Binding →

Pods는 PVC를 참조하여 Storage를 사용하게 된다.

 

3-2. StorageClass

  • PV를 조금 더 효율적으로 사용하는 방법이며 동적 스토리지 프로비저닝을 위한 오브젝트

💁‍♂️ SC 란?

관리자가 다양한 유형의 스토리지 (HDD, SSD, 고성능, 저비용 등)를 정의해놓으면, 사용자가 PVC에서

특정 StorageClass를 지정하여 해당 속성에 맞는 PV를 자동으로 생성할 수 있다.

 

■ SC 정의

SC를 정의하여 Cloud 환경의 Storage를 사용

 

즉, 동적 프로비저닝을 사용하려면?

 

조건 01.Cluster 내에 StorageClass 리소스가 정의되어 있어야 한다.

조건 02. StorageClass에 정의된 프로비저너가 Cluster에 배포되어 실행중이어야 한다.

조건 03. 이 프로비저너는 Cloud 제공업체의 API등을 호출하여 실제 Storage 볼륨을 생성하고 PV 리소스로

추상화하는 역할을 한다.

 

PV와 SC 관계 요약

  • Kubernetes 스토리지 모델의 핵심 목표는 스토리지 제공자(infra 팀), 사용자(Application 개발자)의 역할을 분리하고 추상화 하는 것이다.

💁‍♂️ 스토리지 제공자 (Cluster 관리자 / infra 팀)

  • 다양한 유형의 스토리지(SSD, HDD, 네트워크 파일 시스템 등)를 클러스터에 연결하고 설정.
  • 이러한 스토리지 유형을 StorageClass 라는 리소스로 정의합니다. (예: gold-ssd, silver-hdd, nfs-shared). 각 StorageClass는 해당 스토리지의 특징, 성능, 그리고 실제 스토리지를 생성하는 방법(Provisioner)을 담고 있다.
  • 정적 프로비저닝의 경우, 미리 PV를 생성해두기도 합니다.

💁‍♂️ 스토리지 사용자 (Application 개발자)

  • 자신이 개발하는 애플리케이션(파드)이 데이터를 저장하기 위해 필요한 스토리지 "요구사항"을 명세한다.
  • 이 요구사항을 PersistentVolumeClaim (PVC) 이라는 리소스로 정의합니다. PVC는 단순히 "나 (예: 10Gi) 만큼의 공간이 필요해, (예: gold-ssd 같은) 고성능 스토리지가 좋아" 와 같은 추상적인 요청입니다. 개발자는 스토리지의 실제 물리적 위치나 복잡한 설정에 대해 알 필요가 없다 !!!

 

Kubernetes Object Part를 읽어봐주셔서 감사드리며,

기본적인 내용을 담고 있으므로 추 후 Deep한 내용으로 Project에서 찾아뵙겠습니다 :)