보안과 성능을 최적화하기 위해 애플리케이션을 최신 상태로 유지하는 것이 좋은 방법이라는 것을 누구나 알고 있습니다. Kubernetes 및 Docker를 사용하면 업데이트로 새 컨테이너를 빌드하고 비교적 쉽게 배포 할 수 있으므로 이러한 업데이트를 훨씬 쉽게 수행 할 수 있습니다.
애플리케이션과 마찬가지로 Kubernetes는 새로운 기능과 보안 업데이트를 지속적으로 받고 있으므로 기본 노드와 Kubernetes 인프라도 최신 상태로 유지해야합니다.
이 Kubernetes 권장 사항 에피소드에서는 Google Kubernetes Engine 이 Kubernetes 클러스터를 손쉽게 업그레이드 할 수 있는 방법을 살펴 보겠습니다 .
클러스터의 두 부분
클러스터를 업그레이드 할 때 업데이트해야하는 두 부분 인 마스터와 노드가 있습니다. 먼저 마스터를 업데이트 한 다음 노드를 따라갈 수 있습니다. Kubernetes Engine을 사용하여 두 가지를 모두 업그레이드하는 방법을 살펴 보겠습니다.
다운 타임없이 마스터를 업그레이드하면
Kubernetes Engine이 포인트 릴리스가 출시 될 때 마스터를 자동으로 업그레이드하지만 일반적으로 새 버전 (예 : 1.7에서 1.8)으로 자동으로 업그레이드되지 않습니다. 새 버전으로 업그레이드 할 준비가되면 Kubernetes Engine 콘솔에서 마스터 업그레이드 버튼을 클릭하기만 하면됩니다.
그러나 대화 상자에 다음 내용이 표시됩니다.
“마스터 버전을 변경하면 몇 분의 제어 플레인 다운 타임이 발생할 수 있습니다. 이 기간 동안에는이 클러스터를 편집 할 수 없습니다. "
업그레이드를 위해 마스터가 다운되면 배포, 서비스 등이 예상대로 계속 작동합니다. 그러나 Kubernetes API가 필요한 모든 것이 작동을 멈 춥니 다. 즉, kubectl이 작동을 중지하고 Kubernetes API를 사용하여 클러스터에 대한 정보를 얻는 애플리케이션이 작동을 중지하며 기본적으로 업그레이드하는 동안 클러스터를 변경할 수 없습니다.
그렇다면 다운 타임없이 마스터를 업데이트하는 방법은 무엇입니까?
Kubernetes Engine 지역 클러스터가있는 고 가용성 마스터
표준 '영역'Kubernetes Engine 클러스터에는이를 지원하는 마스터 노드가 하나만 있지만 다중 영역의 고 가용성 마스터를 제공하는 '지역'클러스터를 만들 수 있습니다.
클러스터를 생성 할 때 "지역"옵션을 선택해야합니다.
그리고 그게 다야! Kubernetes Engine은 부하 분산 된 IP 주소 뒤에 마스터가있는 세 영역에 노드와 마스터를 자동으로 생성하므로 Kubernetes API는 업그레이드 중에 계속 작동합니다.
다운 타임없이 노드 업그레이드
노드를 업그레이드 할 때 사용할 수있는 몇 가지 다른 전략이 있습니다. 집중하고 싶은 두 가지가 있습니다.
- 롤링 업데이트
- 노드 풀을 사용한 마이그레이션
롤링 업데이트
Kubernetes 노드를 업데이트 하는 가장 간단한 방법은 롤링 업데이트를 사용하는 것입니다. 이는 Kubernetes Engine이 노드를 업데이트하는 데 사용하는 기본 업그레이드 메커니즘입니다.
지속적 업데이트는 다음과 같은 방식으로 작동합니다. 하나씩 노드가 드레 이닝되고 연결되어 해당 노드에서 실행중인 포드가 더 이상 없습니다. 그런 다음 노드가 삭제되고 업데이트 된 Kubernetes 버전으로 새 노드가 생성됩니다. 해당 노드가 가동되고 실행되면 다음 노드가 업데이트됩니다. 모든 노드가 업데이트 될 때까지 계속됩니다.
노드 풀에서 자동 노드 업그레이드를 사용 설정하여 Kubernetes Engine이이 프로세스를 완전히 관리하도록 할 수 있습니다.
이 옵션을 선택하지 않으면 Kubernetes Engine 대시 보드는 업그레이드가 가능할 때 알림을 표시합니다.
링크를 클릭하고 프롬프트에 따라 지속적 업데이트를 시작하십시오.
경고 : 팟 (Pod)이 ReplicaSet, 배포, StatefulSet 또는 이와 유사한 것으로 관리되는지 확인하십시오. 독립 실행 형 포드는 일정이 변경되지 않습니다!
Kubernetes Engine에서 지속적 업데이트를 수행하는 것은 간단하지만 몇 가지 단점이 있습니다.
한 가지 단점은 클러스터에서 용량 노드가 하나 더 적다는 것입니다. 이 문제는 노드 풀을 확장하여 용량을 추가 한 다음 업그레이드가 완료되면 다시 축소하면 쉽게 해결할 수 있습니다.
롤링 업데이트의 완전 자동화 된 특성으로 인해 쉽게 수행 할 수 있지만 프로세스에 대한 제어 권한이 떨어집니다. 롤링 업데이트를 중지 한 다음 실행 취소해야하므로 문제가있는 경우 이전 버전으로 롤백하는데도 시간이 걸립니다.
노드 풀을 사용한 마이그레이션
롤링 업데이트 에서처럼 '활성'노드 풀을 업그레이드하는 대신 새 노드 풀을 만들고 모든 노드가 실행될 때까지 기다린 다음 한 번에 하나의 노드로 워크로드를 마이그레이션 할 수 있습니다.
현재 Kubernetes 클러스터에 3 개의 VM이 있다고 가정 해 보겠습니다. 다음 명령으로 노드를 볼 수 있습니다.
kubectl get nodes NAME STATUS AGE gke-cluster-1-default-pool-7d6b79ce-0s6z Ready 3h gke-cluster-1-default-pool-7d6b79ce-9kkm Ready 3h gke-cluster-1-default-pool-7d6b79ce-j6ch Ready 3h
새 노드 풀 만들기
'pool-two'라는 이름으로 새 노드 풀 을 만들려면 다음 명령어를 실행하세요.
gcloud container node-pools create pool-two
참고 : 새 노드 풀이 이전 풀과 동일하도록이 명령어를 맞춤 설정해야합니다. 원하는 경우 GUI를 사용하여 새 노드 풀을 만들 수도 있습니다.
이제 노드를 확인하면 새 풀 이름을 가진 세 개의 노드가 더 있음을 알 수 있습니다.
$ kubectl get nodes NAME STATUS AGE gke-cluster-1-pool-two-9ca78aa9–5gmk Ready 1m gke-cluster-1-pool-two-9ca78aa9–5w6w Ready 1m gke-cluster-1-pool-two-9ca78aa9-v88c Ready 1m gke-cluster-1-default-pool-7d6b79ce-0s6z Ready 3h gke-cluster-1-default-pool-7d6b79ce-9kkm Ready 3h gke-cluster-1-default-pool-7d6b79ce-j6ch Ready 3h
그러나 포드는 여전히 이전 노드에 있습니다! 이동합시다.
이전 풀 비우기
이제 작업을 새 노드 풀로 이동해야합니다. 롤링 방식으로 한 번에 하나의 노드 위로 이동합시다.
첫째, 막 으면 이전의 각 노드를. 이렇게하면 새 포드가 예약되지 않습니다.
kubectl cordon <node_name>
모든 이전 노드가 연결되면 새 노드에서만 포드를 예약 할 수 있습니다. 즉, 이전 노드에서 포드 제거를 시작할 수 있으며 Kubernetes는 새 노드에서 포드를 자동으로 예약합니다.
경고 : pod가 ReplicaSet, Deployment, StatefulSet 또는 이와 유사한 것으로 관리되는지 확인하십시오. 독립 실행 형 포드는 일정이 변경되지 않습니다!
다음 명령을 실행하여 각 노드 를 드레 이닝합니다. 그러면 해당 노드의 모든 포드가 삭제됩니다.
kubectl drain <node_name> --force
노드를 드레 이닝 한 후 다음 포드로 이동하기 전에 새 포드가 실행 중인지 확인합니다.
마이그레이션 중에 문제가있는 경우 이전 풀의 연결을 해제 한 다음 새 풀을 연결하고 비우십시오. 포드가 이전 풀로 다시 예약됩니다.
이전 풀 삭제
모든 포드가 안전하게 다시 예약되면 이전 풀 을 삭제할 차례입니다.
"default-pool"을 삭제할 풀로 바꿉니다.
gcloud container node-pools delete default-pool
모든 노드를 성공적으로 업데이트했습니다!
결론
Kubernetes Engine을 사용하면 몇 번의 클릭만으로 Kubernetes 클러스터를 최신 상태로 유지할 수 있습니다.
Kubernetes와 같은 관리 형 서비스를 사용하지 않는 경우에도 자체 클러스터에서 롤링 업데이트 또는 노드 풀 방법을 사용하여 노드를 업그레이드 할 수 있습니다. 차이점은 클러스터에 새 노드를 수동으로 추가하고 마스터 업그레이드를 직접 수행해야한다는 점입니다. 까다로울 수 있습니다.
고 가용성 마스터 및 자동 노드 업그레이드에 Kubernetes Engine 지역 클러스터를 사용하여 번거롭지 않은 업그레이드 경험을 제공하는 것이 좋습니다. 노드 업데이트에 대한 추가 제어가 필요한 경우 노드 풀을 사용하면 Kubernetes Engine이 제공하는 관리 형 Kubernetes 플랫폼의 이점을 포기하지 않고도 제어 할 수 있습니다.
따라서 Kubernetes 모범 사례에 대한이 시리즈를 마칩니다. 나중에 다루고 싶은 다른 주제에 대한 아이디어가 있으면 Twitter에서 저를 찾을 수 있습니다 . 이번 7 월 Google Cloud Next '18 에 참석하신다면 꼭 들러서 인사 해주세요!