노드 드레인 다시 생각하기: 웹훅 기반의 우아한 파드 제거 접근법

쿠버네티스에서 스테이트풀 애플리케이션을 실행할 때 노드 드레인을 더 안전하게 만들기 위해 어드미션 컨트롤러를 구축한 이유와 방법.

쿠버네티스에서 스테이트풀 애플리케이션을 실행하는 것이 점점 더 일반화되고 있으며, 이러한 애플리케이션은 사용자 정의 리소스와 오퍼레이터를 사용하여 관리되는 경우가 많습니다. 그러나 Kubernetes의 동적 특성으로 인해 파드, 특히 스테이트풀 워크로드의 파드는 수명이 보장되지 않습니다. 유지 관리 또는 리소스 압박과 같은 이벤트는 파드 퇴출을 트리거할 수 있으며, 신중하게 처리하지 않으면 서비스가 중단될 위험이 있습니다.

이비젝션 리스케줄 훅은 쿠버네티스 어드미션 컨트롤러를 사용하여 운영자가 관리하는 파드에 대한 이비젝션 요청을 가로채고 거부하는 동시에 운영자에게 파드를 이동해야 함을 알림으로써 이 문제를 해결하는 것을 목표로 하는 오픈소스 프로젝트이다. 그 목표는 서비스 가용성을 유지하고 노드 유지 관리와 같은 이벤트 중에 중단을 줄이는 것입니다.

계속 읽어보세요:

• • 우리가 해결하고 있는 문제
  • 기존 옵션으로는 충분하지 않은 이유
  • 훅 프로젝트 일정 변경 소개

쿠버네티스에 익숙하다면 연산자노드 배수, 입장 제어 역동적인 웹훅 를 참고하시면 도움이 될 것 같아서 주요 개념에 대해 설명해드리려고 합니다. 그리고 카우치베이스 간결성을 위해 전체에서 자율 운영자를 운영자라고 지칭하며, 대부분의 예제와 데모에는 일종의 카우치베이스 리소스가 포함됩니다.

원래 Couchbase 데이터 플랫폼을 염두에 두고 개발되었지만, 재스케줄 후크 프로젝트는 유연하게 사용할 수 있도록 고안되었으며 다른 운영자가 관리하는 상태 저장 애플리케이션을 보호하도록 구성할 수 있습니다.

1부 - 운영자가 관리하는 스테이트풀 애플리케이션에서 퇴거가 어려운 이유

파드 퇴출에 대한 이해

쿠버네티스에서 파드를 퇴출하려면 파드의 사전 중지 훅을 보낸 다음 SIGTERM 가 완료된 후 종료됩니다. 유예 기간 후에도 파드가 종료되지 않으면 후속 조치로 SIGKILL. 퇴출은 노드 압력에서 자동 확장에 이르기까지 다양한 이유로 자발적 또는 비자발적으로 발생하지만, 이 프로젝트에서는 노드를 배수할 때 트리거되는 자발적 퇴출에 초점을 맞추고 있다. 이는 유지 관리 또는 업그레이드와 같은 작업을 위해 길을 비우기 위해 종종 필요한 Kubernetes Eviction API를 사용하여 노드에서 파드가 제거되는 프로세스입니다.

실행 중 kubectl 배수 는 쿠버네티스에서 유지보수를 위해 노드를 준비하는 일반적인 방법이다. 노드를 스케줄할 수 없는 것으로 표시하고 해당 노드에서 실행 중인 모든 파드에 대해 동시에 퇴거 요청을 보냅니다.

스테이트풀 애플리케이션이 어려운 이유

스테이트풀 워크로드는 퇴거 처리에 복잡성을 더합니다:

예측할 수 없는 종료 시간: 이러한 워크로드에는 파드를 안전하게 종료하기 전에 완료해야 하는 비행 중 쿼리와 같은 장기 실행 프로세스가 포함될 수 있습니다.

애플리케이션 조정: 데이터 일관성과 적절한 리밸런싱을 보장하기 위해 애플리케이션 자체에 파드를 제거하기 전에 알림을 보내야 하는 경우가 많습니다.

운영자 관리: 애플리케이션을 관리하는 운영자는 운영자의 내부 상태와 포드 제거를 조율할 시간이 필요합니다.

볼륨 이동: 한 노드에서 다른 노드로 쿠버네티스 볼륨을 마이그레이션하는 데는 파드의 시간을 초과하는 상당한 시간이 소요될 수 있다. 종료유예기간초

운영자는 사용자 지정 리소스에 정의된 원하는 상태와 실제 상태를 지속적으로 조정하여 복잡한 애플리케이션의 수명 주기를 자동화합니다.

Couchbase를 예로 들어보겠습니다. Couchbase 클러스터는 여러 개의 파드로 구성되며, 각 파드는 일반적으로 서로 다른 노드 및 가용성 영역에 분산되어 Couchbase Server 인스턴스를 실행합니다. 운영자는 클러스터 상태가 정의된 상태와 일치하는지 확인합니다. 카우치베이스클러스터 리소스. 파드를 제거해야 하는 경우, 운영자는 클러스터에 데이터 균형을 재조정하고 실행 중인 모든 프로세스를 정상적으로 처리하도록 알려야 합니다.

조직의 과제

또 다른 일반적인 문제는 대규모 조직에서 책임이 분리되어 있다는 점입니다:

• • Kubernetes 관리자가 인프라 관리
  • 애플리케이션 팀은 해당 인프라에서 실행되는 상태 저장 애플리케이션을 관리합니다.

즉, Kubernetes 관리자는 애플리케이션 소유자와 지속적으로 조정하거나 기본 애플리케이션의 가용성 또는 상태에 영향을 주지 않고 유지보수를 수행하기 위해 노드를 안전하게 배출할 수 있는 방법이 필요합니다.

기존 쿠버네티스 보호 - 충분하지 않은 이유

쿠버네티스는 다음과 같은 도구를 제공합니다. 프리스톱 후크 그리고 파드 중단 예산 를 사용하여 퇴거 중에도 애플리케이션을 정상적으로 종료하고 애플리케이션 가용성을 유지할 수 있습니다.

프리스톱 후크 컨테이너 내부에서 스크립트를 실행하기 전에 SIGTERM 신호를 보내서 파드가 정상적으로 종료될 수 있는 기회를 제공합니다. 상태 비저장 애플리케이션의 경우, 이것으로 충분할 때가 많습니다. 그러나 상태 저장 앱의 경우, 운영자는 위에서 설명한 문제를 피하기 위해 종료 전에 파드 제거를 조정해야 하는 경우가 많으며, 이는 preStop 훅 내부에서 수행하기 까다롭습니다.

우리가 본 한 가지 독창적인 접근 방식은 오퍼레이터가 사용하는 파드 템플릿에 preStop 스크립트를 추가하는 것입니다. 이 스크립트는 파드가 자체적으로 재스케줄 어노테이션(나중에 설명)을 추가하여 운영자에게 이동해야 함을 알린 다음 클러스터에서 안전하게 배출될 때까지 반복하도록 합니다.

스크립트의 기본 개요는 정확하지 않습니다:

그러나 이를 위해서는 마운팅이 필요합니다. kubectl 그리고 couchbase-cli 를 각 파드에 추가하여 복잡성과 이미지 크기를 늘립니다. 또한 네트워킹 또는 기타 문제로 인해 스크립트가 중단되어 파드가 조기에 종료될 수 있습니다.

파드 중단 예산(PDB) 는 자발적 중단 중에 최소한의 파드를 사용할 수 있도록 보장합니다. 하지만 동시에 제거할 수 있는 파드의 수만 제한하기 때문에 운영자가 파드 제거를 원활하게 처리할 수 없는 시나리오를 여전히 처리하고 있습니다.

오늘 포드가 퇴거되면 어떻게 되나요?

운영자는 한 번에 퇴출할 수 있는 파드 수를 제한하기 위해 Couchbase용 PDB를 생성합니다. 이렇게 하면 애플리케이션의 가용성이 최소 수준으로 보장되지만, 퇴출되는 파드는 장애 조치를 통해 Couchbase 클러스터에서 안전하지 않게 제거됩니다.

또한 운영자가 이 문제를 어떻게 처리하는지 Couchbase 관리자 UI에서 확인할 수 있습니다.

한 번에 하나의 파드에서 퇴출이 발생하더라도, 파드가 새 노드에서 다시 시작되면, Kubernetes는 새 파드가 스테이트풀 애플리케이션에 안전하게 추가되기 전에 다음 파드에서 퇴출을 허용할 수 있습니다. Couchbase에서는 파드의 준비 게이트를 통해 이를 방지합니다.

이러한 문제를 해결하기 위해 cao.couchbase.com/reschedule 어노테이션을 추가했습니다. 파드에 추가되면 운영자에게 다시 생성해야 함을 알려줍니다. 그러나 수동으로 노드를 코딩하고 이 어노테이션을 추가하는 것은 지루하고 확장성이 좋지 않으며 Couchbase 포드에만 영향을 미치며 다른 포드에는 여전히 정상적인 드레인이 필요합니다.

오퍼레이터 내부에서 이를 전적으로 처리하는 것은 어떨까요?

퇴거 유효성 검사 로직을 오퍼레이터 자체에 내장하는 것을 고려했지만:

• • 이는 쿠버네티스 오퍼레이터 설계의 안티 패턴이다. 오퍼레이터는 어드미션 컨트롤러가 아닌 조정 루프를 통해 작업합니다.
  • 운영자에게 입장 제어 엔드포인트를 추가하면 배포 및 유지 관리가 복잡해집니다.
  • 웹훅 유효성 검사는 클러스터 범위의 리소스이므로 클러스터 범위의 권한이 필요합니다. 오퍼레이터는 네임스페이스 범위가 지정되어 있으므로 필요한 권한을 크게 확장해야 합니다.
  • 이 로직을 자체 프로젝트에 구축하면 오픈 소싱이 가능하고 유사한 사용 사례에 대한 커뮤니티 기여를 유도할 수 있습니다.

2부 - 지능적인 파드 퇴거를 위한 Kubernetes 웹훅 활용하기

에비션 리스케줄 훅은 1부에서 설명한 문제를 피하기 위해 노드 드래그 중에 에비션이 처리되는 방식을 개선하도록 설계된 오픈소스 쿠버네티스 어드미션 컨트롤러이다. 오퍼레이터와 함께 작동하며, 퇴출 요청이 파드에 도달하기 전에 가로채서 파드 스케줄링을 자동화합니다. 이러한 요청은 여전히 표준을 허용하는 방식으로 선택적으로 거부됩니다. kubectl 배수 명령이 예상대로 작동하도록 합니다.

어드미션 컨트롤러는 파드를 즉시 종료하거나 PDB(파드 중단 예산) 한도를 테스트하는 대신, 운영자에게 파드를 이동해야 함을 알린다. cao.couchbase.com/reschedule 어노테이션.

입장 관리 이해

어드미션 제어는 요청이 인증되고 권한이 부여된 후 클러스터에 지속되기 전에 발생하는 쿠버네티스 API 요청 라이프사이클의 핵심 단계입니다.

입장 컨트롤러는 사용자 지정 로직에 따라 이러한 요청의 유효성을 검사하거나 변경할 수 있습니다.

쿠버네티스에서 노드가 드래그되면, 파드 퇴출을 시도할 때마다 만들기 요청에 대한 포드/퇴거 하위 리소스. 바로 이 부분에서 어드미션 컨트롤러가 작동합니다. 이 컨트롤러는 이러한 퇴거 요청이 파드에 도달하기 전에 가로채서 허용 여부를 결정합니다. 우리의 경우, 어드미션 로직에는 재스케줄 어노테이션을 추가하여 운영자에게 파드가 안전하게 재스케줄되어야 한다는 신호를 보내는 것이 포함됩니다.

저희의 주요 목표는 퇴거 요청이 허용되는지 여부를 평가하는 것이기 때문에 변이 웹후크가 아닌 유효성 검사 웹후크를 사용하고 있습니다. 결정 과정의 일부로 파드에 주석을 달 수는 있지만, 웹훅 자체는 퇴거 요청에 대해 변이가 아닌 유효성 검사를 수행합니다.

노드 드레인 처리

이 글의 제목에서 알 수 있듯이, 이 프로젝트의 주요 목표는 노드 드레인을 원활하게 처리할 수 있도록 하는 것입니다. 퇴거 일정 재조정 훅이 적용되면 표준 노드 드레인 흐름이 수정되어 보다 안전한 파드 마이그레이션을 지원합니다.

퇴거 요청은 사전 중지 훅이 실행된다. 파드가 종료되는 대신, 퇴거 요청이 거부되고 파드에 어노테이션이 추가된다. 오퍼레이터는 각 재조정 루프 동안 스케줄 재조정 어노테이션을 확인한다. 어노테이션이 나타나면 파드 재생성을 안전하게 처리한다.

노드를 배수하면 다음과 같이 오염됩니다. node.kubernetes.io/unschedulable의 스케줄링 요구 사항과 일치하는 다른 노드가 쿠버네티스 클러스터에 있다고 가정하면, 오퍼레이터가 새 파드를 생성할 때 다른 노드에 존재할 것입니다.

중요한 것은, 어드미션 컨트롤러가 관련 파드만 선택적으로 필터링하도록 설계되었다는 점입니다. 노드의 다른 모든 워크로드는 기본 퇴출 프로세스를 계속 따릅니다.

Kubectl로 작업하기

다음과 원활하게 통합하려면 kubectl를 실행할 때 내부에서 어떤 일이 발생하는지 이해하는 것이 중요합니다. kubectl 배수. 를 보면 drain.go 출처를 사용하면 노드가 코딩된 후 해당 노드의 각 파드에 대해 별도의 고루틴이 생성되어 퇴거를 처리합니다.

여부 kubectl 가 파드 퇴출을 계속 시도하는지는 어드미션 컨트롤러의 응답에 따라 달라진다. 퇴출 요청이 성공하면(즉, 에러가 반환되지 않으면) 퇴출 요청이 전송되는 루프가 종료됩니다. 그런 다음 후속 확인이 이루어진다. kubectl 는 파드가 삭제될 때까지 기다립니다. 그러나 운영자 관리형 파드의 경우, 우리는 kubectl 를 사용하여 안전하게 일정이 변경될 때까지 계속 재시도하며, 이 시점에서는 추가 확인 전에 고루틴을 종료해야 합니다.

설계상, kubectl 를 429 너무 많은 요청 응답을 고루틴에서 퇴거 요청에 대한 신호로 5초 동안 일시 중지한 후 재시도합니다. 어드미션 컨트롤러에서 이 동작을 활용할 수 있습니다. 파드 선택 로직 이후, 파드 선택 로직이 끝나면 429 상태는 일정 변경을 위해 주석을 달거나 이미 주석을 달고 이동을 기다리고 있는 경우입니다.

파드가 성공적으로 일정이 변경된 후에는 다른 이름을 갖게 되므로 어드미션 컨트롤러가 더 이상 이름과 네임스페이스로 찾을 수 없게 됩니다. 이 시점에서, 우리는 404 찾을 수 없음 응답을 호출하여 고루틴을 종료합니다.

인-플레이스 포드 일정 변경

경우에 따라 운영자가 동일한 이름을 사용하여 파드를 삭제하고 다시 생성할 수 있습니다.

카우치베이스에서는 업그레이드 프로세스 필드에 카우치베이스클러스터 를 다음과 같이 변경할 수 있습니다. 제어 오퍼레이터가 파드를 교체하는 방법. 기본값은 다음과 같다. 스왑 리밸런싱를 사용하여 운영자에게 다른 이름의 새 파드를 생성하고 클러스터에 재밸런싱한 다음 이전 파드를 삭제하도록 지시합니다. 인플레이스업그레이드 는 더 빠르지만 덜 유연한 대안으로, 운영자가 파드를 삭제하고 동일한 이름으로 다시 생성하여 기존 볼륨을 재사용합니다. 이 경우 어드미션 컨트롤러에 문제가 생깁니다.

고루틴이 보낸 퇴거 요청은 다음과 같습니다. kubectl 에는 파드의 이름과 네임스페이스만 포함된다. 이러한 제한된 컨텍스트 때문에, 어드미션 컨트롤러는 스케줄 재조정 어노테이션이 없는 파드를 이동해야 한다고 가정할 수 없으며, 단순히 이미 스케줄이 재조정된 파드의 새로 생성된 인스턴스일 수 있습니다.

이를 처리하기 위해 어드미션 컨트롤러는 파드가 동일한 이름으로 스케줄이 변경될 때 사용되는 경량 추적 메커니즘을 유지한다. 일정 변경을 위해 파드에 어노테이션이 추가되면, 추적 리소스라는 이름의 다른 리소스에도 어노테이션이 추가된다. reschedule.hook/. 키.

스케줄 재조정 어노테이션이 없는 파드에 대한 후속 퇴거 요청을 가로채면, 추적 리소스에 이 어노테이션이 있으면 해당 파드가 이미 스케줄이 재조정되었음을 나타냅니다. 이 경우, 웹훅은 해당 파드의 추적 어노테이션을 정리한 다음 404 찾을 수 없음 응답을 호출하여 고루틴을 종료합니다.

추적 리소스 유형은 기본적으로 카우치베이스클러스터웹훅은 또한 파드의 네임스페이스. 동일한 이름으로 파드를 다시 예약하지 않을 경우 이 기능을 비활성화할 수 있습니다.

퇴거 일정 변경 훅 실행

퇴거 일정 변경 훅과 그 지원 구성 요소를 배포하는 방법은 간단합니다. 퇴거 일정 변경을 위한 README 는 이미지 빌드 및 전체 스택 배포에 대한 자세한 지침을 제공합니다.

일정 변경 훅을 구성하는 주요 구성 요소는 다음과 같습니다:

웹훅 구성 유효성 검사: 쿠버네티스 API 서버에 포워딩을 지시한다. 만들기 요청에 대한 포드/퇴거 웹훅 서비스에 대한 하위 리소스

서비스: 들어오는 웹훅 요청을 입장 컨트롤러 포드로 라우팅합니다.

입장 컨트롤러: 일반적으로 쿠버네티스 배포로 배포되는 컨테이너 내에서 스케줄 재조정 훅을 실행합니다.

서비스 계정, 클러스터 역할 및 클러스터 역할 바인딩: 이를 통해 입학 관리자에게 필요한 권한을 부여합니다. 최소한, get 그리고 패치 파드에 대한 권한이 필요합니다. 추적 리소스를 사용하는 경우, get 그리고 패치 추적 리소스에 대한 권한도 추가해야 합니다.

일단 배포되면, Couchbase 파드가 상주하는 노드를 배수하면 운영자가 안전하게 파드를 클러스터에 다시 생성하고 균형을 맞출 때까지 리스케줄 훅이 퇴거 요청을 가로채고 거부하는 방법을 보여줍니다:

퇴거 요청을 정상적으로 처리하는 것은 카우치베이스 관리자 UI에서도 확인할 수 있습니다. 파드는 더 이상 페일오버되지 않고 대신 다운타임 없이 대체됩니다:

사용해 보고 참여하세요

퇴거 리스케줄 훅은 쿠버네티스에서 실행되는 상태 저장 애플리케이션에서 노드 드레인을 보다 안전하고 예측 가능하게 만든다. 오퍼레이터와 함께 퇴거 처리를 조정함으로써, 기본 애플리케이션을 중단하지 않고 우아하게 일정을 재조정할 수 있습니다.

이 프로젝트는 오픈 소스입니다. 프로젝트의 저장소 에서 시작하여 시작하고 기여 가이드를 참조하세요. 피드백, 이슈, 풀 리퀘스트 모두 환영합니다!