노드 풀 Taint와 unmanaged Pod에 대한 고려사항
노드 풀 Taint와 unmanaged Pod에 대한 고려사항
Cilium이 실행되기 전에 Pod가 노드에서 시작되는 것을 막기 위해 Kubernetes taint를 활용하는 메커니즘과 고려사항을 정리했어요.
본문
환경이나 클라우드 제공자에 따라, Cilium이 설치되거나 이미 실행 중인 특정 클러스터에 속한 노드에 CNI 플러그인 및/또는 구성 파일이 미리 설치되어 있을 수 있어요. 특정 노드에서 시작할 때, 그리고 클러스터의 전용 CNI 플러그인으로 의도될 때 Cilium은 노드에서 CNI 소유권을 최대한 가져오려고 해요. 하지만 몇 가지 상황이 이를 막을 수 있어요.
- Cilium은 시작한 후에만 노드에서 CNI 소유권을 가질 수 있어요. 특정 노드에서 Cilium이 실행되기 전에 시작된 Pod는 미리 구성된 CNI에서 IP를 받을 수 있어요.
- 일부 클라우드 제공자는 노드 재부팅, 업데이트 또는 일상 유지보수 같은 작업 중에 Cilium이 CNI 구성에 만든 변경을 되돌릴 수 있어요.
특히 GKE(non-Dataplane V2)의 경우가 그런데, 노드 재부팅과 업그레이드가 Cilium이 만든 변경을 되돌리고 기본 CNI 구성을 복원해요.
Cilium이 단일 CNI로 지원되지 않는 환경과 클라우드 제공자에서 이 상황을 최대한 극복하기 위해, Cilium은 Kubernetes의 taints를 조작해 해당 노드에서 Cilium이 실행되기 전에 Pod가 시작되는 것을 막을 수 있어요. 작동 메커니즘은 다음과 같아요.
- 클러스터 관리자가 특정 초기화되지 않은 노드에 특정 taint(아래 참고)를 배치해요. taint의 효과(effect, 아래 참고)에 따라, 일치하는 toleration이 없는 Pod는 taint가 제거될 때까지 노드에 스케줄되거나 실행되지 않아요.
- Cilium이 노드에서 실행되어 초기화하고, 준비되면 앞서 언급한 taint를 제거해요.
- 이 시점부터 Pod가 노드에 스케줄되고 실행되며, 네트워킹은 Cilium이 관리해요.
- Cilium이 노드에서 일시적으로 제거되면 Operator가 taint를 다시 적용해요(단, NoSchedule로만).
기본적으로 taint 키는 node.cilium.io/agent-not-ready지만, 일부 시나리오(예: Cluster Autoscaler를 사용하지만 그 플래그를 구성할 수 없는 경우)에서는 이 키를 조정해야 할 수 있어요. 이는 agent-not-ready-taint-key 옵션으로 할 수 있어요. 앞서 언급한 예시에서는 사용자가 ignore-taint.cluster-autoscaler.kubernetes.io/로 시작하는 키를 지정해야 해요. 이런 값을 사용하면 Cluster Autoscaler가 스케줄링을 시뮬레이션할 때 이를 무시해서 클러스터가 스케일업할 수 있어요.
taint의 효과(effect)는 다음 고려사항을 참고해 선택해야 해요.
NoSchedule을 사용하면 Cilium이 taint를 제거할 기회를 갖기 전까지 Pod는 노드에 스케줄되지 않아요. 하지만 실제 효과 중 하나는, 외부 프로세스(예: 재부팅)가 해당 노드의 CNI 구성을 리셋하면 이미 스케줄된 Pod가 다음 노드 재부팅 때 Cilium과 동시에 시작되어 unmanaged가 되어 다른 CNI 플러그인이 네트워킹을 관리하게 될 수 있다는 거예요.NoExecute를 사용하면 Cilium이 taint를 제거할 기회를 갖기 전까지 Pod는 노드에서 실행(및 스케줄)되지 않아요. 실제 효과 중 하나는, 외부 프로세스(예: 업그레이드 중 또는 일상적인 작업)가 taint를 노드에 다시 추가할 때마다 Cilium이 taint를 제거할 기회를 가질 때까지 Pod가 노드에서 축출(evict)된다는 거예요.
또 다른 중요한 고려사항은 노드 자체의 개념과 노드에 대한 서로 다른 관점이에요. 예를 들어 Kubernetes 노드를 뒷받침하는 인스턴스/VM은 클라우드 제공자가 파일시스템 측면에서 패치하거나 리셋하거나, 기존 Kubernetes Node 리소스와 같은 이름으로 돌아오는 완전히 새로운 인스턴스/VM으로 교체될 수 있어요. 이런 시나리오에서도 노드-풀 수준 taint가 Node 리소스에 다시 추가되지만, 이 이름의 노드에 이미 스케줄된 개는 Cilium과 동시에 노드에서 실행되어 잠재적으로 unmanaged가 될 수 있어요. 이것이 NoExecute가 권장되는 이유예요. 이 시나리오에서 taint가 다시 추가된다고 가정하면 이미 스케줄된 Pod가 실행되지 않기 때문이에요.
하지만 일부 환경이나 클라우드 제공자에서는, 앞서 언급한 대로 노드 업그레이드/리셋이 아닌 다른 이유로 노드-풀 수준에서 설정된 taint가 Cilium이 제거한 후 노드에 다시 추가될 수 있어요. 정확한 상황은 다양할 수 있지만, taint 효과로 NoExecute를 사용하는 특정 경우에 원치 않는/예상치 못한 Pod 축출이 발생할 수 있어요. 따라서 각 배포에서 환경이나 클라우드 제공자에 따라 taint 효과(또는 taint 기반 접근을 아예 사용할지 여부)를 위 정보, 환경/클라우드 제공자 문서, 그리고 본질적으로 클러스터에 unmanaged pod가 생기는 것(트래픽 드롭과 기타 문제로 이어질 수 있음)과 예상치 못한/원치 않는 축출(애플리케이션 다운타임으로 이어질 수 있음) 사이의 트레이드오프를 설정한다는 사실을 바탕으로 신중하게 결정하는 것이 권장돼요.
이 모든 것을 고려해, Cilium 문서 전반에서 우리는 사용자가 클라우드 제공자에 Cilium을 배포하는 데 사용할 수 있는 가장 덜 방해적인 모드라고 믿어 NoExecute 사용을 권장해요.