GKE 주소 관리: IPv4 주소 최적화

이 문서는 네트워크 설계자를 위한 시리즈의 일부입니다. 이 시리즈에서는 IPv4 주소를 제한하는 조직에 사용할 수 있는 Google Kubernetes Engine(GKE) 주소 관리 옵션을 설명합니다.

이 시리즈는 다음 문서로 구성됩니다.

이 문서에서는 GKE CIDR 블록 요구사항을 확인하는 프로세스를 설명합니다. 그런 다음 특정 시나리오에 권장되는 솔루션을 파악하는 데 도움이 되는 의사 결정 모델을 소개합니다. 마지막으로 다양한 솔루션을 간략하게 설명하고 각 솔루션의 장점과 단점을 살펴봅니다.

GKE CIDR 블록 요구사항 확인

이 섹션에서는 클러스터의 CIDR 블록 크기를 결정합니다. 클러스터를 생성한 후에는 CIDR 블록을 변경하거나 확장할 수 없으므로 크기를 올바르게 결정해야 합니다.

노드 CIDR 블록 크기 결정

다음 단계에 따라 노드 CIDR 블록 크기를 결정합니다.

  1. 클러스터에서 전체 기간 동안 필요한 최대 노드 수를 결정합니다.

    가능하다면 고객 애플리케이션, 설계, 성장 예측을 바탕으로 필요한 노드 수를 결정합니다. 필요한 최대 노드 수를 결정할 수 없다면 할당량 한도인 5,000 노드를 최댓값으로 사용합니다.

  2. 필요한 노드 수를 계산하는 데 필요한 호스트 비트를 결정합니다.

    필요한 노드 수를 알고 있으면 표 1을 사용하여 넷마스크를 생성하는 데 필요한 호스트 비트를 계산할 수 있습니다. 필요한 노드 열에서 필요한 노드 수를 찾습니다. 다음 단계를 진행할 때 노드 호스트 비트 열에 있는 해당 숫자를 사용합니다.

    필요한 노드 노드 호스트 비트
    1~4 3
    5~12 4
    13~28 5
    29~60 6
    61~124 7
    125~252 8
    253~508 9
    509~1020 10
    1,021~2,044 11
    2,045~4,092 12
    4,093~8,188 13

    표 1. 노드 주소에 필요한 비트

  3. 이전 단계에서 결정한 노드 호스트 비트 열의 숫자를 사용하여 CIDR 블록 넷마스크를 생성합니다.

    32–노드 호스트 비트=노트 CIDR 블록 넷마스크

    다음 그림은 이 수식을 그래픽으로 보여줍니다.

    노드 CIDR 블록 넷마스크

    예를 들어 표 1에 따르면 5,000 노드 클러스터의 경우 노드 넷마스크에 13 호스트 비트가 필요합니다. 전체 넷마스크를 계산하려면 수식 32–13=19에서 노드 호스트 비트를 해당 숫자로 바꾸면 됩니다. 결과는 넷마스크 /19입니다.

Pod CIDR 블록 크기 결정

다음 단계에 따라 Pod CIDR 블록 크기를 결정합니다.

  1. 클러스터에서 전체 기간에 필요한 노드당 최대 pod 수를 결정합니다.

    가능하다면 애플리케이션을 바탕으로 노드당 필요한 pod 수를 결정합니다. 필요한 최대 Pod 수를 결정할 수 없다면 할당량 한도인 노드당 pod 110개를 최댓값으로 사용합니다.

  2. 필요한 pod 수에 필요한 호스트 비트를 결정합니다.

    노드당 필요한 pod 수를 알고 있다면 표 2를 사용하여 넷마스크를 생성하는 데 필요한 호스트 비트를 계산할 수 있습니다. 노드당 pod 수 열에서 필요한 노드당 pod 수를 찾습니다. 다음 단계를 위해 해당 개수를 pod 호스트 비트 열에 사용합니다.

    노드당 pod 수 Pod 호스트 비트
    1~8 4
    9~16 5
    17~32 6
    33~64 7
    65~110 8

    표 2. 노드당 Pod에 필요한 비트

  3. 노드 CIDR 블록 크기 결정 섹션의 2단계에서 결정한 노드 호스트 비트 수와 이전 단계에서 결정한 pod 호스트 비트 수를 사용하여 CIDR 블록 넷마스크를 생성합니다.

    32–(노드 호스트 비트+pod 호스트 비트)=pod CIDR 블록 넷마스크

    다음 그림은 이 수식을 그래픽으로 보여줍니다.

    pod CIDR 블록 넷마스크

    예를 들어 노드당 Pod가 110개 필요하다면 노드당 pod 호스트 비트는 8이 필요합니다. 노드 호스트 비트(13)로 등식 32–(13+8)=11의 수를 대체하면 됩니다. 결과는 넷마스크 /11입니다.

클러스터 IP CIDR 블록 크기 결정

다음 단계에 따라 클러스터 IP 주소의 CIDR 블록 크기를 결정합니다.

  1. 클러스터에서 전체 기간 동안 필요한 최대 클러스터 IP 주소 수를 결정합니다.

    가능하다면 애플리케이션을 바탕으로 필요한 클러스터 IP 주소 수를 결정합니다. 필요한 최대 개수를 결정할 수 없다면 기본값인 /20 넷마스크를 사용합니다. 기본값 넷마스크를 사용한다면 다음 단계는 건너뛰어도 됩니다.

  2. 클러스터 IP 주소의 CIDR 블록에 대한 넷마스크를 결정합니다.

    필요한 클러스터 IP 주소 최댓값을 알고 있다면 표 3을 사용하여 넷마스크를 찾을 수 있습니다.

    클러스터 IP 주소 수 넷마스크
    1~32 /27
    33~64 /26
    65~128 /25
    129~256 /24
    257~512 /23
    513~1,024 /22
    1,025~2,048 /21
    2,049~4,096 /20
    4,097~8,192 /19
    8,193~16,384 /18
    16,385~32,768 /17
    32,769~65,536 /16

    표 3. 서비스의 CIDR 블록 넷마스크

주소 수요 이해

앞의 단계들에서 도출한 CIDR 블록 요구사항을 살펴보면 pod CIDR 블록이 IP 주소 공간에서 가장 큰 부분을 차지한다는 것을 알 수 있습니다. 대부분의 경우 노드 CIDR이 두 번째로 큰 부분을 차지하며, 서비스 CIDR 블록이 세 번째로 큰 부분을 차지합니다.

이제 클러스터 IP 주소 요구사항을 계산했으므로 사용 가능한 RFC 1918 IP 주소 공간을 검토하고 전달할 경로를 선택해야 합니다.

최적의 솔루션 선택

그림 1은 CIDR 블록 요구사항에 따라 최적의 솔루션을 결정하는 데 사용할 수 있는 의사 결정 트리를 보여줍니다. 솔루션 검토 섹션에는 각 솔루션이 요약되어 있습니다.

서비스 설정 예시 (화면에서 읽을 수 있는 PDF 버전을 보려면 이미지를 클릭하세요.)
그림 1. 서비스 설정 예시 (화면에서 읽을 수 있는 PDF 버전을 보려면 이미지를 클릭하세요.)

솔루션 검토

이 섹션에서는 각 솔루션과 사용 시점을 설명하고 장점, 단점, 기타 문제를 요약합니다.

사용 가능한 주소 공간 할당

사용 시점:

  • 사용 가능한 IP 주소 공간을 검토하고 그림 1을 살펴본 후 클러스터 CIDR 블록에 할당할 수 있는 RFC 1918 주소 공간이 충분하다고 결정했습니다. 예를 들어 10.0.0.0/8 주소는 고갈될 수 있지만 172.16.0.0/12 주소나 192.168.0.0/16 주소 공간에는 CIDR 블록 요구사항에 부합하는 공간이 충분합니다.

설명:

  • 이 솔루션에는 다른 특별한 구성 단계가 필요하지 않습니다. 주소 공간을 할당하고 설치를 계속합니다.

장점:

  • 가장 쉬운 솔루션입니다.
  • 특별한 구성이 필요하지 않습니다.

단점:

  • 사용 가능한 IP 주소 공간을 소모합니다.

기타 문제:

GKE pod CIDR 블록 번역

사용 시점:

  • 사용 가능한 IP 주소 공간을 검토하고 그림 1을 살펴본 후 노드 블록 할당에 사용할 수 있는 RFC 1918 주소 공간은 충분하지만 pod CIDR 블록을 위한 공간은 충분하지 않다고 결정했습니다. 따라서 pod CIDR 블록을 번역해야 하며 가능하면 서비스 CIDR 블록도 번역해야 합니다.

설명:

  • GKE 클러스터에서 pod CIDR 블록을 번역하려면 그림 2와 같이 ip-masquerade-agent 기능을 구현합니다. 이 기능은 pod IP 주소를 노드 IP 주소 뒤에 숨깁니다. 이러한 설계로 서비스 CIDR 블록에 CIDR 블록을 재사용할 수도 있습니다.

    GKE 클러스터의 Pod CIDR 블록 NAT (화면에서 읽을 수 있는 PDF 버전을 보려면 이미지를 클릭하세요.)
    그림 2. GKE 클러스터의 pod CIDR 블록 NAT (화면에서 읽을 수 있는 PDF 버전을 보려면 이미지를 클릭하세요.)

    이 아키텍처에는 다음과 같은 여러 구성요소가 있습니다.

    • NAT와 관련하여 CIDR 블록 특성을 설명하는 새로운 용어
    • ip-masquerade-agent 기능
    • 재사용된 RFC 1918 CIDR 블록
    • 온프레미스 연결 시 필터링

장점:

  • Pod CIDR을 위해 IPv4 주소 할당 로드블록을 줄입니다.
  • 지원 가능한 가장 큰 Pod CIDR 블록으로 확장합니다.
  • 전역 라우팅 테이블에서 재사용된 RFC 1918 CIDR 블록을 격리합니다.
  • 여전히 멀티 클러스터 Istio 메시를 만들 수 있습니다.
  • 여전히 네트워크 엔드포인트 그룹 구성을 만들 수 있습니다.

단점:

  • NAT를 사용하면 주소 테더링이나 로깅과 같이 해결해야 할 새로운 문제가 생깁니다.
  • VPC의 모든 리소스가 Pod CIDR 범위와 동일한 CIDR 범위에 할당된 온프레미스 리소스와 통신할 수 있는 것은 아닙니다. 이 문제는 서비스 범위를 재사용할 때 서비스 CIDR 블록을 공유하는 온프레미스 리소스에도 적용됩니다. 재사용된 CIDR 블록은 VPC의 로컬 경로로 표시되므로 VPC 외부로 라우팅되지 않습니다.

기타 문제:

  • GKE CIDR 블록에 재사용할 RFC 1918 CIDR 블록을 선택할 때는 주의해야 합니다.
  • 재사용된 RFC 1918 CIDR 블록을 온프레미스 네트워크에 다시 공지하지 마세요.
  • 재사용된 CIDR 블록은 VPC 라우팅 테이블에 있으므로 VPC 피어링 또는 VPN 연결을 사용할 때는 주의해야 합니다.

모든 GKE CIDR 블록 번역

사용 시점:

  • 사용 가능한 IP 주소 공간을 검토하고 그림 1을 살펴본 후 클러스터 Pod 또는 노드 CIDR 블록에 할당할 수 있는 RFC 1918 주소 공간이 충분하지 않다고 결정했습니다. 따라서 모든 CIDR 블록을 번역해야 합니다.

설명:

  • GKE 클러스터의 모든 CIDR 블록을 번역하려면 그림 3의 아키텍처를 구현합니다.

    GKE 클러스터의 모든 CIDR 블록 NAT (화면에서 읽을 수 있는 PDF 버전을 보려면 이미지를 클릭하세요.)
    그림 3. GKE 클러스터의 모든 CIDR 블록 NAT (화면에서 읽을 수 있는 PDF 버전을 보려면 이미지를 클릭하세요.)

    이 아키텍처에는 다음과 같은 여러 구성요소가 있습니다.

    • NAT와 관련하여 CIDR 블록 특성을 설명하는 새로운 용어
    • 재사용된 RFC 1918 CIDR 블록
    • 공유 네트워크가 있는 호스트 VPC
    • GKE 클러스터를 포함하는, 격리된 VPC라고 칭하는 서비스 VPC
    • NAT를 수행하며, 격리된 VPC와 호스트 VPC 모두에 네트워크 인터페이스가 있는 격리된 VPC 게이트웨이라고 칭하는 Compute Engine 인스턴스
    • 내부 부하 분산기 CIDR 블록의 개념
    • 트래픽을 적절하게 안내하는 두 VPC의 정적 경로
    • 온프레미스 연결 시 필터링

장점:

  • IPv4 주소 할당 로드블록을 줄입니다.
  • 지원 가능한 가장 큰 클러스터로 확장합니다.
  • 여러 클러스터에 쿠키 커터 복제를 허용합니다.
  • 전역 라우팅 테이블에서 재사용된 RFC 1918 CIDR 블록을 가장 우수하게 격리합니다.
  • 여전히 네트워크 엔드포인트 그룹 구성을 만들 수 있습니다.

단점:

  • 이전 솔루션보다 더 복잡합니다.
  • NAT를 사용하면 주소 테더링이나 로깅과 같이 해결해야 할 새로운 문제가 생깁니다.
  • 일부 배포에서는 멀티클러스터 Istio 메시를 사용할 수 없습니다.

기타 문제:

  • GKE CIDR 블록에 재사용할 RFC 1918 CIDR 블록을 선택할 때는 주의해야 합니다.
  • 재사용된 RFC 1918 CIDR 블록을 온프레미스 네트워크에 다시 공지하지 마세요.

다음 단계