이번글에서 Pod의 기능정리에 대해서 마무리해보겠습니다.
🦄 컨테이너 2개 실행
지금까지는 1개의 컨테이너만 사용하여 실습왔습니다.
Pod내에는 1개이상의 컨테이너를 가질수 있는 최소실행단위라고 했었습니다.
그럼 2개의 서로다른 컨테이너를 만들어 실습해보겠습니다.
second.yaml
apiVersion: v1
kind: Pod
metadata:
name: second
spec:
containers:
- name: nginx
image: nginx
- name: curl
image: curlimages/curl
command: ["/bin/sh"]
args: ["-c", "while true; do sleep 5; curl localhost; done"]지금까지 containers property에는 1개의 컨테이너만 명세했었지만, 리스트에 여러 컨테이너정보를 넣어서 2개의 이상의 컨테이너를 가진 Pod를 생성할 수 있습니다.
Pod를 생성하고 logs 명령을 사용하면 error 메세지가 출력됩니다.
메세지 끝부분에 [nginx curl] 리스트에 두개의 컨테이너 중 하나를 선택해달라고 합니다.
따라서 어떤 컨테이너의 로그를 측정할 지 -c옵션으로 컨테이너name을 명시해주어야 합니다.
curl 컨테이너로 바꿔서 해보겠습니다.
처음 실행하면 5초 대기 후 실행이 됩니다.
쿠버네티스는 Pod내부 컨테이너끼리 실행 순서를 보장하지 않습니다.
따라서 nginx컨테이너가 정상적으로 서비스가 올라오고 curl을 호출하게 만든 목적으로 대기합니다.
🔁 컨테이너 초기화
Pod내에 컨테이너 중 첫번째 컨테이너가 먼저 실행된다는 보장은 없습니다.
그렇다면 메인 컨테이너가 실행되기 전에 미리 컨테이너를 초기화 하는 법을 알아보겠습니다.
initContainers property를 사용하면 컨테이너 초기화 작업을 할 수 있습니다.
init-container.yaml
initContainers는 위에서 말했다시피 메인 컨테이너 실행전, 먼저 초기화를 위해 실행되는 컨테이너를 명세합니다.
위에 명세서를 분석하자면, 메인 컨테이너가 실행하기 전에 git 리포지토리를 갖고있어야한다면, 초기화 컨테이너에서 먼저 git pull을 받아 컨테이너끼리의 공유 공간인 emptyDir볼륨(/tmp)에 git 리포지토리를 전달합니다.
그 뒤 메인 컨테이너는 git 리포지토리가 있다고 가정하고 로직을 수행합니다.
🎛️ Config
쿠버네티스에는 설정값들을 따로 모아두고 필요할 때 꺼내 사용할 수 있는 메커니즘이 존재합니다.
이 설정값들이 모아둔 곳을 ConfigMap이라고 합니다.
이번 실습에서는 ConfigMap에 값들을 불러와서 Pod에 전달하는 법을 알아보겠습니다.
🧬ConfigMap 리소스 생성
지금까지 Pod에 직접 설정값(metadata)을 작성했지만 ConfigMap에 모든 설정값들을 저장해서 Pod에서 필요한 값만 불러오게 할 수 있습니다.
ConfigMap을 생성하는 기본 포맷입니다.
$ kubectl create configmap <key> <data-source>game.properties
weapon=gun
health=4
potion=2게임 설정 파일을 하나 만들어 봅니다.
--from-file옵션을 사용하여 game.properties 파일을 game-config라는 이름의 ConfigMap으로 만들어 보겠습니다.
$ kubectl create configmap game-config --from-file=game.properties
ConfigMap을 상세 조회 해봤습니다.
data는 설정값들이 저장된 데이터입니다.
--from-literal이라는 옵션을 사용하여, ConfigMap을 생성해보겠습니다.
-literal옵션은 사용자가 직접 설정값을 지정합니다.
사용자가 직접 ConfigMap리소스를 YAML명세서로 만들 수도 있습니다.
monster-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: monster-config
namespace: default
data:
monsterType: fire
monsterNum: "5"
monsterLife: "3"
🧣ConfigMap 활용
💡볼륨 연결
ConfigMap을 볼륨으로 마운트하여 파일처럼 사용할 수 있습니다.
game-volume.yaml
volumes는 Pod에서 사용할 볼륨을 지정하고, configMap이라는 볼륨 종류에서 name이 game-config인 볼륨을 사용하겠다는 뜻입니다.
game.properties라는 파일로 만든 ConfigMap을 동일하게 파일로 볼륨 마운트해서 활용하는 방법이였습니다.
💡valueFrom
ConFigMap을 Pod의 환경변수로도 사용할 수 있습니다.
special-env.yaml
env : 환경변수 사용
name : 환경변수 키값
valueFrom : 다른 리소스를 참조할때 사용
configMapKeyRef : ConfigMap을 참조하겠다는 의미
- name : 참조할 ConfigMap이름
- key : ConfigMap의 특정 설정값 선택
앞에서 만든 special-config라는 이름의 ConfigMap을 선택하고 special.power를 환경변수로 사용하게 됩니다.
💡envFrom
ConfigMap에 포함된 모든 설정값을 환경변수로 사용하는 법에 대해 실습해보겠습니다.
Monster-env.yaml
envFrom은 env를 대신해서 사용하는 property입니다.
valueFrom과는 다르게 configMapRef의 name까지만 정의해서 ConFigMap전체를 사용합니다.
monster-config ConfigMap에 설정된 모든 값들이 환경변수로 설정되었습니다.
🔒중요데이터 관리
Secret리소스는 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 갖는 리소스로서 Pod 명세서나 컨테이너 이미지에서 중요한 정보를 포함시키길 원치않을 때 사용하는 리소스입니다.
🚨주의사항
쿠버네티스 Secret리소스는 기본적으로 API서버의 etcd에 암호화되지 않은 상태로 저장됩니다.
Api접근 권한이 있는 사용자나 etcd접근할 수 있는 모든 사용자는 Secret을 조회/수정할 수 있습니다.
또는 네임스페이스에서 Pod를 생성할 권한이 있어도 해당 접근을 사용하여 네임스페이스의 모든 Secret을 읽을 수 있습니다.
💿Secret리소스 생성
먼저 임의로 사용할 계정이름과 비밀번호로 만들어 base64로 인코딩해보겠습니다.
위에서 얻은 값을 이용해서 Secret리소스를 생성하겠습니다.
user-info.yaml
type은 여러 종류가 있지만 기본적으로 Opaque를 사용합니다.
data에 중요 데이터 값을 정의합니다.
data에 값들을 base64로 직접 인코딩하지 않고 쿠버네티스가 대신 처리할 수도 있습니다.
user-info-stringdata.yaml
data -> stringdata를 사용합니다.
선언형 커맨드인 yaml말고도 명령형 커맨드를 사용해서 Secret리소스를 생성할 수도 있습니다.
user-info.properties
username=admin
password=password123위 파일을 생성 후 --from-env-file옵션을 사용하여 properties파일 정보로 Secret리소스를 생성합니다.
💫Secret 활용
Secret의 사용처에 관련된 예제들을 몇개 알아보겠습니다.
💡볼륨 연결
Secret도 ConfigMap와 마찬가지로 볼륨 연결이 가능합니다.
secret-volume.yaml
환경변수 활용도 ConfigMap과 유사합니다.
💡valueFrom
secret-env.yaml
💡envFrom
secret-envfrom.yaml
🖼️metadata 전달
앱이 실행되기 전에 이미 알고있는 속성, 설정 값들은 ConfigMap이나 Secret리소스로 파드에 전달할 수 있지만, 파드가 생성 및 실행 되기전에는 알 수 없는 속성들도 존재합니다.
ex) Pod의 이름, IP, Pod내의 node정보 등
이런 Pod의 metadata를 컨테이너에게 전달하는 것을 Downward API라고 합니다.
ConfigMap, Secret처럼 볼륨과 환경변수 연결을 통해서 컨테이너에 정보를 전달할 수 있습니다.
💡볼륨 연결
downward-volume.yaml
downwardAPI : 볼륨 종류
items: 메타데이터로 사용할 아이템 리스트를 지정
- path: 볼륨과 연결할 컨테이너 내부 path 지정
- fieldRef: 참조할 필드
- fieldPath: Pod의 메타데이터 필드를 지정
Pod의 라벨 필드를 컨테이너의 지정한 path위치에 볼륨을 연결했습니다.
items[0].path를 labels로 지정해서 파일이름이 labels로 사용됩니다.
💡valueFrom
downward-env.yaml
fieldPath에 지정해놓은 정보들을 환경변수로 확인할 수 있습니다.
🖐️to be continue
이번 포스트를 마지막으로 쿠버네티스의 가장 기본이 되는 Pod에 대해 핵심 기능들을 알아봤습니다.
이후에 공부할 리소스들 역시 Pod기반으로 확장되어 나오기 때문에 Pod에 대해 깊은 이해도가 필요합니다.
다음 포스트부터는 Service리소스를 실습해보겠습니다.
$ kubectl delete pod --all #생성한 모든 pod를 삭제합니다.