9. Controller - Deployment & 실습

 Deployment는 현재 한 서비스가 운영 중인데 이 서비스를 업데이트 해야 돼서 재배포를 해야 할 때 도움 주는 컨트롤러 입니다. 크게 아래와 같이 4가지 방식이 있습니다.

 

ReCreate

: Deployment를 만들면 이렇게 v1의 파드가 생성됩니다. 그리고 Pod 하나당 위와 같이 하나씩 자원이 사용된다고 가정하겠습니다. Deployment는 먼저 Pod 모두 삭제합니다. 그렇게 되면 서비스에 대한 다운타임이 발생하고, 자원 사용량도 없어지게 됩니다. 그 후 v2에 대한 Pod 2개를 만들어 줍니다. 단점은 다운타임이 발생해서 일시적인 정지가 가능한 서비스인 경우에만 가능한 방법입니다.

 

 

Rolling Update

: 원래의 상태에서 업그레이드 할 때 Deployment는 먼저 v2의 Pod를 하나 만들어줍니다. 그럼 자원 사용량이 하나 늘어날거고, 이 상태부터는 v1, v2에 모두 서비스가 되고 있기 때문에 누군가는 v1에 접속이 되고, 누군가는 v2 하게 됩니다. 그런 다음 Deployment는 v1의 Pod를 하나 삭제하고, 다음으로 남은 v2 파드를 하나 만들고 끝으로 남은 v1 파드를 삭제하면서 사용자들은 v2의 서비스에만 접속을 하게 됩니다. 이 방식은 배포 중간에 추가적인 자원을 요구하지만, 장점은 다운타임이 없다는 것이에요.

 

 

Blue/Green

: Deployment 자체 기능은 아니고, 이것은 리플리카 셋과 같이 Replicas를 관리하는 모든 컨트롤러를 이용해서 할 수 있습니다. 위처럼 컨트롤러를 만들어서 Pod가 생성되면, Pod에는 라벨이 있기 때문에 서비스에 있는 셀렉터와 연결됩니다. 이렇게 운영이 되고 있는 상태에서 컨트롤러를 하나 만듭니다. v2 버전에 대한 Pod와 라벨을 만듭니다. 그래서 자원 사용량은 2배가 됩니다. 추후 서비스의 라벨만 변경을 해주게 되면 기존 Pod 연결은 끊어주고, v2 Pod에 대해서 연결을 해줍니다. 결과적으로 v2 버전의 서비스를 사용할 수 있고, 순간적으로 변경되기 때문에 서비스에 대한 다운타임이 없습니다. 만약 v2에 문제가 발생한다면, 해당 Pod만 v1으로 바꿔주어서 기존 서비스로 전환이 되어 문제시 롤백이 쉽다는 장점이 있습니다. 문제가 없다면 기존 버전은 삭제하면 됩니다. 단점으로 자원이 2배가 필요하는 것 입니다. 

 

 

Canary

: Canary 배포는 실험체를 통해 위험을 검증하고, 위험이 없다는 게 확인이 되면 정식으로 배포하는 방식입니다. v1에 대한 Pod가 있고, Service를 만드는데 v1이 아닌 type:app 라벨을 달아서 연결을 놓습니다. 이렇게 운영중인 상태에서 테스트용으로 컨트롤러를 만들 때 Replicas를 1로 해서 v2에 대한 Pod를 하나 만들고, 똑같이 type:app 라벨을 달면 이 서비스에 연결이 됩니다. 그럼 이 서비스로 들어오는 트래픽은 3개의 버전에 대한 테스트가 진행됩니다. 그러다가 문제가 발생하면 컨트롤러의 Replicas만 0으로 변경하면 됩니다. 이것은 불특정 다수에 대해 테스팅 하는 방식이고,

 

  v1은 v1 대로 v2는 v2대로 각각의 서비스를 만드는데 이를 인그레스 컨트롤러라고 합니다. 유입되는 트래픽을 이렇게 URL 패스에 따라서 서비스에 연결해주는 역할을 하는 컨트롤러가 있는데 이렇게 해놓으면 path 앞에 v2를 단 사람들은 새 버전에 대한 서비스를 사용하게 됩니다. 예로 우리가 글로벌한 서비스를 운영한다면 새로 배포될 서비스는 미국을 테스트 배드 지역으로 설정한다고 정할 수 가 있고, URL 앞에 미국에서 접근했으면 EN을 붙이도록 만들어요. 그러면 인그레스 컨트롤러가 미국에서 접근하는 사람들한테만 v2에 대한 서비스로 연결을 해줍니다. 이렇게 특정 타켓을 정해놓고 테스팅을 할 수 있습니다. 그렇게 테스트가 문제 없다면 v2에 대한 Pod를 증가시키고, 인그레스 컨트롤러의 설정을 변경한 후에 기존 v1에 대한 내용들을 삭제하면 됩니다. 장점으로 다운타임이 존재하지 않고, 자원 사용량은 테스트를 할 Pod 수나 v2 Pod를 얼마나 만들어 놓고 v1 Pod를 다운시키느냐에 따라서 필요한 자원량은 증가하게 됩니다.

 

 이렇게 일반적으로 사용되는 배포 방식과 k8s에서 이것을 어떻게 사용할 수 있는지 설명했는데 ReCreate, Rolling Update에 대해 자세하게 알아볼 것 입니다. Blue/Green은 실습 때 확인하겠습니다.   

 

 

1) ReCreate

: 먼저 Deployment를 만들 때 Replica에서 넣었던 셀렉터와 Replicas, Template 값을 똑같이 넣어줍니다. 이 값들은 직접 이 Deployment가 Pod를 만들어서 관리를 하기 위한 값이 아니고, 위처럼 ReplicaSet을 만들고 이곳에 값들을 지정하기 위한 용도입니다. 그래서 만들어진 ReplicaSet은 본인의 역할대로 Pod를 만들게 됩니다. 그리고 Service를 만들어서 붙어있는 라벨에 연결을 하면 이 서비스를 통해서 Pod에 접근할 수 있게 됩니다.

 

 ReCreate 업그레이드를 하려면 Deployment에 있는 템플릿을 v2 버전으로 업데이트 해주면 되는데, 그러면 이 Deployment는 ReplicaSet의 Replicas 값을 0으로 변경합니다. 그러면 ReplicaSet은 Pod 제거를 하고, 서비스도 연결 대상이 없어집니다. 이때 다운 타임이 발생하게 됩니다. 그리고 새로운 ReplicaSet을 만드는데 이 템플릿에는 변경된 v2의 Pod를 넣기 때문에 Pod들도 v2 버전으로 생성되고, Service는 해당 라벨을 통해 연결이 자동적으로 Pod와 이어집니다. 

 

 

2) Rolling update (default)

: 기존세팅은 위와 같고, 버전을 업데이트 하게 되면서 롤링 업데이트가 시작되는데 먼저 ReplicaSet을 하나 만들고 Replicas 값이 1이기 때문에 Pod가 1개 만들어지면서 이 v1 라벨과 똑같은 라벨이 만들어지니까 서비스에 연결이 됩니다. 그래서 위 Service에 연결을 하면 v1, v2의 트래픽이 분산되서 보내지게 됩니다. 이후 원래 있던 ReplicaSet을 1로 변경하면 Pod가 1개 감소하고, 삭제가 완료되면 새로 만든 ReplicaSet의 값을 2로 만들어 파드를 한개 추가합니다. 이렇게 진행하면 마찬가지로 ReplicaSet을 지우지 않고 배포를 종료하게 됩니다. 

 

 

 

실습

1. ReCreate

: Deployment는 여러 ReplicaSet을 만들고 각각의 ReplicaSet은 자신의 Pod를 구별하기 위해 추가적인 라벨과 셀렉터를 붙여줍니다. 이는 Pod Template Hash라고 키와 밸류가 있고, 실제 Pod를 가보면 아래와 같이 Pod에도 추가 라벨이 붙어있는 것을 확인할 수 있습니다. 추가로 Pod에 라벨과 서비스를 붙였을 때 결과는 아래 그림에 있습니다. 그리고 ClusterIp로 만들었기 때문에 이 주소를 복사해서 서비스에 접근이 가능한지 확인해보겠습니다.

Service의 본인 Selector, Label 확인

추가로 부여된 Pod의 Template Hash

생성한 Pod에 접근 확인 여부

 

 

 이제 배포는 Deployment에서 image를 v1 -> v2로 변경을 하고 업데이트를 누르면 아래 그림과 같이 바로 시작이 됩니다. v1 ReplicaSets의 Pod가 0이 되었고, v2 ReplicaSets의 Pod는 2가 되었습니다. 다운타임이 생겨 연결이 끊어졌다는 문구도 보이죠??

v2로 버전 업데이트 하는 과정

v1으로 롤백하는 과정

 

 

2. Rolling update

 

업데이트 전 준비 상황

Rolling update 버전 업데이트

 

 ReCreate와 같이 업데이트 할 준비를 위 그림으로 확인했습니다. 참고로 svc-2는 다른 1과 당연히 다른 ClusterIP 이기 때문에 주의해주세요!! v1 -> v2 버전으로 변경을 하고, 실행해보면 v2 버전의 Pod가 1개씩 생성되면서, v1의 Pod는 1개씩 죽을겁니다. 결국 나중에는 v2의 Pod만 남아있게 되겠죠.

 

 

 

3. Blue/Green

 

업데이트 전 접속 확인

ReplicaSets와 서비스를 1개씩 생성하고, ReplicaSets를 한개 더 추가하는데 v2로 셀렉터와 Label을 수정해줍니다. 그리고 svc-3에서 초기에는 v1과 관련된 라벨을 가진 Pod를 지니고, 셀렉터의 설정이 v1이었지만 다운타임 없이 위처럼 바로 변경되는 것을 확인 할 수 있습니다.