[Basic] 쿠버네티스 배포

쿠버네티스 배포

롤링 업데이트

롤링 업데이트 개념

• 일반적으로 애플리케이션을 배포하는 방법은 블루/그린, 카나리, 롤링 업데이트와 같은 방식이 사용된다.
• 롤링 업데이트는 가장 많이 사용되는 배포 방식 중 하나이다.
• 롤링 업데이트는 파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 하는 방법이다.
• 사용자들은 애플리케이션이 항상 가용 가능한 상태일 것이라 여기고 개발자들은 하루에 여러번씩 새로운 버전을 배포하도록 요구된다.
  • 시스템을 무 장애로 업데이트할 수 있다는 장점이 있다.

롤링 업데이트 방식

• 여러 개의 인스턴스를 동작시키도록 애플리케이션을 스케일하는 것은 애플리케이션의 가용성에 영향을 미치지 않으면서 업데이트를 수행하는 것에 대한 요구 사항이 있다.
• 기본적으로 업데이트가 이루어지는 동안 이용 불가한 파드의 최대 개수와 생성 가능한 새로운 파드의 최대 개수를 지정한다.
• 애플리케이션 스케일링과 유사하게 디프롤이먼트가 외부로 노출되면 서비스는 업데이트가 이루어지는 동안 오직 가용한 파드에게만 트래픽을 로드밸런싱 할 것이다.
  • 가용한 파드란 애플리케이션의 사용자들에게 가용한 상태의 인스턴스를 의미한다.
• 아래는 롤링 업데이트 방식이며 자세한 내용은 쿠버네티스 공식 문서를 참고한다.

롤링 업데이트 동작

• 하나의 환경에서 또 다른 환경으로의 애플리케이션을 프로모션 한다.
  • 컨테이너 이미지 업데이트를 통해 이루어진다.
• 이전 버전으로의 롤백을 지원한다.
• 서비스 중단 없는 애플리케이션의 지속적인 통합과 지속적인 전달을 지원한다.
• 디플로이먼트가 외부로 노출되면, 서비스는 업데이트가 이루어지는 동안 오직 가용 가능한 파드에게만 트래픽을 로드밸런싱 한다.

---

디플로이먼트

디플로이먼트 개념

• 쿠버네티스에서는 일반적으로 Replication Controller를 이용해서 배포하지 않고 Deployment라는 개념을 사용한다.
• 복제된(replicated) 애플리케이션을 관리하는 API 객체다.
• 각 레플리카는 각각 하나의 파드로 대표되며 그러한 파드들은 클러스터 내 노드들에 걸쳐 배포된다.
• ReplicaSet(+ Pod)을 생성한다.
• 롤링 업데이트 등을 할 때 Replication Controller를 두 개를 만들어야 하고 하나씩 파드의 술르 수동으로 조절해야 하기 때문에 이를 자동화해서 추상화한 개념이 디플로이먼트다.
• 디플로이먼트는 기본적으로 Replication Controller를 생성하고 이를 관리하는 역할을 한다.

디플로이먼트 스펙

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
  spec:
    replicas: 3
    selector:
      matchLabels:
        app: nginx
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:

디플로이먼트 특징

• 디플로이먼트는 쿠버네티스가 애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시한다.
• 디플로이먼트가 만들어지면 쿠버네티스 마스터가 해당 애플리케이션 인스턴스를 클러스터의 개별 노드에 스케줄링한다.
• 애플리케이션 인스턴스가 생성되면 쿠버네티스 디플로이먼트 컨트롤러는 지속적으로 이 인스턴스들을 모니터링한다.
• 머신의 장애나 정비에 대응할 수 있는 자동 복구(self-healing) 메커니즘을 제공한다.
• 디플로이먼트는 애플리케이션 인스턴스를 생성하고 업데이트하는 역할을 담당한다.

디플로이먼트 방식

• Kubectl이라는 쿠버네티스 CLI를 통해 디프롤이먼트를 생성하고 관리한다.
• Kubectl은 클러스터와 상호 작용하기 위해 쿠버네티스 API를 사용한다.
• 디플로이먼트를 생성할 때 애플리케이션에 대한 컨테이너 이미지와 구동시키고자 하는 복제 수를 지정한다.
• 애플리케이션이 쿠버네티스 상에 배포되려면 지원되는 컨테이너 형식 중 하나로 패키지 되어야 한다.
• 디플로이먼트에 대한 자세한 내용은 쿠버네티스 공식 문서를 참고한다.

---

ConfigMap

ConfigMap 개념

• 컨테이너에서 필요한 환경설정 내용을 컨테이너와 분리해서 제공해 주기 위한 기능: 클라우드 네이티브 아키텍처에서 컨테이너는 변하지 않는 자원이다.
• 기밀 데이터가 아닌 데이터를 키-값 쌍으로 저장하기 위해 사용되는 API 객체다.
• 컨테이너 이미지에서 설정 데이터를 분리(decouple)시키기 위한 것이다.
• 컨테이너 이미지에서 사용하는 환경변수와 같은 세부 정보를 분리하고 그 환경변수에 대한 값을 외부로 노출시키지 않고 내부에 존재하는 스토리지에 저장해서 사용하는 방법이다.
• 환경변수, 커맨드라인 변수, 볼륨 내의 설정파일로 사용 가능하다.
• ConfigMap을 사용하면 컨테이너 이미지에서 해당 환경에 국한된 설정을 분리 가능: 애플리케이션을 어디로든 쉽게 이전 가능하다.
• ConfigMap을 변경하더라도 Running 상태의 파드에 곧바로 적용되지 않으며 파드를 재기동 해야 한다.

ConfigMap 스펙

• 생성된 ConfigMap은 kubectl get configmap 명령으로 확인이 가능하다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-dev
  namespace: default
data:
  DB_URL: localhost
  DB_USER: myuser
  DB_PASS: mypass
  DEBUG_INFO: debug

ConfigMap 사용 방법

• ConfigMap을 컨테이너에서 가져다 사용하는 방법은 3가지가 있다.
  • 파일 시스템(filesystem): 파드에 configmap을 마운트할 수 있다. 키 이름에 따라 각 항목의 파일이 생성되며 해당 파일의 내용은 값으로 설정된다.
  • 환경 변수(environment variable): configmap을 사용해 환경변수의 값을 동적으로 설정할 수 있다.
  • 커맨드라인 변수(command-line argument): 쿠버네티스는 configmap 값을 기반으로 컨테이너에 대한 커멘드를 동적으로 생성하도록 지원한다.