Amazon VPC CNI 업데이트하기

Amazon VPC CNI 업데이트하기 (Amazon EKS 추가 기능) (Update the Amazon VPC CNI (Amazon EKS add-on))

Kubernetes용 Amazon VPC CNI 플러그인 추가 기능의 Amazon EKS 유형을 업데이트해요. 아직 Amazon EKS 유형의 추가 기능을 클러스터에 추가하지 않았다면 Amazon VPC CNI 생성하기(Amazon EKS 추가 기능)를 따라 설치할 수 있어요. 또는 다른 유형의 VPC CNI 설치는 Amazon VPC CNI 업데이트하기(자체 관리형 추가 기능)를 따라 업데이트하세요.

출처: 문서

본문

클러스터에 설치된 추가 기능 버전을 확인해요. my-cluster를 클러스터 이름으로 바꾸세요.
```
aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni --query "addon.addonVersion" --output text
```
예시 출력은 다음과 같아요.
```
v1.20.0-eksbuild.1
```
버전을 Amazon VPC CNI 버전의 최신 버전 표와 비교해요. 반환된 버전이 최신 버전 표에서 클러스터의 Kubernetes 버전에 대한 버전과 같다면 이미 최신 버전이 설치된 것이므로 이 절차의 나머지를 완료할 필요가 없어요. 출력에서 버전 번호 대신 오류가 발생한다면 클러스터에 Amazon EKS 유형의 추가 기능이 설치되어 있지 않은 거예요. 이 절차로 업데이트하려면 먼저 추가 기능을 만들어야 해요. VPC CNI 추가 기능의 Amazon EKS 유형을 만들려면 Amazon VPC CNI 생성하기(Amazon EKS 추가 기능)를 따르세요.

현재 설치된 추가 기능의 구성을 저장해요.

kubectl get daemonset aws-node -n kube-system -o yaml > aws-k8s-cni-old.yaml

AWS CLI로 추가 기능을 업데이트해요. AWS Management Console이나 eksctl로 추가 기능을 업데이트하려면 Amazon EKS 추가 기능 업데이트하기를 참고하세요. 다음 명령을 복사하고 필요한 대로 수정한 후 실행하세요.
- my-cluster를 클러스터 이름으로 바꾸세요.
- v1.20.0-eksbuild.1을 클러스터 버전용 최신 버전 표에 나열된 최신 버전으로 바꾸세요.
- 111122223333을 계정 ID로, AmazonEKSVPCCNIRole을 생성한 기존 IAM 역할 이름으로 바꾸세요. VPC CNI용 IAM 역할을 만들려면 1단계: Kubernetes용 Amazon VPC CNI 플러그인 IAM 역할 생성을 참고하세요. 역할을 지정하려면 클러스터용 IAM OIDC(OpenID Connect) 프로바이더가 필요해요. 클러스터에 있는지 확인하거나 만들려면 클러스터용 IAM OIDC 프로바이더 생성하기를 참고하세요.
--resolve-conflicts PRESERVE 옵션은 추가 기능의 기존 구성 값을 보존해요. 추가 기능 설정에 커스텀 값을 설정했는데 이 옵션을 사용하지 않으면 Amazon EKS가 기본값으로 여러분의 값을 덮어써요. 이 옵션을 사용한다면 프로덕션 클러스터에서 추가 기능을 업데이트하기 전에 프로덕션이 아닌 클러스터에서 필드와 값 변경을 테스트하는 것을 권장해요. 이 값을 OVERWRITE로 바꾸면 모든 설정이 Amazon EKS 기본값으로 변경돼요. 어떤 설정에 커스텀 값을 설정했다면 Amazon EKS 기본값으로 덮어써질 수 있어요. 이 값을 none으로 바꾸면 Amazon EKS는 어떤 설정 값도 변경하지 않지만 업데이트가 실패할 수 있어요. 업데이트가 실패하면 충돌 해결을 돕는 오류 메시지가 표시돼요.

구성 설정을 업데이트하는 것이 아니라면 명령에서 --configuration-values '{"env":{"AWS_VPC_K8S_CNI_EXTERNALSNAT":"true"}}'를 제거하세요. 구성 설정을 업데이트한다면 "env":{"AWS_VPC_K8S_CNI_EXTERNALSNAT":"true"}를 설정하려는 값으로 바꾸세요. 이 예시에서는 AWS_VPC_K8S_CNI_EXTERNALSNAT 환경 변수를 true로 설정해요. 지정하는 값은 구성 스키마에 유효해야 해요. 구성 스키마를 모르겠다면 aws eks describe-addon-configuration --addon-name vpc-cni --addon-version v1.20.0-eksbuild.1을 실행하세요. 여기서 v1.20.0-eksbuild.1을 구성을 보고 싶은 추가 기능의 버전 번호로 바꾸세요. 스키마는 출력에 반환돼요. 기존 커스텀 구성이 있고 모두 제거해 모든 설정 값을 Amazon EKS 기본값으로 되돌리려면 명령에서 "env":{"AWS_VPC_K8S_CNI_EXTERNALSNAT":"true"}를 제거해 빈 {}가 되게 하세요. 각 설정에 대한 설명은 GitHub의 CNI Configuration Variables를 참고하세요.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.20.3-eksbuild.1 \
    --service-account-role-arn arn:aws:iam::111122223333:role/AmazonEKSVPCCNIRole \
    --resolve-conflicts PRESERVE --configuration-values '{"env":{"AWS_VPC_K8S_CNI_EXTERNALSNAT":"true"}}'
```
업데이트가 완료되는 데 몇 초가 걸릴 수 있어요.

추가 기능 버전이 업데이트되었는지 확인해요. my-cluster를 클러스터 이름으로 바꾸세요.

aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni

업데이트가 완료되는 데 몇 초가 걸릴 수 있어요. 예시 출력은 다음과 같아요.

{
    "addon": {
        "addonName": "vpc-cni",
        "clusterName": "my-cluster",
        "status": "ACTIVE",
        "addonVersion": "v1.20.3-eksbuild.1",
        "health": {
            "issues": []
        },
        "addonArn": "arn:aws:eks:region:111122223333:addon/my-cluster/vpc-cni/74c33d2f-b4dc-8718-56e7-9fdfa65d14a9",
        "createdAt": "2023-04-12T18:25:19.319000+00:00",
        "modifiedAt": "2023-04-12T18:40:28.683000+00:00",
        "serviceAccountRoleArn": "arn:aws:iam::111122223333:role/AmazonEKSVPCCNIRole",
        "tags": {},
        "configurationValues": "{\"env\":{\"AWS_VPC_K8S_CNI_EXTERNALSNAT\":\"true\"}}"
    }
}

문제 해결 (Troubleshooting)

v1.13.2보다 이전 버전에서 VPC CNI를 업그레이드할 때는 업데이트 후 클러스터의 모든 노드를 교체해야 해요. v1.13.2 이전 버전은 소스 NAT(SNAT) 같은 올바른 기능에 필요한 iptables 규칙을 삽입하기 위해 iptables-legacy 백엔드를 사용해요.

v1.13.2 버전은 iptables-wrapper를 도입한 중요한 릴리스예요. iptables-wrapper는 체인과 규칙을 삽입하기에 적절한 iptables 백엔드(iptables-legacy 또는 iptables-nft)를 자동으로 감지해요. 이 변경은 성능 제한 때문에 레거시 백엔드에서 벗어나기로 한 업스트림 Kubernetes 결정과 일치해요.

VPC CNI를 v1.13.2보다 이전 버전에서 업그레이드한 후 노드를 교체해야 하는 이유는 iptables-legacy와 iptables-nft 두 백엔드 모두에 규칙을 도입하면 비기본 ENI에서 발생하는 트래픽에 예기치 않은 동작이 발생할 수 있기 때문이에요.

더 알아보기 (Learn more)

공식 문서