Merencanakan alamat IP saat bermigrasi ke GKE

Dokumen ini menjelaskan cara mengelola penggunaan alamat IP di Google Kubernetes Engine (GKE) dan cara menggunakan model jaringan alternatif di GKE jika diperlukan. Dokumen ini mencakup konsep berikut:

  • Cara mengurangi penggunaan alamat IP Pod di GKE sehingga GKE sesuai dengan kebutuhan alamat IP sebagian besar organisasi.
  • Cara penerapan model jaringan alternatif di GKE jika arsitektur cluster tidak memenuhi persyaratan organisasi Anda.

Dokumen ini ditujukan untuk arsitek cloud, engineer operasi, dan engineer jaringan yang berencana memigrasikan cluster Kubernetes dari lingkungan lain ke GKE. Gunakan panduan dalam dokumen ini jika organisasi Anda mengalami kesulitan dalam menetapkan alamat IP internal yang cukup untuk penggunaan GKE yang diharapkan.

Dokumen ini berasumsi bahwa Anda sudah memahami Kubernetes dan model jaringannya. Anda juga harus memahami konsep jaringan seperti alamat IP, penafsiran alamat jaringan (NAT), firewall, dan proxy.

Dokumen ini tidak membahas strategi pengelolaan untuk rentang alamat yang digunakan untuk alamat IP Service. Jumlah alamat yang diperlukan untuk Service jauh lebih kecil daripada Pod, dan opsi untuk mengurangi jumlah ini terbatas. Di GKE, rentang alamat IP Service sudah tetap selama masa aktif cluster. Dengan demikian, rentang alamat IP Service perlu diukur dengan jumlah Service terbesar yang diharapkan. Karena alamat IP Service tidak dapat dijangkau di luar cluster, Anda dapat menggunakan kembali alamat tersebut di jaringan lain.

Dokumen ini juga mengacu pada model jaringan Kubernetes yang berbeda: terintegrasi sepenuhnya, mode pulau, dan terisolasi. Model ini berbeda-beda dalam hal cara alamat IP Pod dijangkau di seluruh jaringan. Perbedaan ini berdampak pada strategi pengelolaan alamat IP yang dapat digunakan. Untuk informasi lebih mendetail tentang model ini dan model jaringan GKE, lihat Perbandingan model jaringan yang digunakan oleh GKE dan implementasi Kubernetes lainnya.

Mengurangi penggunaan alamat IP internal di GKE

GKE menggunakan model jaringan yang terintegrasi sepenuhnya tempat cluster di-deploy dalam jaringan VPC yang juga dapat berisi aplikasi lain. Model GKE memiliki banyak manfaat. Namun, jenis model ini tidak mengizinkan penggunaan ulang alamat IP Pod. Kurangnya penggunaan ulang ini mengharuskan Anda menggunakan alamat IP Pod yang unik di seluruh jaringan VPC. Oleh karena itu, Anda harus mempertimbangkan dengan cermat jumlah alamat IP unik yang diperlukan.

Jumlah alamat unik yang Anda perlukan memengaruhi apakah Anda perlu mengurangi penggunaan alamat IP atau tidak, sebagai berikut:

  • Jika memiliki ruang alamat yang cukup untuk kebutuhan alamat IP, Anda tidak perlu melakukan langkah-langkah untuk mengurangi penggunaan alamat IP. Namun, mengetahui cara mengurangi penggunaan alamat IP akan sangat membantu dalam mengidentifikasi jumlah minimum alamat IP yang akan digunakan.
  • Jika tidak memiliki ruang alamat yang cukup, Anda perlu mengurangi penggunaan alamat IP untuk membuat cluster GKE yang sesuai dengan batasan ruang alamat Anda.

Untuk membantu Anda mengurangi penggunaan alamat IP di GKE, pertimbangkan opsi berikut:

  • Mengubah setelan Pod per node. Secara default, cluster Standard GKE mereservasi rentang subnet /24 untuk setiap node dan mengizinkan hingga 110 Pod per node. Jika hanya ingin menggunakan 64 Pod atau kurang per node, Anda dapat menyesuaikan jumlah maksimum Pod per node sehingga mengurangi penggunaan alamat IP Pod hingga setengah atau lebih. Cluster Autopilot mengizinkan 32 Pod per node dan setelan ini tidak dapat diubah.
  • Menggunakan beberapa rentang alamat IP Pod. Dengan menggunakan Classless Inter-Domain Routing (CIDR) multi-Pod yang berjauhan, Anda dapat menambahkan rentang alamat IP Pod sekunder ke cluster yang ada. Anda dapat memilih rentang alamat IP Pod yang digunakan oleh setiap node pool. Dengan memilih rentang alamat IP yang digunakan oleh setiap pool, Anda dapat bersikap konservatif saat mengalokasikan ruang alamat IP Pod awal sekaligus tetap dapat mengembangkan cluster.

  • Menggunakan alamat IP non-RFC 1918. Jaringan perusahaan Anda mungkin tidak memiliki cukup alamat IP RFC 1918 yang belum dialokasikan untuk digunakan bagi alamat IP Pod Anda. Jika tidak memiliki cukup alamat IP RFC 1918 yang belum dialokasikan, Anda dapat menggunakan alamat non-RFC 1918, seperti alamat di ruang alamat (100.64.0.0/10) RFC 6598.

    Jika sudah menggunakan ruang RFC 6598 di tempat lain dalam jaringan perusahaan, Anda dapat menggunakan ruang alamat (240.0.0.0/4) Class E/RFC 5735 untuk Alamat IP pod. Namun, traffic dari alamat IP ini diblokir di host Windows dan di beberapa hardware lokal. Untuk menghindari pemblokiran alamat RFC 5735, pertimbangkan untuk menyamarkan traffic ke tujuan eksternal ini seperti yang dijelaskan di bagian Menyembunyikan alamat IP Pod hanya dari jaringan lokal. Namun, Anda akan kehilangan beberapa data telemetri yang diarahkan ke aplikasi lokal saat menyamarkan traffic ke tujuan eksternal.

Jika organisasi memiliki ruang alamat IP publik yang besar, Anda juga dapat menggunakan alamat publik yang digunakan secara pribadi (PUPI). Saat menggunakan alamat PUPI, Anda harus menyertakan alamat PUPI dalam daftar nonMasqueradeCIDRs agar memiliki konektivitas di luar cluster tanpa menggunakan NAT.

Memilih model jaringan di GKE

Dokumen tentang model jaringan GKE membahas cara kerja cluster Standard di GKE, termasuk alamat IP Pod yang terlibat. Dalam dokumen ini, bagian Mengurangi penggunaan alamat IP internal di GKE menjelaskan cara mengurangi jumlah alamat IP internal yang diperlukan dalam cluster tersebut. Mengetahui cara kerja model jaringan GKE dan cara mengurangi alamat IP internal adalah fondasi untuk setiap model jaringan yang Anda gunakan di GKE.

Namun, hanya mengetahui dan menerapkan konsep tersebut mungkin tidak memberi Anda implementasi jaringan yang memenuhi kebutuhan Anda. Pohon keputusan berikut dapat membantu Anda memutuskan cara mengimplementasikan model jaringan GKE yang paling cocok untuk Anda:

Pohon keputusan untuk strategi migrasi alamat IP di GKE.

Pohon keputusan selalu dimulai dengan pembuatan cluster GKE Standard yang didasarkan pada model jaringan yang terintegrasi sepenuhnya. Langkah berikutnya dari pohon ini adalah mengurangi penggunaan alamat IP dengan menerapkan semua opsi yang dijelaskan dalam dokumen ini.

Jika Anda telah mengurangi penggunaan alamat IP sebanyak mungkin dan masih tidak memiliki ruang alamat yang cukup untuk cluster GKE, Anda memerlukan model jaringan alternatif. Pohon keputusan membantu Anda memutuskan model jaringan alternatif berikut yang akan digunakan:

Ingat bahwa pohon keputusan ini hanya boleh digunakan sebagai panduan. Berdasarkan kasus penggunaan spesifik Anda, mungkin Anda masih lebih memilih model lain berdasarkan kelebihan dan kekurangan setiap model. Sering kali, beberapa model dapat diterapkan dan Anda dapat memilih pendekatan yang lebih sesuai untuk organisasi Anda.

Ada kasus yang jarang terjadi saat model alternatif yang ditampilkan dalam pohon keputusan tidak memenuhi kebutuhan Anda. Untuk kasus yang jarang terjadi ini, Anda mungkin dapat menggunakan model yang dijelaskan dalam Menggunakan instance multi-NIC untuk menyembunyikan alamat cluster.

Mengemulasi model jaringan alternatif

Untuk memanfaatkan model jaringan yang terintegrasi sepenuhnya, sebaiknya tempatkan cluster GKE Anda di jaringan logis yang sama dengan resource cloud lainnya. Namun, Anda mungkin tidak dapat mengikuti rekomendasi ini. Anda mungkin tidak memiliki ruang alamat IP yang cukup, atau Anda mungkin diwajibkan untuk menyembunyikan alamat IP Pod dari jaringan organisasi yang lebih besar.

Bagian ini memberikan opsi untuk menggunakan model jaringan yang terintegrasi sepenuhnya dengan mendeskripsikan berbagai pola arsitektur yang meniru berbagai model jaringan alternatif di GKE. Pola arsitektur alternatif ini membuat mode operasi untuk GKE yang mirip dengan model jaringan mode pulau atau model jaringan mode terisolasi.

Setiap pola arsitektur alternatif menyertakan informasi berikut:

Menyembunyikan alamat IP Pod hanya dari jaringan lokal

Pola arsitektur tempat Anda menyembunyikan alamat IP dari jaringan lokal menggunakan kombinasi tujuan perutean berikut:

  • Minta cluster GKE di Google Cloud untuk menetapkan alamat IP Pod yang dirutekan selama deployment Google Cloud.
  • Cegah alamat IP ini dirutekan tanpa NAT ke resource lokal atau ke lingkungan cloud lainnya melalui Cloud VPN atau Cloud Interconnect.

Pola arsitektur ini biasanya digunakan dengan ruang alamat IP Class E/RFC 5735 karena ruang ini mencakup banyak alamat IP. Memiliki begitu banyak alamat IP yang tersedia akan membantu mengakomodasi kebutuhan untuk memberikan alamat IP yang unik ke setiap Pod. Namun, alamat IP Class E/RFC 5735 tidak dapat dengan mudah dirutekan ke resource lokal karena banyak vendor hardware jaringan yang memblokir traffic ini.

Daripada menggunakan ruang alamat IP Class E/RFC 5735, Anda dapat menggunakan alamat IP RFC 1918 atau kumpulan internal alamat IP non-RFC 1918. Jika Anda menggunakan salah satu dari kumpulan alamat IP lainnya, tentukan apakah ada tumpang tindih alamat IP antara alamat yang digunakan untuk Pod dan alamat yang digunakan di jaringan lokal. Jika ada tumpang tindih, pastikan tidak pernah ada komunikasi antara cluster yang menggunakan alamat tersebut dan aplikasi lokal yang menggunakan alamat yang sama tersebut.

Langkah-langkah berikut menguraikan cara menyiapkan pola arsitektur ini:

  1. Buat rentang alamat IP sekunder untuk subnet Pod. Seperti yang dijelaskan sebelumnya di bagian ini, Anda dapat membuat rentang alamat ini dari ruang Class E/RFC 5735, ruang RFC 1918, atau kumpulan internal alamat IP non-RFC 1918. Biasanya, ruang Class E/RFC 5735 digunakan.
  2. Gunakan pemberitahuan rute kustom dan hapus rentang IP Pod dari pemberitahuan di Cloud Router Anda. Menghapus alamat ini dapat membantu memastikan bahwa rentang IP Pod tidak diumumkan melalui Border Gateway Protocol (BGP) ke router lokal.
  3. Buat cluster GKE menggunakan rentang alamat IP sekunder sebagai Classless Inter-Domain Routing (CIDR) untuk Pod. Anda dapat menggunakan strategi yang dijelaskan dalam Mengurangi penggunaan alamat IP internal di GKE untuk mengurangi penggunaan alamat IP.

  4. Tambahkan alamat IP berikut ke daftar nonMasqueradeCIDRs di agen penyamaran:

    • Rentang alamat IP yang Anda gunakan untuk Pod.
    • Rentang alamat IP yang digunakan untuk node.
    • Alamat IP lain yang hanya digunakan di Google Cloud, seperti rentang alamat IP utama yang digunakan di Google Cloud.

    Jangan sertakan rentang alamat IP internal yang digunakan di lingkungan lokal atau di lingkungan cloud lainnya. Jika Anda memiliki workload Windows di Google Cloud, simpan workload tersebut di subnet terpisah dan jangan sertakan rentang tersebut.

Saat menggunakan langkah-langkah sebelumnya untuk menyiapkan pola ini, Anda perlu mengonfigurasi cluster agar memiliki perilaku berikut:

  • Bertindak seperti model jaringan yang terintegrasi sepenuhnya dalam Google Cloud.
  • Bertindak seperti model jaringan mode pulau saat berinteraksi dengan jaringan lokal.

Agar pola alternatif ini mengemulasikan sepenuhnya model jaringan mode pulau, Anda harus mengubah daftar nonMasqueradeCIDRs di agen penyamaran menjadi daftar yang hanya berisi node cluster dan rentang alamat IP Pod. Pembuatan daftar seperti itu akan selalu menyamarkan traffic di luar cluster ke alamat IP node, bahkan di dalam Google Cloud. Namun, setelah melakukan perubahan ini, Anda tidak dapat mengumpulkan data telemetri tingkat Pod dalam jaringan VPC.

Diagram berikut menunjukkan implementasi pola arsitektur ini:

Diagram jaringan yang menunjukkan penerapan menyembunyikan alamat IP hanya dari jaringan lokal.

Diagram sebelumnya menunjukkan cara menyembunyikan alamat IP Pod dari jaringan eksternal. Seperti yang ditunjukkan pada diagram ini, Pod dalam Google Cloud dapat berkomunikasi langsung satu sama lain, bahkan antar-cluster. Komunikasi Pod ini mirip dengan model GKE. Perhatikan bahwa diagram juga menunjukkan Pod yang menggunakan alamat di ruang Class E/RFC 5735.

Untuk traffic yang dikirim di luar cluster, diagram menunjukkan cara NAT sumber (SNAT) diterapkan ke traffic tersebut saat keluar dari node. SNAT digunakan terlepas dari apakah traffic tersebut dirutekan melalui Cloud VPN ke aplikasi lokal atau melalui Cloud NAT ke aplikasi eksternal.

Pola arsitektur ini menggunakan alamat IP Pod untuk komunikasi dalam Google Cloud. Traffic disamarkan hanya saat diarahkan ke aplikasi lokal atau lingkungan cloud lainnya. Meskipun tidak dapat terhubung ke Pod langsung dari aplikasi lokal, Anda dapat terhubung ke layanan yang diekspos melalui load balancing internal.

Menyembunyikan alamat IP Pod dari jaringan lokal memiliki kelebihan berikut:

  • Anda masih dapat memanfaatkan model jaringan yang terintegrasi sepenuhnya dalam Google Cloud, seperti menggunakan firewall dan mengumpulkan data telemetri berdasarkan alamat IP Pod. Selain itu, Anda juga dapat terhubung langsung ke Pod untuk tujuan proses debug dari dalam Google Cloud.
  • Anda masih dapat menggunakan mesh layanan multi-cluster dengan alamat IP Pod dalam Google Cloud.

Namun, menyembunyikan alamat IP Pod dari jaringan eksternal memiliki kekurangan berikut:

  • Anda tidak dapat menggunakan kembali rentang alamat IP Pod atau Service untuk cluster yang berbeda dalam Google Cloud.
  • Anda mungkin harus mengelola dua kumpulan aturan firewall yang berbeda: satu untuk traffic antara jaringan lokal, dan satu lagi untuk traffic yang sepenuhnya di dalam Google Cloud.
  • Anda tidak dapat memiliki komunikasi Pod ke Pod langsung dalam mesh layanan multi-cluster yang mencakup Google Cloud dan lingkungan lokal Anda atau lingkungan penyedia layanan cloud lainnya. Misalnya, saat menggunakan Istio, semua komunikasi harus dilakukan di antara Istio Gateway.

Menyembunyikan alamat IP Pod menggunakan Private Service Connect

Pola arsitektur ini menggunakan Private Service Connect untuk menyembunyikan alamat IP Pod. Gunakan pola arsitektur ini jika Anda memiliki kebutuhan berikut:

  • Anda hanya perlu mengekspos Service dalam jumlah terbatas dari cluster GKE Anda.
  • Cluster GKE Anda dapat bekerja secara independen dan tidak memerlukan komunikasi traffic keluar ke banyak aplikasi di jaringan perusahaan Anda.

Private Service Connect menyediakan cara untuk memublikasikan layanan Anda yang akan digunakan dari jaringan lain. Anda dapat mengekspos Service GKE menggunakan Load Balancer Jaringan passthrough internal dan lampiran layanan, serta menggunakan layanan ini dengan menggunakan endpoint dari jaringan VPC lain.

Langkah-langkah berikut menguraikan cara menyiapkan pola arsitektur ini:

  1. Di jaringan VPC terpisah, buat cluster GKE. Jaringan VPC hanya boleh berisi cluster tersebut.
  2. Untuk setiap Service GKE di cluster Anda yang perlu diakses dari cluster atau aplikasi lain di jaringan VPC lain, buat Load Balancer Jaringan passthrough internal dengan Private Service Connect.

  3. (Opsional) Jika cluster GKE Anda memerlukan komunikasi traffic keluar ke beberapa aplikasi di jaringan perusahaan, ekspos aplikasi tersebut dengan memublikasikan layanan melalui Private Service Connect.

    Diagram berikut menunjukkan implementasi pola arsitektur ini:

Diagram jaringan yang menunjukkan penerapan penyembunyian alamat IP menggunakan Private Service Connect.

Diagram sebelumnya menunjukkan kemiripan komunikasi di dalam dan di seluruh cluster di model Private Service Connect dengan model jaringan terisolasi. Namun, komunikasi yang diizinkan terjadi melalui endpoint Private Service Connect, bukan melalui alamat IP publik. Seperti yang ditunjukkan dalam diagram ini, setiap cluster mendapatkan jaringan VPC-nya masing-masing. Selain itu, setiap jaringan VPC dapat menggunakan alamat IP yang sama, dan setiap cluster dapat berbagi ruang alamat IP yang sama. Hanya Pod dalam cluster yang dapat berkomunikasi langsung satu sama lain.

Untuk komunikasi dari luar cluster, diagram menunjukkan cara aplikasi eksternal menjangkau cluster melalui endpoint Private Service Connect. Endpoint tersebut terhubung ke lampiran layanan yang disediakan oleh produsen layanan di jaringan VPC cluster. Komunikasi antara cluster juga melalui endpoint Private Service Connect dan lampiran layanan produsen layanan.

Menggunakan Private Service Connect untuk menyembunyikan alamat IP Pod memiliki kelebihan berikut:

  • Anda tidak perlu merencanakan alamat IP karena ruang alamat IP di cluster GKE tersembunyi dari bagian jaringan lainnya. Pendekatan ini hanya mengekspos satu alamat IP per layanan ke jaringan VPC yang menggunakannya.
  • Pengamanan cluster Anda lebih mudah karena model ini menentukan dengan jelas layanan yang diekspos, dan hanya layanan yang terekspos tersebut yang dapat dijangkau dari jaringan VPC lainnya.

Namun, menggunakan Private Service Connect untuk menyembunyikan alamat IP Pod memiliki kekurangan berikut:

  • Pod di dalam cluster tidak dapat membuat komunikasi pribadi di luar cluster. Pod hanya dapat berkomunikasi dengan layanan publik (saat Pod memiliki konektivitas internet) atau Google API (menggunakan Akses Google Pribadi). Jika layanan di luar cluster diekspos melalui Private Service Connect, Pod juga dapat menjangkau layanan tersebut. Namun, tidak semua penyedia layanan internal membuat lampiran layanan. Jadi, penggunaan Private Service Connect hanya berfungsi jika jumlah layanan ini dibatasi bagi penyedia yang menyediakan lampiran.
  • Endpoint hanya dapat dijangkau dari region yang sama dengan tempat layanan berada. Selain itu, endpoint ini hanya dapat dijangkau dari jaringan VPC yang terhubung itu sendiri, bukan dari jaringan VPC yang di-peering atau jaringan yang terhubung melalui Cloud VPN atau Cloud Interconnect.

Menyembunyikan alamat IP Pod menggunakan Cloud VPN

Pola arsitektur ini menggunakan Cloud VPN untuk memisahkan cluster GKE dan jaringan VPC utama. Saat Anda membuat pemisahan ini, jaringan yang dihasilkan akan berfungsi mirip dengan model jaringan mode pulau. Seperti model mode pulau, pola ini menawarkan keuntungan menggunakan kembali rentang alamat IP Pod dan Service antar-cluster. Penggunaan kembali dapat dilakukan karena komunikasi dengan aplikasi di luar cluster menggunakan SNAT. Node menggunakan SNAT untuk memetakan alamat IP Pod ke alamat IP node-nya sendiri sebelum traffic keluar dari node.

Langkah-langkah berikut menguraikan cara menyiapkan model ini:

  1. Di jaringan VPC terpisah, buat cluster GKE. Jaringan VPC hanya boleh berisi cluster tersebut.

    Untuk cluster, gunakan bagian yang tidak digunakan dari penetapan alamat IP publik Anda guna menentukan dua rentang alamat IP: satu untuk Pod dan satu lagi untuk Service. Sesuaikan ukuran rentang alamat IP ini berdasarkan kebutuhan cluster GKE terbesar yang ingin Anda gunakan. Reservasi setiap rentang ini untuk penggunaan eksklusif dalam GKE. Anda juga dapat menggunakan kembali rentang ini untuk semua cluster GKE di organisasi Anda.

    Terkadang, pemesanan alamat IP seperti ini tidak dapat dilakukan. Organisasi Anda mungkin sudah menggunakan salah satu atau kedua rentang alamat IP Pod dan Service untuk aplikasi lain. Jika rentang alamat IP sedang digunakan dan tidak dapat direservasi, pastikan aplikasi yang menggunakan alamat IP tersebut tidak perlu berkomunikasi dengan cluster GKE.

  2. Untuk cluster yang baru saja Anda buat, konfigurasikan daftar nonMasqueradeCIDRs dalam agen penyamaran ke daftar yang berisi node cluster dan rentang alamat IP Pod. Daftar ini menyebabkan GKE selalu menyamarkan traffic yang meninggalkan cluster ke alamat IP node, bahkan di dalam Google Cloud.

  3. Gunakan Cloud VPN untuk menghubungkan jaringan VPC yang berisi cluster GKE ke jaringan VPC (utama) yang sudah ada.

  4. Gunakan pemberitahuan rute kustom untuk menghentikan jaringan VPC cluster agar tidak memberitahukan rentang alamat IP Pod dan Service yang diarahkan ke jaringan VPC utama.

  5. Ulangi langkah 1-4 untuk cluster GKE lain yang Anda butuhkan. Untuk semua cluster, gunakan rentang alamat IP yang sama untuk Pod dan Service. Namun, gunakan alamat IP yang berbeda untuk setiap node.

  6. Jika Anda memiliki konektivitas ke jaringan lokal melalui Cloud VPN atau Cloud Interconnect, gunakan pemberitahuan rute kustom untuk memberitahukan rentang IP node secara manual.

  7. Jika Anda memiliki jaringan lain yang terhubung ke jaringan VPC utama melalui Peering Jaringan VPC, ekspor rute kustom pada peering ini untuk memastikan node cluster GKE dapat menjangkau jaringan yang di-peer.

Diagram berikut menunjukkan implementasi penggunaan Cloud VPN untuk menyembunyikan alamat IP Pod:

Diagram jaringan yang menunjukkan implementasi menyembunyikan alamat IP menggunakan Cloud VPN.

Diagram sebelumnya menunjukkan cara menyembunyikan alamat IP Pod menggunakan Cloud VPN, yang membuat pendekatan yang mirip dengan model jaringan mode pulau. Seperti yang ditunjukkan pada diagram, setiap cluster GKE mendapatkan jaringan VPC-nya sendiri. Setiap jaringan memiliki ruang alamat IP node yang berbeda, tetapi menggunakan ruang alamat IP Pod yang sama. Tunnel Cloud VPN menghubungkan jaringan VPC ini satu sama lain dan ke jaringan perusahaan, dan ruang alamat IP Pod tidak diberitahukan dari jaringan VPC yang berisi cluster.

Perhatikan dalam diagram ini bahwa hanya Pod dalam cluster yang dapat berkomunikasi langsung satu sama lain. Node ini menggunakan SNAT untuk menyamarkan ruang alamat IP Pod saat berkomunikasi di luar cluster ke cluster lain, ke jaringan perusahaan, atau ke jaringan lokal yang terhubung. Pod tidak dapat dijangkau langsung dari cluster lain atau jaringan perusahaan. Hanya Service cluster yang diekspos dengan load balancer internal yang dapat dijangkau melalui koneksi Cloud VPN.

Penggunaan Cloud VPN untuk menyembunyikan alamat IP Pod memiliki kelebihan berikut:

  • Seperti dijelaskan dalam model jaringan mode pulau, Anda dapat menggunakan kembali rentang alamat IP Pod dan Service antar-cluster.
  • Firewall mungkin memerlukan lebih sedikit konfigurasi karena alamat IP Pod tidak dapat dijangkau langsung dari jaringan VPC utama dan jaringan yang terhubung. Oleh karena itu, Anda tidak perlu mengonfigurasi aturan firewall eksplisit untuk memblokir komunikasi dengan Pod.

Namun, menggunakan Cloud VPN untuk menyembunyikan alamat IP Pod memiliki kekurangan berikut:

  • Kekurangan yang sama seperti yang disebutkan dalam model jaringan mode pulau berlaku. Misalnya, Anda tidak dapat menetapkan aturan firewall di tingkat Pod. Anda juga tidak dapat mengumpulkan data telemetri di tingkat Pod di jaringan VPC utama atau jaringan yang terhubung.
  • Dibandingkan dengan model jaringan GKE default, pola ini menimbulkan biaya tambahan yang berasal dari biaya yang terkait dengan tunnel Cloud VPN dan biaya transfer data.
  • Cloud VPN memiliki batas bandwidth per tunnel VPN. Jika batas bandwidth ini tercapai, Anda dapat mengonfigurasi beberapa tunnel Cloud VPN dan mendistribusikan traffic menggunakan equal-cost multipath (ECMP). Namun, melakukan tindakan ini menambah kompleksitas dalam menyiapkan dan mempertahankan implementasi GKE Anda.
  • Menjaga agar pemberitahuan rute tetap sinkron akan menambah kompleksitas pada pembuatan cluster. Setiap kali membuat cluster GKE baru, Anda harus menyiapkan tunnel Cloud VPN, dan membuat pemberitahuan rute kustom di tunnel tersebut dan ke aplikasi lokal.

Menyembunyikan alamat IP Pod menggunakan alamat IP publik yang digunakan secara internal dan Peering Jaringan VPC

Jika organisasi memiliki alamat IP publik yang tidak terpakai, Anda dapat menggunakan pola arsitektur ini yang menyerupai model jaringan mode pulau, tetapi melalui penggunaan ruang alamat IP Publik ini secara pribadi. Arsitektur ini mirip dengan model yang menggunakan Cloud VPN, tetapi menggunakan Peering Jaringan VPC untuk membuat pemisahan antara cluster GKE dan jaringan utama.

Langkah-langkah berikut menguraikan cara menyiapkan pola arsitektur ini:

  1. Di jaringan VPC terpisah, buat cluster GKE. Jaringan VPC hanya boleh berisi cluster tersebut.

    Untuk cluster, gunakan bagian yang tidak digunakan dari penetapan alamat IP publik Anda guna menentukan dua rentang alamat IP: satu untuk Pod dan satu lagi untuk Service. Sesuaikan ukuran rentang alamat IP ini berdasarkan kebutuhan cluster GKE terbesar yang ingin Anda gunakan. Reservasi setiap rentang ini untuk penggunaan eksklusif dalam GKE. Anda juga dapat menggunakan kembali rentang ini untuk semua cluster GKE di organisasi Anda.

    Daripada menggunakan penetapan alamat IP publik, secara teoretis Anda dapat menggunakan blok alamat IP publik yang lebih besar dan tidak digunakan, yang dimiliki oleh pihak ketiga. Namun, kami sangat tidak menyarankan konfigurasi seperti itu karena alamat IP tersebut dapat dijual atau digunakan secara publik kapan saja. Penjualan atau penggunaan alamat telah menyebabkan masalah keamanan dan konektivitas saat menggunakan layanan publik di internet.

  2. Untuk cluster yang baru saja Anda buat, konfigurasikan daftar nonMasqueradeCIDRs dalam agen penyamaran ke daftar yang berisi node cluster dan rentang alamat IP Pod. Daftar ini menyebabkan GKE selalu menyamarkan traffic yang meninggalkan cluster ke alamat IP node, bahkan di dalam Google Cloud.

  3. Gunakan Peering Jaringan VPC untuk menghubungkan jaringan VPC yang berisi cluster GKE ke jaringan VPC (utama) yang ada. Karena Anda tidak ingin alamat PUPI dipertukarkan dalam model ini, tetapkan flag --no-export-subnet-routes-with-public-ip saat mengonfigurasi peering.

  4. Ulangi langkah 1-3 untuk cluster GKE lain yang Anda butuhkan. Untuk semua cluster, gunakan rentang alamat IP yang sama untuk Pod dan Service. Namun, gunakan alamat IP berbeda untuk setiap node.

  5. Jika Anda memiliki konektivitas ke jaringan lokal melalui Cloud VPN atau Cloud Interconnect, gunakan pemberitahuan rute kustom untuk memberitahukan rentang alamat IP node secara manual.

Diagram berikut menunjukkan implementasi pola arsitektur ini:

Diagram jaringan yang menunjukkan implementasi menyembunyikan alamat IP menggunakan PUPI dan Peering Jaringan VPC.

Diagram sebelumnya menunjukkan cara menyembunyikan alamat IP menggunakan Peering Jaringan VPC. Seperti yang ditunjukkan dalam diagram, setiap cluster GKE mendapatkan jaringan VPC-nya sendiri. Setiap node memiliki ruang alamat IP node yang berbeda, tetapi menggunakan ruang alamat IP Pod yang sama dengan yang ditentukan dari ruang alamat PUPI organisasi Anda. Jaringan VPC terhubung satu sama lain dan ke aplikasi non-Kubernetes di Google Cloud melalui Peering Jaringan VPC. Ruang alamat PUPI tidak diberitahukan di antara peering. Jaringan VPC terhubung ke jaringan perusahaan melalui tunnel Cloud VPN.

Hanya Pod dalam cluster yang dapat berkomunikasi langsung satu sama lain. Node menggunakan SNAT untuk menyamarkan ruang IP Pod saat berkomunikasi di luar cluster ke cluster lain, ke jaringan perusahaan, atau ke jaringan lokal yang terhubung. Pod tidak dapat dijangkau langsung dari cluster lain atau jaringan perusahaan. Hanya Service yang diekspos dengan load balancer internal yang dapat dijangkau melalui koneksi Peering Jaringan VPC.

Pola arsitektur ini mirip dengan pendekatan Cloud VPN yang dijelaskan sebelumnya, tetapi memiliki kelebihan berikut dibandingkan pola tersebut:

  • Tidak seperti pola arsitektur Cloud VPN, Peering Jaringan VPC tidak dikenai biaya tambahan untuk tunnel atau bandwidth Cloud VPN antar-lingkungan.
  • Peering Jaringan VPC tidak memiliki batasan bandwidth dan terintegrasi sepenuhnya ke dalam software-defined networking Google. Dengan demikian, Peering Jaringan VPC mungkin memberikan latensi yang sedikit lebih rendah daripada Cloud VPN karena peering tidak memerlukan gateway dan pemrosesan yang diperlukan oleh Cloud VPN.

Namun, model Peering Jaringan VPC juga memiliki kekurangan berikut dibandingkan model Cloud VPN:

  • Organisasi Anda memerlukan ruang alamat IP publik yang tidak digunakan dan cukup besar untuk ruang alamat IP Pod yang dibutuhkan oleh cluster GKE terbesar yang Anda harapkan.
  • Peering Jaringan VPC bersifat non-transitif. Dengan demikian, cluster GKE yang terhubung melalui Peering Jaringan VPC ke jaringan VPC utama tidak dapat langsung berkomunikasi satu sama lain atau dengan aplikasi di jaringan VPC yang di-peer dengan VPC utama. Anda harus langsung menghubungkan jaringan tersebut melalui Peering Jaringan VPC untuk mengaktifkan komunikasi tersebut, atau menggunakan VM proxy di jaringan VPC utama.

Menggunakan instance multi-NIC untuk menyembunyikan alamat cluster

Pola arsitektur ini terdiri dari komponen dan teknologi berikut untuk membuat model yang mirip dengan model jaringan mode pulau:

  • Menggunakan instance Compute Engine dengan beberapa kartu antarmuka jaringan (multi-NIC) untuk membuat lapisan pemisahan antara cluster GKE dan jaringan VPC utama.
  • Protokol ini menggunakan NAT pada alamat IP yang dikirim di antara lingkungan tersebut.

Anda dapat menggunakan pola ini saat perlu memeriksa, mentransformasi, atau memfilter traffic tertentu yang masuk atau keluar dari cluster GKE. Jika Anda perlu melakukan jenis pemeriksaan, transformasi, atau pemfilteran ini, gunakan instance Compute Engine yang di-deploy untuk melakukan tugas ini.

Menggunakan instance multi-NIC untuk menyembunyikan alamat cluster memiliki kelebihan berikut:

  • Ruang alamat IP di cluster GKE tersembunyi dari jaringan lainnya. Hanya satu alamat IP per layanan yang terekspos ke jaringan VPC yang menggunakannya.
  • Service dapat dijangkau secara global, dari jaringan lokal yang terhubung, dan dari jaringan yang di-peer.

Namun, menggunakan instance multi-NIC untuk menyembunyikan alamat cluster memiliki kekurangan berikut:

  • Model ini lebih kompleks untuk diterapkan dibandingkan pendekatan lain karena tidak hanya memerlukan implementasi model, tetapi juga penyiapan pemantauan dan logging untuk instance multi-NIC.
  • Instance multi-NIC memiliki batasan bandwidth dan tunduk pada harga instance VM.
  • Anda perlu mengelola dan mengupgrade instance multi-NIC.

Langkah selanjutnya