Kubernetes `kube-proxy` self-managed 추가 기능 업데이트
Kubernetes kube-proxy self-managed 추가 기능 업데이트
중요
추가 기능의 self-managed 유형 대신 Amazon EKS 유형의 추가 기능을 클러스터에 추가할 것을 권장합니다. 두 유형의 차이를 잘 모르겠다면 Amazon EKS 추가 기능을 참조하세요. Amazon EKS 추가 기능을 클러스터에 추가하는 방법은 Amazon EKS 추가 기능 생성을 참조하세요. Amazon EKS 추가 기능을 사용할 수 없다면 Containers roadmap GitHub 저장소에 사용할 수 없는 이유에 대한 이슈를 제출할 것을 권장합니다.
출처: 문서
본문
사전 요구 사항
기존 Amazon EKS 클러스터. 배포하려면 Amazon EKS 시작하기(Get started with Amazon EKS)를 참조하세요.
고려 사항
- Amazon EKS 클러스터의
Kube-proxy는 Kubernetes와 같은 호환성 및 스큐(skew) 정책을 가집니다. Amazon EKS 추가 기능 버전 호환성을 클러스터와 확인하는 방법을 학습하세요.
절차
클러스터에 self-managed 유형의 추가 기능이 설치되어 있는지 확인합니다. my-cluster를 클러스터 이름으로 바꿉니다.
aws eks describe-addon --cluster-name my-cluster --addon-name kube-proxy --query addon.addonVersion --output text
오류 메시지가 반환되면 클러스터에 self-managed 유형의 추가 기능이 설치되어 있는 것입니다. 이 주제의 나머지 단계는 추가 기능의 self-managed 유형을 업데이트하기 위한 것입니다. 버전 번호가 반환되면 클러스터에 Amazon EKS 유형의 추가 기능이 설치되어 있는 것입니다. 이를 업데이트하려면 이 주제의 절차 대신 Amazon EKS 추가 기능 업데이트의 절차를 사용하세요. 추가 기능 유형 간의 차이를 잘 모르겠다면 Amazon EKS 추가 기능을 참조하세요.
클러스터에 현재 설치된 컨테이너 이미지 버전을 확인합니다.
kubectl describe daemonset kube-proxy -n kube-system | grep Image
예시 출력은 다음과 같습니다.
Image: 602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.29.1-eksbuild.2
예시 출력에서 v1.29.1-eksbuild.2는 클러스터에 설치된 버전입니다.
602401143452와 region-code를 이전 단계의 출력 값으로 바꿔 kube-proxy 추가 기능을 업데이트합니다. v1.30.6-eksbuild.3을 각 Amazon EKS 클러스터 버전에 대한 최신 사용 가능한 self-managed kube-proxy 컨테이너 이미지 버전 표에 나열된 kube-proxy 버전으로 바꿉니다.
중요
각 이미지 유형의 매니페스트는 다르며 기본(default) 또는 최소(minimal) 이미지 유형 간에 호환되지 않습니다. 엔트리포인트와 인수가 일치하도록 이전 이미지와 같은 이미지 유형을 사용해야 합니다.
kubectl set image daemonset.apps/kube-proxy -n kube-system kube-proxy=602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.30.6-eksbuild.3
예시 출력은 다음과 같습니다.
daemonset.apps/kube-proxy image updated
새 버전이 클러스터에 설치되었는지 확인합니다.
kubectl describe daemonset kube-proxy -n kube-system | grep Image | cut -d ":" -f 3
예시 출력은 다음과 같습니다.
v1.30.0-eksbuild.3
같은 클러스터에서 x86과 Arm 노드를 사용하고 클러스터가 2020년 8월 17일 이전에 배포된 경우, 다음 명령으로 kube-proxy 매니페스트를 편집해 여러 하드웨어 아키텍처에 대한 노드 셀렉터를 포함하세요. 이는 일회성 작업입니다. 매니페스트에 셀렉터를 추가한 뒤에는 추가 기능을 업데이트할 때마다 추가할 필요가 없습니다. 클러스터가 2020년 8월 17일 이후에 배포된 경우 kube-proxy는 이미 멀티 아키텍처를 지원합니다.
kubectl edit -n kube-system daemonset/kube-proxy
편집기에서 파일에 다음 노드 셀렉터를 추가한 뒤 파일을 저장합니다. 편집기에서 이 텍스트를 포함할 위치의 예시는 GitHub의 CNI 매니페스트 파일을 참조하세요. 이는 Kubernetes가 노드의 하드웨어 아키텍처를 기반으로 올바른 하드웨어 이미지를 가져오도록 합니다.
- key: "kubernetes.io/arch"
operator: In
values:
- amd64
- arm64
클러스터가 원래 Kubernetes 버전 1.14 이상으로 생성되었다면 kube-proxy가 이미 이 Affinity Rule을 포함하므로 이 단계를 건너뛸 수 있습니다. 원래 Kubernetes 버전 1.13 이하로 Amazon EKS 클러스터를 만들고 클러스터에 Fargate 노드를 사용하려 한다면 kube-proxy Pod가 Fargate 노드에 스케줄링되지 않도록 NodeAffinity 규칙을 포함하도록 kube-proxy 매니페스트를 편집합니다. 이는 일회성 편집입니다. 매니페스트에 Affinity Rule을 추가한 뒤에는 추가 기능을 업데이트할 때마다 추가할 필요가 없습니다. kube-proxy DaemonSet을 편집합니다.
kubectl edit -n kube-system daemonset/kube-proxy
편집기에서 파일의 DaemonSet spec 섹션에 다음 Affinity Rule을 추가한 뒤 파일을 저장합니다. 편집기에서 이 텍스트를 포함할 위치의 예시는 GitHub의 CNI 매니페스트 파일을 참조하세요.
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- fargate