Dokumen ini menunjukkan cara merencanakan alamat IP untuk penginstalan Google Distributed Cloud yang mencakup cluster pengguna yang menggunakan kubeception.
Apa itu {i>kubeception<i}?
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 ketika bidang kontrol untuk cluster pengguna berjalan pada satu atau beberapa node dalam cluster admin.
Kami tidak merekomendasikan penggunaan kubeception. Sebagai gantinya, kami merekomendasikan penggunaan Controlplane V2. Dengan Controlplane V2, node bidang kontrol untuk cluster pengguna berada dalam 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 mencakup elemen-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 worker node
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 dengan ketersediaan tinggi (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 pada node cluster, sehingga tidak diperlukan VM tambahan untuk load balancing.
Subnet
Untuk contoh ini, asumsikan bahwa setiap cluster berada di VLAN-nya sendiri, dan cluster berada di subnet ini:
| 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 suatu Layanan. Misalnya, dalam 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 yang berada 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 menentukan VIP untuk dikonfigurasi pada load balancer untuk cluster admin. Perhatikan bahwa VIP untuk server Kubernetes API dari cluster pengguna berada di subnet cluster admin. Hal tersebut karena dalam contoh ini, server Kubernetes API untuk cluster
pengguna berjalan pada node di cluster admin. Perlu diperhatikan bahwa dalam file konfigurasi cluster, kolom tempat Anda menentukan VIP untuk server Kubernetes API disebut controlPlaneVIP:
| VIP | IP address |
|---|---|
| VIP untuk server Kubernetes API cluster admin | 172.16.20.30 |
| VIP add-on cluster admin | 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 1 pengguna
Tabel berikut memberikan contoh cara menentukan VIP untuk dikonfigurasi pada load balancer untuk cluster pengguna 1:
| VIP | Deskripsi | IP address |
|---|---|---|
| VIP masuk untuk cluster pengguna 1 | Dikonfigurasi pada 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 pada 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 2 pengguna
Tabel berikut memberikan contoh cara menentukan VIP untuk dikonfigurasi pada load balancer untuk cluster pengguna 2:
| VIP | Deskripsi | IP address |
|---|---|---|
| VIP masuk untuk cluster pengguna 2 | Dikonfigurasi pada 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 pada 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 Service
Sebelum membuat cluster, Anda harus menentukan rentang CIDR yang akan digunakan untuk alamat IP Pod dan rentang CIDR lain yang akan digunakan untuk ClusterIP alamat Layanan Kubernetes.
Tentukan rentang CIDR yang ingin Anda gunakan untuk Pod dan Service. 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 bisa sama untuk beberapa cluster.
Biasanya Anda memerlukan lebih banyak Pod daripada Layanan. Oleh karena itu, untuk cluster tertentu, Anda mungkin menginginkan rentang CIDR Pod yang lebih besar dari rentang Service CIDR. 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.
Menghindari tumpang-tindih
Anda dapat 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 apa pun di luar cluster yang ingin Anda jangkau dari dalam cluster.
Misalnya, rentang Service 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 di salah satu rentang tersebut akan diperlakukan sebagai traffic dalam cluster dan tidak akan mencapai tujuan apa pun di luar cluster.
Secara khusus, rentang Service 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 direkomendasikan untuk menggunakan alamat RFC 1918. Misalkan rentang Pod atau Service 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 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 juga harus mengetahui alamat IP gateway default untuk setiap subnet. Pada contoh sebelumnya, gateway default untuk tiap subnet adalah alamat pertama dalam rentang tersebut. Misalnya, dalam subnet cluster admin, gateway default ditampilkan sebagai 172.16.20.1.