Cluster native VPC

Autopilot Standard

Halaman ini memberikan ringkasan umum tentang cluster berbasis VPC di Google Kubernetes Engine (GKE).

Halaman ini ditujukan untuk Arsitek cloud dan Spesialis jaringan yang mendesain dan membangun arsitektur jaringan untuk organisasi mereka. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud , lihat Peran dan tugas pengguna GKE umum.

Ringkasan

Di GKE, cluster dapat dibedakan menurut cara mengarahkan traffic dari satu Pod ke Pod lainnya.

Cluster yang menggunakan rentang alamat IP alias disebut cluster VPC native. Cluster yang menggunakan rute statis kustom di jaringan VPC disebut sebagai cluster berbasis rute.

Praktik terbaik:

Rencanakan dan desain konfigurasi cluster Anda dengan Arsitek jaringan, Administrator jaringan, atau tim Engineer jaringan lainnya di organisasi Anda yang bertanggung jawab untuk menentukan, menerapkan, dan memelihara arsitektur jaringan Anda.

Manfaat cluster native VPC

Cluster VPC native memiliki beberapa manfaat:

• Alamat IP Pod dapat dirutekan secara native dalam jaringan VPC cluster dan jaringan VPC lain yang terhubung dengannya melalui Peering Jaringan VPC.

• Alamat IP pod dicadangkan di jaringan VPC sebelum Pod dibuat di cluster Anda. Tindakan ini mencegah konflik dengan resource lain di jaringan VPC dan memungkinkan Anda merencanakan alokasi alamat IP dengan lebih baik.

• Rentang alamat IP pod tidak bergantung pada rute statis kustom. Class ini tidak memakai kuota rute statis kustom dan yang dihasilkan sistem. Sebagai gantinya, rute subnet yang dibuat secara otomatis akan menangani perutean untuk cluster native VPC.

• Anda dapat membuat aturan firewall yang hanya berlaku untuk rentang alamat IP Pod, bukan alamat IP apa pun di node cluster.

• Rentang alamat IP pod, dan rentang alamat IP sekunder subnet secara umum, dapat diakses dari jaringan lokal yang terhubung dengan Cloud VPN atau Cloud Interconnect menggunakan Cloud Router.

• Beberapa fitur, seperti grup endpoint jaringan (NEG), hanya berfungsi dengan cluster native VPC.

Mode jaringan cluster default

VPC native adalah mode jaringan default untuk semua cluster di GKE versi 1.21.0-gke.1500 dan yang lebih baru. Untuk versi sebelumnya, mode jaringan cluster default bergantung pada cara Anda membuat cluster.

Tabel berikut mencantumkan mode jaringan cluster default untuk versi cluster GKE dan metode pembuatan cluster.

Versi GKE	Metode pembuatan cluster	Mode jaringan cluster
Semua versi	Google Cloud console	VPC native
1.21.0-gke.1500 dan yang lebih baru	GKE API atau Google Cloud CLI	VPC native

Anda juga dapat membuat cluster berbasis rute dengan menentukan flag --no-enable-ip-alias saat membuat cluster.

Rentang alamat IP untuk cluster native VPC

Saat membuat cluster native VPC, Anda menentukan subnet di jaringan VPC. Cluster menggunakan rentang alamat IP subnet berikut:

Alokasi alamat IPv4

Cluster native VPC mengalokasikan alamat IPv4 untuk node, Pod, dan Layanan sebagai berikut.

• Alamat IPv4 node: Cluster menggunakan rentang alamat IPv4 utama subnet untuk menetapkan alamat IP ke semua node.

• Alamat IPv4 Pod: Cluster menggunakan satu atau beberapa rentang alamat IPv4 sekunder subnet untuk semua alamat IPv4 Pod. Halaman ini berfokus pada penggunaan satu rentang alamat IPv4 sekunder subnet. Untuk mengetahui informasi tentang cara menggunakan beberapa rentang, lihat Menambahkan rentang alamat IPv4 Pod.

• Alamat IPv4 layanan: Tersedia dua opsi:

  • Alamat IPv4 Layanan dari 34.118.224.0/20: Cluster Autopilot GKE yang menjalankan versi 1.27 dan yang lebih baru serta cluster Standard GKE yang menjalankan versi 1.29 dan yang lebih baru menggunakan rentang alamat IPv4 34.118.224.0/20 untuk Layanan.Google Cloud menggunakan rentang alamat 34.118.224.0/20 untuk tujuan pribadi dan tidak memublikasikan rute apa pun di internet publik untuk rentang ini. Anda tidak dapat menggunakan rentang ini untuk alamat IPv4 eksternal resource Anda.

  • Alamat IPv4 Layanan dari rentang alamat IPv4 sekunder subnet: Untuk semua alamat Layanan (ClusterIP), cluster menggunakan rentang alamat IPv4 sekunder subnet yang berbeda dari rentang yang digunakan oleh Pod.

Alokasi alamat IPv6 (jaringan stack ganda)

• Alamat IPv6 Node dan Pod: di cluster yang diaktifkan untuk jaringan stack ganda, alamat IPv6 node dan semua alamat IPv6 Pod berasal dari rentang alamat IPv6 /96 yang ditetapkan node. Alamat IP node itu sendiri adalah /128 pertama (alamat IPv6 tunggal) dalam rentang ini. Untuk mengetahui informasi selengkapnya, lihat jaringan stack ganda.

• Alamat IPv6 Layanan: Cluster GKE menggunakan rentang alamat IPv6 2600:2D00:0:4::0:0/64 untuk Layanan. Google Cloudmenggunakan rentang alamat 2600:2D00:0:4::0:0/64 untuk tujuan pribadi dan tidak memublikasikan rute apa pun di internet publik untuk rentang ini. Anda tidak dapat menggunakan rentang ini untuk alamat IPv6 eksternal resource Anda.

Tabel berikut berisi ringkasan rentang alamat IP untuk node, Pod, dan Layanan:

Rentang	Penjelasan	Contoh
Node	Alamat IP node ditetapkan dari rentang alamat IP utama subnet yang terkait dengan cluster Anda. Alamat IP node dan ukuran rentang alamat IP sekunder subnet untuk Pod membatasi jumlah node yang dapat didukung cluster. Lihat rentang yang membatasi node untuk informasi selengkapnya.	Jika Anda ingin membuat cluster 900 node, rentang alamat IP utama subnet cluster setidaknya harus /22 (2^(32-22) = 2^10 = 1.024 alamat). Dari 1.024 alamat tersebut, 1.020 dapat digunakan karena empat alamat IP dicadangkan di setiap rentang alamat IP primer. Lihat Rentang alamat IP primer subnet dan Rentang alamat IP sekunder subnet untuk Pod untuk mengetahui informasi selengkapnya.
Pod	Alamat IP pod diambil dari rentang alamat IP sekunder subnet cluster untuk Pod. Kecuali jika Anda menetapkan jumlah maksimum Pod per node yang berbeda, GKE akan mengalokasikan /24rentang IP alias (256 alamat) untuk setiap node untuk Pod yang berjalan di dalamnya. Di setiap node, 256 alamat IP alias tersebut digunakan untuk mendukung hingga 110 Pod.	Untuk cluster dengan 900 node yang mendukung hingga 110 Pod per node, Anda memerlukan 900 × 256 = 230.400 alamat IP untuk Pod. (Setiap node dialokasikan rentang IP alias yang ukuran netmask-nya adalah /24.) Cluster ini memerlukan subnet yang rentang IP sekundernya untuk Pod memiliki subnet mask tidak lebih besar dari /14. Rentang IP sekunder ini memberikan 2^(32-14) = 2^18 = 262.144 alamat IP untuk Pod. Lihat Rentang alamat IP sekunder subnet untuk Pod untuk mengetahui informasi selengkapnya.
Layanan	Alamat layanan (IP cluster) diambil dari rentang alamat IP sekunder subnet cluster untuk Layanan. Anda harus memastikan rentang ini cukup besar untuk memberikan alamat bagi semua Layanan Kubernetes yang dihosting di cluster Anda. Pada cluster GKE Autopilot yang menjalankan versi 1.27 dan yang lebih baru, serta cluster GKE Standard yang menjalankan versi 1.29 dan yang lebih baru, GKE menetapkan alamat IP untuk Layanan GKE dari rentang yang dikelola GKE: 34.118.224.0/20 secara default. Dengan cara ini, Anda tidak perlu menentukan rentang alamat IP Anda sendiri untuk Layanan. Untuk mengetahui detailnya, lihat Rentang alamat IP sekunder subnet untuk Layanan.	Untuk cluster yang menjalankan hingga 3.000 Layanan, Anda memerlukan 3.000 alamat IP cluster. Anda memerlukan rentang sekunder ukuran /20 atau yang lebih besar. Rentang alamat IP /20 menghasilkan 2^(32-20) = 2^12 = 4.096 alamat IP. Lihat Rentang alamat IP sekunder subnet untuk Layanan untuk mengetahui informasi selengkapnya.

Alamat IPv4 internal

Alamat IPv4 yang Anda gunakan untuk subnet cluster native VPC harus berasal dari rentang subnet yang valid. Rentang yang valid mencakup alamat IPv4 pribadi, seperti RFC 1918, dan alamat IP publik yang digunakan secara pribadi. Lihat Rentang yang valid dan Rentang yang dibatasi dalam dokumentasi VPC untuk mengetahui informasi selengkapnya tentang rentang IPv4 subnet yang valid.

Untuk mengetahui informasi penting tentang penggunaan alamat pribadi yang bukan alamat RFC 1918, lihat Menggunakan rentang alamat IPv4 pribadi non-RFC 1918.

Untuk mengetahui informasi penting tentang penggunaan rentang alamat IPv4 publik yang digunakan secara pribadi, lihat Mengaktifkan rentang alamat IP publik yang digunakan secara pribadi.

Metode penetapan rentang IPv4 sekunder subnet

Anda dapat menetapkan rentang alamat IP Pod dan rentang alamat Layanan (ClusterIP) ke cluster native VPC. Rentang alamat IP ini dapat dikelola oleh GKE atau dikelola pengguna.

Anda harus memahami istilah utama berikut untuk memahami metode penetapan rentang sekunder.

Penetapan: penetapan rentang alamat IP mengacu pada proses mengalokasikan rentang subnet tertentu ke cluster native VPC. Hal ini akan membuat kumpulan alamat IP yang dapat digunakan komponen dalam cluster, seperti Pod dan Layanan.

Pengelolaan: pengelolaan rentang alamat IP mengacu pada operasi CRUD yang sedang berlangsung (pembuatan, pembaruan, penghapusan, pembacaan) di tingkat cluster, node pool, atau Pod, yang terkait dengan rentang subnet yang ditetapkan dan alokasi resource dalam cluster native VPC Anda.

Rentang sekunder yang dikelola GKE (default)

Untuk cluster GKE Autopilot yang menjalankan versi 1.27 dan yang lebih baru serta cluster GKE Standard yang menjalankan versi 1.29 dan yang lebih baru, GKE menetapkan alamat IP untuk Layanan dari rentang yang dikelola GKE secara default: 34.118.224.0/20. Dengan cara ini, Anda tidak perlu menentukan rentang alamat IP Anda sendiri untuk Layanan. Pertimbangan berikut berlaku:

• Secara opsional, Anda dapat menentukan rentang kustom untuk Layanan menggunakan flag --services-ipv4-cidr.
• Jika Anda hanya menentukan ukuran rentang menggunakan flag --services-ipv4-cidr (misalnya, /22), GKE tetap menggunakan rentang yang dikelola GKE untuk mendapatkan sub-rentang alamat.
• GKE tidak membuat rentang alamat IP sekunder terpisah untuk Layanan saat rentang yang dikelola GKE digunakan.

Dikelola pengguna

Untuk kontrol penuh atas alokasi alamat IP, Anda dapat mengelola subnet cluster native VPC secara manual.

Anda dapat membuat rentang alamat IP sekunder subnet, lalu membuat cluster yang menggunakan rentang tersebut. Selama pembuatan cluster, tentukan nama rentang subnet untuk Pod dan Layanan. Jika membuat rentang sekunder secara manual, Anda harus mengelolanya sendiri.

Perhatian: Rentang yang dikelola pengguna memungkinkan Anda menggunakan rentang sekunder subnet yang lebih kecil dari yang dimungkinkan saat menggunakan rentang yang dikelola oleh GKE. Berhati-hatilah saat membuat rentang alamat Pod yang lebih kecil dari /21 karena Anda dapat kehabisan alamat IP Pod seiring bertambahnya cluster Anda.

Rentang alamat IP terkecil yang dapat Anda buat tanpa menggunakan CIDR multi-Pod yang terpisah-pisah adalah /28, tetapi rentang tersebut hanya memungkinkan Anda membuat 1 node dengan maksimum 8 Pod. Anda harus menggunakan rentang yang cukup besar untuk jumlah node maksimum yang dibutuhkan.

Rentang minimum yang dapat digunakan juga bergantung pada jumlah maksimum Pod per Node.

Lihat tabel di Rentang CIDR Pod di cluster Standard untuk mengetahui rentang CIDR minimum yang dapat digunakan untuk berbagai nilai Pod maksimum per node.

Jika rentang alamat IP untuk Pod sudah habis, Anda harus melakukan salah satu hal berikut:

• Buat cluster baru dengan rentang alamat IP yang lebih besar.
• Buat ulang node pool setelah menurunkan --max-pods-per-node untuk node pool.
• Perluas rentang alamat IP Pod sekunder menggunakan CIDR multi-Pod yang terpisah-pisah.

Perbedaan dengan cluster berbasis rute

Skema alokasi untuk alamat Pod dan Layanan (ClusterIP) berbeda dengan skema yang digunakan oleh cluster berbasis rute. Daripada menetapkan satu CIDR untuk Pod dan Layanan secara bersamaan, Anda harus memilih atau membuat dua rentang alamat IP sekunder di subnet cluster: satu untuk Pod dan satu lagi untuk Layanan.

Pertimbangan VPC Bersama

Saat membuat cluster native VPC di lingkungan VPC Bersama, pemilik project, editor, atau akun utama Identity and Access Management (IAM) dengan peran Admin Jaringan di project host VPC Bersama harus membuat subnet dan rentang alamat IP sekunder cluster secara manual. Administrator project layanan yang membuat cluster setidaknya harus memiliki izin tingkat subnet ke subnet dalam project host jaringan VPC Bersama.

Dalam lingkungan VPC Bersama, rentang alamat IP sekunder tidak dapat dikelola oleh GKE. Admin Jaringan di project host VPC Bersama harus membuat subnet dan rentang alamat IP sekunder sebelum Anda dapat membuat cluster. Untuk contoh yang menunjukkan cara menyiapkan cluster native VPC di jaringan VPC Bersama, lihat Menyiapkan cluster dengan VPC Bersama.

Perencanaan rentang alamat IP

Gunakan informasi di bagian berikut untuk membantu menghitung ukuran rentang alamat IP utama dan sekunder dari subnet yang digunakan oleh cluster Anda.

Rentang alamat IPv4 primer subnet

Pertimbangkan hal berikut saat Anda merencanakan rentang alamat IPv4 utama subnet cluster:

• Setiap subnet harus memiliki rentang alamat IP primer. Ini adalah rentang alamat IP yang digunakan GKE untuk mengalokasikan alamat IP untuk load balancing dan node internal.
• Anda tidak dapat menyusutkan atau mengubah rentang alamat IP utama subnet setelah subnet dibuat.
• Setelah membuat subnet, Anda dapat memperluas rentang alamat IP utamanya, tetapi Anda tidak dapat menguranginya. Jika memperluas subnet yang digunakan oleh cluster dengan jaringan yang diizinkan, Anda harus menambahkan rentang alamat IP yang diperluas ke daftar jaringan yang diizinkan bidang kontrol. Sebelum memperluas rentang, pastikan untuk meninjau batasan dan rekomendasi dalam Memperluas rentang IPv4 utama.
• Dua alamat IP pertama dan terakhir dalam rentang alamat IP primer dicadangkan oleh Google Cloud.
• Cluster dengan Private Service Connect menggunakan rentang subnet utama untuk menyediakan alamat IP internal yang ditetapkan ke endpoint bidang kontrol. Namun, Anda dapat mengganti penyediaan alamat IP ini dengan tanda private-endpoint-subnetwork. Untuk mempelajari lebih lanjut, lihat Membuat cluster dan memilih rentang alamat IP bidang kontrol.

Tabel berikut menunjukkan jumlah maksimum node yang dapat Anda buat berdasarkan ukuran rentang alamat IPv4 utama subnet dan konfigurasi cluster:

• Skenario 1: jumlah maksimum node dalam cluster yang menggunakan subnet default.
• Skenario 2: jumlah maksimum node dalam cluster Private Service Connect yang tidak menggunakan flag private-endpoint-subnetwork.

Rentang alamat IP primer subnet	Skenario 1	Skenario 2
/29 Ukuran minimum untuk rentang alamat IP utama subnet	4 node	3 node
/28	12 node	11 node
/27	28 node	27 node
/26	60 node	59 node
/25	124 node	123 node
/24	252 node	251 node
/23	508 node	507 node
/22	1.020 node	1.019 node
/21	2.044 node	2.043 node
/20 Ukuran default rentang alamat IP primer subnet di jaringan mode otomatis	4.092 node	4.091 node
/19	8.188 node	8.187 node
/8 Ukuran maksimum untuk rentang alamat IP utama subnet	16.777.212 node	16.777.211 node

Memperluas rentang alamat IP utama

Jika kehabisan alamat IP di rentang alamat IP utama, Anda dapat memperluas rentang alamat IP utama kapan saja, bahkan saat Google Cloud resource, seperti load balancer dan grup endpoint jaringan, menggunakan subnet.

Sebelum Anda memperluas rentang alamat IP utama, pertimbangkan hal berikut:

• Tidak boleh ada rentang alamat IP yang tumpang tindih di subnet.
• GKE menggunakan rentang alamat IP utama untuk mengalokasikan alamat IP untuk load balancer dan node internal.
• Jika cluster menggunakan jaringan yang diizinkan, Anda harus menambahkan rentang alamat IP utama yang diperluas ke daftar jaringan yang diizinkan.

Formula yang berguna

Anda dapat menggunakan formula berikut untuk:

• Hitung jumlah maksimum node, N, yang dapat didukung oleh netmask tertentu di cluster yang menggunakan subnet default. Gunakan S untuk ukuran netmask, yang rentangnya valid antara 8 dan 29, inklusif.

  N = 2^{(32 -S)} - 4

• Hitung ukuran netmask, S, yang diperlukan untuk mendukung maksimum N node:

  S = 32 - ⌈log₂(N + 4)⌉

  ⌈⌉ adalah fungsi plafon (bilangan bulat terkecil), yang berarti membulatkan ke bilangan bulat berikutnya. Rentang yang valid untuk ukuran netmask, S, adalah antara 8 dan 29, inklusif.

Di cluster Private Service Connect yang tidak menggunakan tanda private-endpoint-subnetwork, Anda dapat menggunakan formula sebelumnya, tetapi mengurangi nilai N sebesar 1.

Pertimbangan pengukuran cluster untuk rentang alamat IP sekunder untuk Pod

Untuk menghitung jumlah maksimum Pod yang dapat didukung cluster Anda, pertimbangkan ukuran subnet Pod dan jumlah maksimum Pod per node. Jumlah maksimum Pod bergantung pada mask subnet dan jumlah maksimum Pod per node. Selain itu, ingatlah bahwa beberapa alamat IP dicadangkan dalam rentang utama.

Variabel utama

• Q: jumlah maksimum Pod per node.
• DS: ukuran blok CIDR yang dipilih untuk subnet Pod (misalnya, /17).
• M: ukuran netmask untuk rentang Pod setiap node.
• HM: jumlah bit host untuk netmask rentang Pod node.
• HD: jumlah bit host untuk blok CIDR subnet Pod.
• MN: jumlah maksimum node yang dapat didukung.
• MP: jumlah maksimum Pod yang dapat didukung.
• S: panjang awalan rentang alamat IP utama subnet.
• N: jumlah alamat IP yang dapat digunakan dalam rentang alamat IP utama subnet.

Langkah-langkah untuk menghitung jumlah maksimum Pod

1. Tentukan Pod maksimum per node (Q):

   • Untuk cluster Autopilot, nilai Q ditetapkan pada 32.
   • Untuk cluster Standard, Anda dapat mengonfigurasi Q.

2. Tentukan ukuran blok CIDR untuk subnet Pod (DS):

   • Tentukan ukuran blok CIDR yang dipilih untuk subnet Pod (misalnya, /17).

3. Hitung ukuran netmask (M):

   M = 31 - ⌈log₂(Q)⌉
   

   Ganti Q dengan nilai maksimum Pod per node. Gunakan fungsi ceiling (⌈ ⌉) untuk membulatkan ke bilangan bulat terdekat.

4. Hitung bit host untuk rentang Pod (HM):

   HM = 32 - M
   

5. Hitung bit host untuk blok CIDR yang dipilih (HD):

   HD = 32 - DS
   

6. Hitung jumlah maksimum node (MN):

   MN = 2<sup>(HD - HM)</sup>
   

   Hasil penghitungan ini adalah jumlah maksimum node yang dapat didukung oleh subnet Pod yang dipilih.

7. Hitung jumlah maksimum Pod (MP):

   MP = MN * Q
   

   Hasil perhitungan ini adalah jumlah maksimum Pod yang dapat didukung cluster.

8. Hitung jumlah alamat IP yang dapat digunakan dalam rentang utama (N): none N = 2<sup>(32-S)</sup> - 4 Dengan S adalah panjang awalan rentang CIDR utama untuk subnet.

   Catatan: Dua alamat IP pertama dan terakhir dalam rentang alamat IP primer dicadangkan oleh Google Cloud.

Catatan penting

• Semua alamat IP dalam rentang sekunder dapat digunakan untuk Pod.
• Penghitungan ini memberikan nilai maksimum teoretis. Performa di dunia nyata dapat dipengaruhi oleh faktor lain.

Contoh

Misalkan Anda membuat cluster GKE Autopilot dengan hal berikut:

• Blok CIDR subnet Pod /17 (DS = 17).
• Maksimum 32 Pod per node (Q = 32).

Hitung jumlah maksimum Pod:

1. M = 31 - ⌈log₂(32)⌉ = 26
2. HM = 32 - 26 = 6
3. HD = 32 - 17 = 15
4. MN = 2(15 - 6) = 512
5. MP = 512 * 32 = 16,384

Cluster ini dapat mendukung maksimum 512 node dan 16.384 Pod.

Anda dapat menambahkan lebih banyak alamat IPv4 untuk Pod dengan menambahkan rentang alamat IPv4 Pod atau dengan menambahkan subnet ke cluster.

Rentang alamat IP sekunder subnet untuk Layanan

Rencanakan rentang alamat IP sekunder Anda dengan cermat untuk Layanan. Karena ini juga merupakan rentang alamat IP sekunder subnet, rentang ini tidak dapat diubah setelah cluster dibuat.

Jika Anda menggunakan layanan multi-cluster, objek ServiceImport akan menggunakan alamat IP dari rentang alamat IP sekunder untuk Layanan.

Pada cluster GKE Autopilot yang menjalankan versi 1.27 dan yang lebih baru, serta cluster GKE Standard yang menjalankan versi 1.29 dan yang lebih baru, GKE menetapkan alamat IP untuk Layanan dari rentang yang dikelola GKE secara default: 34.118.224.0/20. Dengan cara ini, Anda tidak perlu menentukan rentang alamat IP Anda sendiri untuk Layanan. Pertimbangan berikut berlaku:

• Secara opsional, Anda dapat menentukan rentang kustom untuk Layanan menggunakan flag --services-ipv4-cidr atau flag --services-secondary-range-name.
• Jika Anda hanya menentukan ukuran rentang menggunakan flag --services-ipv4-cidr (misalnya, /22), GKE tetap menggunakan rentang yang dikelola GKE untuk mendapatkan sub-rentang alamat.
• GKE tidak membuat rentang alamat IP sekunder terpisah untuk Layanan saat rentang yang dikelola Google digunakan. Rentang yang dikelola GKE tidak menggunakan kuota rentang alamat IP sekunder untuk subnet Anda.

Tabel berikut menunjukkan jumlah maksimum Layanan yang dapat dibuat dalam satu cluster menggunakan subnet, berdasarkan ukuran rentang alamat IP sekunder subnet untuk Layanan.

Rentang IP sekunder untuk Layanan	Jumlah Layanan maksimum
/28 Rentang alamat layanan sekecil mungkin jika metode penetapan rentang sekunder dikelola pengguna	16 Layanan
/27 Rentang alamat layanan terkecil yang dimungkinkan saat metode penetapan rentang sekunder dikelola oleh GKE	32 Layanan
/26	64 Layanan
/25	128 Layanan
/24	256 Layanan
/23	512 Layanan
/22	1.024 Layanan
/21	2.048 Layanan
/20 Ukuran default untuk rentang IP sekunder subnet untuk Layanan saat metode penetapan rentang sekunder dikelola oleh GKE	4.096 Layanan
/19	8.192 Layanan
/18	16.384 Layanan
/17	32.768 Layanan
/16 Rentang alamat IP Layanan seluas mungkin	65.536 Layanan

Membagikan rentang alamat IP di seluruh cluster GKE

Anda dapat membagikan rentang utama, rentang alamat IP sekunder untuk Pod, dan rentang alamat IP sekunder untuk Layanan antar-cluster di subnetwork yang sama. Perilaku ini tersedia untuk cluster Standar dan Autopilot.

Anda mungkin ingin membagikan rentang alamat IP jika memiliki tim terpusat yang mengelola infrastruktur cluster. Anda dapat mengurangi overhead dengan membuat tiga rentang untuk Pod, Layanan, dan node, serta menggunakan kembali atau membagikannya, terutama dalam model VPC Bersama. Pengaturan ini juga dapat memudahkan administrator jaringan untuk mengelola alamat IP dengan tidak mengharuskan mereka membuat subnet tertentu untuk setiap cluster.

Membagikan rentang subnet yang disesuaikan untuk bidang kontrol

Secara default, GKE menggunakan rentang subnet utama untuk menyediakan endpoint internal bidang kontrol. Namun, di cluster dengan Private Service Connect, Anda dapat mengonfigurasi GKE untuk menyediakan endpoint internal dari subnet berbeda yang Anda buat. Anda dapat membagikan subnet ini di antara cluster lain, atau di seluruh project jika Anda menggunakan VPC Bersama.

Membagikan rentang alamat IP utama untuk node

Jika Anda membuat lebih dari satu cluster di subnet, rentang alamat IP utama untuk node akan dibagikan secara default.

Berbagi alamat IP primer untuk node memiliki batasan berikut:

• Jika Anda berbagi rentang alamat IP primer untuk node dengan dua atau beberapa cluster native VPC, satu cluster dapat menggunakan sebagian besar rentang alamat IP bersama, sehingga cluster lainnya tidak memiliki alamat IP yang memadai untuk meluaskan.

Membagikan rentang alamat IP sekunder untuk Pod

Saat Anda membagikan rentang sekunder untuk Pod, setiap Pod masih akan mendapatkan alamat IP yang unik.

Berbagi rentang alamat IP sekunder untuk Pod memiliki batasan berikut:

• Jika Anda berbagi rentang alamat IP sekunder untuk Pod dengan dua atau beberapa cluster native VPC, satu cluster dapat menggunakan sebagian besar rentang alamat IP bersama, sehingga cluster lain tidak memiliki alamat IP yang memadai untuk diperluas.

• Di antara berbagai jenis rentang sekunder, baik rentang Pod yang dikelola GKE dan rentang Pod tambahan tidak dapat dibagikan di seluruh cluster.

• Untuk membagikan rentang alamat IP sekunder, teruskan rentang tersebut pada command line dengan --cluster-secondary-range. Anda tidak dapat menggunakan rentang sekunder bersama saat membuat cluster di UI.

Membagikan rentang alamat IP sekunder untuk Layanan

Dua cluster atau lebih dapat menggunakan rentang alamat IPv4 sekunder subnet yang sama secara bersamaan untuk Layanan jika Anda menggunakan rentang sekunder yang dikelola pengguna.

Untuk mengonfigurasi dua atau beberapa cluster agar berbagi rentang alamat IPv4 sekunder subnet yang sama untuk Layanan, gunakan rentang alamat IPv4 sekunder subnet yang sama saat Anda membuat setiap cluster. Tidak ada tanda konfigurasi terpisah yang diperlukan untuk berbagi rentang alamat IPv4 umum untuk Layanan.

Saat berbagi rentang alamat IPv4 umum untuk Layanan, setiap cluster menggunakan seluruh rentang alamat IPv4 sekunder subnet untuk Layanan secara internal. Alamat IP untuk Layanan diprogram dalam setiap node cluster, tetapi tidak ditetapkan ke antarmuka jaringan node mana pun. Alamat IP layanan tidak dapat dirutekan dalam jaringan VPC cluster. Alamat IP layanan hanya dapat digunakan oleh Pod klien dalam cluster yang sama dengan Layanan.

Saat Pod mengirim paket ke alamat IP Layanan, konfigurasi iptables atau eBPF pada node akan melakukan Penafsiran Alamat Jaringan tujuan (NAT), yang mengubah alamat IP tujuan paket dari IP Layanan ke alamat IP Pod yang aktif. Paket diarahkan berdasarkan alamat IP Pod tujuan.

Berbagi rentang alamat IP sekunder untuk Layanan memberikan manfaat berikut:

• Mengurangi jumlah rentang alamat IP sekunder unik untuk Layanan yang dibuat di subnet
• Gunakan lebih sedikit alamat IP

Berbagi rentang alamat IP sekunder untuk Layanan memiliki batasan berikut:

• Berbagi rentang alamat IP sekunder untuk Layanan tidak didukung dengan Cloud DNS lingkup VPC untuk GKE.

• Anda tidak dapat membagikan rentang yang cocok dengan ekspresi reguler berikut:

  ^gke-.*-services-[abcdef0-9]{8}
  

• Untuk membagikan rentang alamat IP sekunder untuk layanan, teruskan rentang tersebut pada command line dengan --cluster-secondary-range. Anda tidak dapat menggunakan rentang sekunder bersama untuk layanan saat membuat cluster di UI.

Node yang membatasi rentang

Jumlah maksimum Pod dan Service untuk cluster GKE tertentu dibatasi oleh ukuran rentang sekunder cluster. Jumlah maksimum node dalam cluster dibatasi oleh ukuran rentang alamat IP utama subnet cluster dan rentang alamat Pod cluster.

Pesan error berikut menunjukkan bahwa rentang alamat IP primer subnet atau rentang alamat IP Pod cluster (rentang alamat IP sekunder subnet untuk Pod) telah habis:

Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted

Anda dapat menambahkan lebih banyak alamat IP untuk node dengan memperluas subnet primer, atau menambahkan alamat IP baru untuk Pod menggunakan CIDR multi-Pod yang terpisah-pisah. Untuk mengetahui informasi selengkapnya, lihat Ruang alamat IP yang kosong tidak cukup untuk Pod.

Jejaring stack ganda IPv4/IPv6

Dengan jaringan stack ganda IPv4/IPv6, Anda dapat menentukan cara GKE mengalokasikan alamat IP (ipFamilies) ke objek berikut:

• Untuk Pod dan node, GKE mengalokasikan alamat IPv4 dan IPv6.
• Untuk Layanan, GKE mengalokasikan alamat stack tunggal (khusus IPv4 atau IPv6), atau alamat stack ganda.

Pada GKE versi 1.24 atau yang lebih baru, Anda dapat mengaktifkan jaringan stack ganda untuk cluster GKE baru di jaringan VPC mandiri dan Bersama. Anda juga dapat menerapkan kebijakan jaringan jika jaringan stack ganda diaktifkan. Jika Anda melihat error validasi saat mengaktifkan jaringan stack ganda pada cluster GKE yang telah diupgrade dari versi 1.24 ke versi 1.25 atau 1.26, hubungi Google Cloud tim dukungan.

Catatan: Anda dapat mengonfigurasi cluster agar memiliki node dengan akses internal (pribadi) atau eksternal (publik) menggunakan flag enable-private-nodes. Flag enable-private-nodes hanya memengaruhi alamat IPv4 node di cluster Anda. Oleh karena itu, tanda ini tidak memengaruhi konfigurasi jaringan stack ganda IPv4/IPv6 yang Anda tentukan di bagian ini.

Manfaat

Jaringan stack ganda memberikan manfaat berikut:

• Memungkinkan komunikasi IPv6 end-to-end.
• Memungkinkan performa yang lebih baik dibandingkan dengan penafsiran alamat jaringan (NAT) atau tunneling IP. Hal ini tercapai karena tidak ada terjemahan IPv6 ke IPv4.

Ketersediaan

Jaringan stack ganda dengan GKE memiliki batasan berikut:

• Jaringan stack ganda hanya tersedia untuk cluster berbasis VPC dengan GKE Dataplane V2 yang diaktifkan.
• Jaringan stack ganda hanya didukung di subnet dalam VPC mode kustom. Untuk mengetahui informasi selengkapnya, lihat Google Cloud jenis jaringan VPC.
• Alamat IPv6 stack tunggal untuk Pod atau node tidak didukung.
• Cluster stack ganda menggunakan memori tambahan per node untuk mendukung IPv4 dan IPv6 dibandingkan dengan cluster khusus IPv4. Pertimbangkan karakteristik ini saat menyiapkan cluster berskala besar.
• Cluster stack ganda tidak mendukung Akses Google Pribadi melalui IPv6.
• GKE versi 1.26.0-gke.2200 dan yang lebih baru mendukung data IPv6 (AAAA) dengan Cloud DNS untuk operasi internal cluster dan kueri DNS eksternal.
• Layanan stack ganda didukung untuk Layanan ClusterIP, NodePort, dan LoadBalancer.
• IPv6 tidak didukung untuk node Windows.

Pertimbangkan batasan sebelumnya sebelum membuat cluster dengan jaringan stack ganda. Untuk mengetahui informasi selengkapnya, pelajari cara membuat cluster native VPC dengan jaringan stack ganda.

Penetapan alamat IPv6 Publik dan Pribadi

Tabel berikut memberikan ringkasan alamat IPv6 publik dan pribadi dengan perilaku dan konfigurasi jaringan stack ganda:

Flag ipv6-access-type	Penetapan alamat IP	Rentang subnet
EXTERNAL	GKE menetapkan alamat IPv6 eksternal yang dapat dirutekan ke internet.	Dari 2600:1900/28
INTERNAL	GKE menetapkan alamat IPv6 internal yang tidak dapat dirutekan ke internet. Cluster dengan jenis akses IPv6 INTERNAL tidak dapat mengakses internet melalui alamat IPv6. Cloud NAT tidak mendukung alamat IPv6.	Dari fd20::/20 (yang merupakan subset rentang ULA keseluruhan: fc00::/7).

Untuk mempelajari lebih lanjut, lihat cara menggunakan jaringan stack ganda untuk cluster native VPC.

Arsitektur

Cluster dengan jaringan stack ganda IPv4/IPv6 memiliki rentang berikut yang dialokasikan:

• Rentang /64 ke setiap subnet sebagai rentang utama.
• Rentang per node /96 dari rentang utama untuk digunakan sebagai rentang alamat IP node utama.

• Rentang /112 per node dari rentang alamat IP node utama yang akan digunakan sebagai rentang alamat IP Pod untuk node tersebut. Dengan jaringan stack ganda, Pod mendapatkan alamat IPv6-nya dari rentang alamat IP Pod secara keseluruhan (serupa dengan node), dan bukan dari rentang sekunder untuk Pod yang dicadangkan ke alamat IPv4.

  Rentang alamat IP Pod keseluruhan terdiri dari rentang yang tidak tumpang-tindih dari rentang IP node utama. Oleh karena itu, rentang IP Pod ini tidak berdekatan.

• Rentang /112 yang akan digunakan untuk Layanan. Rentang ini berasal dari rentang /64 dari rentang alamat pribadi Google yang telah dicadangkan untuk rentang alamat IP Layanan sekunder GKE.

Diagram berikut menunjukkan cara Google Cloud dan GKE mengalokasikan alamat IPv6:

Alokasi alamat IPv6 di GKE.

Dalam diagram, rentang utama subnet VPC adalah 2600:1900:0:1::/64 dan rentang yang dicadangkan untuk Layanan GKE adalah 2600:2D00:0:4::0:0/64. Setiap node dalam cluster memiliki rentang /96 untuk rentang alamat IP node utama dan rentang /112 untuk rentang alamat IP Pod. Cluster ini juga memiliki rentang alamat IP Layanan sekunder /112.

Catatan: GKE otomatis memilih rentang alamat IP IPv6 untuk rentang alamat IP Pod dan rentang alamat IP Layanan sekunder.

Layanan

Anda dapat membuat Layanan stack ganda IPv4/IPv6 dengan jenis ClusterIP atau NodePort. Cluster GKE baru yang menjalankan versi 1.29 atau yang lebih baru mendukung Layanan stack ganda jenis LoadBalancer.

Anda dapat mengekspos Deployment dengan Layanan jenis ClusterIP, NodePort, atau LoadBalancer. Untuk setiap jenis Layanan ini, Anda dapat menentukan kolom ipFamilies dan ipFamilyPolicy sebagai Layanan IPv4, IPv6, atau stack ganda. Untuk mengetahui informasi selengkapnya, lihat contoh cara menyiapkan Deployment.

Langkah berikutnya

• Pelajari Peering Jaringan VPC lebih lanjut.
• Pelajari cara membuat cluster VPC native.
• Pelajari insight penggunaan alamat IP GKE.