상태 점검 기반 부하 분산 구성

표준

이 문서에서는 상태 점검 기반 부하 분산을 사용하여 Google Kubernetes Engine (GKE)에서 영구 IP 주소의 고가용성을 구현하는 방법을 보여줍니다. 표준 영구 IP 구성은 단일 영구 IP 주소를 단일 포드에 매핑하지만 상태 점검 기반 부하 분산을 사용하면 하나 이상의 영구 IP 주소에서 발생하는 트래픽을 정상 포드 풀에 분산할 수 있습니다.

특정 영구 IP 주소를 요청하고 트래픽을 수신하는 포드를 식별하려면 GKEIPRoute 커스텀 리소스를 만듭니다. GKEIPRoute 리소스를 리전별 상태 확인과 통합하면 GKE가 네트워킹 레이어에서 워크로드를 모니터링하고 트래픽을 수신할 준비가 된 포드로만 라우팅합니다. GKEIPRoute 객체를 사용하여 선택적 백업 포드를 지정할 수도 있습니다. 모든 기본 활성 포드가 상태 확인에 실패하면 GKE는 이러한 대기 포드로만 트래픽을 라우팅합니다.

요구사항 및 제한사항

상태 확인 기반 부하 분산을 사용하려면 클러스터가 GKE 버전 1.32.3-gke.1440000 이상이어야 합니다. GKE는 버전 1.35.0-gke.1403000 이상에서만 백업 포드 선택을 지원합니다.
클러스터에 GKE Dataplane V2 및 Gateway API가 사용 설정되어 있어야 합니다.
단일 GKEIPRoute 객체는 노드당 일치하는 포드 하나만 지원합니다. 노드의 여러 포드가 GKEIPRoute의 포드 선택기와 일치하는 경우 GKE는 해당 노드에서 가장 최근에 생성된 포드를 선택합니다.
GKEIPRoute 객체를 만든 후에는 게이트웨이 클래스를 수정할 수 없습니다.
상태 점검 기반 부하 분산은 워크로드 외부에서 시작된 트래픽만 지원합니다. 워크로드 내에서 영구 IP 주소로 시작된 트래픽은 지원되지 않습니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

Google Kubernetes Engine API를 사용 설정합니다.

Google Kubernetes Engine API 사용 설정

이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치했으면 gcloud components update 명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
참고: 기존 gcloud CLI 설치의 경우 compute/region 속성을 설정해야 합니다. 주로 영역 클러스터를 사용하는 경우에는 대신 compute/zone을 설정합니다. 기본 위치를 설정하면 gcloud CLI에서 One of [--zone, --region] must be supplied: Please specify location과 같은 오류를 방지할 수 있습니다. 클러스터의 위치가 설정한 기본값과 다른 경우 특정 명령어에서 위치를 지정해야 할 수 있습니다.

IP 주소에 대해 알아봅니다.

상태 점검 기반 부하 분산 구현

이 섹션에서는 상태 점검 기반 부하 분산을 구현하기 위한 워크플로를 요약합니다.

리전별 상태 점검 만들기: GKE가 Pod 상태를 모니터링하는 데 사용하는 매개변수를 정의합니다. 이 객체는 네트워킹 레이어에 영구 IP 주소에서 트래픽을 수신할 수 있는 정상 엔드포인트를 알려줍니다.
클러스터 만들기: GKE Dataplane V2 및 Gateway API가 사용 설정된 GKE 클러스터를 설정합니다. 이러한 구성요소는 영구 IP 라우팅과 상태 점검 기반 부하 분산을 관리하는 데 필요한 기본 인프라를 제공합니다.
IP 주소 예약: 클러스터와 동일한 리전에서 고정 내부 또는 외부 IP 주소를 선택하고 예약합니다. 이 주소는 GKE가 활성 또는 백업 포드 풀에 분산하는 영구 진입점 역할을 합니다.
게이트웨이 만들기: 예약된 영구 IP 주소를 관리하도록 게이트웨이 객체를 구성합니다. GKEIPRoute 객체는 워크로드의 게이트웨이에서 특정 IP 주소를 클레임하고 사용합니다.
GKEIPRoute 객체 만들기: 라벨 선택기를 사용하여 영구 IP 주소를 포드 그룹에 매핑하는 라우팅 규칙을 정의합니다. 이 객체 내에서 리전 상태 점검을 참조하고 필요에 따라 장애 조치 시나리오의 백업 Pod를 지정합니다.
일치하는 엔드포인트 보기: 자동으로 생성된 EndpointSlice를 검사하여 GKE가 활성 및 백업 포드를 올바르게 식별했는지 확인합니다. 이 단계에서는 라벨이 예상 포드와 일치하고 네트워킹 레이어가 트래픽을 라우팅할 준비가 되었는지 확인합니다.

1단계: 리전 상태 확인 및 방화벽 규칙 만들기

리전별 상태 점검을 만들려면 상태 점검 만들기의 단계를 따르세요. 여기에 입력한 이름은 GKEIPRoute 구성에 사용됩니다. 예를 들면 다음과 같습니다.

gcloud compute health-checks create http reg-lb-hc \
    --region=us-central1 \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2

Google Cloud 의 상태 점검 프로브가 노드에 도달하도록 하려면 방화벽 규칙을 만들어야 합니다.

2단계: GKE 클러스터 만들기

Gateway API 및 GKE Dataplane V2가 사용 설정된 클러스터를 만듭니다. 예를 들면 다음과 같습니다.

gcloud container clusters create cluster-1 \
    --enable-dataplane-v2 \
    --gateway-api=standard \
    --region=us-central1

클러스터의 기본 VPC 네트워크와 다른 VPC 네트워크에서 GKEIPRoute 객체를 구성하는 경우 다중 네트워크 기능이 있는 GKE 클러스터를 만들어야 합니다. 자세한 내용은 포드에 대한 다중 네트워크 지원 설정을 참고하세요.

3단계: IP 주소 예약

워크로드에 사용할 IP 주소를 예약합니다. Google 제공 IP 주소를 예약하거나 자체 IP 주소를 사용(BYOIP)하도록 선택할 수 있습니다.

3a단계: Google 제공 IP 주소 예약

외부 IP 주소를 예약하려면 다음 명령어를 실행합니다.

gcloud compute addresses create ADDRESS_NAME \
   --region=REGION

다음을 바꿉니다.

ADDRESS_NAME: 이 주소와 연결할 이름
REGION: 이 주소를 예약할 리전. 이 리전은 IP 주소를 연결하려는 포드와 같은 리전이어야 합니다.

참고: 영구 IP 주소의 트래픽 라우팅을 처리하는 전달 규칙이 리전에 해당하기 때문에 IP 주소를 예약할 때 리전을 지정해야 합니다. 라우팅이 제대로 작동하려면 IP 주소와 GKE 클러스터가 같은 리전에 있어야 합니다.

내부 IP 주소를 예약하려면 다음 명령어를 실행합니다.

gcloud compute addresses create ADDRESS_NAME \
    --region REGION
    --subnet SUBNETWORK \
    --addresses IP_ADDRESS

다음을 바꿉니다.

ADDRESS_NAME: 예약하려는 주소 하나 이상의 이름. 주소가 여러 개인 경우 모든 주소를 공백으로 구분하여 목록으로 지정합니다. 예를 들면 example-address-1 example-address-2 example-address-3입니다.
REGION: 이 요청의 리전
SUBNETWORK: 이 내부 IPv4 주소의 서브넷
IP_ADDRESS: 선택한 서브넷의 기본 IP 주소 범위에서 사용되지 않은 내부 IP 주소입니다.

비공개 네트워크 내에서 트래픽이 올바르게 라우팅되게 하려면 내부 IP 주소가 클러스터의 기본 서브넷이나 추가 네트워크 서브넷에 속해야 합니다.

외부 및 내부 IP 주소에 대한 자세한 내용이나 Google Cloud 콘솔을 사용하여 주소를 예약하는 방법을 알아보려면 고정 외부 IP 주소 예약 및 고정 내부 IP 주소 예약을 참고하세요.

3b단계: 자체 IP 주소 사용 (BYOIP)

Google 제공 IP 주소를 사용하는 대신 자체 IP 주소를 사용(BYOIP)할 수 있습니다. BYOIP는 애플리케이션에 특정 IP 주소가 필요하거나 기존 시스템을 Google Cloud로 이동하는 경우에 유용합니다. BYOIP를 사용하기 위해 Google에서 개발자가 IP 주소 범위를 소유하고 있는지 검증합니다. IP 주소를 Google Cloud로 가져온 후에는 개발자가 이 IP 주소를 GKE 포드의 IP 주소로 할당할 수 있습니다. 자세한 내용은 자체 IP 주소 사용을 참고하세요.

4단계: Gateway 객체 만들기

L3 네트워크 유형만 지원하는 다음 게이트웨이 클래스 중 하나를 사용하여 게이트웨이를 만듭니다.

gke-passthrough-lb-external-managed 또는
gke-passthrough-lb-internal-managed.

다음 예에서는 외부 IP 주소 풀을 관리하는 게이트웨이를 정의합니다.

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: lb-gateway
spec:
  gatewayClassName: gke-passthrough-lb-external-managed

  listeners:
    - name: default
      port: 443
      protocol: none
      allowedRoutes:
        namespaces:
          from: All

  addresses:
    - value: "34.123.10.1/32"
      type: "gke.networking.io/cidr"
    - value: "34.123.10.2/32"
      type: "gke.networking.io/cidr"

위 예시에서 다음 필드에 유의하세요.

addresses: 특정 게이트웨이에서 권한을 관리하는 모든 IP 주소 범위를 나열합니다.
listeners: GKEIPRoute 객체가 이 Gateway를 참조할 수 있는 네임스페이스를 식별합니다.

리스너 사용에 관한 자세한 내용은 게이트웨이 객체 만들기를 참고하세요.

5단계: 부하 분산 및 상태 점검 구성으로 GKEIPRoute 객체 만들기

기본 및 백업 포드 선택기를 정의하고 1단계에서 만든 상태 점검을 연결하는 GKEIPRoute 객체를 만듭니다.

kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
  namespace: default
  name: my-ip-route
spec:
  parentRefs:
  - name: lb-gateway
  addresses:
  - value: "34.123.10.1/32"
    type: "gke.networking.io/cidr"
  - value: "34.123.10.2/32"
    type: "gke.networking.io/cidr"
  network: default
  podSelector:
    matchLabels:
      component: activePodSelector

  loadBalancing:
    healthCheckName: "reg-lb-hc"
    backupPodSelector:
      namespaceSelector:
        matchLabels:
          environment: test
          dc: us-central
      podSelector:
        matchLabels:
          component: backupPodSelector
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: proxy-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: proxy
  template:
    metadata:
      # annotations:  <- Include these lines if the pods are multi-nic pods
      #   networking.gke.io/default-interface: 'eth0'
      #   networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}]'
      labels:
        component: proxy
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

다음에 유의하세요.

podSelector: 정의된 영구 IP 주소에서 트래픽을 수신하는 기본 활성 포드를 식별합니다. 이 필드는 라벨을 사용하여 GKEIPRoute 리소스와 동일한 네임스페이스 내의 포드를 일치시킵니다. GKE는 이 선택기와 일치하는 모든 정상 포드에 트래픽을 분산합니다. 일치하는 포드가 동일한 노드에 여러 개 있는 경우 GKE는 트래픽을 수신할 가장 최근에 생성된 포드만 선택합니다. 여기에 정의된 라벨은 backupPodSelector 필드의 라벨과 중복되어서는 안 됩니다. 이 필드를 변경할 수 있습니다.
backupPodSelector: podSelector 객체와 일치하는 모든 기본 포드가 상태 점검에 실패하는 경우에만 트래픽을 수신하는 대기 포드를 정의합니다. 이 선택기에는 다음이 포함됩니다.
- namespaceSelector: GKE가 이러한 백업 포드를 찾기 위해 검색하는 네임스페이스를 결정합니다. 라벨 선택기를 사용하여 특정 네임스페이스로 검색을 제한할 수 있습니다. 이 필드가 생략되거나 비어 있으면 GKE는 클러스터의 모든 네임스페이스에서 백업 포드를 찾습니다.
- podSelector: 라벨을 기반으로 백업 포드를 일치시킵니다. 이러한 라벨은 기본 podSelector 객체에 사용된 라벨과 달라야 합니다.

이 매니페스트의 다른 필드에 대한 자세한 내용은 GKEIPRoute 객체 만들기를 참고하세요.

6단계: 포드 내에서 할당된 IP 주소 사용

GKEIPRoute 객체를 사용하여 GKE 포드에 IP 주소를 할당해도 애플리케이션에서 자동으로 IP 주소를 사용할 수 있게 되는 것은 아닙니다. IP 주소는 네트워크 라우팅 수준에서 처리되지만 포드의 기본 구성은 이를 인식하지 못합니다. 포드 내에서 주소를 인식하고 사용하도록 포드 사양을 구성해야 합니다. 이를 위해서는 포드에 권한 권한이 필요합니다.

다음 옵션 중 하나를 사용하여 Pod 사양을 구성할 수 있습니다.

net.ipv4.ip_nonlocal_bind sysctl 수정

포드 securityContext에서 net.ipv4.ip_nonlocal_bind sysctl을 설정하여 애플리케이션이 인터페이스에 직접 할당되지 않은 IP 주소를 사용할 수 있도록 시스템 설정을 수정할 수 있습니다. 이 옵션은 애플리케이션이 인터페이스에 없는 IP 주소에 바인드할 수 있는 경우에 유용합니다.

spec.template.spec 아래의 배포 또는 StatefulSet YAML 사양에 다음을 추가합니다.
```
securityContext:
  sysctls:
  - name: net.ipv4.ip_nonlocal_bind
    value: "1"
```
할당된 IP 주소를 포드 인터페이스에 추가

init 컨테이너를 사용하여 GKEIPRoute 객체에서 요청한 IP 주소를 포드의 인터페이스 중 하나에 수동으로 추가할 수 있습니다. 이렇게 하면 IP 주소가 직접 할당된 것처럼 포드에 표시됩니다. 이 경우 NET_ADMIN 기능이 필요합니다.

spec.template.spec 아래의 배포 또는 StatefulSet YAML 사양에 다음을 추가합니다.
```
initContainers:
- name: configure-ips
  image: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
  command: ['sh', '-c', 'ip address add ASSIGNED_IP/32 dev eth0']
  securityContext:
    capabilities:
      add:
      - NET_ADMIN
```
ASSIGNED_IP를 GKEIPRoute 객체에 할당된 IP 주소 중 하나로 바꿉니다.
Raw sockets: 더욱 효율적인 제어를 위해 애플리케이션에서 네트워크 스택과 직접 상호작용할 수 있습니다 (고급).
Userspace IP address stack: 특수한 경우 포드 내에서 개별 애플리케이션이 실행되어 IP 주소를 관리할 수 있습니다 (매우 고급).

7단계: 할당된 IP 주소에 ARP 사용 설정 (기본 네트워크만 해당)

유효한 주소 결정 프로토콜 (ARP) 요청 및 응답을 생성하고 기본 네트워크에서 GKEIPRoute 객체에 의해 할당된 IP 주소를 사용하여 포드에 새 연결을 설정하려면 arp_announce 변수를 구성해야 합니다.

arp_announce 변수를 설정하려면 포드에서 다음 명령어를 실행합니다.

echo "2" > /proc/sys/net/ipv4/conf/eth0/arp_announce

여기서 arp_announce 변수는 ARP 공지사항이 처리되는 방식을 제어합니다. '2'로 설정하면 영구 IP 주소에 대한 ARP 공지사항이 게시되므로 네트워크의 다른 기기에서 새 연결을 학습할 수 있습니다.

8단계: 일치하는 엔드포인트 보기

트래픽 분산을 관리하기 위해 GKE는 각 GKEIPRoute 객체에 대해 EndpointSlice를 만듭니다. 이러한 슬라이스는 해당 특정 경로의 라우팅 대상으로 지정된 모든 포드의 레지스트리 역할을 합니다.

GKE는 활성 엔드포인트와 백업 엔드포인트에 대해 별도의 EndpointSlice를 생성합니다. 시스템은 워크로드를 기반으로 EndpointSlice 수를 자동으로 확장합니다. 단일 EndpointSlice는 최대 1,000개의 엔드포인트를 지원하지만 일치하는 포드 수가 이 한도를 초과하면 GKE에서 슬라이스를 추가로 생성합니다.

특정 GKEIPRoute 객체의 모든 EndpointSlice를 보려면 다음 명령어를 실행합니다.

kubectl get endpointslices --all-namespaces -l \
  networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,\
  networking.gke.io/gkeiproute-namespace=GKEIPROUTE_NAMESPACE

다음을 바꿉니다.

GKEIPROUTE_NAME: GKEIPRoute 매니페스트의 이름입니다.
GKEIPROUTE_NAMESPACE: GKEIPRoute 매니페스트의 네임스페이스입니다.

다음 출력은 EndpointSlice의 예를 보여줍니다.

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
 name: {gkeiproute_name-truncated}-{gkeiproute_namespace-truncated}-backup-{unique_hash}
 namespace: {gkeiproute_namespace}
 labels:
  endpointslice.kubernetes.io/managed-by: gkeiproute-controller
  networking.gke.io/gkeiproute-name: {gkeiproute_name}
  networking.gke.io/gkeiproute-namespace: {gkeiproute_namespace}
  networking.gke.io/pip-es-role: backup
 ownerReferences:
  - kind: GKEIPRoute
    name: {gkeiproute_name}
    apiVersion: networking.gke.io/v1
    uid: {uid}
    controller: true
addressType: IPv4
endpoints:
 - addresses:
     - "{pod_ip_address}"
   targetRef:
     Name: {pod_name}
   nodeName: {node_name}

활성 또는 백업 엔드포인트의 EndpointSlice를 구체적으로 보려면 pip-eps-role 라벨을 사용하여 결과를 필터링합니다. 예를 들면 다음과 같습니다.

kubectl get endpointslices --all-namespaces -l \
   networking.gke.io/pip-eps-role=ROLE \
  networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,

다음을 바꿉니다.

ROLE: 보려는 엔드포인트 유형입니다(active 또는 backup).
GKEIPROUTE_NAME: 특정 GKEIPRoute 객체의 이름입니다.

상태 점검 기반 부하 분산 문제 해결

이 섹션에서는 상태 점검 기반 부하 분산과 관련된 문제를 해결하는 방법을 보여줍니다.

일부 활성 포드가 비정상이지만 백업 포드는 트래픽을 수신하지 않음

증상

GKEIPRoute 상태가 Ready로 표시됩니다. 이는 일치하는 포드의 IP 주소 구성이 완료되었음을 나타냅니다. 상태 확인 또는 기타 진단에서 일부 활성 포드가 비정상으로 표시됩니다. 하지만 백업 포드는 트래픽을 수신하지 않습니다.

원인

백업 포드는 모든 활성 포드가 비정상일 때까지 트래픽을 수신하지 않습니다. 그때까지 모든 트래픽은 나머지 정상 활성 포드에 분산됩니다.

해결 방법

필요한 경우 더 이상 활성 포드와 일치하지 않도록 podSelector 필드 라벨을 업데이트합니다. GKE는 백엔드 그룹으로 트래픽을 자동으로 라우팅합니다.

GKEIPRoute가 구성되었지만 일부 포드에서 트래픽을 수신하지 않음

증상

GKEIPRoute 상태가 Ready로 표시됩니다. 이는 일치하는 포드의 IP 주소 구성이 완료되었지만 일치하는 포드 중 일부가 트래픽을 수신하지 않음을 나타냅니다.

원인

트래픽을 수신하지 않는 포드는 비정상적이거나 상태 점검에 올바르게 응답하지 않을 수 있습니다. 일치하는 모든 포드가 정상 상태가 아니면 GKE는 상태와 관계없이 모든 포드에 트래픽을 분산합니다.

해결 방법

포드가 정상인지 확인: Google Cloud CLI 또는Google Cloud 콘솔을 사용하여 포드가 상태 점검에 올바르게 응답하는지 확인합니다.
필요한 경우 추가 조사: 포드가 비정상인 경우 상태 점검을 위한 방화벽을 올바르게 설정했고 포드가 응답하는지 확인합니다.

잘못된 부하 분산기 구성 오류

이 섹션에서는 GKEIPRoute 상태 오류를 해결하는 방법을 설명합니다.

`Backup pod and active pod are on the same node`

증상

GKEIPRoute 상태에서 다음 오류가 보고됩니다.

invalid LB configuration: Backup pod %s and active pod %s are on the same node %s. Active and backup pods must reside on different nodes.

원인

동일한 GKEIPRoute 객체와 일치하는 활성 포드와 백업 포드가 동일한 노드에 예약됩니다. 즉, 동일한 노드에서 활성 및 백업 podSelector 객체와 모두 일치하는 포드가 있습니다.

해결 방법

활성 포드와 백업 포드가 서로 다른 노드에 있는지 확인합니다. 동일한 노드의 두 포드가 동일한 GKEIPRoute 객체와 일치하지 않도록 GKEIPRoute 구성을 업데이트하고 podSelector 또는 backupPodSelector 라벨을 조정합니다.

`Pod cannot be selected as both an active and a backup pod`

증상

GKEIPRoute 상태에서 다음 오류가 보고됩니다.

invalid LB configuration: pod %s cannot be selected as both an active and a backup pod. Active and backup pod sets must be mutually exclusive

원인

하나 이상의 포드가 podSelector (활성) 필드와 backupPodSelector (대기) 필드의 라벨 선택기와 일치합니다. GKE에서는 이 두 그룹이 상호 배타적이어야 합니다. 단일 포드는 자체 백업으로 사용할 수 없습니다.

해결 방법

활성 포드와 백업 포드가 고유한지 확인합니다. GKEIPRoute 매니페스트에서 podSelector 필드 또는 backupPodSelector 필드를 수정하여 더 구체적이거나 고유한 라벨 키와 값을 사용합니다.

`NoPodsFound` 상태

증상

GKEIPRoute 매니페스트에 NoPodsFound 상태가 표시됩니다. 이는 일치하는 라벨이 있는 네임스페이스 내에 포드가 없음을 나타냅니다.

가능한 원인

잘못된 라벨: 구성된 IP 주소를 사용하려는 포드에 잘못된 라벨이 있거나 라벨이 아예 없을 수 있습니다.
포드가 없음: reactionMode == Exists인 경우 pod.Spec.nodeName 필드를 확인하여 포드가 노드에 할당되었는지 확인합니다. GKEIPRoute의 네임스페이스에서 실행 중인 포드 중에 선택기와 일치하는 포드가 없을 수 있습니다.
포드가 준비되지 않음: reactionMode == ReadyCondition인 경우 포드 상태가 READY인지 확인합니다. 일치하는 포드가 있지만 READY 상태가 아니면 포드가 트래픽을 처리할 수 없으므로 선택되지 않습니다.

해결 방법

라벨 확인: GKEIPRoute 객체의 podSelector 필드에 있는 라벨이 의도한 포드에 적용한 라벨과 일치하는지 확인합니다.
포드 존재 확인: 올바른 라벨이 있는 포드가 실제로 Gateway의 리스너에 지정된 GKEIPRoute 객체의 네임스페이스에 있는지 확인합니다. reactionMode == Exists인 경우 pod.Spec.nodeName 필드를 확인하여 포드가 노드에 할당되었는지 확인합니다.
포드 준비 확인: reactionMode == ReadyCondition인 경우 포드 상태가 READY인지 확인합니다. 다음 명령어를 사용하여 포드가 Ready 상태인지 확인합니다.
```
kubectl get pods -n NAMESPACE
```
다른 상태 (예: Pending, Error)의 포드는 선택되지 않습니다.

일치하는 포드가 있고 GKEIPRoute IP 주소 프로그래밍이 진행 중인 경우 `Mutated` 상태

증상

GKEIPRoute 상태가 Mutated로 표시됩니다. 이는 일치하는 포드의 IP 주소 구성이 진행 중임을 나타냅니다.

잠재적 원인

시스템에서 구성된 IP 주소의 GKE 데이터 경로와 Google Cloud 리소스를 설정하므로 구성 중에 Mutated 상태가 표시될 수 있습니다.

해결 방법

대기 및 재시도: 대부분의 경우 구성 프로세스는 짧은 시간 내에 자동으로 완료됩니다. 기다린 후 상태를 확인합니다. 성공하면 Ready로 변경됩니다.
추가 조사 (필요한 경우): Mutated 상태가 장시간 동안 지속된다면 구성 오류가 있을 수 있습니다. GKEIPRoute 객체의 다른 상태 조건을 검사합니다.
- Accepted: GKEIPRoute 설정이 유효한지 여부를 나타냅니다.
- GCPReady: Google Cloud 리소스가 예상대로 설정되었는지 여부를 나타냅니다.

이러한 조건에서 문제를 해결하는 데 도움이 되는 오류 메시지를 찾습니다.

다음 단계

GKE 포드의 영구 IP 주소 자세히 알아보기

상태 점검 기반 부하 분산 구성 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

요구사항 및 제한사항

시작하기 전에

상태 점검 기반 부하 분산 구현

1단계: 리전 상태 확인 및 방화벽 규칙 만들기

2단계: GKE 클러스터 만들기

3단계: IP 주소 예약

3a단계: Google 제공 IP 주소 예약

3b단계: 자체 IP 주소 사용 (BYOIP)

4단계: Gateway 객체 만들기

5단계: 부하 분산 및 상태 점검 구성으로 GKEIPRoute 객체 만들기

6단계: 포드 내에서 할당된 IP 주소 사용

7단계: 할당된 IP 주소에 ARP 사용 설정 (기본 네트워크만 해당)

8단계: 일치하는 엔드포인트 보기

상태 점검 기반 부하 분산 문제 해결

일부 활성 포드가 비정상이지만 백업 포드는 트래픽을 수신하지 않음

GKEIPRoute가 구성되었지만 일부 포드에서 트래픽을 수신하지 않음

잘못된 부하 분산기 구성 오류

Backup pod and active pod are on the same node

Pod cannot be selected as both an active and a backup pod

NoPodsFound 상태

일치하는 포드가 있고 GKEIPRoute IP 주소 프로그래밍이 진행 중인 경우 Mutated 상태

다음 단계

상태 점검 기반 부하 분산 구성

`Backup pod and active pod are on the same node`

`Pod cannot be selected as both an active and a backup pod`

`NoPodsFound` 상태

일치하는 포드가 있고 GKEIPRoute IP 주소 프로그래밍이 진행 중인 경우 `Mutated` 상태