Merencanakan alamat IP Anda (kubeception)

Dokumen ini menunjukkan cara merencanakan alamat IP untuk penginstalan Google Distributed Cloud yang menyertakan cluster pengguna yang menggunakan kubeception.

Apa yang dimaksud dengan kubeception?

Istilah kubeception digunakan untuk menyampaikan gagasan bahwa cluster Kubernetes digunakan untuk membuat dan mengelola cluster Kubernetes lainnya. Dalam konteks Google Distributed Cloud, kubeception mengacu pada kasus saat platform kontrol untuk cluster pengguna berjalan di satu atau beberapa node dalam cluster admin.

Sebaiknya jangan gunakan kubeception. Sebagai gantinya, sebaiknya gunakan Controlplane V2. Dengan Controlplane V2, node bidang kontrol untuk cluster pengguna berada di cluster pengguna itu sendiri.

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 menyertakan elemen berikut:

  • Workstation admin

  • Cluster admin

  • Satu cluster pengguna ketersediaan tinggi (HA) yang memiliki lima node pekerja

  • Satu cluster pengguna non-HA yang memiliki empat node pekerja

Node cluster admin

Cluster admin memiliki tujuh node:

  • Satu node yang menjalankan bidang kontrol untuk cluster admin
  • Dua node yang menjalankan add-on untuk cluster admin
  • Tiga node yang menjalankan bidang kontrol untuk cluster pengguna HA
  • Satu node yang menjalankan bidang kontrol untuk cluster pengguna non-HA

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 mengilustrasikan 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.

Alamat IP untuk cluster admin dan dua cluster pengguna.
Alamat IP untuk cluster admin dan dua cluster pengguna (Klik untuk memperbesar)

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

Untuk cluster admin yang memiliki tujuh node, Anda perlu menyisihkan delapan alamat IP. Alamat tambahan diperlukan, karena diperlukan selama upgrade, update, dan perbaikan otomatis cluster. Misalnya, Anda dapat menyisihkan alamat IP berikut untuk node di cluster admin:

Alamat IP untuk node di cluster admin
172.16.20.2 - 172.16.20.9

Contoh alamat IP: VIP di subnet cluster admin

Tabel berikut memberikan contoh cara menetapkan VIP untuk dikonfigurasi di load balancer untuk cluster admin. Perhatikan bahwa VIP untuk server Kubernetes API dari cluster pengguna berada di subnet cluster admin. Hal ini karena dalam contoh ini, server Kubernetes API untuk cluster pengguna berjalan di node dalam cluster admin. Perhatikan bahwa dalam file konfigurasi cluster, kolom tempat Anda menentukan VIP untuk server Kubernetes API disebut controlPlaneVIP:

VIP Alamat IP
VIP untuk server Kubernetes API cluster admin 172.16.20.30
Add-on cluster admin VIP 172.16.20.31
VIP untuk server Kubernetes API cluster pengguna 1 172.16.20.32
VIP untuk server Kubernetes API cluster pengguna 2 172.16.20.33

Contoh alamat IP: Node cluster pengguna 1

Untuk cluster pengguna yang memiliki lima node, Anda perlu menyisihkan enam alamat IP. Alamat tambahan diperlukan, karena diperlukan 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.7

Contoh alamat IP: VIP di subnet cluster pengguna 1

Tabel berikut memberikan contoh cara menetapkan VIP untuk dikonfigurasi di load balancer untuk cluster pengguna 1:

VIP Deskripsi Alamat IP
VIP ingress untuk cluster pengguna 1 Dikonfigurasi di load balancer untuk cluster pengguna 1 172.16.21.30
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 masuk.
Ini adalah persyaratan untuk load balancer MetalLB.
172.16.21.30 - 172.16.21.39

Contoh alamat IP: Node cluster pengguna 2

Untuk cluster pengguna yang memiliki empat node, Anda perlu menyisihkan lima alamat IP. Alamat tambahan diperlukan, karena diperlukan 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.6

Contoh alamat IP: VIP di subnet cluster pengguna 2

Tabel berikut memberikan contoh cara menetapkan VIP untuk dikonfigurasi di load balancer untuk cluster pengguna 2:

VIP Deskripsi Alamat IP
VIP ingress untuk cluster pengguna 2 Dikonfigurasi di load balancer untuk cluster pengguna 2 172.16.22.30
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 masuk.
Ini adalah persyaratan untuk load balancer MetalLB.
172.16.22.30 - 172.16.22.39

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:

TujuanRentang CIDR
Pod di cluster admin192.168.0.0/16
Pod di cluster pengguna 1192.168.0.0/16
Pod di cluster pengguna 2192.168.0.0/16
Layanan di cluster admin10.96.232.0/24
Layanan di cluster pengguna 110.96.0.0/20
Layanan di cluster pengguna 210.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, sehingga untuk cluster tertentu, Anda mungkin ingin rentang CIDR Pod yang lebih besar daripada rentang CIDR Service. Contoh rentang Pod untuk cluster pengguna adalah 192.168.0.0/16, yang memiliki alamat 2^(32-16) = 2^16. Namun, contoh rentang Layanan untuk cluster pengguna adalah 10.96.0.0/20, yang hanya memiliki alamat 2^(32-20) = 2^12.

Hindari tumpang-tindih

Sebaiknya gunakan rentang CIDR non-default untuk menghindari tumpang-tindih dengan alamat IP yang dapat dijangkau di jaringan Anda. Rentang Layanan dan Pod tidak boleh tumpang-tindih dengan alamat apa pun di luar cluster yang ingin Anda jangkau dari dalam cluster.

Misalnya, anggap 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). Setiap traffic yang dikirim dari Pod ke alamat dalam salah satu rentang tersebut akan diperlakukan sebagai traffic dalam cluster dan tidak akan menjangkau tujuan apa pun 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 kontrol dan load balancer

  • Alamat IP server vCenter, server DNS, dan server NTP

Sebaiknya rentang Layanan dan Pod Anda berada dalam ruang alamat pribadi RFC 1918.

Berikut adalah salah satu alasan rekomendasi untuk menggunakan alamat RFC 1918. Misalkan rentang Pod atau Layanan Anda berisi alamat IP eksternal. Setiap traffic yang dikirim dari Pod ke salah satu alamat eksternal tersebut akan diperlakukan sebagai traffic dalam cluster dan tidak akan menjangkau 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 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.

Informasi selengkapnya

Mengelola alamat IP node