EKS 및 IP 주소 탐색: 보조 CIDR 범위 및 전용 NAT 게이트웨이

9857 단어 devopseksvpcaws

EKS 및 IP 주소에 대한 요구
Kubernetes에서는 다양한 워크로드를 유사한 방식으로 실행할 수 있습니다.사용자의 측면에서 볼 때 한 노드에서 두 개의pod(각pod당 2개의 vCPU 소모)를 운행하는 것과 몇 십 개의pod(각pod당 0.05개의 vCPU 소모)를 운행하는 것은 별 차이가 없다.그러나 네트워크를 보면 큰 차이가 있다. 모든pod는 유일한 IP 주소가 필요하다.대부분의 Kubernetes 구현에는 CNI 플러그인이 있습니다. 그룹 내부의 IP 공간에서 모든pod에 IP 주소를 할당할 수 있습니다.
AWS가 관리하는 Kubernetes 제품인 EKS by default은 Amazon VPC CNI plugin for Kubernetes을 사용합니다.대부분의 네트워크와 달리 이것은 VPC(노드가 있는 네트워크)에서 각pod에 전용 IP 주소를 분배한다.
VPC CNI 플러그인 1의 역할은 다음과 같습니다.
  • 은 각 노드에 대량의 네트워크 인터페이스(ENI)와 IP 주소를 따뜻하게 유지하여 IP 주소를 새로운 POD에 신속하게 분배할 수 있도록 한다.
  • 은 기본적으로 전체 예비 에니를 보온합니다.
  • 은 모든 노드가 사실상 2 ENIs * ips-per-ENI을 성명한다는 것을 의미한다. 왜냐하면 최소한 하나의 수호 프로그램이 첫 번째 ENI의 IP 주소를 성명하기 때문이다.
    • 지금 list of available IP addresses per ENI을 보고 하나의 예를 계산하면 다음과 같습니다.
  • EC2 유형 m5.xlarge, 각 ENI에는 15개의 IP 주소가 있습니다.노드당 최소 30개의 IP 주소가 있어야 합니다.
  • 예를 들어 우리는 50개의 노드가 운행하고 있다.1500개의 개인 주소입니다.(투시도: 필요에 따라 EC2로 매달 약 7000달러를 계산한다).
    • 예를 들어 우리는 /21개의 VPC를 가지고 3개의 /23개의 개인 서브넷을 제공한다.3 x 512 = 1536개의 사용 가능한 IP 주소입니다.
  • 관리형 서비스에는 IP 주소가 필요합니다.
    • 우리는 이것이 어떻게 된 일인지 볼 수 있다.그렇다면 /16개의 전용 네트워크를 만드는 것은 무엇일까?이 가능하다, ~할 수 있다,...

    다중 독점 네트워크
    많은 조직에서 독점 네트워크만 있는 것은 아니다.네트워크 환경은 다음과 같은 요소의 조합일 수 있습니다.
  • 하나 이상의 지역에서 여러 AWS 계정 및 VPC
  • 데이터 센터
  • 사무용 네트워크
    • AWS 이외의 공급업체의 DBAA와 같은
  • 피어 서비스
    전용 네트워크 및 기타 네트워크에 many ways개 접속할 수 있습니다.독점 네트워크의 외부 라우팅이 필요한 CIDR 범위가 클수록 중첩 가능성이 커집니다.
    따라서 비교적 큰 조직에서 개인 AWS 계정은 보통 한 VPC가 제공하고 CIDR의 범위가 상대적으로 작으며 비교적 큰 네트워크 계획에 적합하다."대량의 IP"를 유지하기 위해 AWS VPC can be configured with에는 보조 CIDR 범위가 있습니다.
    이것은 IP 공간 문제를 해결했지만 그 자체로 루트 문제를 해결할 수 없다.두 번째 CIDR 시리즈는 전체 네트워크 환경에서 독점 네트워크 외부에서 라우팅하기 위해 고유해야 합니다.보조 CIDR의 워크로드가 VPC 내의 리소스에 연결되기만 하면 문제가 되지 않을 수 있지만 일반적으로 그렇지 않습니다.
    최근 미국용접학회(AWS)는 맞춤형 네트워크와 함께 차급 CIDR 시리즈에서 라우팅 가능한 EKS 크레인을 촉진하는 Private NAT gateways을 출시했다.

    독점 네트워크 설정
    EKS를 실행하는 방법에 대해 설명하는 VPC 설정을 살펴보겠습니다.

    기본적
    기본적인 VPC는 CIDR 시리즈, 개인 및 공공 서브넷, NAT 게이트웨이, 인터넷 게이트웨이로 구성되어 있다.주요 CIDR 범위의 크기에 따라 충분할 수 있지만, 비교적 큰 조직 범위 내에서 비교적 작은 CIDR 범위를 가정해 봅시다.
  • Professional: Simple
  • Con: 개인 IP 사용량

    • 보조 CIDR 시리즈
    다음: 보조 CIDR 범위를 추가하고 보조 서브넷에 노드 및 POD를 배치합니다.전용 네트워크 이외의 전용 네트워크에 연결된 자원이 작업 부하에 영원히 필요하지 않다면, 이것은 작용할 수 있으며, 이것은 불가능하다.이론적으로 POD는 다른 VPC에 패키지를 보낼 수 있지만 되돌아오는 경로가 없다.
  • Professional: Simple
  • Con: VPC
    • 이외의 POD와 개인 리소스 사이에 라우팅 없음

    보조 CIDR 시리즈 + 맞춤형 네트워크
    라우팅 문제를 해결하기 위해 VPC CNI 플러그인에서 사용자 정의 네트워크를 활성화할 수 있습니다.이것은 노드와 크레인을 서로 다른 서브넷에 놓을 수 있도록 허용한다.노드는 메인 사유 서브넷에 들어가고 크레인은 보조 사유 서브넷에 들어간다.기본적으로 외부 네트워크로의 데이터에 대해 CNI 플러그인은pods IP 주소를 노드의 주 IP 주소(SNAT)로 변환하기 때문에 루트 문제를 해결했다.이 설정에서 이러한 노드는 라우팅 가능한 서브넷에 있습니다.

    AWS knowledge center과 Amazon EKS Workshop에는 보조 CIDR 범위 설정 및 사용자 정의 네트워크가 설명되어 있습니다.
    소스 네트워크 주소 변환 is disabled when using security groups for pods 2:

    Source NAT is disabled for outbound traffic from pods with assigned security groups so that outbound security group rules are applied. To access the internet, pods with assigned security groups must be launched on nodes that are deployed in a private subnet configured with a NAT gateway or instance. Pods with assigned security groups deployed to public subnets are not able to access the internet.

  • Pro: 추가 NAT 게이트웨이 필요 없음
  • Con: 복잡한 독점 네트워크 CNI 네트워크 구성
  • Con: POD
    • 보안 그룹과 호환되지 않음

    보조 cidr+ 전용 NAT 게이트웨이
    사용자 지정 네트워크를 구성하는 것 외에 전용 NAT 게이트웨이를 사용하여 라우팅 문제를 해결할 수도 있습니다.공용 NAT 게이트웨이와 달리 전용 서브넷에 위치하며 인터넷 게이트웨이와 연결되지 않습니다.
    이렇게 하면 노드와 POD는 보조 CIDR 범위 내에서 운행할 수 있고 루트 문제는 EKS 밖에서 해결할 수 있다.
  • Pro: 직접 기본 VPC CNI 네트워크 구성
  • Pro: 보안 그룹과 함께 POD
  • Con: NAT 게이트웨이 생성 비용

    • 경로 선택과 원가 제어

    NAT 게이트웨이 하나면 충분합니다.
    보조 사설 서브넷에 대해 설정할 수 있는 가장 기본적인 라우팅 테이블을 살펴보겠습니다.
    10.150.40.0/21  local   
100.64.0.0/16   local   
0.0.0.0/0       nat-<private-id>
    이것은 모든 비VPC 데이터를 메인 전용 서브넷에 넣고 거기에 설정된 루트표가 나머지 작업을 완성하도록 합니다.간단하지만 노드의 인터넷 연결을 테스트할 때 우리는 함정 3을 관찰할 수 있다.
    [ec2-user@ip-100-64-43-196 ~]$ ping www.google.com
PING www.google.com (74.125.193.147) 56(84) bytes of data.
64 bytes from ig-in-f147.1e100.net (74.125.193.147): icmp_seq=1 ttl=49 time=2.31 ms
^C

[ec2-user@ip-100-64-43-196 ~]$ tracepath -p 443 74.125.193.147
 1?: [LOCALHOST]                                         pmtu 9001
 1:  ip-10-150-42-36.eu-west-1.compute.internal            0.168ms
 1:  ip-10-150-42-36.eu-west-1.compute.internal            1.016ms
 2:  ip-10-150-40-116.eu-west-1.compute.internal           0.739ms
 3:  ip-10-150-40-1.eu-west-1.compute.internal             1.510ms pmtu 1500
 3:  no reply
^C
    추적 및 기존 NAT 게이트웨이를 살펴보면 트래픽이 전용 및 NAT 게이트웨이를 통과하는 것을 확인할 수 있습니다.

    세심한 관찰자들은 유량도 속의 녹색선이 전용 NAT 스위치를 돌고 있다는 것을 이미 알아차렸을 것이다.이를 위해서는 전용 네트워크 트래픽을 전용 NAT 게이트웨이로 지정하여 라우팅 테이블을 조정하기만 하면 됩니다.
    10.150.40.0/21  local   
100.64.0.0/16   local   
10.0.0.0/8      nat-<private-id>
0.0.0.0/0       nat-<public-id>
    NAT 게이트웨이를 통과하는 트래픽을 절반으로 줄이는 것은 비용을 절반으로 줄이는 것이다(NAT 게이트웨이의 고정 비용은 무시).

    VPC 엔드포인트 및 피어 연결
    위에서 설명한 바와 같이 VPC 단점과 대등한 연결을 복제하는 루트 테이블 항목(주요 개인 서브넷에 존재)은 불필요한 데이터가 개인 NAT 스위치를 통과하는 것을 피하기 위해 매우 중요하다.그것은 작용할 수 있지만 불필요한 원가를 가져올 수 있다.
    알림: DNS, 루트, 보안 그룹인 행성을 정렬해야 하기 때문에, VPC에 존재하는 '인터페이스' 유형의 모든 VPC 단점에 보조 CIDR 범위 접근 권한을 부여하십시오.그렇지 않으면 DNS는 전용 NAT 게이트웨이를 통해 VPC 엔드포인트의 보안 그룹에 의해 차단되는 VPC 로컬 IP 주소를 반환합니다.

    총결산
    2단계 CIDR 범위 내에서 EKS POD를 실행할 때 전용 NAT 게이트웨이는 사용자 정의 네트워크를 대체할 수 있습니다.다음과 같은 몇 가지 균형을 고려해야 합니다.
  • 전송 및 전용 NAT 게이트웨이를 통한 네트워크 트래픽
  • POD용 보안 그룹 기능
  • 설치의 복잡성
    • 이상의 내용은 EKS 네트워크 세계에 견해를 제공하고 무엇을 더 깊이 조사하고 어떤 함정을 피하는지에 대한 지도를 제공할 것으로 보인다.예전과 같이 언제든지 토론해 주십시오!
    이 블로그는 https://betterprogramming.pub/amazon-eks-is-eating-my-ips-e18ea057e045 ↩
    면책 성명: 우리는 아직 POD를 위해 안전팀을 사용하지 않았기 때문에 이것은 이론적인 것이다.그러나 설명한 NAT 없음 = 인터넷 라우팅 없음 논리에 따라 외부 전용 네트워크에 비슷한 제한이 적용된다고 가정할 수 있습니다.  ↩
    NAT 게이트웨이를 더 많이 사용해야 하는 경우에는 큰 문제가 될 수 있으며 장애가 발생할 수 있습니다.  ↩
    인터넷 강의 방문 량

    좋은 웹페이지 즐겨찾기

    개발자 우수 사이트 수집

    개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
    best100-homepage