search

emeraldgoose / kubernetes_study

Kubernetes In Action
0 stars 0 forks source link

9장. 디플로이먼트: 선언적 애플리케이션 업데이트 #9

Open emeraldgoose opened 8 months ago

emeraldgoose commented 8 months ago

9.1 파드에서 실행 중인 애플리케이션 업데이트

서비스가 이전 버전의 파드에 연결되어 있는 상태에서 새 파드가 모두 실행되면 서비스의 레이블 셀렉터를 변경하여 서비스를 새 파드로 전환할 수 있다. 이것을 블루-그린 디플로이먼트라고 한다. 전환한 후 새 버전이 올바르게 작동하면 이전 레플리케이션컨트롤러를 삭제해 이전 파드를 삭제할 수 있다.

새 파드가 모두 실행된 후 이전 파드를 한 번에 삭제하는 방법 대신 파드를 단계별로 교체하는 롤링 업데이트를 수행할 수도 있다.

emeraldgoose commented 8 months ago

9.2 레플리케이션컨트롤러로 자동 롤링 업데이트 수행

롤링 업데이트를 수행하려면 kubectl rolling-update {교체할 레플리케이션컨트롤러 이름} {새 레플리케이션컨트롤러 이름} --image={image} 명령어를 수행한다. 명령어를 수행하면 새 레플리케이션컨트롤러가 즉시 만들어지고 replicas는 0으로 설정된다.

하지만 kubectl rolling-update를 더 이상 사용하지 않는다. 쿠버네티스 마스터 대신 kubectl 클라이언트가 스케일링을 수행하여 쿠버네티스에게 의도하는 시스템의 상태를 선언하는 형태가 아니기 때문이다.

emeraldgoose commented 8 months ago

9.3 애플리케이션을 선언적으로 업데이트하기 위한 디플로이먼트 사용하기

디플로이먼트는 레플리케이션컨트롤러 또는 레플리카셋을 통해 수행하는 대신 애플리케이션을 배포하고 선언적(declarative)으로 업데이트하기 위한 높은 수준(high-level)의 리소스다. 디플로이먼트를 생성하면 레플리카셋 리소스가 그 아래에 생성되어 파드는 디플로이먼트 아래 레플리카셋에 의해 생성되고 관리된다.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name:
spec:
  replicas: 3
  template:
    metadata:
      name:
      labels:
        ...
    spec:
      containers:
      - image:
        name:

디플로이먼트를 생성하기 위해 kubectl create -f {manifest}.yaml --record 명령을 사용한다. --record 옵션을 사용해서 개정 이력(revision history)에 명령어를 기록해 나중에 유용하게 사용할 수 있다. 디플로이먼트가 롤아웃 상태를 확인하기 위해 kubectl rollout status deployment {deployment_name} 명령을 사용할 수 있다.

디플로이먼트의 전략은 RollingUpdate 이외에 Recreate가 있다. Recreate 전략은 새 파드를 만들기 전에 이전 파드를 모두 삭제한다. 애플리케이션이 여러 버전을 병렬로 실행하는 것을 지원하지 않고 새 버전을 시작하기 전에 이전 버전을 완전히 중지해야 하는 경우 이 전략을 사용한다. RollingUpdate 전략은 이전 파드를 하나씩 제거하고 동시에 새 파드를 추가해 애플리케이션을 계속 사용할 수 있도록 하고 서비스 다운 타임이 없도록 한다.

kubectl set image deployment {deployment_name} {name}={image} 명령을 실행하면 디플로이먼트의 파드 템플릿이 업데이트되어 사용된 이미지가 변경된다. 업데이트 동안 이전 레플리카셋의 크기를 0으로 스케일 다운하고 새 레플리카셋 스케일을 천천히 스케일 업한다. 만약 문제가 생겨 롤아웃을 되돌려야 하는 경우 kubectl rollout undo deployment {deployment_name} 명령을 사용한다. 디플로이먼트의 이력을 확인하고 싶다면 kubectl rollout history deployment {deployment_name} 명령을 사용하고 특정 디플로이먼트 개정(revision) 번호로 돌리고 싶다면 --to-revision={number} 옵션을 사용한다. 롤아웃을 멈추고 재개하려면 kubectl rollout pause, kubectl rollout resume 명령을 사용한다. 롤아웃 속도를 제어하려면 spec.strategy.rollingUpdate.maxSurge, spec.strategy.rollingUpdate.maxUnavailable 값을 수정한다.

잘못된 버전의 롤아웃을 방지하기 위해 minReadySeconds 속성을 사용한다. 파드를 사용 가능한 것으로 취급하기 전에 새로 만든 파드를 준비할 시간을 지정하는 속성이다. 일반적으로 실제 트래픽을 수신하기 시작한 후 파드가 준비 상태를 계속 보고할 수 있도록 minReadySeconds를 훨씬 높게 설정한다.

레디니스 프로브를 가진 디플로이먼트를 정의하려면 다음과 같다.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name:
spec:
  replicas: 3
  minReadySeconds: 10
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      name:
      labels:
        ...
    spec:
      containers:
      - image:
        name:
        readinessProbe:
          periodSeconds: 1 # 매초마다 실행될 레디니스 프로브를 정의한다
            httpGet:
              path: /
              port: 8080

kubectl apply 명령을 통해 디플로이먼트를 업데이트한다. 업데이트할 때 원하는 레플리카 수를 변경하지 않으려면 YAML에 replicas 필드를 포함하면 안 된다.

롤아웃은 10분 동안 진행되지 않으면 실패한 것으로 간주된다. 시간을 설정하기 위해 스펙의 progressDeadlineSeconds 값을 변경하면 된다.