Mempelajari dokumentasi dan kasus penggunaan jaringan GKE

Jaringan di Google Kubernetes Engine (GKE) mencakup berbagai konsep, termasuk Pod, layanan, DNS, load balancing, keamanan, dan pengelolaan alamat IP. Meskipun dokumentasi menjelaskan setiap fitur secara mendetail, mungkin sulit untuk mengetahui dari mana harus memulai saat menghadapi masalah dunia nyata.

Dokumen ini membantu Anda menelusuri dokumentasi jaringan GKE dengan menghubungkan tantangan umum dengan fitur dan bagian yang menyelesaikannya. Setiap kasus penggunaan menyajikan skenario, mengidentifikasi tantangan, dan mengarahkan Anda ke dokumentasi yang relevan. Dokumen ini ditujukan untuk arsitek cloud, developer, dan tim operasi yang harus memahami dan menyelesaikan tantangan jaringan umum di GKE.

Jika Anda sudah memahami tantangan jaringan umum dan lebih suka mempelajari detail teknis secara langsung, pelajari referensi berikut untuk membangun pengetahuan dasar Anda tentang jaringan GKE:

Kasus penggunaan: Mendesain fondasi jaringan untuk GKE

Dalam kasus penggunaan ini, Anda adalah arsitek cloud yang perlu mendesain fondasi jaringan yang skalabel, aman, dan andal untuk platform GKE baru.

Tantangan: Mencegah kehabisan alamat IP

Skenario: kompleksitas dan penggunaan aplikasi Anda diperkirakan akan meningkat, sehingga Anda perlu merancang jaringan yang dapat diskalakan untuk menangani peningkatan traffic dan mendukung pertumbuhan Pod, layanan, dan node. Anda juga perlu merencanakan alokasi alamat IP untuk menghindari kehabisan

Solusi: rencanakan skema pengalamatan IP Anda untuk memperhitungkan jumlah node, Pod, dan Layanan yang Anda perlukan. Rencana ini mencakup pemilihan rentang alamat IP yang sesuai untuk setiap jaringan, dengan mempertimbangkan kepadatan Pod, dan menghindari tumpang-tindih dengan jaringan lain. Untuk mengetahui informasi selengkapnya, lihat Mengelola migrasi alamat IP di GKE.

Tantangan: Menerapkan keamanan berlapis

Skenario: Anda perlu mengamankan perimeter cluster dan menerapkan aturan zero-trust, Pod-ke-Pod.

Solusi: gunakan Kebijakan firewall untuk perimeter cluster. Untuk mengetahui informasi selengkapnya, lihat Mengontrol komunikasi antara Pod dan Service menggunakan kebijakan jaringan.

Tantangan: Merutekan traffic ke berbagai jenis aplikasi

Skenario: Anda perlu memastikan bahwa layanan dan pengguna lain dapat menjangkau berbagai jenis aplikasi, seperti backend pribadi dan aplikasi HTTP(S) publik.

Solusi: gunakan load balancer internal untuk backend pribadi. Untuk aplikasi HTTP(S) publik, gunakan Ingress atau Gateway API. Untuk mengetahui informasi selengkapnya, lihat Tentang load balancing di GKE.

Tantangan: Menggunakan alat observabilitas untuk memantau dan memecahkan masalah beban kerja

Skenario: Anda harus memperbaiki masalah traffic jaringan, dan perlu memahami serta memantau alur traffic GKE untuk mendiagnosis masalah secara efektif.

Solusi: menerapkan alat observabilitas untuk memantau dan memecahkan masalah traffic jaringan. Untuk mengetahui informasi selengkapnya, lihat Mengamati traffic menggunakan kemampuan observasi GKE Dataplane V2.

Kasus penggunaan: Mengekspos microservice baru

Dalam kasus penggunaan ini, Anda adalah developer yang men-deploy microservice baru di GKE. Anda perlu membuat microservice dapat diakses oleh layanan lain dalam cluster, dan selanjutnya, oleh klien eksternal.

Tantangan: Menyediakan endpoint yang stabil untuk komunikasi Pod-ke-Pod

Skenario: aplikasi Anda memerlukan Pod untuk berkomunikasi dengan Pod lain, tetapi alamat IP dinamis yang digunakan oleh Pod membuat komunikasi ini tidak dapat diandalkan.

Solusi: buat layanan Kubernetes. Layanan ClusterIP menyediakan alamat IP virtual dan nama DNS yang stabil, yang di-load balance di seluruh Pod. Untuk mengetahui informasi selengkapnya, lihat Memahami layanan Kubernetes.

Tantangan: Mengekspos layanan untuk akses eksternal

Skenario: microservice harus dapat dijangkau dari internet untuk demo.

Solusi: buat layanan LoadBalancer. GKE menyediakan Load Balancer Jaringan passthrough eksternal regional dengan alamat IP publik. Untuk traffic HTTP(S), pertimbangkan untuk menggunakan Ingress atau Gateway, yang menyediakan fitur Lapisan 7. Untuk mengetahui informasi selengkapnya, lihat Tentang Layanan LoadBalancer.

Tantangan: Menetapkan URL permanen yang mudah digunakan

Skenario: layanan memerlukan nama domain yang stabil untuk klien.

Solusi: cadangkan alamat IP statis dan konfigurasi DNS untuk domain kustom. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi nama domain dengan alamat IP statis.

Tantangan: Mengelola perutean traffic lanjutan

Skenario: seiring berkembangnya aplikasi, Anda memerlukan kontrol yang lebih canggih terhadap cara traffic diarahkan. Misalnya, Anda mungkin perlu melakukan hal berikut:

  • Menghosting beberapa situs (seperti api.example.com dan shop.example.com) di satu load balancer untuk menghemat biaya.
  • Merutekan permintaan ke layanan yang berbeda berdasarkan jalur URL (misalnya, mengirim / ke workload frontend dan /api/v1 ke workload backend).
  • Amankan aplikasi Anda dengan HTTPS dengan mengelola sertifikat TLS.
  • Deploy fitur baru secara bertahap dengan aman menggunakan rilis canary, di mana Anda mengirimkan sebagian kecil traffic ke versi baru sebelum peluncuran penuh.

Solusi: gunakan Gateway API. Implementasi Gateway API di GKE menyediakan cara yang efektif dan standar untuk mengelola traffic north-south semacam ini, yang mendukung fitur lanjutan seperti perutean berbasis jalur, pencocokan header, dan pemisahan traffic. Untuk informasi selengkapnya, lihat Tentang Gateway API.

Kasus penggunaan: Menskalakan penemuan layanan untuk aplikasi yang berkembang

Seiring pertumbuhan traffic dan kompleksitas aplikasi berbasis microservice Anda, kueri DNS antar-layanan akan meningkat secara signifikan. Meskipun developer perlu memahami cara membangun aplikasi yang tangguh di lingkungan ini, tim platform dan operasi sering kali bertanggung jawab untuk menerapkan solusi jaringan yang skalabel.

Tantangan: Mengaktifkan komunikasi layanan ke layanan

Skenario: Pod memerlukan cara yang andal untuk menemukan layanan lain.

Solusi: GKE menyediakan layanan DNS dalam cluster (seperti kube-dns atau Cloud DNS) yang me-resolve nama DNS stabil untuk Layanan, sehingga memungkinkan komunikasi Pod-ke-Pod yang andal. Untuk mengetahui informasi selengkapnya, lihat Penemuan layanan dan DNS.

Tantangan: Meningkatkan performa DNS dalam skala besar

Skenario: volume kueri yang tinggi menyebabkan penundaan pencarian.

Solusi: aktifkan NodeLocal DNSCache. Setiap node menyimpan kueri DNS secara lokal, sehingga mengurangi latensi. Untuk mengetahui informasi selengkapnya, lihat Ringkasan penyiapan NodeLocal DNSCache.

Tantangan: Menyediakan penemuan layanan di seluruh VPC

Skenario: VM Compute Engine perlu mengakses layanan di dalam cluster.

Solusi: lakukan integrasi dengan Cloud DNS agar data DNS layanan dapat di-resolve di seluruh VPC. Untuk mengetahui informasi selengkapnya, lihat Menggunakan Cloud DNS untuk GKE.

Kasus penggunaan: Mengamankan aplikasi multi-tingkat

Dalam kasus penggunaan ini, Anda berada di tim engineering platform yang men-deploy aplikasi tiga tingkat (frontend, penagihan, database), dan Anda harus menerapkan komunikasi zero trust.

Tantangan: Menerapkan aturan traffic yang ketat

Skenario: hanya layanan tertentu yang boleh berkomunikasi satu sama lain.

Solusi: aktifkan penerapan kebijakan jaringan dan terapkan default deny kebijakan, lalu tentukan aturan izin eksplisit (misalnya, frontend mengizinkan traffic ke penagihan, penagihan mengizinkan traffic ke database). Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi kebijakan jaringan untuk aplikasi.

Tantangan: Mengaudit dan memverifikasi kebijakan jaringan

Skenario: keamanan memerlukan bukti penegakan dan visibilitas.

Solusi: Aktifkan logging kebijakan jaringan untuk merekam koneksi yang diizinkan dan ditolak. Untuk mengetahui informasi selengkapnya, lihat Menggunakan logging kebijakan jaringan.

Tantangan: Mengekspos layanan secara pribadi kepada konsumen

Skenario: layanan backend, seperti database atau API, harus dapat diakses oleh konsumen di jaringan VPC lain tanpa mengeksposnya ke internet publik atau menangani kompleksitas peering VPC.

Solusi: gunakan Private Service Connect untuk memublikasikan layanan. Konsumen kemudian dapat membuat endpoint PSC di VPC mereka sendiri untuk mengakses layanan Anda secara pribadi dan aman. Untuk mengetahui informasi selengkapnya, lihat Mengekspos layanan dengan Private Service Connect.

Kasus penggunaan: Mencapai ketersediaan tinggi di beberapa cluster

Dalam kasus penggunaan ini, Anda adalah SRE yang menjalankan workload untuk perusahaan e-commerce di beberapa cluster GKE di berbagai region untuk meningkatkan keandalan.

Tantangan: Mengaktifkan komunikasi lintas cluster

Skenario: layanan di satu cluster harus menemukan dan memanggil layanan di cluster lain.

Solusi: gunakan Layanan multi-cluster (MCS) GKE untuk membuat nama DNS global dan merutekan traffic secara otomatis ke backend yang sehat. Untuk mengetahui informasi selengkapnya, lihat Layanan Multi-cluster.

Tantangan: Memastikan failover yang tangguh

Skenario: jika satu layanan regional tidak tersedia, traffic harus dialihkan secara otomatis.

Solusi: MCS menyediakan penemuan layanan yang memperhatikan kondisi, sehingga klien dapat me-resolve satu nama DNS ke backend yang sehat di cluster terdekat yang tersedia. Pendekatan ini memungkinkan failover yang tangguh. Untuk mengetahui informasi selengkapnya, lihat Layanan Multi-cluster.

Kasus penggunaan: Membangun lingkungan GKE multi-tenant yang aman dan efisien

Sebagai bagian dari tim engineering platform, Anda menyediakan cluster GKE untuk beberapa tim aplikasi. Anda perlu memusatkan kontrol jaringan, menghemat alamat IP, dan menerapkan keamanan yang ketat.

Tantangan: Memusatkan kontrol jaringan

Skenario: beberapa tim aplikasi memerlukan cluster mereka sendiri, tetapi jaringan harus dikelola secara terpusat.

Solusi: gunakan VPC Bersama. Resource jaringan berada di project host, tetapi cluster aplikasi berjalan di project layanan. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi cluster dengan VPC Bersama.

Tantangan: Mengelola alamat IP terbatas secara efisien

Skenario: Ruang alamat IP terbatas dan perlu digunakan secara efisien.

Solusi: sesuaikan jumlah maksimum Pod per node dan, jika diperlukan, gunakan rentang non-RFC 1918 untuk alamat IP Pod. Untuk mengetahui informasi selengkapnya, lihat Mengelola migrasi alamat IP di GKE.

Tantangan: Menggunakan dataplane modern dan aman, serta menyediakan cluster dengan dataplane baru

Skenario:

  • Perusahaan memerlukan performa tinggi dan penerapan kebijakan bawaan untuk mendukung beban kerja yang berat dan postur keamanan zero-trust. Misalnya, Anda mungkin menjalankan microservice skala besar yang sensitif terhadap latensi jaringan, atau Anda mungkin perlu menerapkan batas keamanan yang ketat antara aplikasi dalam cluster multi-tenant untuk memenuhi persyaratan kepatuhan terhadap peraturan.
  • Cluster harus dikonfigurasi untuk menggunakan dataplane jaringan modern demi performa dan keamanan yang tinggi, serta harus di-deploy dalam struktur jaringan yang dikelola secara terpusat oleh organisasi.

Solusi: gunakan GKE Dataplane V2, yang berbasis eBPF dan memberikan performa tinggi serta penerapan kebijakan jaringan bawaan. Untuk mengetahui informasi selengkapnya, lihat GKE Dataplane V2.

Kasus penggunaan: Mengamati dan memecahkan masalah traffic

Sebagai SRE, Anda sedang menyelidiki alasan layanan checkout tidak dapat terhubung ke layanan pembayaran.

Tantangan: Menyelesaikan masalah konektivitas

Skenario: paket dihapus, tetapi penyebabnya tidak jelas.

Solusi: aktifkan kemampuan observasi GKE Dataplane V2. Metrik seperti hubble_drop_total mengonfirmasi bahwa paket ditolak. Untuk mengetahui informasi selengkapnya, lihat Memecahkan masalah dengan Hubble.

Tantangan: Menemukan penyebab utama paket yang tidak terkirim

Skenario: setelah mengonfirmasi bahwa paket jaringan dihentikan (misalnya, dengan menggunakan hubble_drop_total), identifikasi kebijakan jaringan spesifik yang memblokir traffic antar-layanan.

Solusi: gunakan antarmuka command line atau UI Hubble untuk melacak alur. UI Hubble memberikan representasi visual traffic, yang menandai kebijakan yang salah konfigurasi yang menolak koneksi. Visualisasi ini memungkinkan tim dengan cepat menemukan akar penyebab masalah dan memperbaiki kebijakan. Untuk mengetahui informasi selengkapnya, lihat Mengamati traffic menggunakan kemampuan observasi GKE Dataplane V2.

Kasus penggunaan menyeluruh: Men-deploy dan menskalakan aplikasi retail yang aman

Dalam skenario end-to-end ini, tim engineering platform membangun platform GKE standar untuk beberapa tim aplikasi. Tim men-deploy dan mengoptimalkan aplikasi retail tiga tingkat (frontend, penagihan, database). Proses ini mencakup pengamanan, penskalaan, peningkatan performa untuk beban kerja machine learning, dan integrasi peralatan keamanan tingkat lanjut.

Diagram berikut mengilustrasikan arsitektur end-to-end aplikasi retail multi-tingkat yang aman dan di-deploy di GKE. Arsitektur berkembang melalui beberapa fase:

  • Tahap 1: bangun penyiapan dasar menggunakan VPC Bersama dan GKE Dataplane V2.
  • Fase 2: ekspos aplikasi menggunakan Gateway API dan layanan multi-cluster untuk ketersediaan tinggi.
  • Tahap 3: mempercepat tugas ML menggunakan gVNIC dan jaringan Tingkat 1.
  • Tahap 4: men-deploy peralatan keamanan tingkat lanjut menggunakan dukungan multi-jaringan.
Diagram yang menunjukkan arsitektur menyeluruh untuk aplikasi retail multi-tingkat yang aman di GKE, yang mengilustrasikan komponen jaringan di enam fase deployment dan penskalaan.
Gambar 1. Arsitektur menyeluruh untuk aplikasi retail multi-tingkat yang aman di GKE, yang menyoroti komponen jaringan utama yang digunakan di setiap fase deployment dan penskalaan. Detail setiap fase dijelaskan di bagian berikut.

Fase 1: Membangun fondasi platform

Tantangan: Memusatkan jaringan untuk beberapa tim aplikasi dan mengalokasikan alamat IP yang memadai untuk menangani penskalaan.

Solusi:

Tahap 2: Men-deploy dan mengamankan aplikasi

Tantangan: memastikan komunikasi antarlayanan yang andal dan menerapkan keamanan zero trust.

Solusi:

Fase 3: Ekspos aplikasi dan lakukan penskalaan untuk pertumbuhan

Tantangan: menyediakan akses eksternal dan mengurangi latensi pencarian DNS seiring dengan peningkatan traffic.

Solusi:

Fase 4: Mencapai ketersediaan tinggi dan memecahkan masalah

Tantangan: memastikan failover regional dan men-debug traffic yang terputus.

Solusi:

Tahap 5: Mempercepat workload machine learning

Tantangan: menghilangkan hambatan jaringan untuk pelatihan model berbasis GPU.

Solusi:

  • Aktifkan gVNIC untuk bandwidth yang lebih tinggi.
  • Konfigurasi jaringan Tier 1 pada node penting untuk throughput maksimum.

Fase 6: Men-deploy perangkat keamanan canggih

Tantangan: men-deploy firewall dan IDS pihak ketiga dengan traffic bidang data dan pengelolaan terpisah pada latensi sangat rendah.

Solusi:

Langkah berikutnya