Dokumen ini menjelaskan cara menyiapkan dan menggunakan load balancer yang dipaketkan dengan Border
Gateway Protocol (BGP) untuk GKE di Bare Metal. Mode load balancing ini
mendukung iklan 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 lainnya, yaitu jaringan eksternal, melalui peering.
Load balancer yang dipaketkan dengan kemampuan BGP berlaku untuk semua jenis cluster, tetapi cluster admin hanya mendukung bagian load balancing bidang kontrol dari kemampuan ini.
Penggunaan load balancer yang dipaketkan dengan fitur BGP memberikan manfaat berikut:
- Menggunakan kemampuan load balancing aktif/aktif N-way, yang memberikan failover yang lebih cepat dan penggunaan bandwidth yang tersedia lebih efisien.
- Mendukung protokol Lapisan 3 yang beroperasi dengan switch dan router top-of-rack (ToR) pihak ketiga yang kompatibel dengan eBGP.
- Memungkinkan pusat data yang menjalankan stack software-defined networking (SDN) lanjutan untuk mengirim batas Lapisan 3 hingga ke cluster.
Cara kerja paket load balancing dengan BGP
Bagian berikut memberikan ringkasan singkat tentang cara kerja load balancer yang dipaketkan dengan 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 floating yang Anda tentukan dalam resource kustom
NetworkGatewayGroup
. - Pengontrol Anthos Network Gateway mengelola alamat IP mengambang.
- Load balancing berbasis BGP berbasis paket 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 apa pun diharapkan akan didistribusikan ulang di seluruh jaringan dan dapat dijangkau dari tempat lain dalam cluster.
- Sebaiknya gunakan kemampuan
ADD-PATH
BGP dalam mode penerimaan untuk sesi peering. - Iklankan beberapa jalur dari setiap pembanding akan menghasilkan load balancing aktif/aktif.
- Perutean multijalur dengan biaya yang sama (ECMP) harus diaktifkan untuk jaringan Anda agar beberapa jalur dapat digunakan untuk menyebarkan traffic ke sekumpulan node load balancer.
Load balancing bidang kontrol
Setiap node bidang kontrol di cluster Anda menetapkan sesi BGP dengan satu atau beberapa peer di infrastruktur Anda. Setiap node bidang kontrol harus memiliki setidaknya satu peer. Dalam file konfigurasi cluster, Anda dapat mengonfigurasi node bidang kontrol mana yang terhubung ke peer eksternal.
Diagram berikut menunjukkan contoh peering bidang kontrol. Cluster tersebut memiliki dua node bidang kontrol di satu subnet dan satu di subnet lainnya. Ada peer eksternal (TOR) di setiap subnet dan node bidang kontrol GKE on Bare Metal yang peer dengan TOR-nya.
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 dari
alamat IP node cluster secara langsung, tetapi menggunakan alamat IP floating.
Layanan dengan kebijakan jaringan externalTrafficPolicy=Local
didukung.
Namun, setelan externalTrafficPolicy=Local
bergantung pada beban kerja dan menyebabkan rute diupdate setiap kali Pod yang mendukung Service ditambahkan atau dihapus sepenuhnya dari node. Perilaku pembaruan rute ini dapat menyebabkan perutean Equal Cost
Multi-Path (ECMP) mengubah aliran traffic, yang dapat mengakibatkan penurunan
traffic.
Alamat IP floating
Load balancing layanan mengharuskan Anda mencadangkan alamat IP mengambang di subnet node cluster agar digunakan untuk peering BGP. Setidaknya satu alamat IP floating 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 mengambang menghilangkan kekhawatiran tentang pemetaan alamat IP speaker BGP ke
node. Pengontrol Anthos Network Gateway menangani penetapan
NetworkGatewayGroup
ke node dan juga mengelola alamat IP floating. Jika node tidak aktif, pengontrol Gateway Jaringan Anthos akan menetapkan ulang alamat IP floating untuk memastikan bahwa peer eksternal memiliki alamat IP deterministik untuk di-peering.
Pembanding eksternal
Untuk load balancing bidang data, Anda dapat menggunakan pembanding eksternal yang sama yang telah 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 bidang data, tambahkan spesifikasi resource BGPLoadBalancer
dan BGPPeer
ke file konfigurasi cluster. Jika Anda tidak menentukan resource kustom ini, pembanding bidang kontrol akan digunakan secara otomatis untuk bidang data.
Anda menentukan pembanding 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
berdasarkan resource kustom BGPLoadBalancer
yang sesuai. Anda menentukan label
yang cocok di kolom peerSelector
dalam resource kustom BGPLoadBalancer
untuk
memilih BGPPeer
yang akan digunakan.
Pengontrol Gateway Jaringan Anthos mencoba menetapkan sesi (jumlah sesi dapat dikonfigurasi) ke setiap peer eksternal dari kumpulan alamat IP mengambang yang dicadangkan. Sebaiknya tentukan setidaknya 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 floating yang ditentukan dalam resource kustom NetworkGatewayGroup
.
Node load balancer
Sekumpulan node dari cluster digunakan untuk load balancing, yang berarti node tersebut
adalah node yang diiklankan agar dapat menerima traffic load balancing yang masuk.
Kumpulan node ini secara default disetel ke kumpulan node bidang kontrol, tetapi Anda dapat menentukan
kumpulan node yang berbeda di bagian loadBalancer
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 berjalan atau tidak pada node load balancer. Alamat IP floating ditetapkan ke node dalam subnet yang sama dan peering dimulai dari sana, terlepas dari apakah node tersebut merupakan node load balancer atau tidak. Namun, hop berikutnya yang diiklankan melalui BGP selalu merupakan 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 subnetnya masing-masing. Ada dua pembanding eksternal yang ditentukan. Setiap peer IP mengambang dengan kedua peer eksternal.
Menyiapkan load balancer BGP
Bagian berikut menjelaskan cara mengonfigurasi cluster dan jaringan eksternal Anda agar dapat menggunakan load balancer yang dipaketkan dengan BGP.
Merencanakan integrasi Anda dengan infrastruktur eksternal
Untuk menggunakan load balancer yang dipaketkan dengan BGP, Anda harus menyiapkan infrastruktur eksternal:
Infrastruktur eksternal harus dikonfigurasi untuk melakukan peering dengan setiap node bidang kontrol dalam cluster guna menyiapkan komunikasi bidang kontrol. Sesi peering ini digunakan untuk mengiklankan VIP bidang kontrol Kubernetes.
Infrastruktur eksternal harus dikonfigurasi agar melakukan peer dengan kumpulan alamat IP mengambang yang dicadangkan untuk komunikasi bidang data. Alamat IP floating digunakan untuk peering BGP untuk VIP Layanan. Sebaiknya gunakan dua alamat IP mengambang dan dua pembanding untuk memastikan ketersediaan tinggi untuk sesi BII. Proses penyimpanan IP mengambang dijelaskan sebagai bagian dari mengonfigurasi cluster untuk load balancing yang dipaketkan dengan BGP.
Setelah mengonfigurasi infrastruktur, tambahkan informasi peering BGP ke file konfigurasi cluster. Cluster yang Anda buat dapat memulai sesi peering dengan infrastruktur eksternal.
Mengonfigurasi cluster Anda untuk paket load balancing dengan BGP
Anda harus mengaktifkan dan mengonfigurasi load balancing yang dipaketkan dengan BGP dalam file konfigurasi cluster saat membuat cluster. Di 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 Layanan.BGPLoadBalancer
: menentukan dengan pemilih label pembanding yang digunakan untuk load balancing BGP.BGPPeer
: menentukan peer individual, termasuk label untuk tujuan pemilihan, untuk sesi peering BGP.
Petunjuk berikut menjelaskan cara mengonfigurasi cluster Anda dan tiga resource kustom untuk menyiapkan load balancing yang dipaketkan dengan BGP.
Tambahkan kolom
advancedNetworking
ke file konfigurasi cluster di bagianclusterNetwork
dan tetapkan ketrue
.Kolom ini memungkinkan kemampuan jaringan lanjutan, khususnya resource Grup Gateway Jaringan.
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 GKE di Bare Metal adalah nama cluster yang diawali dengancluster-
. Misalnya, jika Anda menamai cluster Andatest
, namespace-nya adalahcluster-test
.Di bagian
loadBalancer
file konfigurasi cluster, tetapkanmode
kebundled
dan tambahkan kolomtype
dengan nilaibgp
.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 ...
Untuk menentukan informasi BGP-peering bagi 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 pembanding eksternal,
bgpPeers
akan mengambil daftar pemetaan. Sebaiknya tentukan setidaknya dua peer eksternal untuk ketersediaan tinggi untuk sesi BGP. Untuk contoh dengan beberapa pembanding, lihat Contoh konfigurasi.Tetapkan kolom
loadBalancer.ports
,loadBalancer.vips
, danloadBalancer.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 ...
Tentukan node cluster yang akan digunakan untuk melakukan load balancing pada bidang data.
Langkah ini opsional. Jika Anda tidak menghapus tanda 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> ...
Cadangkan alamat IP floating dengan mengonfigurasi resource kustom
NetworkGatewayGroup
:Alamat IP floating 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 GKE di Bare Metal adalah nama cluster yang diawali dengancluster-
. Misalnya, jika Anda menamai cluster Andatest
, namespace-nya adalahcluster-test
.FLOATING_IP
: alamat IP dari salah satu subnet cluster. Anda harus menentukan setidaknya satu alamat IP, tetapi sebaiknya tentukan setidaknya dua alamat IP.NODE_SELECTOR
: (Opsional) pemilih label guna mengidentifikasi node untuk membuat instance sesi peering dengan pembanding eksternal, seperti tombol top-of-rack (ToR). Jika tidak diperlukan, hapus kolom ini.
Pastikan resource kustom
NetworkGatewayGroup
diberi namadefault
dan menggunakan namespace cluster. Untuk melihat contoh tampilan spesifikasi resource kustomNetworkGatewayGroup
, lihat Contoh konfigurasi.(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 cluster. Secara default, namespace cluster untuk GKE di Bare Metal adalah nama cluster yang diawali dengancluster-
. Misalnya, jika Anda menamai cluster Andatest
, namespace-nya adalahcluster-test
.PEER_LABEL
: label yang digunakan untuk mengidentifikasi peer mana yang akan digunakan untuk load balancing. Setiap resource kustomBGPPeer
dengan label yang cocok akan menentukan detail setiap pembanding.
Pastikan resource kustom
BGPLoadBalancer
diberi namadefault
dan menggunakan namespace cluster. Jika Anda tidak menentukan resource kustomBGPLoadBalancer
, peer bidang kontrol akan digunakan secara otomatis untuk load balancing bidang data. Untuk mengetahui contoh yang komprehensif, lihat Contoh konfigurasi.(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 pembanding.CLUSTER_NAMESPACE
: namespace untuk cluster. Secara default, namespace cluster untuk GKE di Bare Metal adalah nama cluster yang diawali dengancluster-
. Misalnya, jika Anda menamai cluster Andatest
, namespace-nya adalahcluster-test
.PEER_LABEL
: label yang digunakan untuk mengidentifikasi peer mana yang akan digunakan untuk load balancing. Label ini harus sesuai dengan label yang ditentukan dalam resource kustomBGPLoadBalancer
.CLUSTER_ASN
: nomor sistem otonom untuk cluster yang sedang dibuat.PEER_IP
: alamat IP perangkat peer eksternal. Sebaiknya tentukan setidaknya dua pembanding eksternal, tetapi Anda harus menentukan setidaknya 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 mati.GATEWAY_REF
: (Opsional) nama resource NetworkGatewayGroup yang akan digunakan untuk peering. Jika kebijakan tidak disetel, sebagian atau semua resource gateway dapat digunakan. Gunakan setelan ini bersama dengan kolomnodeSelector
di resource NetworkGatewayGroups untuk memilih node yang akan digunakan untuk peering dengan peer eksternal tertentu, seperti toR switch. Langkah ini dapat memerlukan beberapa entri untuk memilih beberapa NetworkGatewayGroups, jika diinginkan, dalam format satu gateway per baris.
Anda dapat menentukan beberapa pembanding eksternal dengan membuat resource kustom
BGPPeer
tambahan. Sebaiknya tentukan minimal dua peer eksternal (dua resource kustom) untuk mengetahui ketersediaan tinggi sesi BGP. Jika Anda tidak menentukan resource kustomBGPPeer
, pembanding bidang kontrol akan digunakan secara otomatis untuk load balancing bidang data.Saat Anda menjalankan
bmctl cluster create
untuk membuat cluster, pemeriksaan preflight akan berjalan. Di antara pemeriksaan lainnya, pemeriksaan preflight memvalidasi konfigurasi peering BGP untuk bidang kontrol dan melaporkan semua masalah langsung ke workstation admin sebelum cluster dapat dibuat.Jika berhasil, resource load balancing BGP yang ditambahkan (NetworkGatewayGroup, BGPLoadBalancer, dan BGPPeer) akan dikirim ke cluster admin di namespace cluster pengguna. Gunakan file kubeconfig cluster admin saat Anda melakukan pembaruan berikutnya pada resource ini. Cluster admin kemudian merekonsiliasi perubahan pada cluster pengguna. Jika Anda mengedit resource ini di cluster pengguna secara langsung, cluster admin akan menimpa perubahan yang Anda buat dalam rekonsiliasi berikutnya.
Iklankan beberapa next-hop per sesi dengan BGP ADD-PATH
Sebaiknya gunakan kemampuan ADD-PATH
BGP untuk sesi peering seperti
yang ditentukan dalam
RFC 7911.
Secara default, protokol BGP hanya mengizinkan satu next hop untuk diiklankan ke peer untuk satu awalan. BGP ADD-PATH
memungkinkan periklanan beberapa hop berikutnya
untuk awalan yang sama. Saat ADD-PATH
digunakan dengan load balancing paket berbasis BGP, cluster dapat memberitahukan beberapa node cluster sebagai node frontend (hop berikutnya) untuk layanan load balancer (awalan). Aktifkan ECMP di jaringan sehingga traffic dapat tersebar di beberapa jalur. Kemampuan untuk menyebarkan traffic dengan mengiklankan beberapa node cluster sebagai hop berikutnya, memberikan penskalaan yang lebih baik untuk kapasitas bidang data untuk load balancing.
Jika perangkat peer eksternal Anda, seperti router atau switch top-of-rack (ToR),
mendukung ADD-PATH
BGP, Anda cukup mengaktifkan ekstensi penerimaan saja.
Load balancing paket dengan BGP berfungsi tanpa kemampuan ADD-PATH
, tetapi pembatasan untuk mengiklankan node load balancing tunggal per sesi peering akan membatasi kapasitas bidang data load balancer. Tanpa ADD-PATH
, GKE pada Bare Metal akan memilih node untuk beriklan dari kumpulan node load balancer, dan berupaya menyebarkan hop berikutnya untuk VIP yang berbeda di berbagai node.
Membatasi peering BGP ke node load balancer
GKE di Bare Metal otomatis menetapkan alamat IP floating pada node mana pun dalam subnet yang sama dengan alamat IP floating. Sesi BGP dimulai dari alamat IP ini meskipun tidak mendarat di node load balancer. Perilaku ini sudah dirancang 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 akan digunakan hanya untuk node load balancer. Artinya, Anda dapat mengonfigurasi semua node dalam subnet tersebut agar berada di kumpulan node load balancer. Kemudian, saat Anda mengonfigurasi alamat IP floating yang digunakan untuk peering BGP, pastikan alamat tersebut berasal dari subnet yang sama. GKE di Bare Metal memastikan bahwa penetapan alamat IP mengambang dan peering BGP hanya terjadi dari node load balancer.
Menyiapkan load balancing BGP dengan jaringan dual stack
Dimulai dengan rilis GKE pada Bare Metal 1.14.0, load balancing berbasis BGP mendukung IPv6. Dengan diperkenalkannya dukungan IPv6, Anda dapat mengonfigurasi Layanan IPv6 dan LoadBalancer dual-stack di cluster yang dikonfigurasi untuk jaringan dual-stack. Bagian ini menjelaskan perubahan yang diperlukan untuk mengonfigurasi load balancing dua stack dan paket dengan BGP.
Untuk mengaktifkan Layanan LoadBalancer dual-stack, perubahan konfigurasi berikut diperlukan:
Cluster yang mendasarinya harus dikonfigurasi untuk jaringan dual-stack:
Tentukan CIDR Layanan IPv4 dan IPv6 di file konfigurasi cluster di bagian
spec.clusterNetwork.services.cidrBlocks
.Menentukan resource ClusterCIDRConfig yang sesuai untuk menentukan rentang CIDR IPv4 dan IPv6 untuk Pod.
Untuk mengetahui 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 MetalLB dapat mengalokasikan alamat IP ke Layanan Dual Stack, setidaknya harus ada satu kumpulan alamat yang memiliki alamat format IPv4 dan IPv6.
Contoh konfigurasi berikut menyoroti perubahan yang diperlukan untuk load balancing paket 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 dual stack dan paket dengan BGP
Saat mengonfigurasi cluster untuk menggunakan load balancing dual stack yang 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 BGP Multiprotokol.
Contoh konfigurasi
Bagian berikut ini menunjukkan cara mengonfigurasi load balancing berbasis BGP untuk berbagai opsi atau perilaku.
Mengonfigurasi semua node menggunakan pembanding yang sama
Seperti yang ditunjukkan dalam diagram, konfigurasi ini menghasilkan kumpulan pembanding 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 akan mencapai pembanding.
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 floating dapat ditetapkan ke node yang berada di
subnet yang sama.
Seperti yang ditunjukkan dalam 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 ke semua peer.
Anda menentukan alamat IP floating yang akan digunakan untuk sesi peering load balancing
Layanan di resource kustom NetworkGatewayGroup
. Dalam contoh ini, karena tidak ada
BGPLoadBalancer
yang 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 ditunjukkan dalam diagram, konfigurasi ini menghasilkan peering dua node bidang kontrol (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
) di-peering dengan peer eksternal lainnya (10.0.2.254
). Konfigurasi ini berguna saat Anda tidak ingin semua node terhubung ke semua peer. Misalnya, Anda mungkin ingin agar node bidang kontrol melakukan peering hanya dengan tombol 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.
Seperti ditunjukkan dalam contoh konfigurasi cluster berikut, Anda membatasi
node bidang kontrol mana yang dapat terhubung ke peer tertentu dengan menentukan alamat IP-nya
di kolom controlPlaneNodes
untuk peer di bagian bgpPeers
.
Anda menentukan alamat IP floating yang akan digunakan untuk sesi peering load balancing
Layanan di resource kustom NetworkGatewayGroup
. Dalam contoh ini, karena tidak ada
BGPLoadBalancer
yang 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 ditunjukkan dalam diagram, konfigurasi ini menghasilkan peering dua node bidang kontrol (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
) dengan peering eksternal lainnya (10.0.2.254
).
Peering 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 Layanan. Alamat IP mengambang dapat ditetapkan
ke node yang berada di subnet yang sama.
Seperti ditunjukkan dalam contoh konfigurasi cluster berikut, Anda membatasi
node bidang kontrol mana yang dapat terhubung ke peer tertentu dengan menentukan alamat IP-nya
di kolom controlPlaneNodes
untuk peer di bagian bgpPeers
.
Anda menentukan alamat IP floating 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 dalam resource
BGPPeer
dan tambahkan label yang akan digunakan untuk pemilihan pembanding, seperticluster.baremetal.gke.io/default-peer: "true"
.Tentukan label yang cocok untuk kolom
peerSelector
di resourceBGPLoadBalancer
.
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 membuat cluster yang dikonfigurasi untuk menggunakan load balancing yang dipaketkan 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). Cluster admin kemudian merekonsiliasi perubahan pada cluster pengguna. Jika Anda mengedit resource ini secara langsung pada cluster pengguna, cluster admin akan menimpa perubahan yang Anda buat dalam rekonsiliasi berikutnya.
Bidang kontrol
Informasi peering BGP bidang kontrol dapat diperbarui di resource Cluster
.
Anda dapat menambahkan atau menghapus pembanding yang ditentukan di bagian load balancing bidang kontrol.
Bagian berikut menguraikan praktik terbaik untuk memperbarui informasi peering BGP bidang kontrol Anda.
Memeriksa status pembanding sebelum memperbarui
Untuk meminimalkan risiko salah mengonfigurasi peer, pastikan sesi peering BGP
bidang kontrol berada dalam status yang diharapkan sebelum melakukan perubahan. Misalnya,
jika Anda berharap semua sesi peering BGP saat ini aktif, verifikasi bahwa
semua Pod bgp-advertiser
melaporkan ready
, yang menunjukkan bahwa sesi tersebut telah selesai.
Jika status saat ini tidak cocok dengan yang Anda harapkan, perbaiki masalah sebelum
memperbarui konfigurasi pembanding.
Untuk mengetahui informasi tentang cara mengambil detail sesi BGP bidang kontrol, lihat Mengontrol sesi BGP bidang.
Memperbarui pembanding secara terkendali
Perbarui peer satu per satu, jika memungkinkan, untuk membantu mengisolasi kemungkinan masalah:
- Menambahkan atau memperbarui satu pembanding.
- Tunggu hingga konfigurasi direkonsiliasi.
- Pastikan bahwa cluster dapat terhubung ke peer baru atau yang diupdate.
- Hapus rekan lama atau yang tidak dibutuhkan.
Service
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
. Setiap perubahan pada informasi peering dalam resource kustom ini tercermin dalam konfigurasi solusi load balancing di cluster target.
Lakukan update di resource sumber di namespace cluster hanya di cluster admin. 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 paket dengan BGP.
Sesi BGP bidang kontrol
Konfigurasi BGP-peering bidang kontrol divalidasi dengan pemeriksaan preflight selama pembuatan cluster. Pemeriksaan preflight berupaya untuk:
- Membuat koneksi BGP dengan setiap peer.
- Mengiklankan bidang kontrol VIP.
- Verifikasi bahwa node bidang kontrol dapat dijangkau, menggunakan VIP.
Jika pembuatan cluster Anda gagal dalam pemeriksaan preflight, tinjau log pemeriksaan preflight untuk menemukan error. File log pemeriksaan preflight yang dilengkapi tanggal berada di
direktori baremetal/bmctl-workspace/CLUSTER_NAME/log
.
Saat runtime, speaker BGP bidang kontrol berjalan sebagai pod statis pada 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
Saat Pod beroperasi dengan baik, 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 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 menampilkan daftar sesi saat ini:
kubectl -n kube-system get bgpsessions
Perintah tersebut 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 guna 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
Responsnya, 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 diiklankan di setiap rute.
Memulihkan akses ke bidang kontrol VIP untuk cluster yang dikelola sendiri
Untuk mendapatkan kembali akses ke VIP bidang kontrol pada cluster admin, hybrid, atau
mandiri, Anda harus mengupdate konfigurasi BGP pada cluster. Seperti yang ditunjukkan dalam
contoh perintah berikut, gunakan SSH untuk terhubung ke node, lalu gunakan kubectl
untuk
membuka resource cluster untuk mengedit.
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 berfungsi, pod akan dimulai ulang dan menjadi responsif setelah terhubung ke pembanding.
Verifikasi BGP manual
Bagian ini berisi petunjuk untuk memverifikasi konfigurasi BGP secara manual. Prosedur ini akan menyiapkan koneksi BGP yang berjalan lama agar Anda dapat men-debug konfigurasi BGP lebih lanjut dengan tim jaringan. Gunakan prosedur ini untuk memverifikasi konfigurasi Anda sebelum membuat cluster atau menggunakannya jika pemeriksaan preflight terkait BGP gagal.
Pemeriksaan preflight mengotomatiskan tugas verifikasi BGP berikut:
- Menyiapkan koneksi BGP ke peer.
- Mengiklankan bidang kontrol VIP.
- Pastikan traffic yang dikirim dari semua node cluster lain 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 preflight tidak membuat koneksi yang berjalan lama, sehingga proses debug kegagalan akan sulit.
Bagian berikut memberikan petunjuk untuk menyiapkan koneksi BGP dan mengiklankan rute dari satu mesin cluster ke satu peer. Untuk menguji beberapa komputer dan beberapa peer, ulangi lagi petunjuk menggunakan mesin dan kombinasi pembanding yang berbeda.
Perlu diingat bahwa koneksi BGP dibuat dari node bidang kontrol, jadi pastikan untuk menguji prosedur ini dari salah satu node bidang kontrol yang Anda rencanakan.
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 menguji.
Ambil image docker ansible-runner.
Tanpa Mirror Registry
Jika Anda tidak menggunakan pencerminan registry, jalankan perintah berikut untuk mengambil 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 pencerminan registry, jalankan perintah berikut untuk mengambil 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 duplikasi registry Anda.
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 .
Untuk menyalin biner
bgpadvertiser
ke node bidang kontrol yang ingin Anda uji, 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.
Buat file konfigurasi pada 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.
Jalankan daemon
bgpadvertiser
, dengan mengganti bidang kontrol VIP dalam perintah berikut:/tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIP
Ganti
CONTROL_PLANE_VIP
dengan alamat IP yang akan digunakan untuk bidang kontrol VIP. Perintah ini menyebabkan pengiklan BGP mengiklankan alamat ini ke peer.Lihat output program.
Pada tahap ini, daemon
bgpadvertiser
dimulai, mencoba terhubung ke peer, dan mengiklankan VIP. Program ini secara berkala mencetak pesan (lihat contoh output berikut) yang menyertakanBGP_FSM_ESTABLISHED
saat koneksi BGP terhubung.{"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 memverifikasi dengan administrator jaringan. Anda kini sudah menyiapkan koneksi BGP. Anda dapat memverifikasi dengan administrator jaringan bahwa mereka melihat koneksi yang dibuat di pihak mereka dan bahwa mereka melihat rute yang diiklankan kepada mereka.
Pengujian 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
berjalan:
Tambahkan VIP ke node bidang kontrol:
ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME
Ganti kode berikut:
CONTROL_PLANE_VIP
: argumen--advertise-ip
VIP daribgpadvertiser
.INTF_NAME
: antarmuka Kubernetes pada node. Artinya, antarmuka dengan alamat IP yang Anda masukkan ke dalam konfigurasi GKE pada Bare Metal untukloadBalancer.bgpPeers.controlPlaneNodes
.
Melakukan ping ke VIP dari node yang berbeda:
ping CONTROL_PLANE_VIP
Jika ping tidak berhasil, mungkin ada masalah dengan konfigurasi BGP di perangkat jaringan. Bekerja samalah dengan administrator jaringan Anda untuk memverifikasi konfigurasi dan menyelesaikan masalah ini.
Pembersihan
Pastikan untuk mengikuti langkah-langkah ini untuk mereset node setelah Anda memverifikasi secara manual bahwa BGP berfungsi. Jika Anda tidak mereset node dengan benar, penyiapan manual dapat mengganggu pemeriksaan preflight atau pembuatan cluster berikutnya.
Hapus VIP dari node bidang kontrol jika Anda menambahkannya untuk pengujian traffic:
ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME
Pada node bidang kontrol, tekan
Ctrl
+C
di terminalbgpadvertiser
untuk menghentikan bgpAdvertiser.Pastikan tidak ada proses
bgpadvertiser
yang sedang berjalan:ps -ef | grep bgpadvertiser
Jika Anda melihat proses sedang berjalan, hentikan menggunakan perintah
kill
.