[CKAD] Pod의 배포 및 업데이트

개요

Pod를 배포하고 전략적으로 업데이트하는 방법을 알아보겠습니다.

Deployment 배포 

kubectl apply -f {deployment.yaml}

Deployment가 생성한 Pod의 이름 구조

Deployment가 생성한 Pod의 이름은 보통 다음과 같은 구조를 가집니다

<Deployment-이름>-<ReplicaSet-해시>-<Pod-유니크-ID>

이 구조를 상세히 설명하면 아래와 같습니다. 

<Deployment-이름>

• Deployment 리소스를 만들 때 정의한 이름입니다.
• 이 이름은 사용자가 Deployment를 생성할 때 지정한 이름을 따릅니다.

예: my-app

<ReplicaSet-해시>

• ReplicaSet의 이름에서 파생된 해시값입니다. Deployment는 내부적으로 ReplicaSet을 관리하며, ReplicaSet이 실제 Pod를 생성합니다. 이 해시값은 Deployment의 현재 상태를 나타내는 값입니다.
• 예를 들어, 새로운 버전의 이미지를 사용하거나 환경 변수를 변경하면 새로운 ReplicaSet이 생성되고, 새로운 해시값이 Pod명에 반영됩니다.

예: 845d94c7b9

<Pod-유니크-ID>

• Pod마다 고유한 식별자인 유니크 ID가 자동으로 생성됩니다.
• 이 부분은 Pod마다 다르며, 클러스터 내에서 충돌을 방지하고 각 Pod를 구별하기 위한 것입니다.

Deployment 업데이트 방식

Recreate와 Rolling update

https://doitnow-man.tistory.com/entry/CKA-16-k8s-Rolling-update-and-Rollback

[CKA] 16. k8s Rolling update and Rollback

알면 좋은것

Deployment가 update될 때마다 새로운 ReplicaSet이 생성되며, 새로운 hash값이 포함된 Pod명이 생성됩니다.

Deployment 배포 전략

Blue/Green 

원리

Blue/Green 배포는 두 개의 환경(Blue 환경과 Green 환경)을 사용하여 새로운 애플리케이션 버전을 배포하는 방식입니다.

• Blue 환경: 기존에 운영 중인 애플리케이션 버전입니다. 현재 사용자가 접속하여 사용하고 있는 프로덕션 버전입니다.
• Green 환경: 새로운 애플리케이션 버전을 배포하는 환경입니다. Green 환경에 새 버전을 배포하고 충분히 테스트한 후, 트래픽을 Blue에서 Green으로 전환합니다.

절차

1. Green 환경에 새로운 버전 배포: 기존의 Blue 환경에서 서비스가 운영되는 동안, 새로운 버전의 애플리케이션을 Green 환경에 배포합니다.
2. 테스트 및 검증: Green 환경에서 새로운 버전의 애플리케이션을 테스트하고, 오류가 없는지 검증합니다.
3. 트래픽 전환: Green 환경이 정상적으로 동작하는 것을 확인하면, 로드 밸런서나 서비스 엔드포인트를 변경하여 사용자 트래픽을 Blue 환경에서 Green 환경으로 전환합니다.
4. Blue 환경 삭제: 새로운 버전의 애플리케이션이 안정적으로 운영되면, 기존의 Blue 환경을 삭제하거나 유지 보수 작업을 합니다.

장점

• 빠른 롤백: 문제가 발생하면 Blue 환경으로 빠르게 롤백할 수 있습니다.
• 서비스 중단 없음: Blue와 Green 환경이 동시에 존재하기 때문에 배포 과정 중에 서비스 중단이 없습니다.

단점

• 리소스 요구량 증가: 두 개의 환경(Blue, Green)을 동시에 유지해야 하기 때문에 더 많은 리소스가 필요합니다.

Canary

원리

Canary 배포는 새로운 버전의 애플리케이션을 점진적으로 배포하면서, 기존 버전과 병행하여 사용자의 트래픽 일부를 새로운 버전으로 전환하는 전략입니다. 초기에는 소수의 사용자만 새 버전으로 접속하게 한 후, 문제가 없으면 점차적으로 트래픽을 증가시킵니다.

절차

1. 소수의 트래픽 할당: 새로운 버전의 애플리케이션을 소수의 Pod에 배포하고, 사용자 트래픽의 일부분(예: 1~5%)만 이 새로운 버전으로 전송합니다.
2. 모니터링 및 검증: 소수의 사용자에게 새로운 버전을 제공하면서, 시스템 성능, 오류율, 사용자 피드백 등을 모니터링합니다.
3. 트래픽 점진적 증가: 문제가 없으면 트래픽을 조금씩 더 많은 사용자에게 확장합니다. (예: 10%, 25%, 50% 등)
4. 전체 전환: 최종적으로 문제가 발견되지 않으면 모든 사용자 트래픽을 새로운 버전으로 전환합니다.
5. 롤백 가능: 만약 특정 단계에서 문제가 발생하면, 새로운 버전의 트래픽 비율을 줄이거나 롤백할 수 있습니다.

장점

• 리스크 감소: 한 번에 모든 트래픽을 전환하는 것이 아니라 점진적으로 배포하므로, 버그나 성능 문제를 발견했을 때 빠르게 대응할 수 있습니다.
• 사용자 기반 피드백: 실제 사용자 트래픽을 일부만 새로운 버전으로 보내면서 피드백을 받을 수 있습니다.

단점

• 배포 시간이 길어짐: 트래픽을 점진적으로 전환하는 과정이 시간이 걸릴 수 있습니다.
• 복잡한 모니터링 필요: 트래픽 비율을 조절하면서 세심한 모니터링이 필요합니다.

Blue/Green vs Canary 비교

항목	Blue/Green 배포	Canary 배포
트래픽 전환 방식	모든 트래픽을 한 번에 전환	트래픽을 점진적으로 전환
리소스 사용량	두 개의 완전한 환경(Blue, Green)을 유지해야 함	점진적으로 트래픽을 전환하므로 리소스 사용 효율적
롤백 속도	Blue 환경으로 빠르게 롤백 가능	Canary 버전으로 전환된 트래픽만 롤백 가능
복잡성	상대적으로 단순	모니터링 및 트래픽 분배 조정이 필요
리스크	한 번에 트래픽 전환 시 리스크 있음	점진적 전환으로 리스크 분산 가능

Canary 설정 유의 사항 

트래픽을 Deployment로 배포된 Pod로 보내는 방법에서 중요한 것은 Service와 Deployment 간의 연결입니다. 이때, Service의 selector는 Deployment의 selector가 아니라 Deployment의 Pod에 설정된 label과 일치해야 합니다.

이유

• Deployment의 역할은 Pod를 관리하는 것입니다. 즉, Deployment는 여러 개의 Pod를 생성하고 그들을 관리합니다.
• Service는 selector를 이용해 Pod를 선택하고, 트래픽을 해당 Pod로 라우팅합니다.

따라서, Service의 selector는 Deployment가 생성한 Pod의 label과 일치해야 합니다. 이를 통해 Service가 올바른 Pod로 트래픽을 전달할 수 있습니다.

 

<Deployment yaml>

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

 

<service Yaml> 

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app  # 이 selector는 Pod의 label과 일치해야 함
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

결론

 

• Service의 selector는 Pod의 label을 기준으로 해야 합니다.
• Deployment의 selector는 Deployment가 관리하는 Pod를 정의하기 위한 것이며, Service의 selector와는 직접적인 관계가 없습니다.