Cluster native VPC

Autopilot Standard

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

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 native VPC.

Untuk cluster GKE Autopilot, perutean traffic VPC native diaktifkan secara default.

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	Konsol Google Cloud	VPC native
1.21.0-gke.1500 dan yang lebih baru	Kubernetes Engine API atau Google Cloud CLI	VPC native
Lebih awal dari 1.21.0-gke.1500	Kubernetes Engine API atau Google Cloud CLI	Berbasis rute

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 ini menggunakan rentang alamat IP subnet berikut:

Alokasi alamat IPv4

Cluster VPC native mengalokasikan alamat IPv4 untuk node, Pod, dan Layanan menggunakan rentang yang berbeda-beda dalam subnet yang ditentukan sebagai berikut.

Alamat IP node: Cluster menggunakan rentang alamat IPv4 utama subnet untuk menetapkan alamat IP ke semua node.
Alamat IP pod: Cluster menggunakan rentang alamat IPv4 sekunder dalam subnet untuk semua alamat IPv4 Pod dalam cluster. Untuk meningkatkan fleksibilitas, Anda dapat menggunakan rentang alamat IPv4 sekunder subnet tambahan dengan mengonfigurasi CIDR multi-Pod terpisah.
Alamat IP layanan: Cluster ini menggunakan rentang alamat IP sekunder yang terpisah untuk semua alamat Service (IP cluster). Untuk mengetahui informasi tentang cara mengaktifkan beberapa cluster agar memiliki rentang IPv4 Layanan yang sama, lihat Berbagi rentang alamat IP di seluruh cluster GKE.

Alokasi alamat IPv6 (jaringan dual-stack)

Alamat IPv6 Pod dan Node: Dalam cluster yang diaktifkan untuk jaringan dual-stack, 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 dual-stack.

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

Rentang Penjelasan Contoh

Node

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¹⁰ = 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 `/24`rentang 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¹⁸ = 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 Autopilot baru yang menjalankan GKE versi 1.27 dan yang lebih baru, GKE menetapkan alamat IP untuk Layanan GKE dari rentang yang dikelola Google: `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¹² = 4.096 alamat IP. Lihat Rentang alamat IP sekunder subnet untuk Layanan untuk mengetahui informasi selengkapnya.

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¹⁰ = 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¹⁸ = 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 Autopilot baru yang menjalankan GKE versi 1.27 dan yang lebih baru, GKE menetapkan alamat IP untuk Layanan GKE dari rentang yang dikelola Google: 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¹² = 4.096 alamat IP.

Lihat Rentang alamat IP sekunder subnet untuk Layanan untuk mengetahui informasi selengkapnya.

Alamat IP internal

Alamat IP yang Anda gunakan untuk subnet cluster native VPC harus berasal dari rentang subnet yang valid. Rentang yang valid mencakup alamat IP pribadi (RFC 1918 dan lainnya) 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 subnet yang valid.

Lihat Menggunakan rentang alamat IP pribadi non-RFC 1918 untuk mendapatkan petunjuk cara mengaktifkan penggunaan rentang ini.

Lihat Mengaktifkan rentang alamat IP publik yang digunakan secara pribadi untuk mendapatkan petunjuk tentang penggunaan rentang ini.

Metode penetapan rentang sekunder

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: menetapkan rentang alamat IP mengacu pada proses pengalokasian rentang subnet tertentu ke cluster VPC native. Tindakan ini akan menetapkan kumpulan alamat IP yang dapat digunakan komponen dalam cluster, seperti Pod dan Layanan.

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

Rentang sekunder yang dikelola GKE (default)

Secara default, GKE menetapkan dan mengelola alamat IP untuk cluster berbasis VPC Anda. Saat membuat cluster, Anda tidak perlu membuat subnet. Anda dapat menentukan rentang CIDR atau ukuran netmask untuk Pod dan Service. GKE menangani pembuatan dan pengelolaan rentang subnet. Misalnya, Anda dapat menentukan 10.1.0.0/16 untuk Pod dan 10.2.0.0/20 untuk Service, atau Anda dapat menentukan /16 untuk Pod dan /20 untuk Service.

Untuk cluster Autopilot yang menjalankan GKE 1.27 dan yang lebih baru, GKE menetapkan alamat IP Layanan dari rentang yang dikelola Google secara default 34.118.224.0/20, sehingga Anda tidak perlu menentukan rentang Layanan sendiri. Pertimbangan berikut berlaku:

Secara opsional, Anda dapat menentukan rentang kustom untuk Layanan menggunakan flag --services-ipv4-cidr.
Jika Anda hanya menentukan ukuran rentang menggunakan tanda --services-ipv4-cidr (misalnya, /22), GKE tetap menggunakan rentang yang dikelola Google untuk mendapatkan sub-rentang alamat.
GKE tidak membuat rentang alamat IP sekunder yang terpisah untuk Layanan saat rentang yang dikelola Google 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 Service. Jika membuat rentang sekunder secara manual, Anda harus mengelolanya sendiri.

Rentang alamat IP terkecil yang dapat Anda buat tanpa menggunakan CIDR multi-Pod terpisah adalah /28, tetapi rentang tersebut hanya memungkinkan Anda membuat 1 node dengan maksimum 8 Pod. Anda harus menggunakan rentang yang cukup besar untuk jumlah maksimum node yang diperlukan. Rentang minimum yang dapat digunakan juga bergantung pada jumlah maksimum Pod per Node.

Lihat tabel dalam Mengoptimalkan alokasi alamat IP untuk mengetahui rentang CIDR minimum yang dapat digunakan bagi 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 Pod yang lebih besar.
Membuat ulang kumpulan node setelah mengurangi --max-pods-per-node untuk kumpulan node.
Perluas rentang alamat IP Pod sekunder menggunakan CIDR multi-Pod yang terputus.

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. Admin 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 IP primer subnet

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.

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

Tabel berikut menunjukkan jumlah maksimum node yang dapat Anda buat di semua cluster yang menggunakan subnet, mengingat ukuran rentang alamat IP primer subnet.

Rentang IP primer subnet	Node maksimum
/29 Ukuran minimum untuk rentang IP primer subnet	4 node
/28	12 node
/27	28 node
/26	60 node
/25	124 node
/24	252 node
/23	508 node
/22	1.020 node
/21	2.044 node
/20 Ukuran default rentang IP primer subnet di jaringan mode otomatis	4.092 node
/19	8.188 node
/8 Ukuran maksimum untuk rentang IP primer subnet	16.777.212 node

Memperluas rentang alamat IP utama

Jika kehabisan alamat IP di rentang alamat IP utama, Anda dapat perluas rentang alamat IP utama kapan saja, bahkan saat resource Google Cloud, 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.

Formula yang berguna

Anda dapat menggunakan formula berikut untuk:

Menghitung jumlah maksimum node, N, yang dapat didukung oleh netmask tertentu. 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 node N:

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.

Rentang alamat IP sekunder subnet untuk Pod

Rencanakan rentang alamat IP sekunder Anda untuk Pod dengan cermat.

Tabel berikut menunjukkan jumlah maksimum node dan Pod yang dapat Anda buat di semua cluster yang menggunakan subnet, mengingat ukuran rentang alamat IP sekunder subnet yang digunakan oleh Pod. Tabel ini mengasumsikan jumlah maksimum Pod per node adalah 110, yang merupakan kepadatan Pod default.

Rentang IP sekunder subnet untuk Pod	Alamat IP Pod maksimum	Node maksimum	Pod maksimum
/24 Rentang IP Pod terkecil saat metode penetapan rentang sekunder dikelola pengguna	256 alamat	1 node	Autopilot: 32 Pod Standar: 110 Pod
/23 Hanya memungkinkan jika metode penetapan rentang sekunder dikelola pengguna	512 alamat	2 node	Autopilot: 64 Pod Standar: 220 Pod
/22 Hanya memungkinkan jika metode penetapan rentang sekunder dikelola pengguna	1.024 alamat	4 node	Autopilot: 128 Pod Standar: 440 Pod
/21 Rentang IP Pod terkecil saat metode penetapan rentang sekunder dikelola oleh GKE	2.048 alamat	8 node	Autopilot: 256 Pod Standar: 880 Pod
/20	4.096 alamat	16 node	Autopilot: 512 Pod Standar: 1.760 Pod
/19	8.192 alamat	32 node	Autopilot: 1.024 Pod Standar: 3.520 Pod
/18	16.384 alamat	64 node	Autopilot: 2.048 Pod Standar: 7.040 Pod
/17	32.768 alamat	128 node	Autopilot: 4.096 Pod Standar: 14.080 Pod
/16	65.536 alamat	256 node	Autopilot: 8.192 Pod Standar: 28.160 Pod
/15	131.072 alamat	512 node	Autopilot: 16.384 Pod Standar: 56.320 Pod
/14 Ukuran default untuk rentang IP sekunder subnet untuk Pod saat metode penetapan rentang sekunder dikelola oleh GKE	262.144 alamat	1.024 node	Autopilot: 32.768 Pod Standar: 112.640 Pod
/13	524.288 alamat	2.048 node	Autopilot: 65.536 Pod Standar: 225.280 Pod
/12	1.048.576 alamat	4.096 node	Autopilot: 131.072 Pod Standar: 450.560 Pod
/11	2.097.152 alamat	8.192 node	Autopilot: 262.144 Pod Standar: 901.120 Pod
/10	4.194.304 alamat	16.384 node	Autopilot: 524.288 Pod Standar: 1.802.240 Pod
/9 Rentang alamat IP Pod terbesar yang memungkinkan	8.388.608 alamat	32.768 node	Autopilot: 1.048.576 Pod Standar: 3.604.480 Pod

Jika telah mengubah jumlah maksimum Pod per node, Anda dapat menggunakan formula berikut untuk menghitung jumlah maksimum node dan Pod yang dapat rentang alamat IP sekunder subnet untuk Pod. dukungan:

Hitung ukuran netmask dari setiap rentang Pod node, M.
M = 31 - ⌈log₂(Q)⌉ di mana:
- Q adalah jumlah Pod per node
- ⌈⌉ adalah fungsi ceiling (bilangan bulat terkecil), yang berarti membulatkan ke bilangan bulat berikutnya
- Misalnya, jika Q adalah 110, maka M = 24
Hitung jumlah maksimum node, N, yang dapat didukung oleh rentang alamat IP sekunder subnet untuk Pod:
N = 2^{(M - S)} dengan:
- M adalah ukuran netmask dari rentang alamat IP alias setiap node untuk Pod, yang dihitung pada langkah pertama
- S adalah ukuran subnet mask dari rentang alamat IP sekunder subnet
- Misalnya, jika M adalah 24, dan S adalah 20, maka N = 16
Hitung jumlah maksimum Pod, P, yang dapat didukung rentang alamat IP sekunder subnet untuk Pod:
P = N × Q dengan:
- N adalah jumlah node maksimum yang dihitung pada langkah sebelumnya
- Q adalah jumlah Pod per node
- Misalnya, jika N adalah 16, dan Q adalah 110, maka P = 1760

Anda dapat menambahkan alamat IP lainnya untuk Pod menggunakan CIDR multi-Pod yang terpisah-pisah.

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.

Pada cluster Autopilot baru yang menjalankan GKE versi 1.27 dan yang lebih baru, GKE menetapkan alamat IP untuk Layanan dari rentang yang dikelola Google 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 tanda --services-ipv4-cidr atau tanda --services-secondary-range-name.
Jika Anda hanya menentukan ukuran rentang menggunakan flag --services-ipv4-cidr (misalnya, /22), GKE tetap menggunakan rentang yang dikelola Google untuk mendapatkan sub-rentang alamat.
GKE tidak membuat rentang alamat IP sekunder yang terpisah untuk Layanan saat rentang yang dikelola Google digunakan. Rentang yang dikelola Google 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 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 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 regex berikut:
```
^gke-.*-services-[abcdef0-9]{8}
```
Guna membagikan rentang 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 Layanan 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 utama 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.

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 Jenis jaringan VPC Google Cloud.
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 Dual-stack didukung untuk Layanan ClusterIP, NodePort, dan LoadBalancer.

Pertimbangkan batasan sebelumnya sebelum membuat cluster dengan jaringan dual stack. 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

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`).

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 dual stack untuk cluster native VPC.

Arsitektur

Cluster dengan jaringan dual-stack 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 dua tumpukan, 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:

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.

Service

Anda dapat membuat Layanan IPv6 jenis ClusterIP, NodePort, atau 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 informasi selengkapnya, lihat contoh cara menyiapkan Deployment.