Amazon EKS 클러스터에서 DNS에 대한 CoreDNS 관리
CoreDNS는 Kubernetes 클러스터 DNS로 사용할 수 있는 유연하고 확장 가능한 DNS 서버입니다. 하나 이상의 노드가 있는 Amazon EKS 클러스터를 시작하면 클러스터에 배포된 노드 수에 관계없이 CoreDNS 이미지의 복제본 2개가 기본적으로 배포됩니다. CoreDNS Pods는 클러스터의 모든 Pods의 이름을 확인합니다. 클러스터에 CoreDNS deployment
의 네임스페이스와 일치하는 네임스페이스로 시작할 때 AWS 파게이트를 사용하는 포드 시작 시 AWS Fargate를 사용하는 Pods 정의정의가 포함된 경우 CoreDNS Pods를 Fargate 노드에 배포할 수 있다. CoreDNS에 대한 자세한 내용은 Kubernetes 설명서의 서비스 검색에 CoreDNS 사용
CoreDNS 버전
다음 표에는 각 Kubernetes 버전에 사용할 수 있는 Amazon EKS 추가 기능 유형의 최신 버전이 나열되어 있습니다.
Kubernetes 버전 | CoreDNS 버전 |
---|---|
1.31 |
v1.11.3-eksbuild.1 |
1.30 |
v1.11.3-eksbuild.1 |
1.29 |
v1.11.3-eksbuild.1 |
1.28 |
v1.10.1-eksbuild.13 |
1.27 |
v1.10.1-eksbuild.13 |
1.26 |
v1.9.3-eksbuild.17 |
1.25 |
v1.9.3-eksbuild.17 |
1.24 |
v1.9.3-eksbuild.17 |
1.23 |
v1.8.7-eksbuild.16 |
중요
이 추가 기능을 자체 관리하는 경우 표의 버전이 사용 가능한 자체 관리 버전과 다를 수 있습니다. 이 추가 기능의 자체 관리형 유형 업데이트에 대한 자세한 내용은 CoreDNS Amazon EKS 자체 관리형 추가 기능 업데이트 부분을 참조하세요.
중요 CoreDNS 업그레이드 고려 사항
-
CoreDNS Deployment의 안정성과 가용성을 개선하기 위해 버전
v1.9.3-eksbuild.6
이상과v1.10.1-eksbuild.3
가PodDisruptionBudget
과 함께 배포됩니다. 기존PodDisruptionBudget
버전을 배포한 경우 이러한 버전으로의 업그레이드가 실패할 수 있습니다. 업그레이드가 실패할 경우 다음 작업 중 하나를 수행하면 문제가 해결됩니다.-
Amazon EKS 추가 기능을 업그레이드할 때 충돌 해결 옵션으로 기존 설정을 재정의하도록 선택합니다. Deployment에 다른 사용자 지정 설정을 지정한 경우 업그레이드 후 다른 사용자 지정 설정을 다시 적용할 수 있도록 업그레이드하기 전에 설정을 백업해야 합니다.
-
기존
PodDisruptionBudget
을 제거하고 업그레이드를 다시 시도하세요.
-
-
EKS 추가 기능 버전
v1.9.3-eksbuild.3
이상 및v1.10.1-eksbuild.6
이상에서는 CoreDNS Deployment는/ready
엔드포인트를 사용하도록readinessProbe
를 설정합니다. 이 엔드포인트는 CoreDNS의Corefile
구성 파일에서 활성화됩니다.사용자 지정
Corefile
을 사용하는 경우 프로브가 사용할/ready
엔드포인트가 CoreDNS에서 활성화되도록 구성에ready
플러그인을 추가해야 합니다. -
EKS 추가 기능 버전
v1.9.3-eksbuild.7
이상 및v1.10.1-eksbuild.4
이상에서는PodDisruptionBudget
을 변경할 수 있습니다. 다음 예제의 필드를 사용하여 선택적 구성 설정에서 추가 기능을 편집하고 이러한 설정을 변경할 수 있습니다. 이 예제는 기본PodDisruptionBudget
을 보여줍니다.{ "podDisruptionBudget": { "enabled": true, "maxUnavailable": 1 } }
maxUnavailable
또는minAvailable
을 설정할 수 있지만 단일PodDisruptionBudget
에서 둘 다 설정할 수는 없습니다.PodDisruptionBudgets
에 대한 자세한 내용은 [.noloc]Kubernetes
문서에서 포드 중단 예산 지정을 참조합니다. enabled
을false
으로 설정한 경우PodDisruptionBudget
은 제거되지 않는다는 점에 유의하세요. 이 필드를false
(으)로 설정한 후에는PodDisruptionBudget
객체를 삭제해야 합니다. 마찬가지로,PodDisruptionBudget
이 있는 버전으로 업그레이드한 후 이전 버전의 추가 기능을 사용하도록 추가 기능을 편집(추가 기능 다운그레이드)해도PodDisruptionBudget
은 제거되지 않습니다.PodDisruptionBudget
을 삭제하려면 다음 명령을 실행할 수 있습니다.kubectl delete poddisruptionbudget coredns -n kube-system
-
EKS 추가 기능 버전
v1.10.1-eksbuild.5
이상에서는 KEP 2067을 준수하도록 기본 허용 범위를node-role.kubernetes.io/master:NoSchedule
에서node-role.kubernetes.io/control-plane:NoSchedule
로 변경합니다. KEP 2067에 대한 자세한 내용은 GitHub의 Kubernetes Enhancement Proposals (KEPs)에서 KEP-2067: Rename the kubeadm "master" label and taint를 참조하세요. EKS 추가 기능 버전
v1.8.7-eksbuild.8
이상 및v1.9.3-eksbuild.9
이상에서 허용 범위는 모든 Kubernetes 버전과 호환되도록 설정됩니다. -
EKS 추가 기능 버전
v1.9.3-eksbuild.11
및v1.10.1-eksbuild.7
이상에서는 CoreDNS Deployment가topologySpreadConstraints
에 대한 기본값을 설정합니다. 기본값은 사용 가능한 여러 가용 영역에 노드가 있는 경우 CoreDNS Pods가 가용 영역에 분산되도록 합니다. 기본값 대신 사용될 사용자 지정 값을 설정할 수 있습니다. 기본값은 다음과 같습니다.topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: k8s-app: kube-dns
CoreDNSv1.11
업그레이드 고려 사항
-
EKS 추가 기능 버전
v1.11.1-eksbuild.4
이상에서 컨테이너 이미지는 최소 패키지를 포함하고 셸이 없는 Amazon EKS Distro에서 유지 관리하는 최소 기본 이미지를 기반으로 합니다. 자세한 내용은 Amazon EKS Distro 를 참조하세요. CoreDNS 이미지의 사용법과 문제 해결은 동일하게 유지됩니다.