Konektivitas kontainer bukanlah masalah kecil bagi perusahaan dengan penempatan Docker dan Kubernetes yang besar. Kita dapat persiapkan alat untuk mendukung beban kerja tersebut. Mari kita pelajari cara membangun jaringan kontainer untuk skalabilitas.

Dokcker dan Kubernetes

Organisasi TI memilih teknologi jaringan dan penjadwalan untuk mendukung kontaineriasasi seperti Docker untuk penyebaran skalabel, redeployment dari komponen yang gagal, shared microservices dan integrasi aplikasi enterprise-wide – dengan fokus khusus pada area kritis dari alamat dan manajemen alur kerja.

Kubernetes adalah jalur untuk menyelesaikan sebagian besar masalah jaringan penampung dengan Docker, jika pengguna Kubernetes merencanakan model mereka dengan serius.

Jaringan docker sederhana. Sebuah host Docker pada dasarnya adalah subnet IP pribadi, mirip dengan banyak jaringan rumah. Di dalam subnet, semuanya bisa berkomunikasi. Tidak ada yang bisa dilihat di luar, kecuali beberapa di dalam port yang memang sengaja diekspos.

Desain jaringan Kubernetes mengandaikan bahwa setiap kontainer dapat berbicara dengan setiap wadah lainnya. Sepertinya jaringan Kubernetes menawarkan lebih dari Docker, tetapi sebetulnya tidak seperti itu. Untuk melakukannya dengan benar, kita dapat mengambil alat dan teknologi tambahan yang mendukung jaringan penampung.

Membangun Jaringan Kontainer

Cara Anda membangun jaringan Kubernetes kemungkinan merupakan keputusan penyebaran kontainer yang paling penting. Desain harus memenuhi model jaringan Kubernetes dari konektivitas universal antar kontainer tetapi juga memaparkan aplikasi ke pengguna yang benar. Pendekatan ini harus memungkinkan koneksi dengan komponen non-Kubernetes dan integrasi dukungan dengan cloud publik untuk beberapa aplikasi atau komponen aplikasi.

Banyak alat untuk membuat konektivitas jaringan kontainer. Salah satu pendekatannya adalah :

  • melalui kontrol eksternal dan jaringan yang ditentukan perangkat lunak (SDN),
  • dengan alat seperti Cisco Application Centric Infrastructure, VMware NSX, Juniper Contrail, dan Nokia Nuage.

Model lain mendukung pendekatan yang terintegrasi dengan Kubernetes. Contoh populer termasuk :

  • Kube-router,
  • Multus dan plug-in Kubernetes lainnya.

Pengaturan konektivitas berbasis SDN sejauh ini adalah yang paling fleksibel dan kemungkinan besar untuk mendukung kebutuhan jaringan perusahaan yang sudah ada, jadi berikan pertimbangan serius pada SDN.

Fitur Kubernetes untuk manajemen jaringan kontainer

Untuk mengekspos aplikasi kontainer ke pengguna di Kubernetes, gunakan “Layanan”. Layanan merupakan abstraksi antarmuka komponen, dipetakan ke Kubernetes Pod yang mendukungnya di satu sisi dan ke antarmuka eksternal di sisi lain.

Antarmuka eksternal dapat mencapai alamat pribadi intracluster (default), alamat eksternal atau load balancing yang mengarahkan pekerjaan ke satu contoh layanan.

Pendekatan Layanan juga mengelola penskalaan kontainer, menggunakan antarmuka penyeimbang beban untuk menautkan Layanan ke grup Pod elastis.

Penyeimbang beban mendistribusikan pekerjaan. Pengguna dapat memperbarui daftar load balancer dari sumber daya yang tersedia dengan menugaskan sumber daya baru dan kontainer.

Sumber daya baru tersebut akan digunakan di mana pun mereka di hosting. Tindakan scaling-down menghilangkan sumber daya baik dari Pod hosting mereka dan dari inventaris load balancer.

Menjaga kestabilan jaringan kontainer bisa menjadi tantangan, dan ini artinya tidak hanya sampai di sini saja.

Kubernetes Container Networking Interface

Adalah cara untuk mengotomatiskan dan mengatur tugas jaringan dalam Kubernetes, termasuk pemetaan antarmuka Layanan. Pengguna harus menyediakan alat jaringan khusus seperti produk SDN tersebut di atas, dan mengelola ruang alamat sehingga semuanya tidak bisa diacuhkan.

Sebagian besar pengguna Kubernetes menggunakan pengalamatan IP pribadi untuk kluster mereka dan mengekspos alamat yang digunakan oleh pekerja dan elemen non-Kubernetes ke jaringan pribadi virtual (VPN). Sering juga diperlukan untuk mengakomodasi sumber daya cloud publik.

Pengalamatan jaringan kontainer

Pengalamatan kontainer adalah masalah kunci kedua dalam jaringan kontainer Kubernetes. Jaringan kontainer hampir selalu didasarkan pada alamat IP pribadi, yang bersifat lokal. Ini berarti mereka beroperasi hanya di dalam domain.

Domain dapat berupa kluster Kubernetes, perusahaan atau grup kumpulan lainnya. Alamat IP lokal ini tidak dapat diakses dari internet atau dari perusahaan lain. Permintaan internet untuk komentar 1918 (RFC1918) menjabarkan ruang alamat IP pribadi: satu alamat Kelas A (16 juta alamat), 16 alamat Kelas B (masing-masing 65.000 alamat) dan 256 alamat Kelas C (256 alamat masing-masing).

Sebagian besar pengguna Kubernetes mengadopsi alamat Kelas A karena pilihan itu menawarkan fleksibilitas terbesar saat mereka menetapkan alamat.

Hindari tumpang tindih alamat IP pribadi untuk VPN dan Kubernetes atau tumpang tindih dalam kluster terpisah. Pilih ruang alamat yang berbeda atau bagian dari ruang Kelas A untuk mencegah kebingungan.

Bertindak secara global, proses secara lokal

Membangun kluster Kubernetes, kapan pun dimungkinkan, dari sumber daya hosting fisik yang digabung atau setidaknya secara lokal dan cukup terhubung sehingga sumber daya di dalamnya bekerja secara bergantian.

Kedekatan menghilangkan risiko terhadap kualitas pengalaman yang disebabkan oleh keterbatasan konektivitas di seluruh jaringan kontainer ketika sebuah aplikasi tersebar pada beberapa server jarak jauh di data center yang lain.

Pertimbangkan untuk menggunakan kluster yang berbeda di mana ada pemisahan geografis yang berbeda dalam kumpulan sumber daya.

Juga, ikuti aturan umum ini: Berikan kluster ruang alamat umum, dan kemudian, putuskan apakah kluster tertentu harus mendukung hanya aplikasi dan pengguna yang terkait atau apakah kluster harus menyediakan cadangan satu sama lain.

Pengguna Kubernetes dapat meneruskan alur kerja di antara kluster independen dengan mengekspos antarmuka untuk alur kerja tersebut di VPN perusahaan. Jika klaster saling mendukung, gunakan kapabilitas federasi Kubernetes untuk menentukan aplikasi yang disinkronkan di seluruh kluster dan menyediakan akses seragam ke sumber daya tersebut.

Federasi menganggap bahwa Kubernetes harus menyinkronkan keadaan aplikasi di seluruh klaster. Ini dapat menghasilkan overhead yang signifikan. Beralihlah ke alat data center tradisional dan alat penyebaran Kubernetes secara langsung, bukan ke federasi, untuk kluster independen atau untuk mengontrol sinkronisasi versi aplikasi dan basis data di seluruh kluster.

 

Untuk penyebaran kontainer skala besar atau yang kemungkinan akan tumbuh menjadi besar, mulailah dengan Kubernetes bersama dengan Docker, bukan hanya Docker. Rencanakan model jaringan Kubernetes untuk perluasan pertumbuhan kontainer yang diharapkan.

Pendekatan ini sangat disarankan. Beralih ke Kubernetes atau ke model jaringan Kubernetes setelah penerapan mencapai skala yang cukup besar. Hal ini dapat meningkatkan peluang bahwa jaringan kontainer dilakukan dengan benar dengan mengantisipasi skala dari hari pertama.