Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Perangkat Google Distributed Cloud (GDC) dengan air gap menyediakan load balancer yang memungkinkan aplikasi saling mengekspos layanan. Load balancer mengalokasikan alamat IP virtual (VIP) yang stabil
yang menyeimbangkan traffic di serangkaian workload backend.
Load balancer di GDC melakukan load balancing lapisan empat (L4), yang berarti load balancer tersebut memetakan serangkaian port TCP atau UDP frontend yang dikonfigurasi ke port backend yang sesuai. Load balancer dikonfigurasi di tingkat project.
Load balancer dikonfigurasi untuk jenis workload berikut:
Workload yang berjalan di VM.
Workload dalam container di dalam cluster Kubernetes.
Ada tiga cara untuk mengonfigurasi load balancer di
GDC:
Gunakan gdcloud CLI.
Anda dapat menggunakan API ini untuk membuat load balancer.
Gunakan Layanan Kubernetes langsung dari cluster Kubernetes. Metode ini hanya membuat load balancer zonal.
Komponen load balancer
Saat menggunakan KRM API atau gcloud CLI untuk mengonfigurasi load balancer, Anda menggunakan load balancer penerusan L4:
L4 berarti protokolnya adalah TCP atau UDP.
Passthrough berarti tidak ada proxy antara beban kerja dan klien.
Load balancer terdiri dari komponen yang dapat dikonfigurasi berikut:
Aturan penerusan: menentukan traffic yang diteruskan, dan ke layanan backend mana. Aturan penerusan memiliki spesifikasi berikut:
Terdiri dari tiga tuple, CIDR, port, dan protokol, untuk diakses klien.
Mendukung protokol TCP dan UDP.
Menawarkan aturan penerusan internal dan eksternal. Klien dapat mengakses aturan penerusan internal dari dalam Virtual Private Cloud (VPC). Klien dapat mengakses aturan penerusan eksternal dari luar platform GDC atau dari dalam oleh workload yang memiliki nilai EgressNAT yang ditentukan.
Aturan penerusan terhubung ke layanan backend. Anda dapat mengarahkan beberapa aturan penerusan untuk mengarah ke layanan backend yang sama.
Layanan backend: adalah hub load balancing yang menghubungkan aturan penerusan, health check, dan backend. Layanan backend mereferensikan objek
backend, yang mengidentifikasi workload yang diteruskan trafficnya oleh load balancer. Ada batasan pada backend yang dapat direferensikan oleh satu layanan backend:
Satu resource backend zona per zona.
Satu resource backend cluster per cluster. Hal ini tidak dapat digabungkan dengan backend project.
Backend: objek zonal yang menentukan endpoint yang berfungsi sebagai backend untuk layanan backend yang dibuat. Resource backend harus dicakup ke zona. Pilih endpoint menggunakan label. Cakupan pemilih ke project atau cluster:
Backend project adalah backend yang tidak memiliki kolom ClusterName yang ditentukan. Dalam hal ini, label yang ditentukan berlaku untuk semua beban kerja dalam project tertentu, di VPC zona tertentu. Label diterapkan ke workload VM dan pod di beberapa cluster. Saat layanan backend menggunakan backend project, Anda tidak dapat mereferensikan backend lain untuk zona tersebut di layanan backend tersebut.
Backend cluster adalah backend yang memiliki kolom ClusterName yang ditentukan. Dalam hal ini, label yang ditentukan berlaku untuk semua beban kerja dalam cluster bernama di project yang ditentukan. Anda dapat menentukan paling banyak satu backend per zona per cluster dalam satu layanan backend.
Health check: tentukan pemeriksaan untuk menentukan apakah endpoint workload tertentu di backend responsif atau tidak. Endpoint yang tidak responsif akan dikeluarkan dari load balancer, hingga endpoint tersebut responsif kembali. Pemeriksaan
kondisi hanya berlaku untuk workload VM. Workload Pod dapat menggunakan mekanisme pemeriksaan Kubernetes bawaan untuk menentukan apakah endpoint tertentu dalam kondisi baik.
Saat menggunakan Layanan Kubernetes secara langsung, Anda menggunakan objek Service, bukan komponen yang tercantum sebelumnya. Anda hanya dapat menargetkan workload di cluster tempat objek Service dibuat.
Load balancing eksternal dan internal
Aplikasi GDC memiliki akses ke jenis layanan jaringan berikut:
Load Balancer Internal (ILB): memungkinkan Anda mengekspos layanan ke cluster lain dalam organisasi.
Load Balancer Eksternal (ELB): mengalokasikan alamat VIP dari rentang yang dapat dirutekan dari beban kerja eksternal dan mengekspos layanan di luar organisasi GDC, seperti organisasi lain di dalam atau di luar instance GDC.
Alamat IP virtual layanan
ILB mengalokasikan alamat VIP yang hanya bersifat internal bagi organisasi. Alamat
VIP ini tidak dapat dijangkau dari luar organisasi; oleh karena itu, Anda
hanya dapat menggunakannya untuk mengekspos layanan ke aplikasi lain dalam
organisasi. Alamat IP ini dapat tumpang-tindih antar-organisasi dalam instance yang sama.
Di sisi lain, ELB mengalokasikan alamat VIP yang dapat dijangkau secara eksternal dari luar organisasi. Oleh karena itu, alamat VIP ELB harus unik di antara semua organisasi. Biasanya, lebih sedikit alamat VIP ELB yang tersedia
untuk digunakan oleh organisasi.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[],[],null,["# Manage load balancers\n\nGoogle Distributed Cloud (GDC) air-gapped appliance provides load balancers that enable\napplications to expose services to one another. Load balancers allocate a stable\nvirtual IP (VIP) address that balances traffic over a set of backend workloads.\nLoad balancers in GDC perform layer four (L4) load balancing, which means they\nmap a set of configured frontend TCP or UDP ports to corresponding backend\nports. Load balancers are configured at the project level.\n\nLoad balancers are configured for the following workload types:\n\n- Workloads running on VMs.\n- Containerized workloads inside the Kubernetes cluster.\n\nThere are three ways to configure load balancers in\nGDC:\n\n- Use the [Networking Kubernetes Resource Model (KRM)\n API](/distributed-cloud/hosted/docs/latest/appliance/apis/service/networking/networking-api-overview). You can use this API to create load balancers.\n- Use the [gdcloud CLI](/distributed-cloud/hosted/docs/latest/appliance/resources/gdcloud-overview). You can use this API to create load balancers.\n- Use the Kubernetes Service directly from the Kubernetes cluster. This method only creates zonal load balancers.\n\nLoad balancer components\n------------------------\n\nWhen you use the KRM API or gdcloud CLI to configure the load\nbalancer, you use an L4 passthrough load balancer:\n\n- L4 means the protocol is either TCP or UDP.\n- Passthrough means there is no proxy between workload and client.\n\nThe load balancer consists of the following configurable components:\n\n- **Forwarding rules**: specify what traffic is forwarded, and to which\n backend service. Forwarding rules have the following specifications:\n\n - Consists of three tuples, CIDR, port and protocol, for the client to access.\n - Supports TCP and UDP protocols.\n - Offers internal and external forwarding rules. Clients can access internal forwarding rules from within the Virtual Private Cloud (VPC). Clients can access external forwarding rules from outside the GDC platform or from within by workloads that have `EgressNAT` value defined.\n - Forwarding rules connect to a backend service. You can point multiple forwarding rules to point to the same backend service.\n- **Backend services**: are the load balancing hub that link forwarding rules,\n health checks and backends together. A backend service references a backend\n object, that identifies the workloads the load balancer forwards the traffic\n to. There are limitations on what backends a single backend service can\n reference:\n\n - One zonal backend resource per zone.\n - One cluster backend resource per cluster. This cannot be mixed with the project backends.\n- **Backends**: a zonal object that specifies the endpoints that serve as the backends for the created backend services. Backend resources must be scoped to a zone. Select endpoints using labels. Scope the selector to a project or cluster:\n\n - A project backend is is a backend that does not have the `ClusterName` field specified. In this case the specified labels apply to all of the workloads in the specific project, in the specific VPC of a zone. The labels are applied to VM and pod workloads across multiple clusters. When a backend service uses a project backend, you can't reference another backend for that zone in that backend service.\n\n - A cluster backend is a backend that has the `ClusterName` field specified. In this case, the specified labels apply to all the workloads in the named cluster in the specified project. You can specify, at most, one backend per zone per cluster in a single backend service.\n\n- **Health checks**: specify the probes to determine whether a given\n workload endpoint in the backend is healthy. The unhealthy endpoint is\n taken out from the load balancer, until it becomes healthy again. Health\n checks are only applicable to VM workloads. Pod workloads can use the built-in Kubernetes probe mechanism to determine if a specific endpoint is healthy.\n\nWhen using the Kubernetes Service directly, you use the `Service` object instead of the previously listed components. You can only target workloads in the cluster where the `Service` object is created.\n\nExternal and internal load balancing\n------------------------------------\n\nGDC applications have access to the following\nnetworking service types:\n\n- **Internal Load Balancer (ILB)**: lets you expose a service to other clusters within the organization.\n- **External Load Balancer (ELB)**: allocates a VIP address from a range that is routable from external workloads and exposes services outside of the GDC organization, such as other organizations inside or outside of the GDC instance.\n\nService virtual IP addresses\n----------------------------\n\nILBs allocate VIP addresses that are internal only to the organization. These\nVIP addresses are not reachable from outside the organization; therefore, you\ncan only use them to expose services to other applications within an\norganization. These IP addresses may overlap between organizations in the same\ninstance.\n\nOn the other hand, ELBs allocate VIP addresses that are externally reachable\nfrom outside the organization. For this reason, ELB VIP addresses must be unique\namong all organizations. Typically, fewer ELB VIP addresses will be available\nfor use by the organization.\n\nWhat's next\n-----------\n\n- [Configure internal load balancers](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/ilb-service)\n- [Configure external load balancers](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/elb-service)"]]
