Amazon EKS 클러스터에 대해 Windows 지원 사용 설정 - Amazon EKS

Amazon EKS 클러스터에 대해 Windows 지원 사용 설정

Windows 노드를 배포하기 전에 다음 사항을 고려해야 합니다.

고려 사항
  • HostProcess 포드로 Windows 노드에서 호스트 네트워킹을 사용할 수 있습니다. 자세한 내용은 Kubernetes 설명서의 Create a Windows HostProcessPod를 참조하세요.

  • Amazon EKS 클러스터에는 CoreDNS와 같이 Linux에서만 실행되는 코어 시스템 Pods를 실행하기 위한 Linux 또는 Fargate 노드가 하나 이상 있어야 합니다.

  • kubeletkube-proxy 이벤트 로그는 EKS Windows 이벤트 로그로 리디렉션되며 200MB 제한으로 설정됩니다.

  • Windows 노드에서 실행되는 Pods에 Pods의 보안 그룹를 사용할 수 없습니다.

  • Windows 노드에는 사용자 지정 네트워킹을 사용할 수 없습니다.

  • Windows 노드에서는 IPv6를 사용할 수 없습니다.

  • Windows 노드는 노드당 하나의 Elastic 네트워크 인터페이스를 지원합니다. 기본적으로 Windows 노드당 실행할 수 있는 Pods 수는 노드의 인스턴스 유형에 대해 탄력적 네트워크 인터페이스당 사용 가능한 IP 주소 수에서 1을 뺀 값과 같습니다. 자세한 내용은 Windows 인스턴스용 Amazon EC2 사용 설명서인스턴스 유형별 네트워크 인터페이스당 IP 주소를 참조하세요.

  • Amazon EKS 클러스터에서 로드 밸런서가 있는 단일 서비스는 최대 1,024개의 백엔드 Pods를 지원할 수 있습니다. 각 Pod에는 고유한 IP 주소가 있습니다. OS 빌드 17763.2746부터 Windows Server 업데이트 후 이전의 64개 Pods 제한이 더 이상 적용되지 않습니다.

  • Windows 컨테이너는 Fargate의 Amazon EKS Pods에 대해 지원되지 않습니다.

  • vpc-resource-controller 포드에서 로그를 검색할 수 없습니다. 이전에는 컨트롤러를 데이터 영역에 배포할 때 가능했습니다.

  • IPv4 주소가 새 포드에 할당되기 전에 휴지 기간이 있습니다. 이렇게 하면 오래된 kube-proxy 규칙으로 인해 동일한 IPv4 주소를 사용하는 이전 포드로 트래픽이 흐르는 것을 방지할 수 있습니다.

  • 컨트롤러의 소스는 GitHub에서 관리됩니다. 컨트롤러에 기여하거나 컨트롤러에 대한 문제를 제기하려면 GitHub의 프로젝트를 방문하세요.

  • Windows 관리형 노드 그룹에 사용자 지정 AMI ID를 지정할 때는 AWS IAM Authenticator 구성 맵에 eks:kube-proxy-windows를 추가합니다. 자세한 내용은 AMI ID 지정 시 제한과 조건 단원을 참조하십시오.

사전 조건
  • 기존 클러스터가 있어야 합니다. 클러스터는 다음 표에 나열된 Kubernetes 버전 및 플랫폼 버전 중 하나를 실행해야 합니다. 나열된 것보다 이후의 모든 Kubernetes 및 플랫폼 버전이 지원됩니다. 클러스터 또는 플랫폼 버전이 다음 버전 중 하나보다 이전인 경우 클러스터의 데이터 영역에서 레거시 Windows 지원을 사용 설정해야 합니다. 클러스터가 다음 Kubernetes 및 플랫폼 버전 이상 중 하나에 있으면 컨트롤 플레인에서 레거시 Windows 지원을 제거하고 Windows 지원을 사용 설정할 수 있습니다.

    Kubernetes 버전 플랫폼 버전
    1.29 eks.1
    1.28 eks.1
    1.27 eks.1
    1.26 eks.1
    1.25 eks.1
    1.24 eks.2
  • CoreDNS를 실행하려면 클러스터에 Linux 노드 또는 Fargate Pod가 1개 이상(최소 2개 권장) 있어야 합니다. 레거시 Windows 지원을 사용 설정하는 경우 Linux 노드(Fargate Pod 사용 불가)를 사용하여 CoreDNS를 실행해야 합니다.

  • 기존 Amazon EKS 클러스터 IAM 역할 보유.

Windows 지원 활성화

클러스터가 전제 조건에 나열된 Kubernetes 및 플랫폼 버전 중 하나 이상이 아니면 대신에 레거시 Windows 지원을 활성화해야 합니다. 자세한 내용은 레거시 Windows 지원 사용 단원을 참조하십시오.

클러스터에서 Windows 지원을 사용 설정한 적이 없다면 다음 단계로 건너뜁니다.

전제 조건에 나열된 Kubernetes 또는 플랫폼 버전보다 이전인 클러스터에서 Windows 지원을 사용 설정한 경우 먼저 데이터 영역에서 vpc-resource-controller 및 vpc-admission-webhook를 제거해야 합니다. 낙후되었으며 더 이상 필요하지 않습니다.

클러스터에 Windows 지원을 사용하려면 다음을 수행합니다.
  1. 클러스터에 Amazon Linux 노드가 없고 Pods에 보안 그룹을 사용하는 경우 다음 단계로 건너뜁니다. 그렇지 않으면 AmazonEKSVPCResourceController 관리형 정책이 클러스터 역할에 연결되어 있는지 확인합니다. eksClusterRole를 클러스터 역할 이름으로 교체합니다.

    aws iam list-attached-role-policies --role-name eksClusterRole

    예제 출력은 다음과 같습니다.

    {
        "AttachedPolicies": [
            {
                "PolicyName": "AmazonEKSClusterPolicy",
                "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
            },
            {
                "PolicyName": "AmazonEKSVPCResourceController",
                "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController"
            }
        ]
    }

    이전 출력에서와 같이 정책이 연결된 경우 다음 단계를 건너뜁니다.

  2. AmazonEKSVPCResourceController 관리형 정책을 Amazon EKS 클러스터 IAM 역할에 연결합니다. eksClusterRole를 클러스터 역할 이름으로 교체합니다.

    aws iam attach-role-policy \ --role-name eksClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
  3. 다음 콘텐츠를 가진 vpc-resource-controller-configmap.yaml이라는 파일을 생성합니다:

    apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-windows-ipam: "true"
  4. 클러스터에 ConfigMap 적용.

    kubectl apply -f vpc-resource-controller-configmap.yaml
  5. aws-auth ConfigMap에 Windows 노드의 인스턴스 역할에 대한 매핑이 포함되어 eks:kube-proxy-windows RBAC 권한 그룹을 포함하는지 확인합니다. 다음 명령을 실행하여 확인할 수 있습니다.

    kubectl get configmap aws-auth -n kube-system -o yaml

    예제 출력은 다음과 같습니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: aws-auth
      namespace: kube-system
    data:
      mapRoles: |
        - groups:
          - system:bootstrappers
          - system:nodes
          - eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
          rolearn: arn:aws:iam::111122223333:role/eksNodeRole
          username: system:node:{{EC2PrivateDNSName}}
    [...]
    

    그룹 아래에 eks:kube-proxy-windows가 표시될 것입니다. 그룹이 지정되지 않은 경우 ConfigMap을 업데이트하거나 생성하여 필수 그룹을 포함해야 합니다. aws-auth ConfigMap에 대한 자세한 내용은 클러스터에 aws-authConfigMap 적용 섹션을 참조하세요.

데이터 영역에서 레거시 Windows 지원 제거

전제 조건에 나열된 Windows 또는 플랫폼 버전보다 이전인 클러스터에서 Kubernetes 지원을 사용 설정한 경우 먼저 데이터 영역에서 vpc-resource-controllervpc-admission-webhook를 제거해야 합니다. 제공한 기능이 이제 제어 영역에서 사용 설정되기 때문에 낙후되어 더 이상 필요하지 않습니다.

  1. 다음 명령을 사용하여 vpc-resource-controller를 제거합니다. 원래 설치 시 사용한 도구에 관계없이 이 명령을 사용합니다. region-code(/manifests/ 뒤의 해당 텍스트 인스턴스만)를 클러스터가 있는 AWS 리전으로 바꿉니다.

    kubectl delete -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml
  2. 설치 시 사용한 도구에 대한 지침을 사용하여 vpc-admission-webhook를 제거합니다.

    eksctl

    다음 명령을 실행합니다.

    kubectl delete deployment -n kube-system vpc-admission-webhook kubectl delete service -n kube-system vpc-admission-webhook kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io vpc-admission-webhook-cfg
    kubectl on macOS or Windows

    다음 명령을 실행합니다. region-code(/manifests/ 뒤의 해당 텍스트 인스턴스만)를 클러스터가 있는 AWS 리전으로 바꿉니다.

    kubectl delete -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml
  3. 컨트롤 플레인에서 클러스터에 대한 Windows 지원을 사용 설정합니다.

Windows 지원 사용 중지

클러스터에서 Windows 지원을 사용 중지하려면 다음을 수행합니다.
  1. 클러스터에 Amazon Linux 노드가 포함되어 있고 Pods에 보안 그룹을 함께 사용하는 경우 이 단계를 건너뜁니다.

    클러스터 역할에서 AmazonVPCResourceController 관리형 IAM 정책을 제거합니다. eksClusterRole을 클러스터 역할의 이름으로 바꾸고 111122223333를 계정 ID로 바꿉니다.

    aws iam detach-role-policy \ --role-name eksClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
  2. amazon-vpc-cni ConfigMap에서 Windows IPAM을 사용 중지합니다.

    kubectl patch configmap/amazon-vpc-cni \ -n kube-system \ --type merge \ -p '{"data":{"enable-windows-ipam":"false"}}'

포드 배포

클러스터에 포드를 배포할 때 노드 유형을 혼합하여 실행하는 경우 사용되는 운영 체제를 지정해야 합니다.

Linux Pods의 경우 매니페스트에서 다음 노드 선택기 텍스트를 사용합니다.

nodeSelector: kubernetes.io/os: linux kubernetes.io/arch: amd64

Windows Pods의 경우 매니페스트에서 다음 노드 셀렉터 텍스트를 사용합니다.

nodeSelector: kubernetes.io/os: windows kubernetes.io/arch: amd64

샘플 애플리케이션을 배포하여 사용 중인 노드 셀렉터를 볼 수 있습니다.

레거시 Windows 지원 사용

클러스터가 전제 조건에 나열된 Kubernetes 및 플랫폼 버전 중 하나 이상인 경우 대신 컨트롤 플레인에서 Windows 지원을 사용 설정하는 것이 좋습니다. 자세한 내용은 Windows 지원 활성화 단원을 참조하십시오.

클러스터 또는 플랫폼 버전이 전제 조건에 나열된 버전보다 이전인 경우 다음 단계에 따라 Amazon EKS 클러스터의 데이터 영역에 대한 레거시 Windows 지원을 사용 설정할 수 있습니다. 클러스터 및 플랫폼 버전이 전제 조건에 나열된 버전 이상인 경우 레거시 Windows 지원을 제거하고 컨트롤 플레인에 대해 사용 설정하는 것이 좋습니다.

eksctl, Windows 클라이언트, macOS 또는 Linux 클라이언트를 사용하여 클러스터에 대해 레거시 Windows 지원을 사용할 수 있습니다.

eksctl
eksctl로 클러스터에 대한 레거시 Windows 지원을 사용하려면 다음을 수행합니다.
전제 조건

이 절차에는 eksctl 버전 0.172.0 이상이 필요합니다. 버전은 다음 명령을 통해 확인할 수 있습니다.

eksctl version

eksctl 업그레이드 또는 설치에 관한 자세한 내용은 eksctl 설명서에서 Installation를 참조하세요.

  1. 다음 eksctl 명령을 사용하여 Amazon EKS 클러스터에 대한 Windows 지원을 사용 설정합니다. my-cluster를 클러스터 이름으로 바꿉니다. 이 명령은 Amazon EKS 클러스터에서 Windows 워크로드를 실행하는 데 필요한 VPC 리소스 컨트롤러 및 VPC 승인 컨트롤러 웹후크를 배포합니다.

    eksctl utils install-vpc-controllers --cluster my-cluster --approve
    중요

    VPC 승인 컨트롤러 Webhook는 발급일로부터 1년 후에 만료되는 인증서로 서명됩니다. 가동 중지 시간을 방지하려면 인증서가 만료되기 전에 인증서를 갱신해야 합니다. 자세한 내용은 VPC 승인 Webhook 인증서 갱신 단원을 참조하십시오.

  2. Windows 지원을 활성화한 후 클러스터에서 Windows 노드 그룹을 시작할 수 있습니다. 자세한 내용은 자체 관리형 Windows 노드 시작 단원을 참조하십시오.

Windows
Windows 클라이언트로 클러스터에 대한 레거시 Windows 지원을 사용하려면 다음을 수행합니다.

다음 단계에서 region-code를 클러스터가 있는 AWS 리전으로 바꿉니다.

  1. VPC 리소스 컨트롤러를 클러스터에 배포합니다.

    kubectl apply -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml
  2. VPC 승인 컨트롤러 Webhook을 클러스터에 배포합니다.

    1. 필요한 스크립트 및 배포 파일을 다운로드합니다.

      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml; curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/Setup-VPCAdmissionWebhook.ps1; curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.ps1; curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-patch-ca-bundle.ps1;
    2. OpenSSLjq를 설치합니다.

    3. VPC 승인 Webhook을 설정하고 배포합니다.

      ./Setup-VPCAdmissionWebhook.ps1 -DeploymentTemplate ".\vpc-admission-webhook-deployment.yaml"
      중요

      VPC 승인 컨트롤러 Webhook는 발급일로부터 1년 후에 만료되는 인증서로 서명됩니다. 가동 중지 시간을 방지하려면 인증서가 만료되기 전에 인증서를 갱신해야 합니다. 자세한 내용은 VPC 승인 Webhook 인증서 갱신 단원을 참조하십시오.

  3. 클러스터에 필요한 클러스터 역할 바인딩이 있는지 확인합니다.

    kubectl get clusterrolebinding eks:kube-proxy-windows

    다음 예제 출력과 유사한 출력이 반환되면 클러스터에 필요한 역할 바인딩이 있습니다.

    NAME AGE eks:kube-proxy-windows 10d

    출력에 Error from server (NotFound)가 포함되어 있으면 클러스터에 필요한 클러스터 역할 바인딩이 없습니다. 다음 내용으로 eks-kube-proxy-windows-crb.yaml 파일을 생성하여 바인딩을 추가합니다.

    kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: eks:kube-proxy-windows labels: k8s-app: kube-proxy eks.amazonaws.com/component: kube-proxy subjects: - kind: Group name: "eks:kube-proxy-windows" roleRef: kind: ClusterRole name: system:node-proxier apiGroup: rbac.authorization.k8s.io

    클러스터에 구성을 적용합니다.

    kubectl apply -f eks-kube-proxy-windows-crb.yaml
  4. Windows 지원을 사용 설정한 후 클러스터에서 Windows 노드 그룹을 시작할 수 있습니다. 자세한 내용은 자체 관리형 Windows 노드 시작 단원을 참조하십시오.

macOS and Linux
macOS 또는 Linux 클라이언트로 클러스터에 대한 레거시 Windows 지원을 사용하려면 다음을 수행합니다.

이 절차를 수행하려면 클라이언트 시스템에 openssl 라이브러리 및 jq JSON 프로세서가 설치되어 있어야 합니다.

다음 단계에서 region-code를 클러스터가 있는 AWS 리전으로 바꿉니다.

  1. VPC 리소스 컨트롤러를 클러스터에 배포합니다.

    kubectl apply -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-resource-controller/latest/vpc-resource-controller.yaml
  2. 클러스터에 대한 VPC 승인 컨트롤러 Webhook 매니페스트를 생성합니다.

    1. 필요한 스크립트 및 배포 파일을 다운로드합니다.

      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.sh curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-patch-ca-bundle.sh curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/vpc-admission-webhook-deployment.yaml
    2. 셸 스크립트를 실행할 수 있도록 셸 스크립트에 권한을 추가합니다.

      chmod +x webhook-create-signed-cert.sh webhook-patch-ca-bundle.sh
    3. 보안 통신을 위한 보안 암호를 생성합니다.

      ./webhook-create-signed-cert.sh
    4. 보안 암호를 확인합니다.

      kubectl get secret -n kube-system vpc-admission-webhook-certs
    5. Webhook을 구성하고 배치 파일을 생성합니다.

      cat ./vpc-admission-webhook-deployment.yaml | ./webhook-patch-ca-bundle.sh > vpc-admission-webhook.yaml
  3. VPC 승인 Webhook을 배포합니다.

    kubectl apply -f vpc-admission-webhook.yaml
    중요

    VPC 승인 컨트롤러 Webhook는 발급일로부터 1년 후에 만료되는 인증서로 서명됩니다. 가동 중지 시간을 방지하려면 인증서가 만료되기 전에 인증서를 갱신해야 합니다. 자세한 내용은 VPC 승인 Webhook 인증서 갱신 단원을 참조하십시오.

  4. 클러스터에 필요한 클러스터 역할 바인딩이 있는지 확인합니다.

    kubectl get clusterrolebinding eks:kube-proxy-windows

    다음 예제 출력과 유사한 출력이 반환되면 클러스터에 필요한 역할 바인딩이 있습니다.

    NAME ROLE AGE eks:kube-proxy-windows ClusterRole/system:node-proxier 19h

    출력에 Error from server (NotFound)가 포함되어 있으면 클러스터에 필요한 클러스터 역할 바인딩이 없습니다. 다음 내용으로 eks-kube-proxy-windows-crb.yaml 파일을 생성하여 바인딩을 추가합니다.

    kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: eks:kube-proxy-windows labels: k8s-app: kube-proxy eks.amazonaws.com/component: kube-proxy subjects: - kind: Group name: "eks:kube-proxy-windows" roleRef: kind: ClusterRole name: system:node-proxier apiGroup: rbac.authorization.k8s.io

    클러스터에 구성을 적용합니다.

    kubectl apply -f eks-kube-proxy-windows-crb.yaml
  5. Windows 지원을 사용 설정한 후 클러스터에서 Windows 노드 그룹을 시작할 수 있습니다. 자세한 내용은 자체 관리형 Windows 노드 시작 단원을 참조하십시오.

VPC 승인 Webhook 인증서 갱신

VPC 승인 Webhook에 사용되는 인증서는 발행 후 1년이 지나면 만료됩니다. 가동 중지 시간을 방지하려면 만료되기 전에 인증서를 갱신하는 것이 중요합니다. 다음 명령을 사용하여 현재 인증서의 만료 날짜를 확인할 수 있습니다.

kubectl get secret \ -n kube-system \ vpc-admission-webhook-certs -o json | \ jq -r '.data."cert.pem"' | \ base64 -decode | \ openssl x509 \ -noout \ -enddate | \ cut -d= -f2

예제 출력은 다음과 같습니다.

May 28 14:23:00 2022 GMT

eksctl, Windows 또는 Linux/macOS 컴퓨터를 사용하여 인증서를 갱신할 수 있습니다. VPC 승인 Webhook를 설치하는 데 처음 사용했던 도구에 대한 지침을 따릅니다. 예를 들어 eksctl을 사용하여 VPC 승인 Webhook를 처음 설치한 경우 eksctl 탭의 지침에 따라 인증서를 갱신해야 합니다.

eksctl
  1. 인증서 재설치 my-cluster를 클러스터 이름으로 바꿉니다.

    eksctl utils install-vpc-controllers -cluster my-cluster -approve
  2. 다음 출력이 표시되는지 확인합니다.

    2021/05/28 05:24:59 [INFO] generate received request
    2021/05/28 05:24:59 [INFO] received CSR
    2021/05/28 05:24:59 [INFO] generating key: rsa-2048
    2021/05/28 05:24:59 [INFO] encoded CSR
  3. Webhook 배포를 다시 시작합니다.

    kubectl rollout restart deployment -n kube-system vpc-admission-webhook
  4. 갱신한 인증서가 만료되어 Windows Pods 포드가 Container creating 상태인 경우 해당 Pods를 삭제하고 다시 배포해야 합니다.

Windows
  1. 새 인증서를 생성하는 스크립트를 가져옵니다.

    curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.ps1;
  2. 스크립트에 대한 파라미터를 준비합니다.

    ./webhook-create-signed-cert.ps1 -ServiceName vpc-admission-webhook-svc -SecretName vpc-admission-webhook-certs -Namespace kube-system
  3. Webhook 배포를 다시 시작합니다.

    kubectl rollout restart deployment -n kube-system vpc-admission-webhook-deployment
  4. 갱신한 인증서가 만료되어 Windows Pods 포드가 Container creating 상태인 경우 해당 Pods를 삭제하고 다시 배포해야 합니다.

Linux and macOS
전제 조건

컴퓨터에 OpenSSL 및 jq가 jq설치되어 있어야 합니다.

  1. 새 인증서를 생성하는 스크립트를 가져옵니다.

    curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/region-code/vpc-admission-webhook/latest/webhook-create-signed-cert.sh
  2. 권한을 변경합니다.

    chmod +x webhook-create-signed-cert.sh
  3. 스크립트를 실행합니다.

    ./webhook-create-signed-cert.sh
  4. Webhook를 다시 시작합니다.

    kubectl rollout restart deployment -n kube-system vpc-admission-webhook-deployment
  5. 갱신한 인증서가 만료되어 Windows Pods 포드가 Container creating 상태인 경우 해당 Pods를 삭제하고 다시 배포해야 합니다.

Windows 노드에서 더 높은 Pod 밀도 지원

Amazon EKS에서 각 Pod에는 VPC의 IPv4 주소가 할당됩니다. 이로 인해 노드에서 더 많은 Pods를 실행하기에 충분한 리소스가 있더라도 노드에 배포할 수 있는 Pods 수는 사용 가능한 IP 주소에 의해 제한됩니다. Windows 노드에서는 탄력적 네트워크 인터페이스를 하나만 지원하므로 기본적으로 Windows 노드에서 사용 가능한 최대 IP 주소 수는 다음과 같습니다.

Number of private IPv4 addresses for each interface on the node - 1

하나의 IP 주소는 네트워크 인터페이스의 기본 IP 주소로 사용되므로 Pods에 할당할 수 없습니다.

IP 접두사 위임을 활성화하여 Windows 노드에서 더 높은 Pod 밀도를 활성화할 수 있습니다. 이 기능을 사용하면 보조 IPv4 주소를 할당하는 대신 기본 네트워크 인터페이스에 /28 IPv4 접두사를 할당할 수 있습니다. IP 접두사를 할당하면 노드에서 사용 가능한 최대 IPv4 주소가 다음으로 증가합니다.

(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16

이렇게 사용 가능한 IP 주소의 수가 상당히 많기 때문에 사용 가능한 IP 주소가 노드의 Pods 수를 확장하는 기능을 제한하지는 않습니다. 자세한 내용은 Amazon EC2 노드에 사용 가능한 IP 주소 증량 단원을 참조하십시오.