Dokumen ini menunjukkan cara merencanakan alamat IP untuk penginstalan Google Distributed Cloud.
Sebelum memulai
Baca Ringkasan Google Distributed Cloud dan ringkasan penginstalan.
Contoh alokasi alamat IP
Bagian ini memberikan contoh cara mengalokasikan alamat IP statis dalam penginstalan yang mencakup elemen berikut:
Workstation admin
Cluster admin dengan ketersediaan tinggi (HA)
Satu cluster pengguna HA yang memiliki lima worker node
Satu cluster pengguna non-HA yang memiliki empat worker node
Dalam contoh ini, cluster pengguna telah mengaktifkan Controlplane V2. Dengan Controlplane V2, node bidang kontrol untuk cluster pengguna berada di cluster pengguna itu sendiri.
Jika Anda tidak ingin mengaktifkan Controlplane V2 untuk cluster pengguna, lihat Merencanakan alamat IP Anda (kubeception). Istilah kubeception mengacu pada kasus ketika control plane untuk cluster pengguna berjalan di satu atau beberapa node di cluster admin. Sebaiknya jangan gunakan kubeception. Sebaiknya aktifkan Controlplane V2.
Node cluster admin
Admin cluster memiliki tiga node, yang masing-masing menjalankan komponen bidang kontrol.
Load balancing
Untuk contoh ini, asumsikan bahwa cluster menggunakan load balancer MetalLB. Load balancer ini berjalan di node cluster, sehingga tidak ada VM tambahan yang diperlukan untuk load balancing.
Subnet
Untuk contoh ini, asumsikan bahwa setiap cluster berada di VLAN-nya sendiri, dan cluster berada di subnet berikut:
| VM | Subnet | Gateway default |
|---|---|---|
| Workstation admin dan cluster admin | 172.16.20.0/24 | 172.16.20.1 |
| Cluster pengguna 1 | 172.16.21.0/24 | 172.16.21.1 |
| Cluster pengguna 2 | 172.16.22.0/24 | 172.16.22.1 |
Diagram berikut menggambarkan tiga VLAN dan subnet. Perhatikan bahwa VIP tidak ditampilkan terkait dengan node tertentu dalam cluster. Hal ini karena load balancer MetalLB dapat memilih node mana yang mengumumkan VIP untuk setiap Layanan. Misalnya, di cluster pengguna 1, satu node pekerja dapat mengumumkan 172.16.21.31, dan node pekerja lain dapat mengumumkan 172.16.21.32.
Contoh alamat IP: workstation admin
Dalam contoh ini, workstation admin berada di subnet yang sama dengan cluster admin: 172.16.20.0/24. Alamat di dekat alamat node akan cocok untuk workstation admin. Misalnya, 172.16.20.20.
Contoh alamat IP: node cluster admin
Cluster admin dalam contoh ini memiliki tiga node, jadi Anda perlu menetapkan tiga alamat IP. Misalnya, Anda dapat menyisihkan alamat IP berikut untuk node di cluster admin:
| Cluster admin | Alamat IP |
|---|---|
| Cluster admin HA | 172.16.20.2 - 172.16.20.4 |
Contoh alamat IP: VIP untuk cluster admin
Anda harus menyisihkan VIP untuk server Kubernetes API cluster admin.
Perhatikan bahwa di file konfigurasi cluster, kolom untuk VIP ini disebut
controlPlaneVIP. Misalnya, Anda dapat menyisihkan VIP berikut untuk server API Kubernetes dari cluster admin:
| VIP | Alamat IP |
|---|---|
| VIP untuk server Kubernetes API cluster admin | 172.16.20.30 |
Perhatikan bahwa untuk cluster admin HA, controlPlaneVIP harus berada di VLAN yang sama dengan IP node bidang kontrol yang ditentukan dalam network.controlPlaneIPBlock.
Contoh alamat IP: Node cluster pengguna 1
Untuk cluster pengguna yang memiliki delapan node, Anda perlu menyisihkan sembilan alamat IP. Alamat tambahan diperlukan karena dibutuhkan selama upgrade, update, dan perbaikan otomatis cluster. Misalnya, Anda dapat menyisihkan alamat IP berikut untuk node di cluster pengguna 1:
| Alamat IP untuk node di cluster pengguna 1 |
|---|
| 172.16.21.2 - 172.16.21.10 |
Contoh alamat IP: VIP untuk cluster pengguna 1
Tabel berikut memberikan contoh cara Anda dapat menetapkan VIP untuk dikonfigurasi di load balancer untuk cluster pengguna 1:
| VIP | Deskripsi | Alamat IP |
|---|---|---|
| VIP untuk server Kubernetes API cluster pengguna 1 | Dikonfigurasi di load balancer untuk cluster pengguna 1 | 172.16.21.30 |
| VIP Ingress untuk cluster pengguna 1 | Dikonfigurasi di load balancer untuk cluster pengguna 1 | 172.16.21.31 |
| VIP layanan untuk cluster pengguna 1 | Sepuluh alamat untuk Layanan jenis LoadBalancer.Dikonfigurasi sesuai kebutuhan di load balancer untuk cluster pengguna 1. Perhatikan bahwa rentang ini mencakup VIP ingress. Ini adalah persyaratan untuk load balancer MetalLB. |
172.16.21.31 - 172.16.21.40 |
Perhatikan bahwa VIP untuk server Kubernetes API ditentukan dalam loadBalancer.vips.controlPlaneVIP pada file konfigurasi cluster. Jika
ControlPlane V2 diaktifkan, controlPlaneVIP harus berada di
VLAN yang sama dengan IP node bidang kontrol yang ditentukan dalam network.controlPlaneIPBlock.
Contoh alamat IP: Node cluster pengguna 2
Untuk cluster pengguna yang memiliki lima node, Anda perlu menyisihkan enam alamat IP. Alamat tambahan diperlukan karena dibutuhkan selama upgrade, update, dan perbaikan otomatis cluster. Misalnya, Anda dapat menyisihkan alamat IP berikut untuk node di cluster pengguna 2:
| Alamat IP untuk node di cluster pengguna 2 |
|---|
| 172.16.22.2 - 172.16.22.7 |
Contoh alamat IP: VIP untuk cluster pengguna 2
Tabel berikut memberikan contoh cara Anda dapat menetapkan VIP untuk dikonfigurasi di load balancer untuk cluster pengguna 2:
| VIP | Deskripsi | Alamat IP |
|---|---|---|
| VIP untuk server Kubernetes API untuk cluster pengguna 2 | Dikonfigurasi di load balancer untuk cluster pengguna 2 | 172.16.22.30 |
| VIP Ingress untuk cluster pengguna 2 | Dikonfigurasi di load balancer untuk cluster pengguna 2 | 172.16.22.31 |
| VIP layanan untuk cluster pengguna 2 | Sepuluh alamat untuk Layanan jenis LoadBalancer.Dikonfigurasi sesuai kebutuhan di load balancer untuk cluster pengguna 2. Perhatikan bahwa rentang ini mencakup VIP ingress. Ini adalah persyaratan untuk load balancer MetalLB. |
172.16.22.31 - 172.16.22.40 |
Perhatikan bahwa VIP untuk server Kubernetes API ditentukan dalam loadBalancer.vips.controlPlaneVIP pada file konfigurasi cluster. Jika
ControlPlane V2 diaktifkan, controlPlaneVIP harus berada di
VLAN yang sama dengan IP node bidang kontrol yang ditentukan dalam network.controlPlaneIPBlock.
Contoh alamat IP: Pod dan Layanan
Sebelum membuat cluster, Anda harus menentukan rentang CIDR yang akan digunakan untuk alamat IP Pod dan rentang CIDR lain yang akan digunakan untuk alamat ClusterIP Layanan Kubernetes.
Tentukan rentang CIDR yang ingin Anda gunakan untuk Pod dan Layanan. Contoh:
| Tujuan | Rentang CIDR |
|---|---|
| Pod di cluster admin | 192.168.0.0/16 |
| Pod di cluster pengguna 1 | 192.168.0.0/16 |
| Pod di cluster pengguna 2 | 192.168.0.0/16 |
| Layanan di cluster admin | 10.96.232.0/24 |
| Layanan di cluster pengguna 1 | 10.96.0.0/20 |
| Layanan di cluster pengguna 2 | 10.96.128.0/20 |
Contoh sebelumnya menggambarkan poin-poin berikut:
Rentang CIDR Pod dapat sama untuk beberapa cluster.
Biasanya Anda memerlukan lebih banyak Pod daripada Service, jadi untuk cluster tertentu, Anda mungkin menginginkan rentang CIDR Pod yang lebih besar daripada rentang CIDR Service. Contoh rentang Pod untuk cluster pengguna adalah 192.168.0.0/16, yang memiliki 2^(32-16) = 2^16 alamat. Namun, contoh rentang Layanan untuk cluster pengguna adalah 10.96.0.0/20, yang hanya memiliki 2^(32-20) = 2^12 alamat.
Hindari tumpang-tindih
Anda mungkin ingin menggunakan rentang CIDR non-default untuk menghindari tumpang-tindih dengan alamat IP yang dapat dijangkau di jaringan Anda. Rentang Service dan Pod tidak boleh tumpang-tindih dengan alamat di luar cluster yang ingin Anda jangkau dari dalam cluster.
Misalnya, anggaplah rentang Layanan Anda adalah 10.96.232.0/24, dan rentang Pod Anda adalah 192.168.0.0/16 (192.168.0.1 - 192.168.255.254). Semua traffic yang dikirim dari Pod ke alamat dalam salah satu rentang tersebut akan diperlakukan sebagai traffic dalam cluster dan tidak akan mencapai tujuan di luar cluster.
Secara khusus, rentang Layanan dan Pod tidak boleh tumpang-tindih dengan:
Alamat IP node di cluster mana pun
Alamat IP yang digunakan oleh mesin load balancer
VIP yang digunakan oleh node bidang kontrol dan load balancer
Alamat IP server vCenter, server DNS, dan server NTP
Sebaiknya rentang Service dan Pod Anda berada di ruang alamat pribadi RFC 1918.
Berikut adalah salah satu alasan rekomendasi penggunaan alamat RFC 1918. Misalkan rentang Pod atau Service Anda berisi alamat IP eksternal. Semua traffic yang dikirim dari Pod ke salah satu alamat eksternal tersebut akan diperlakukan sebagai traffic dalam cluster dan tidak akan mencapai tujuan eksternal.
Server DNS dan gateway default
Sebelum mengisi file konfigurasi, Anda harus mengetahui alamat IP server DNS yang dapat digunakan oleh workstation admin dan node cluster Anda.
Anda juga harus mengetahui alamat IP gateway default untuk setiap subnet. Dalam contoh sebelumnya, gateway default untuk setiap subnet adalah alamat pertama dalam rentang. Misalnya, di subnet untuk cluster admin, gateway default ditampilkan sebagai 172.16.20.1.