Kubernetes v1.35: Kubelet 구성 드롭인 디렉터리가 GA로 전환되었습니다.

최근 Kubernetes v1.35 릴리스와 함께 Kubelet 구성 드롭인 디렉터리 지원이 정식 버전(GA)으로 제공됩니다. 이 새롭게 안정화된 기능은 규모가 크고 이기종적인 클러스터 전반에 걸쳐 Kubelet 구성 관리를 단순화합니다.

v1.35부터 Kubelet 명령줄 인자 --config-dir는 프로덕션 환경에서 사용할 준비가 되었으며 완전히 지원되어 Kubelet 구성 드롭인 파일을 포함하는 디렉터리를 지정할 수 있습니다. 해당 디렉터리 내의 모든 파일은 기본 Kubelet 구성과 자동으로 병합됩니다. 이를 통해 클러스터 관리자는 복잡한 도구나 수동 구성 관리 없이도 Kubelet에 대한 일관된 기본 구성을 유지하면서 다양한 노드 그룹 또는 사용 사례에 대한 맞춤형 사용자 지정을 가능하게 합니다.

문제: 대규모 Kubelet 구성 관리

Kubernetes 클러스터가 커지고 복잡해짐에 따라, 종종 서로 다른 하드웨어 기능, 워크로드 요구 사항 및 운영 제약을 가진 이기종 노드 풀을 포함하게 됩니다. 이러한 다양성으로 인해 노드 그룹마다 다른 Kubelet 구성이 필요하지만, 대규모로 이러한 다양한 구성을 관리하는 것은 점점 더 어려워집니다. 몇 가지 문제점이 발생합니다:

구성 편차(Configuration drift): 노드마다 약간 다른 구성이 적용되어 일관성 없는 동작을 초래할 수 있습니다.
노드 그룹 맞춤 설정: GPU 노드, 엣지 노드 및 표준 컴퓨트 노드에는 종종 다른 Kubelet 설정이 필요합니다.
운영 오버헤드: 각 노드 유형에 대해 별도의 완전한 구성 파일을 유지하는 것은 오류가 발생하기 쉽고 감사하기 어렵습니다.
변경 관리: 이기종 노드 풀 전체에 구성 변경 사항을 배포하려면 신중한 조정이 필요합니다.

이 지원이 Kubernetes에 추가되기 전에는 클러스터 관리자가 모든 노드에 단일 모놀리식 구성 파일을 사용하거나, 여러 개의 완전한 구성 파일을 수동으로 유지하거나, 별도의 도구에 의존하는 것 중 하나를 선택해야 했습니다. 각 접근 방식에는 자체적인 단점이 있었습니다. 이번 안정화 버전으로의 전환은 클러스터 관리자에게 이러한 문제를 해결할 수 있는 완전히 지원되는 네 번째 방법을 제공합니다.

사용 사례 예시

이기종 노드 풀 관리

여러 노드 유형(표준 컴퓨트 노드, 고용량 노드(예: GPU 또는 대용량 메모리 포함), 특수 요구 사항을 가진 엣지 노드)으로 구성된 클러스터를 생각해 봅시다.

기본 구성

파일: 00-base.conf

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
 - "10.96.0.10"
clusterDomain: cluster.local

고용량 노드 재정의

파일: 50-high-capacity-nodes.conf

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
maxPods: 50
systemReserved:
 memory: "4Gi"
 cpu: "1000m"

엣지 노드 재정의

파일: 50-edge-nodes.conf (엣지 컴퓨트는 일반적으로 용량이 더 낮습니다)

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
 memory.available: "500Mi"
 nodefs.available: "5%"

이 구조를 사용하면 고용량 노드는 기본 구성과 용량별 재정의를 모두 적용하고, 엣지 노드는 엣지별 설정과 함께 기본 구성을 적용합니다.

점진적 구성 롤아웃

구성 변경 사항을 롤아웃할 때 다음을 수행할 수 있습니다:

높은 숫자 접두사가 붙은 새 드롭인 파일 추가 (예: 99-new-feature.conf)
노드 하위 집합에서 변경 사항 테스트
점진적으로 더 많은 노드로 롤아웃
안정화되면 변경 사항을 기본 구성에 병합

병합된 구성 보기

이제 구성이 여러 파일에 분산되어 있으므로 Kubelet의 /configz 엔드포인트를 사용하여 최종 병합된 구성을 검사할 수 있습니다:

# Start kubectl proxy
kubectl proxy

# In another terminal, fetch the merged configuration
# Change the '<node-name>' placeholder before running the curl command
curl -X GET http://127.0.0.1:8001/api/v1/nodes/<node-name>/proxy/configz | jq .

이는 모든 병합이 적용된 후 Kubelet이 실제로 사용하고 있는 구성을 보여줍니다. 병합된 구성에는 Kubelet 명령줄 인자를 통해 지정된 모든 구성 설정도 포함됩니다.

자세한 설정 지침, 구성 예시 및 병합 동작에 대해서는 공식 문서를 참조하십시오:

모범 사례

Kubelet 구성 드롭인 디렉터리를 사용할 때:

구성을 점진적으로 테스트: 위험을 최소화하기 위해 새로운 드롭인 구성을 클러스터 전체에 롤아웃하기 전에 항상 노드 하위 집합에서 테스트하십시오.
드롭인을 버전 관리: 변경 사항을 추적하고 손쉬운 롤백을 위해 인프라 코스와 함께 드롭인 구성 파일을 버전 관리 시스템(또는 이러한 파일이 생성되는 구성 소스)에 저장하십시오.
예측 가능한 순서를 위해 숫자 접두사 사용: 병합 순서를 명확하게 제어하고 다른 관리자에게 구성 계층을 명확하게 하기 위해 파일 이름을 숫자 접두사(예: 00-, 50-, 90-)로 지정하십시오.
임시 파일에 유의: 일부 텍스트 편집기는 편집 시 동일한 디렉터리에 백업 파일(예: .bak, .swp 또는 ~ 접미사가 있는 파일)을 자동으로 생성합니다. Kubelet에 의해 처리될 수 있으므로 이러한 임시 또는 백업 파일이 구성 디렉터리에 남아 있지 않도록 하십시오.

감사의 말씀

이 기능은 SIG Node의 협력적인 노력으로 개발되었습니다. v1.28의 알파 단계부터 v1.30의 베타 단계를 거쳐 v1.35의 GA에 이르기까지 이 기능의 설계, 구현, 테스트 및 문서화에 도움을 주신 모든 기여자분들께 특별한 감사를 드립니다.

이 기능에 대한 피드백을 제공하려면 Kubernetes Node 특별 관심 그룹에 참여하거나, 공개 Slack 채널(#sig-node)에서 토론에 참여하거나, GitHub에 이슈를 제출하십시오.

참여하기

Kubelet 구성 관리에 대한 피드백이나 질문이 있거나 이 기능을 사용한 경험을 공유하고 싶다면 다음 토론에 참여하십시오:

SIG Node는 프로덕션 환경에서 이 기능을 사용한 여러분의 경험을 듣고 싶어 합니다!