Kubernetes 1.16 전환의 CoreDNS·메트릭·API 변경

kubeadm 클러스터 구성과 버전 업그레이드4 / 4

1.16 전환 때 남긴 CoreDNS 사전 검사 오류와 cAdvisor 레이블·API 변경을 당시 업그레이드 명령과 함께 정리합니다.

← 이전 글: kubeadm으로 Kubernetes 1.15.4까지 올린 작업 메모

Kubernetes 1.15에서 1.16으로 올릴 때는 패키지 버전 외에도 CoreDNS 설정과 모니터링 레이블, 사용하는 API를 확인해야 했습니다. 당시 업그레이드 명령과 후속 확인 메모를 한 글로 정리했습니다.

1.15에서 1.16으로의 변경은 마이너 버전 업그레이드입니다. 마이너 버전에서도 기존 설정에 영향을 주는 변경이 포함될 수 있었습니다.

패키지와 클러스터 업그레이드

당시 apt 환경에서 kubeadm을 1.16.0-00으로 맞추고 다음 순서로 계획과 적용을 진행했습니다.

bash


sudo kubeadm upgrade plan
sudo kubeadm upgrade apply v1.16.0

워커에서는 목표 버전의 kubeadm을 설치한 뒤 kubeadm upgrade node를 사용했습니다. kubelet·kubectl 패키지도 1.16.0-00으로 맞추고 kubelet을 다시 시작하는 절차였습니다.

패키지 작업의 형태는 1.15.4 업그레이드 메모와 비슷하지만, 아래 변경 사항은 버전에 맞춰 따로 확인해야 했습니다.

CoreDNS 사전 검사 오류

kubeadm upgrade plan에서 다음 오류를 확인했습니다.

text


[ERROR CoreDNSUnsupportedPlugins]: there are unsupported plugins in the CoreDNS Corefile

당시 참고한 이슈에서는 기존 Corefile의 proxy 플러그인과 forward로의 변경을 다뤘습니다. 특정 Corefile 조건에서는 사전 검사를 무시하고 진행하면 마이그레이션이 처리된다는 안내도 있었습니다.

다만 --ignore-preflight-errors 자체가 설정을 고치는 기능은 아닙니다. 현재 Corefile의 내용과 대상 CoreDNS·kubeadm 버전을 확인하지 않고 모든 경우에 사용할 우회 명령으로 소개하기는 어렵습니다.

먼저 설정을 보관하고 실제 변경이 필요한 플러그인을 확인할 수 있습니다.

bash


kubectl get configmap coredns -n kube-system -o yaml > coredns-backup.yaml

전환 후에는 CoreDNS Pod의 실행 상태뿐 아니라 서비스 이름 조회와 필요한 외부 DNS 조회도 확인합니다.

cAdvisor 레이블과 메트릭 필터

1.16에서는 기존 pod_name·container_name 레이블을 사용하는 쿼리와 relabel 설정을 pod·container에 맞춰 변경해야 했습니다.

당시 설정에는 이름을 복사하는 규칙 외에, 컨테이너 이름이 있는 메트릭만 남기는 keep 규칙도 있었습니다. 예시로 줄이면 변경 전은 다음과 같습니다.

yaml


metric_relabel_configs:
  - source_labels: [pod_name]
    target_label: workload_pod
  - source_labels: [container_name]
    target_label: workload_container
  - source_labels: [container_name]
    regex: '(.+)'
    action: keep

변경 후에는 복사와 필터에서 읽는 레이블을 모두 맞춥니다.

yaml


metric_relabel_configs:
  - source_labels: [pod]
    target_label: workload_pod
  - source_labels: [container]
    target_label: workload_container
  - source_labels: [container]
    regex: '(.+)'
    action: keep

없는 레이블을 읽어 빈 값이 되면 마지막 keep 규칙에서 메트릭이 제외될 수 있습니다. 단순히 화면에 표시할 이름만 바꾸는 문제가 아니었습니다. 수집 대상의 응답, relabel 결과, 대시보드와 알림 쿼리를 이어서 확인해야 했습니다.

일부 API의 지원 종료

1.16에서는 apps/v1beta1·apps/v1beta2와 일부 extensions/v1beta1 리소스의 기본 제공이 종료됐습니다. Deployment 등은 apps/v1으로 바꿔야 했지만, 모든 v1beta1 리소스를 같은 API로 치환할 수 있는 것은 아닙니다.

API 버전만 바꾸는 것으로 끝나지도 않습니다. apps/v1 Deployment는 selector와 Pod 레이블이 맞아야 하므로 해당 버전의 필수 필드와 동작도 확인해야 합니다.

전환 이후의 확인 범위

노드가 Ready이고 시스템 Pod가 실행 중이어도 DNS·메트릭·기존 배포 파일의 호환성은 따로 문제가 남을 수 있습니다. 당시에는 클러스터 상태와 애플리케이션 주변의 연동을 나눠 확인해야 했습니다.