Kubernetes v1.35: Kubelet 구성 Drop-in 디렉터리 GA로 승격

Source: Kubernetes Blog

위에 제공된 소스 링크 외에 번역할 텍스트가 없습니다. 번역이 필요한 본문을 제공해 주시면 한국어로 번역해 드리겠습니다.

새로운 기능?

• --config-dir 플래그가 이제 완전히 지원됩니다.
• kubelet을 여러 구성 파일이 포함된 디렉터리로 지정할 수 있습니다.
• 해당 디렉터리의 모든 파일이 메인 kubelet 구성과 자동으로 병합됩니다.

Drop‑In 디렉터리를 사용하는 이유?

• 중앙 집중식 기본 구성 – 모든 kubelet에 대한 공통 설정 집합을 유지합니다.
• 대상 맞춤 설정 – 기본 파일을 건드리지 않고 노드 그룹별 맞춤 조정을 추가합니다.
• 간소화된 관리 – 노드당 복잡한 도구나 수동 편집이 필요 없습니다.

사용 방법

# Example kubelet systemd unit (or static pod) snippet
ExecStart=/usr/local/bin/kubelet \
  --config=/etc/kubernetes/kubelet-config.yaml \
  --config-dir=/etc/kubernetes/kubelet-config.d

• --config는 주요 구성 파일(기본 파일)을 가리킵니다.
• --config-dir는 추가 YAML 파일이 들어 있는 디렉터리(예: /etc/kubernetes/kubelet-config.d)를 가리킵니다.

모범 사례

예시 디렉터리 레이아웃

/etc/kubernetes/kubelet-config.d/
├── 01-base.yaml          # Common settings for all nodes
├── 10-gpu-nodes.yaml     # GPU‑specific flags (only applied to GPU nodes)
└── 20-custom-metrics.yaml# Extra metrics exporters

kubelet이 시작될 때, 파일들을 사전식 순서(01‑base.yaml → 10‑gpu-nodes.yaml → 20‑custom-metrics.yaml)로 병합하고, 그 결과 구성(configuration)을 적용합니다.

문제: 대규모 Kubelet 구성 관리

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

주요 문제점

• 구성 드리프트 – 노드 간 약간의 차이로 인해 동작이 일관되지 않음.
• 노드‑그룹 맞춤화 – GPU 노드, 엣지 노드, 표준 컴퓨트 노드 각각에 고유한 kubelet 설정이 필요.
• 운영 오버헤드 – 모든 노드 유형에 대해 별도의 완전한 구성 파일을 유지하는 것은 오류 발생 가능성이 높고 감사가 어려움.
• 변경 관리 – 이질적인 풀 전반에 구성 업데이트를 배포하려면 신중한 조정이 필요.

이전 접근 방식

Kubernetes에 네이티브 지원이 추가되기 전에는 관리자가 다음 중 하나를 선택해야 했으며, 각각 단점이 있었습니다:

1. 모든 노드에 대한 단일 거대한 구성 – 노드별 요구사항을 수용할 수 없음.
2. 수동으로 유지 관리되는 다수의 전체 구성 – 드리프트 위험이 높고 감사가 어려움.
3. 외부 도구 또는 스크립트 – 복잡성을 추가하고 제어 플레인과의 통합이 부족함.

새로운 솔루션

kubelet 구성 지원이 stable 단계로 졸업함에 따라 클러스터 관리자는 네 번째, 완전 지원되는 방법을 통해 이질적인 kubelet 설정을 신뢰성 있게 대규모로 관리할 수 있게 되었습니다.

예시 사용 사례

이기종 노드 풀 관리

여러 종류의 노드가 있는 클러스터를 고려하십시오:

• 표준 컴퓨트 노드
• 고용량 노드 (예: GPU 또는 대용량 메모리)
• 엣지 노드 (특수 요구 사항 포함)

기본 구성

File: 00-base.conf

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

고용량 노드 오버라이드

File: 50-high-capacity-nodes.conf

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

엣지 노드 오버라이드

File: 50-edge-nodes.conf – 엣지 컴퓨트는 일반적으로 용량이 낮음

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

결과:

• 고용량 노드는 기본 구성 플러스 고용량 오버라이드를 로드합니다.
• 엣지 노드는 기본 구성 플러스 엣지 전용 오버라이드를 로드합니다.

점진적인 구성 롤아웃

구성 변경을 롤아웃할 때는 다음 패턴을 따르세요:

1. 새 드롭인 파일을 높은 숫자 접두사와 함께 생성합니다 (예: 99-new-feature.conf).
2. 테스트를 작은 노드 집합에서 수행합니다.
3. 점진적으로 롤아웃을 추가 노드로 확장합니다.
4. 변경이 안정되면, 새 설정을 기본 구성에 병합합니다.

병합된 구성 보기

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

# kubectl proxy 시작
kubectl proxy

# 다른 터미널에서 병합된 구성 가져오기
# <node-name>을 노드 이름으로 바꾸세요
curl -X GET http://127.0.0.1:8001/api/v1/nodes/<node-name>/proxy/configz | jq .

출력에는 모든 병합이 적용된 후 kubelet이 실제로 사용하는 정확한 구성이 표시되며, 여기에는 kubelet 명령줄 인수를 통해 제공된 설정도 포함됩니다.

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

• Set Kubelet Parameters via a Configuration File
• Kubelet Configuration Directory Merging

Good Practices

When using the kubelet configuration drop‑in directory:

• Test configurations incrementally – Always test new drop‑in configurations on a subset of nodes before rolling them out cluster‑wide to minimize risk.
• Version‑control your drop‑ins – Store your drop‑in configuration files (or the source that generates them) in version control alongside your infrastructure‑as‑code. This lets you track changes and roll back easily.
• Use numeric prefixes for predictable ordering – Name files with numeric prefixes (e.g., 00-, 50-, 90-) to explicitly control merge order and make the configuration layering obvious to other administrators.
• Be mindful of temporary files – Some text editors automatically create backup files (such as .bak, .swp, or files with a ~ suffix) in the same directory when editing. Ensure these temporary or backup files are not left in the configuration directory, as they may be processed by the kubelet.

좋은 실천 방법

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

• 구성을 점진적으로 테스트 – 새로운 드롭‑인 구성을 클러스터 전체에 적용하기 전에 먼저 일부 노드에 적용해 테스트하여 위험을 최소화합니다.
• 드롭‑인 파일을 버전 관리 – 드롭‑인 구성 파일(또는 이를 생성하는 소스)을 인프라‑코드와 함께 버전 관리 시스템에 저장합니다. 이렇게 하면 변경 사항을 추적하고 쉽게 롤백할 수 있습니다.
• 예측 가능한 순서를 위해 숫자 접두사 사용 – 파일 이름에 숫자 접두사(00-, 50-, 90- 등)를 붙여 병합 순서를 명시적으로 제어하고, 다른 관리자들이 구성 레이어링을 쉽게 이해하도록 합니다.
• 임시 파일에 주의 – 일부 텍스트 편집기는 편집 시 같은 디렉터리에 백업 파일(.bak, .swp 또는 ~ 접미사가 붙은 파일 등)을 자동으로 생성합니다. 이러한 임시 또는 백업 파일이 구성 디렉터리에 남아 있지 않도록 하세요. kubelet이 이를 처리할 수 있습니다.

감사의 글

이 기능은 SIG Node 의 협업을 통해 개발되었습니다. v1.28의 alpha 릴리스부터 v1.30의 beta, v1.35의 GA까지 설계, 구현, 테스트, 문서화를 도와준 모든 기여자들에게 특별히 감사드립니다.

피드백 및 토론

• **Kubernetes Node Special Interest Group**에 참여하세요.
• 공개 Slack 채널 **#sig-node**에 참여하세요.
• **GitHub**에 이슈를 등록하세요.

참여하기

If you have feedback or questions about kubelet configuration management, or want to share your experience using this feature, join the discussion:

• SIG Node 커뮤니티 페이지 – (link pending)
• Kubernetes Slack – #sig-node 채널에 참여하세요
• SIG Node 메일링 리스트 – (link pending)

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