Praktik terbaik untuk jaringan GKE

Dokumen ini menguraikan praktik terbaik untuk mengonfigurasi opsi jaringan untuk cluster Google Kubernetes Engine (GKE). Dokumen ini dimaksudkan sebagai panduan perencanaan arsitektur bagi arsitek cloud dan engineer jaringan dengan rekomendasi konfigurasi cluster yang berlaku untuk sebagian besar cluster GKE. Sebelum membuat cluster GKE, sebaiknya Anda meninjau semua bagian dalam dokumen ini untuk memahami opsi jaringan yang didukung GKE dan implikasinya.

Opsi jaringan yang Anda pilih memengaruhi arsitektur cluster GKE Anda. Beberapa opsi ini tidak dapat diubah setelah dikonfigurasi tanpa membuat ulang cluster.

Dokumen ini tidak dimaksudkan untuk memperkenalkan konsep atau terminologi jaringan Kubernetes dan mengasumsikan bahwa Anda telah memiliki beberapa tingkat konsep jaringan umum dan pengetahuan jaringan Kubernetes. Untuk informasi selengkapnya, lihat ringkasan jaringan GKE.

Saat meninjau dokumen ini, pertimbangkan hal-hal berikut:

  • Cara Anda merencanakan pengeksposan workload secara internal ke jaringan Virtual Private Cloud (VPC), workload lain di cluster, cluster GKE lain, atau secara eksternal ke internet.
  • Cara Anda merencanakan penskalaan workload.
  • Jenis layanan Google yang ingin Anda gunakan.

Untuk mengetahui checklist ringkasan semua praktik terbaik, lihat Ringkasan checklist.

Desain VPC

Saat mendesain jaringan VPC, ikuti praktik terbaik untuk desain VPC.

Bagian berikut memberikan beberapa rekomendasi khusus GKE untuk desain jaringan VPC.

Praktik terbaik:

Gunakan cluster VPC native.
Gunakan Jaringan VPC bersama.

Menggunakan cluster VPC native

Sebaiknya gunakan cluster berbasis VPC. Cluster VPC native menggunakan rentang alamat IP alias pada node GKE dan diperlukan untuk cluster GKE pribadi serta untuk membuat cluster di VPC Bersama, dan memiliki banyak manfaat lainnya. Untuk cluster yang dibuat dalam mode Autopilot, mode native VPC selalu aktif dan tidak dapat dinonaktifkan.

Keuntungan dari penggunaan cluster native VPC dapat dimanfaatkan bersama dengan dukungan IP alias. Misalnya, grup endpoint jaringan (NEG) hanya dapat digunakan dengan alamat IP sekunder, sehingga hanya didukung di cluster berbasis VPC.

Menggunakan Jaringan VPC bersama

Cluster GKE memerlukan perencanaan alamat IP yang cermat. Sebagian besar organisasi cenderung memiliki struktur pengelolaan terpusat dengan tim administrasi jaringan yang dapat mengalokasikan ruang alamat IP untuk cluster dan administrator platform untuk mengoperasikan cluster. Jenis struktur organisasi ini bekerja dengan baik dengan arsitektur jaringan VPC Bersama Google Cloud. Dalam arsitektur jaringan VPC Bersama, administrator jaringan dapat membuat subnet dan membagikannya dengan VPC. Anda dapat membuat cluster GKE dalam project layanan dan menggunakan subnet yang dibagikan dari VPC Bersama pada project host. Komponen alamat IP tetap berada di project host, dan komponen cluster lainnya tetap berada di project layanan.

Secara umum, Jaringan VPC bersama adalah arsitektur yang sering digunakan dan cocok untuk sebagian besar organisasi dengan tim pengelolaan terpusat. Sebaiknya gunakan Jaringan VPC bersama untuk membuat subnet untuk cluster GKE Anda dan untuk menghindari konflik alamat IP di seluruh organisasi Anda. Anda juga dapat menggunakan VPC Bersama untuk tata kelola fungsi operasional. Misalnya, Anda dapat memiliki tim jaringan yang hanya bekerja pada komponen dan keandalan jaringan, dan tim lain yang menangani GKE.

Strategi pengelolaan alamat IP

Semua cluster Kubernetes, termasuk cluster GKE, memerlukan alamat IP yang unik untuk setiap Pod.

Untuk mempelajari lebih lanjut, lihat model jaringan GKE.

Di GKE, semua alamat IP ini dapat dirutekan di seluruh jaringan VPC. Oleh karena itu, perencanaan alamat IP diperlukan karena alamat tidak boleh tumpang-tindih dengan ruang alamat IP internal yang digunakan secara lokal atau di lingkungan terhubung lainnya. Bagian berikut menyarankan strategi untuk pengelolaan alamat IP dengan GKE.

Praktik terbaik:

Merencanakan alokasi alamat IP yang diperlukan.
Menggunakan spasi non-RFC 1918 jika diperlukan.
Menggunakan mode subnet kustom.
Merencanakan Kepadatan Pod per node.
Menhindari tumpang-tindih dengan alamat IP yang digunakan di lingkungan lain.
Membuat subnet load balancer.
Mencadangkan ruang alamat IP yang cukup untuk autoscaler cluster.
Berbagi alamat IP di berbagai cluster.
Berbagi alamat IP untuk Service LoadBalancer internal.

Merencanakan alokasi alamat IP yang diperlukan

Cluster pribadi direkomendasikan dan dibahas lebih lanjut di bagian Keamanan jaringan. Dalam konteks cluster pribadi, hanya cluster native VPC yang didukung dan memerlukan rentang alamat IP berikut:

  • Rentang alamat IP bidang kontrol: gunakan subnet /28 dalam rentang pribadi alamat IP yang disertakan pada RFC 1918. Anda harus memastikan subnet ini tidak tumpang tindih dengan perutean antar-domain (CIDR) tanpa class lainnya di jaringan VPC.
  • Subnet node: subnet dengan rentang alamat IP utama yang ingin Anda alokasikan untuk semua node dalam cluster. Layanan dengan jenis LoadBalancer yang menggunakan anotasi cloud.google.com/load-balancer-type: "Internal" juga menggunakan subnet ini secara default. Anda juga dapat menggunakan subnet khusus untuk load balancer internal.
  • Rentang alamat IP Pod: rentang IP yang dialokasikan untuk semua Pod dalam cluster Anda. GKE menyediakan rentang ini sebagai alias subnet. Untuk mengetahui informasi selengkapnya, lihat rentang alamat IP untuk cluster VPC native
  • Rentang alamat IP Service: rentang alamat IP yang Anda alokasikan untuk semua Service di cluster Anda. GKE menyediakan rentang ini sebagai alias dari subnet.

Untuk cluster pribadi, Anda harus menentukan subnet node, rentang alamat IP Pod, dan rentang alamat IP Service.

Jika Anda ingin menggunakan ruang alamat IP secara lebih efisien, lihat Mengurangi penggunaan alamat IP internal di GKE.

Rentang alamat IP bidang kontrol dikhususkan untuk bidang kontrol yang dikelola GKE dan berada di project tenant yang dikelola Google yang di-peering dengan VPC Anda. Rentang alamat IP ini tidak boleh tumpang-tindih dengan alamat IP mana pun di grup peering VPC Anda karena GKE mengimpor rute ini ke project Anda. Artinya, jika Anda memiliki rute ke CIDR yang sama dalam project, Anda mungkin akan mengalami masalah pemilihan rute.

Saat membuat cluster, subnet memiliki rentang utama untuk node cluster dan rentang tersebut harus ada sebelum pembuatan cluster. Subnet harus mengakomodasi jumlah maksimum node yang Anda harapkan di cluster dan alamat IP load balancer internal di seluruh cluster menggunakan subnet.

Anda dapat menggunakan penskala otomatis cluster untuk membatasi jumlah maksimum node.

Rentang alamat IP Pod dan layanan direpresentasikan sebagai rentang sekunder yang berbeda dari subnet Anda, yang diterapkan sebagai alamat IP alias di cluster VPC native.

Pilih rentang alamat IP yang cukup luas agar Anda dapat mengakomodasi semua node, Pod, dan Layanan untuk cluster.

Pertimbangkan batasan berikut:

Gunakan lebih dari sekadar alamat IP RFC 1918 pribadi

Untuk beberapa lingkungan, ruang RFC 1918 dalam blok CIDR besar yang berdekatan mungkin sudah dialokasikan di suatu organisasi. Anda dapat menggunakan ruang non-RFC 1918 untuk CIDR tambahan bagi cluster GKE, jika tidak tumpang tindih dengan alamat IP publik milik Google. Sebaiknya gunakan bagian 100.64.0.0/10 dari ruang alamat RFC karena ruang alamat Class E dapat menghadirkan masalah interoperabilitas dengan hardware lokal. Anda dapat menggunakan IP publik yang digunakan kembali secara pribadi (PUPI).

Anda tidak boleh menggunakan penafsiran alamat jaringan sumber (SNAT) dalam cluster dengan traffic Pod-to-Pod dan Pod-to-Service. Hal ini merusak model jaringan Kubernetes.

Kubernetes mengasumsikan bahwa semua alamat IP non-RFC 1918 digunakan kembali secara pribadi dan menggunakan SNAT untuk semua traffic yang berasal dari alamat tersebut.

Jika menggunakan alamat IP non-RFC 1918 untuk cluster GKE, untuk cluster Standar, Anda harus menonaktifkan SNAT secara eksplisit atau mengonfigurasi agen mengonfigurasi agen penyamaran IP untuk mengecualikan alamat IP Pod cluster dan rentang alamat IP sekunder untuk Layanan dari SNAT. Untuk cluster Autopilot, hal ini tidak memerlukan langkah tambahan.

Menggunakan mode subnet kustom

Saat menyiapkan jaringan, Anda juga memilih mode subnet: auto (default) atau custom (direkomendasikan). Mode auto menyerahkan alokasi subnet kepada Google dan merupakan opsi yang bagus untuk memulai tanpa perencanaan alamat IP. Namun, sebaiknya pilih mode custom karena mode ini memungkinkan Anda memilih rentang alamat IP yang tidak akan tumpang-tindih dengan rentang lain di lingkungan Anda. Jika Anda menggunakan VPC Bersama, administrator organisasi atau administrator jaringan dapat memilih mode ini.

Contoh berikut membuat jaringan bernama my-net-1 dengan mode subnet kustom:

gcloud compute networks create my-net-1 --subnet-mode custom

Merencanakan kepadatan Pod per node

Secara default, cluster Standar mencadangkan rentang /24 untuk setiap node dari ruang alamat Pod di subnet dan memungkinkan hingga 110 Pod per node. Namun, Anda dapat mengonfigurasi cluster Standar untuk mendukung hingga 256 Pod per node, dengan rentang /23 yang dicadangkan untuk setiap node. Bergantung pada ukuran node dan profil aplikasi Pod, Anda mungkin menjalankan lebih sedikit Pod di setiap node.

Jika Anda tidak akan menjalankan lebih dari 64 Pod per node, sebaiknya sesuaikan Pod maksimum per node untuk mempertahankan ruang alamat IP di subnet Pod.

Jika diperkirakan akan menjalankan lebih dari 110 Pod default per node, Anda dapat meningkatkan jumlah Pod maksimum per node hingga 256, dengan /23 dicadangkan untuk setiap node. Dengan jenis konfigurasi kepadatan Pod tinggi ini, sebaiknya gunakan instance dengan 16 core CPU atau lebih untuk memastikan skalabilitas dan performa cluster Anda.

Untuk cluster Autopilot, jumlah maksimum Pod per node ditetapkan ke 32, dengan rentang /26 untuk setiap node. Setelan ini tidak dapat dikonfigurasi di cluster Autopilot.

Menghindari tumpang-tindih dengan alamat IP yang digunakan di lingkungan lain

Anda dapat menghubungkan jaringan VPC ke lingkungan lokal atau penyedia layanan cloud lainnya melalui Cloud VPN atau Cloud Interconnect. Lingkungan ini dapat berbagi rute sehingga skema pengelolaan alamat IP lokal penting dalam perencanaan alamat IP untuk GKE. Sebaiknya pastikan alamat IP tidak tumpang tindih dengan alamat IP yang digunakan di lingkungan lain.

Membuat subnet load balancer

Buat subnet load balancer terpisah untuk menampilkan layanan dengan load balancing TCP/UDP internal. Jika subnet load balancer terpisah tidak digunakan, layanan ini akan diekspos menggunakan alamat IP dari subnet node, yang dapat menyebabkan penggunaan semua ruang yang dialokasikan di subnet tersebut lebih awal dari yang diharapkan dan dapat membuat Anda berhenti menskalakan cluster GKE ke jumlah node yang diharapkan.

Menggunakan subnet load balancer terpisah juga berarti Anda dapat memfilter traffic ke dan dari node GKE secara terpisah ke layanan yang diekspos oleh load balancing TCP/UDP internal sehingga Anda dapat menetapkan batas keamanan yang lebih ketat.

Mencadangkan ruang alamat IP yang cukup untuk autoscaler cluster

Anda dapat menggunakan autoscaler cluster untuk menambahkan dan menghapus node dalam cluster secara dinamis sehingga Anda dapat mengontrol biaya dan meningkatkan utilisasi. Namun, saat menggunakan penskala otomatis cluster, pastikan bahwa perencanaan alamat IP Anda memperhitungkan ukuran maksimum semua kumpulan node. Setiap node baru memerlukan alamat IP node-nya sendiri serta kumpulan alamat IP Pod yang dapat dialokasikan berdasarkan Pod yang dikonfigurasi per node. Jumlah Pod per node dapat dikonfigurasi secara berbeda dari yang dikonfigurasi di level cluster. Anda tidak dapat mengubah jumlah Pod per node setelah membuat cluster atau kumpulan node. Anda harus mempertimbangkan jenis workload dan menetapkannya ke kumpulan node yang berbeda untuk alokasi alamat IP yang optimal.

Pertimbangkan untuk menggunakan penyediaan otomatis node, dengan scaler cluster, terutama jika Anda menggunakan cluster native VPC. Untuk informasi selengkapnya, baca Rentang yang membatasi node.

Berbagi alamat IP di seluruh cluster

Anda mungkin perlu berbagi alamat IP di seluruh cluster jika memiliki tim terpusat yang mengelola infrastruktur untuk cluster. Untuk membagikan alamat IP ke seluruh cluster GKE, baca artikel Membagikan rentang alamat IP di seluruh cluster GKE. Anda dapat mengurangi kehabisan IP dengan membuat tiga rentang untuk Pod, Service, dan node, serta menggunakan kembali atau membagikannya, terutama dalam model VPC Bersama. Penyiapan ini juga dapat memudahkan administrator jaringan untuk mengelola alamat IP dengan tidak mengharuskan mereka membuat subnet khusus untuk setiap cluster.

Pertimbangkan hal berikut:

  • Sebagai praktik terbaik, gunakan subnet dan rentang alamat IP terpisah untuk semua cluster.
  • Anda dapat membagikan rentang alamat IP Pod sekunder, tetapi hal ini tidak direkomendasikan karena satu cluster mungkin menggunakan semua alamat IP.
  • Anda dapat berbagi rentang alamat IP Layanan sekunder, tetapi fitur ini tidak berfungsi dengan Cloud DNS cakupan VPC untuk GKE.

Jika kehabisan alamat IP, Anda dapat membuat rentang alamat IP Pod tambahan menggunakan CIDR multi-Pod yang terputus.

Berbagi alamat IP untuk Service LoadBalancer internal

Anda dapat berbagi satu alamat IP dengan maksimal 50 backend menggunakan port yang berbeda. Hal ini memungkinkan Anda mengurangi jumlah alamat IP yang diperlukan untuk LoadBalancer Service internal.

Untuk mengetahui informasi selengkapnya, lihat IP bersama.

Opsi keamanan jaringan

Beberapa rekomendasi utama diuraikan di bagian ini untuk isolasi cluster. Keamanan jaringan untuk cluster GKE adalah tanggung jawab bersama antara Google dan administrator cluster Anda.

Praktik terbaik:

Gunakan GKE Dataplane V2.
Pilih jenis cluster pribadi.
Minimalkan eksposur bidang kontrol cluster.
Mengizinkan akses ke bidang kontrol.
Mengizinkan konektivitas bidang kontrol.
Men-deploy proxy untuk akses bidang kontrol dari jaringan yang di-peering.
Membatasi traffic cluster menggunakan kebijakan jaringan.
Aktifkan kebijakan keamanan Google Cloud Armor untuk Ingress.
Menggunakan Identity-Aware Proxy untuk menyediakan autentikasi untuk aplikasi dengan pengguna IAM.
Menggunakan batasan kebijakan organisasi untuk lebih meningkatkan keamanan.

Menggunakan GKE Dataplane V2

GKE Dataplane V2 didasarkan pada eBPF dan memberikan pengalaman visibilitas dan keamanan jaringan terintegrasi. Saat membuat cluster menggunakan GKE Dataplane V2, Anda tidak perlu mengaktifkan kebijakan jaringan secara eksplisit karena GKE Dataplane V2 mengelola pemilihan rute layanan, penerapan kebijakan jaringan, dan logging. Aktifkan paket data baru dengan opsi --enable-dataplane-v2 Google Cloud CLI saat membuat cluster. Setelah kebijakan jaringan dikonfigurasi, objek CRD NetworkLogging default dapat dikonfigurasi untuk mencatat koneksi jaringan yang diizinkan dan ditolak. Sebaiknya buat cluster dengan GKE Dataplane V2 untuk memanfaatkan sepenuhnya fitur bawaan seperti logging kebijakan jaringan.

Memilih jenis cluster pribadi

Cluster publik memiliki alamat IP pribadi dan publik pada node dan hanya endpoint publik untuk node bidang kontrol. Cluster pribadi memberikan lebih banyak isolasi dengan hanya memiliki alamat IP internal pada node, dan memiliki endpoint pribadi atau publik untuk node bidang kontrol (yang dapat diisolasi lebih lanjut dan dibahas di bagian Meminimalkan eksposur bidang kontrol cluster). Dalam cluster pribadi, Anda masih dapat mengakses Google API dengan Akses Google Pribadi. Sebaiknya pilih cluster pribadi.

Dalam cluster pribadi, Pod diisolasi dari komunikasi masuk dan keluar (perimeter cluster). Anda dapat mengontrol alur terarah ini dengan mengekspos layanan menggunakan load balancing dan Cloud NAT, yang dibahas di bagian konektivitas cluster dalam dokumen ini. Diagram berikut menunjukkan jenis penyiapan ini:

Diagram 1: Komunikasi cluster pribadi

Diagram ini menunjukkan cara cluster pribadi dapat berkomunikasi. Klien lokal dapat terhubung ke cluster dengan klien kubectl. Akses ke Layanan Google disediakan melalui Akses Google Pribadi, dan komunikasi ke internet hanya tersedia menggunakan Cloud NAT.

Untuk mengetahui informasi selengkapnya, tinjau persyaratan, batasan, dan batasan cluster pribadi.

Meminimalkan eksposur bidang kontrol cluster

Dalam cluster pribadi, server GKE API dapat diekspos sebagai endpoint publik atau pribadi. Anda dapat menentukan endpoint yang akan digunakan saat membuat cluster. Anda dapat mengontrol akses dengan jaringan yang diizinkan, dengan endpoint publik dan pribadi yang ditetapkan secara default untuk mengizinkan semua komunikasi antara Pod dan alamat IP node di cluster. Untuk mengaktifkan endpoint pribadi saat membuat cluster, gunakan flag --enable-private-endpoint.

Mengizinkan akses ke bidang kontrol

Jaringan yang diizinkan dapat membantu menentukan subnet alamat IP yang dapat mengakses node bidang kontrol GKE. Setelah mengaktifkan jaringan ini, Anda dapat membatasi akses ke rentang alamat IP sumber tertentu. Jika endpoint publik dinonaktifkan, rentang alamat IP sumber ini harus bersifat pribadi. Jika endpoint publik diaktifkan, Anda dapat mengizinkan rentang alamat IP publik atau internal. Konfigurasikan iklan rute kustom agar endpoint pribadi bidang kontrol cluster dapat dijangkau dari lingkungan lokal. Anda dapat membuat endpoint GKE API pribadi dapat dijangkau secara global menggunakan opsi --enable-master-global-access saat membuat cluster.

Diagram berikut menunjukkan konektivitas bidang kontrol standar menggunakan jaringan yang diizinkan:

Diagram 2: Mengontrol konektivitas bidang menggunakan jaringan yang diizinkan

Diagram ini menunjukkan bahwa pengguna tepercaya yang dapat berkomunikasi dengan bidang kontrol GKE melalui endpoint publik karena mereka adalah bagian dari jaringan yang diizinkan, sementara akses dari pelaku yang tidak tepercaya diblokir. Komunikasi ke dan dari cluster GKE terjadi melalui endpoint pribadi bidang kontrol.

Mengizinkan konektivitas bidang kontrol

Pod sistem tertentu di setiap node pekerja perlu menjangkau layanan seperti server Kubernetes API (kube-apiserver), Google API, atau server metadata. kube-apiserverjuga harus berkomunikasi dengan beberapa Pod sistem, seperti event-exporter khususnya. Komunikasi ini diizinkan secara default. Jika Anda men-deploy aturan firewall VPC dalam project (detail selengkapnya di bagian Membatasi traffic cluster), pastikan Pod tersebut dapat terus berkomunikasi dengan kube-apiserver dan juga Google API.

Men-deploy proxy untuk akses bidang kontrol dari jaringan yang di-peering

Akses ke bidang kontrol untuk cluster GKE pribadi adalah melalui Peering Jaringan VPC. Peering Jaringan VPC bersifat non-transitif sehingga Anda tidak dapat mengakses bidang kontrol cluster dari jaringan yang di-peering lain.

Jika Anda menginginkan akses langsung dari jaringan yang di-peering atau dari infrastruktur lokal saat menggunakan arsitektur hub-and-spoke, deploy proxy untuk traffic bidang kontrol.

Membatasi traffic cluster menggunakan kebijakan jaringan

Keamanan jaringan yang terdiri dari beberapa tingkat dapat diterapkan untuk beban kerja cluster yang dapat digabungkan: aturan firewall VPC, Kebijakan firewall hierarkis, dan kebijakan jaringan Kubernetes. Aturan firewall VPC dan kebijakan firewall hierarkis berlaku pada level virtual machine (VM), yaitu node pekerja tempat Pod cluster GKE berada. Kebijakan jaringan Kubernetes berlaku di level Pod untuk menerapkan Pod ke jalur traffic Pod.

Firewall VPC dapat merusak komunikasi default yang diperlukan pada komunikasi bidang kontrol, misalnya komunikasi kubelet dengan bidang kontrol. GKE membuat aturan firewall yang diperlukan secara default, tetapi aturan tersebut dapat ditimpa. Beberapa deployment mungkin memerlukan bidang kontrol untuk menjangkau cluster pada layanan. Anda dapat menggunakan firewall VPC untuk mengonfigurasi kebijakan ingress yang membuat layanan mudah diakses.

Kebijakan jaringan GKE dikonfigurasi melalui Kubernetes Network Policy API untuk menerapkan komunikasi Pod cluster. Anda dapat mengaktifkan kebijakan jaringan saat membuat cluster menggunakan opsi gcloud container clusters create, --enable-network-policy. Untuk membatasi traffic menggunakan kebijakan jaringan, Anda dapat mengikuti Panduan penerapan blueprint traffic Anthos.

Mengaktifkan kebijakan keamanan Google Cloud Armor untuk Ingress

Dengan menggunakan kebijakan keamanan Google Cloud Armor, Anda dapat melindungi aplikasi yang menggunakan Load Balancer Aplikasi eksternal dari serangan DDoS dan serangan berbasis web lainnya dengan memblokir traffic tersebut di edge jaringan. Di GKE, aktifkan kebijakan keamanan Google Cloud Armor untuk aplikasi menggunakan Ingress untuk Load Balancer Aplikasi eksternal dan menambahkan kebijakan keamanan ke BackendConfig yang dilampirkan ke objek Ingress.

Menggunakan Identity-Aware Proxy agar dapat menyediakan autentikasi untuk aplikasi dengan pengguna IAM

Jika ingin men-deploy service agar hanya dapat diakses oleh pengguna di dalam organisasi, tetapi tanpa perlu berada di jaringan perusahaan, Anda dapat menggunakan Identity-Aware Proxy untuk membuat lapisan otentikasi untuk aplikasi-aplikasi ini. Agar dapat mengaktifkan Identity-Aware Proxy untuk GKE, ikuti langkah-langkah konfigurasi untuk menambahkan Identity-Aware Proxy sebagai bagian dari BackendConfig untuk Ingress service Anda. Identity-Aware Proxy dapat digabungkan dengan Google Cloud Armor.

Menggunakan batasan kebijakan organisasi untuk lebih meningkatkan keamanan

Dengan menggunakan batasan kebijakan organisasi, Anda dapat menetapkan kebijakan untuk lebih meningkatkan postur keamanan Anda. Misalnya, Anda dapat menggunakan batasan untuk membatasi pembuatan Load Balancer ke jenis tertentu, seperti load balancer internal saja.

Menskalakan konektivitas cluster

Bagian ini membahas opsi skalabel untuk konektivitas keluar dan DNS dari cluster Anda ke layanan internet dan Google.

Praktik terbaik:

Gunakan Cloud DNS untuk GKE.
Aktifkan NodeLocal DNSCache.
Gunakan Cloud NAT untuk akses internet dari cluster pribadi.
Gunakan Akses Google Pribadi untuk mengakses layanan Google.

Menggunakan Cloud DNS untuk GKE

Anda dapat menggunakan Cloud DNS untuk GKE untuk menyediakan resolusi Pod dan DNS Layanan dengan DNS terkelola tanpa penyedia DNS yang dihosting cluster. Cloud DNS menghilangkan overhead pengelolaan server DNS yang dihosting cluster dan tidak memerlukan penskalaan, pemantauan, atau pengelolaan instance DNS karena ini merupakan layanan Google yang dihosting.

Mengaktifkan NodeLocal DNSCache

GKE menggunakan kube-dns untuk menyediakan layanan DNS lokal cluster sebagai add-on cluster default. kube-dns direplikasi di seluruh cluster sebagai fungsi dari jumlah total core dan node dalam cluster.

Anda dapat meningkatkan performa DNS dengan NodeLocal DNSCache. NodeLocal DNSCache adalah add-on yang di-deploy sebagai DaemonSet, dan tidak memerlukan perubahan konfigurasi Pod. Pencarian DNS ke layanan Pod lokal tidak membuat koneksi terbuka yang perlu dilacak pada node yang memungkinkan skala yang lebih besar. Pencarian nama host eksternal diteruskan ke Cloud DNS, sedangkan semua kueri DNS lainnya akan diteruskan ke kube-dns.

Aktifkan NodeLocal DNSCache untuk waktu pencarian kueri DNS yang lebih konsisten dan skala cluster yang lebih baik. Untuk cluster Autopilot, NodeLocal DNSCache diaktifkan secara default dan tidak dapat diganti.

Opsi Google Cloud CLI berikut mengaktifkan NodeLocal DNSCache saat Anda membuat cluster: --addons NodeLocalDNS.

Jika Anda memiliki kontrol atas nama yang ingin diselesaikan oleh aplikasi, ada cara untuk meningkatkan penskalaan DNS. Misalnya, gunakan FQDN (akhiri nama host dengan titik) atau nonaktifkan perluasan jalur penelusuran melalui opsi manifes Pod.dnsConfig.

Menggunakan Cloud NAT untuk akses internet dari cluster pribadi

Secara default, cluster pribadi tidak memiliki akses internet. Agar Pod dapat menjangkau internet, aktifkan Cloud NAT untuk setiap region. Minimal, aktifkan Cloud NAT untuk rentang primer dan sekunder di subnet GKE. Pastikan Anda mengalokasikan cukup alamat IP untuk Cloud NAT dan port per VM.

Gunakan praktik terbaik konfigurasi Gateway Cloud NAT berikut saat menggunakan Cloud NAT untuk cluster pribadi:

  • Saat membuat gateway Cloud NAT, aktifkan gateway hanya untuk rentang subnet yang digunakan oleh cluster Anda. Dengan menghitung semua node di semua cluster, Anda dapat menentukan jumlah VM konsumen NAT yang Anda miliki dalam project.

  • Gunakan alokasi port dinamis untuk mengalokasikan jumlah port yang berbeda per VM, berdasarkan penggunaan VM. Mulailah dengan port minimum 64 dan port maksimum 2048.

  • Jika Anda perlu mengelola banyak koneksi simultan ke 3-tuple tujuan yang sama, kurangi waktu tunggu TIME_WAIT TCP dari nilai default 120s menjadi 5s. Untuk mengetahui informasi selengkapnya, lihat Menentukan waktu tunggu yang berbeda untuk NAT.

  • Aktifkan logging error Cloud NAT untuk memeriksa log terkait.

  • Periksa log Gateway Cloud NAT setelah mengonfigurasi gateway. Untuk mengurangi status alokasi yang terhenti, Anda mungkin perlu meningkatkan jumlah maksimum port per VM.

Anda harus menghindari SNAT ganda untuk traffic Pod (SNAT terlebih dahulu di node GKE, lalu diikuti lagi dengan Cloud NAT). Kecuali jika Anda mewajibkan SNAT untuk menyembunyikan alamat IP Pod dari jaringan lokal yang terhubung oleh Cloud VPN atau Cloud Interconnect, disable-default-snat dan alihkan pelacakan SNAT ke Cloud NAT untuk mendapatkan skalabilitas. Solusi ini berfungsi untuk semua rentang IP subnet primer dan sekunder. Gunakan kebijakan jaringan untuk membatasi traffic eksternal setelah mengaktifkan Cloud NAT. Cloud NAT tidak diperlukan untuk mengakses layanan Google.

Menggunakan Akses Google Pribadi untuk mengakses layanan Google

Dalam cluster pribadi, Pod tidak memiliki alamat IP publik untuk menjangkau layanan publik, termasuk Google API dan layanan Google. Akses Google Pribadi memungkinkan resource Google Cloud pribadi menjangkau layanan Google.

Akses Google Pribadi diaktifkan secara default di cluster pribadi, kecuali untuk cluster VPC Bersama.

Aplikasi yang aktif

Saat membuat aplikasi yang dapat dijangkau secara eksternal atau internal untuk organisasi Anda, pastikan Anda menggunakan jenis dan opsi load balancer yang tepat. Bagian ini memberikan beberapa rekomendasi tentang cara mengekspos dan menskalakan aplikasi dengan Cloud Load Balancing.

Praktik terbaik:

Menggunakan load balancing berbasis container.
Memilih resource GKE yang tepat untuk mengekspos aplikasi Anda.
Membuat health check berdasarkan BackendConfig.
Menggunakan kebijakan traffic lokal untuk mempertahankan alamat IP asli.
Menggunakan Private Service Connect.

Menggunakan load balancing berbasis container

Gunakan load balancing berbasis container saat mengekspos layanan dengan menggunakan HTTP(S) secara eksternal. Load balancing berbasis container memungkinkan hop jaringan yang lebih sedikit, latensi yang lebih rendah, dan distribusi traffic yang lebih tepat. Layanan ini juga meningkatkan visibilitas waktu round-trip dan memungkinkan Anda menggunakan fitur load balancing seperti Google Cloud Armor.

Memilih resource GKE yang tepat untuk mengekspos aplikasi Anda

Bergantung pada cakupan klien Anda (internal, eksternal, atau bahkan cluster-internal), regionalitas aplikasi, dan protokol yang digunakan, terdapat berbagai resource GKE yang dapat Anda pilih gunakan untuk mengekspos aplikasi Anda. Ringkasan jaringan layanan menjelaskan opsi ini dan dapat membantu Anda memilih resource terbaik untuk mengekspos setiap bagian aplikasi Anda menggunakan opsi load balancing Google Cloud.

Membuat health check berdasarkan BackendConfig

Jika Anda menggunakan Ingress untuk mengekspos layanan, gunakan konfigurasi health check di BackendConfig CRD untuk menggunakan fungsi health check dari Load Balancer Aplikasi eksternal. Anda dapat mengarahkan health check ke endpoint yang sesuai dan menetapkan batas Anda sendiri. Tanpa CRD BackendConfig, health check disimpulkan dari parameter pemeriksaan kesiapan atau menggunakan parameter default.

Menggunakan kebijakan traffic lokal untuk mempertahankan alamat IP asli

Saat Anda menggunakan Load Balancer Jaringan passthrough internal dengan GKE, tetapkan opsi externalTrafficPolicy ke Local untuk mempertahankan alamat IP sumber permintaan. Gunakan opsi ini jika aplikasi Anda memerlukan alamat IP sumber yang asli. Namun, opsi externalTrafficPolicy local dapat menyebabkan penyebaran beban yang kurang optimal, jadi hanya gunakan fitur ini saat diperlukan. Untuk layanan HTTP(S), Anda dapat menggunakan Pengontrol Ingress dan mendapatkan alamat IP asli dengan membaca header X-Forwarded-For dalam permintaan HTTP.

Menggunakan Private Service Connect

Anda dapat menggunakan Private Service Connect untuk membagikan Service Network Load Balancer passthrough internal di seluruh jaringan VPC lainnya. Hal ini berguna untuk Layanan yang dihosting di cluster GKE, tetapi melayani pelanggan yang berjalan di project dan VPC yang berbeda.

Anda dapat menggunakan Private Service Connect untuk mengurangi penggunaan alamat IP dengan menyediakan konektivitas antar-VPC dengan alamat IP yang tumpang-tindih.

Operasi dan administrasi

Praktik terbaik:

Gunakan IAM untuk izin GKE guna mengontrol kebijakan di jaringan VPC Bersama.
Gunakan cluster regional dan distribusikan workload Anda untuk ketersediaan tinggi.
Menggunakan Cloud Logging dan Cloud Monitoring serta mengaktifkan logging kebijakan jaringan.

Bagian berikut berisi praktik terbaik operasional yang membantu Anda memastikan opsi otorisasi terperinci untuk workload Anda. Untuk menghindari pembuatan aturan firewall manual, ikuti praktik terbaik operasional di bagian ini. Aktivitas ini juga mencakup rekomendasi untuk mendistribusikan workload Anda serta melakukan pemantauan dan logging di GKE.

Menggunakan IAM untuk izin GKE guna mengontrol kebijakan di jaringan VPC Bersama

Saat menggunakan jaringan VPC Bersama, aturan firewall untuk load balancer akan dibuat secara otomatis di project host.

Agar tidak perlu membuat aturan firewall secara manual, tetapkan peran khusus dengan hak istimewa terendah untuk akun layanan GKE di project host yang bernama service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com.

Ganti HOST_PROJECT_NUMBER dengan nomor project project host untuk VPC Bersama.

Peran khusus yang Anda buat harus memiliki izin berikut:

  • compute.firewalls.create
  • compute.firewalls.get
  • compute.firewalls.list
  • compute.firewalls.delete

Selain itu, aturan firewall yang dibuat oleh GKE selalu memiliki prioritas default 1.000 sehingga Anda dapat melarang traffic tertentu agar tidak mengalir dengan membuat aturan firewall pada prioritas yang lebih tinggi.

Jika Anda ingin membatasi pembuatan jenis load balancer tertentu, gunakan kebijakan organisasi untuk membatasi pembuatan load balancer.

Menggunakan cluster regional dan distribusikan workload Anda untuk ketersediaan tinggi

Cluster regional dapat meningkatkan ketersediaan aplikasi dalam cluster karena node dan bidang kontrol cluster tersebar di beberapa zona.

Namun, untuk mendapatkan pengalaman pengguna terbaik jika terjadi kegagalan zona, gunakan autoscaler cluster untuk memastikan cluster Anda dapat menangani beban yang diperlukan kapan saja.

Anda juga dapat menggunakan anti-afinitas Pod untuk memastikan bahwa Pod dari layanan tertentu dijadwalkan di beberapa zona.

Guna mengetahui informasi selengkapnya tentang cara mengonfigurasi setelan ini untuk ketersediaan tinggi dan pengoptimalan biaya, baca Praktik terbaik untuk cluster GKE yang sangat tersedia.

Menggunakan Cloud Logging dan Cloud Monitoring serta mengaktifkan logging kebijakan jaringan

Meskipun setiap organisasi memiliki persyaratan yang berbeda untuk visibilitas dan pengauditan, sebaiknya aktifkan logging kebijakan jaringan. Fitur ini hanya tersedia di GKE Dataplane V2. Logging kebijakan jaringan memberikan visibilitas terkait penerapan kebijakan dan pola traffic Pod. Perlu diketahui bahwa ada biaya yang diperlukan untuk logging kebijakan jaringan.

Untuk cluster GKE yang menggunakan versi 1.14 atau yang lebih baru, Logging dan Monitoring diaktifkan secara default. Monitoring menyediakan dasbor untuk cluster GKE Anda. Logging juga memungkinkan anotasi GKE untuk VPC Flow Logs. Secara default, Logging mengumpulkan log untuk semua workload yang di-deploy ke cluster, tetapi opsi log khusus sistem juga ada. Gunakan dasbor GKE untuk mengamati dan menyetel pemberitahuan. Untuk cluster yang dibuat dalam mode Autopilot, pemantauan dan logging otomatis diaktifkan dan tidak dapat dikonfigurasi.

Perlu diketahui bahwa ada biaya yang diperlukan untuk Kemampuan Observasi Google Cloud.

Ringkasan checklist

Area Praktik
Desain VPC
Strategi pengelolaan alamat IP
Opsi keamanan jaringan
Penskalaan
Aplikasi yang aktif
Operasi dan administrasi

Langkah selanjutnya