Mempelajari arsitektur jaringan GKE

Jaringan Google Kubernetes Engine (GKE) menggunakan dan memperluas infrastruktur software-defined networking (SDN) yang disediakan oleh Virtual Private Cloud (VPC). Jaringan GKE memungkinkan komponen Anda berkomunikasi dalam cluster Kubernetes dan dengan layanan serta jaringan eksternal. Model jaringan GKE dibangun berdasarkan prinsip jaringan Kubernetes—di mana setiap Pod mendapatkan alamat IP-nya sendiri—untuk menyediakan pengalamatan IP, load balancing, resolusi DNS, dan penerapan kebijakan jaringan. Dokumen ini menjelaskan cara komponen inti seperti node, Pod, dan Layanan berinteraksi dengan bidang kontrol dalam konteks jaringan GKE, yang mencakup hal berikut:

• Cara komponen ini berinteraksi dalam VPC Anda
• Cara alamat IP dialokasikan dan dikelola
• Cara traffic masuk, berada di dalam, dan keluar dari cluster

Arsitektur jaringan GKE

Jaringan GKE dibangun di atas Virtual Private Cloud (VPC) Cloud de Confiance by S3NS. Dasar ini menyediakan konektivitas yang andal dan skalabel untuk semua aplikasi yang di-container.

Dasar VPC dan rentang alamat IP

Dalam VPC, Anda menentukan subnet, yang merupakan rentang alamat IP regional. GKE secara strategis menggunakan rentang alamat IP yang berbeda dalam subnet ini untuk berbagai komponen cluster, sering kali menggunakan rentang alamat IP alias VPC:

• Rentang alamat IP node: ini adalah rentang alamat IP utama subnet tempat node cluster Anda di-deploy. Semua worker node GKE Anda, yang merupakan VM Compute Engine, mendapatkan alamat IP utamanya dari rentang ini. Alamat IP ini digunakan untuk komunikasi antar-node dan untuk pemeriksaan kondisi dari load balancer. Alamat IP node juga merupakan sumber traffic yang berasal dari node itu sendiri. Di cluster VPC native, traffic dari Pod menggunakan alamat IP Pod sebagai alamat sumber, kecuali jika alamat IP Pod diterjemahkan oleh fitur seperti Cloud NAT.
• Rentang alamat IP Pod: rentang alamat IP sekunder khusus, sering kali blok CIDR yang lebih besar, yang berada dalam subnet Anda. Setiap node menerima kumpulan alamat IP dari rentang ini. GKE menetapkan alamat IP ini ke Pod yang berjalan di node tersebut. Setiap Pod di cluster Anda mendapatkan alamat IP uniknya dari rentang ini. Alamat IP Pod ini dapat dirutekan secara native dalam Virtual Private Cloud Anda. Secara default, setiap node mendapatkan rentang /24, yang menyediakan 256 alamat IP. Namun, GKE membatasi jumlah maksimum Pod per node hingga 110. Buffer ini membantu memastikan ketersediaan alamat IP selama pembuatan dan penghapusan Pod yang cepat, yang juga dikenal sebagai churn. Alamat IP ini memungkinkan komunikasi langsung antar-Pod di seluruh node yang berbeda tanpa memerlukan Network Address Translation (NAT).
• Rentang alamat IP layanan (ClusterIP): rentang alamat IP sekunder untuk alamat IP virtual (ClusterIP) yang ditetapkan ke Layanan Kubernetes. Alamat IP stabil ini hanya digunakan untuk komunikasi dalam cluster.
• Alamat IP bidang kontrol: setiap bidang kontrol memiliki alamat IP publik atau internal, bergantung pada jenis cluster, versi, dan tanggal pembuatan. Alamat IP ini digunakan oleh node pekerja dan klien eksternal, seperti kubectl, untuk berkomunikasi secara aman dengan server Kubernetes API. Frontend GKE (GKFE) menyediakan endpoint berbasis DNS untuk setiap cluster, sehingga menawarkan cara yang aman dan andal untuk mengakses bidang kontrol tanpa mengelola alamat IP secara langsung.

Tiga pilar jaringan GKE

Jaringan GKE terdiri dari tiga pilar yang saling terhubung, yang masing-masing merepresentasikan lapisan komunikasi yang berbeda. Framework ini membantu Anda memahami cara aplikasi Anda berkomunikasi di dalam cluster dan dengan jaringan eksternal:

• Jaringan Pod: lapisan dasar, yang menentukan cara setiap penampung (Pod) berkomunikasi satu sama lain dalam cluster.
• Jaringan layanan: dibangun di atas jaringan Pod, lapisan ini menjelaskan cara Layanan Kubernetes menyediakan endpoint yang stabil untuk mengekspos aplikasi bagi klien internal atau eksternal, termasuk load balancing dan penemuan layanan.
• Jaringan cluster: lapisan terluar, yang mencakup cara seluruh cluster GKE Anda terhubung ke ekosistem jaringan yang lebih luas, termasuk mengelola ingress dari internet, egress ke layanan eksternal, dan konektivitas ke layanan Cloud de Confiance by S3NS dan sistem lokal.

Lapisan ini bekerja sama untuk membuat model komunikasi komprehensif yang mendukung konektivitas, keamanan, dan skalabilitas internal dan eksternal. Bagian berikut membahas setiap pilar secara mendetail.

Jaringan pod

Jaringan pod adalah fondasi untuk semua komunikasi dalam cluster GKE. Objek ini menentukan cara aplikasi yang berjalan di dalam Pod dapat menemukan dan berinteraksi satu sama lain. Di Kubernetes, Pod adalah unit terkecil dan paling dasar yang dapat di-deploy. Pod berfungsi sebagai host logis untuk aplikasi Anda. Pod menjalankan satu atau beberapa container yang berbagi resource jaringan. Saat Pod dijadwalkan di sebuah node, Kubernetes akan membuat namespace jaringan khusus untuk Pod tersebut di kernel Linux node, yang mengisolasi jaringannya dari Pod lain di node yang sama.

Cara kerja jaringan Pod

Jaringan pod dibuat melalui kombinasi alamat IP unik, perangkat jaringan virtual, dan plugin khusus yang mengelola konektivitas.

Container Network Interface (CNI): GKE menggunakan plugin CNI untuk menerapkan dan mengelola jaringan Pod. Untuk cluster VPC native, CNI default adalah Google CNI. Opsi lainnya mencakup kubenet (untuk cluster non-berbasis VPC), Calico, dan GKE Dataplane V2 (yang berbasis Cilium). Plugin ini bertanggung jawab untuk menghubungkan Pod ke jaringan dan menerapkan kebijakan jaringan.

• Alokasi alamat IP: setiap node menerima kumpulan alamat IP dari rentang alamat IP Pod untuk ditetapkan ke Pod. GKE mencadangkan sebagian alamat ini untuk membuat buffer yang memastikan ketersediaan alamat IP selama churn Pod yang cepat (pembuatan dan penghancuran). Reservasi ini menyebabkan jumlah alamat IP Pod yang dapat dialokasikan per node selalu lebih kecil daripada ukuran rentang.

• Namespace jaringan dan pasangan Ethernet virtual (veth): untuk memfasilitasi komunikasi, Kubernetes menghubungkan namespace jaringan terisolasi Pod ke namespace jaringan utama, atau root, node. Kubernetes membuat koneksi ini dengan menggunakan pasangan Ethernet virtual, atau pasangan veth, yang bertindak seperti kabel jaringan virtual. Salah satu ujung pasangan ditempatkan di dalam namespace Pod dan muncul sebagai eth0. Ujung lainnya terhubung ke jembatan jaringan atau langsung ke stack jaringan node di namespace root node, yang kemudian memungkinkan aliran paket ke dan dari Pod.

  Metode koneksi tertentu bergantung pada plugin CNI yang digunakan cluster Anda:

  • Google CNI: ini adalah CNI default untuk cluster VPC native. Pasangan veth Pod terhubung ke namespace jaringan root node. Karena alamat IP Pod adalah alamat IP alias yang diketahui oleh jaringan VPC, perutean Linux standar di node mengarahkan traffic ke dan dari Pod.
  • GKE Dataplane V2: menggunakan program eBPF untuk menangani jaringan Pod dan sering kali melewati jembatan Linux konvensional dan pasangan veth untuk mengelola alur paket secara langsung dalam kernel untuk performa yang lebih tinggi.
  • Kubenet: digunakan di cluster non-VPC native. Ujung lain dari pasangan veth terhubung ke perangkat bridge Linux yang disebut cbr0 di namespace root node. Jembatan ini mengelola traffic antar-Pod di node yang sama dan menggunakan NAT untuk traffic yang meninggalkan node.
  • Calico: saat kebijakan jaringan diaktifkan dengan Calico, ujung lain dari pasangan veth terhubung ke namespace root node, dan Calico kemudian memprogram rute host untuk mengarahkan traffic ke Pod yang benar.

Unit Transmisi Maksimum (MTU): ini menentukan ukuran paket terbesar yang dapat dikirim melalui jaringan tanpa difragmentasi. Di GKE, MTU untuk antarmuka Pod adalah setelan penting yang bergantung pada plugin CNI GKE yang digunakan cluster dan setelan MTU dari jaringan VPC yang mendasarinya. Ketidakcocokan nilai MTU dapat menyebabkan paket hilang atau penurunan performa. Nilai MTU antarmuka Pod adalah 1460 byte tetap atau diwarisi dari antarmuka jaringan utama node, seperti yang ditunjukkan dalam tabel berikut.

Alur komunikasi Pod-to-Pod

Kubernetes menggunakan model jaringan datar, di mana setiap Pod memiliki alamat IP yang unik dan dapat dirutekan. Model ini membantu memastikan konektivitas yang lancar antar-Pod.

Komunikasi dalam node yang sama

Saat Pod mengirim traffic ke Pod lain di node yang sama, permintaan akan mengalir dari namespace jaringan Pod pertama, melalui pasangan veth-nya, dan ke namespace jaringan root node. Traffic ini tetap berada di dalam node. Bergantung pada plugin CNI yang digunakan, plugin CNI kemudian meneruskan traffic ke pasangan veth Pod kedua. Misalnya, dengan kubenet, perangkat perantara meneruskan traffic. Dengan GKE Dataplane V2, program eBPF mengelola aliran paket secara langsung.

Komunikasi antar-node yang berbeda

Saat Pod di satu node mengirim traffic ke Pod di node lain, traffic akan mengalir ke namespace jaringan root node pertama. Traffic kemudian keluar dari antarmuka jaringan utama node pertama dan masuk ke jaringan VPC. Karena alamat IP Pod dapat dirutekan secara native di cluster GKE VPC native, jaringan VPC merutekan traffic langsung ke node kedua. Kemudian, node kedua meneruskan traffic ke Pod tujuan.

Pod jaringan host

Untuk kasus penggunaan tertentu, Anda dapat mengonfigurasi Pod dengan setelan hostNetwork: true. Setelan ini melewati jaringan Pod terisolasi dan memungkinkan Pod berbagi namespace jaringan node secara langsung. Dengan akses langsung ini, Pod menggunakan alamat IP node dan dapat berkomunikasi dengan semua Pod lain tanpa memerlukan NAT. Di cluster yang menggunakan plugin CNI kubenet, perilaku ini berbeda dengan Pod biasa. Pod Reguler memerlukan NAT untuk traffic keluar karena alamat IP-nya tidak dapat dirutekan secara langsung di jaringan VPC. Sebaliknya, jaringan VPC native GKE membuat terjemahan ini tidak diperlukan untuk semua Pod. Namun, saat mengonfigurasi Pod dengan setelan hostNetwork: true, berhati-hatilah untuk menghindari konflik port dengan proses atau Pod lain yang berjalan di node yang sama. Di cluster yang menggunakan CNI kubenet, jembatan jaringan virtual cbr0 hanya dibuat jika node memiliki Pod yang memiliki setelan hostNetwork: false.

Service Networking

Meskipun jaringan Pod menyediakan konektivitas mendasar antara Pod individual, hal ini tidak cukup untuk membangun aplikasi yang andal dan skalabel. Pod bersifat sementara; Pod dapat dibuat, dihancurkan, dan dijadwalkan ulang kapan saja. Situasi ini menyebabkan alamat IP mereka berubah. Jaringan layanan memecahkan masalah ini dengan menyediakan cara yang stabil dan andal untuk mengekspos aplikasi dan mengelola cara aplikasi berkomunikasi, baik di dalam cluster maupun dengan dunia luar.

Layanan Kubernetes adalah abstraksi yang mendefinisikan kumpulan logis Pod dan kebijakan untuk mengaksesnya. Service menggunakan label untuk mengelompokkan beberapa Pod terkait ke dalam satu unit logis. Saat Anda membuat Service, Kubernetes akan menetapkan alamat IP virtual yang stabil, yang dikenal sebagai ClusterIP, dari kumpulan alamat yang dicadangkan untuk Service. ClusterIP ini, beserta nama DNS terkait, tetap konstan selama seluruh siklus proses Service, sehingga menyediakan endpoint yang konsisten yang dapat digunakan aplikasi lain untuk terhubung ke Pod.

Cara kerja Jaringan layanan

Jaringan layanan mengandalkan dua mekanisme utama untuk merutekan traffic dari endpoint stabil Layanan ke Pod backend dinamisnya: penemuan layanan dan load balancing.

Penemuan layanan: agar aplikasi dapat saling menemukan dan berkomunikasi, GKE menyediakan layanan DNS internal (baik kube-dns maupun Cloud DNS). Saat Anda membuat Layanan, layanan DNS akan otomatis membuat data DNS yang sesuai. Data ini memungkinkan aplikasi terhubung ke Layanan menggunakan nama DNS-nya (misalnya, my-app-service), bukan harus mengetahui ClusterIP-nya. Meskipun kube-dns adalah default untuk cluster Standard, Cloud DNS untuk GKE adalah solusi yang direkomendasikan untuk sebagian besar lingkungan produksi. Solusi ini juga merupakan satu-satunya solusi yang didukung untuk cluster Autopilot GKE. Layanan ini terkelola sepenuhnya, skalabel, dan sangat tersedia. Layanan ini terintegrasi dengan jaringan VPC dan Cloud Logging, sehingga menawarkan performa dan kemampuan pengamatan yang lebih baik tanpa mengharuskan Anda mengelola Pod kube-dns.

Mekanisme load balancing: penerapan load balancing Service bergantung pada mode jaringan cluster GKE Anda.

• GKE Dataplane V2: cluster yang menggunakan GKE Dataplane V2 (yang berbasis Cilium) tidak menggunakan kube-proxy untuk load balancing Service. Sebagai gantinya, GKE Dataplane V2 menggunakan program eBPF yang berjalan di kernel Linux. Program eBPF ini sangat efisien dalam mencegat traffic ke ClusterIP Service dan langsung melakukan load balance traffic ke Pod backend yang sesuai. Pendekatan ini menghasilkan performa yang lebih baik dan terintegrasi erat dengan kemampuan penerapan kebijakan jaringan GKE Dataplane V2.

• kube-proxy (untuk cluster tanpa GKE Dataplane V2): di setiap node dalam cluster GKE yang tidak menggunakan GKE Dataplane V2, komponen yang disebut kube-proxy menerapkan mekanisme alamat IP virtual untuk Layanan. kube-proxy memantau perubahan pada Layanan dan Endpoint di server Kubernetes API, lalu memprogram aturan jaringan di node untuk mencegat traffic yang ditujukan ke ClusterIP Layanan.

  kube-proxy dapat beroperasi dalam berbagai mode, termasuk yang berikut:

  • Mode iptables: ini adalah mode default. kube-proxy menambahkan dan menghapus aturan Network Address Translation (NAT) Tujuan (DNAT) di subsistem iptables node. Saat traffic tiba untuk ClusterIP Service, aturan ini akan melakukan terjemahan NAT dan mengubah alamat IP tujuan menjadi salah satu Pod backend yang responsif. Load balancing di seluruh Pod backend biasanya bersifat acak atau round-robin.
  • Mode ipvs: mode ini menggunakan IP Virtual Server (IPVS) Linux untuk load balancing berperforma tinggi. kube-proxy mengonfigurasi aturan IPVS, yang dapat menangani sejumlah besar layanan dan menyediakan algoritma load balancing yang lebih canggih.

Contoh alur komunikasi internal

Daftar berikut menjelaskan alur permintaan dari Pod klien ke Pod server menggunakan Layanan di cluster yang tidak menggunakan GKE Dataplane V2:

1. Aplikasi klien membuat kueri DNS untuk my-server-service.
2. Layanan DNS internal cluster me-resolve nama ini ke ClusterIP stabil Service (misalnya, 10.0.32.8).
3. Pod klien mengirimkan permintaan ke ClusterIP Service.
4. Aturan iptables pada node klien, yang dikelola oleh kube-proxy, mencegat permintaan ini.
5. Aturan iptables ini menjalankan DNAT dan memilih salah satu Pod backend yang sehat untuk my-server-service (misalnya, Pod 2 dengan alamat IP 10.4.0.3). Aturan ini juga menulis ulang alamat IP tujuan paket ke alamat IP Pod.
6. Paket dirutekan melalui jaringan Pod datar ke Pod 2, yang memproses permintaan.

Di cluster yang menggunakan GKE Dataplane V2, program eBPF menangani pencegatan dan load balancing traffic ke ClusterIP Layanan, dengan melewati kube-proxy dan iptables.

Contoh manifes Layanan

Contoh berikut menunjukkan manifes Service. Kolom selector menentukan Pod mana yang menerima traffic berdasarkan labelnya.

apiVersion: v1
kind: Service
metadata:
  name: my-server-service
spec:
  selector:
    app: my-server # This should match the labels on your server Pods
  ports:
  - protocol: TCP
    port: 80 # The port the Service exposes
    targetPort: 8080 # The port the containers in the Pods are listening on

Fitur Service Networking

Jaringan Layanan GKE menawarkan beberapa fitur untuk mengelola alur traffic dan mengekspos aplikasi, baik secara internal maupun eksternal.

• Load balancing internal dan eksternal. Untuk Layanan yang hanya perlu diakses dari dalam cluster, kube-proxy (atau GKE Dataplane V2) menangani load balancing secara internal. Untuk Layanan yang perlu diekspos ke internet, GKE secara otomatis menyediakan load balancer cloud untuk mendistribusikan traffic eksternal ke node dalam cluster.
• Load Balancer Aplikasi untuk perutean HTTP(S). Untuk traffic HTTP(S), GKE menggunakan load balancer Lapisan 7 khusus, yaitu Load Balancer Aplikasi. Anda mengonfigurasi load balancer ini menggunakan Kubernetes Gateway API, yang merupakan pendekatan yang direkomendasikan untuk semua aplikasi baru. Pengontrol Gateway GKE adalah implementasi Google untuk Gateway API dan dirancang untuk menjadi penerus yang lebih ekspresif, fleksibel, dan dapat di-extend untuk resource Ingress. Gateway API menggunakan resource berikut untuk mengonfigurasi load balancer:
  • Gateway: menentukan konfigurasi pemroses seperti port, protokol, dan nama host. Objek ini berfungsi sebagai titik masuk untuk traffic.
  • HTTPRoute: menentukan cara traffic yang diterima oleh Gateway dirutekan ke Layanan. Traffic Director mendukung fitur lanjutan seperti perutean berbasis jalur, pencocokan header, dan pemisahan traffic.
  • Kebijakan: menentukan fungsi infrastruktur Cloud de Confiance by S3NS yang mendasarinya dengan dilampirkan ke Gateway, Rute, atau Layanan.
• Integrasi mesh layanan. Untuk arsitektur microservice yang kompleks, GKE mendukung teknologi mesh layanan. Mesh layanan adalah lapisan infrastruktur opsional yang menyediakan fitur lanjutan untuk pengelolaan traffic, kemampuan observasi, dan keamanan. Untuk pengalaman yang terkelola sepenuhnya dan didukung, GKE menawarkan Cloud Service Mesh, yang dibangun di atas Istio.

Jaringan cluster

Jaringan cluster adalah lapisan terluar dari jaringan GKE. Bagian ini berfokus pada cara seluruh cluster Kubernetes Anda berinteraksi dengan resource dan jaringan eksternal, termasuk cara klien internet menjangkau aplikasi Anda, cara Pod Anda mengakses API eksternal, dan cara cluster Anda terhubung ke pusat data lokal. Jaringan cluster dibangun di atas infrastruktur VPC Cloud de Confiance by S3NS.

Mengelola traffic masuk

Ingress adalah traffic yang memasuki cluster Anda dari dunia luar. GKE menggunakan beberapa fitur terintegrasi Cloud de Confiance by S3NS untuk mengelola dan mengamankan traffic ini.

Alur data akses eksternal: saat klien dari internet mengirim permintaan ke aplikasi Anda (biasanya diekspos melalui Layanan berjenis LoadBalancer atau resource Ingress atau Gateway), permintaan tersebut akan mencapai load balancer Cloud de Confiance by S3NS terlebih dahulu. Load balancer merutekan permintaan ke node yang responsif di cluster Anda. Node meneruskan traffic ke Pod yang sesuai. kube-proxy menangani penerusan ini di cluster yang tidak menggunakan GKE Dataplane V2, atau program eBPF menanganinya di cluster yang menggunakan GKE Dataplane V2. Pod tujuan mungkin berada di node yang sama atau node yang berbeda.

Aturan firewall: Cluster GKE menggunakan aturan firewall VPC untuk mengontrol traffic masuk. Meskipun GKE secara otomatis membuat beberapa aturan firewall default untuk operasi cluster penting, seperti mengizinkan bidang kontrol menjangkau node, Anda dapat menentukan aturan kustom untuk memenuhi persyaratan keamanan spesifik Anda. Aturan firewall VPC ini berfungsi dengan Kebijakan Jaringan Kubernetes untuk memberikan pertahanan mendalam dengan mengontrol traffic di tingkat node dan Pod.

Mengoptimalkan alur traffic eksternal: saat load balancer mengirimkan traffic ke sebuah node, node tersebut mungkin perlu meneruskan traffic tersebut ke Pod di node yang berbeda, yang memerlukan hop jaringan tambahan. Untuk menghindari situasi ini, setel kolom externalTrafficPolicy ke Local dalam manifes Layanan Anda. Jika kebijakan ini aktif, load balancer akan menggunakan health check untuk mengidentifikasi node mana yang memiliki Pod responsif untuk Service target. Load balancer hanya mengirimkan traffic ke Pod yang responsif, sehingga mencegah hop jaringan tambahan. Kelemahannya adalah kebijakan ini dapat menyebabkan distribusi traffic yang tidak merata jika Pod backend Anda tidak didistribusikan secara merata di seluruh node dalam cluster Anda.

Mengelola traffic keluar

Egress adalah traffic yang keluar dari cluster Anda. Agar cluster GKE dapat berfungsi dan aplikasi Anda dapat menjangkau layanan eksternal, Anda harus mengelola beberapa jalur konektivitas.

Persyaratan konektivitas mendasar: semua cluster GKE memerlukan konektivitas keluar ke domain *.googleapis.com, *.gcr.io, dan *.pkg.dev. Konektivitas keluar ke alamat IP bidang kontrol juga harus berfungsi dengan benar. Akses internet untuk Pod menggunakan Cloud NAT: di cluster pribadi tempat Pod tidak memiliki alamat IP publik, gunakan Cloud NAT untuk mengaktifkan akses internet keluar. Cloud NAT adalah layanan terkelola yang memungkinkan Pod terhubung ke internet untuk tugas seperti mendownload update atau mengakses API eksternal tanpa mengekspos Pod ke koneksi masuk.

Konektivitas ke Cloud de Confiance by S3NS Layanan: jika Anda perlu mengizinkan cluster Anda berkomunikasi secara aman dengan layanan Cloud de Confiance by S3NS lain, seperti Cloud Storage atau Cloud SQL, tanpa melintasi internet publik, gunakan Private Google Access. Ini adalah mekanisme keluar yang penting untuk cluster pribadi yang berinteraksi dengan Google API.

Konektivitas hybrid dan multi-cluster

Untuk menghubungkan cluster GKE Anda ke infrastruktur lokal, gunakan Cloud VPN untuk tunnel terenkripsi atau Cloud Interconnect untuk koneksi ber-bandwidth tinggi khusus. Untuk mengaktifkan komunikasi antara beberapa cluster GKE, gunakan Layanan Multi-cluster, yang memfasilitasi penemuan layanan dan alur traffic di berbagai cluster, region, atau project.

Kontrol keamanan jaringan

Untuk melindungi cluster dan aplikasi yang berjalan di dalamnya, GKE menyediakan beberapa lapisan kontrol keamanan untuk traffic internal (east-west) dan eksternal (north-south).

Mengamankan traffic internal (timur-barat) dengan kebijakan jaringan

Secara default, semua Pod dalam cluster GKE dapat berkomunikasi dengan bebas satu sama lain. Untuk mengamankan traffic internal dan menerapkan prinsip hak istimewa terendah, Anda dapat menggunakan NetworkPolicy. NetworkPolicy adalah resource Kubernetes yang bertindak sebagai firewall untuk Pod Anda dengan mengontrol traffic jaringan di antara Pod. Resource NetworkPolicy memungkinkan Anda menentukan aturan untuk membatasi traffic ingress dan egress untuk sekelompok Pod yang dipilih berdasarkan kombinasi label, rentang alamat IP, dan nomor port. Saat Anda membuat NetworkPolicy pertama di namespace, semua traffic yang tidak diizinkan secara eksplisit oleh kebijakan tersebut akan ditolak. Penerapan kebijakan ini dibuat langsung ke GKE Dataplane V2, atau ditangani oleh plugin CNI cluster, seperti Calico.

Contoh manifes NetworkPolicy

Contoh berikut menunjukkan manifes NetworkPolicy. Kebijakan ini berlaku untuk Pod dengan label app: backend dan hanya mengizinkan traffic masuk dari Pod yang memiliki label app: frontend di port TCP 6379.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 6379

Mengamankan akses eksternal ke cluster

Mengontrol traffic yang masuk dan keluar dari cluster sangat penting untuk melindungi aplikasi Anda dari ancaman eksternal.

Aturan firewall VPC

Cluster GKE berada dalam jaringan Cloud de Confiance by S3NS VPC dan dilindungi oleh aturan firewall VPC yang mengontrol traffic ke dan dari node cluster. Aturan firewall VPC dan kebijakan jaringan bekerja sama untuk memberikan pertahanan mendalam. Firewall VPC beroperasi di tingkat node (Lapisan 3 atau Lapisan 4), dan mengontrol traffic ke VM itu sendiri. Kebijakan jaringan beroperasi di tingkat Pod (Lapisan 3 atau Lapisan 4), dan memberikan kontrol yang lebih terperinci atas traffic antar-aplikasi di dalam cluster.

Membatasi akses ke load balancer

Saat mengekspos aplikasi menggunakan Layanan atau Ingress Kubernetes, Anda dapat menerapkan kontrol keamanan tambahan di tingkat load balancer. Untuk load balancer eksternal, pertimbangkan opsi berikut:

• Jika mengekspos Service menggunakan kolom type: LoadBalancer, Anda dapat menentukan kolom loadBalancerSourceRanges dalam manifes Service. Kolom ini membatasi akses ke Layanan hanya untuk rentang alamat IP yang Anda tentukan.

• Untuk load balancer aplikasi (Ingress), Anda dapat menggunakan layanan keamanan yang lebih canggih saat menampilkan aplikasi HTTP(S):

  • Google Cloud Armor: layanan ini adalah firewall aplikasi web (WAF) yang membantu melindungi aplikasi Anda dari serangan DDoS dan ancaman berbasis web lainnya.
  • Identity-Aware Proxy (IAP): untuk kontrol akses terperinci, Anda dapat mengaktifkan IAP di endpoint. IAP memverifikasi identitas pengguna dan menggunakannya untuk menentukan apakah pengguna harus diizinkan untuk mengakses aplikasi.

Langkah berikutnya

• Pelajari cara membuat cluster VPC native.
• Baca selengkapnya tentang GKE Dataplane V2.
• Terapkan kebijakan jaringan untuk mengamankan komunikasi Pod-ke-Pod.
• Pelajari berbagai cara untuk mengekspos aplikasi menggunakan Layanan dan mengonfigurasi Ingress dengan Gateway API.