Mengonfigurasi load balancer yang dipaketkan dengan BGP

Dokumen ini menjelaskan cara menyiapkan dan menggunakan load balancer yang dipaketkan dengan Border Gateway Protocol (BGP) untuk Google Distributed Cloud. Mode load balancing ini mendukung iklan ServiceType LoadBalancer alamat IP virtual (VIP) melalui Border Gateway Protocol (eBGP) eksternal untuk cluster Anda. Di beberapa dalam skenario ini, jaringan cluster Anda adalah sistem otonom, yang saling menghubungkan dengan sistem otonom lainnya, jaringan eksternal, melalui peering.

Load balancer yang dipaketkan dengan kemampuan BGP berlaku untuk semua jenis cluster, tetapi admin hanya mendukung bagian load balancing bidang kontrol dari kemampuan IT mereka.

Penggunaan paket load balancer dengan fitur BGP memberikan hal berikut manfaat:

  • Menggunakan kemampuan load balancing aktif/aktif N-way, yang memberikan failover dan penggunaan bandwidth yang tersedia secara lebih efisien.
  • Mendukung protokol Lapisan 3 yang beroperasi dengan top-of-rack (ToR) pihak ketiga {i>switch dan router<i} yang kompatibel dengan eBGP.
  • Memungkinkan pusat data yang menjalankan software-defined yang canggih (SDN) untuk mendorong batas Lapisan 3 ke klaster.

Cara kerja load balancing yang dipaketkan dengan BGP

Bagian berikut memberikan ringkasan singkat tentang paket load balancer dengan tugas BGP.

Peering BGP

Load balancer yang dipaketkan 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 mengambang yang Anda tentukan di resource kustom NetworkGatewayGroup.
  • Gateway Jaringan untuk pengontrol GDC mengelola alamat IP mengambang.
  • Load balancing berbasis BGP dipaket 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 pembanding mana pun diharapkan untuk didistribusikan ulang ke seluruh jaringan dan dapat dijangkau dari tempat lain di cluster.
  • Penggunaan kemampuan ADD-PATH BGP dalam mode terima direkomendasikan untuk peering sesi.
  • Mengiklankan beberapa jalur dari setiap pembanding menghasilkan pemuatan aktif/aktif balancing.
  • {i>Equal-cost multipath routing <i}(ECMP) harus diaktifkan untuk jaringan Anda agar jaringan beberapa jalur dapat digunakan untuk menyebarkan lalu lintas data pada satu rangkaian node balancer.

Load balancing bidang kontrol

Tiap node bidang kontrol di cluster Anda menetapkan sesi BGP dengan satu atau lebih banyak rekan di infrastruktur Anda. Kita mengharuskan setiap node bidang kontrol memiliki setidaknya satu rekan. Di file konfigurasi cluster, Anda dapat mengonfigurasi {i>node<i} bidang kontrol terhubung ke rekan-rekan eksternal mana.

Diagram berikut menunjukkan contoh peering bidang kontrol. Cluster ini memiliki dua node bidang kontrol di satu subnet dan satu di subnet lainnya. Ada direktori eksternal peer (TOR) di setiap subnet dan node bidang kontrol Google Distributed Cloud rekan dengan TOR mereka.

Load balancing layanan dengan peering BGP

Load balancing layanan

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

Layanan dengan kebijakan jaringan externalTrafficPolicy=Local didukung. Namun, setelan externalTrafficPolicy=Local bergantung pada workload dan menyebabkan rute diperbarui setiap kali Pod yang mendukung Service ditambahkan atau dihapus sepenuhnya dari sebuah {i>node<i}. Perilaku pembaruan rute ini dapat menyebabkan Biaya yang Sama Pemilihan rute Multi-Jalur (ECMP) untuk mengubah alur traffic, yang dapat mengakibatkan penurunan kemacetan.

Alamat IP floating

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

Alamat IP mengambang menghilangkan kekhawatiran atas pemetaan alamat IP speaker BGP ke node. Pengontrol Jaringan Gateway untuk GDC menangani penetapan NetworkGatewayGroup ke node dan juga mengelola alamat IP mengambang. Jika node nonaktif, Gateway Jaringan untuk pengontrol GDC akan ditetapkan ulang alamat IP mengambang untuk memastikan bahwa peer eksternal memiliki IP deterministik yang harus dituju.

Pembanding eksternal

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

Jika Anda ingin menentukan peer BGP yang berbeda untuk peering bidang data, tambahkan Spesifikasi resource BGPLoadBalancer dan BGPPeer untuk cluster file konfigurasi Anda. Jika Anda tidak menetapkan resource kustom ini, kontrol peer pesawat digunakan secara otomatis di bidang data.

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

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

Node load balancer

Sebuah subset node dari cluster digunakan untuk load balancing, yang berarti node tersebut apakah node yang diiklankan dapat menerima traffic load balancing yang masuk. Kumpulan node ini ditetapkan secara default ke kumpulan node bidang kontrol, tetapi Anda dapat menentukan kumpulan node yang berbeda di bagian loadBalancer pada konfigurasi cluster . Jika ditetapkan, node pool akan digunakan untuk node load balancer, alih-alih kumpulan node bidang kontrol.

Alamat IP mengambang, yang berfungsi sebagai speaker BGP, dapat berjalan atau tidak ke node load balancer. Alamat IP mengambang ditetapkan ke node di subnet dan peering yang sama dimulai dari sana, terlepas dari apakah load balancer Google Cloud. Namun, next hop yang diberitahukan melalui BGP selalu merupakan beban node balancer.

Contoh topologi peering

Diagram berikut menunjukkan contoh load balancing Layanan dengan BGP peering. Ada dua alamat IP mengambang yang ditetapkan ke node dalam subnet yang sesuai. Ada dua pembanding eksternal yang ditentukan. Setiap peer IP mengambang dengan kedua rekan eksternal.

Load balancing layanan dengan peering BGP

Menyiapkan load balancer BGP

Bagian berikut menjelaskan cara mengonfigurasi cluster dan konfigurasi cluster jaringan Google Cloud untuk menggunakan load balancer yang dipaketkan dengan BGP.

Rencanakan integrasi Anda dengan infrastruktur eksternal

Untuk menggunakan load balancer yang dipaketkan dengan BGP, Anda harus menyiapkan infrastruktur:

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

  • Infrastruktur eksternal harus dikonfigurasikan untuk peer dengan serangkaian alamat IP mengambang untuk komunikasi bidang data. IP mengambang alamat yang digunakan untuk peering BGP untuk VIP Layanan. Sebaiknya menggunakan dua alamat IP mengambang dan dua peer untuk memastikan ketersediaan tinggi untuk Sesi BGP. Proses reservasi IP mengambang dijelaskan sebagai bagian dari mengonfigurasi cluster untuk paket load balancing dengan BGPnya.

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

Mengonfigurasi cluster Anda untuk paket load balancing dengan BGP

Anda mengaktifkan dan mengonfigurasi load balancing yang dipaketkan dengan BGP di cluster file konfigurasi Anda saat membuat cluster. Dalam file konfigurasi cluster, aktifkan jaringan lanjutan dan perbarui bagian loadBalancer. Anda juga tambahkan spesifikasi untuk tiga resource kustom berikut:

  • NetworkGatewayGroup: menentukan alamat IP mengambang yang digunakan untuk Layanan peering BGP layanan.

  • BGPLoadBalancer: menentukan dengan pemilih label mana pembanding digunakan Load balancing BGP.

  • BGPPeer: menentukan pembanding individual, termasuk label untuk pilihan eksternal, untuk sesi peering BGP.

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

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

    Bidang ini memungkinkan kemampuan jaringan lanjutan, khususnya Jaringan ke resource 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 menamai cluster test, namespace-nya akan cluster-test.

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

    Nilai kolom ini mengaktifkan load balancing paket 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 peer eksternal perangkat seluler.
    • PEER_ASN: nomor sistem otonom untuk yang berisi perangkat peer eksternal.
    • CP_NODE_IP: (opsional) alamat IP bidang kontrol yang terhubung ke peer eksternal. Jika Anda tidak menentukan node bidang kontrol, semua node bidang kontrol dapat terhubung dari rekan eksternal. Jika Anda menentukan satu atau beberapa alamat IP, hanya spesifik yang berpartisipasi dalam sesi peering.

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

  4. Setel loadBalancer.ports, loadBalancer.vips, dan Kolom 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 melakukan load balancing pada bidang data.

    Langkah ini opsional. Jika Anda tidak menghapus tanda komentar di bagian nodePoolSpec, node bidang kontrol digunakan untuk {i>load balancing<i} 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 NetworkGatewayGroup resource kustom:

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

    ...
---
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: untuk cluster tersebut. Secara default, namespace cluster untuk Google Distributed Cloud adalah nama cluster yang diawali dengan cluster-. Misalnya, jika Anda menamai cluster test, namespace akan adalah cluster-test.
    • FLOATING_IP: alamat IP dari salah satu subnet cluster Anda. Anda harus menentukan setidaknya satu alamat IP, tetapi kami sarankan Anda untuk menentukan setidaknya dua alamat IP.
    • NODE_SELECTOR: (Opsional) pemilih label untuk mengidentifikasi node untuk membuat instance sesi peering dengan peer eksternal, seperti sakelar {i>top-of-rack<i} (ToR). Jika tidak diperlukan, hapus kolom tersebut.

    Pastikan resource kustom NetworkGatewayGroup diberi nama default dan menggunakan namespace cluster. Contoh tampilan NetworkGatewayGroup spesifikasi resource kustom. Lihat Contoh konfigurasi.

  7. (Opsional) Tentukan pembanding 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. Secara default, namespace cluster untuk Google Distributed Cloud adalah nama cluster yang diawali dengan cluster-. Misalnya, jika Anda menamai cluster test, namespace akan adalah cluster-test.
    • PEER_LABEL: label yang digunakan untuk mengidentifikasi pembanding untuk load balancing. Semua resource kustom BGPPeer dengan label pencocokan menentukan detail setiap pembanding.

    Pastikan resource kustom BGPLoadBalancer diberi nama default dan menggunakan namespace cluster. Jika Anda tidak menentukan resource kustom BGPLoadBalancer, peer bidang kontrol digunakan secara otomatis untuk beban bidang data balancing. Untuk contoh yang komprehensif, lihat Contoh konfigurasi.

  8. (Opsional) Tentukan pembanding eksternal untuk bidang data dengan mengonfigurasinya atau lebih banyak 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 pembanding.
    • CLUSTER_NAMESPACE: untuk cluster tersebut. Secara default, namespace cluster untuk Google Distributed Cloud adalah nama cluster yang diawali dengan cluster-. Misalnya, jika Anda menamai cluster test, namespace akan adalah cluster-test.
    • PEER_LABEL: label yang digunakan untuk mengidentifikasi pembanding 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 peer eksternal perangkat seluler. Sebaiknya tentukan minimal dua pembanding eksternal, tetapi Anda harus menentukan setidaknya satu.
    • PEER_ASN: nomor sistem otonom untuk yang berisi perangkat peer eksternal.
    • SESSION_QTY: jumlah sesi yang akan buat rekan ini. Sebaiknya tetapkan setidaknya dua sesi untuk memastikan bahwa Anda menjaga koneksi dengan rekan jika terjadi salah satu node Anda tidak berfungsi.
    • GATEWAY_REF: (Opsional) nama Resource NetworkGatewayGroup yang akan digunakan untuk peering. Jika tidak disetel, setiap atau dapat digunakan semua resource gateway. Gunakan setelan ini bersama dengan kolom nodeSelector di resource NetworkGatewayGroups untuk memilih node mana yang akan digunakan untuk peering dengan peer eksternal tertentu, seperti Tombol ToR. Dibutuhkan beberapa entri untuk memilih beberapa NetworkGatewayGroups, jika diinginkan, dalam format satu gateway per baris.

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

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

    Setelah berhasil, resource load balancing BGP tambahan (NetworkGatewayGroup, BGPLoadBalancer, dan BGPPeer) masuk ke cluster admin di cluster pengguna namespace. Gunakan file kubeconfig cluster admin saat Anda membuat pembaruan untuk sumber daya ini. Cluster admin kemudian merekonsiliasi perubahan dengan cluster pengguna. Jika Anda mengedit resource ini di cluster pengguna secara langsung, admin akan menimpa perubahan Anda dalam rekonsiliasi berikutnya.

Sebaiknya gunakan kemampuan ADD-PATH BGP untuk sesi peering sebagai ditentukan dalam RFC 7911. Secara default, protokol BGP hanya mengizinkan satu hop berikutnya yang dapat diiklankan pembanding untuk satu awalan. ADD-PATH BGP memungkinkan periklanan beberapa hop berikutnya untuk awalan yang sama. Jika ADD-PATH digunakan dengan beban paket berbasis BGP load balancing, cluster dapat mengiklankan beberapa node cluster sebagai node frontend (hop berikutnya) untuk layanan load balancer (awalan). Aktifkan ECMP di jaringan sehingga lalu lintas itu dapat tersebar di beberapa jalur. Kemampuan untuk menyebarkan traffic dengan mengiklankan beberapa node cluster sebagai next hop, memberikan penskalaan kapasitas bidang data untuk load balancing.

Jika perangkat peer eksternal Anda, seperti router atau tombol rak atas (ToR), mendukung ADD-PATH BGP, Anda cukup mengaktifkan ekstensi terima saja. Load balancing paket dengan BGP berfungsi tanpa kemampuan ADD-PATH, tetapi pembatasan iklan node load balancing tunggal 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 berupaya menyebarkan hop berikutnya untuk VIP yang berbeda di berbagai node.

Membatasi peering BGP ke node load balancer

Google Distributed Cloud otomatis menetapkan alamat IP mengambang pada node apa pun di subnet yang sama dengan alamat IP mengambang. Sesi BGP dimulai dari alamat IP ini meskipun tidak sampai di node load balancer. Ini adalah berdasarkan desain, karena kita telah memisahkan bidang kontrol (BGP) dari bidang data (kumpulan node LB).

Jika ingin membatasi kumpulan node yang dapat digunakan untuk peering BGP, Anda harus dapat menetapkan satu subnet yang hanya akan digunakan untuk node load balancer. Yaitu, Anda dapat mengonfigurasi semua node dalam subnet tersebut agar berada di kumpulan node load balancer. Kemudian, ketika Anda mengonfigurasi alamat IP mengambang yang digunakan untuk peering BGP, memastikan bahwa mereka berasal dari {i>subnet<i} yang sama. Google Distributed Cloud memastikan bahwa penetapan alamat IP mengambang dan peering BGP berlangsung dari load balancer node saja.

Menyiapkan load balancing BGP dengan jaringan dual-stack

Dimulai dengan rilis Google Distributed Cloud 1.14.0, paket beban berbasis BGP load balancer mendukung IPv6. Dengan diperkenalkannya dukungan IPv6, Anda dapat mengkonfigurasi Layanan LoadBalancer dual-stack dan IPv6 di cluster yang dikonfigurasi untuk dual-stack berjejaring (netrworking){b>.<b} Bagian ini menjelaskan perubahan yang diperlukan untuk mengonfigurasi dual-stack, paket load balancing dengan BGP.

Untuk mengaktifkan Layanan LoadBalancer dual-stack, perubahan konfigurasi berikut wajib diisi:

  • Cluster pokok harus dikonfigurasi untuk jaringan dual-stack:

    • Menentukan CIDR Layanan IPv4 dan IPv6 di file konfigurasi cluster di bawah spec.clusterNetwork.services.cidrBlocks.

    • Menentukan resource ClusterCIDRConfig yang sesuai untuk menentukan IPv4 dan IPv6 Rentang CIDR untuk Pod.

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

  • Tentukan kumpulan alamat IPv6 dalam file konfigurasi cluster di bagian spec.loadBalancer.addressPools. Agar dapat MetalLB untuk mengalokasikan alamat IP ke Dual Stack Service, setidaknya harus ada satu kumpulan alamat yang memiliki format IPv4 dan IPv6 untuk alamat internal dan eksternal.

Contoh konfigurasi berikut menyoroti perubahan yang diperlukan untuk dual-stack paket load balancing 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 dual-stack dan dipaketkan dengan BGP

Saat mengonfigurasi cluster untuk menggunakan load balancing dual-stack, dipaketkan dengan 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 Multiprotocol BGP.

Contoh konfigurasi

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

Mengonfigurasi semua node menggunakan pembanding 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) dan IP mengambang alamat (10.0.1.100 dan 10.0.2.100) yang ditetapkan ke node bidang data, semuanya menjangkau rekan-rekan Anda.

Peering eksternal yang sama keduanya dapat dijangkau oleh salah satu IP mengambang alamat (10.0.1.100 atau 10.0.2.100) yang dicadangkan untuk loadBalancer Peering layanan. Alamat IP mengambang dapat ditetapkan ke {i>node<i} yang berada dalam subnet yang sama.

Load balancing BGP di mana semua node menggunakan peer yang sama

Seperti yang ditunjukkan pada contoh konfigurasi cluster berikut, Anda mengonfigurasi pembanding untuk node bidang kontrol, bgpPeers, tanpa menentukan controlPlaneNodes. Jika tidak ada node yang ditentukan untuk peer, maka semua node bidang kontrol akan terhubung semua rekan.

Anda menentukan alamat IP mengambang yang akan digunakan untuk peering load balancing Layanan sesi di resource kustom NetworkGatewayGroup. Dalam contoh ini, karena tidak BGPLoadBalancer telah ditentukan, pembanding bidang kontrol 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 pembanding eksternal tertentu

Seperti yang ditunjukkan dalam diagram berikut, konfigurasi ini menghasilkan dua kontrol node bidang (10.0.1.10 dan 10.0.1.11) dengan satu peer eksternal (10.0.1.254). Node bidang kontrol ketiga (10.0.2.10) melakukan peering dengan pembanding eksternal (10.0.2.254). Konfigurasi ini berguna ketika Anda tidak ingin semua {i>node<i} terhubung ke semua rekan-rekan. Misalnya, Anda mungkin ingin node bidang untuk di-peering dengan hanya switch rak teratas (ToR) yang sesuai.

Peering eksternal yang sama keduanya dapat dijangkau oleh salah satu IP mengambang alamat (10.0.1.100 atau 10.0.2.100) yang dicadangkan untuk Layanan sesi peering load balancing. 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 pada contoh konfigurasi cluster berikut, Anda membatasi bidang kontrol dapat terhubung ke peer tertentu dengan menentukan alamat IP-nya di kolom controlPlaneNodes untuk pembanding di bagian bgpPeers.

Anda menentukan alamat IP mengambang yang akan digunakan untuk peering load balancing Layanan sesi di resource kustom NetworkGatewayGroup. Dalam contoh ini, karena tidak BGPLoadBalancer telah ditentukan, pembanding bidang kontrol 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 kontrol node bidang (10.0.1.10 dan 10.0.1.11) dengan satu peer eksternal (10.0.1.254) dan node bidang kontrol ketiga (10.0.2.11) yang melakukan peering dengan pembanding eksternal (10.0.2.254).

Peering eksternal ketiga (10.0.3.254) dapat dijangkau oleh salah satu IP mengambang alamat (10.0.3.100 atau 10.0.3.101) yang dicadangkan untuk Layanan sesi peering load balancing. 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 pada contoh konfigurasi cluster berikut, Anda membatasi bidang kontrol dapat terhubung ke peer tertentu dengan menentukan alamat IP-nya di kolom controlPlaneNodes untuk pembanding di bagian bgpPeers.

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

Untuk mengonfigurasi load balancing bidang data:

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

  • Tentukan label yang cocok untuk kolom peerSelector di bagian 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 Anda

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

Gunakan file kubeconfig cluster admin saat Anda melakukan pembaruan berikutnya pada Resource terkait BGP (NetworkGatewayGroup, BGPLoadBalancer, dan BGPPeer). Tujuan lalu merekonsiliasi perubahan pada cluster pengguna tersebut. Jika Anda mengeditnya resource di cluster pengguna secara langsung, cluster admin akan menimpa perubahan pada rekonsiliasi berikutnya.

Bidang kontrol

Informasi peering BGP bidang kontrol dapat diupdate di resource Cluster. Anda dapat menambahkan atau menghapus pembanding yang ditentukan dalam load balancing bidang kontrol bagian.

Bagian berikut menguraikan praktik terbaik untuk memperbarui kontrol menyediakan informasi peering BGP.

Memeriksa status pembanding sebelum mengupdate

Untuk meminimalkan risiko salah mengonfigurasi peer, periksa bidang kontrol BGP sesi peering berada dalam status yang diharapkan sebelum melakukan perubahan. Misalnya, jika Anda memperkirakan bahwa semua sesi peering BGP saat ini sudah aktif, maka pastikan bgp-advertiser Pod melaporkan ready, yang menunjukkan bahwa sesi sudah naik. Jika status saat ini tidak sesuai dengan yang Anda harapkan, perbaiki masalah sebelum memperbarui konfigurasi peer.

Untuk mengetahui informasi tentang cara mengambil detail sesi BGP bidang kontrol, lihat Kontrol sesi BGP pesawat.

Memperbarui pembanding dengan cara yang terkontrol

Jika memungkinkan, perbarui pembanding satu per satu untuk membantu mengisolasi kemungkinan masalah:

  1. Menambahkan atau memperbarui satu pembanding.
  2. Tunggu hingga konfigurasi direkonsiliasi.
  3. Pastikan cluster dapat terhubung ke peer baru atau yang diperbarui.
  4. Menghapus pembanding 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 dibuat: edit resource kustom NetworkGatewayGroup dan BGPLoadBalancer. Apa saja modifikasi pada informasi peering di resource kustom ini direfleksikan pada konfigurasi solusi load balancing di cluster target.

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

Pemecahan masalah

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

Sesi BGP bidang kontrol

Konfigurasi peering BGP bidang kontrol divalidasi dengan pemeriksaan preflight selama pembuatan cluster. Pemeriksaan preflight mencoba:

  • Membuat koneksi BGP dengan setiap peer.
  • Iklankan VIP bidang kontrol.
  • Verifikasi bahwa node bidang kontrol dapat dijangkau, menggunakan VIP.

Jika cluster Anda gagal dalam pemeriksaan preflight, tinjau pemeriksaan preflight log untuk menemukan error. File log pemeriksaan preflight yang diberi stempel tanggal ada di Direktori baremetal/bmctl-workspace/CLUSTER_NAME/log.

Saat runtime, speaker BGP bidang kontrol berjalan sebagai pod statis pada setiap kontrol {i>node bidang<i} dan menulis informasi peristiwa ke dalam log{i>.<i} Pod statis ini mencakup "bgppengiklan" pada 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 baik, responsnya akan terlihat seperti berikut ini:

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 Pod bgpadvertiser-node-01:

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

Sesi BGP layanan

Resource BGPSession memberikan informasi tentang sesi BGP saat ini. Kepada memperoleh informasi sesi, pertama mendapatkan sesi saat ini, kemudian mengambil BGPSession resource untuk salah satu sesi.

Gunakan perintah kubectl get berikut untuk membuat daftar sesi saat ini:

kubectl -n kube-system get bgpsessions

Perintah tersebut 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 berikut contoh:

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 hop berikutnya yang berada di setiap rute periklanan.

Memulihkan akses ke VIP bidang kontrol untuk cluster yang dikelola sendiri

Untuk mendapatkan kembali akses ke VIP bidang kontrol pada admin, campuran, atau mandiri , Anda harus mengupdate konfigurasi BGP di cluster tersebut. Seperti yang ditampilkan dalam contoh perintah berikut, gunakan SSH untuk terhubung ke node, lalu gunakan kubectl untuk buka 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 otentikasi 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 yang baru konfigurasi cluster, memantau kondisi pod bgpadvertiser. Jika berfungsi, pod akan dimulai ulang dan menjadi responsif setelah terhubung kepada rekan-rekan mereka.

Verifikasi BGP manual

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

Pemeriksaan preflight mengotomatiskan tugas verifikasi BGP berikut:

  • Siapkan koneksi BGP ke peer.
  • Iklankan 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. Meneruskan pemeriksaan sangat penting saat membuat cluster. Namun, pemeriksaan preflight tidak membuat koneksi jangka panjang, sehingga men-{i>debug<i} kegagalan akan sulit.

Bagian berikut memberikan petunjuk untuk menyiapkan koneksi BGP dan memberitahukan rute dari satu mesin cluster ke satu peer. Untuk menguji beberapa komputer dan beberapa rekan, ulangi instruksi lagi, menggunakan mesin dan peer.

Perlu diingat bahwa koneksi BGP dibuat dari node bidang kontrol, jadi pastikan untuk menguji prosedur ini dari salah satu {i>node<i} bidang kontrol yang direncanakan.

Mendapatkan biner program pengujian BGP

Jalankan langkah-langkah di bagian ini pada workstation admin Anda. Langkah-langkah ini mendapatkan Program bgpadvertiser yang digunakan untuk menguji koneksi BGP dan menyalinnya ke bidang kontrol yang ingin Anda uji.

  1. Tarik gambar docker ansible-runner.

    Tanpa Mirror Registry

    Jika Anda tidak menggunakan registry duplikasi, jalankan perintah berikut untuk mengambil gambar 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 duplikasi registry, jalankan perintah berikut untuk mengambil ansible-runner docker image:

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

    Ganti REGISTRY_HOST dengan nama di server duplikat registry Anda.

  2. Untuk mengekstrak biner bgpadvertiser.

    Tanpa Mirror 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 bidang kontrol yang Anda inginkan untuk melakukan pengujian, jalankan perintah berikut:

    scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/

    Ganti kode berikut:

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

    • CP_NODE_IP: alamat IP {i>node<i} bidang kontrol.

Menyiapkan koneksi BGP

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

  1. Buat file konfigurasi pada node di /tmp/bgpadvertiser.conf yang akan 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 sedang Anda buka.
    • CLUSTER_ASN: nomor sistem otonom yang digunakan oleh cluster.
    • PEER_IP: alamat IP salah satu eksternal rekan yang ingin Anda uji.
    • PEER_ASN: nomor sistem otonom untuk yang berisi perangkat peer eksternal.

  2. Jalankan daemon bgpadvertiser, dengan mengganti VIP bidang kontrol di 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 untuk mengiklankan alamat ini ke rekan sejawat.

  3. Lihat output program.

    Pada tahap ini, daemon bgpadvertiser dimulai, mencoba terhubung ke rekan, dan mengiklankan VIP. Program ini secara berkala mencetak pesan (lihat contoh output berikut) yang menyertakan BGP_FSM_ESTABLISHED saat koneksi BGP akan 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 konfigurasi BGP dalam file konfigurasi dan verifikasi dengan administrator jaringan. Sekarang Anda telah menyiapkan koneksi BGP. Anda dapat memverifikasi dengan administrator jaringan yang mereka melihat koneksi yang dibuat di pihak mereka dan mereka melihat rute diiklankan kepada mereka.

Uji lalu lintas

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 yang berbeda sehingga Anda dapat membiarkan bgpadvertiser tetap berjalan:

  1. Tambahkan VIP ke node bidang kontrol:

    ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME

    Ganti kode berikut:

    • CONTROL_PLANE_VIP: Argumen VIP --advertise-ip dari bgpadvertiser.
    • INTF_NAME: Kubernetes antarmuka pada node. Yaitu, antarmuka yang memiliki alamat IP yang telah dimasukkan ke 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 BGP pada perangkat jaringan. Bekerja samalah dengan administrator jaringan Anda untuk memverifikasi konfigurasi dan menyelesaikan masalahnya.

Pembersihan

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

  1. Menghapus VIP dari node bidang kontrol jika Anda menambahkannya untuk lalu lintas uji coba:

    ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME

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

  3. Pastikan tidak ada proses bgpadvertiser yang berjalan:

    ps -ef | grep bgpadvertiser

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