다운타임 없이 Kubernetes 클러스터 업그레이드

Kubernetes 클러스터 업그레이드 프로세스

어느 시점에서는 Kubernetes 클러스터를 사용할 때 실행 중인 노드를 업데이트해야 할 필요가 있습니다. 여기에는 패키지 업데이트, 커널 업데이트 또는 새 가상 머신 이미지 배포가 포함될 수 있습니다. Kubernetes 용어에서는 이를 다음과 같이 부릅니다. "자발적 방해".

이 게시물은 4개 게시물 시리즈의 일부입니다.

1. 이 게시물.
2. Kubernetes 클러스터에서 포드의 올바른 종료
3. 포드 삭제 시 포드 종료 지연
4. PodDisruptionBudget을 사용하여 Kubernetes 클러스터 가동 중지 시간을 방지하는 방법

(대략. 가까운 시일 내에 시리즈의 나머지 기사에 대한 번역이 나올 것으로 예상됩니다.)

이 문서에서는 클러스터에서 실행되는 노드의 가동 중지 시간을 없애기 위해 Kubernetes가 제공하는 모든 도구에 대해 설명합니다.

문제 정의

우리는 처음에는 순진한 접근 방식을 취하고, 문제를 식별하고 이 접근 방식의 잠재적 위험을 평가하며, 주기 전반에 걸쳐 직면하는 각 문제를 해결하기 위한 지식을 구축할 것입니다. 그 결과 제로 다운타임 목표를 달성하기 위해 수명 주기 후크, 준비 상태 프로브 및 Pod 중단 예산을 사용하는 구성이 탄생했습니다.

여정을 시작하려면 구체적인 예를 들어보겠습니다. 두 개의 노드로 구성된 Kubernetes 클러스터가 있고, 그 뒤에 두 개의 포드가 있는 애플리케이션이 실행되고 있다고 가정해 보겠습니다. Service:

두 개의 Kubernetes 클러스터 노드에서 실행되는 Nginx 및 Service가 포함된 두 개의 포드부터 시작하겠습니다.

클러스터에 있는 두 작업자 노드의 커널 버전을 업데이트하려고 합니다. 어떻게 해야 할까요? 간단한 해결책은 업데이트된 구성으로 새 노드를 부팅한 다음 새 노드를 시작하는 동안 이전 노드를 종료하는 것입니다. 이 방법은 작동하지만 이 접근 방식에는 몇 가지 문제가 있습니다.

• 이전 노드를 끄면 해당 노드에서 실행 중인 포드도 꺼집니다. 정상적인 종료를 위해 Pod를 지워야 하는 경우에는 어떻게 되나요? 사용 중인 가상화 시스템은 정리 프로세스가 완료될 때까지 기다리지 않을 수 있습니다.
• 모든 노드를 동시에 끄면 어떻게 될까요? Pod가 새 노드로 이동하는 동안 상당한 가동 중지 시간이 발생합니다.

노드를 변경하는 동안 작업자 프로세스가 실행되지 않도록 하면서 이전 노드에서 포드를 정상적으로 마이그레이션하는 방법이 필요합니다. 또는 예제에서처럼 클러스터를 완전히 교체할 때(즉, VM 이미지 교체) 실행 중인 애플리케이션을 이전 노드에서 새 노드로 전송하려고 합니다. 두 경우 모두 새 포드가 이전 노드에서 예약되는 것을 방지한 다음 실행 중인 모든 포드를 해당 노드에서 제거하려고 합니다. 이러한 목표를 달성하기 위해 다음 명령을 사용할 수 있습니다. kubectl drain.

노드의 모든 포드 재배포

드레이닝 작업을 사용하면 노드의 모든 Pod를 재배포할 수 있습니다. 드레이닝 실행 중에 노드는 예약 불가능으로 표시됩니다(플래그 NoSchedule). 이렇게 하면 새 포드가 표시되는 것을 방지할 수 있습니다. 그런 다음 배수가 노드에서 포드를 제거하기 시작하고 현재 노드에서 실행 중인 컨테이너를 종료하여 신호를 보냅니다. TERM 포드의 컨테이너.

이기는하지만 kubectl drain 포드 제거 작업을 훌륭하게 수행할 것입니다. 배수 작업이 실패할 수 있는 다른 두 가지 요인이 있습니다.

• 귀하의 신청서는 제출 시 정상적으로 종료될 수 있어야 합니다. TERM 신호. Pod가 제거되면 Kubernetes는 신호를 보냅니다. TERM 컨테이너를 종료하고 지정된 시간 동안 컨테이너가 중지될 때까지 기다린 후 중지되지 않은 경우 강제로 종료합니다. 어떤 경우든 컨테이너가 신호를 올바르게 인식하지 못하는 경우 현재 실행 중인 포드(예: 데이터베이스 트랜잭션이 진행 중)라면 포드를 잘못 끌 수 있습니다.
• 애플리케이션이 포함된 모든 포드가 손실됩니다. 새 컨테이너가 새 노드에서 시작될 때 사용하지 못할 수도 있고, 컨트롤러 없이 포드가 배포된 경우 전혀 다시 시작되지 않을 수도 있습니다.

다운타임 방지

노드의 드레이닝 작업과 같은 자발적인 중단으로 인한 가동 중지 시간을 최소화하기 위해 Kubernetes는 다음과 같은 오류 처리 옵션을 제공합니다.

• 우아한 종료
• 수명주기 후크
• PodDisruptionBudgets

시리즈의 나머지 부분에서는 이러한 Kubernetes 기능을 사용하여 포드 마이그레이션의 영향을 완화할 것입니다. 주요 아이디어를 더 쉽게 따르기 위해 다음 리소스 구성과 함께 위의 예를 사용하겠습니다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

이 구성은 최소한의 예입니다. Deployment, 클러스터의 nginx 포드를 관리합니다. 또한 구성은 리소스를 설명합니다. Service, 클러스터의 nginx 포드에 액세스하는 데 사용할 수 있습니다.

주기 전반에 걸쳐 이 구성을 반복적으로 확장하여 결국에는 가동 중지 시간을 줄이기 위해 Kubernetes가 제공하는 모든 기능을 포함하게 됩니다.

AWS 이상에서 다운타임이 발생하지 않도록 완벽하게 구현되고 테스트된 Kubernetes 클러스터 업데이트 버전을 보려면 다음을 방문하세요. 그런트워크.io.

블로그에서 다른 기사도 읽어보세요.

• 가동 중지 시간이 없는 배포 및 데이터베이스
• Kubernetes: 시스템 리소스 관리를 설정하는 것이 왜 그렇게 중요한가요?
• Tekton Pipeline - Kubernetes 기반 파이프라인
• Nginx용 동적 모듈 빌드
• Hashicorp Consul의 Kubernetes 인증 소개
• 승인이 없는 ClickHouse에서 승인이 있는 ClickHouse로 마이그레이션한 결과는 무엇입니까?

출처 : habr.com