Mengonfigurasi load balancer gabungan dengan BGP

Dokumen ini menjelaskan cara menyiapkan dan menggunakan load balancer paket dengan Border Gateway Protocol (BGP) untuk Google Distributed Cloud. Mode load balancing ini mendukung pengumuman alamat IP virtual (VIP) ServiceType LoadBalancer melalui Border Gateway Protocol (eBGP) eksternal untuk cluster Anda. Dalam skenario ini, jaringan cluster Anda adalah sistem otonom, yang saling terhubung dengan sistem otonom lain, jaringan eksternal, melalui peering.

Load balancer gabungan dengan kemampuan BGP berlaku untuk semua jenis cluster, tetapi cluster admin hanya mendukung bagian load balancing bidang kontrol dari kemampuan ini.

Menggunakan load balancer yang disertakan dengan fitur BGP memberikan manfaat berikut:

  • Menggunakan kemampuan load balancing aktif/aktif N-way, sehingga memberikan failover yang lebih cepat dan penggunaan bandwidth yang tersedia secara lebih efisien.
  • Mendukung protokol Lapisan 3 yang beroperasi dengan router dan switch top-of-rack (ToR) pihak ketiga yang kompatibel dengan eBGP.
  • Memungkinkan pusat data yang menjalankan stack jaringan (SDN) canggih yang ditentukan software untuk mendorong batas Layer 3 hingga ke cluster.

Cara kerja load balancing gabungan dengan BGP

Bagian berikut memberikan ringkasan singkat tentang cara kerja load balancer gabungan dengan BGP.

Peering BGP

Load balancer yang dibundel dengan fitur BGP memulai beberapa koneksi BGP ke infrastruktur Anda. BGP memiliki persyaratan teknis berikut:

  • Sesi peering terpisah untuk VIP bidang kontrol dan untuk VIP layanan.
  • Sesi peering bidang kontrol dimulai dari alamat IP node bidang kontrol.
  • Sesi peering layanan dimulai dari alamat IP floating yang Anda tentukan di resource kustom NetworkGatewayGroup.
  • Pengontrol Network Gateway untuk GDC mengelola alamat IP mengambang.
  • Load balancing berbasis BGP yang tergabung hanya mendukung peering eBGP.
  • Peering multi-hop didukung secara default.
  • Sandi MD5 pada sesi BGP tidak didukung.
  • Sesi peering berbasis IPv6 tidak didukung.
  • Rute yang diiklankan ke peer mana pun diharapkan didistribusikan ulang di seluruh jaringan dan dapat dijangkau dari tempat lain di cluster.
  • Penggunaan kemampuan ADD-PATH BGP dalam mode penerimaan direkomendasikan untuk sesi peering.
  • Mengiklankan beberapa jalur dari setiap peer menghasilkan load balancing aktif/aktif.
  • Perutean multi-jalur berongkos sama (ECMP) harus diaktifkan untuk jaringan Anda agar beberapa jalur dapat digunakan untuk menyebarkan traffic di seluruh set node load balancer.

Load balancing bidang kontrol

Setiap node bidang kontrol di cluster Anda membuat sesi BGP dengan satu atau beberapa peer di infrastruktur Anda. Kami mewajibkan setiap node bidang kontrol memiliki setidaknya satu peer. Dalam file konfigurasi cluster, Anda dapat mengonfigurasi node bidang kontrol mana yang terhubung ke peer eksternal mana.

Diagram berikut menunjukkan contoh peering bidang kontrol. Cluster memiliki dua node bidang kontrol dalam satu subnet dan satu di subnet lainnya. Ada peer eksternal (TOR) di setiap subnet dan node bidang kontrol Google Distributed Cloud melakukan peering dengan TOR-nya.

Load balancing layanan dengan peering BGP

Load balancing layanan

Selain sesi peering yang dimulai dari setiap node bidang kontrol untuk peering bidang kontrol, sesi peering tambahan dimulai untuk Layanan LoadBalancer. Sesi peering ini tidak dimulai langsung dari alamat IP node cluster, tetapi menggunakan alamat IP mengambang.

Layanan dengan kebijakan jaringan externalTrafficPolicy=Local didukung. Namun, setelan externalTrafficPolicy=Local bergantung pada workload dan menyebabkan rute diperbarui setiap kali Pod yang mendukung Layanan ditambahkan atau dihapus sepenuhnya dari node. Perilaku pembaruan rute ini dapat menyebabkan perutean Equal Cost Multi-Path (ECMP) mengubah alur traffic, yang dapat mengakibatkan penurunan traffic.

Alamat IP floating

Load balancing layanan mengharuskan Anda mencadangkan alamat IP mengambang di subnet node cluster untuk digunakan dalam peering BGP. Minimal satu alamat IP mengambang diperlukan untuk cluster, tetapi sebaiknya cadangkan minimal dua alamat untuk memastikan ketersediaan tinggi untuk sesi BGP. Alamat IP floating ditentukan dalam resource kustom (CR) NetworkGatewayGroup, yang dapat disertakan dalam file konfigurasi cluster.

Alamat IP floating menghilangkan kekhawatiran tentang pemetaan alamat IP speaker BGP ke node. Pengontrol Network Gateway untuk GDC menangani penetapan NetworkGatewayGroup ke node dan juga mengelola alamat IP mengambang. Jika node tidak berfungsi, pengontrol Network Gateway for GDC akan menetapkan ulang alamat IP mengambang untuk memastikan bahwa peer eksternal memiliki alamat IP deterministik untuk melakukan peering.

Peer eksternal

Untuk load balancing bidang data, Anda dapat menggunakan peer eksternal yang sama yang ditentukan untuk peering bidang kontrol di bagian loadBalancer.controlPlaneBGP file konfigurasi cluster. Atau, Anda dapat menentukan peer BGP yang berbeda.

Jika Anda ingin menentukan peer BGP yang berbeda untuk peering data plane, tambahkan spesifikasi resource BGPLoadBalancer dan BGPPeer ke file konfigurasi cluster. Jika Anda tidak menentukan resource kustom ini, peer bidang kontrol akan digunakan secara otomatis untuk bidang data.

Anda menentukan peer eksternal yang digunakan untuk sesi peering dengan alamat IP floating di resource kustom BGPPeer, yang Anda tambahkan ke file konfigurasi cluster. Resource BGPPeer menyertakan label untuk identifikasi oleh resource kustom BGPLoadBalancer yang sesuai. Anda menentukan label pencocokan di kolom peerSelector dalam resource kustom BGPLoadBalancer untuk memilih BGPPeer yang akan digunakan.

Network Gateway untuk pengontrol GDC mencoba membuat sesi (jumlah sesi dapat dikonfigurasi) ke setiap peer eksternal dari kumpulan alamat IP mengambang yang dicadangkan. Sebaiknya tentukan minimal dua peer eksternal untuk memastikan ketersediaan tinggi untuk sesi BGP. Setiap peer eksternal yang ditetapkan untuk load balancing Layanan harus dikonfigurasi untuk melakukan peering dengan setiap alamat IP mengambang yang ditentukan dalam resource kustom NetworkGatewayGroup.

Node load balancer

Subkumpulan node dari cluster digunakan untuk load balancing, yang berarti node tersebut diiklankan agar dapat menerima traffic load balancing yang masuk. Kumpulan node ini secara default adalah node pool bidang kontrol, tetapi Anda dapat menentukan node pool yang berbeda di bagian loadBalancer pada file konfigurasi cluster. Jika Anda menentukan kumpulan node, kumpulan node tersebut akan digunakan untuk node load balancer, bukan kumpulan node bidang kontrol.

Alamat IP mengambang, yang berfungsi sebagai speaker BGP, mungkin atau tidak berjalan di node load balancer. Alamat IP mengambang ditetapkan ke node di subnet yang sama dan peering dimulai dari sana, terlepas dari apakah itu node load balancer. Namun, next hop yang diiklankan melalui BGP selalu berupa node load balancer.

Contoh topologi peering

Diagram berikut menunjukkan contoh load balancing Layanan dengan peering BGP. Ada dua alamat IP mengambang yang ditetapkan ke node di subnet masing-masing. Ada dua peer eksternal yang ditentukan. Setiap IP mengambang melakukan peering dengan peer eksternal.

Load balancing layanan dengan peering BGP

Menyiapkan load balancer BGP

Bagian berikut menjelaskan cara mengonfigurasi cluster dan jaringan eksternal untuk menggunakan load balancer yang disertakan dengan BGP.

Merencanakan integrasi Anda dengan infrastruktur eksternal

Untuk menggunakan load balancer gabungan dengan BGP, Anda harus menyiapkan infrastruktur eksternal:

  • Infrastruktur eksternal harus dikonfigurasi untuk melakukan peering dengan setiap node bidang kontrol di cluster untuk menyiapkan komunikasi bidang kontrol. Sesi peering ini digunakan untuk mengiklankan VIP bidang kontrol Kubernetes.

  • Infrastruktur eksternal harus dikonfigurasi untuk melakukan peering dengan serangkaian alamat IP mengambang yang dicadangkan untuk komunikasi bidang data. Alamat IP floating digunakan untuk peering BGP bagi VIP Layanan. Sebaiknya gunakan dua alamat IP mengambang dan dua peer untuk memastikan ketersediaan tinggi untuk sesi BGP. Proses mencadangkan IP mengambang dijelaskan sebagai bagian dari mengonfigurasi cluster untuk load balancing gabungan dengan BGP.

Setelah Anda mengonfigurasi infrastruktur, tambahkan informasi peering BGP ke file konfigurasi cluster. Cluster yang Anda buat dapat memulai sesi peering dengan infrastruktur eksternal.

Mengonfigurasi cluster untuk load balancing gabungan dengan BGP

Anda mengaktifkan dan mengonfigurasi load balancing gabungan dengan BGP di file konfigurasi cluster saat membuat cluster. Dalam file konfigurasi cluster, Anda mengaktifkan jaringan lanjutan dan memperbarui bagian loadBalancer. Anda juga menambahkan spesifikasi untuk tiga resource kustom berikut:

  • NetworkGatewayGroup: menentukan alamat IP floating yang digunakan untuk sesi peering BGP Services.

  • BGPLoadBalancer: menentukan dengan pemilih label peer mana yang digunakan untuk load balancing BGP.

  • BGPPeer: menentukan setiap peer, termasuk label untuk tujuan pemilihan, untuk sesi peering BGP.

Petunjuk berikut menjelaskan cara mengonfigurasi cluster dan tiga resource kustom untuk menyiapkan load balancing gabungan dengan BGP.

  1. Tambahkan kolom advancedNetworking ke file konfigurasi cluster di bagian clusterNetwork dan tetapkan ke true.

    Kolom ini memungkinkan kemampuan jaringan tingkat lanjut, khususnya resource Network Gateway Group.

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: CLUSTER_NAMESPACE
spec:
...
  clusterNetwork:
    advancedNetworking: true

    Ganti CLUSTER_NAMESPACE dengan namespace untuk cluster. Secara default, namespace cluster untuk Google Distributed Cloud adalah nama cluster yang diawali dengan cluster-. Misalnya, jika Anda memberi nama cluster test, namespace-nya adalah cluster-test.

  2. Di bagian loadBalancer pada file konfigurasi cluster, tetapkan mode ke bundled dan tambahkan kolom type dengan nilai bgp.

    Nilai kolom ini memungkinkan load balancing gabungan berbasis BGP.

    ...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp
    ...

  3. Untuk menentukan informasi peering BGP untuk bidang kontrol, tambahkan kolom berikut ke bagian loadBalancer:

        ...
    # AS number for the cluster
    localASN: CLUSTER_ASN

    # List of BGP peers used for the control plane peering sessions.
    bgpPeers:
    - ip: PEER_IP
      asn: PEER_ASN
      # optional; if not specified, all CP nodes connect to all peers.
      controlPlaneNodes:   # optional
      - CP_NODE_IP
...

    Ganti kode berikut:

    • CLUSTER_ASN: nomor sistem otonom untuk cluster yang sedang dibuat.
    • PEER_IP: alamat IP perangkat peer eksternal.
    • PEER_ASN: nomor sistem otonom untuk jaringan yang berisi perangkat peer eksternal.
    • CP_NODE_IP: (opsional) alamat IP node bidang kontrol yang terhubung ke peer eksternal. Jika Anda tidak menentukan node bidang kontrol, semua node bidang kontrol dapat terhubung ke peer eksternal. Jika Anda menentukan satu atau beberapa alamat IP, hanya node yang ditentukan yang berpartisipasi dalam sesi peering.

    Anda dapat menentukan beberapa peer eksternal, bgpPeers mengambil daftar pemetaan. Sebaiknya tentukan minimal dua peer eksternal untuk ketersediaan tinggi sesi BGP. Untuk contoh dengan beberapa peer, lihat Contoh konfigurasi.

  4. Tetapkan kolom loadBalancer.ports, loadBalancer.vips, dan loadBalancer.addressPools (nilai default ditampilkan).

    ...
  loadBalancer:
  ...
    # Other existing load balancer options remain the same
    ports:
      controlPlaneLBPort: 443
    # When type=bgp, the VIPs are advertised over BGP
    vips:
      controlPlaneVIP: 10.0.0.8
      ingressVIP: 10.0.0.1

    addressPools:
    - name: pool1
      addresses:
      - 10.0.0.1-10.0.0.4
...

  5. Tentukan node cluster yang akan digunakan untuk menyeimbangkan beban bidang data.

    Langkah ini opsional. Jika Anda tidak menghapus komentar pada bagian nodePoolSpec, node bidang kontrol akan digunakan untuk load balancing bidang data.

    ...
  # Node pool used for load balancing data plane (nodes where incoming traffic
  # arrives. If not specified, this defaults to the control plane node pool.
  # nodePoolSpec:
  #   nodes:
  #   - address: <Machine 1 IP>
...

  6. Cadangkan alamat IP mengambang dengan mengonfigurasi resource kustom NetworkGatewayGroup:

    Alamat IP mengambang digunakan dalam sesi peering untuk load balancing bidang data.

    ...
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
  nodeSelector:    # optional
  - NODE_SELECTOR
...

    Ganti kode berikut:

    • CLUSTER_NAMESPACE: namespace untuk cluster. Secara default, namespace cluster untuk Google Distributed Cloud adalah nama cluster yang diawali dengan cluster-. Misalnya, jika Anda memberi nama cluster test, namespace-nya adalah cluster-test.
    • FLOATING_IP: alamat IP dari salah satu subnet cluster. Anda harus menentukan setidaknya satu alamat IP, tetapi sebaiknya Anda menentukan setidaknya dua alamat IP.
    • NODE_SELECTOR: (Opsional) pemilih label untuk mengidentifikasi node untuk membuat sesi peering dengan peer eksternal, seperti switch top-of-rack (ToR). Jika tidak diperlukan, hapus kolom ini.

    Pastikan resource kustom NetworkGatewayGroup diberi nama default dan menggunakan namespace cluster. Untuk contoh tampilan spesifikasi resource kustom NetworkGatewayGroup, lihat Contoh konfigurasi.

  7. (Opsional) Tentukan peer yang akan digunakan untuk load balancing bidang data dengan mengonfigurasi resource kustom BGPLoadBalancer:

    ...
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  peerSelector:
    PEER_LABEL: "true"
...

    Ganti kode berikut:

    • CLUSTER_NAMESPACE: namespace cluster. Secara default, namespace cluster untuk Google Distributed Cloud adalah nama cluster yang diawali dengan cluster-. Misalnya, jika Anda memberi nama cluster test, namespace-nya adalah cluster-test.
    • PEER_LABEL: label yang digunakan untuk mengidentifikasi rekan yang akan digunakan untuk load balancing. Setiap resource kustom BGPPeer dengan label yang cocok menentukan detail setiap peer.

    Pastikan resource kustom BGPLoadBalancer diberi nama default dan menggunakan namespace cluster. Jika Anda tidak menentukan resource kustom BGPLoadBalancer, partner bidang kontrol akan otomatis digunakan untuk menyeimbangkan beban bidang data. Untuk contoh lengkap, lihat Contoh konfigurasi.

  8. (Opsional) Tentukan peer eksternal untuk bidang data dengan mengonfigurasi satu atau beberapa resource kustom BGPPeer:

    ...
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: BGP_PEER_NAME
  namespace: CLUSTER_NAMESPACE
  labels:
    PEER_LABEL: "true"
spec:
  localASN: CLUSTER_ASN
  peerASN: PEER_ASN
  peerIP: PEER_IP
  sessions: SESSION_QTY
  selectors:   # Optional
    gatewayRefs:
    - GATEWAY_REF
  ...

    Ganti kode berikut:

    • BGP_PEER_NAME: nama peer.
    • CLUSTER_NAMESPACE: namespace untuk cluster. Secara default, namespace cluster untuk Google Distributed Cloud adalah nama cluster yang diawali dengan cluster-. Misalnya, jika Anda memberi nama cluster test, namespace-nya adalah cluster-test.
    • PEER_LABEL: label yang digunakan untuk mengidentifikasi rekan yang akan digunakan untuk load balancing. Label ini harus sesuai dengan label yang ditentukan dalam resource kustom BGPLoadBalancer.
    • CLUSTER_ASN: nomor sistem otonom untuk cluster yang sedang dibuat.
    • PEER_IP: alamat IP perangkat peer eksternal. Sebaiknya Anda menentukan minimal dua peer eksternal, tetapi Anda harus menentukan minimal satu.
    • PEER_ASN: nomor sistem otonom untuk jaringan yang berisi perangkat peer eksternal.
    • SESSION_QTY: jumlah sesi yang akan dibuat untuk peer ini. Sebaiknya buat setidaknya dua sesi untuk memastikan Anda mempertahankan koneksi ke peer jika salah satu node Anda tidak berfungsi.
    • GATEWAY_REF: (Opsional) nama resource NetworkGatewayGroup yang akan digunakan untuk peering. Jika tidak disetel, resource gateway apa pun atau semua resource gateway dapat digunakan. Gunakan setelan ini bersama dengan kolom nodeSelector di resource NetworkGatewayGroups untuk memilih node yang akan digunakan untuk peering dengan peer eksternal tertentu, seperti switch ToR. Anda dapat memasukkan beberapa entri untuk memilih beberapa NetworkGatewayGroups, jika diinginkan, dalam format satu gateway per baris.

    Anda dapat menentukan beberapa peer eksternal dengan membuat resource kustom BGPPeer tambahan. Sebaiknya tentukan minimal dua peer eksternal (dua resource kustom) untuk ketersediaan tinggi sesi BGP. Jika Anda tidak menentukan resource kustom BGPPeer, peer bidang kontrol akan digunakan secara otomatis untuk load balancing bidang data.

  9. Saat Anda menjalankan bmctl cluster create untuk membuat cluster, pemeriksaan preflight akan dijalankan. Di antara pemeriksaan lainnya, pemeriksaan pra-penerbangan memvalidasi konfigurasi peering BGP untuk bidang kontrol dan melaporkan masalah apa pun langsung ke workstation admin sebelum cluster dapat dibuat.

    Jika berhasil, resource load balancing BGP yang ditambahkan (NetworkGatewayGroup, BGPLoadBalancer, dan BGPPeer) akan masuk ke cluster admin di namespace cluster pengguna. Gunakan file kubeconfig cluster admin saat Anda melakukan update berikutnya pada resource ini. Kemudian, cluster admin merekonsiliasi perubahan pada cluster pengguna. Jika Anda mengedit resource ini langsung di cluster pengguna, cluster admin akan mengganti perubahan Anda dalam rekonsiliasi berikutnya.

Sebaiknya gunakan kemampuan ADD-PATH BGP untuk sesi peering seperti yang ditentukan dalam RFC 7911. Secara default, protokol BGP hanya mengizinkan satu next hop diiklankan ke peer untuk satu awalan. BGP ADD-PATH memungkinkan pengiklanan beberapa hop berikutnya untuk awalan yang sama. Saat ADD-PATH digunakan dengan load balancing gabungan berbasis BGP, cluster dapat mengiklankan beberapa node cluster sebagai node frontend (hop berikutnya) untuk layanan load balancer (awalan). Aktifkan ECMP di jaringan agar traffic dapat didistribusikan ke beberapa jalur. Kemampuan untuk mendistribusikan traffic dengan mengiklankan beberapa node cluster sebagai hop berikutnya, memberikan peningkatan penskalaan kapasitas bidang data untuk load balancing.

Jika perangkat peer eksternal Anda, seperti router atau switch top-of-rack (ToR), mendukung BGP ADD-PATH, cukup aktifkan ekstensi penerimaan saja. Load balancing gabungan dengan BGP berfungsi tanpa kemampuan ADD-PATH, tetapi pembatasan pengiklanan satu node load balancing per sesi peering membatasi kapasitas bidang data load balancer. Tanpa ADD-PATH, Google Distributed Cloud memilih node untuk diiklankan dari kumpulan node load balancer dan mencoba menyebarkan next hop untuk berbagai VIP di berbagai node.

Membatasi peering BGP ke node load balancer

Google Distributed Cloud otomatis menetapkan alamat IP mengambang pada node mana pun di subnet yang sama dengan alamat IP mengambang. Sesi BGP dimulai dari alamat IP ini meskipun tidak mendarat di node load balancer. Perilaku ini sudah didesain seperti itu, karena kami telah memisahkan bidang kontrol (BGP) dari bidang data (kumpulan node LB).

Jika ingin membatasi kumpulan node yang dapat digunakan untuk peering BGP, Anda dapat menetapkan satu subnet yang hanya digunakan untuk node load balancer. Artinya, Anda dapat mengonfigurasi semua node di subnet tersebut agar berada di kumpulan node load balancer. Kemudian, saat Anda mengonfigurasi alamat IP mengambang yang digunakan untuk peering BGP, pastikan alamat IP tersebut berasal dari subnet yang sama ini. Google Distributed Cloud memastikan bahwa penetapan alamat IP mengambang dan peering BGP hanya dilakukan dari node load balancer.

Menyiapkan load balancing BGP dengan jaringan stack ganda

Mulai rilis Google Distributed Cloud 1.14.0, load balancer gabungan berbasis BGP mendukung IPv6. Dengan diperkenalkannya dukungan IPv6, Anda dapat mengonfigurasi Layanan LoadBalancer IPv6 dan stack ganda pada cluster yang dikonfigurasi untuk jaringan stack ganda. Bagian ini menjelaskan perubahan yang diperlukan untuk mengonfigurasi load balancing gabungan dual-stack dengan BGP.

Untuk mengaktifkan Layanan LoadBalancer stack ganda, perubahan konfigurasi berikut diperlukan:

  • Cluster pokok harus dikonfigurasi untuk jaringan stack ganda:

    • Tentukan CIDR Layanan IPv4 dan IPv6 dalam file konfigurasi cluster di bagian spec.clusterNetwork.services.cidrBlocks.

    • Tentukan resource ClusterCIDRConfig yang sesuai untuk menentukan rentang CIDR IPv4 dan IPv6 untuk Pod.

    Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi cluster untuk jaringan stack ganda, lihat Jaringan stack ganda IPv4/IPv6.

  • Tentukan kumpulan alamat IPv6 dalam file konfigurasi cluster di bagian spec.loadBalancer.addressPools. Agar MetalLB dapat mengalokasikan alamat IP ke Layanan Stack Ganda, harus ada setidaknya satu kumpulan alamat yang memiliki alamat berformat IPv4 dan IPv6.

Contoh konfigurasi berikut menunjukkan perubahan yang diperlukan untuk load balancing gabungan dual-stack dengan BGP:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  clusterNetwork:
  services:
      cidrBlocks:
      # Dual-stack Service IP addresses must be provided
      - 10.96.0.0/16
      - fd00::/112
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

    addressPools:
    - name: pool1
      addresses:
      # Each address must be either in the CIDR form (1.2.3.0/24)
      # or range form (1.2.3.1-1.2.3.5).
      - "203.0.113.1-203.0.113.20"
      - "2001:db8::1-2001:db8::20"  # Note the additional IPv6 range

... # Other cluster config info omitted
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-bm
spec:
  ipv4:
    cidr: "192.168.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "2001:db8:1::/112"
    perNodeMaskSize: 120

Batasan untuk load balancing stack ganda yang digabungkan dengan BGP

Saat mengonfigurasi cluster untuk menggunakan load balancing paket dengan stack ganda dan BGP, perhatikan batasan berikut:

  • Load balancing bidang kontrol IPv6 tidak didukung.

  • Sesi BGP IPv6 tidak didukung, tetapi rute IPv6 dapat diiklankan melalui sesi IPv4 menggunakan BGP Multiprotokol.

Contoh konfigurasi

Bagian berikut menunjukkan cara mengonfigurasi load balancing berbasis BGP untuk berbagai opsi atau perilaku.

Mengonfigurasi semua node agar menggunakan peer yang sama

Seperti yang ditunjukkan dalam diagram berikut, konfigurasi ini menghasilkan serangkaian peer eksternal (10.8.0.10 dan 10.8.0.11) yang dapat dijangkau oleh semua node. Node bidang kontrol (10.0.1.10, 10.0.1.11, dan 10.0.2.10) serta alamat IP mengambang (10.0.1.100 dan 10.0.2.100) yang ditetapkan ke node bidang data semuanya mencapai peer.

Peer eksternal yang sama dapat dijangkau oleh salah satu alamat IP mengambang (10.0.1.100 atau 10.0.2.100) yang dicadangkan untuk peering Layanan loadBalancer. Alamat IP mengambang dapat ditetapkan ke node yang berada di subnet yang sama.

Load balancing BGP dengan semua node menggunakan peer yang sama

Seperti yang ditunjukkan dalam contoh konfigurasi cluster berikut, Anda mengonfigurasi peer untuk node bidang kontrol, bgpPeers, tanpa menentukan controlPlaneNodes. Jika tidak ada node yang ditentukan untuk peer, semua node panel kontrol akan terhubung ke semua peer.

Anda menentukan alamat IP mengambang yang akan digunakan untuk sesi peering load balancing Layanan di resource kustom NetworkGatewayGroup. Dalam contoh ini, karena tidak ada BGPLoadBalancer yang ditentukan, peer bidang kontrol akan digunakan secara otomatis untuk sesi BGP bidang data.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

Mengonfigurasi node bidang kontrol tertentu untuk melakukan peering dengan peer eksternal tertentu

Seperti yang ditunjukkan dalam diagram berikut, konfigurasi ini menghasilkan dua node bidang kontrol (10.0.1.10 dan 10.0.1.11) yang melakukan peering dengan satu peer eksternal (10.0.1.254). Node bidang kontrol ketiga (10.0.2.10) melakukan peering dengan peer eksternal lain (10.0.2.254). Konfigurasi ini berguna jika Anda tidak ingin semua node terhubung ke semua peer. Misalnya, Anda mungkin ingin node bidang kontrol hanya melakukan peering dengan switch top-of-rack (ToR) yang sesuai.

Peer eksternal yang sama dapat dijangkau oleh salah satu alamat IP mengambang (10.0.1.100 atau 10.0.2.100) yang dicadangkan untuk sesi peering load balancing Layanan. Alamat IP mengambang dapat ditetapkan ke node yang berada di subnet yang sama.

Load balancing BGP dengan pemetaan eksplisit node bidang kontrol ke peer

Seperti yang ditunjukkan dalam contoh konfigurasi cluster berikut, Anda membatasi node bidang kontrol yang dapat terhubung ke peer tertentu dengan menentukan alamat IP-nya di kolom controlPlaneNodes untuk peer di bagian bgpPeers.

Anda menentukan alamat IP mengambang yang akan digunakan untuk sesi peering load balancing Layanan di resource kustom NetworkGatewayGroup. Dalam contoh ini, karena tidak ada BGPLoadBalancer yang ditentukan, peer bidang kontrol akan digunakan secara otomatis untuk sesi BGP bidang data.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.10

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

Mengonfigurasi bidang kontrol dan bidang data secara terpisah

Seperti yang ditunjukkan dalam diagram berikut, konfigurasi ini menghasilkan dua node bidang kontrol (10.0.1.10 dan 10.0.1.11) yang melakukan peering dengan satu peer eksternal (10.0.1.254) dan node bidang kontrol ketiga (10.0.2.11) yang melakukan peering dengan peer eksternal lain (10.0.2.254).

Peer eksternal ketiga (10.0.3.254) dapat dijangkau oleh salah satu alamat IP mengambang (10.0.3.100 atau 10.0.3.101) yang dicadangkan untuk sesi peering load balancing Services. Alamat IP mengambang dapat ditetapkan ke node yang berada di subnet yang sama.

Load balancing BGP dengan konfigurasi terpisah untuk bidang kontrol dan bidang data

Seperti yang ditunjukkan dalam contoh konfigurasi cluster berikut, Anda membatasi node bidang kontrol yang dapat terhubung ke peer tertentu dengan menentukan alamat IP-nya di kolom controlPlaneNodes untuk peer di bagian bgpPeers.

Anda menentukan alamat IP mengambang yang akan digunakan untuk sesi peering load balancing Layanan di resource kustom NetworkGatewayGroup.

Untuk mengonfigurasi load balancing bidang data:

  • Tentukan peer eksternal untuk bidang data di resource BGPPeer dan tambahkan label untuk digunakan dalam pemilihan peer, seperti cluster.baremetal.gke.io/default-peer: "true".

  • Tentukan label yang cocok untuk kolom peerSelector di resource BGPLoadBalancer.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.11

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

Mengubah konfigurasi load balancing berbasis BGP

Setelah Anda membuat cluster yang dikonfigurasi untuk menggunakan load balancing gabungan dengan BGP, beberapa setelan konfigurasi dapat diperbarui, tetapi beberapa setelan tidak dapat diperbarui setelah cluster dibuat.

Gunakan file kubeconfig cluster admin saat Anda melakukan update berikutnya pada resource terkait BGP (NetworkGatewayGroup, BGPLoadBalancer, dan BGPPeer). Kemudian, cluster admin merekonsiliasi perubahan ke cluster pengguna. Jika Anda mengedit resource ini langsung di cluster pengguna, cluster admin akan menggantikan perubahan Anda dalam rekonsiliasi berikutnya.

Bidang kontrol

Informasi peering BGP bidang kontrol dapat diperbarui di resource Cluster. Anda dapat menambahkan atau menghapus peer yang ditentukan di bagian load balancing bidang kontrol.

Bagian berikut menguraikan praktik terbaik untuk memperbarui informasi peering BGP control plane Anda.

Memeriksa status peer sebelum memperbarui

Untuk meminimalkan risiko kesalahan konfigurasi peer, periksa apakah sesi peering BGP panel kontrol berada dalam status yang diharapkan sebelum melakukan perubahan. Misalnya, jika Anda mengharapkan semua sesi peering BGP saat ini aktif, maka verifikasi bahwa semua Pod bgp-advertiser melaporkan ready, yang menunjukkan bahwa sesi aktif. Jika status saat ini tidak sesuai dengan yang Anda harapkan, perbaiki masalahnya sebelum memperbarui konfigurasi peer.

Untuk mengetahui informasi tentang pengambilan detail sesi BGP bidang kontrol, lihat Sesi BGP bidang kontrol.

Memperbarui peer secara terkontrol

Perbarui satu peer dalam satu waktu, jika memungkinkan, untuk membantu mengisolasi kemungkinan masalah:

  1. Menambahkan atau memperbarui satu peer.
  2. Tunggu hingga konfigurasi disesuaikan.
  3. Pastikan cluster dapat terhubung ke peer baru atau yang diupdate.
  4. Hapus peer lama atau yang tidak diperlukan.

Layanan

Untuk memperbarui kumpulan alamat dan setelan node load balancer, edit nodePoolSpec di resource Cluster.

Untuk mengubah konfigurasi peering BGP setelah cluster Anda dibuat, edit resource kustom NetworkGatewayGroup dan BGPLoadBalancer. Setiap modifikasi pada informasi peering di resource kustom ini akan tercermin dalam konfigurasi solusi penyeimbangan beban di cluster target.

Lakukan pembaruan pada resource sumber di namespace cluster di cluster admin saja. Setiap modifikasi yang dilakukan pada resource di cluster target (pengguna) akan ditimpa.

Pemecahan masalah

Bagian berikut menjelaskan cara mengakses informasi pemecahan masalah untuk load balancing gabungan dengan BGP.

Sesi BGP bidang kontrol

Konfigurasi peering BGP bidang kontrol divalidasi dengan pemeriksaan pra-peluncuran selama pembuatan cluster. Pemeriksaan awal mencoba untuk:

  • Buat koneksi BGP dengan setiap peer.
  • Mengiklankan VIP bidang kontrol.
  • Pastikan bahwa node bidang kontrol dapat dijangkau, menggunakan VIP.

Jika pembuatan cluster Anda gagal dalam pemeriksaan preflight, tinjau log pemeriksaan preflight untuk mengetahui error. File log pemeriksaan pra-penerbangan yang diberi stempel tanggal berada di direktori baremetal/bmctl-workspace/CLUSTER_NAME/log.

Saat runtime, speaker BGP bidang kontrol berjalan sebagai pod statis di setiap node bidang kontrol dan menulis informasi peristiwa ke log. Pod statis ini menyertakan "bgpadvertiser" dalam namanya, jadi gunakan perintah kubectl get pods berikut untuk melihat status Pod speaker BGP:

kubectl -n kube-system get pods | grep bgpadvertiser

Jika Pod beroperasi dengan benar, responsnya akan terlihat seperti berikut:

bgpadvertiser-node-01                            1/1     Running   1          167m
bgpadvertiser-node-02                            1/1     Running   1          165m
bgpadvertiser-node-03                            1/1     Running   1          163m

Gunakan perintah berikut untuk melihat log untuk Pod bgpadvertiser-node-01:

kubectl -n kube-system logs bgpadvertiser-node-01

Sesi BGP layanan

Resource BGPSession memberikan informasi tentang sesi BGP saat ini. Untuk mendapatkan informasi sesi, dapatkan sesi saat ini terlebih dahulu, lalu ambil resource BGPSession untuk salah satu sesi.

Gunakan perintah kubectl get berikut untuk mencantumkan sesi saat ini:

kubectl -n kube-system get bgpsessions

Perintah ini akan menampilkan daftar sesi seperti contoh berikut:

NAME                 LOCAL ASN   PEER ASN   LOCAL IP     PEER IP      STATE            LAST REPORT
10.0.1.254-node-01   65500       65000      10.0.1.178   10.0.1.254   Established      2s
10.0.1.254-node-02   65500       65000      10.0.3.212   10.0.1.254   Established      2s
10.0.3.254-node-01   65500       65000      10.0.1.178   10.0.3.254   Established      2s
10.0.3.254-node-02   65500       65000      10.0.3.212   10.0.3.254   Established      2s

Gunakan perintah kubectl describe berikut untuk mendapatkan resource BGPSession untuk sesi BGP 10.0.1.254-node-01:

kubectl -n kube-system describe bgpsession 10.0.1.254-node-01

Resource BGPSession yang ditampilkan akan terlihat seperti contoh berikut:

Name:         10.0.1.254-node-01
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         BGPSession
Metadata:
 (omitted)
Spec:
  Floating IP:  10.0.1.178
  Local ASN:    65500
  Local IP:     10.0.1.178
  Node Name:    node-01
  Peer ASN:     65000
  Peer IP:      10.0.1.254
Status:
  Advertised Routes:
    10.0.4.1/32
  Last Report Time:  2021-06-14T22:09:36Z
  State:             Established

Gunakan perintah kubectl get untuk mendapatkan resource BGPAdvertisedRoute:

kubectl -n kube-system get bgpadvertisedroutes

Respons, yang akan terlihat mirip dengan contoh berikut, menunjukkan rute yang saat ini diiklankan:

NAME                                    PREFIX           METRIC
default-default-load-balancer-example   10.1.1.34/32
default-gke-system-istio-ingress        10.1.1.107/32

Gunakan kubectl describe untuk melihat detail tentang next hop yang diiklankan oleh setiap rute.

Memulihkan akses ke VIP bidang kontrol untuk cluster yang dikelola sendiri

Untuk mendapatkan kembali akses ke VIP bidang kontrol di cluster admin, hybrid, atau mandiri, Anda harus memperbarui konfigurasi BGP di cluster. Seperti yang ditunjukkan dalam contoh perintah berikut, gunakan SSH untuk terhubung ke node, lalu gunakan kubectl untuk membuka resource cluster untuk diedit.

ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP

kubectl --kubeconfig /etc/kubernetes/admin.conf edit -n CLUSTER_NAMESPACE cluster CLUSTER_NAME

Ganti kode berikut:

  • IDENTITY_FILE: nama file identitas SSH yang berisi kunci identitas untuk autentikasi kunci publik.
  • CLUSTER_NODE_IP: alamat IP untuk node cluster.
  • CLUSTER_NAMESPACE: namespace cluster.
  • CLUSTER_NAME: nama cluster.

Ubah konfigurasi peering BGP di objek cluster. Setelah menyimpan konfigurasi cluster baru, pantau kondisi pod bgpadvertiser. Jika konfigurasi berhasil, pod akan dimulai ulang dan menjadi responsif setelah terhubung ke peer-nya.

Verifikasi BGP manual

Bagian ini berisi petunjuk untuk memverifikasi konfigurasi BGP secara manual. Prosedur ini menyiapkan koneksi BGP yang berjalan lama sehingga Anda dapat men-debug lebih lanjut konfigurasi BGP dengan tim jaringan Anda. Gunakan prosedur ini untuk memverifikasi konfigurasi Anda sebelum membuat cluster atau menggunakannya jika pemeriksaan preflight terkait BGP gagal.

Pemeriksaan pra-penerbangan mengotomatiskan tugas verifikasi BGP berikut:

  • Siapkan koneksi BGP ke peer.
  • Mengiklankan VIP bidang kontrol.
  • Pastikan traffic yang dikirim dari semua node cluster lainnya ke VIP mencapai node load balancer saat ini.

Tugas ini dijalankan untuk setiap peer BGP di setiap node bidang kontrol. Lulus pemeriksaan ini sangat penting saat membuat cluster. Namun, pemeriksaan pra-penerbangan tidak membuat koneksi yang berjalan lama, sehingga sulit untuk men-debug kegagalan.

Bagian berikut memberikan petunjuk untuk menyiapkan koneksi BGP dan mengiklankan rute dari satu mesin cluster ke satu peer. Untuk menguji beberapa mesin dan beberapa peer, ulangi petunjuk lagi, menggunakan kombinasi mesin dan peer yang berbeda.

Ingatlah bahwa koneksi BGP dibuat dari node bidang kontrol, jadi pastikan untuk menguji prosedur ini dari salah satu node bidang kontrol yang direncanakan.

Mendapatkan biner program pengujian BGP

Jalankan langkah-langkah di bagian ini di workstation admin Anda. Langkah-langkah ini akan mendapatkan program bgpadvertiser yang digunakan untuk menguji koneksi BGP dan menyalinnya ke node bidang kontrol tempat Anda ingin melakukan pengujian.

  1. Tarik image Docker ansible-runner.

    Tanpa Pencerminan Registry

    Jika Anda tidak menggunakan mirror registry, jalankan perintah berikut untuk menarik image Docker ansible-runner:

    gcloud auth login
gcloud auth configure-docker
docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Dengan Mirror Registry

    Jika Anda menggunakan mirror registry, jalankan perintah berikut untuk menarik image Docker ansible-runner:

    docker login REGISTRY_HOST
docker pull REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Ganti REGISTRY_HOST dengan nama server mirror registry Anda.

  2. Untuk mengekstrak biner bgpadvertiser.

    Tanpa Pencerminan Registry

    Untuk mengekstrak biner bgpadvertiser, jalankan perintah berikut:

    docker cp $(docker create gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

    Dengan Mirror Registry

    Untuk mengekstrak biner bgpadvertiser, jalankan perintah berikut:

    docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

  3. Untuk menyalin biner bgpadvertiser ke node control plane yang ingin Anda gunakan untuk pengujian, jalankan perintah berikut:

    scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/

    Ganti kode berikut:

    • USERNAME: nama pengguna yang Anda gunakan untuk mengakses node bidang kontrol.

    • CP_NODE_IP: alamat IP node bidang kontrol.

Menyiapkan koneksi BGP

Jalankan langkah-langkah di bagian ini pada node bidang kontrol.

  1. Buat file konfigurasi di node di /tmp/bgpadvertiser.conf yang terlihat seperti berikut:

    localIP: NODE_IP
localASN: CLUSTER_ASN
peers:
- peerIP: PEER_IP
  peerASN: PEER_ASN

    Ganti kode berikut:

    • NODE_IP: Alamat IP node bidang kontrol yang Anda gunakan.
    • CLUSTER_ASN: nomor sistem otonom yang digunakan oleh cluster.
    • PEER_IP: alamat IP salah satu peer eksternal yang ingin Anda uji.
    • PEER_ASN: nomor sistem otonom untuk jaringan yang berisi perangkat peer eksternal.

  2. Jalankan daemon bgpadvertiser, dengan mengganti VIP panel kontrol dalam perintah berikut:

    /tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIP

    Ganti CONTROL_PLANE_VIP dengan alamat IP yang akan Anda gunakan untuk VIP bidang kontrol. Perintah ini menyebabkan pengiklan BGP mengiklankan alamat ini ke peer.

  3. Lihat output program.

    Pada tahap ini, daemon bgpadvertiser akan dimulai, mencoba terhubung ke peer, dan mengiklankan VIP. Program ini secara berkala mencetak pesan (lihat contoh output berikut) yang menyertakan BGP_FSM_ESTABLISHED saat koneksi BGP dibuat.

    {"level":"info","ts":1646788815.5588224,"logger":"BGPSpeaker","msg":"GoBGP gRPC debug endpoint disabled","localIP":"21.0.101.64"}
{"level":"info","ts":1646788815.5596201,"logger":"BGPSpeaker","msg":"Started.","localIP":"21.0.101.64"}
I0309 01:20:15.559667 1320826 main.go:154] BGP advertiser started.
I0309 01:20:15.561434 1320826 main.go:170] Health status HTTP server started at "127.0.0.1:8080".
INFO[0000] Add a peer configuration for:21.0.101.80      Topic=Peer
{"level":"info","ts":1646788815.5623345,"logger":"BGPSpeaker","msg":"Peer added.","localIP":"21.0.101.64","peer":"21.0.101.80/4273481989"}
DEBU[0000] IdleHoldTimer expired                         Duration=0 Key=21.0.101.80 Topic=Peer
I0309 01:20:15.563503 1320826 main.go:187] Peer applied: {4273481989 21.0.101.80}
DEBU[0000] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ACTIVE old=BGP_FSM_IDLE reason=idle-hold-timer-expired
DEBU[0000] create Destination                            Nlri=10.0.0.1/32 Topic=Table
{"level":"info","ts":1646788815.5670514,"logger":"BGPSpeaker","msg":"Route added.","localIP":"21.0.101.64","route":{"ID":0,"Metric":0,"NextHop":"21.0.101.64","Prefix":"10.0.0.1/32","VRF":""}}
I0309 01:20:15.568029 1320826 main.go:199] Route added: {0 0 21.0.101.64 10.0.0.1/32 }
I0309 01:20:15.568073 1320826 main.go:201] BGP advertiser serving...
DEBU[0005] try to connect                                Key=21.0.101.80 Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENSENT old=BGP_FSM_ACTIVE reason=new-connection
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENCONFIRM old=BGP_FSM_OPENSENT reason=open-msg-received
INFO[0005] Peer Up                                       Key=21.0.101.80 State=BGP_FSM_OPENCONFIRM Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ESTABLISHED old=BGP_FSM_OPENCONFIRM reason=open-msg-negotiated
DEBU[0005] sent update                                   Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer attributes="[{Origin: i} 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] received update                               Key=21.0.101.80 Topic=Peer attributes="[{Origin: i} 4273481989 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] create Destination                            Nlri=10.0.0.1/32 Topic=Table
DEBU[0035] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"
DEBU[0065] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"

Jika Anda tidak melihat pesan ini, periksa kembali parameter konfigurasi BGP dalam file konfigurasi dan verifikasi dengan administrator jaringan. Sekarang Anda telah menyiapkan koneksi BGP. Anda dapat memverifikasi dengan administrator jaringan bahwa mereka melihat koneksi yang dibuat di sisi mereka dan bahwa mereka melihat rute yang diiklankan kepada mereka.

Uji traffic

Untuk menguji apakah jaringan dapat meneruskan traffic ke VIP, Anda harus menambahkan VIP ke node bidang kontrol yang menjalankan bgpadvertiser. Jalankan perintah berikut di terminal lain agar Anda dapat membiarkan bgpadvertiser berjalan:

  1. Tambahkan VIP ke node bidang kontrol Anda:

    ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME

    Ganti kode berikut:

    • CONTROL_PLANE_VIP: argumen VIP --advertise-ip dari bgpadvertiser.
    • INTF_NAME: antarmuka Kubernetes di node. Artinya, antarmuka yang memiliki alamat IP yang Anda masukkan dalam konfigurasi Google Distributed Cloud untuk loadBalancer.bgpPeers.controlPlaneNodes.

  2. Ping VIP dari node lain:

    ping CONTROL_PLANE_VIP

    Jika ping tidak berhasil, mungkin ada masalah dengan konfigurasi BGP di perangkat jaringan. Hubungi administrator jaringan Anda untuk memverifikasi konfigurasi dan menyelesaikan masalah ini.

Pembersihan

Pastikan untuk mengikuti langkah-langkah ini guna mereset node setelah Anda memverifikasi secara manual bahwa BGP berfungsi. Jika Anda tidak mereset node dengan benar, penyiapan manual dapat mengganggu pemeriksaan awal atau pembuatan cluster berikutnya.

  1. Hapus VIP dari node bidang kontrol jika Anda menambahkannya untuk pengujian traffic:

    ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME

  2. Di node bidang kontrol, tekan Ctrl+C di terminal bgpadvertiser untuk menghentikan bgpadvertiser.

  3. Pastikan tidak ada proses bgpadvertiser yang sedang berjalan:

    ps -ef | grep bgpadvertiser

  4. Jika Anda melihat proses sedang berjalan, hentikan proses tersebut menggunakan perintah kill.