[Kubernetes] "자 이제 누가 진짜 리더지?" - 리더 선출 메커니즘

 

해당 글은 틀린 부분이 있을 수 있습니다. 마음껏 지적해주세요!

 

쿠버네티스 위에 있는 모든 파드와 노드는 ephermeral 하게 디자인 되었습니다.

 

그에 따라 파드와 노드는 언제 갑자기 급사? 할지 모릅니다. 하지만 급사 한다고 해서 서비스에 영향이 가선 안됩니다.

 

그렇기 때문에 쿠버네티스를 구성할 때 고가용성(HA) 은 반드시 동반되어야 합니다.

 

고가용성을 유지하지 위해서는 여러 절차가 동반되어야 하는데, 이번 글에서는 그 중 Stateful 한 서비스의 고가용성을 유지하는 방법 중 하나인 '리더 선출 메커니즘(Leader Election Mechanism)' 에 대해 알아보려고 합니다.

 

그 전에 Stateless 한 서비스의 고가용성부터 알아봅시다.

 

Stateless 한 파드가 여러 개 있고, Service 를 통해 트래픽이 라우팅 됩니다.

Stateless

 

Stateless 특성상 아무 파드나 트래픽을 받아도 전혀 문제가 없습니다.

 

그러다 혹시 리소스가 부족해지더라도 HPA 를 통해서 스케일 아웃 해주면 됩니다.

Stateless + HPA

 

이렇게해주어도 꽤나 괜찮은 고가용성을 유지할 수 있습니다.

 

Stateless 은 크게 신경쓸 것이 없습니다.

 

하지만 서비스가 Stateful 하게 되면 얘기가 살짝 달라집니다.

 

예를 들어 트래픽을 받는 서비스가 아닌, Karpenter 와 같이 Control Loop 을 진행하는 Stateful 서비스로 가정해보겠습니다.

Stateful

 

Karpenter 같은 경우 Ec2NodeClass 와 같은 CRD 를 Control Loop 을 통해 지켜보다가 특이 사항이 생기면 AWS EC2 를 생성하게 되는데, Karpenter 파드가 3개라고 하면 똑같은 AWS EC2 가 3개가 될 것입니다. 3개의 파드 모두 각자의 일을 할테니까요.

Karpenter 코드는 까보지 않았지만, 이를 방지하고자 하는 코드가 있을 수도 있습니다. (리더 선출 메커니즘을 제외한)
단순히 예제를 위한 것입니다.

 

이때 리더 선출 메커니즘을 사용한다면, 리더 파드만 작업을 하게 되어 AWS EC2 가 동시에 3개를 생성하는 중복을 막을 수 있습니다.

(더 높은 고가용성을 위해서라면 VPA 와 같은 스케일 업이 필요할 수 있습니다)

Stateful

 

추가적으로 Karpenter 를 Deployment 가 아닌 StatefulSet 로 생성해도 해결 방법은 아닙니다.

StatefulSet 는 네트워크, 스토리지 같은 식별자를 두어, 트래픽에 대한 Stateful 은 유지할 수 있겠지만, 결국 StatefulSet 의 파드가 3개라면 Deployment 처럼 중복된 작업을 수행하게 될 것입니다. 프로세스 자체를 제어할 순 없으니깐요.

 

 

그럼 리더 선출 메커니즘이 뭐고, 왜 필요한지 간략하게 알아봤으니, 코드로 이를 어떻게 구현할 수 있는 지 바로 알아보도록 하죠!

 

렛츠두더코드~

 

 

Code - Go Client

---

응답값으로 현재의 파드 이름과 IP 를 리턴해주는 gin 기반의 애플리케이션을 만들었고, 여기에 리더 선출 메커니즘을 적용할 것입니다.

응답 예시

 

그리고 애플리케이션은 미니 PC 로 운영하는 쿠버네티스에 배포합니다.

미니 PC 로 운영하는 쿠버네티스가 궁금하다면 여기 클릭!

 

리더 선출 메커니즘을 알아보면서 가장 궁금했던 것이, "누가 리더인지 애플리케이션에서 어떻게 알지?" 였습니다.

왜냐 만든 애플리케이션은 데이터베이스 같은 스토리지가 없기 때문이였습니다.

 

최소한 누가 리더인지는 알아야 리더를 뽑을 테니 말이죠.

 

다행히 쿠버네티스는 이를 Lease 라는 리소스를 이용해서 해결하였습니다. 그리고 Lease 는 ETCD 로 관리되겠죠.

apiVersion: coordination.k8s.io/v1

 

이 말은 즉 애플리케이션이 쿠버네티스 API 에 접근할 수 있어야 한다는 말이기도 합니다.

 

그래서 아래와 같은 코드를 먼저 작성해주었습니다.

config, err := buildConfig(kubeconfig)
if err != nil {
    klog.Fatal(err)
}
client := clientset.NewForConfigOrDie(config)

 

buildConfig 함수는 아래와 같습니다. 로컬에서 실행하면 커맨드 인자로 넘겨주고, 쿠버네티스 상에서 실행된다면 rest.InClusterConfig() 를 통해 Service Account Token 을 찾아줍니다.

func buildConfig(kubeconfig string) (*rest.Config, error) {
    if kubeconfig != "" {
        cfg, err := clientcmd.BuildConfigFromFlags("", kubeconfig)
        if err != nil {
            return nil, err
        }
        return cfg, nil
    }

    cfg, err := rest.InClusterConfig()
    if err != nil {
        return nil, err
    }
    return cfg, nil
}

 

다음은 리더 선출 메커니즘의 실행 함수입니다.

엔드포인트 "/" 를 통해 파드를 구분할 수 있는 응답값을 받게 됩니다.

run := func(ctx context.Context) {
    // complete your controller loop here
    klog.Info("Controller loop...")

    engine := gin.New()
    engine.Use(
        CorsHandler(),
    )

    engine.GET("/", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "pod_namespace": os.Getenv("POD_NAMESPACE"),
            "pod_name":      os.Getenv("POD_NAME"),
            "pod_id":        os.Getenv("POD_IP"),
            "id":            id,
        })
    })
    engine.Run(fmt.Sprintf("%s:%d", "0.0.0.0", 8080))
}

당연하게도 engine.Run 과 같이 foreground 로 지속적으로 프로세스를 실행시켜주어야 합니다.

 

바로 위에서 리더 선출 메커니즘은 Lease 라는 리소스를 통해 진행된다고 했는데, 이 역시 Lease 를 생성하는 코드를 작성해줍니다.

var leaseLockName = os.Getenv("LEASE_LOCK_NAME")
var leaseLockNamespace = os.Getenv("LEASE_LOCK_NAMESPACE")
var id = uuid.New().String()

lock := &resourcelock.LeaseLock{
    LeaseMeta: metav1.ObjectMeta{
        Name:      leaseLockName,
        Namespace: leaseLockNamespace,
    },
    Client: client.CoordinationV1(),
    LockConfig: resourcelock.ResourceLockConfig{
        Identity: id,
    },
}

 

leaseLockName 과 leaseLockNamespace 는 Configmap 을 이용해서 환경변수로 넘겨줄 것이고, Identity 는 uuid 를 넘겨줍니다.

 

이제부터가 리더 선출 메커니즘의 핵심 코드입니다.

leaderelection.RunOrDie(ctx, leaderelection.LeaderElectionConfig{
    Lock: lock,
    ReleaseOnCancel: true,             // true로 설정하면, 프로세스가 종료되거나 컨텍스트가 취소될 때 리스를 즉시 해제
    LeaseDuration:   60 * time.Second, // RenewDeadline 동안 갱신에 실패했을 때, 리더십이 유지될 수 있는 시간
    RenewDeadline:   15 * time.Second, // 리더는 이 기간 동안 리더십을 갱신해야함
    RetryPeriod:     5 * time.Second,  // 리더 획득 시도 간의 대기 시간을 설정
    Callbacks: leaderelection.LeaderCallbacks{
        OnStartedLeading: func(ctx context.Context) {
            run(ctx)
        },
        OnStoppedLeading: func() {
            klog.Infof("leader lost: %s", id)
            os.Exit(0)
        },
        OnNewLeader: func(identity string) {
            if identity == id {
                return
            }
            klog.Infof("new leader elected: %s", identity)
        },
    },
})

 

위에서 생성했던 run 함수도 leaderelection.RunOrDie 의 콜백함수로 실행되게 됩니다.

 

OnStartedLeading 함수는 리더가 되었을 때 한번 실행되는 함수고, OnStoppedLeading 은 리더를 상실했을 때 한번 실행되는 함수고, OnNewLeader 는 새로운 리더가 선출되었을 때 리더가 아닌 서비스에서 실행되는 함수입니다.

 

생각보다 어려운 부분은 없는것 같습니다. 그럼 좀 더 디테일한 이해를 위해 Deep Dive 를 진행해보겠습니다.

만약 동작 방식만 보고싶다면, 다음 Deep Dive 파트는 건너뛰어도 무방합니다.

 

 

Code - Deep Dive

---

다음은 kube-controller-manager 의 코드인데 관리하는 리소스를 보면 Lease 는 없습니다. 즉, kube-controller-manager 가 Lease 의 Yaml 을 바라보면서 Reconcile 할 것이 없다는 것입니다.

controllermanager.go

 

이 말은 또 리더 선출 메커니즘은 애플리케이션과 Lease 리소스만으로도 충분히 실행될 수 있는 것을 의미합니다.

 

한편, 리더 선출 메커니즘은 leaderelection.RunOrDie 함수를 시작으로 실행됩니다.

leaderelection.go

 

Run 함수를 보게되면 아까 콜백에 작성했던 OnStoppedLeading defer 함수와 OnStartedLeading 고루틴을 실행하는 걸 볼 수 있고, le.renew(ctx) 를 실행하게 됩니다.

 

leaderelection.go

 

renew 함수를 보게 되면, 좀 더 핵심적인 코드를 볼 수 있는데 크게 tryAcquireOrRenew 와 tryCoordinatedRenew 입니다. 그리고 이 함수들은 모두 wait.Until 함수 내에서 동작하게 됩니다.

wait.Until 은 지난 [Kubernetes] Controller 와 Operator, 어디까지 까봤니? 에서 다룬적이 있죠.

 

tryAcquireOrRenew 부터 살펴보겠습니다.

leaderelection.go

 

현재 프로세스가 리더이고, Lease 가 유효하다면, 이전 Lease 의 AcquireTime, LeaderTransitions 를 가져와서 업데이트를 해줍니다. 결국 이전 Lease 와 비교했을 때 RenewTime 만 업데이트 되겠죠.

 

문제가 없다면 true 를 리턴해줌으로써 갱신에 성공하게 됩니다.

 

첫번째 로직에서 끝나지 않았다면, 다음 두번째 로직으로 가게 됩니다.

leaderelection.go

 

btye 로 구성된 이전 Lease 에 대한 정보와 구조체로 이루어진 Lease 정보를 갖고 오게 됩니다. 이 과정에서 에러가 발생하면 바로 아래 if 문을 타게 되는데, 여기서 문제가 있으면 갱신에 실패하고, 리더를 잃게 될 것입니다.

 

두번째 로직에서 끝나지 않았다면, 다음 세번째 로직으로 가게 됩니다.

leaderelection.go

 

이전 Lease 의 HolderIdentity 가 존재하고, 유효하지만 리더가 아니라면 갱신을 할 수 없다는 로직입니다.

 

세번째 로직에서 끝나지 않았다면, 마지막 네번째 로직으로 가게 됩니다.

leaderelection.go

 

현재 프로세스가 리더라면 첫번째 로직과 비슷하게 RenewTime 만 업데이트 될 것입니다.

다만 차이가 있다면 첫번째 로직은 FastPath 이고, 네번째 로직은 SlowPath 라는 것입니다.

글이 너무 길어져서 굳이 FastPath 와 SlowPath 는 다루지 않겠습니다.

 

모든 로직이 끝나고도, 로직이 계속 돈다면 최종적으로 갱신할 수 있도록 true 를 리턴해줍니다.

 

다음은 tryCoordinatedRenew 함수입니다.

 

tryAcquireOrRenew 와 달리 새로운 리더를 얻기 위한 함수라기 보다는 이름에서도 알 수 있듯이 리더 조율을 위한 함수로 이해하면 쉽습니다.

leaderelection.go

 

코드도 서로 굉장히 비슷한데 큰 차이라고 하면 tryCoordinatedRenew 은 최종 true 를 리턴해주는 거 빼고, 전부 false 만 리턴해주는 것이죠. 특이 사항이 생기게 되면 갱신을 해주지 않아 리더를 박탈시켜 버립니다.

 

결과적으로 현재 리더인 프로세스가 주어진 시간에 갱신을 하지 못하게 되면, 리더 자격을 잃게 되고 다른 프로세스가 리더를 차지하게 됩니다.

 

쿠버네티스에서의 동작 방식

---

지금까지 코드를 살펴봤으니, 이번엔 해당 코드로 작성된 애플리케이션이 쿠버네티스 위에선 어떻게 동작하는지 살펴보겠습니다.

yamls

 

먼저 Lease 리소스부터 살펴봅니다.

Lease

 

현재 리더의 id 는 ae4cf8ca-f345-481c-b4dc-67995c009951(uuid 로 생성했던) 인 것을 확인할 수 있습니다.

그리고 최대 60초 내로 리더 파드는 자신이 리더로서 문제가 없다는 것을 증명해주어야 합니다.

 

증명하지 못하면 다른 파드가 리더가 되겠죠.

 

다음은 배포된 파드들의 로그를 살펴보겠습니다. 총 3개의 파드가 배포되었고, 그 중 하나만 리더로 선출된 것을 확인할 수 있습니다.

I'm Leader

 

그리고 애플리케이션으로 요청을 보내게 되면, 리더 파드의 정보만 응답 받는 걸 확인할 수 있습니다.

id 또한 Lease 리소스의 holderIdentity 와 일치합니다.

Only Leader

 

이번엔 한번 리더 파드를 죽여보겠습니다.

 

기존의 리더 파드가 죽었다는 걸 확인할 수 있고, 그에 따라 새로운 파드가 리더가 되었습니다.

New Leader

 

Lease 리소스를 확인해보면 holderIdentity 가 바뀐 것을 확인할 수 있고, leaseTransitions 도 리더가 바뀜에 따라 카운트가 증가했습니다.

Lease

 

추가로 리더가 된 파드를 계속해서 죽였을 때 RetryPeriod(이 옵션은 코드 레벨에 있음) 이후에 새로운 파드가 리더가 되서 정상적으로 응답을 받는 걸 확인할 수 있습니다.

Leaders

 

대표적인 리더 선출 메커니즘을 사용하는 프로젝트들

---

그럼 리더 선출 메커니즘을 사용하는 대표적인 프로젝트들은 무엇이 있을까요?

리더 선출 메커니즘을 사용하는 프로젝트들

 

Karpenter, Cert Manager, ArgoCD, AWS LB Controller, Kubernetes Components 등 엄청나게 다양한 프로젝트나 애플리케이션이 리더 선출 메커니즘을 사용하고 있는 것을 확인할 수 있습니다.

 

그러면 오늘은 여기까지!