Distributed Cloud Connected의 네트워킹 기능

이 페이지에서는 서브네트워크, BGP 피어링 세션, 부하 분산을 비롯한 Google Distributed Cloud connected의 네트워킹 기능을 설명합니다.

이 페이지의 절차는 Distributed Cloud 연결 랙에만 적용됩니다. 단, 부하 분산은 Distributed Cloud 연결 랙과 Distributed Cloud 연결 서버 모두에 적용됩니다.

IPv4/IPv6 이중 스택 네트워킹

Distributed Cloud Connected를 사용하면 IPv4/IPv6 이중 스택 네트워킹을 사용하는 클러스터를 만들 수 있습니다. 이 기능을 활용하려면 이중 스택 IPv4/IPv6 네트워킹이 사용 설정된 Distributed Cloud를 주문해야 합니다. IPv4/IPv6 이중 스택 네트워킹에 연결된 기존 IPv4 전용 Distributed Cloud 배포를 재구성할 수 없습니다. 배포가 IPv4/IPv6 이중 스택 네트워킹을 지원하는지 확인하려면 머신에 관한 정보 가져오기의 안내를 따르고 반환된 dualstack_capable 라벨 값을 확인하세요.

이중 스택 클러스터에서 IPv4 스택은 섬 모드를 사용하고 IPv6 스택은 플랫 모드를 사용합니다. 따라서 동일한 서브네트워크에 속하는 개별적인 노드 및 포드 IPv6 주소를 지정해야 합니다. 자세한 내용은 플랫 모드와 섬(island) 모드 네트워크 모델 비교를 참고하세요.

예를 들어 Distributed Cloud 연결 노드와 기타 로컬 머신이 동일한 Layer 2 도메인에 있는 경우 클러스터의 IPv6 CIDR 블록을 다음과 같이 지정할 수 있습니다.

차단 목적	차단 범위	블록 크기
IPv6 서브네트워크	fd12::/56	2^72
포드	fd12::1:0/59	2^69
서비스	fd12::2:0/59	2^69

이 예에서는 다음을 가정합니다.

• 노드, 포드, 서비스 CIDR 블록은 fd:12::/56 슈퍼 네트워크에 속합니다.
• 노드, 포드, 서비스 IP 주소는 지정된 CIDR 블록의 서브네트워크입니다.
• 서브네트워크가 중복되지 않습니다.

IPv4/IPv6 이중 스택 네트워킹에는 IPv4 BGP 피어링을 위한 레이어 2 부하 분산과 IPv6 피어링을 위한 레이어 3 부하 분산이 필요합니다. 자세한 내용은 부하 분산을 참고하세요.

IPv4/IPv6 이중 스택 클러스터에 워크로드를 배포하는 방법에 대한 자세한 내용은 다음을 참고하세요.

• IPv4/IPv6 이중 스택 네트워킹
• IPv4/IPv6 이중 스택

Distributed Cloud Edge Network API 사용 설정

연결된 Distributed Cloud 배포에서 네트워킹을 구성하려면 먼저 Distributed Cloud Edge Network API를 사용 설정해야 합니다. 이렇게 하려면 이 섹션의 단계를 완료하세요. 기본적으로 Distributed Cloud(연결형) 서버는 Distributed Cloud Edge Network API가 이미 사용 설정된 상태로 제공됩니다.

콘솔

1. Google Cloud 콘솔에서 Distributed Cloud Edge Network API 페이지로 이동합니다.

   API 사용 설정하기

2. 사용 설정을 클릭합니다.

gcloud

다음 명령어를 사용하세요.

gcloud services enable edgenetwork.googleapis.com

Distributed Cloud(연결형)에서 네트워킹 구성

이 섹션에서는 Distributed Cloud 연결 배포에서 네트워킹 구성요소를 구성하는 방법을 설명합니다.

Distributed Cloud 연결 서버에는 다음 제한사항이 적용됩니다.

• 서브네트워크만 구성할 수 있으며
• 서브네트워크는 VLAN ID만 지원하며 CIDR 기반 서브네트워크는 지원되지 않습니다.

Distributed Cloud Connected의 일반적인 네트워크 구성은 다음 단계로 구성됩니다.

1. 선택사항: 필요한 경우 타겟 영역의 네트워크 구성을 초기화합니다.

2. 네트워크를 만듭니다.

3. 네트워크 내에 서브네트워크를 하나 이상 만듭니다.

4. 해당 상호 연결 연결을 사용하여 PE 라우터와 북바운드 BGP 피어링 세션을 설정합니다.

5. 해당 서브넷을 사용하여 워크로드를 실행하는 포드와 하위 BGP 피어링 세션을 설정합니다.

6. 선택사항: 고가용성을 위해 루프백 BGP 피어링 세션을 설정합니다.

7. 구성을 테스트합니다.

8. 포드를 네트워크에 연결합니다.

Distributed Cloud 영역의 네트워크 구성 초기화

온프레미스에 Distributed Cloud 연결 하드웨어가 설치된 후 즉시 Distributed Cloud 연결 영역의 네트워크 구성을 초기화해야 합니다. 영역의 네트워크 구성을 초기화하는 것은 일회성 절차입니다.

영역의 네트워크 구성을 초기화하면 default라는 기본 라우터와 default라는 기본 네트워크가 생성됩니다. 또한 해당 Interconnect 연결을 만들어 Distributed Cloud 연결 하드웨어를 주문할 때 요청한 모든 Interconnect와 피어링하도록 default 라우터를 구성합니다. 이 구성은 Distributed Cloud 연결 배포에 로컬 네트워크로의 기본 업링크 연결을 제공합니다.

자세한 내용은 영역의 네트워크 구성 초기화를 참고하세요.

네트워크 만들기

새 네트워크를 만들려면 네트워크 만들기의 안내를 따르세요. 또한 분산 클라우드 연결 노드가 네트워크에 연결할 수 있도록 네트워크 내에 하나 이상의 서브네트워크를 만들어야 합니다.

하나 이상의 서브네트워크 만들기

서브네트워크를 만들려면 서브네트워크 만들기의 안내를 따르세요. 노드가 네트워크에 액세스할 수 있도록 네트워크에 하나 이상의 서브네트워크를 만들어야 합니다. 생성한 각 서브네트워크에 해당하는 VLAN은 영역의 모든 노드에서 자동으로 사용할 수 있습니다.

Distributed Cloud 연결 서버의 경우 VLAN ID를 사용하여 서브넷만 구성할 수 있습니다. CIDR 기반 서브네트워크는 지원되지 않습니다.

북쪽 BGP 피어링 세션 설정

네트워크와 해당 서브네트워크를 만들면 Distributed Cloud 연결 영역에 로컬로 생성됩니다. 아웃바운드 연결을 사용 설정하려면 네트워크와 피어링 에지 라우터 간에 하나 이상의 북바운드 BGP 피어링 세션을 설정해야 합니다.

업스트림 BGP 피어링 세션을 설정하려면 다음 단계를 따르세요.

1. 영역에서 사용 가능한 상호 연결을 나열한 다음 이 피어링 세션의 대상 상호 연결을 선택합니다.

2. 선택한 Interconnect에서 하나 이상의 Interconnect 연결을 만듭니다. 상호 연결 연결은 다음 단계에서 만드는 라우터를 선택한 상호 연결에 연결합니다.

3. 라우터를 만듭니다. 이 라우터는 이전 단계에서 만든 상호 연결 연결을 사용하여 상호 연결과 네트워크 간에 트래픽을 라우팅합니다.

4. 이 절차의 앞부분에서 만든 각 Interconnect 연결에 대해 라우터에 인터페이스를 추가합니다. 각 인터페이스에 대해 Distributed Cloud 연결 랙에 있는 해당 ToR (Top-of-Rack) 스위치의 IP 주소를 사용합니다. 자세한 내용은 북바운드 피어링 세션 설정을 참고하세요.

5. 이전 단계에서 라우터에 만든 각 인터페이스의 피어를 추가합니다.

다운스트림 BGP 피어링 세션 설정

로컬 네트워크에서 워크로드로의 인바운드 연결을 사용 설정하려면 피어링 에지 라우터와 포드가 속한 서브네트워크 간에 하나 이상의 사우스바운드 BGP 피어링 세션을 설정해야 합니다. 각 서브네트워크의 게이트웨이 IP 주소는 Distributed Cloud에 연결된 랙에 있는 해당 ToR 스위치의 IP 주소입니다.

다운스트림 BGP 피어링 세션을 설정하려면 다음 단계를 따르세요.

1. 인바운드 연결을 프로비저닝하려는 각 서브네트워크에 대해 타겟 네트워크의 라우터에 인터페이스를 추가합니다. 자세한 내용은 다운스트림 피어링 세션 설정을 참고하세요.

2. 이전 단계에서 라우터에 만든 각 인터페이스에 대해 피어를 추가합니다.

선택사항: 루프백 BGP 피어링 세션 설정

워크로드와 로컬 네트워크 간에 고가용성 연결을 사용 설정하려면 타겟 포드와 Distributed Cloud 연결 랙의 ToR 스위치 간에 루프백 BGP 피어링 세션을 설정하면 됩니다. 루프백 피어링 세션은 포드에 대해 두 개의 독립적인 피어링 세션을 설정합니다. 각 ToR 스위치에 하나씩입니다.

루프백 BGP 피어링 세션을 설정하려면 다음 단계를 따르세요.

1. 타겟 네트워크의 라우터에 루프백 인터페이스를 추가합니다. 자세한 내용은 루프백 피어링 세션 설정을 참고하세요.

2. 루프백 인터페이스의 피어 추가

구성 테스트

생성한 네트워크 구성요소의 구성을 테스트하려면 다음을 실행하세요.

1. 네트워크의 운영 상태를 확인합니다.

2. 각 서브네트워크의 프로비저닝 상태를 확인합니다.

3. 인터커넥트의 운영 상태를 확인합니다.

4. 상호 연결 연결의 운영 상태를 확인합니다.

5. 라우터의 작동 상태를 확인합니다.

포드를 네트워크에 연결

포드를 네트워크에 연결하고 고급 네트워크 기능을 구성하려면 네트워크 기능 운영자의 안내를 따르세요. 이 기능은 가상 머신 워크로드에서는 사용할 수 없습니다.

(선택사항) 클러스터 네트워크 격리 구성

Distributed Cloud connected는 클러스터 네트워크 격리를 지원합니다. 네트워크 격리 클러스터에 할당된 노드는 동일한 Distributed Cloud 연결 영역 내의 다른 노드와 통신할 수 없습니다. 클러스터 네트워크 격리를 사용 설정하려면 클러스터를 만들거나 수정할 때 --enable-cluster-isolation 플래그를 사용하세요. 자세한 내용은 클러스터 만들기 및 관리를 참고하세요.

(선택사항) 섬 모드 구성

Distributed Cloud connected는 가상 네트워킹 하위 시스템의 아일랜드 모드를 지원합니다. 아일랜드 모드를 사용하면 포드의 보조 네트워크 인터페이스에서 격리된 IP 주소 범위를 지정할 수 있습니다. 이 격리된 주소 범위는 기본 네트워크 인터페이스 VLAN의 주소 범위와는 독립적입니다. 섬 모드로 구성된 포드에는 이 격리된 '섬' 주소 범위의 주소만 할당됩니다. 자세한 내용은 플랫 모드와 섬(island) 모드 네트워크 모델 비교를 참고하세요.

아일랜드 모드에 지정하는 격리된 IP 주소 범위는 다음 IP 주소 범위와 충돌하지 않아야 합니다.

• 클러스터에 구성된 네트워크의 기본 VLAN CIDR
• Network 리소스의 networking.gke.io/gdce-lb-service-vip-cidrs 주석에 지정된 부하 분산기 가상 IP 주소 범위
• 클러스터의 다른 네트워크에 대해 아일랜드 모드에 사용되는 IP 주소 범위

아일랜드 모드 구성

포드 수준에서 아일랜드 모드를 구성하려면 해당 Network 커스텀 리소스에 networking.gke.io/gdce-pod-cidr 주석을 추가합니다. 주석 값을 타겟 격리 IP 주소 범위로 설정하고 수정된 Network 리소스를 클러스터에 적용합니다. 예를 들면 다음과 같습니다.

networking.gke.io/gdce-pod-cidr: 172.15.10.32/27

다음 매개변수도 설정해야 합니다.

• type은 L3로 설정해야 합니다.
• IPAMMode은 Internal로 설정해야 합니다.

예를 들면 다음과 같습니다.

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: my-network
  annotations:
    # Enable island mode and specify the isolated address range.
    networking.gke.io/gdce-pod-cidr: 172.15.10.32/27
    # Specify the VLAN ID for this secondary network.
    networking.gke.io/gdce-vlan-id: "561"
    # Specify the CIDR block for load balancer services on this network.
    networking.gke.io/gdce-lb-service-vip-cidrs: 172.20.5.180/30
spec:
  # Network type must be L3 for island mode.
  type: L3
  # IPAMMode must be Internal for island mode.
  IPAMMode: Internal
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.561 # The name for the target network interface.
  gateway4: 172.20.5.177 # Gateway IP address; must be unique in this CR.
  externalDHCP4: false
  dnsConfig:
    nameservers:
    - 8.8.8.8

아일랜드 모드가 사용 설정되어 있는지 확인하려면 다음을 실행하세요.

1. 테스트 포드를 만들고 클러스터에 적용합니다. 예를 들면 다음과 같습니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: island-pod-tester
     annotations:
       networking.gke.io/interfaces: '[{"interfaceName":"eth1","network":"test-network-vlan561"}]'
       networking.gke.io/default-interface: "eth1"
   spec:
     containers:
     - name: sample-container
       image: busybox
       command: ["/bin/sh", "-c", "sleep 3600"]
   

2. 포드의 IP 주소를 가져옵니다.

   kubectl get pod island-pod-tester -o wide
   

   이 명령어는 지정한 격리된 주소 범위 내에 있는 포드의 IP 주소를 반환합니다.

ClusterIP 서비스를 사용하여 아일랜드 모드 구성

ClusterIP 서비스를 사용하여 아일랜드 모드를 구성하려면 이전 섹션의 단계를 완료한 후 Network 리소스에 networking.gke.io/gke-gateway-clusterip-cidr 주석을 추가하고 비즈니스 요구사항에 따라 값을 설정합니다. Network 리소스에 지정된 주소 범위는 겹쳐서는 안 됩니다. 예를 들면 다음과 같습니다.

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  annotations:
    networking.gke.io/gdce-lb-service-vip-cidrs: 172.20.5.180/30
    networking.gke.io/gdce-pod-cidr: 172.15.10.32/27
    networking.gke.io/gdce-vlan-id: "561"
    networking.gke.io/gke-gateway-clusterip-cidr: 10.20.1.0/28
  name: test-network-vlan561
spec:
  IPAMMode: Internal
  dnsConfig:
    nameservers:
    - 8.8.8.8
  externalDHCP4: false
  gateway4: 172.20.5.177
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.561
  type: L3

부하 분산

Distributed Cloud connected는 다음 부하 분산 솔루션과 함께 제공됩니다.

• MetalLB를 사용한 레이어 2 부하 분산
• Google Distributed Cloud 부하 분산기를 사용한 레이어 3 부하 분산

Distributed Cloud(연결형)에 내장된 부하 분산 솔루션은 중복되는 Kubernetes 서비스 가상 IP 접두사를 사용할 수 없습니다. 계층 2 MetalLB 부하 분산을 사용하는 기존 Distributed Cloud 연결 배포가 있고 Google Distributed Cloud 부하 분산기를 사용하여 계층 3 부하 분산으로 전환하려면 계층 2 MetalLB 부하 분산 구성에서 사용하는 프리픽스와 중복되지 않는 서비스 가상 IP 프리픽스를 사용해야 합니다.

MetalLB를 사용한 레이어 2 부하 분산

Distributed Cloud는 Layer 2 모드의 MetalLB를 기반으로 하는 번들 네트워크 부하 분산 솔루션과 함께 제공됩니다. 이 솔루션을 사용하면 다음과 같이 가상 IP 주소 (VIP)를 사용하여 Distributed Cloud 영역에서 실행되는 서비스를 외부 세계에 노출할 수 있습니다.

1. 네트워크 관리자는 Distributed Cloud를 주문할 때 네트워크 토폴로지를 계획하고 필요한 가상 IPv4 및 IPv6 주소 서브넷을 지정합니다. Google은 배송 전에 Distributed Cloud 하드웨어를 적절하게 구성합니다. 다음 사항에 유의하세요.
   • 이 VIP 서브네트워크는 Distributed Cloud 영역 내에서 실행되는 모든 Kubernetes 클러스터 간에 공유됩니다.
   • 요청된 VIP 서브넷의 경로는 Distributed Cloud 영역과 로컬 네트워크 간의 BGP 세션을 통해 공지됩니다.
   • 서브네트워크의 첫 번째 (네트워크 ID), 두 번째 (기본 게이트웨이), 마지막 (브로드캐스트 주소) 주소는 핵심 시스템 기능을 위해 예약되어 있습니다. 이러한 주소를 MetalLB 구성의 주소 풀에 할당하지 마세요.
   • 각 클러스터는 구성된 VIP 서브넷 내에 있는 별도의 VIP 범위를 사용해야 합니다.
2. Distributed Cloud 영역에서 클러스터를 만들 때 클러스터 관리자는 CIDR 표기법을 사용하여 포드 및 ClusterIP 서비스 주소 풀을 지정합니다. 네트워크 관리자가 클러스터 관리자에게 적절한 LoadBalancer VIP 서브넷을 제공합니다.

3. 클러스터가 생성되면 클러스터 관리자가 해당 VIP 풀을 구성합니다. 클러스터를 만들 때 --external-lb-address-pools 플래그를 사용하여 VIP 풀을 지정해야 합니다. 이 플래그는 다음 형식의 YAML 또는 JSON 페이로드가 포함된 파일을 허용합니다.

    addressPools:
    - name: foo
      addresses:
      - 10.2.0.212-10.2.0.221
      - fd12::4:101-fd12::4:110
      avoid_buggy_ips: true
      manual_assign: false
   
    - name: bar
      addresses:
      - 10.2.0.202-10.2.0.203
      - fd12::4:101-fd12::4:102
      avoid_buggy_ips: true
      manual_assign: false
   

   VIP 주소 풀을 지정하려면 페이로드에 다음 정보를 제공하세요.

   • name: 이 VIP 주소 풀을 고유하게 식별하는 설명 이름입니다.
   • addresses: 이 주소 풀에 포함할 IPv4 및 IPv6 주소, 주소 범위, 서브넷 목록입니다.
   • avoid_buggy_ips: .0 또는 .255로 끝나는 IP 주소를 제외합니다.
   • manual_assign: MetalLB 컨트롤러가 자동으로 할당하는 대신 타겟 LoadBalancer 서비스의 구성에서 이 풀의 주소를 수동으로 할당할 수 있습니다.

   VIP 주소 풀 구성에 대한 자세한 내용은 MetalLB 문서의 주소 풀 지정을 참고하세요.

4. 클러스터 관리자가 적절한 Kubernetes LoadBalancer 서비스를 만듭니다.

단일 노드 풀의 Distributed Cloud 노드는 공통 레이어 2 도메인을 공유하므로 MetalLB 부하 분산기 노드이기도 합니다.

Google Distributed Cloud 부하 분산기를 사용한 레이어 3 부하 분산

Distributed Cloud Connected는 BGP 스피커로 구성된 Layer 3 모드의 Google Distributed Cloud 번들 부하 분산기를 기반으로 하는 번들 네트워크 부하 분산 솔루션과 함께 제공됩니다. 이 솔루션을 사용하면 VIP를 사용하여 Distributed Cloud 연결 영역에서 실행되는 서비스를 외부 세계에 노출할 수 있습니다.

metallb-config ConfigMap을 사용하여 해당 LoadBalancer 서비스의 VIP 범위를 지정할 수 있습니다. 예를 들면 다음과 같습니다.

kind: ConfigMap
apiVersion: v1
data:
  config: |
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 10.100.10.66/27
metadata:
  name: metallb-config
  namespace: metallb-system

위의 예시에서 구성한 각 LoadBalancer 서비스에는 ConfigMap에 지정된 10.100.10.66/27 범위의 가상 IP 주소가 자동으로 할당됩니다. 그런 다음 이러한 VIP는 BGPPeer 리소스를 통해 ToR 스위치에 구성된 Distributed Cloud BGP 스피커에 의해 북쪽으로 공지됩니다.

Distributed Cloud 클러스터를 만들면 해당 클러스터에 다음 리소스가 자동으로 생성됩니다.

• BGP 부하 분산기를 인스턴스화하는 BGPLoadBalancer 리소스
• BGP 스피커에 사용할 로컬 유동 IP 주소를 지정하는 NetworkGatewayGroup 리소스입니다. 이러한 IP 주소는 클러스터에 할당된 Kubernetes 노드 서브네트워크의 마지막 두 IP 주소로 자동 설정됩니다.

이러한 리소스가 있으면 해당 BGPPeer 리소스를 구성하여 Distributed Cloud ToR 스위치에 BGP 세션을 설정할 수 있습니다. 이렇게 하려면 필요한 자율 시스템 번호 (ASN)와 ToR 스위치의 루프백 피어 IP 주소가 있어야 합니다. 이러한 IP 주소는 기본 네트워크 리소스의 ToR 스위치 BGP 세션 엔드포인트 역할을 합니다. network 매개변수의 값은 pod-network이어야 합니다.

다음은 두 BGPPeer 리소스의 예시입니다.

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor1
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.10
  sessions: 1

kind: BGPPeer
apiVersion: networking.gke.io/v1
metadata:
  name: bgppeertor2
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
  namespace: kube-system
spec:
  network: pod-network
  localASN: 64777
  peerASN: 64956
  peerIP: 10.112.0.11
  sessions: 1

IPv6 피어링을 위한 Layer 3 BGP 부하 분산 자동화 구성

IPv4/IPv6 이중 스택 네트워킹 클러스터에서 IPv6 피어링을 사용하려면 먼저 Google 지원팀과 협력하여 Distributed Cloud 연결 배포에서 Google Distributed Cloud 부하 분산기 자동화를 사용 설정해야 합니다.

레이어 3 LoadBalancer 서비스 만들기

Distributed Cloud(연결형) 배포에서 Google Distributed Cloud 부하 분산기 자동화를 사용 설정한 후 레이어 3 LoadBalancer 서비스를 인스턴스화합니다. 예를 들면 다음과 같습니다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app.kubernetes.io/name: MyApp
spec:
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
  - IPv6
  - IPv4
  selector:
    app.kubernetes.io/name: MyApp
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80

BGP 세션 및 부하 분산 서비스의 상태 확인

BGP 세션의 상태를 확인하려면 다음 명령어를 사용하세요.

kubectl get bgpsessions.networking.gke.io -A

이 명령어는 다음 예와 유사한 출력을 반환합니다.

NAMESPACE     NAME                                                 LOCAL ASN   PEER ASN   LOCAL IP        PEER IP         STATE            LAST REPORT
kube-system   bgppeertor1-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.10     Established      2s
kube-system   bgppeertor2-np-den6-120demo-den6-04-6ad5b6f4         64777       64956      10.100.10.61    10.112.0.11     Established      2s

LoadBalancer 서비스가 BGP 스피커에 의해 광고되고 있는지 확인하려면 다음 명령어를 사용하세요.

kubectl get bgpadvertisedroutes.networking.gke.io -A

이 명령어는 다음 예와 유사한 출력을 반환합니다.

NAMESPACE      NAME                           PREFIX            METRIC
kube-system    bgplb-default-service-tcp      10.100.10.68/32
kube-system    bgplb-default-service-udp      10.100.10.77/32

Distributed Cloud 인그레스

부하 분산 외에도 Distributed Cloud Connected는 Kubernetes Ingress 리소스를 지원합니다. Kubernetes Ingress 리소스는 Distributed Cloud 연결 클러스터에서 실행되는 Kubernetes 서비스로의 HTTP(S) 트래픽 흐름을 제어합니다. 다음 예에서는 일반적인 Ingress 리소스를 보여줍니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: my-service
            port:
              number: 80
        path: /foo
        pathType: Prefix

구성되면 네트워크 트래픽이 istio-ingress 서비스를 통해 흐르며, 이 서비스에는 기본적으로 MetalLB 구성에 지정된 VIP 풀에서 임의의 IP 주소가 할당됩니다. istio-ingress 서비스 정의에서 loadBalancerIP 필드를 사용하여 MetalLB 구성에서 특정 IP 주소 또는 가상 IP 주소를 선택할 수 있습니다. 예를 들면 다음과 같습니다.

apiVersion: v1
kind: service
metadata:
  labels:
    istio: ingress-gke-system
    release: istio
  name: istio-ingress
  namespace: gke-system
spec:
  loadBalancerIP: <targetLoadBalancerIPaddress>

이 기능은 Distributed Cloud 연결 서버에서 사용할 수 없습니다.

기본 Distributed Cloud Ingress 리소스 사용 중지

기본적으로 Distributed Cloud 연결 클러스터를 만들면 Distributed Cloud가 클러스터의 istio-ingress 서비스를 자동으로 구성합니다. istio-ingress 서비스 없이 Distributed Cloud 연결 클러스터를 만들 수 있습니다. 그러려면 다음 단계를 완료하세요.

gcloud

1. 다음 콘텐츠로 SystemsAddonConfig.yaml이라는 YAML 구성 파일을 만듭니다.

   systemAddonsConfig:
    ingress:
      disabled: true
   

2. 클러스터 생성 명령어에서 --system-addons-config 플래그를 사용하여 SystemsAddonConfig.yaml 파일을 전달합니다. 이 기능을 사용하려면 gcloud alpha 버전을 사용해야 합니다. 예를 들면 다음과 같습니다.

   gcloud alpha edge-cloud container clusters create MyGDCECluster1 --location us-west1 \
       --system-addons-config=SystemsAddonConfig.yaml
   

   Distributed Cloud 클러스터 만들기에 대한 자세한 내용은 클러스터 만들기를 참고하세요.

API

1. 클러스터 생성 요청의 JSON 페이로드에 다음 JSON 콘텐츠를 추가합니다.

   "systemAddonConfig" {
      "ingress" {
              "disabled": true
      }
   }
   

2. 클러스터 만들기에 설명된 대로 클러스터 생성 요청을 제출합니다.

NodePort 서비스

Distributed Cloud connected는 원하는 포트 번호에서 Distributed Cloud 노드의 연결을 수신하는 Kubernetes NodePort 서비스를 지원합니다. NodePort 서비스는 TCP, UDP, SCTP 프로토콜을 지원합니다. 예를 들면 다음과 같습니다.

apiVersion: v1
kind: pod
metadata:
  name: socat-nodeport-sctp
  labels:
    app.kubernetes.io/name: socat-nodeport-sctp
spec:
  containers:
  - name: socat-nodeport-sctp
    ...
    ports:
      - containerPort: 31333
        protocol: SCTP
        name: server-sctp

---

apiVersion: v1
kind: service
metadata:
  name: socat-nodeport-sctp-svc
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: socat-nodeport-sctp
  ports:
    - port: 31333
      protocol: SCTP
      targetPort: server-sctp
      nodePort: 31333

SCTP 지원

Distributed Cloud connected는 내부 및 외부 네트워킹 모두에 대해 기본 네트워크 인터페이스에서 스트림 제어 전송 프로토콜 (SCTP)을 지원합니다. SCTP 지원에는 NodePort, LoadBalancer, ClusterIP 서비스 유형이 포함됩니다. 포드는 SCTP를 사용하여 다른 포드 및 외부 리소스와 통신할 수 있습니다. 다음 예에서는 SCTP를 사용하여 IPERF를 ClusterIP 서비스로 구성하는 방법을 보여줍니다.

apiVersion: v1
kind: pod
metadata:
  name: iperf3-sctp-server-client
  labels:
    app.kubernetes.io/name: iperf3-sctp-server-client
spec:
  containers:
  - name: iperf3-sctp-server
    args: ['-s', '-p 31390']
    ports:
      - containerPort: 31390
        protocol: SCTP
        name: server-sctp
  - name: iperf3-sctp-client
    ...

---

apiVersion: v1
kind: service
metadata:
  name: iperf3-sctp-svc
spec:
  selector:
    app.kubernetes.io/name: iperf3-sctp-server-client
  ports:
    - port: 31390
      protocol: SCTP
      targetPort: server-sctp

이 기능은 Distributed Cloud 연결 서버에서 사용할 수 없습니다.

SCTP 커널 모듈

버전 1.5.0부터 Distributed Cloud Connected는 sctp Edge OS 커널 모듈을 로드 가능으로 구성합니다. 이렇게 하면 커널 사용자 공간에 자체 SCTP 프로토콜 스택을 로드할 수 있습니다.

또한 Distributed Cloud(연결형)는 기본적으로 다음 모듈을 커널에 로드합니다.

모듈 이름	구성 이름
fou	CONFIG_NET_FOU
nf_conntrack_proto_gre	CONFIG_NF_CT_PROTO_GRE
nf_conntrack_proto_sctp	CONFIG_NF_CT_PROTO_SCTP
inotify	CONFIG_INOTIFY_USER
xt_redirect	CONFIG_NETFILTER_XT_TARGET_REDIRECT
xt_u32	CONFIG_NETFILTER_XT_MATCH_U32
xt_multiport	CONFIG_NETFILTER_XT_MATCH_MULTIPORT
xt_statistic	CONFIG_NETFILTER_XT_MATCH_STATISTIC
xt_owner	CONFIG_NETFILTER_XT_MATCH_OWNER
xt_conntrack	CONFIG_NETFILTER_XT_MATCH_CONNTRACK
xt_mark	CONFIG_NETFILTER_XT_MARK
ip6table_mangle	CONFIG_IP6_NF_MANGLE
ip6_tables	CONFIG_IP6_NF_IPTABLES
ip6table_filter	CONFIG_IP6_NF_FILTER
ip6t_reject	CONFIG_IP6_NF_TARGET_REJECT
iptable_mangle	CONFIG_IP_NF_MANGLE
ip_tables	CONFIG_IP_NF_IPTABLES
iptable_filter	CONFIG_IP_NF_FILTER

리소스 ClusterDNS개

Distributed Cloud(연결형)는 spec.domains 섹션을 사용하여 특정 도메인의 업스트림 네임서버를 구성하기 위한 Google Distributed Cloud ClusterDNS 리소스를 지원합니다. 이 리소스 구성에 대한 자세한 내용은 spec.domains을 참고하세요.

이 기능은 Distributed Cloud 연결 서버에서 사용할 수 없습니다.

다음 단계

• 포드 및 서비스 네트워크 주소 할당