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 dibuat berdasarkan prinsip jaringan Kubernetes—di mana setiap Pod mendapatkan alamat IP-nya sendiri—untuk menyediakan alamat IP, load balancing, resolusi DNS, dan penerapan kebijakan jaringan. Dokumen ini menjelaskan cara komponen inti seperti node, Pod, dan Service 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 mengalir ke dalam, di dalam, dan ke luar cluster

Arsitektur jaringan GKE

Jaringan GKE dibangun di atas Virtual Private Cloud (VPC) Cloud de Confiance by S3NS. Fondasi ini menyediakan konektivitas yang tangguh dan skalabel untuk semua aplikasi dalam container Anda.

Dasar-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 health check 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 berupa 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 Service (ClusterIP): rentang alamat IP sekunder untuk alamat IP virtual (ClusterIP) yang ditetapkan ke Service Kubernetes. Alamat IP stabil ini hanya digunakan untuk komunikasi di dalam cluster.
• Alamat IP bidang kontrol: setiap bidang kontrol memiliki alamat IP publik atau IP 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, yang 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 akan membahas setiap pilar secara mendetail.

Jaringan pod

Jaringan pod adalah fondasi untuk semua komunikasi dalam cluster GKE. Layanan 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 mengimplementasikan dan mengelola jaringan Pod. Untuk cluster VPC native, defaultnya 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 membantu 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 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 bridge 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 keluar dari 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.

Maximum Transmission Unit (MTU): menentukan ukuran paket terbesar yang dapat dikirim melalui jaringan tanpa terfragmentasi. 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 ke Pod

Kubernetes menggunakan model jaringan datar, yang setiap Pod-nya memiliki alamat IP unik yang 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 jembatan 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 meninggalkan antarmuka jaringan utama node pertama dan memasuki jaringan VPC. Karena alamat IP Pod dapat dirutekan secara native di cluster GKE VPC native, jaringan VPC merutekan traffic langsung ke node kedua. Node kedua kemudian 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 dasar antara setiap Pod, jaringan ini tidak cukup untuk membangun aplikasi yang tangguh dan skalabel. Pod bersifat sementara; Pod dapat dibuat, dihancurkan, dan dijadwalkan ulang kapan saja. Situasi ini menyebabkan alamat IP-nya berubah. Jaringan layanan menyelesaikan 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 menentukan 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 Service 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 Service menggunakan nama DNS-nya (misalnya, my-app-service) tanpa perlu 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 dengan tingkat ketersediaan tinggi. Layanan ini terintegrasi dengan jaringan VPC dan Cloud Logging, sehingga menawarkan performa dan kemampuan observasi yang lebih baik tanpa mengharuskan Anda mengelola Pod kube-dns.

Mekanisme load balancing: penerapan load balancing Layanan 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 mengimplementasikan 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 Destination NAT (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 cara permintaan mengalir dari Pod klien ke Pod server menggunakan Service dalam 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 mengirim permintaan ke ClusterIP Service.
4. Aturan iptables di node klien, yang dikelola oleh kube-proxy, mencegat permintaan ini.
5. Aturan iptables ini menjalankan DNAT dan memilih salah satu Pod backend yang responsif 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 intersepsi dan load balancing traffic ke ClusterIP Service, dengan mengabaikan kube-proxy dan iptables.

Contoh manifes Service

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 Service GKE menawarkan beberapa fitur untuk mengelola aliran 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 Service yang perlu diekspos ke internet, GKE 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 resource Ingress yang lebih ekspresif, fleksibel, dan dapat di-extend. Gateway API menggunakan resource berikut untuk mengonfigurasi load balancer:
  • Gateway: menentukan konfigurasi pemroses seperti port, protokol, dan nama host. Fungsinya sebagai titik entri untuk traffic.
  • HTTPRoute: menentukan cara traffic yang diterima oleh Gateway dirutekan ke Service. Load balancer ini mendukung fitur lanjutan seperti pemilihan rute 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 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 defense in depth dengan mengontrol traffic di level 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, tetapkan 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 dasar: 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 mengeksposnya ke koneksi masuk.

Konektivitas ke Layanan Cloud de Confiance by S3NS : 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 Akses Google Pribadi. Ini adalah mekanisme egress 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 khusus dengan bandwidth tinggi. 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 tersebut. 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 defense in depth. 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 di antara 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 Layanan menggunakan kolom type: LoadBalancer, Anda dapat menentukan kolom loadBalancerSourceRanges dalam manifes Layanan. 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.

CNI Kustom

GKE menawarkan opsi CNI yang didukung secara native, termasuk Google CNI default, Calico, dan GKE Dataplane V2. Meskipun CNI kustom pihak ketiga lainnya mungkin berfungsi di cluster Anda, GKE tidak mendukungnya secara resmi. Menggunakan CNI kustom mengharuskan Anda mengelola konfigurasinya dan memecahkan masalah yang mungkin terjadi.

Jika CNI kustom terdeteksi di cluster Anda, GKE memberikan Rekomendasi yang menyarankan Anda untuk menghapusnya guna membantu memastikan konfigurasi yang didukung. Untuk kasus penggunaan mesh layanan, penginstalan Istio kustom juga dianggap tidak didukung; sebaiknya gunakan Cloud Service Mesh.

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 Service dan mengonfigurasi Ingress dengan Gateway API.