topologySpreadConstraints - matchLabelKeys 옵션

Why

 

Kubernetes에서 파드를 동일한 노드에 배치하지 않기 위해 Anti-Affinity를 설정하는 경우가 많습니다. 하지만, 새로운 버전의 파드(예: 1.0.0 → 1.0.1) 배포 시 기존 노드에 실행하지 않고 새로운 노드에 배치되는 경우가 발생합니다. 이는 동일한 Deployment라 레이블이 같기 때문입니다.

 

기존 파드와 새로운 파드는 서로 다른 버전이라 같은 노드에 실행해도 문제없지만, 같은 레이블을 사용하기 때문에 서로 다른 노드에 배치됩니다. 이는 일반적인 상황에서는 문제가 없지만, Karpenter 환경에서는 새로운 노드가 생성되면서 기존 노드에 실행 중이던 파드들이 새로운 노드로 불필요하게 이동하는 문제가 발생합니다. (Karpenter의 consolidation 기능으로 인한 파드 재배치)

 

미드저니

 

특정 파드 재배포 시 기존의 파드까지 불필요하게 재시작되는 문제가 발생할 수 있습니다.

 

What

 

Kubernetes 1.27부터 topologySpreadConstraints에 matchLabelKeys 옵션이 도입되었습니다. 이 옵션을 사용하면 새로운 버전의 파드를 기존 노드에 배치할 수 있어, 불필요하게 기존 파드가 재시작되는 현상을 방지할 수 있습니다. 

 

Kubernetes 1.31 버전부터는 affinity 설정에서도 동일한 matchLabelKeys 옵션을 지원합니다.

 

Two Key - 미드저니

 

topologySpreadConstraints:         - maxSkew: 1           topologyKey: kubernetes.io/hostname           whenUnsatisfiable: DoNotSchedule           labelSelector:             matchLabels:               app: foo           matchLabelKeys:             - pod-template-hash

How

 

위 설정에서 matchLabelKeys에 pod-template-hash를 지정합니다. pod-template-hash는 파드의 각 Deployment 버전에 따라 고유한 해시값이 생성됩니다. 이를 통해 서로 다른 버전의 파드를 같은 노드에 배치할 수 있습니다.

 

다음은 pod-template-hash 값이 파드에 어떻게 적용되는지 확인하는 예시입니다:

 

확인 방법

 

(baas-dev-01:default)~$ kubectl get pod netshoot-78bb977dcf-m5td2 -oyaml (생략) metadata:   labels:     app: netshoot     pod-template-hash: 78bb977dcf

 

같은 버전의 Deployment는 동일한 해시값을 가지지만, 새로운 버전으로 배포된 Deployment는 다른 해시값을 가집니다. 이 Hash 값은 자동으로 설정됩니다. 따라서 matchLabelKeys 옵션을 사용하면 Hash 값이 다르므로 서로 다른 버전의 Deployment가 같은 노드에 실행됩니다.

 

실제 테스트를 하면 아래와 같이 Replicas 1이면 같은 노드에 실행되는 것을 확인할 수 있습니다.

 

(baas-dev-01:default)~$ kubectl get pods -o wide -w --selector app=echo NAME                    READY   STATUS    RESTARTS   AGE   IP             NODE                                            NOMINATED NODE   READINESS GATES echo-869d59f8f8-8knfl   1/1     Running   0          86s   10.62.75.149   ip-10-62-74-4.ap-northeast-2.compute.internal   <none>           <none> echo-76b9fbf5b7-zghbf   0/1     Pending   0          0s    <none>         ip-10-62-74-4.ap-northeast-2.compute.internal   <none>           <none> echo-76b9fbf5b7-zghbf   0/1     ContainerCreating   0          0s    <none>         ip-10-62-74-4.ap-northeast-2.compute.internal   <none>           <none> echo-76b9fbf5b7-zghbf   1/1     Running             0          1s    10.62.75.150   ip-10-62-74-4.ap-northeast-2.compute.internal   <none>           <none> echo-869d59f8f8-8knfl   1/1     Terminating         0          104s   10.62.75.149   ip-10-62-74-4.ap-northeast-2.compute.internal   <none>           <none>

 

하지만, Replicas 수량이 2일 때는 첫 번째 파드는 기존 노드에 배치되지만, 두 번째 파드는 새로운 노드에 배치되는 현상이 발견되었습니다. 이 부분에 대해서는 추가적인 조사가 필요합니다.

 

결론

 

matchLabelKeys 옵션을 활용하면 Karpenter 환경에서 불필요한 파드 재시작을 방지하고, 파드 배치를 더욱 최적화할 수 있습니다. Kubernetes의 지속적인 업데이트로 인해 파드 배치 정책을 세밀하게 조정할 수 있는 기능들이 늘어나고 있으니, 이를 적극 활용하여 효율적인 클러스터 운영을 해보시길 바랍니다.