[Kubernetes] 쿠버네티스의 리소스 관리와 설정

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.
 

Kubernetes

---

이번 포스팅에서는 지금까지 배운 쿠버네티스의 오브젝트들인 파드, 레플리카셋, 디플로이먼트, 서비스와 같은 리소스들을 효율적으로 관리할 수 있도록 하는 것들에 대해 배워보도록 하자. 그 중에서도 이번 포스팅에서는 네임스페이스, 컨피그맵, 시크릿의 사용 방법에 대해 소개하려고 한다.

1. 리소스를 구분하는 장벽, 네임스페이스(Namespace)

이전에 배웠던 도커나 도커 스웜을 배웠을 때는 배포한 컨테이너들을 논리적으로 구분하는 방법이 없었다. 예를 들어, 100개의 도커 컨테이너를 배포한 후, docker ps -a 명령어를 사용하면 배포한 100개의 컨테이너들이 모두 출력이 되었다. 물론 key : value 형태로 컨테이너에 레이블을 붙여 일종의 필터링을 적용할 수 있긴 하지만, 좀 더 명확하게 컨테이너들을 구분하는 방법은 없었다.

 

하지만 쿠버네티스는 용도나 목적에 따라 파드, 레플리카셋 등과 같은 컨테이너와 관련된 리소스들을 구분 지어 관리할 수 있는 별도의 오브젝트가 존재한다. 바로 네임스페이스 오브젝트이다. 만약 여러 개발 조직이 하나의 쿠버네티스 클러스터를 공유해 사용해야 한다면 조직별로 네임스페이스를 구성해서 각 네임스페이스에 각 조직이 사용하는 파드, 디플로이먼트, 서비스 등과 같은 리소스들을 설정할 수 있다. 네임스페이스는 마치 하나의 클러스터 내부에 여러 개의 가상 클러스터를 동시에 사용하는 느낌이다.(물론 실제로 가상 클러스터를 구축하는 것은 아니다. 오해하지 말자)

 

네임스페이스를 좀 더 제대로 이해하기 위해서 실습과 같이 진행해보자. 일단, 기본적으로 쿠버네티스에서 아무런 설정을 해주지 않으면 아래와 같이 4개의 네임스페이스가 설정되어 있다.

 

쿠버네티스에서 기본적으로 사용하는 네임스페이스들

 

위에서 보여지는 네임스페이스들 각각에 파드, 레플리카셋, 디플로이먼트, 서비스와 같은 리소스가 따로 존재하게 된다. 우리가 쿠버네티스를 설치하고 생성하는 리소스 오브젝트들은 기본적으로 default 라는 네임스페이스에 할당된다. 만약 특정 네임스페이스에만 존재하는 리소스들을 보려면 --namespace 옵션을 넣어 주면 된다.

 

$ kubectl get pods --namespace kube-system
$ kubectl get pods -n kube-system

 

참고로 위에서 설정한 kube-system 이라는 네임스페이스는 쿠버네티스 클러스터 구성에 필수적인 컴포넌트들과 설정값들이 존재하는 네임스페이스이다. 

 

그렇다면 여기서 네임스페이스와 라벨 간의 차이점에 대해 궁금해할 수 있다. 여기서 '라벨'이라 함은 우리가 이전에 파드와 레플리카셋 간에 연결해주도록 한 라벨 셀렉터(Label Selector)이다. 결론은 네임스페이스가 라벨보다 더욱 넓은 용도로 사용할 수 있다. 예를 들어, ResourceQuota 라는 오브젝트를 이용해 특정 네임스페이스에서 생성되는 파드의 자원 사용량을 제한하거나, 애드미션 컨트롤러라는 기능을 이용해서 특정 네임스페이스에 생성되는 파드에는 사이드카 컨테이너를 붙일 수 있도록 한다던지가 가능하다. 또한 모니터링, 로드 밸런싱 인그레스 등의 특정 목적을 위해서도 사용하기도 한다.

1-1. 네임스페이스 생성하기

그러면 이제 YAML 파일 또는 명령어를 이용해 네임스페이스를 생성해보자. 사용한 YAML 파일 내용은 아래와 같다.

 

apiVersion: v1
kind: Namespace
metadata:
  name: zedd-default

 

YAML 파일을 통해 네임스페이스를 생성할 때도 kubectl apply 명령어를 사용하면 된다. 만약에 명령어로 네임스페이스를 직접 생성하고 싶다면 아래처럼 실행하면 된다.

 

$ kubectl create namespace zedd-default

 

이제 그러면 위에서 생성한 네임스페이스에다가 디플로이먼트, 서비스 같은 오브젝트들을 생성해보자. 아직은 생성한 네임스페이스에 할당된 리소스가 없는 상태다.

 

 

이제 디플로이먼트, 서비스를 생성하는 YAML 파일은 아래와 같다. 해당 파일은 기존에 실습할 때 사용하던 것과 동일하되, 네임스페이스 설정하는 부분만 추가되었다.

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname-deployment-ns
  namespace: zedd-default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      name: my-webserver
      labels:
        app: webserver
    spec:
      containers:
      - name: my-webserver
        image: alicek106/rr-test:echo-hostname
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: hostname-svc-clusterip-ns
  namespace: zedd-default
spec:
  ports:
    - name: web-port
      port: 8080
      targetPort: 80
  selector:
    app: webserver
  type: ClusterIP

 

위 YAML 파일로 파드가 잘 생성되었는지 살펴보기 위해서 모든 네임스페이스의 파드를 출력해보도록 하자. --all-namespaces 옵션을 주어 확인할 수 있다.

 

$ kubectl get pods --all-namespaces

1-2 .네임스페이스 내의 서비스에 접근하기

이번엔 위에서 생성한 zedd-deafult 네임스페이스 내의 서비스에 접근해보도록 하자. 이전 포스팅에서 서비스 오브젝트에 대해 설명하면서, 쿠버네티스 클러스터 내부에서 특정 파드내에서 다른 파드로 통신할 때, 서비스의 이름을 일종의 도메인으로 하여 접근할 수 있다는 것을 배웠다. 그런데 엄밀히 말하면, "같은 네임스페이스 내의 서비스"일 경우에만 서비스 이름으로 접근할 수가 있다. 예를 들어, zedd-default 라는 네임스페이스에 내가 서비스를 생성했다. 그리고 이 서비스에 접근하기 위해 특정 파드를 하나 생성했다고 가정해보자. 그런데 이 파드는 default 라는 네임스페이스 내에 생성된 파드이다. 이럴 경우, default 네임스페이스 내에 있는 파드는 zedd-default 라는 네임스페이스 내의 서비스에 접근이 불가능하다는 것이다. 

 

하지만 서비스 이름을 특정 규칙에 맞게 명시한다면 다른 네임스페이스에 있더라도 접근이 가능하다. 그 규칙은 아래와 같다.

 

{SERVICE NAME}.{NAMESPACE NAME}.svc
# 아래가 서비스의 Fully Qualified Domain Name(FQDN)임. 아래처럼 정의해도 통신 가능
{SERVICE NAME}.{NAMESPACE NAME}.svc.cluster.local

 

네임스페이스도 kubectl delete 명령어로 삭제가 가능하다. 단, 네임스페이스를 삭제하면 해당 네임스페이스 존재하는 모든 리소스 또한 함께 삭제되기 때문에 네임스페이스를 삭제할 땐 반드시 신중해지는 습관을 갖도록 하자.

1-3. 네임스페이스와는 종속적인 또는 독립적인 오브젝트

위에서 네임스페이스를 배우면서 우리는 파드, 레플리카셋, 디플로이먼트, 서비스라는 오브젝트가 네임스페이스에 따라 논리적으로 구분되는 즉, 네임스페이스에 종속된다는 사실을 배웠다. 이를 오브젝트가 네임스페이스에 속한다 하여 object is namespaced 라고도 한다. 네임스페이스에 속하는 오브젝트들이 무엇이 있는지 보기 위해서는 --namespaced 옵션을 true로 주어 확인할 수 있다.

 

$ kubectl api-resources --namespaced=true

 

그러면 네임스페이스와 독립적이지 않은 오브젝트들도 있을까? 당연하다. 대표적으로 노드라는 오브젝트가 그렇다. 노드는 쿠버네티스 클러스터에서 사용되는 저수준의 오브젝트이며, 네임스페이스에 의해 구분되지 않는다. 다른 독립적인 오브젝트가 무엇이 있는지 보기 위해서는 위 명령어에서 false로 바꾸어주면 확인이 가능하다.

2. 설정값을 파드에 전달하자, Configmap 과 Secret

이번에는 쿠버네티스를 통해 배포하는 애플리케이션 내부에서 사용할 설정값을 동적으로 제어할 수 있도록 해주는 컨피그맵(Configmap)과 시크릿(Secret)에 대해 알아보자. 사실 이전에 도커 스웜을 배우면서 그 때도 동일하게 컨피그맵과 시크릿에 대해 배운적이 있다. 그 때 배웠던 역할들과 쿠버네티스에서도 매우 유사하다. 

 

물론 컨피그맵과 시크릿같은 오브젝트를 사용하지 않고 애플리케이션 내부에서 사용할 설정값들을 세팅할 수 있다. 가장 단순한 방법으로는 빌드할 (도커) 이미지 내부에 환경 변수 또는 파일의 형태로 설정 값들을 미리 지정해놓을 수 있다. 하지만 도커 이미지는 한 번 빌드를 하면 불변의 상태를 갖기 때문에 만약 중간에 설정 값들을 변경해야 하는 상황이 생기면 이미지를 다시 빌드해야 하는 귀찮음이 발생한다.

 

다른 방법으로는 쿠버네티스 파드를 정의하는 YAML 파일 내부에 env 키워드로 각 환경변수 이름과 그의 값을 정의할 수 있다.

 

출처: 쿠버네티스 공식 문서

 

하지만 이렇게 하드코딩하는 방식은 상황에 따라 단점이 존재한다. 만약 특정 설정 값만 다르고 나머지 YAML 파일 내용이 모두 같은 상황, 예를 들어, 개발 환경과 운영 환경에서 각각 배포하는 파드를 위한 YAML 파일을 정의한다고 하면 어떤 환경인지를 나타내는 특정 env 값만 을 제외하고는 모두 동일할 것이고, 결국 거의 비슷한 내용으로 이루어져 있는 YAML 파일 2개를 따로 정의해야 한다.

 

만약 컨피그맵과 시크릿을 사용한다면 위와 같은 상황을 효율적으로 해결할 수 있다. 좀 더 구체적으로, 컨피그맵에는 설정값을, 시크릿에는 보안상 노출되어서는 안되는 값들을 저장할 수 있다. 이렇게 컨피그맵과 시크릿을 활용한다면 설정값들을 파드와 분리하여 별도의 오브젝트로 관리할 수 있게 된다. 그러면 이제 하나씩 알아보도록 하자. 먼저 컨피그맵이다.

2-1. 컨피그맵(Configmap)

컨피그맵은 보안상 노출되어도 상관이 없는 일반적인 설정값을 담아 저장할 수 있는 오브젝트이다. 그리고 네임스페이스에 종속적이기 때문에 네임스페이스 별로 컨피그맵이 존재한다. 이제 컨피그맵을 생성해보도록 하자. YAML 파일에 직접 정의해서 컨피그맵을 생성할 수도 있지만 kubectl 명령어를 사용해서도 생성이 가능하다. 아래 명령어 형식을 통해서 컨피그맵을 하나 생성해보자.

 

$ kubectl create configmap [CONFIGMAP NAME] --from-literal [KEY]=[VALUE]
$ kubectl create configmap log-level-configmap --from-literal LOG_LEVEL=DEBUG

 

--from-literal 옵션을 여러 번 사용해서 여러 개의 key=value 형태로 컨피그맵에서 사용할 수 있도록 설정할 수 있다. 아래처럼 말이다.

 

$ kubectl create configmap zedd-configmap \
--from-literal LOG_LEVEL=DEBUG \
--from-literal NAME=ZEDD

 

그리고 생성한 컨피그맵의 자세한 내용을 확인하고 싶다면 아래 2가지 명령어 중 하나 선택해서 볼 수 있다. 

 

$ kubectl describe configmap [CONFIGMAP NAME]
$ kubectl get configmap [CONFIGMAP NAME] -o yaml

 

만약 컨피그맵 이름을 지정해주지 않으면 모든 컨피그맵에 대한 내용이 출력된다. 그리고 생성한 컨피그맵의 리스트를 보고 싶다면 kubectl get configmap 또는 kubectl get cm 이라는 명령어로 확인이 가능하다.

 

이제 컨피그맵을 생성해보았으니, 다음으로는 파드에서 해당 컨피그맵을 가져와 볼 차례이다. 파드에서 컨피그맵을 사용하려면 파드, 레플리카셋, 디플로이먼트 같은 오브젝트를 생성하는 YAML 파일의 파드 템플릿 내에 아래처럼 정의해주면 된다.(아래에서는 파드 템플릿 부분만 발췌하였다)

 

spec:
  containers:
  - name: zedd-webserver
    env:
      valueFrom:
        configMapKeyRef:
          name: log-level-configmap
          key: LOG_LEVEL

 

그런데 위와 같이 YAML 파일에 컨피그맵을 정의하고 파드를 배포하게 된다면 내부적으로 파드가 컨피그맵을 어떻게 사용하는 걸까? 크게 2가지 방법이 있는데, 이 2가지 방법 중 적절한 것을 선택하는 기준은 애플리케이션이 소스코드 내부에서 어떻게 설정값을 읽어들이는지에 따라 달라진다.

2-1-1. 컨테이너의 환경 변수로 컨피그맵 사용하기

가장 먼저 알아볼 방법은 컨피그맵의 값을 컨테이너의 환경변수로 읽어들이는 방법이다. 컨피그맵에 저장된 key=value 형태의 데이터가 컨테이너의 환경변수에 그대로 사용된다. 예를 들어, 컨피그맵을 우리는 MY_CONFIG=ZEDD 로 설정했다고 한다면 컨테이너 내부 터미널에서 echo $MY_CONFIG 를 입력하면 ZEDD 라는 값이 나오게 된다. 그래서 애플리케이션 내부에서 시스템 환경 변수로부터 설정값을 가져오려고 한다면 이 방법을 사용하는 것이 좋다.

 

그러면 컨피그맵의 설정값을 컨테이너의 환경 변수로 가져와 보는 실습을 진행해보자. 적용해볼 YAML 파일 내용은 아래와 같다.

 

apiVerson: v1
kind: Pod
metadata:
  name: container-env-zedd
spec:
  containers:
    - name: zedd-container
      image: busybox
      args: ['tail', '-f', '/dev/null']
      envFrom:
      - configMapRef:
          name: log-level-configmap
      - configMapRef:
          name: start-k8s

 

위 파일 내용 중 중요한 부분은 envFrom 과 configMapRef 키워드이다. 위에서 작성된 내용은 log-level-configmap 과 start-k8s 라는 컨피그맵으로부터 값을 가져와 환경변수를 생성하도록 설정하는 것이다. 구체적으로, envFrom 항목은 하위에 적어준 하나의 컨피그맵이 여러 개의 key:value를 갖고있다면 그 모두를 환경변수로 가져오도록한다. 만약 위 YAML 파일에 정의된 컨피그맵이 생성되어 있지 않은 상태라면 아래 명령어를 수행해주자.

 

$ kubectl create configmap log-level-configmap \
--from-literal LOG_LEVEL=DEBUG && \
kubectl create configmap start-k8s \
--from-literal k8s=kubernetes \
--from-literal container=docker

 

이제 YAML 파일을 kubectl apply 명령어를 활용해서 배포해보도록 하자. 그리고 난 다음 배포한 파드 내에 실제로 환경변수가 잘 설정되었는지 아래 명령어를 통해 확인해보자.

 

$ kubectl exec container-env-zedd printenv | grep -E "(LOG|container|k8s)"

 

 

터미널 화면을 보면 위에서 YAML 파일에 정의한 컨피그맵의 key:value 값들이 파드 내 환경 변수로 잘 설정된 것을 볼 수 있다. 

 

이번에는 컨피그맵의 모든 환경변수를 파드 내에 설정하는 것이 아니라 컨피그맵의 특정 key:value만 파드 내의 환경변수로 설정해보도록 하자. 이번에는 valueFrom 과 configMapKeyRef 키워드를 사용해야 한다. 아래 YAML 파일을 살펴보자.

 

apiVersion: v1
kind: Pod
metadata:
  name: container-env-zedd-v2
spec:
  containers:
    - name: zedd-container
      image: busybox
      args: ['tail', '-f', '/dev/null']
      env:
      - name: ENV_KEYNAME_1
        valueFrom:
          configMapKeyRef:
            name: log-level-configmap
            key: LOG_LEVEL
      - name: ENV_KEYNAME_2
        valueFrom:
          configMapKeyRef:
            name: start-k8s
            key: k8s

 

env 항목의 내용을 살펴보자. 우선 컨피그맵에서 선택적으로 가져올 key:value를 파드 내에서 어떤 환경변수 이름으로 설정할지 나타낼 수 있다. 그것이 바로 ENV_KEYNAME_1 과 ENV_KEYNAME_2에 해당한다. 그리고 valueFrom 키워드를 통해서 어떤 컨피그맵의 어떤 key로부터 값을 가져올 것인지 configMapKeyRef 키워드를 통해 나타낼 수 있다. 위 YAML 파일 내용의 파드를 새롭게 배포하고, 파드 내부로 들어가 환경변수를 출력하는 명령어를 입력해보자.

 

$ kubectl exec container-env-zedd-v2 printenv | grep -E "(KEYNAME)"

 

 

터미널 화면을 보면 해당 파드 내부의 환경변수에 YAML 파일로 명시해준 환경변수 값이 잘 들어가 있는 것을 볼 수 있다.

2-1-2. 컨피그맵의 값을 파일 형태로 파드 내부에 마운트하기

다음은 컨피그맵의 값을 파드 내의 환경변수가 아닌 파일 형태로 마운트하는 방법에 대해 알아보자. 이번에 사용할 키워드는 volumeMounts 와 volumes 이다. 여기서 쿠버네티스에서의 볼륨이라는 것을 활용한다. 이 볼륨은 도커 포스팅 시리즈에서 배웠던 볼륨과 기능이 거의 유사하다. 즉, 컨피그맵을 마운트하기 위해 볼륨을 사용할 것이다. 아래 YAML 파일 내용 예시를 살펴보자.

 

apiVersion: v1
kind: Pod
metadata:
  name: configmap-volume-all-pod
spec:
  containers:
    - name: zedd-container
      image: busybox
      args: ["tail", "-f", "/dev/null"]
      volumeMounts:
      - name: configmap-volume
        mountPath: /etc/config
  volumes:
    - name: configmap-volume
      configMap:
        name: start-k8s

 

새롭게 추가된 항목들에 대해 알아보자.

 

• spec.volumes : 새롭게 생성할 볼륨의 이름을 명시한다. 그리고 그 볼륨이 사용할 컨피그맵이 무엇인지 정의한다.
• spec.containers.volumeMounts : 이용할 볼륨을 명시하고, 파드 내에서 마운트할 경로를 명시해준다.

이제 위 YAML 파일 내용으로 파드를 배포하고 파드 내부의 /etc/config 경로로 이동해보자.

 

$ kubectl exec -it configmap-volume-all-pod ls /etc/config

 

 

container, k8s 라는 심볼릭 링크 형태의 파일이 2개 존재하는 것을 볼 수 있다. 이 때 파일 이름은 컨피그맵의 key에 해당한다. 그러면 각 파일 내용에 그럼 무엇이 들어있을까? cat 명령어를 활용해 열어보자. 파일 내용은 바로 컨피그맵의 특정 key에 해당하는 value 값이 들어있다. 

 

$ kubectl exec configmap-volume-all-pod cat /etc/config/container && \
kubectl exec configmap-volume-all-pod cat /etc/config/k8s

 

이번에는 컨피그맵에서 원하는 key:value 쌍 데이터만 파드 내의 파일로 마운트해보도록 하자. 방금 배포한 YAML 파일 내용에서 spec.volumes 부분에 간단하게 추가만 해주면 된다. 아래 내용을 살펴보자.

 

apiVersion: v1
kind: Pod
metadata:
  name: configmap-volume-all-pod-v2
spec:
  containers:
    - name: zedd-container
      image: busybox
      args: ["tail", "-f", "/dev/null"]
      volumeMounts:
      - name: configmap-volume
        mountPath: /etc/config
  volumes:
    - name: configmap-volume
      configMap:
        name: start-k8s
        items:
        - key: k8s
          path: k8s_selected

 

추가된 부분은 spec.volumes.configMap.items 부분이다. 해당 부분에 명시한 컨피그맵(위 예시에서는 start-k8s라는 컨피그맵)에서 어떤 key의 값만 가져올 것인지, 그리고 path 부분에는 그 가져온 값이 들어있는 파일의 이름을 무엇으로 할지 명시해준다. 위 YAML 파일을 배포하고, 파드 내부로 들어가 아래 명령어를 입력해보자. 그러면 k8s 이름이 아닌 k8s_selected 라는 이름의 파일이 존재하게 된다.

 

$ kubectl exec configmap-volume-all-pod-v2 ls /etc/config
$ kubectl exec configmap-volume-all-pod-v2 cat /etc/config/k8s_selected

 

참고로 이렇게 쿠버네티스의 리소스의 데이터를 파드 내부 디렉터리에 위치시키는 것을 공식 문서에서는 투사(Projection)라고 표현한다.

2-1-3. 파일로부터 컨피그맵 생성하기

지금까지는 컨피그맵을 단순한 문자열로 할당하기 위해 --from-literal 옵션을 활용해서 생성했다. 이번에는 컨피그맵의 설정 값들이 들어있는 특정 파일로부터 컨피그맵을 생성해보자. 이 때 사용하는 옵션은 --from-file 옵션이다. 만약 컨피그맵으로 설정할 파일 내용이 index.html 이라고 한다면 아래처럼 컨피그맵을 생성할 수 있다. 참고로 --from-file도 연속적으로 사용해서 여러 개의 파일을 컨피그맵으로 설정할 수 있다.

 

$ kubectl create configmap index-configmap --from-file index.html

 

그런데, 위 명령어로 컨피그맵을 생성하고 볼륨을 활용해 파드 내에 마운트시켰을 때, 파드 내부로 들어가 마운트시킨 경로를 가보면 파일의 이름이 컨피그맵의 key로, 파일의 내용이 컨피그맵의 value로 설정된다. 만약 컨피그맵의 key를 명시적으로 지정하고 싶다면 아래처럼 등호(=)를 활용해서 이름을 명시해줄 수 있다.

 

$ kubectl create configmap index-configmap --from-file index_key=index.html

 

그리고 .env 라는 확장자의 파일을 이용해서 여러 개의 key=value 값 형태로 구성된 설정 파일을 한꺼번에 컨피그맵으로 가져올 수 있다. 아래처럼 index.env 라는 파일이 있다고 가정해보자.

 

key1=value1
key2=value2
key3=value3

 

이 .env 파일을 컨피그맵으로 생성하려면 --from-env-file 이라는 옵션을 사용하면 된다.

 

$ kubectl create configmap from-envfile --from-env-file index.env

 

다음은 YAML 파일로 컨피그맵을 생성하는 방법이다. 즉, 컨피그맵을 생성할 때 문자열이면 --from-literal, 만약 파일이라면 --from-file 과 같은 옵션을 활용하는 것이 아닌 생성할 컨피그맵 오브젝트가 정의된 YAML 파일을 배포(즉, kubectl apply 명령어를 사용)해서도 컨피그맵을 생성할 수도 있다. 바로 --dry-run 과 -o yaml 옵션을 함께 사용해서 말이다. 이 2가지 옵션을 사용하면 컨피그맵을 실질적으로 생성하지 않은 채로 생성될 컨피그맵을 YAML 파일 형태로 출력시킬 수 있다.

 

이것이 가능한 이유는 --dry-run 옵션 때문인데, 'dry run' 이라는 용어 자체의 의미를 보면 그 이유를 짐작할 수 있다. dry run 이란, 특정 작업의 실행 가능 여부를 검토하는 명령어 또는 API를 의미한다. 실제로, 쿠버네티스 명령어(ex. kubectl apply, create, ...)에 --dry-run 옵션을 추가하면 실행 가능 여부를 확인할 수 있으며 실행 가능함을 판단하더라도 실제로 쿠버네티스 리소스를 생성하지 않게 된다. 만약에 에러가 나는 YAML 파일을 실행하고자 하면 아래와 같이 에러가 날 것임을 암시(?)해준다.

 

그럼 이제 --dry-run 과 -o yaml 옵션을 같이 사용해서 생성할 컨피그맵을 YAML 파일 내용으로 출력시켜보자.

 

$ kubectl create configmap zedd-configmap-yaml \
--from-literal NAME=ZEDD --dry-run -o yaml

 

 

터미널 화면을 보면 생성할 컨피그맵에 대한 YAML 파일 내용을 출력해준다. 이를 리다이렉션 하여 YAML 파일로 저장하고, kubectl apply 명령어를 사용해서 컨피그맵을 생성할 수 있다. 이런 방법을 쓰는 이유는 뭘끼? 정확하지는 않지만 아마 생성할 컨피그맵을 YAML 파일 형태로 남기고 아카이빙 및 재사용 목적으로 이용하는 용도라고 생각된다.

 

$ kubectl create configmap zedd-configmap-yaml \
--from-literal NAME=ZEDD --dry-run -o yaml > zedd-configmap-yaml.yaml && \
kubectl apply -f zedd-configmap-yaml.yaml

 

하지만 컨피그맵의 key, value 데이터가 너무 많아지면 YAML 파일의 길이가 불필요하게 길어진다는 단점이 있다. 이러한 단점을 해결하기 위해서 쿠버네티스 1.14 버전부터는 kustomize 라는 기능을 사용하면 더욱 편하게 컨피그맵을 생성할 수 있게 된다. 이에 대해서는 아래 시크릿을 배우면서 알아볼 예정이다.

2-2. 시크릿(Secret)

컨피그맵과 유사하긴 하지만 SSH 키, DB 계정의 패스워드 등과 같이 보안에 민감한 정보를 저장하기 위해 사용하는 시크릿에 대해 배워보자. 이 시크릿도 마찬가지로, 이전에 배웠던 도커 스웜에서 소개하는 시크릿과 용도가 매우 유사하다. 그리고 시크릿은 네임스페이스에 종속되는 쿠버네티스 오브젝트이며, 앞서 배운 컨피그맵과 사용하는 방법도 거의 동일하다. 하지만 시크릿이 보다 더 세분화된 사용 방법을 제공한다. 

2-2-1. 사용자가 정의하는 데이터를 비밀스럽게 저장하자, Opaque 시크릿

우선 간단하게 시크릿을 하나 생성해보자. 시크릿을 생성할 때도, --from-literal, --from-file, --from-env-file 옵션을 모두 사용할 수 있다. 여기서는 명시한 문자열을 시크릿으로 생성해보자.

 

$ kubectl create secret generic \
zedd-password --from-literal password=zedd1234

 

시크릿만의 차이점이라고 한다면 위 명령어에서 generic 이라는 특수 옵션을 붙인 것을 볼 수 있다. 이는 데이터의 사용 목적에 따라 시크릿의 종류가 몇 가지 종류로 나뉘기 떄문인데, 아래에서 보면 generic 옵션을 지정해 시크릿을 만들면 Opaque 라는 TYPE의 시크릿이 생성이 되는 것을 볼 수 있다.

 

 

자, 이제 그러면 생성한 시크릿의 정보를 살펴보자. 

 

 

도커 스웜때와 마찬가지로 위에서 시크릿을 생성할 때 value에 명시한 zedd1234 라는 값이 시크릿 정보에는 emVkZDEyMzQ= 이라는 문자열로 바뀐 것을 볼 수 있다. 이는 기본적으로 시크릿 값에 저장할 때 쿠버네티스가 base64로 값을 인코딩하기 때문이다.(단, 시크릿이 설정되었다고 하더라도 파드 내부로 직접 들어가 해당 시크릿의 값을 직접 보면 그 때는 디코딩된 값으로 되어있다)

 

시크릿도 YAML 파일로부터 생성이 가능한데, YAML 파일에 명시되는 데이터도 반드시 인코딩된 값으로 명시되어야 한다. 실제로, --dry-run 과 -o yaml 옵션을 사용해서 시크릿을 생성할 때의 YAML 파일을 보면 아래처럼 인코딩된 값으로 설정됨을 볼 수 있다.

 

 

그리고 컨피그맵을 배웠을 때처럼 시크릿에 명시된 모든 값을 한번에 파드 내 환경변수로 설정하거나, 시크릿의 특정 값만 환경변수로 설정하는 방법, 볼륨을 활용해서 모든 시크릿 또는 특정 시크릿을 파드 내의 특정 경로에 마운트하는 방법들 모두 YAML 파일 내에서 정의할 수 있다. 단지 YAML 파일 항목에서 컨피그맵에서의 configMapRef 키워드를 secretRef로, configMapKeyRef 키워드를 secretKeyRef 키워드로만 바꾸어 주면 된다.

2-2-2. 비공개 레지스트리에 접근하도록 해주자, docker-registry 시크릿

다음은 Opaque 유형의 시크릿과는 다른 종류인 docker-registry 유형의 시크릿에 대해 배워보자. 이 시크릿은 비공개 이미지 레지스트리에 접근할 때 사용하는 인증을 위한 유형이다. 일례로, 우리는 앞서 쿠버네티스 디플로이먼트, 파드 등을 배포할 때 활용하는 YAML 파일 내에서 파드 템플릿 내의 컨테이너 스펙을 정의해줄 때 컨테이너가 사용할 이미지를 명시해주었다. 이렇게 명시한 이미지를 최초로는 로컬 서버에서 찾고, 존재하지 않으면 기본적으로 도커 허브에서 다운로드 받는다.(도커 컨테이너가 이미지를 찾는 과정이랑 동일)

 

하지만 지금까지 실습하면서 활용한 이미지들은 모두 도커 허브에 공개된 이미지였기 때문에 별다른 문제가 없었지만, 만약 활용하려는 이미지가 사내의 사설 레지스트리이거나 도커 허브의 개인 레포지토리라면 추가적인 인증절차가 필요할 수 있다. 

 

도커에서는 docker login 명령어로 원하는 사설 레지스트리 도메인을 입력하여 Username, Password를 입력하여 인증을 할 수 있었다. 하지만 쿠버네티스에서는 이러한 명령어 대신 사설 레지스트리의 인증 정보를 저장하는 별도의 시크릿을 생성해서 인증 절차를 수행한다.

 

이 인증 절차를 위해 쿠버네티스가 시크릿을 생성하는 2가지 방법이 존재한다. 우선 사용자의 홈 디렉터리 경로의 .docker 디렉토리에 존재하는 config.json 파일을 사용하는 것이다. 이 json 파일에는 인증을 위한 정보가 담겨있기 때문에 해당 파일을 --from-file 옵션을 사용해 그대로 가져와 시크릿으로 생성하면 된다. 예시는 아래와 같다.

 

$ kubectl create secret generic registry-auth \
--from-file=.dockerconfigjson=/root/.docker/config.json \
--type=kubernetes.io/dockerconfigjson

 

두 번째 방법은 시크릿을 생성하는 명령어에 직접 로그인할 수 있는 정보(Username, Password)를 넣어주는 것이다. --docker-username, --docker-password 옵션을 활용하면 된다. 참고로 --docker-server 옵션을 사용해서 인증할 사설 레지스트리 서버의 도메인을 입력해줄 수 있다. --docker-server 옵션을 지정해주지 않으면 기본적으로 도커 허브(docker.io) 도메인이라고 가정한다.

 

$ kubectl create secret docker-registry registry-auth-by-cmd \
--docker-username=zedd-user \
--docker-password=zedd1234 \
--docker-server=zedd-registry.com

 

이렇게 생성한 시크릿을 디플로이먼트, 파드를 배포할 때 활용하는 YAML 파일 내에 명시할 수 있다. 바로 imagePullSecret 항목을 넣어주면 된다. 예시는 아래와 같다.

 

apiVerson: v1
kind: Pod
metadata:
  name: private-registry-pod
spec:
  containers:
  - name: zedd-private-container
    image: zedd-image:v1
  imagePullSecrets:
  - name: registry-auth-by-cmd

3. 컨피그맵과 시크릿을 좀 더 쉽게 배포하자, kustomize

다음으로 배워볼 것은 지금까지 배워 온 컨피그맵과 시크릿을 쉽게 배포할 수 있도록 지원해주는 kustomize에 대해 알아보자. 위에서 컨피그맵이나 시크릿의 값을 별도로 관리하려고 한다면 --dry-run 옵션을 사용해서 YAML 파일로 따로 저장해놓아야 했다. 하지만 만약에 저장해야 할 컨피그맵과 시크릿 개수가 늘어난다면 그 모든 설정값들을 YAML 파일에 저장해야 한다. 이렇게 되면 우선 시크릿과 같은 보안에 민감한 값을 (물론 암호화된 상태로 설정되긴 하지만..) 파일 내에 직접 명시하기 때문에 보안적으로 취약한다는 점과 시크릿과 컨피그맵 개수가 많아지면 그 데이터들을 관리하기가 매우 힘들어진다.

 

이러한 단점을 해결하기 위해서 컨피그맵이나 시크릿에 설정된 값들을 YAML 파일에 작성하지 않고 YAML 파일과 분리하여 별도로 관리할 수 있는 kustomize 기능을 사용할 수 있다. kustomize는 시크릿과 컨피그맵 이외에도 자주 사용되는 YAML 파일의 속성 값을 별도로 정의해 재사용하거나 더 나아가 여러 YAML 파일을 하나로 묶는 등 다양한 용도로 사용할 수 있다. 

 

kustomize를 사용하는 방법은 공식 문서를 보면 자세히 나와있긴 하지만 생각보다 간단하다. kustomize도 일종의 YAML 파일을 별도로 작성한 후, kubectl apply 명령어를 사용해서 배포하면 된다. 단, 기존에는 -f 옵션을 사용했지만, kustomize의 경우 -k 옵션을 사용한다. kustomize를 사용해서 시크릿을 정의해보자. YAML 파일 내용은 아래와 같으며, 반드시 파일 이름을 kustomization.yaml 또는 kustomization.yml 또는 Kustomization 으로 설정해야 한다.

 

secretGenerator:
- name: kustomize-zedd-secret
  type: Opaque
  files:
  - key=zedd-secret

 

이 YAML 파일을 사용해서 시크릿을 생성하기 위해 아래 명령어를 사용하자. 아래 명령어의 마지막 인자에는 해당 YAML 파일이 있는 경로를 명시해준다.

 

$ kubectl apply -k ./

 

위 명령어가 잘 동작하는지 테스트 하기 위해 일반적으로 --dry-run 옵션을 사용했던 것처럼 kustomize를 사용할 때도 비슷한 기능을 사용할 수 있다. 아래 명령어를 입력해보면 된다. 역시 아래 명령어의 마지막 인자에는 해당 YAML 파일이 있는 경로를 명시해준다.

 

$ kubectl kustomize ./

 

만약 시크릿이 아닌 컨피그맵을 kustomize로 생성하고 싶다면 위 YAML 파일에서 secretGenerator 키워드를 configMapGenerator로 바꾸어준다. 그리고 시크릿과는 달리 컨피그맵에는 유형(type)이 없기 때문에 type 키워드가 작성되어 있는 라인을 삭제해주면 된다.

 

마지막으로, kustomize를 사용해서 시크릿 또는 컨피그맵을 생성하면 시크릿, 컨피그맵을 구분할 수 있도록 하는 해쉬값이 시크릿, 컨피그맵의 이름 끝에 붙는다. 그래서 방금 위에서 kustomize를 활용해서 생성한 시크릿을 보면 시크릿 생성 시 이름을 kustomize-zedd-secret만 명시했지만 이름 끝에 해쉬값이 붙은 것을 볼 수 있다.

 

 

물론, 일반적인 kubectl 명령어를 사용해서도 생성할 시크릿, 컨피그맵의 이름 끝에 해쉬값을 붙여줄 수 있다. 명령어 마지막에 --append-hash 옵션을 붙여주면 된다.

4. 컨피그맵과 시크릿을 갱신해서 애플리케이션의 설정값도 갱신시키기

애플리케이션에 설정된 컨피그맵과 시크릿 값 중 일부를 변경해야 하는 상황이 생길 수 있다. 그렇다면 컨피그맵과 시크릿에 설정된 값을 변경해야 하는데, 이 때 크게 3가지 방법이 존재한다. 첫 번째는 kubectl edit 명령어로 수정하는 방법, 두 번째는 컨피그맵 또는 시크릿이 명시된 YAML 파일을 변경한 뒤 리소스를 재배포하는 방법, 마지막으로는 kubectl patch 명령어를 사용하는 방법이 있다.

 

그런데 컨피그맵과 시크릿의 값을 위 3가지 방법 중 하나를 사용해서 변경했다고 하더라도, 애플리케이션 파드 내에서도 해당 값이 변경되었는지는 컨피그맵 또는 시크릿을 파드에 제공하는 방법에 따라 달라진다.

 

앞서서, 우리는 컨피그맵 또는 시크릿을 파드에 제공하는 방법으로 2가지를 배웠다. 첫 번째는 환경 변수로 파드 내부에 설정값을 제공하는 방법이였고, 두 번째는 볼륨이라는 쿠버네티스 오브젝트를 활용해서 파드 내부의 특정 경로에 마운트하는 방법이였다. 

 

두 방법 중 첫 번재 방법은 컨피그맵이나 시크릿 값을 변경하더라도 파드 내에 제공된 값들도 같이 변경되지 않는다. 반면에 두번째 방법을 활용한다면 변경 후의 컨피그맵과 시크릿의 값이 파드 내에서도 같이 변경된다.

 

하지만 두 번째 방법(마운트하는 방법)을 사용한다고 하더라도 파드에서 이미 실행 중인 애플리케이션의 설정이 자동으로 변경되는 것은 또 아니다. 이 말을 이해하기 위해 머신러닝 모델을 사용하는 애플리케이션을 예시로 한 번 들어보자.

 

우리에게는 모델 A, B 라는 2가지 종류의 모델이 소스코드 내의 서로 다른 경로에 존재하고, 이 모델이 존재하는 경로를 우리는 컨피그맵으로 생성하여 파드 내에 제공하려고 한다. 그리고 최초로 애플리케이션을 개발할 때, 모델 A가 있는 경로를 컨피그맵으로 생성하여 애플리케이션을 쿠버네티스로 배포하였다. 그런데 갑자기 중간에 모델 A의 성능에 문제점이 생겨 모델 B로 교체하려고 한다. 이 때, 우리는 컨피그맵의 값 즉, 모델 A가 있는 경로에서 모델 B가 있는 경로로 값을 변경 하고 애플리케이션 내에도 반영시키려고 한다. 

 

컨피그맵을 수정했다고 가정하고, 그 이후부터 애플리케이션은 앞으로 어떤 모델을 사용하게 될까? 모델 A? B? 정답은 A이다. 왜 컨피그맵을 갱신시키고, 파드 내 애플리케이션의 설정값도 갱신시켰음에도 불구하고 여전히 모델 A를 사용하는 걸까? 이유는 애플리케이션의 프로세스가 이미 모델 A를 바라보고 있을 때 실행된 상태이기 때문이다. 다시 말해, 애플리케이션이 실행되기 시작했을 때 이미 모델 A 경로로 설정된 컨피그맵을 본 상태에서 실행된 상태이기 때문에, 모델 B 경로로 수정된 컨피그맵을 애플리케이션이 새롭게 바라보도록 해야 하는 것은 또 별개로 해주어야 한다.

 

그러면 이런 상황에서 애플리케이션이 모델 B를 바라보도록 하기 위해서 어떻게 해야 할까? 가장 간단하게는 파드를 새로 배포하는 것이다. 그런데 매번 이렇게 배포하는 과정을 수기로 해주게 되면 귀찮을 수 있다. 이를 자동화하기 위해 변경된 파일을 다시 읽어 들이도록 컨테이너의 프로세스에 별도의 시그널(SIGHUP)을 보내는 사이드카 컨테이너를 애플리케이션과 함께 파드 내에 포함시켜볼 수 있다. 또 다른 방법으로는 쿠버네티스 API를 활용해서 컨피그맵, 시크릿의 데이터 변경에 대한 알림(Watch)을 받은 뒤, 자동으로 reload 하여 갱신하는 로직도 생각해볼 수 있다. 그 이외에 다양한 방법이 존재할 것이다. 이는 사용자의 기술 숙련도나 상황, 입맛에 맞게 선택을 하면 된다.

---

지금까지 포스팅으로 하여 쿠버네티스의 기초에 대한 모든 목차를 마무리했다. 책에서는 이제 그 이후의 내용으로 쿠버네티스 고급 기능에 대해 소개한다. 필자도 지금 당장의 공부 진도는 여기까지로 하여 마무리하려고 한다. 현업에서 물론 쿠버네티스를 활용하긴 하지만, 필자의 메인 직무가 DevOps 엔지니어가 아닐 뿐더러, 추후에 고급 기능이 내게 필요로 할 때 그 때 당시 책을 다시 펴보려고 한다.