[AWS VPN] Amazon VPC의 CIDR 블록 IP 확장방법, AWS IP증설

ㅁ 개요

  EKS 환경해서 POD당 하나의 IP가 필요하다. 초기 설계보다 많은 트래픽이 발생하여 더 많은 POD를 생성해야 하는데, subnet으로 할당된 IP가 부족하였다. 그래서 더 많은 호스트를 수용할 수 있도록 IP를 확장하기로 하여, Amazon EKS에서 여러 CIDR 범위 확장하는 방법에 대해서 공부하였다. AWS 문서 Amazon EKS에서 여러 CIDR 범위를 사용하려면 어떻게 해야 하나요?를 참조하였다.

 

 

ㅁ VPC CIDR 확장 정책 변경의 필요성

  초기 VPC 생성 시 할당한 CIDR는 변경할 수가 없었다. 신규로 더 큰 가용IP를 생성하여 기존의 서브넷과 교체하는 방법 확장할 수도 있다. 하지만 서비스를 운영에 변경은 쉽지 않다. 현재의 상황은 시스템 초기 설계 기준보다 더 많은 트래픽이 발생하여 더 많은 POD를 생성해야 하지만 subnet 가용IP가 부족하였다.

 

 

ㅁ 테스트를 위한 AWS EKS 1.22 생성

$ eksctl create cluster \                                                                                                         ✔  5105  14:09:43
--name k8s-peterica \
--region ap-northeast-2 \
--version 1.22 \
--nodegroup-name work-nodes \
--nodes 1 \
--nodes-min 1 \
--nodes-max 3 \
--node-type t3.medium \
--node-volume-size=20 \
--with-oidc \
--ssh-access \
--ssh-public-key aws-login-key \
--managed

 ㅇ 클러스터 이름이 지정한 이름으로 생성되지 않았다.

 ㅇ 클러스터 이름이 예전에 생성했던 이름과 동일하여 자동생성되었다.

 ㅇ 다음에 생성할 때에는 k8s-peterica-20221212의 형태로 해야겠다.

 

 

ㅁ VPC에 Subnet 추가하기

 ㅇ 사용자 VPC를 선택 후 작업 > CIDR 편집을 클릭한다.

 

 ㅇ 새 IPv4 CIDR 추가 클릭

 

 ㅇ 수동으로 100.87.128.0/20을 입력한다.

 

 ㅇ 새 IPv4 대역이 생성된 것을 확인 할 수 있다.

 

 

ㅁ Routing Tables 확인

 ㅇ VPC > Route Tables > Routes에서 새 IPv4대역이 Routing Tables에 자동으로 추가된다.

 ㅇ 새 IPv4대역 100.87.128.0/20을 검색하면 추가된 라우터 목록을 확인할 수 있다.

 

 ㅇ 라우팅 상세에서 라우팅 대상에 추가된 것을 확인 할 수 있다.

 

 

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

 ㅇ VPC-CNI가 추가되지 않은 상태에서 추가하는 작업을 수행하였고, CNI 플로그인에 추가된 CIDR 범위를 적용하는 과정이다.

 ㅇ 실험적으로 VPC-CNI 의 권장 버젼보다 낮은 상황을 재현하기도 하였다.

 

1.    최신 버전의 CNI 플러그인이 있는지 확인하려면 다음 명령을 실행

$ kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
amazon-k8s-cni-init:v1.10.1-eksbuild.1
amazon-k8s-cni:v1.10.1-eksbuild.1

ㅇ 최신 버전의 CNI 플러그인이 있는지 확인하려면 위 명령을 실행한다.

ㅇ CNI 플러그인의 버전이 1.6.3-eksbuild.2보다 이전 버전인 경우 최신 버전으로 업데이트해야 한다.

ㅇ 현재 VPC-CNI은 추가되어 있지 않은 상태이다. 

 

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/managing-vpc-cni.html

 ㅇ EKS 1.22의 권장 VPC CNI는 1.11.4-eksbuild.1 이다.

 ㅇ 빠르게 진행하기 위해 AWS console에서 추가 기능을 추가하였다. 참고 Amazon VPC CNI plugin for Kubernetes 추가 기능 관리

 ㅇ 과정 중에 한단계 낮은 버젼을 실험적으로 선택해 보았다.

 

 ㅇ EKS > 클러스터 이동하여 추가 기능 추가를 하였다.

 ㅇ VPC CNI를 선택하여 권장 버젼 아래 버젼인 1.11.3-eksbuild.1을 선택한 후 다음을 클릭하였다.

 

 

 ㅇ 선택 사항을 확인하고 생성을 클릭하였다.

 

 

 ㅇ  클러스터 화면에서 생성 중임을 확인 할 수 있다.

 

 

1.1. VPC CNI 생성 실패

 ㅇ 권장 단계보다 낮을 경우 1.11.3-eksbuild.1 버젼의 생성은 실패하였다.

 ㅇ 생성 실패 시에는 업데이트가 되지 않기 때문에 삭제를 하고 다시 설치해야한다.

 

 ㅇ 추가 기능 상세보기 화면에서 제거를 클릭한다.

 

 

 

 ㅇ 삭제 시 5분정도 소요되었다.

 

 ㅇ 올바른 v1.11.4-eksbuild.1 버젼으로 신규 생성진행하였고 활성화 상태를 확인하였다.

 

 

 

2.    CNI 플러그인에 대한 사용자 지정 네트워크 구성을 활성화하려면 다음 명령을 실행

$ kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
daemonset.apps/aws-node env updated

 

3.    작업자 노드를 식별하기 위한 ENIConfig 레이블을 추가하려면 다음 명령을 실행

kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=failure-domain.beta.kubernetes.io/zone
daemonset.apps/aws-node env updated

 

 

4.    ENIConfig 사용자 지정 리소스 정의를 설치하려면 다음 명령을 실행

cat << EOF | kubectl apply -f -
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: eniconfigs.crd.k8s.amazonaws.com
spec:
  scope: Cluster
  group: crd.k8s.amazonaws.com
  version: v1alpha1
  names:
    plural: eniconfigs
    singular: eniconfig
    kind: ENIConfig
EOF

 ㅇ 위 명령은 기존 v1bataAWS에서 제공하는 ENIConfig 세팅 명령어이다.

 

 

4.1. ENIConfig apiVersion 트러블 슈팅

error: unable to recognize "STDIN": no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1"

 ㅇ 공식 문서의 내용을 그대로 적용하였지만, 잘못되어 있었다.

 

 ㅇ 현재 EKS 버젼(1.22)에서는 API 목록을 확인해 한 결과, 지원되지 않는 API이었다.

 ㅇ 새로운 API 규격에 받는 CustomResourceDefinition 생성 명령어를 작성해야했다.

 ㅇ apiextensions.k8s.io/v1 API 예제는 여기를 참조하였다.

 

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: eniconfigs.crd.k8s.amazonaws.com
spec:
  group: crd.k8s.amazonaws.com
  versions:
    - name: v1alpha1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          x-kubernetes-preserve-unknown-fields: true
  scope: Cluster
  names:
    plural: eniconfigs
    singular: eniconfig
    kind: ENIConfig
    listKind: ENIConfigList

 ㅇ 기존 apiextension v1beta1을 참조하여 resourcedefinition.yaml을 생성하였다.

 

 

$ kubectl apply -f resourcedefinition.yaml
customresourcedefinition.apiextensions.k8s.io/eniconfigs.crd.k8s.amazonaws.com configured

 ㅇ 커스텀리소스가 정상적으로 설정이 되었다.

 

 

 

5.    모든 서브넷 및 가용 영역에 대해 ENIConfig 사용자 지정 리소스를 생성

 ㅇ 생성된 subnet을 ENIConfig 설정으로 EKS 인식시켜줘야한다.

 

 

apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
 name: ap-northeast-2b
spec:
  subnet: subnet-06e4e22038e55a386
---
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
 name: ap-northeast-2c
spec:
  subnet: subnet-02191819646424f8a
---
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
 name: ap-northeast-2d
spec:
  subnet: subnet-00627071e96c62c9d

 ㅇ eniconfig.yaml를 생성하였다.

 

 ㅇ 검증을 위해 dry-run을 수행하면서 문제점을 찾고 구글링을 통해 보안을 하였다.

 

 

$ kubectl apply -f eniconfig.yaml
eniconfig.crd.k8s.amazonaws.com/ap-northeast-2b created
eniconfig.crd.k8s.amazonaws.com/ap-northeast-2c created
eniconfig.crd.k8s.amazonaws.com/ap-northeast-2d created

 ㅇ 완성된 명령어를 수행하여 모두 eniconfig가 생성되었다.

 

 

6.    새 CIDR 범위의 IP 주소를 할당하기

ㅇ workNode 새롭게 생성해야한다.

ㅇ 이 단계에서 CNI 플러그인(ipamd)이 새 워커 노드에서 새 CIDR 범위의 IP 주소를 할당할 수 있다.

ㅇ 이 작업을 수행하지 않을 경우에는 다음과 같은 에러가 발생한다.

f2266fbadc05bc074b432319df49b6011c7f954364f3" network for pod "x-y-service-aws-sae1-prdt-ppd-dev-789b656b462tbt4": networkPlugin cni failed to set up pod "aws-load-balancer~~" network: add cmd: failed to assign an IP address to container

 ㅇ CNI로부터 새로운 IP를 할당받지 못하여 POD가 홀딩되는 상황이 발생한다.

 ㅇ 이 경우에 대한 트러블 슈팅은 여전 글인 여기에 정리를 하였다.

 

 

 ㅇ 기존 WorkNode에 할당된 IPv4 주소는 192.168.x.x만 확인된다.

 

 ㅇ 인스턴스 > 작업 > 네트워크 > IP 주소 관리를 확인해 보면 인스턴스에 할당된 eni가
     기존 192.168.0.0/19 CIDR에 할당된 것을 확인하였다.

 ㅇ 인스턴스를 종료하고 신규로 생성하자 할당되지 않았던 100.87.0.0./20 CIDR가 할당된 것을 확인 할 수 있었다.

 

 

 ㅇ 보조 프라이빗 IPv4 주소도 100.87.0.0/20 대역으로 할당된 것을 확인할 수 있었다.

 

 

ㅁ Test Pod 생성해 보기

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: cidrtest
  name: cidrtest
spec:
  containers:
  - image: openjdk:15-jdk-alpine
    name: cidrtest
    command: ["/bin/sleep", "3650d"]
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

 ㅇ 테스트로 Pod를 생성해 보았다.

 

 ㅇ 테스트로 생성한 cidrTest Pod가 정상적으로 생성되었고, IP가 100.87.134.83으로 할당된 것을 확인할 수 있었다.

 ㅇ 아래의 내용은 CNI 플러그인에 문제가 발생할 경우 해결하는 과정을 정리해 보았다.

 

 

ㅁ Amazon EKS의 CNI 플러그인 문제를 해결하려면 어떻게 해야 합니까?

 ㅇ CNI플러그인에 문제가 있는 경우  Amazon EKS의 kubelet 또는 CNI 플러그인 문제를 해결하려면 어떻게 해야 합니까?  이곳을 참조하면 된다.

$ kubectl get pods -n kube-system -l k8s-app=aws-node -o wide
NAME             READY   STATUS    RESTARTS   AGE   IP              NODE                                               NOMINATED NODE   READINESS GATES
aws-node-hbbvh   1/1     Running   0          58m   192.168.66.22   ip-192-168-66-22.ap-northeast-2.compute.internal   <none>           <none>

 ㅇ 각 작업자 노드에서 aws-node 포드가 실행 상태인지 확인: 이상무

 

 

$ kubectl get pods -n kube-system -l k8s-app=kube-proxy -o wide
NAME               READY   STATUS    RESTARTS   AGE   IP              NODE                                               NOMINATED NODE   READINESS GATES
kube-proxy-sffl4   1/1     Running   0          62m   192.168.66.22   ip-192-168-66-22.ap-northeast-2.compute.internal   <none>           <none>

 ㅇ 각 작업자 노드에서 kube-proxy 포드가 실행 상태인지 확인: 이상무

 

 

$ aws ec2 describe-subnets --filters "Name=vpc-id,Values= vpc-02114fbc06fa495a5"| jq '.Subnets[]| .SubnetId + "=" + "\(.AvailableIpAddressCount)"'
"subnet-00627071e96c62c9d=8186"
"subnet-06047485224c15781=8186"
"subnet-0e0680be1dd221513=8187"
"subnet-0d53d50416a112f19=8186"
"subnet-06e4e22038e55a386=8186"
"subnet-02191819646424f8a=8187"

  ㅇ 서브넷에 사용 가능한 여유 IP 주소가 충분히 있는지 확인: 서브넷에 8180여개 여유 확인

 

 

 

ㅁ 테스트 완료 후 EKS 정리

$ eksctl delete cluster -n ferocious-mushroom-1669871447
2022-12-13 21:32:04 [ℹ]  deleting EKS cluster "ferocious-mushroom-1669871447"
2022-12-13 21:32:05 [ℹ]  will drain 0 unmanaged nodegroup(s) in cluster "ferocious-mushroom-1669871447"
2022-12-13 21:32:05 [ℹ]  starting parallel draining, max in-flight of 1
2022-12-13 21:32:05 [ℹ]  deleted 0 Fargate profile(s)
2022-12-13 21:32:06 [✔]  kubeconfig has been updated
2022-12-13 21:32:06 [ℹ]  cleaning up AWS load balancers created by Kubernetes objects of Kind Service or Ingress
2022-12-13 21:32:07 [ℹ]
2 sequential tasks: { delete nodegroup "ng-ee6f597f", delete cluster control plane "ferocious-mushroom-1669871447" [async]
}
2022-12-13 21:32:07 [ℹ]  will delete stack "eksctl-ferocious-mushroom-1669871447-nodegroup-ng-ee6f597f"
2022-12-13 21:32:07 [ℹ]  waiting for stack "eksctl-ferocious-mushroom-1669871447-nodegroup-ng-ee6f597f" to get deleted
2022-12-13 21:32:07 [ℹ]  waiting for CloudFormation stack "eksctl-ferocious-mushroom-1669871447-nodegroup-ng-ee6f597f"
2022-12-13 21:32:38 [ℹ]  waiting for CloudFormation stack "eksctl-ferocious-mushroom-1669871447-nodegroup-ng-ee6f597f"
2022-12-13 21:33:25 [ℹ]  waiting for CloudFormation stack "eksctl-ferocious-mushroom-1669871447-nodegroup-ng-ee6f597f"
2022-12-13 21:35:11 [ℹ]  waiting for CloudFormation stack "eksctl-ferocious-mushroom-1669871447-nodegroup-ng-ee6f597f"
2022-12-13 21:36:11 [ℹ]  waiting for CloudFormation stack "eksctl-ferocious-mushroom-1669871447-nodegroup-ng-ee6f597f"
2022-12-13 21:37:52 [ℹ]  waiting for CloudFormation stack "eksctl-ferocious-mushroom-1669871447-nodegroup-ng-ee6f597f"
2022-12-13 21:39:09 [ℹ]  waiting for CloudFormation stack "eksctl-ferocious-mushroom-1669871447-nodegroup-ng-ee6f597f"
2022-12-13 21:39:10 [ℹ]  will delete stack "eksctl-ferocious-mushroom-1669871447-cluster"
2022-12-13 21:39:10 [✔]  all cluster resources were deleted

 

ㅁ 함께 보면 좋은 사이트

Amazon EKS에서 여러 CIDR 범위 사용

 

더 많은 호스트를 수용하도록 VPC의 CIDR 블록 수정

 

AWS신규 기능 테스트: VPC CIDR(/16) 추가 확장 - BESPINGLOBAL

커스텀 리소스

 

Amazon EKS의 kubelet 또는 CNI 플러그인 문제 해결