왜 GKE 노드 자동 업그레이드로 애플리케이션 서비스가 중지되는지

개요

GKE에서 제공하는 노드 자동 업그레이드은 유용하지만 인스턴스 재부팅을 고려하지 않은 구성 및 설정은 응용 프로그램 서비스를 중지합니다.
해결하는 문제는 적지만 애플리케이션 서비스가 중지되는 경우와 해결 방법을 정리했습니다.

환경

Kubernetes(GKE): >= v1.6

애플리케이션 서비스가 중단되는 경우

포드 배치가 치우친

spec.replicas: 2 의 Deployment 를 apply 하면 아래 그림과 같이 하나의 인스턴스로 치우치는 경우가 발생합니다.

노드의 업그레이드는 1대씩 kubectl drain 하므로, PodA 가 같은 타이밍에 terminate 됩니다.

이 상태가 되면, PodA 와 통신을 할 수 없기 때문에, 어플리케이션 서비스의 정지에 연결됩니다.

해결 방법

PodDisruptionBudget 설정

kubectl drain 런타임에 maxAvailable를 설정하여 Pod의 시작 수를 조정할 수 있습니다

minAvailable를 사용하는 경우 spec.replicas의 수치가 작 으면 ALLOWED DISRUPTIONS의 수치가 0이되므로주의

PodAffinity 설정

필수는 아니지만 업그레이드 시간이 단축되고 내결함성이 향상

포드의 배치가 편향됨(kube-dns)

namespace=kube-system kube-dns에 대해서도 비슷한 문제가 발생합니다 (GKE v1.6에서 확인).
이전 문제와 마찬가지로 PodDisruptionBudget를 설정할 수 있습니다.
그러나 Evict 처리로 다른 인스턴스로 이동한 Pod가 왜인가 terminate 되고 kubectl drain 의 처리가 타임 아웃할 때까지 처리가 정지합니다.
이것은 kube-dns-autoscaler 가 독자적으로 kube-dns 의 Pod 를 컨트롤 하고 있기 때문이라고 생각합니다.

해결 방법

해결할 수 없습니다.
kube-dns에 PodDisruptionBudget 설정Issue 도 있기 때문에 장래적으로는 해소될 것입니다.
kube-dns의 기동은 몇 초이므로, 10초 정도의 다운타임을 허용할 수 있는 어플리케이션 서비스라면 문제가 되지 않습니다.kube-dns 를 delete pod 하는 것으로, 인스턴스를 이동시키는 것도 가능합니다만, 업그레이드중에 다시 치우칠 가능성이 있기 때문에 효과는 얇습니다.

Stateful 응용 프로그램 재시작 처리를 고려하지 않음

이것은 단순히 영속화가 필요한 데이터에 PersistentVolume의 설정이 되어 있지 않은 실수나, StatefulSets 의 어플리케이션, 미들웨어의 초기화 스크립트가 누설되고 있는 경우입니다.
예를 들어 RedisCluster의 경우 init-containers 처리에서 클러스터로 돌아가거나 리샤딩하는 스크립트가 필요합니다.
해결 방법도 개별 대응이므로 본 기사에는 기재하지 않습니다.