🏴 🚁 👩‍🎓 [Ilustrasi] Panduan jaringan di Kubernetes. Bagian 3 🤚🏿 😯 💶

Catatan perev. : Artikel ini melanjutkan serangkaian bahan pada perangkat dasar jaringan di Kubernetes, yang dijelaskan dalam bentuk yang dapat diakses dan dengan ilustrasi ilustrasi (namun, praktis belum ada ilustrasi di bagian beton ini). Menerjemahkan dua bagian sebelumnya dari seri ini, kami menggabungkannya menjadi satu publikasi , yang berbicara tentang model jaringan K8 (interaksi dalam node dan antara node) dan jaringan overlay. Bacaan pendahuluannya diinginkan (direkomendasikan oleh penulis sendiri). Kelanjutan ini dikhususkan untuk layanan Kubernetes dan pemrosesan lalu lintas keluar dan masuk.
NB : Untuk kenyamanan penulis, teks penulis dilengkapi dengan tautan (terutama ke dokumentasi resmi K8).

Dinamika klaster

Karena sifat Kubernet yang selalu berubah dan dinamis dan sistem terdistribusi secara umum, pod (dan, sebagai akibatnya, alamat IP mereka) juga terus berubah. Alasan untuk ini bervariasi dari pembaruan yang masuk untuk mencapai keadaan yang diinginkan dan acara yang mengarah ke penskalaan, hingga crash yang tak terduga pada pod atau node. Oleh karena itu, alamat IP pod tidak dapat digunakan secara langsung untuk komunikasi.

Layanan di Kubernetes berperan - IP virtual dengan sekelompok alamat IP pod yang digunakan sebagai titik akhir dan diidentifikasi melalui pemilih label . Layanan semacam itu berfungsi sebagai penyeimbang beban virtual, alamat IP-nya tetap konstan, dan pada saat yang sama, alamat IP pod yang disajikan olehnya dapat terus berubah.

Label selektor di objek Layanan di Kubernetes

Di balik seluruh implementasi IP virtual ini terdapat aturan iptables (versi terbaru dari Kubernetes juga memiliki kemampuan untuk menggunakan IPVS, tetapi ini adalah topik untuk diskusi lain), yang dikendalikan oleh komponen Kubernetes yang disebut kube-proxy . Namun, nama seperti itu menyesatkan dalam realitas saat ini. Kube-proxy benar-benar digunakan sebagai proxy pada hari-hari sebelum rilis Kubernetes v1.0, tetapi ini menyebabkan konsumsi besar sumber daya dan rem karena operasi penyalinan yang konstan antara ruang kernel dan ruang pengguna. Sekarang ini hanya sebuah pengontrol - seperti banyak pengontrol lain di Kubernetes. Ini memonitor server API untuk perubahan ke titik akhir dan memperbarui aturan iptables sesuai.

Menurut aturan iptables ini, jika paket ditujukan untuk alamat IP layanan, Terjemahan Tujuan Jaringan Alamat (DNAT) dilakukan untuk itu: ini berarti bahwa alamat IP-nya akan berubah dari IP layanan ke salah satu titik akhir, yaitu. salah satu alamat IP pod, yang iptables pilih secara acak. Ini memastikan bahwa beban didistribusikan secara merata di antara polong.

DNAT dalam iptables

Dalam hal DNAT seperti itu, informasi yang diperlukan disimpan dalam conntrack - tabel penghubung koneksi di Linux (ini menyimpan terjemahan lima-pasangan yang dibuat oleh iptables: protocol , srcIP , srcPort , dstIP , dstPort ). Semuanya diatur sedemikian rupa sehingga ketika respons dikembalikan, operasi DNAT terbalik (un-DNAT) dapat terjadi, mis. mengganti sumber IP dari Pod IP ke Service IP. Berkat klien ini, sama sekali tidak perlu tahu cara bekerja dengan paket di belakang layar.

Entri lima pasang (5-tupel) dalam tabel conntrack

Jadi, dengan menggunakan layanan Kubernetes, kita dapat bekerja dengan port yang sama tanpa konflik (karena port reassignment ke endpoint dimungkinkan). Ini membuat penemuan layanan sangat mudah. Cukup menggunakan DNS internal dan hard-code host layanan. Anda bahkan dapat menggunakan variabel yang sudah dikonfigurasikan Kubernet dengan host dan port layanan.

Petunjuk : Dengan memilih jalur kedua, Anda menyimpan banyak panggilan DNS yang tidak perlu!

Lalu lintas keluar

Layanan Kubernetes yang dijelaskan di atas beroperasi dalam sebuah cluster. Dalam praktiknya, aplikasi biasanya memerlukan akses ke beberapa API / situs eksternal.

Secara umum, host dapat memiliki alamat IP pribadi dan publik. Untuk mengakses Internet, NAT satu-satu disediakan untuk alamat IP pribadi dan publik ini - ini terutama berlaku untuk lingkungan cloud.

Untuk interaksi normal dari host dengan alamat IP eksternal, IP sumber berubah dari IP host pribadi ke IP publik untuk paket keluar, dan untuk paket masuk - ke arah yang berlawanan. Namun, dalam kasus ketika koneksi ke IP eksternal dimulai oleh pod, alamat IP sumber adalah Pod IP, yang tidak diketahui mekanisme NAT penyedia cloud. Oleh karena itu, ia hanya akan menjatuhkan paket dengan alamat IP sumber yang berbeda dari alamat IP host.

Dan di sini, Anda dapat menebaknya, kita akan membutuhkan iptables lebih banyak lagi! Kali ini, aturan, yang juga ditambahkan oleh kube-proxy, dilakukan oleh SNAT (Source Network Address Translation), alias IP MASQUERADE (menyamar). Alih-alih memberi tahu alamat IP sumber, kernel diminta untuk menggunakan antarmuka IP dari mana paket berasal. Dalam conntrack, catatan juga muncul untuk eksekusi lebih lanjut dari operasi mundur (un-SNAT) pada respons.

Lalu lintas masuk

Sejauh ini, semuanya baik-baik saja. Pod dapat berkomunikasi satu sama lain dan dengan Internet. Namun, kami masih kekurangan hal utama - melayani lalu lintas pengguna. Saat ini ada dua cara untuk mengimplementasikannya:

1. NodePort / Cloud Load Balancer (level L4: IP dan port)

Mengatur NodePort sebagai jenis layanan akan menetapkan layanan NodePort dalam kisaran 30.000–33.000. nodePort terbuka pada setiap node, bahkan ketika tidak ada pod yang berjalan pada node. Lalu lintas masuk di NodePort dikirim ke salah satu pod (yang bahkan mungkin muncul di node lain!), Lagi-lagi menggunakan iptables.

Jenis layanan LoadBalancer di lingkungan cloud menciptakan penyeimbang beban cloud (misalnya, ELB) di depan semua node, yang bekerja lebih jauh dengan NodePort sama.

2. Masuk (tingkat L7: HTTP / TCP)

Banyak implementasi lain juga melakukan HTTP host / path mapping dengan backend yang sesuai - misalnya, nginx, traefik, HAProxy, dll. Dengan mereka, LoadBalancer dan NodePort lagi menjadi titik masuk untuk lalu lintas, tetapi ada keuntungan di sini bahwa kita hanya perlu satu Ingress untuk melayani lalu lintas masuk semua layanan, bukan banyak NodePort / LoadBalancers.

Kebijakan jaringan

Kebijakan jaringan dapat dianggap sebagai grup keamanan / ACL untuk pod. Aturan NetworkPolicy membolehkan / menolak lalu lintas antar pod. Implementasi yang tepat tergantung pada lapisan jaringan / CNI, tetapi kebanyakan dari mereka hanya menggunakan iptables.

...

Itu saja. Dalam angsuran sebelumnya, kami mempelajari dasar-dasar jaringan di Kubernetes dan cara kerja overlay. Sekarang kita tahu bagaimana abstraksi Layanan membantu dalam cluster dinamis dan membuat penemuan layanan sangat sederhana. Kami juga memeriksa bagaimana arus lalu lintas keluar / masuk dan kebijakan jaringan apa yang dapat berguna untuk mengamankan sebuah cluster.

[Ilustrasi] Panduan jaringan di Kubernetes. Bagian 3