**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# Kubernetes `kube-proxy` 자체 관리형 추가 기능 업데이트
**중요**
자체 관리형 추가 기능 유형을 사용하는 대신 클러스터에 Amazon EKS 유형의 추가 기능을 추가하는 것이 좋습니다. 유형 간의 차이를 잘 모르는 경우 [Amazon EKS 추가 기능](eks-add-ons.md) 부분을 참조하세요. Amazon EKS 추가 기능을 클러스터에 추가하는 방법에 대한 자세한 내용은 [Amazon EKS 추가 기능 생성](creating-an-add-on.md) 섹션을 참조하세요. Amazon EKS 추가 기능을 사용할 수 없는 경우, 사용할 수 없는 이유에 대한 문제를 [컨테이너 로드맵 GitHub 리포지토리](https://github.com/aws/containers-roadmap/issues)에 제출하는 것이 좋습니다.
## 사전 조건
+ 기존 Amazon EKS 클러스터. 배포하려면 [Amazon EKS 시작하기](getting-started.md) 섹션을 참조하세요.
## 고려 사항
+ Amazon EKS 클러스터의 `Kube-proxy`에는 [Kubernetes와 동일한 호환성 및 skew 정책](https://kubernetes.io/releases/version-skew-policy/#kube-proxy)이 있습니다. [클러스터와 Amazon EKS 추가 기능 버전 호환성을 확인](addon-compat.md)하는 방법을 알아보세요.
1. 클러스터에 자체 관리형 추가 기능 유형이 설치되어 있는지 확인하세요. *my-cluster*를 해당 클러스터의 이름으로 바꿉니다.
```
aws eks describe-addon --cluster-name my-cluster --addon-name kube-proxy --query addon.addonVersion --output text
```
오류 메시지가 반환되면 자체 관리형 추가 기능 유형이 클러스터에 설치됩니다. 이 주제의 나머지 단계는 추가 기능의 자체 관리형 유형을 업데이트하는 단계입니다. 버전 번호가 반환되는 경우 Amazon EKS 유형의 추가 기능이 클러스터에 설치됩니다. 업데이트하려면 이 항목의 절차 대신 [Amazon EKS 추가 기능 업데이트](updating-an-add-on.md)의 절차를 사용하세요. 추가 기능 유형 간의 차이를 잘 모르는 경우 [Amazon EKS 추가 기능](eks-add-ons.md) 부분을 참조하세요.
1. 클러스터에 현재 설치된 컨테이너 이미지의 버전을 확인하세요.
```
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*가 클러스터에 설치된 버전입니다.
1. *602401143452* 및 *region-code*를 이전 단계의 출력의 값으로 대체하여 `kube-proxy` 추가 기능을 업데이트합니다. *v1.30.6-eksbuild.3*를 [각 Amazon EKS 클러스터 버전에서 사용 가능한 최신 자체 관리형 kube-proxy 컨테이너 이미지 버전](managing-kube-proxy.md#managing-kube-proxy-images) 표에 나열된 `kube-proxy` 버전으로 바꿉니다.
**중요**
각 이미지 유형의 매니페스트는 서로 다르며 *기본* 또는 *최소* 이미지 유형 사이에서 호환되지 않습니다. 진입점과 인수가 일치하도록 이전 이미지와 동일한 이미지 유형을 사용해야 합니다.
```
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
```
1. 이제 클러스터에 새 버전이 설치되어 있는지 확인합니다.
```
kubectl describe daemonset kube-proxy -n kube-system | grep Image | cut -d ":" -f 3
```
예제 출력은 다음과 같습니다.
```
v1.30.0-eksbuild.3
```
1. 동일한 클러스터에서 `x86` 및 `Arm` 노드를 사용하고 있고 클러스터가 2020년 8월 17일 이전에 배포된 경우 다음 명령을 사용하여 여러 하드웨어 아키텍처에 대한 노드 셀렉터를 포함하도록 `kube-proxy` 매니페스트를 편집합니다. 이는 일회성 작업입니다. 매니페스트에 셀렉터를 추가한 후에는 추가 기능을 업데이트할 때마다 이 옵션을 추가할 필요가 없습니다. 클러스터가 2020년 8월 17일 또는 이후에 배포된 경우, `kube-proxy`은(는) 이미 멀티 아키텍처를 지원합니다.
```
kubectl edit -n kube-system daemonset/kube-proxy
```
다음 노드 선택기를 편집기에서 파일에 추가한 후 파일을 저장합니다. 편집기에서 이 텍스트를 포함할 위치에 대한 예는 GitHub에서 [CNI 매니페스트](https://github.com/aws/amazon-vpc-cni-k8s/blob/release-1.11/config/master/aws-k8s-cni.yaml#L265-#L269) 파일을 참조하세요. 이를 통해 Kubernetes는 노드의 하드웨어 아키텍처를 기반으로 올바른 하드웨어 이미지를 가져올 수 있습니다.
```
- key: "kubernetes.io/arch"
operator: In
values:
- amd64
- arm64
```
1. 원래 클러스터가 Kubernetes 버전 `1.14` 이상으로 생성된 경우 `kube-proxy`가 이미 `Affinity Rule`을 포함하므로 이 단계를 건너뛸 수 있습니다. 원래 Kubernetes 버전 `1.13` 이하로 Amazon EKS 클러스터를 생성했고 클러스터에서 Fargate 노드를 사용하려는 경우 `kube-proxy` 매니페스트를 편집하여 `NodeAffinity` 규칙을 포함시켜 `kube-proxy` 포드가 Fargate 노드에서 예약하지 못하도록 하세요. 이는 일회성 편집입니다. `Affinity Rule`을(를) 매니페스트에 추가하면 추가 기능을 업데이트할 때마다 추가할 필요가 없습니다. `kube-proxy` DaemonSet을 편집합니다.
```
kubectl edit -n kube-system daemonset/kube-proxy
```
편집기에서 파일의 DaemonSet `spec` 섹션에 다음 `Affinity Rule`를 추가한 다음 파일을 저장합니다. 편집기에서 이 텍스트를 포함할 위치에 대한 예는 GitHub에서 [CNI 매니페스트](https://github.com/aws/amazon-vpc-cni-k8s/blob/release-1.11/config/master/aws-k8s-cni.yaml#L270-#L273) 파일을 참조하세요.
```
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- fargate
```