Log Aliran VPC

Log Aliran VPC mencatat sampel aliran jaringan yang dikirim dari dan diterima oleh instance VM, termasuk instance yang digunakan sebagai node Google Kubernetes Engine. Log ini dapat digunakan untuk pemantauan jaringan, forensik, analisis keamanan real-time, dan pengoptimalan biaya.

Anda dapat melihat log aliran di Cloud Logging, dan mengekspornya ke tujuan mana pun yang didukung oleh ekspor Cloud Logging.

Log aliran digabungkan berdasarkan koneksi dari VM Compute Engine dan diekspor secara real time. Dengan berlangganan Pub/Sub, Anda dapat menganalisis log aliran menggunakan API streaming real-time.

Properti utama

• Log Aliran VPC merupakan bagian dari Andromeda, software yang mendukung jaringan VPC. Dengan Log Aliran VPC, penundaan atau penalti performa dapat dihindari saat diaktifkan.
• Log Aliran VPC berfungsi dengan jaringan VPC, bukan jaringan lama. Anda mengaktifkan atau menonaktifkan Log Aliran VPC per subnet. Jika diaktifkan untuk subnet, Log Aliran VPC akan mengumpulkan data dari semua instance VM di subnet tersebut.
• Log Aliran VPC mengambil sampel setiap aliran VM yang meliputi TCP, UDP, ICMP, ESP, dan GRE. Sampel meliputi aliran masuk maupun keluar. Aliran ini dapat berada di antara VM dan VM lain, host di pusat data lokal, layanan Google, atau host di internet. Jika aliran diambil dengan pengambilan sampel, Log Aliran VPC akan menghasilkan log untuk aliran tersebut. Setiap data aliran mencakup informasi yang dijelaskan di bagian Format data.
• Log Aliran VPC berinteraksi dengan aturan firewall dengan cara berikut:
  • Paket keluar diambil sampelnya sebelum aturan firewall keluar. Meskipun aturan firewall keluar menolak paket keluar, paket tersebut dapat diambil sampelnya oleh Log Aliran VPC.
  • Paket masuk diambil sampelnya setelah aturan firewall masuk. Jika aturan firewall masuk menolak paket masuk, paket tersebut tidak akan diambil sampelnya oleh Log Aliran VPC.
• Anda dapat menggunakan filter di Log Aliran VPC untuk menghasilkan log tertentu saja.
• Log Aliran VPC mendukung VM yang memiliki beberapa antarmuka jaringan. Anda harus mengaktifkan Log Aliran VPC untuk setiap subnet, di setiap VPC, yang berisi antarmuka jaringan.
• Untuk mencatat aliran antara Pod pada node Google Kubernetes Engine (GKE) yang sama, Anda harus mengaktifkan visibilitas Intranode untuk cluster.

Kasus penggunaan

Pemantauan jaringan

Log Aliran VPC memberi Anda visibilitas real-time ke throughput dan performa jaringan. Anda dapat:

• Memantau jaringan VPC
• Melakukan diagnosis jaringan
• Memfilter log aliran oleh VM dan oleh aplikasi untuk memahami perubahan traffic
• Memahami pertumbuhan traffic untuk memperkirakan kapasitas

Memahami penggunaan jaringan dan mengoptimalkan biaya traffic jaringan

Anda dapat menganalisis penggunaan jaringan dengan Log Aliran VPC. Anda dapat menganalisis aliran jaringan untuk hal berikut:

• Traffic antara region dan zona
• Memperkirakan traffic ke negara tertentu di internet
• Pembicara teratas

Berdasarkan analisis tersebut, Anda dapat mengoptimalkan biaya traffic jaringan.

Forensik jaringan

Anda dapat menggunakan Log Aliran VPC untuk forensik jaringan. Misalnya, jika terjadi insiden, Anda dapat memeriksa hal berikut:

• IP mana yang berinteraksi dengan siapa dan kapan
• Setiap IP yang disusupi dengan menganalisis semua aliran jaringan yang masuk dan keluar

Analisis keamanan real-time

Anda dapat memanfaatkan API streaming real-time (melalui Pub/Sub), dan berintegrasi dengan sistem SIEM (Informasi Keamanan dan Manajemen Peristiwa). Hal ini dapat memberikan pemantauan real-time, korelasi peristiwa, analisis, dan notifikasi keamanan.

Pengumpulan log

Log aliran akan dikumpulkan untuk setiap koneksi VM pada interval tertentu. Semua paket yang dikumpulkan selama interval tertentu untuk koneksi tertentu akan digabungkan selama jangka waktu tertentu (interval agregasi) ke dalam satu entri log aliran. Data ini kemudian dikirim ke Logging.

Log disimpan di Logging selama 30 hari secara default. Jika ingin menyimpan log lebih lama dari itu, Anda dapat menetapkan periode retensi data kustom atau mengekspornya ke file yang didukung.

Pengambilan sampel dan pemrosesan log

Google Cloud mengambil sampel paket yang keluar dan masuk VM untuk membuat log aliran. Tidak setiap paket dicatat ke dalam data log-nya sendiri. Sekitar 1 dari setiap 30 paket dicatat, tetapi frekuensi pengambilan sampel ini mungkin lebih rendah yang bergantung pada beban VM. Anda tidak dapat menyesuaikan frekuensi ini.

Setelah log aliran dibuat, Google Cloud akan memprosesnya sesuai dengan prosedur berikut:

1. Pemfilteran: Anda dapat menentukan bahwa hanya log yang cocok dengan kriteria yang ditentukan yang akan dibuat. Misalnya, Anda dapat memfilter sehingga hanya log untuk VM tertentu atau hanya log dengan nilai metadata tertentu yang dibuat dan sisanya akan dihapus. Untuk mengetahui informasi lebih lanjut, lihat Pemfilteran log.
2. Agregasi: Informasi untuk paket yang diambil sampelnya digabungkan melalui interval agregasi yang dapat dikonfigurasi untuk menghasilkan entri log aliran.
3. Pengambilan sampel log aliran: Ini adalah proses pengambilan sampel kedua. Entri log aliran diambil sampelnya lebih lanjut sesuai dengan parameter frekuensi sampel yang dapat dikonfigurasi.
4. Metadata: Jika dinonaktifkan, semua anotasi Metadata akan dihapus. Jika ingin menyimpan metadata, Anda dapat menentukan bahwa semua kolom atau serangkaian kolom yang ditentukan akan dipertahankan. Untuk mengetahui informasi selengkapnya, lihat anotasi metadata.
5. Penulisan ke Logging: Entri log akhir ditulis ke Cloud Logging.

Karena Log Aliran VPC tidak mencatat semua paket, Log Aliran VPC akan mengompensasi paket yang terlewat dengan melakukan interpolasi dari paket yang dicatat. Hal ini terjadi untuk paket yang terlewat karena setelan pengambilan sampel awal dan yang dapat dikonfigurasi pengguna.

Meskipun Google Cloud tidak mencatat setiap paket, data log yang dicatat dapat berukuran cukup besar. Anda dapat menyeimbangkan visibilitas traffic dan kebutuhan biaya penyimpanan dengan menyesuaikan aspek pengumpulan log berikut:

• Interval agregasi: Paket yang diambil sampelnya selama interval waktu akan digabungkan ke dalam satu entri log. Interval waktu ini dapat berupa 5 detik (default), 30 detik, 1 menit, 5 menit, 10 menit, atau 15 menit.
• Frekuensi sampel: Sebelum ditulis ke Logging, jumlah log dapat diambil sampelnya untuk mengurangi jumlahnya. Secara default, volume entri log diskalakan sebesar 0,5 (50%), yang berarti bahwa separuh entri akan disimpan. Anda dapat menetapkannya dari 1.0 (100%, semua entri log disimpan) hingga 0.0 (0%, tidak ada log yang disimpan).
• Anotasi metadata: Secara default, entri log aliran dianotasi dengan informasi metadata, seperti nama VM sumber dan tujuan atau region geografis sumber dan tujuan eksternal. Anotasi metadata dapat dinonaktifkan, atau Anda dapat menentukan anotasi tertentu saja, untuk menghemat ruang penyimpanan.
• Pemfilteran: Secara default, log dihasilkan untuk setiap aliran di subnet. Anda dapat menyetel filter sehingga hanya log yang cocok dengan kriteria tertentu yang akan dibuat.

Anotasi metadata

Data log berisi kolom dasar dan kolom metadata. Bagian Format data mencantumkan kolom mana yang merupakan metadata jenis dan mana yang merupakan basis jenis. Semua kolom dasar selalu disertakan. Anda dapat menyesuaikan kolom metadata yang ingin disimpan.

• Jika Anda memilih semua metadata, semua kolom metadata dalam format data Log Aliran VPC disertakan dalam log aliran. Saat kolom metadata baru ditambahkan ke format data, log aliran akan otomatis menyertakan kolom baru.

• Jika Anda tidak memilih metadata, semua kolom metadata akan dihapus.

• Jika memilih metadata kustom, Anda dapat menentukan kolom metadata yang ingin disertakan oleh kolom induk, seperti src_vpc, atau dengan nama lengkapnya, seperti src_vpc.project_id

  Saat kolom metadata baru ditambahkan ke format data, log aliran tidak akan menyertakan kolom ini, kecuali kolom tersebut merupakan kolom baru dalam kolom induk yang telah Anda tentukan untuk disertakan.

  • Jika Anda menentukan metadata kustom menggunakan kolom induk, saat kolom metadata baru ditambahkan ke format data dalam kolom induk tersebut, log aliran akan otomatis menyertakan kolom baru tersebut.

  • Jika Anda menentukan metadata kustom menggunakan nama lengkap kolom, saat kolom metadata baru ditambahkan ke kolom induk, log aliran tidak akan menyertakan kolom baru tersebut.

Untuk mengetahui informasi tentang cara menyesuaikan kolom metadata, lihat petunjuk gcloud CLI atau API untuk mengaktifkan logging aliran VPC saat Anda membuat subnet.

Anotasi GKE

Aliran yang memiliki endpoint di Cluster GKE dapat dianotasi dengan anotasi GKE, yang dapat mencakup detail Cluster, Pod, dan Layanan endpoint.

Anotasi Layanan GKE

Traffic yang dikirim ke ClusterIP, NodePort, atau LoadBalancer dapat menerima anotasi Service. Jika dikirim ke NodePort atau LoadBalancer, aliran akan menerima anotasi Service pada kedua hop koneksi.

Traffic yang dikirim langsung ke port Service Pod dianotasi dengan anotasi Service pada endpoint tujuan.

Traffic yang dikirim ke port Service Pod tempat Pod mendukung lebih dari satu Service di port Service yang sama akan dianotasi dengan beberapa Service di endpoint tujuan. Hal ini terbatas untuk dua Service. Jika jumlahnya lebih dari itu, endpoint akan dianotasi dengan penanda MANY_SERVICES khusus.

Anotasi pod pada traffic internet

Traffic antara Pod dan internet tidak menerima anotasi Pod secara default. Untuk paket ke internet, agen penyamaran menerjemahkan alamat IP Pod ke alamat IP node sebelum Log Aliran VPC melihat paket tersebut. Dengan begitu, Log Aliran VPC tidak akan mengetahui hal apa pun tentang Pod dan tidak dapat menambahkan anotasi Pod.

Karena penyamaran, anotasi Pod hanya terlihat jika tujuannya berada dalam salah satu tujuan non-penyamaran default atau dalam daftar nonMasqueradeCIDRs kustom. Jika Anda menyertakan tujuan internet dalam daftar nonMasqueradeCIDRs kustom, Anda harus memberikan cara agar alamat IP Pod internal dapat diterjemahkan sebelum dikirimkan ke internet. Anda dapat menggunakan Cloud NAT, baik untuk cluster pribadi maupun non-pribadi. Lihat interaksi GKE untuk mengetahui detail selengkapnya.

Format data

Data log berisi kolom dasar, yang merupakan kolom inti dari setiap data log, dan kolom metadata yang menambahkan informasi tambahan. Kolom metadata dapat dihilangkan untuk menghemat biaya penyimpanan.

Beberapa kolom log menggunakan format multi-kolom, dengan lebih dari satu bagian data dalam kolom tertentu. Misalnya, kolom connection memiliki format IpConnection, yang berisi alamat IP dan port sumber dan tujuan, serta protokol, dalam satu kolom. Kolom multi-kolom ini dijelaskan di bawah tabel format data.

Format kolom IpConnection

Format kolom GkeDetails

Format kolom ClusterDetails

Format kolom PodDetails

Format kolom ServiceDetails

Contoh:

Jika ada dua layanan, kolom Service akan terlihat seperti ini:

service: [
 0: {
  service_name: "my-lb-service"
  service_namespace: "default"
 }
 1: {
  service_name: "my-lb-service2"
  service_namespace: "default"
 }
]

Jika ada lebih dari dua layanan, kolom Service akan terlihat seperti ini:

service: [
 0: {
  service_name: "MANY_SERVICES"
 }
]

Format kolom InstanceDetails

Format kolom GeographicDetails

Format kolom VpcDetails

Pemfilteran log

Saat mengaktifkan Log Aliran VPC, Anda dapat menetapkan filter berdasarkan kolom dasar dan metadata yang hanya menyimpan log yang cocok dengan filter. Semua log lainnya akan dihapus sebelum ditulis ke Logging, sehingga menghemat biaya Anda dan mengurangi waktu yang diperlukan untuk menemukan informasi yang Anda cari.

Anda dapat memfilter subset kolom mana pun dari Format data.

Pemfilteran Log Aliran VPC menggunakan CEL, bahasa ekspresi yang disematkan untuk ekspresi logika berbasis atribut. Ekspresi filter untuk Log Aliran VPC memiliki batas 2.048 karakter. Untuk mengetahui informasi selengkapnya, lihat Operator logika CEL yang didukung.

Untuk mengetahui informasi selengkapnya tentang CEL, lihat pengantar CEL dan definisi bahasa. Fitur filter pembuatan mendukung subset terbatas dari sintaksis CEL.

Untuk mengetahui informasi tentang cara membuat subnet yang menggunakan pemfilteran log, lihat petunjuk gcloud CLI atau API untuk Mengaktifkan Log Aliran VPC saat membuat subnet.

Untuk mengetahui informasi tentang cara mengonfigurasi pemfilteran log, lihat petunjuk gcloud CLI atau API untuk Memperbarui parameter Log Aliran VPC.

Contoh 1: Membatasi pengumpulan log ke VM tertentu yang bernama my-vm. Dalam kasus ini, hanya log dengan kolom src_instance seperti yang dilaporkan oleh sumber traffic adalah my-vm atau kolom dst_instance seperti yang dilaporkan oleh tujuan traffic adalh my-vm yang dicatat.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr="(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance.vm_name == 'my-vm' && reporter=='DEST')"

Contoh 2: Membatasi pengumpulan log ke paket yang alamat IP sumbernya berada di subnet 10.0.0.0/8.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr="inIpRange(connection.src_ip, '10.0.0.0/8')"

Contoh 3: Membatasi pengumpulan log ke traffic yang bersifat eksternal pada VPC.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr '!(has(src_vpc.vpc_name) && has(dest_vpc.vpc_name))'

Operator logika CEL yang didukung

Contoh pola traffic

Bagian ini menunjukkan cara kerja Log Aliran VPC untuk berbagai kasus penggunaan.

Aliran VM-ke-VM dalam jaringan VPC yang sama

Untuk aliran VM-ke-VM di jaringan VPC yang sama, log aliran dilaporkan dari VM yang meminta dan merespons, selama kedua VM berada di subnet yang mengaktifkan Log Aliran VPC. Dalam contoh ini, VM 10.10.0.2 mengirim permintaan dengan 1.224 byte ke VM 10.50.0.2, yang juga berada di subnet yang mengaktifkan logging. Selanjutnya, 10.50.0.2 akan merespons permintaan tersebut dengan balasan yang berisi 5.342 byte. Permintaan dan balasan dicatat dari VM yang meminta dan merespons.

Aliran VM-ke-alamat-IP-eksternal

Untuk aliran yang melintasi internet antara VM yang ada dalam jaringan VPC dan endpoint dengan alamat IP eksternal, log aliran dilaporkan dari VM yang ada di jaringan VPC saja:

• Untuk aliran keluar, log dilaporkan dari VM jaringan VPC yang merupakan sumber traffic.
• Untuk aliran masuk, log dilaporkan dari VM jaringan VPC yang merupakan tujuan traffic.

Dalam contoh ini, VM 10.10.0.2 bertukar paket melalui internet dengan endpoint yang memiliki alamat IP eksternal 203.0.113.5. Traffic keluar sebesar 1.224 byte yang dikirim dari 10.10.0.2 ke 203.0.113.5 dilaporkan dari VM sumber, 10.10.0.2. Traffic masuk sebesar 5.342 byte yang dikirim dari 203.0.113.5 ke 10.10.0.2 dilaporkan dari tujuan traffic, VM 10.10.0.2.

Aliran VM-ke-lokal

Untuk aliran antara VM yang ada di jaringan VPC dan endpoint lokal dengan alamat IP internal, log aliran dilaporkan dari VM yang ada di jaringan VPC saja:

• Untuk aliran keluar, log dilaporkan dari VM jaringan VPC yang merupakan sumber traffic.
• Untuk aliran masuk, log dilaporkan dari VM jaringan VPC yang merupakan tujuan traffic.

Dalam contoh ini, VM 10.10.0.2 dan endpoint lokal 10.30.0.2 terhubung melalui gateway VPN atau Cloud Interconnect. Traffic keluar sebesar 1.224 byte yang dikirim dari 10.10.0.2 ke 10.30.0.2 dilaporkan dari VM sumber, 10.10.0.2. Traffic masuk sebesar 5.342 byte yang dikirim dari 10.30.0.2 ke 10.10.0.2 dilaporkan dari tujuan traffic, VM 10.10.0.2.

Aliran VM-ke-VM untuk VPC Bersama

Untuk aliran VM-ke-VM untuk VPC Bersama, Anda dapat mengaktifkan Log Aliran VPC untuk subnet dalam project host. Misalnya, subnet 10.10.0.0/20 termasuk dalam jaringan VPC Bersama yang ditentukan dalam project host. Anda dapat melihat log aliran dari VM milik subnet ini, termasuk yang dibuat oleh project layanan. Dalam contoh ini, project layanan disebut "webserver", "recommendation", "database".

Untuk aliran VM-ke-VM, jika kedua VM berada di project yang sama, atau dalam kasus jaringan bersama, project host yang sama, anotasi untuk project ID, dan sejenisnya akan diberikan untuk endpoint lainnya dalam koneksi. Jika VM lain berada di project yang berbeda, anotasi untuk VM lainnya tidak akan diberikan.

Tabel berikut menunjukkan aliran seperti yang dilaporkan oleh 10.10.0.10 atau 10.10.0.20.

• src_vpc.project_id dan dest_vpc.project_id ditujukan untuk project host karena subnet VPC adalah milik project host.
• src_instance.project_id dan dest_instance.project_id ditujukan untuk project layanan karena instance termasuk dalam project layanan.

Project layanan tidak memiliki jaringan VPC Bersama dan tidak memiliki akses ke log aliran jaringan VPC Bersama.

Aliran VM-ke-VM untuk Peering Jaringan VPC

Kecuali jika kedua VM berada dalam project Google Cloud yang sama, aliran VM-ke-VM untuk jaringan VPC yang di-peering dilaporkan dengan cara yang sama seperti untuk endpoint eksternal—project dan informasi anotasi lain untuk VM lain tidak disediakan. Jika kedua VM berada di project yang sama, meskipun di jaringan yang berbeda, informasi project dan anotasi lainnya juga akan diberikan untuk VM lainnya.

Dalam contoh ini, subnet VM 10.10.0.2 di project analytics-prod dan VM 10.50.0.2 di project webserver-test terhubung melalui Peering Jaringan VPC. Jika Log Aliran VPC diaktifkan di produk analisis project, traffic (1.224 byte) yang dikirim dari 10.10.0.2 ke 10.50.0.2 dilaporkan dari VM 10.10.0.2, yang merupakan sumber aliran. Traffic (5342 byte) yang dikirim dari 10.50.0.2 ke 10.10.0.2 juga dilaporkan dari 10.10.0.2 VM, yang merupakan tujuan aliran.

Dalam contoh ini, Log Aliran VPC tidak diaktifkan di project webserver-test, sehingga tidak ada log yang dicatat oleh VM 10.50.0.2.

Aliran VM-ke-VM untuk Load Balancer Jaringan passthrough internal

Ketika Anda menambahkan VM ke layanan backend untuk Load Balancer Jaringan passthrough internal, Lingkungan Linux atau Windows Guest Environment akan menambahkan alamat IP load balancer ke server tabel perutean lokal VM. Hal ini memungkinkan VM menerima paket permintaan dengan tujuan yang ditetapkan ke alamat IP load balancer. Saat VM membalas, VM akan mengirimkan responsnya secara langsung. Namun, alamat IP sumber untuk paket respons ditetapkan ke alamat IP load balancer, bukan VM yang mengalami load balancing.

Aliran VM-ke-VM yang dikirim melalui Load Balancer Jaringan passthrough internal dilaporkan dari sumber dan tujuan. Untuk contoh pasangan respons/permintaan HTTP, tabel berikut menjelaskan kolom entri log aliran yang diamati. Untuk tujuan ilustrasi ini, pertimbangkan konfigurasi jaringan berikut:

• Instance browser di 192.168.1.2
• Load Balancer Jaringan passthrough internl di 10.240.0.200
• Instance webserver di 10.240.0.3

VM yang meminta tidak mengetahui VM mana yang akan merespons permintaan. Selain itu, karena VM lain mengirimkan respons dengan IP load balancing internal sebagai alamat sumber, VM yang meminta tidak tahu VM mana yang telah meresponsnya. Karena alasan ini, VM yang meminta tidak dapat menambahkan informasi dest_instance ke laporannya, hanya informasi src_instance. Karena VM yang merespons mengetahui alamat IP VM lainnya, VM yang merespons dapat menyediakan informasi src_instance dan dest_instance.

Aliran Pod ke ClusterIP

Dalam contoh ini, traffic dikirim dari Pod klien (10.4.0.2) ke cluster-service (10.0.32.2:80). Tujuan ditetapkan ke alamat IP Pod server yang dipilih (10.4.0.3) pada port target (8080).

Di edge node, flow diambil sampelnya dua kali dengan port dan alamat IP yang diterjemahkan. Untuk kedua titik pengambilan sampel, kita akan mengidentifikasi bahwa Pod tujuan mendukung cluster-service layanan pada port 8080, dan menganotasi data dengan detail Service serta detail Pod. Jika traffic dirutekan ke Pod di node yang sama, traffic tidak akan meninggalkan node dan tidak diambil sampelnya sama sekali.

Dalam contoh ini, data berikut ditemukan.

Aliran LoadBalancer eksternal GKE

Traffic dari alamat IP eksternal ke layanan GKE (35.35.35.35) dirutekan ke node dalam cluster, 10.0.12.2 dalam contoh ini, untuk perutean. Secara default, Load Balancer Jaringan passthrough eksternal mendistribusikan traffic ke semua node dalam cluster, bahkan yang tidak menjalankan Pod yang relevan. Traffic mungkin memerlukan hop ekstra untuk sampai ke Pod yang relevan. Untuk mengetahui informasi selengkapnya, lihat Jaringan di luar cluster.

Traffic dirutekan dari node (10.0.12.2) ke Pod server yang dipilih (10.4.0.2). Kedua hop dicatat karena semua edge node diambil sampelnya. Jika traffic dirutekan ke Pod di node yang sama, 10.4.0.3 dalam contoh ini, hop kedua tidak akan dicatat dalam log karena tidak meninggalkan node. Hop kedua dicatat ke dalam log oleh titik pengambilan sampel dari kedua node. Hop kedua dicatat oleh titik pengambilan sampel dari kedua node. Untuk hop pertama, kami mengidentifikasi Service berdasarkan IP load balancer dan port Service (80). Untuk hop kedua, kami mengidentifikasi bahwa Pod tujuan mendukung Service pada port target (8080).

Dalam contoh ini, data berikut ditemukan.

Aliran Ingres GKE

Koneksi dari alamat IP publik ke tujuan Ingress dihentikan di Service Load Balancer. Koneksi dipetakan ke Service NodePort sesuai dengan URL. Untuk melayani permintaan, load balancer (130.211.0.1) terhubung ke salah satu node cluster (10.0.12.2) untuk perutean menggunakan NodePort Service. Secara default, saat membuat Ingress, pengontrol Ingress GKE mengonfigurasi load balancer HTTP(S) yang mendistribusikan traffic di semua node dalam cluster, termasuk yang tidak menjalankan Pod yang relevan. Traffic mungkin memerlukan hop ekstra untuk mencapai Pod yang relevan. Untuk mengetahui informasi selengkapnya, lihat Jaringan di luar cluster. Traffic dirutekan dari node (10.0.12.2) ke Pod server yang dipilih (10.4.0.2).

Kedua hop dicatat karena semua edge node diambil sampelnya. Untuk hop pertama, kami mengidentifikasi Service berdasarkan NodePort (60000) Service. Untuk hop kedua, kita mengidentifikasi bahwa Pod tujuan mendukung Service pada port target (8080). Hop kedua dicatat oleh titik pengambilan sampel kedua node. Namun, jika traffic dirutekan ke Pod pada node yang sama (10.4.0.3), hop kedua tidak akan dicatat dalam log karena traffic tidak meninggalkan node.

Dalam contoh ini, data berikut ditemukan.

Aliran Ingress GKE menggunakan load balancing berbasis container

Permintaan dari alamat IP publik ke Ingress yang menggunakan load balancing berbasis container dihentikan di load balancer. Dalam jenis Ingress ini, Pod adalah objek inti untuk load balancing. Kemudian, permintaan dikirim dari load balancer (130.211.0.1) langsung ke Pod yang dipilih (10.4.0.2). Kami mengidentifikasi bahwa Pod tujuan mendukung Service pada port target (8080).

Dalam contoh ini, data berikut ditemukan.

Pod ke aliran eksternal

Traffic dari Pod (10.4.0.3) ke IP eksternal (203.0.113.1) dimodifikasi oleh IP yang menyamar sehingga paket dikirim dari IP node (10.0.12.2), bukan IP Pod. Secara default, cluster GKE dikonfigurasi untuk menyamarkan traffic ke tujuan eksternal. Untuk mengetahui informasi selengkapnya, lihat Agen penyamaran IP.

Agar dapat melihat anotasi Pod untuk traffic ini, Anda dapat mengonfigurasi agen penyamaran agar tidak menyamarkan IP pod. Dalam kasus semacam ini, untuk mengizinkan traffic ke internet, Anda dapat mengonfigurasi Cloud NAT, yang memproses alamat IP Pod. Untuk mengetahui informasi lebih lanjut tentang Cloud NAT dengan GKE, tinjau interaksi GKE.

Dalam contoh ini, data berikut ditemukan.

Harga

Harga standar untuk Logging, BigQuery, atau Pub/Sub berlaku. Harga Log Aliran VPC dijelaskan dalam harga Network Telemetry.

FAQ

• Apakah Log Aliran VPC menyertakan traffic yang diizinkan dan ditolak berdasarkan aturan firewall?

  • Log Aliran VPC mencakup traffic dari perspektif VM. Semua traffic keluar dari VM akan dicatat dalam log, meskipun diblokir oleh aturan firewall penolakan keluar. Traffic masuk dicatat ke dalam log jika diizinkan oleh aturan firewall izin masuk. Traffic masuk yang diblokir oleh aturan firewall penolakan masuk tidak dicatat dalam log.

• Apakah Log Aliran VPC dapat digunakan pada instance VM dengan berbagai antarmuka?

  • Ya, Anda dapat mengaktifkan Log Aliran VPC untuk semua antarmuka di VM multi-antarmuka.

• Apakah Log Aliran VPC dapat digunakan pada jaringan lama?

  • Tidak, Log Aliran VPC tidak didukung di jaringan lama.

Langkah selanjutnya

• Menggunakan Log Aliran VPC