Kubernetes Networks: Pods

Bahan, terjemahan yang kami terbitkan hari ini, dikhususkan untuk fitur-fitur interaksi jaringan perapian Kubernetes. Ini ditujukan bagi mereka yang sudah memiliki pengalaman dengan Kubernetes. Jika Anda tidak terlalu berpengalaman dalam Kubernetes, maka mungkin ada baiknya Anda membaca tutorial Kubernetes ini sebelum membaca materi ini, di mana bekerja dengan platform ini dianggap sebagai pemula.

Polong

Apa yang ada di bawah (pod) Kubernetes? Sub adalah entitas yang terdiri dari satu atau lebih kontainer yang dihosting di host yang sama dan dikonfigurasikan untuk berbagi sumber daya tumpukan jaringan dan sumber daya lain seperti volume. Pod adalah blok bangunan dasar yang membentuk aplikasi yang berjalan pada platform Kubernetes. Pod berbagi tumpukan jaringan. Dalam praktiknya, ini berarti bahwa semua wadah yang membentuk perapian dapat berkomunikasi satu sama lain melalui localhost . Jika ada wadah di perapian yang menjalankan nginx, mendengarkan pada port 80, dan wadah lain yang menjalankan scrapyd, wadah ini dapat mengakses wadah pertama di http://localhost:80 . Itu tidak terlihat begitu sulit. Sekarang mari kita bertanya pada diri sendiri bagaimana ini sebenarnya bekerja. Mari kita lihat situasi tipikal ketika wadah Docker diluncurkan pada mesin lokal.


Kontainer Docker berjalan pada mesin lokal

Jika Anda melihat skema ini dari atas ke bawah, ternyata ada antarmuka jaringan fisik eth0 . Jembatan docker0 , dan antarmuka jaringan virtual docker0 veth0 ke jembatan. Perhatikan bahwa veth0 dan veth0 berada di jaringan yang sama, dalam contoh ini adalah 172.17.0.0/24 . Pada jaringan ini, antarmuka docker0 diberikan alamat IP 172.17.0.1 , antarmuka ini adalah gateway default untuk antarmuka veth0 , yang diberi alamat 172.17.0.2 . Karena kekhasan pengaturan ruang nama jaringan saat memulai wadah, proses di dalam wadah hanya melihat antarmuka veth0 dan berinteraksi dengan dunia luar melalui antarmuka docker0 dan eth0 . Sekarang jalankan wadah kedua.


Dua kontainer Docker berjalan di mesin lokal

Seperti yang dapat Anda lihat dalam diagram di atas, antarmuka jaringan virtual baru veth1 ditugaskan ke wadah kedua, yang terhubung ke jembatan yang sama dengan wadah pertama - ke docker0 . Ini adalah deskripsi yang agak ringkas tentang apa yang sebenarnya terjadi. Selain itu, perlu dicatat bahwa koneksi antara wadah dan jembatan dibuat berkat sepasang antarmuka Ethernet virtual yang terhubung, salah satunya adalah dalam namespace kontainer dan yang lainnya di namespace jaringan root. Detail tentang ini dapat ditemukan di sini .

Semua ini bagus, tetapi belum menggambarkan apa yang kami, seperti yang diterapkan pada pod Kubernetes, memanggil "tumpukan jaringan bersama". Untungnya, ruang nama sangat fleksibel. Docker dapat meluncurkan wadah, dan alih-alih membuat antarmuka jaringan virtual baru untuk itu, membuatnya menggunakan antarmuka yang ada bersama-sama dengan wadah lainnya. Dengan pendekatan ini, kita harus mengubah skema di atas seperti yang ditunjukkan di bawah ini.


Wadah menggunakan antarmuka jaringan yang umum

Sekarang wadah kedua berinteraksi dengan antarmuka veth0 sudah ada, dan tidak dengan antarmuka veth1 sendiri, seperti pada contoh sebelumnya. Penggunaan skema semacam itu mengarah pada beberapa konsekuensi. Untuk mulai dengan, kita sekarang dapat mengatakan bahwa kedua kontainer terlihat secara eksternal di alamat yang sama - 172.17.0.2 , dan di dalam masing-masing kontainer dapat mengakses port di localhost dibuka oleh kontainer lain. Selain itu, ini berarti bahwa kontainer ini tidak dapat membuka port yang sama. Ini, tentu saja, adalah batasan, tetapi tidak berbeda dari batasan serupa dalam situasi ketika beberapa proses membuka port pada host yang sama. Dengan pendekatan ini, serangkaian proses mendapatkan semua keuntungan yang terkait dengan menjalankan proses ini dalam wadah, seperti konektivitas dan isolasi yang buruk, tetapi pada saat yang sama, proses dapat mengatur kolaborasi dalam lingkungan jaringan yang ada yang paling sederhana.

Kubernet mengimplementasikan pola ini dengan membuat wadah khusus untuk setiap tungku yang tujuan utamanya adalah menyediakan antarmuka jaringan untuk wadah tungku lainnya. Jika Anda terhubung ke node dari cluster Kubernetes yang ditugaskan sub spesifik oleh ssh dan menjalankan perintah docker ps , Anda akan melihat setidaknya satu kontainer berjalan dengan perintah pause . Perintah ini menjeda proses saat ini sampai sinyal SIGTERM tiba. Wadah seperti itu sama sekali tidak melakukan apa-apa, mereka dalam keadaan "tidur" dan sedang menunggu sinyal ini. Terlepas dari kenyataan bahwa wadah yang "ditangguhkan" tidak melakukan apa-apa, mereka, dengan demikian, adalah "jantung" perapian, menyediakan wadah lain dengan antarmuka jaringan virtual yang dapat mereka gunakan untuk berinteraksi satu sama lain atau dengan dunia luar. Hasilnya, ternyata dalam lingkungan hipotetis yang mirip dengan, skema kami sebelumnya akan terlihat seperti yang ditunjukkan di bawah ini.


Wadah hipotetis

Jaringan perapian

Satu di bawah, penuh wadah, adalah blok bangunan sistem tertentu, tetapi sejauh ini bukan sistem itu sendiri. Arsitektur Kubernetes didasarkan pada persyaratan bahwa pod harus dapat berinteraksi dengan pod lain terlepas dari apakah mereka berjalan di komputer yang sama atau di mesin yang berbeda. Untuk mempelajari bagaimana semua ini bekerja, kita perlu pergi ke tingkat abstraksi yang lebih tinggi dan berbicara tentang bagaimana node bekerja di kluster Kubernetes. Di sini kita akan membahas topik rute jaringan dan rute. Topik ini sering dihindari dalam materi seperti ini, mengingat terlalu rumit. Tidak mudah menemukan panduan yang dapat dimengerti dan tidak terlalu panjang untuk IP routing, tetapi jika Anda ingin melihat gambaran singkat masalah ini, Anda dapat melihat materi ini .

Cluster Kubernetes terdiri dari satu node atau lebih node. Node adalah sistem host, fisik atau virtual, yang berisi berbagai alat perangkat lunak dan dependensinya (terutama Docker), serta beberapa komponen sistem Kubernet. Node terhubung ke jaringan, yang memungkinkannya untuk bertukar data dengan node lain di cluster. Inilah yang terlihat seperti kluster dua-simpul sederhana.


Cluster dua simpul sederhana

Jika cluster yang dimaksud berjalan di lingkungan cloud seperti GCP atau AWS, maka skema ini cukup akurat menyampaikan esensi arsitektur jaringan default untuk masing-masing proyek. Untuk tujuan demonstrasi, jaringan pribadi 10.100.0.0/24 digunakan dalam contoh ini. Akibatnya, alamat 10.100.0.1 ditugaskan ke 10.100.0.1 , dan alamat 10.100.0.2 dan 10.100.0.3 dua node. Menggunakan arsitektur ini, masing-masing node dapat berinteraksi dengan yang lain menggunakan antarmuka jaringan eth0 . Sekarang mari kita ingat bahwa di bawah, berjalan di host, tidak ada di jaringan pribadi ini. Terhubung ke jembatan di jaringan yang sama sekali berbeda. Ini adalah jaringan virtual yang hanya ada dalam simpul tertentu. Untuk membuatnya lebih jelas, mari kita menggambar ulang skema sebelumnya, menambahkan apa yang kita sebut perapian hipotetis di atas.


Pod dan node

Host yang terletak di sebelah kiri diagram ini memiliki antarmuka eht0 dengan alamat 10.100.0.2 , gateway default yang merupakan router dengan alamat 10.100.0.1 . Jembatan docker0 dengan alamat 172.17.0.1 terhubung ke antarmuka ini, dan ke sana, melalui antarmuka virtual veth0 dengan alamat 172.17.0.2 , terhubung dengan apa yang kita sebut perapian di sini. Antarmuka veth0 dibuat dalam wadah yang ditangguhkan. Itu terlihat di ketiga kontainer melalui tumpukan jaringan bersama. Karena kenyataan bahwa aturan perutean lokal dikonfigurasikan saat membuat jembatan, setiap paket yang tiba di eth0 dan memiliki alamat tujuan 172.17.0.2 akan dialihkan ke jembatan, yang akan meneruskannya ke antarmuka virtual veth0 . Sementara semua ini terlihat lumayan. Jika diketahui bahwa host yang kita diskusikan memiliki alamat 172.17.0.2 , maka kita dapat menambahkan aturan ke pengaturan router yang menjelaskan bahwa transisi berikutnya untuk alamat ini adalah 10.100.0.2 , setelah itu paket dari sana harus diarahkan ke veth0 . Luar biasa. Sekarang mari kita lihat host lain.

Tuan rumah yang ditunjukkan pada diagram di sebelah kanan memiliki antarmuka fisik eth0 dengan alamat 10.100.0.3 . Ia menggunakan gateway default yang sama - 10.100.0.1 , dan, sekali lagi, terhubung ke jembatan docker0 dengan alamat 172.17.0.1 . Ada perasaan bahwa semuanya tidak berjalan dengan baik. Alamat ini, pada kenyataannya, mungkin berbeda dari yang digunakan pada host yang terletak di sebelah kiri. Alamat jembatan di sini dibuat sama untuk menunjukkan skenario yang paling buruk, yang, misalnya, dapat terjadi jika Anda baru saja memasang Docker dan membiarkannya berfungsi sesuai keinginan. Tetapi bahkan jika jaringan yang dimaksud berbeda, contoh kami menyoroti masalah yang lebih dalam, yaitu bahwa node biasanya tidak tahu apa-apa tentang alamat pribadi yang ditugaskan untuk jembatan yang terletak di node lain. Dan kita perlu tahu tentang ini - untuk dapat mengirim paket ke jembatan ini dan memastikan bahwa mereka akan datang ke tempat yang mereka butuhkan. Jelas, di sini kita memerlukan semacam entitas, yang memungkinkan kita untuk memastikan konfigurasi alamat yang benar di node yang berbeda.

Platform Kubernetes memberi kita solusi dua langkah untuk masalah ini. Pertama, platform ini memberikan ruang alamat umum untuk jembatan di setiap node dan kemudian menetapkan jembatan alamat di ruang ini berdasarkan pada simpul mana jembatan itu berada. Kedua, Kubernetes menambahkan aturan perutean ke gateway yang terletak, dalam kasus kami, di 10.100.0.1 . Aturan-aturan ini menentukan aturan untuk paket routing yang ditujukan untuk masing-masing jembatan. Artinya, mereka menggambarkan melalui mana antarmuka fisik eth0 dapat dihubungi dengan masing-masing jembatan. Kombinasi antarmuka jaringan virtual, jembatan, dan aturan perutean ini biasa disebut jaringan hamparan . Berbicara tentang Kubernet, saya biasanya menyebut jaringan ini sebagai "jaringan perapian", karena ini adalah jaringan hamparan yang memungkinkan pod yang terletak di beberapa node berbeda untuk berkomunikasi satu sama lain. Berikut ini diagram yang akan terlihat setelah mekanisme Kubernet turun ke bisnis.


Jaringan perapian

Segera menarik perhatian bahwa nama-nama jembatan diubah dari docker0 ke cbr0 . Kubernetes tidak menggunakan jembatan Docker standar. Apa yang kami sebut cbr adalah singkatan dari "custom bridge", yaitu, kita berbicara tentang beberapa jembatan khusus. Saya tidak siap untuk memberikan daftar lengkap perbedaan antara meluncurkan wadah Docker di pod dan menjalankannya di komputer biasa, tetapi apa yang kita bicarakan di sini adalah salah satu perbedaan penting yang serupa. Selain itu, Anda perlu memperhatikan fakta bahwa ruang alamat yang ditugaskan untuk jembatan dalam contoh ini adalah 10.0.0.0/14 . Alamat ini diambil dari salah satu kelompok pementasan kami, yang digunakan pada platform Google Cloud, jadi di atas adalah contoh nyata dari jaringan perapian. Cluster Anda dapat diberi rentang alamat yang sangat berbeda. Sayangnya, saat ini tidak ada cara untuk mendapatkan informasi tentang alamat-alamat ini menggunakan utilitas kubectl , tetapi, misalnya, jika Anda menggunakan GCP, Anda dapat menjalankan perintah seperti gcloud container clusters describe <cluster> dan melihat properti clusterIpv4Cidr .

Secara umum, dapat dicatat bahwa Anda biasanya tidak harus berpikir tentang cara kerja jaringan perapian. Ketika seorang sub bertukar data dengan perapian lain, paling sering ini terjadi melalui layanan Kubernetes. Ini adalah sedikit proksi yang ditentukan perangkat lunak. Tetapi alamat jaringan perapian muncul di log. Dalam beberapa situasi, khususnya selama debugging, Anda mungkin perlu menetapkan aturan perutean secara eksplisit di jaringan perapian. Misalnya, lalu lintas yang meninggalkan Kubernet terikat ke alamat apa pun di kisaran 10.0.0.0/8 tidak diproses secara default menggunakan NAT. Oleh karena itu, jika Anda berinteraksi dengan layanan yang berlokasi di jaringan pribadi lain yang memiliki rentang alamat yang sama, Anda mungkin perlu mengonfigurasi aturan perutean yang akan memungkinkan Anda untuk mengatur pengiriman paket yang benar.

Ringkasan

Hari ini kami berbicara tentang pod Kubernetes dan fitur-fitur jaringan mereka. Kami berharap materi ini membantu Anda mengambil langkah yang tepat untuk menerapkan skenario interaksi perapian yang kompleks di jaringan Kubernetes.

Pembaca yang budiman! Artikel ini adalah yang pertama dari serangkaian jaringan Kubernetes. Bagian kedua dari siklus ini telah diterjemahkan . Kami sedang memikirkan apakah akan menerjemahkan bagian ketiga . Kami meminta Anda untuk mengomentari ini dalam komentar.