내용으로 건너뛰기

Amazon EKS로 여러 CIDR 범위를 사용하려면 어떻게 해야 합니까?

6분 분량
0

Amazon Elastic Kubernetes Service(Amazon EKS)로 여러 CIDR 범위를 사용하여 포드 관련 문제를 해결하고 싶습니다.

간략한 설명

Amazon EKS에서 여러 CIDR 범위를 사용하려면 다음 단계를 완료하십시오.

  1. 더 많은 CIDR 범위를 추가하여 가상 프라이빗 클라우드(VPC) 네트워크를 확장합니다.
  2. 새 CIDR 범위로 서브넷을 만듭니다.
  3. 새 서브넷을 라우팅 테이블에 연결합니다.
  4. 새 CIDR 범위를 사용하도록 Amazon Virtual Private Cloud(Amazon VPC) 컨테이너 네트워크 인터페이스(CNI) 플러그인을 구성합니다.

참고: 100.64.0.0/10 또는 198.19.0.0/16과 같은 통신사 등급 NAT(CGN) 공간의 CIDR(/16)을 사용하는 것이 가장 좋습니다. 유효한 VPC 범위를 사용자 지정 네트워크의 보조 CIDR 범위로 사용할 수 있습니다. 그러나 이러한 범위는 기업 환경에서 사용될 가능성이 낮습니다. 사용자 지정 네트워킹 요구 사항에 대한 자세한 내용은 고려 사항을 참조하십시오.

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하면 AWS CLI의 오류 해결을 참조하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.

전제 조건: 다음과 같은 구성이 있어야 합니다.

더 많은 CIDR 범위를 추가하여 VPC 네트워크 확장

다음 단계를 완료하십시오.

  1. 클러스터 VPC의 ID를 검색하여 변수에 저장하려면 다음 AWS CLI describe-cluster 명령을 실행합니다.
    VPC_ID=$(aws eks describe-cluster --name CLUSTER_NAME --region REGION_CODE --query "cluster.resourcesVpcConfig.vpcId" --output text)
    참고: CLUSTER_NAME을 클러스터 이름으로 바꾸고, REGION_CODE를 클러스터를 배포한 AWS 리전으로 바꾸십시오.
  2. 100.64.0.0/16 범위의 다른 CIDR 블록을 VPC에 연결하려면 다음 associate-vpc-cidr-block 명령을 실행합니다.
    aws ec2 associate-vpc-cidr-block --vpc-id $VPC_ID --cidr-block 100.64.0.0/16

새 CIDR 범위로 서브넷 만들기

다음 단계를 완료하십시오.

  1. 해당 리전의 모든 가용 영역을 나열하려면 다음 describe-availability-zones 명령을 실행합니다.
    aws ec2 describe-availability-zones --region REGION_CODE --query 'AvailabilityZones[*].ZoneName'
    참고: REGION_CODE를 리소스를 배포한 리전으로 바꾸십시오.
  2. 기존 서브넷이 있는 각 가용 영역에서 사용할 서브넷을 만듭니다. 새 CIDR 범위를 사용하여 VPC에서 새 서브넷을 만들려면 다음 create-subnet 명령을 실행합니다.
    CUST_SNET1=$(aws ec2 create-subnet --cidr-block 100.64.0.0/19 --vpc-id $VPC_ID --availability-zone AZ1 | jq -r .Subnet.SubnetId)
    CUST_SNET2=$(aws ec2 create-subnet --cidr-block 100.64.32.0/19 --vpc-id $VPC_ID --availability-zone AZ2 | jq -r .Subnet.SubnetId)
    CUST_SNET3=$(aws ec2 create-subnet --cidr-block 100.64.64.0/19 --vpc-id $VPC_ID --availability-zone AZ3 | jq -r .Subnet.SubnetId)
    참고: AZ1, AZ2, AZ3을 기존 서브넷 가용 영역으로 바꾸십시오.
  3. (선택 사항) 키-값 페어를 설정하여 서브넷에 이름 태그를 추가하려면 다음 create-tags 명령을 실행합니다.
    aws ec2 create-tags --resources $CUST_SNET1 --tags Key=KEY,Value=VALUE
    aws ec2 create-tags --resources $CUST_SNET2 --tags Key=KEY,Value=VALUE
    aws ec2 create-tags --resources $CUST_SNET3 --tags Key=KEY,Value=VALUE
    참고: KEY를 태그 키로, VALUE를 태그 값으로 바꾸십시오.

새 서브넷을 라우팅 테이블에 연결

기본적으로 Amazon VPC는 새 서브넷을 VPC의 기본 라우팅 테이블과 연결합니다. 이 라우팅 테이블은 VPC에 배포된 리소스 간의 통신만 허용합니다. VPC의 CIDR 블록 외부에 있는 IP 주소와의 통신을 허용하려면 서브넷에 대한 자체 라우팅 테이블을 만들어야 합니다.

새 CIDR 범위를 사용하도록 Amazon VPC CNI 플러그인 구성

다음 단계를 완료하십시오.

  1. Kubernetes 버전에 맞는 플러그인 버전을 실행하는지 확인합니다. 버전을 확인하려면 다음 명령을 실행합니다.

    kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

    올바른 플러그인 버전이 없는 경우 Amazon VPC CNI를 업데이트하십시오.

  2. Amazon VPC CNI 플러그인의 사용자 지정 네트워크 구성을 활성화하려면 다음 명령을 실행합니다.

    kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
  3. 워커 노드를 식별하기 위해 ENIConfig 레이블을 추가하려면 다음 명령을 실행합니다.

    kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone
  4. 모든 서브넷과 가용 영역에 대한 ENIConfig 사용자 지정 리소스를 만들려면 다음 명령을 실행합니다.

    cat <<EOF  | kubectl apply -f -apiVersion: crd.k8s.amazonaws.com/v1alpha1
    kind: ENIConfig
    metadata:
     name: $AZ1
    spec:
      securityGroups:
        - cluster_security_group_id
      subnet: $CUST_SNET1
    EOF
    
    cat <<EOF | kubectl apply -f -
    apiVersion: crd.k8s.amazonaws.com/v1alpha1
    kind: ENIConfig
    metadata:
     name: $AZ2
    spec:
      securityGroups:
        - cluster_security_group_id
      subnet: $CUST_SNET2
    EOF
    
    cat <<EOF | kubectl apply -f -
    apiVersion: crd.k8s.amazonaws.com/v1alpha1
    kind: ENIConfig
    metadata:
     name: $AZ3
    spec:
      securityGroups:
        - cluster_security_group_id
      subnet: $CUST_SNET3
    EOF

    참고: cluster_security_group_id를 각 ENIConfig 리소스에 사용할 기존 보안 그룹의 ID로 바꾸십시오. ENIConfig 리소스 이름은 새 서브넷을 만든 가용 영역과 동일합니다.

  5. 자체 관리형 노드 그룹을 사용하는 경우 플러그인이 IP 주소를 할당할 수 있도록 자체 관리형 워커 노드를 시작합니다. 서브넷의 경우 ENIConfig 리소스에서 사용한 새 서브넷 대신 클러스터를 만들 때 선택한 원래 서브넷을 사용하십시오. 시작 템플릿이 있는 관리형 노드 그룹을 사용하여 노드를 시작할 수도 있습니다. 두 경우 모두 인스턴스 유형에 맞는 max-pods 값을 식별해야 합니다. 이는 Amazon EKS의 사용자 지정 네트워킹이 포드 배치에 기본 네트워크 인터페이스를 사용하지 않기 때문입니다. max-pods-calculator.sh 스크립트를 실행할 때 --cni-custom-networking-enabled 파라미터를 추가해야 합니다.
    그 후 다음 명령을 실행하여 자체 관리형 노드의 max-pods 값을 지정합니다.

    --use-max-pods false --kubelet-extra-args '--max-pods=20'

    참고: 20을 계산한 max-pods 값으로 바꾸십시오.
    관리형 노드 그룹의 경우 사용자 데이터에 다음 스크립트를 추가합니다.

    #!/bin/bash
    /etc/eks/bootstrap.sh my-cluster-name --use-max-pods false --kubelet-extra-args '--max-pods=20'

    참고: my-cluster-name을 클러스터 이름으로 바꾸고 20을 계산한 max-pods 값으로 바꾸십시오. 시작 템플릿에서 Amazon EKS에 최적화된 Amazon Machine Image(AMI) ID 또는 Amazon EKS 최적화 AMI를 기반으로 구축된 사용자 지정 AMI를 지정합니다. Amazon Linux 2023(AL2023) AMI는 nodeadm 프로세스를 사용합니다. 이로 인해 사용자 데이터 구성이 어떻게 변경되는지에 대한 자세한 내용은 Amazon Linux 2에서 Amazon Linux 2023으로 업그레이드를 참조하십시오.
    시작 템플릿이나 지정된 AMI ID가 없는 관리형 노드 그룹을 사용하는 경우 관리형 노드 그룹은 자동으로 max-pods 값을 계산합니다.

  6. 새 노드가 준비되면 이전 노드를 드레이닝하여 포드를 정상적으로 종료합니다. 자세한 내용은 Kubernetes 웹 사이트에서 안전하게 노드 드레이닝을 참조하십시오. 노드가 기존 관리형 노드 그룹에 있는 경우 다음 명령을 실행하여 노드 그룹을 삭제합니다.

    aws eks delete-nodegroup --cluster-name CLUSTER_NAME --nodegroup-name my-nodegroup

    참고: CLUSTER_NAME을 클러스터 이름으로 바꾸고 my-nodegroup을 노드 그룹 이름으로 바꾸십시오.

  7. 새 배포를 시작하여 구성을 테스트하려면 다음 명령을 실행합니다.

    kubectl create deployment nginx-test --image=nginx --replicas=10   
    kubectl get pods -o wide --selector=app=nginx-test

    참고: 위 명령은 새 포드 10개를 추가하고 새 워커 노드의 새 CIDR 범위에 예약합니다.

중요: 클러스터가 VPC와 연결된 새 CIDR 블록을 인식하고 허용 목록에 추가하는 데 최대 5시간이 걸릴 수 있습니다. 이 시간 동안 Amazon EKS 컨트롤 플레인은 새 서브넷에서 시작하는 포드와 통신할 수 없습니다. api-server가 웹훅, kubectl logs 명령 또는 kubectl exec 명령으로 포드에 접속하면 다음과 같은 오류 메시지가 표시될 수 있습니다.

"failed calling webhook "linkerd-proxy-injector.linkerd.io": failed to call webhook: Post "https://linkerd-proxy-injector.linkerd.svc:443/?timeout=10s": Address is not allowed"

AWS 공식업데이트됨 4달 전