Halaman 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 di halaman 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.
Sebelum membaca halaman ini, pastikan Anda memahami konsep dan terminologi jaringan Kubernetes, beberapa tingkat konsep jaringan umum, dan jaringan Kubernetes. Untuk mengetahui informasi selengkapnya, lihat ringkasan jaringan GKE.
Saat meninjau praktik terbaik 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.
Menggunakan cluster VPC native
Sebaiknya gunakan cluster native VPC. Cluster native VPC menggunakan rentang alamat IP alias di node GKE dan diperlukan untuk cluster berdasarkan Peering Jaringan VPC, untuk cluster di VPC Bersama, dan memiliki banyak manfaat lain. Untuk cluster yang dibuat dalam mode Autopilot, mode native VPC selalu aktif dan tidak dapat dinonaktifkan.
Cluster VPC native dapat diskalakan lebih mudah daripada cluster berbasis rute tanpa menggunakan rute Google Cloud sehingga tidak terlalu rentan terhadap batas perutean.
Keuntungan menggunakan cluster native VPC dapat digabungkan dengan dukungan IP alias. Misalnya, grup endpoint jaringan (NEG) hanya dapat digunakan dengan alamat IP sekunder sehingga hanya didukung di cluster native 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 admin platform untuk mengoperasikan cluster. Jenis struktur organisasi ini berfungsi 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 di project layanan dan menggunakan subnet yang dibagikan dari VPC Bersama di project host. Komponen alamat IP tetap berada di project host, dan komponen cluster lainnya berada dalam 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 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 di infrastruktur 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
Sebaiknya gunakan cluster native VPC dengan Private Service Connect (PSC). Cluster yang menggunakan Peering Jaringan VPC harus berupa cluster VPC native.
Cluster VPC native 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 tanpa class (CIDR) lainnya di jaringan VPC.
- Subnet node: subnet dengan rentang alamat IP utama yang ingin Anda
alokasikan untuk semua node dalam cluster. Layanan dengan jenis
LoadBalanceryang menggunakan anotasicloud.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 native VPC
- Rentang alamat IP Service: rentang alamat IP yang Anda alokasikan untuk semua Service di cluster Anda. GKE menyediakan rentang ini sebagai alias dari subnet.
Saat mengonfigurasi jaringan cluster, 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 perkirakan dalam cluster dan alamat IP load balancer internal di seluruh cluster menggunakan subnet.
Anda dapat menggunakan autoscaler 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 lebar sehingga Anda dapat mengakomodasi semua node, Pod, dan Layanan untuk cluster.
Pertimbangkan batasan berikut:
- Anda dapat memperluas rentang alamat IP utama, tetapi tidak dapat mempersempitnya. Rentang alamat IP ini tidak boleh terputus.
- Anda dapat memperluas rentang Pod dengan menambahkan rentang Pod tambahan ke cluster atau membuat node pool baru dengan rentang Pod sekunder lainnya.
- Rentang alamat IP sekunder untuk Layanan tidak dapat diperluas atau diubah selama masa aktif cluster.
- Tinjau batasan untuk rentang alamat IP sekunder untuk Pod dan Layanan.
Menggunakan lebih dari 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 sebagai CIDR tambahan untuk cluster GKE, jika CIDR tersebut 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 menimbulkan masalah interoperabilitas dengan infrastruktur lokal perangkat keras. Anda dapat menggunakan IP publik yang digunakan kembali secara pribadi (PUPI).
Saat menggunakan alamat IP publik yang digunakan secara pribadi, gunakan dengan hati-hati dan pertimbangkan untuk mengontrol pemberitahuan rute di jaringan lokal ke internet saat memilih opsi ini.
Anda tidak boleh menggunakan penafsiran alamat jaringan sumber (SNAT) dalam cluster dengan traffic Pod-to-Pod dan Pod-to-Service. Hal ini akan merusak model jaringan Kubernetes.
Kubernetes mengasumsikan bahwa semua alamat IP non-RFC 1918 adalah alamat IP publik yang digunakan kembali secara pribadi dan menggunakan SNAT untuk semua traffic yang berasal dari alamat ini.
Jika menggunakan alamat IP non-RFC 1918 untuk cluster GKE, untuk cluster Standar, Anda harus menonaktifkan SNAT secara eksplisit atau mengonfigurasi agen konfigurasi 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 apa pun.
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 Standard mencadangkan rentang /24 untuk setiap node dari ruang alamat Pod di subnet dan memungkinkan hingga 110 Pod per node. Namun, Anda dapat mengonfigurasi cluster Standard 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 mencegah Anda 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 secara dinamis di cluster agar Anda dapat mengontrol biaya dan meningkatkan pemanfaatan. Namun, saat Anda menggunakan autoscaler cluster, pastikan perencanaan alamat IP Anda memperhitungkan ukuran maksimum semua node pool. Setiap node baru memerlukan alamat IP node-nya sendiri serta kumpulan alamat IP Pod yang dapat dialokasikan sendiri berdasarkan Pod yang dikonfigurasi per node. Jumlah Pod per node dapat dikonfigurasi secara berbeda dari yang dikonfigurasi di tingkat cluster. Anda tidak dapat mengubah jumlah Pod per node setelah membuat cluster atau node pool. Anda harus mempertimbangkan jenis workload dan menetapkannya ke node pool yang berbeda untuk alokasi alamat IP yang optimal.
Pertimbangkan untuk menggunakan penyediaan otomatis node, dengan autoscaler cluster, terutama jika Anda menggunakan cluster native VPC. Untuk informasi selengkapnya, lihat 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 berbagi alamat IP di seluruh cluster GKE, lihat Membagikan rentang alamat IP di seluruh cluster GKE. Anda dapat mengurangi kehabisan IP dengan membuat tiga rentang untuk Pod, Layanan, 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 tertentu 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 membagikan rentang alamat IP Service sekunder, tetapi fitur ini tidak berfungsi dengan Cloud DNS untuk GKE dengan cakupan VPC.
Jika kehabisan alamat IP, Anda dapat membuat rentang alamat IP Pod tambahan menggunakan CIDR multi-Pod yang tidak terhubung.
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 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.Minimalkan eksposur node.
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.
Gunakan Identity-Aware Proxy untuk menyediakan autentikasi bagi aplikasi dengan pengguna IAM.
Gunakan batasan kebijakan organisasi untuk lebih meningkatkan keamanan.
Menggunakan GKE Dataplane V2
GKE Dataplane V2 didasarkan pada
eBPF dan memberikan pengalaman keamanan
dan visibilitas jaringan terintegrasi. Saat membuat cluster menggunakan
GKE Dataplane V2, Anda tidak perlu secara eksplisit mengaktifkan kebijakan jaringan karena
GKE Dataplane V2 mengelola perutean layanan, penerapan kebijakan jaringan, dan
logging. Aktifkan dataplane 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.
Meminimalkan eksposur node
Dalam cluster dengan node pribadi saja, 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 ini menunjukkan cara cluster dengan node pribadi dapat berkomunikasi. Klien lokal dapat terhubung ke cluster dengan klien kubectl. Akses ke Google Service disediakan melalui Akses Google Pribadi, dan komunikasi ke internet hanya tersedia dengan menggunakan Cloud NAT.
Meminimalkan eksposur bidang kontrol cluster
Bidang kontrol memiliki dua jenis endpoint untuk akses cluster:
- Endpoint berbasis DNS
- Endpoint berbasis IP
Hanya gunakan endpoint berbasis DNS untuk mengakses bidang kontrol Anda guna mendapatkan konfigurasi yang disederhanakan dan lapisan keamanan yang fleksibel dan berbasis kebijakan.
Endpoint DNS dapat diakses dari jaringan apa pun yang dapat dijangkau oleh Google Cloud API, termasuk jaringan lokal atau jaringan cloud lainnya. Untuk mengaktifkan endpoint berbasis DNS, gunakan flag --enable-dns-access.
Server GKE API juga dapat diekspos sebagai
endpoint berbasis IP 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 secara default 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 pemberitahuan 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 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 juga dapat terus berkomunikasi dengan kube-apiserver serta Google
API.
Men-deploy proxy untuk akses bidang kontrol dari jaringan yang di-peering
Jika cluster Anda menggunakan Peering Jaringan VPC, Anda tidak dapat mengakses bidang kontrol cluster dari jaringan yang di-peering lain.
Jika Anda menginginkan akses langsung dari jaringan yang di-peering lain atau dari lokal saat menggunakan arsitektur hub-and-spoke, deploy proxy untuk traffic bidang kontrol.
Membatasi traffic cluster menggunakan kebijakan jaringan
Beberapa tingkat keamanan jaringan dapat diterapkan untuk workload cluster yang dapat digabungkan: aturan firewall VPC, kebijakan firewall Hierarkis, dan kebijakan jaringan Kubernetes. Aturan firewall VPC dan Kebijakan firewall hierarkis berlaku di tingkat virtual machine (VM), yaitu node pekerja tempat Pod cluster GKE berada. Kebijakan jaringan Kubernetes berlaku di level Pod untuk menerapkan jalur traffic Pod ke 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 di layanan. Anda dapat menggunakan firewall VPC untuk mengonfigurasi kebijakan ingress agar layanan dapat 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 yang membatasi.
Mengaktifkan kebijakan keamanan Google Cloud Armor untuk Ingress
Dengan 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 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. 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.
Gunakan Akses Google Pribadi untuk mengakses layanan Google.
Menggunakan Cloud DNS untuk GKE
Anda dapat menggunakan Cloud DNS untuk GKE untuk menyediakan resolusi DNS Pod dan 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 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 apa pun. 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
Secara default, cluster dengan node pribadi yang diaktifkan 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 Cloud NAT Gateway berikut saat menggunakan Cloud NAT untuk cluster:
- 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 mengaloksir jumlah port yang berbeda per VM, berdasarkan penggunaan VM. Mulai dengan port minimum 64 dan port maksimum 2048.
Jika Anda perlu mengelola banyak koneksi simultan ke 3-tuple tujuan yang sama, turunkan waktu tunggu TCP
TIME_WAITdari nilai defaultnya120smenjadi5s. 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 masalah penurunan status alokasi, Anda mungkin perlu meningkatkan jumlah maksimum port per VM.
Anda harus menghindari SNAT ganda untuk traffic Pod (SNAT terlebih dahulu di node GKE, lalu dengan Cloud NAT lagi). Kecuali jika Anda memerlukan SNAT untuk menyembunyikan alamat IP Pod ke jaringan lokal yang terhubung oleh Cloud VPN atau Cloud Interconnect, disable-default-snat, dan mengurangi beban pelacakan SNAT ke Cloud NAT untuk skalabilitas. Solusi ini
berfungsi untuk semua rentang IP subnet primer dan sekunder. Menggunakan 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 dengan node 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 dengan node 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 native 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 CRD BackendConfig untuk menggunakan fungsi health check Load Balancer Aplikasi eksternal. Anda dapat mengarahkan health check ke endpoint yang sesuai dan menetapkan nilai minimum Anda sendiri. Tanpa BackendConfig CRD, health check akan 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 dari 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 di
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.
Gunakan Cloud Logging dan Cloud Monitoring serta aktifkan 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.createcompute.firewalls.getcompute.firewalls.listcompute.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 sebaik mungkin jika terjadi kegagalan zona, gunakan autoscaler cluster untuk memastikan bahwa 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.
Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi setelan ini untuk ketersediaan tinggi dan pengoptimalan biaya, lihat 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 dengan GKE Dataplane V2. Logging kebijakan jaringan memberikan visibilitas terkait penerapan kebijakan dan pola traffic Pod. Perhatikan 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. Pemantauan menyediakan dasbor untuk cluster GKE Anda. Logging juga mengaktifkan anotasi GKE untuk Log Aliran VPC. Secara default, Logging mengumpulkan log untuk semua workload yang di-deploy ke cluster, tetapi opsi log khusus sistem juga tersedia. Gunakan dasbor GKE untuk mengamati dan menyetel pemberitahuan. Untuk cluster yang dibuat dalam mode Autopilot, pemantauan dan logging diaktifkan secara otomatis dan tidak dapat dikonfigurasi.
Perhatikan bahwa ada biaya yang diperlukan untuk Google Cloud Observability.