포드의 영구 IP 주소 정보

이 문서에서는 Google Kubernetes Engine (GKE) 클러스터의 특정 포드에 하나 이상의 영구 IP 주소를 할당하여 안정적인 통신을 구성하는 방법을 설명합니다. 고가용성이 필요한 애플리케이션의 경우 빠른 장애 조치를 지원하거나 상태 점검 기반 부하 분산을 사용하도록 이러한 영구 IP 주소를 구성할 수도 있습니다.

커스텀 네트워크 주소 변환(NAT) 솔루션을 실행하는 특정 경우에는 NAT 솔루션이 연결을 시작하거나 수신할 때 발신 및 수신 연결 모두에 고정 영구 IP 주소가 필요할 수 있습니다. 또한 다른 시스템과 상호작용하는 방법 또는 비즈니스 요구사항에 따라 특정 유형의 요청을 처리하는 방법을 관리하기 위해 애플리케이션에 할당된 IP 주소를 제어해야 할 수도 있습니다.

기본적으로 포드는 인터페이스 IP 주소를 사용하여 트래픽을 이그레스합니다. 포드가 다시 시작되거나 이동될 때 인터페이스 IP 주소가 변경됩니다. 라우팅 통신을 더 세부적으로 제어하려면 GKE에서 포드의 영구 IP 주소를 수동으로 구성하면 됩니다.

이러한 IP 주소는 인터넷을 통해 통신할 외부 IP 주소이거나 Google Cloud네트워크 내에서 통신할 내부 IP 주소일 수 있습니다. Google에서 제공하는 IP 주소를 사용하거나 자체 IP 주소를 사용(BYOIP)할 수 있습니다.

GKE에서 포드의 영구 IP 주소를 구성하면 특정 포드가 영구 IP 주소로 트래픽을 주고받을 수 있도록 애플리케이션과 비즈니스 로직을 매핑할 수 있습니다.

다음 다이어그램에서는 여러 네트워크 인터페이스가 있는 포드가 기본 네트워크에서 계속 통신하면서 보조 네트워크의 영구 IP 주소를 사용할 수 있는 방법을 보여줍니다.

다중 네트워크 아키텍처
Multi-network-architecture

용어 및 개념

이 페이지에서는 다음 개념을 사용합니다.

상태 점검 기반 부하 분산

특정 라벨 선택기와 일치하는 여러 활성 포드에 영구 IP 주소의 트래픽을 분산하려면 상태 점검 기반 부하 분산을 사용하세요. 이 기능은 사용자가 만든 리전 상태 점검을 사용하여 포드를 지속적으로 모니터링하고 트래픽이 정상 엔드포인트로만 라우팅되도록 합니다. 영구 IP 주소에 대해 대기 (백업) 포드를 구성할 수도 있습니다. GKE는 모든 기본 활성 포드가 상태 확인에 실패하는 경우에만 이러한 대기 포드로 트래픽을 자동으로 분산합니다. 이 구성은 장애 발생 시 개별 포드가 과부하되는 것을 방지하고 지속적인 서비스 가용성을 보장합니다.

게이트웨이 클래스

영구 IP 주소 할당을 관리하는 게이트웨이 클래스는 다음과 같은 클래스로 제공됩니다.

  • 외부 IP 주소의 경우 gke-persistent-regional-external-managed
  • 내부(Google Cloud전용) IP 주소의 경우 gke-persistent-regional-internal-managed
  • 빠른 장애 조치 기능이 있는 외부 IP 주소의 경우 gke-persistent-fast-regional-external-managed
  • 빠른 장애 조치가 있는 내부 (Google Cloud전용) IP 주소의 경우 gke-persistent-fast-regional-internal-managed

상태 점검 기반 부하 분산에는 다음 게이트웨이 클래스가 적용됩니다.

  • 여러 포드 간에 공유되는 내부 (Google Cloud전용) 영구 IP 주소의 경우 gke-passthrough-lb-internal-managed
  • 여러 포드 간에 공유되는 외부 고정 IP 주소의 경우 gke-passthrough-lb-external-managed

    게이트웨이 클래스는 특정 리전 내에서 작동합니다. 게이트웨이 클래스는 기본 IP 주소 관리를 제공하며 레이어 3 (L3) 네트워크 라우팅에 중점을 둡니다.

다음 표에서는 각 게이트웨이 클래스의 기능을 비교합니다.

기능 gke-persistent-* 게이트웨이 클래스 gke-passthrough-lb-* 게이트웨이 클래스
기본 목표 단일 워크로드의 영구 IP 주소입니다. 여러 워크로드에 걸친 부하 분산
광고 모음 매핑 1:1 (가장 최근에 생성된 일치하는 Pod로 라우팅) 1:N (정상 상태의 일치하는 모든 포드에 트래픽을 분산)
상태 확인 라우팅 결정에는 지원되지 않음 필수 (리전 상태 점검 사용)
백업 포드 지원되지 않음. 지원됨 (장애 조치를 위해 대기 포드 사용)
장애 조치 속도 표준 또는 빠른 (*-fast-* 클래스 사용) 상태 점검 매개변수로 구성 가능

게이트웨이 객체

게이트웨이 객체는 영구 IP 주소를 관리하고 구성하는 중앙 지점 역할을 합니다. GKE의 게이트웨이 객체는 영구 IP 주소 풀을 관리합니다. 이러한 주소를 나열하고 이러한 IP 주소를 GKEIPRoute에 할당되는 규칙을 정의합니다.

리스너

리스너는 GKE 게이트웨이 구성의 일부로, 게이트웨이가 보유한 영구 IP 주소를 사용할 수 있는 게이트웨이 네임스페이스의 포드를 제어합니다. 리스너를 사용하면 유연성과 보안을 위해 액세스를 맞춤설정할 수 있습니다. 각 리스너에는 고유한 이름이 필요하며 네임스페이스(전체, 라벨 기반 또는 게이트웨이의 네임스페이스만)를 기준으로 액세스를 필터링할 수 있습니다.

GKEIPRoute 객체

GKEIPRoute 객체는 GKE 클러스터의 특정 포드에 영구 IP 주소를 할당하도록 구성하는 커스텀 리소스입니다. GKEIPRoute 객체의 상태 섹션을 사용하여 영구 IP 주소 설정을 모니터링할 수 있습니다. 이 설정은 다음 필드를 통해 주요 정보를 제공합니다.

  • 포드

    포드 필드에는 영구 IP 주소에 연결된 포드의 정확한 이름이 표시됩니다. 단일 포드는 영구 IP 주소를 여러 개 사용할 수 있습니다.

  • 조건

    조건 필드는 외부 IP 주소 설정이 올바르게 작동하는지 알려주며 구성이 유효하지 않은 경우 문제를 진단하는 데도 도움이 됩니다. 다음과 같은 네 가지 조건이 있습니다.

    • Accepted: GKEIPRoute 리소스 사양이 유효한지 나타냅니다. 구성에 오류가 있으면 Accepted 조건이 이유와 함께 False입니다.
    • GCPReady: Google Cloud 가 필요한 모든 리소스를 준비했음을 나타냅니다. Google Cloud 리소스 프로비저닝 프로세스 중에 발생한 오류는 GCPReady 조건의 상태에 반영됩니다.
    • DPV2Ready: 구성된 영구 IP 주소에서 네트워크 연결을 허용하도록 데이터 경로가 준비되고 프로그래밍된 경우와 같은 데이터 경로 프로그래밍의 상태를 나타냅니다.
    • Ready: 영구 IP 주소 설정이 유효하고 작동함을 나타냅니다. 애플리케이션이 영구 IP 주소를 사용하도록 구성한 경우 포드에 연결할 수 있습니다. 이전의 다른 세 조건도 모두 True인 경우 True으로 설정됩니다.
  • nodeSelector

    빠른 장애 조치를 사용하는 경우 nodeSelector 필드를 사용하여 빠른 장애 조치를 위해 미리 구성된 노드를 지정해야 합니다. 이렇게 하면 장애 조치 발생 시 영구 IP 주소가 있는 지정된 노드에서 새 포드를 빠르게 온라인 상태로 전환할 수 있습니다. 이러한 노드에서 영구 IP 주소를 사용하여 포드를 예약해야 합니다. 일반적으로 포드의 nodeSelector를 사용하여 노드의 라벨을 일치시켜 이를 수행합니다. 빠른 장애 조치를 구성할 때는 nodeSelector 필드를 사용하고 지정된 라벨이 64개 이상의 노드를 선택하지 않는지 확인합니다.

다음 필드는 상태 점검 기반 부하 분산에만 적용됩니다.

  • loadBalancing: 포드의 상태를 모니터링하는 리전 상태 점검 이름을 지정합니다.
  • backupPodSelector: 모든 기본 포드가 비정상인 경우 트래픽을 수신하는 포드 집합을 정의합니다.

반응 모드

반응 모드는 영구 IP 주소에 연결된 포드가 노드 간 이동 또는 새로 생성된 일치하는 포드를 사용할 수 있게 될 때와 같은 변경 사항이 발생할 때 시스템의 동작 방식을 결정합니다. 반응 모드를 사용하여 포드가 변경되더라도 영구 IP 주소를 계속 사용할 수 있습니다.

반응 모드는 다음 중 하나입니다.

  • ReadyCondition

    ReadyCondition 모드에서 영구 IP 주소 시스템은 포드 상태를 우선시합니다. 영구 IP 주소 시스템은 지정된 라벨과 일치하고 Kubernetes 상태 프로브를 통과하여 Ready 상태를 True로 표시한 포드에만 IP 주소를 할당합니다. 이 모드는 영구 IP 주소를 수신하는 포드가 수신 및 발신 트래픽을 처리할 준비가 완전히 되어야 하는 애플리케이션에 적합합니다.

  • 존재

    Exists 모드는 포드 유무를 우선시합니다. 영구 IP 주소는 포드가 구성의 라벨과 일치하고 클러스터의 특정 노드에 스케줄링된 경우 포드에 연결됩니다. 이는 포드가 존재하고 실행할 위치가 지정되었음을 의미합니다. 이 모드는 영구 IP 주소의 빠른 할당이 엄격한 준비보다 우선시되는 시나리오 또는 즉각적인 연결이 전체 애플리케이션 상태보다 중요한 개발 및 테스트와 같은 환경에 적합합니다.

StatefulSet

StatefulSets는 안정적인 식별자와 영구 스토리지가 필요한 애플리케이션을 위해 설계된 Kubernetes 워크로드 유형입니다. StatefulSet 내의 포드에는 예측 가능한 이름이 있습니다(예: my-app-0, my-app-1).

배포

Deployments는 일반적으로 포드가 상호 교환 가능한 스테이트리스(Stateless) 애플리케이션을 관리하기 위한 Kubernetes 워크로드 유형입니다. 배포 내 포드 이름을 완전히 예측할 수 없습니다.

사용 사례

GKE 포드의 영구 IP 주소는 GKE에서 네트워크 관련 애플리케이션을 실행하는 네트워크 및 보안 서비스 제공업체의 여러 사용 사례를 해결합니다.

GKE 포드의 영구 IP 주소는 다음 사용 사례를 해결합니다.

  • NAT 제어: 네트워크 기능을 실행하는 포드에 영구 IP 주소를 할당하면 아웃바운드 트래픽에 사용되는 소스 IP 주소를 세밀하게 제어할 수 있습니다. 이를 통해 독점 NAT 로직을 통합할 수 있습니다.
  • 전용 IP 주소 풀: 전용 IP 주소를 사용하면 특정 주소를 개별 5G 코어 포드에 일치시켜 전문 공급업체 소프트웨어와의 호환성을 보장할 수 있습니다.
  • 신뢰할 수 있는 트래픽 흐름: 반환 트래픽이 같은 네트워크 함수를 통해 다시 라우팅되어야 하므로 영구 IP 주소를 사용하면 외부 시스템이 통신 중단 없이 올바른 포드를 인식하고 응답할 수 있습니다.
  • 시간에 민감한 애플리케이션의 고가용성: 통신 업계와 같이 엄격한 가동시간 요구사항이 있는 애플리케이션의 경우 빠른 장애 조치와 함께 영구 IP 주소를 사용하여 장애 발생 시 트래픽을 정상 포드로 빠르게 리디렉션할 수 있으므로 다운타임을 몇 초로 최소화할 수 있습니다.
  • 부하 분산: 상태 점검 기반 부하 분산을 사용하면 GKE가 단일 인스턴스의 과부하를 방지하기 위해 여러 활성 포드에 트래픽을 분산합니다. 정상 포드를 사용할 수 없는 경우 다른 네임스페이스나 노드에 백업 포드를 구성할 수 있습니다.

이점

GKE 포드의 영구 IP 주소는 다음과 같은 이점을 제공합니다.

  • 외부 ID: 포드에 외부 영구 IP 주소를 제공하면 포드가 클러스터 내에서 다시 시작되거나 이동되더라도 외부 시스템에서 해당 포드에 일관되게 연결할 수 있습니다. 이는 외부에서 검색 가능한 엔드포인트가 필요한 서비스에 유용합니다.
  • 안정적인 통신: 특정 IP 주소가 있는 다른 리소스에 의존하는 애플리케이션은 영구 IP 주소를 사용하여 안정적으로 연결을 설정할 수 있습니다. 영구 IP 주소는 하드코딩된 IP 주소 종속 항목이 있는 기존 시스템이나 애플리케이션에 중요합니다.
  • 레거시 마이그레이션: 레거시 마이그레이션은 전환 프로세스 중 특정 IP 주소를 사용하는 애플리케이션을 마이그레이션하는 데 도움이 될 수 있습니다.
  • BYOIP: BYOIP는 이미 소유하고 있는 특정 IP 주소 범위를 GKE 클러스터 내에서 사용하여 제어를 유지할 수 있게 해줍니다.
  • 애플리케이션 업타임 개선: 빠른 장애 조치 기능을 사용하면 포드 장애 발생 시 다운타임을 몇 초로 최소화하여 중요한 애플리케이션의 업타임을 크게 개선할 수 있습니다.
  • 자동 장애 조치를 통한 고가용성: 기본 포드가 상태 점검에 실패하면 트래픽을 정상 대기 포드로 자동 리디렉션하여 서비스 가용성을 달성합니다.

다음 단계