Salah satu persyaratan dasar model jaringan Kubernetes adalah bahwa setiap pod harus memiliki alamat IP-nya sendiri, dan setiap pod lain dalam kluster harus dapat menjangkau di alamat tersebut. Ada banyak "penyedia" jaringan (Flanel, Calico, Canal, dll.) Yang membantu mengimplementasikan model jaringan ini.
Ketika saya pertama kali mulai bekerja dengan Kubernetes, tidak sepenuhnya jelas bagi saya bagaimana tepatnya pod mendapatkan alamat IP-nya. Bahkan dengan pemahaman tentang bagaimana masing-masing komponen berfungsi, sulit membayangkan mereka bekerja bersama. Misalnya, saya tahu untuk apa plugin CNI, tetapi saya tidak tahu bagaimana mereka dipanggil. Oleh karena itu, saya memutuskan untuk menulis artikel ini untuk membagikan pengetahuan saya tentang berbagai komponen jaringan dan bagaimana mereka bekerja bersama dalam cluster Kubernetes, yang memungkinkan setiap pod mendapatkan alamat IP uniknya sendiri.
Ada beberapa cara berbeda untuk mengatur jaringan di Kubernetes, sama seperti opsi runtime yang berbeda untuk container. Posting ini akan menggunakan Flanel untuk jaringan cluster dan menggunakan Containerd sebagai runtime . Saya juga melanjutkan dari asumsi bahwa Anda tahu cara kerja jaringan antar kontainer, jadi saya hanya akan menyentuhnya secara singkat, semata-mata untuk konteks.
Beberapa konsep dasar
Wadah dan jaringan: gambaran umum
Ada banyak publikasi bagus di Internet yang menjelaskan bagaimana wadah berkomunikasi satu sama lain melalui jaringan. Oleh karena itu, saya hanya akan memberikan gambaran umum tentang konsep dasar dan membatasi diri saya pada satu pendekatan, yang melibatkan pembuatan jembatan Linux dan paket enkapsulasi. Detailnya dihilangkan, karena topik jaringan container itu sendiri membutuhkan artikel terpisah. Tautan ke beberapa publikasi yang sangat informatif dan informatif akan diberikan di bawah ini.
Penampung di satu host
Salah satu cara untuk membangun komunikasi alamat IP antara kontainer yang berjalan pada host yang sama adalah dengan membuat jembatan Linux. Untuk ini, perangkat virtual veth (virtual ethernet) dibuat di Kubernetes (dan Docker ) . Salah satu ujung perangkat veth terhubung ke namespace jaringan wadah, yang lain terhubung ke jembatan Linux di jaringan host.
Semua container di host yang sama memiliki salah satu ujung veth yang terhubung ke bridge di mana mereka dapat berkomunikasi satu sama lain menggunakan alamat IP. Bridge Linux juga memiliki alamat IP dan bertindak sebagai gateway untuk lalu lintas keluar dari pod ke node lain.
Penampung di host yang berbeda
Enkapsulasi paket adalah salah satu cara untuk mengizinkan kontainer pada host yang berbeda untuk berkomunikasi satu sama lain menggunakan alamat IP. Di Flannel , teknologi vxlan bertanggung jawab atas fitur ini , yang "mengemas" paket asli ke dalam paket UDP dan kemudian mengirimkannya ke tujuannya.
Dalam cluster Kubernetes, Flannel membuat perangkat vxlan dan menambahkan tabel rute pada setiap node yang sesuai. Setiap paket yang ditujukan untuk penampung di host yang berbeda melewati perangkat vxlan dan dienkapsulasi dalam paket UDP. Di tempat tujuan, paket bersarang diekstrak dan dialihkan ke pod yang diinginkan.
Catatan: Ini hanyalah salah satu cara untuk membuat jaringan antar kontainer.
Apa itu CRI?
CRI (Container Runtime Interface) adalah plugin yang memungkinkan kubelet untuk menggunakan lingkungan runtime container yang berbeda. CRI API dibangun ke dalam berbagai lingkungan waktu proses, sehingga pengguna dapat memilih waktu proses pilihan mereka.
Apakah CNI itu?
Proyek CNI adalah spesifikasi untuk mengatur solusi jaringan universal untuk wadah Linux. Selain itu, ini menyertakan plugin yang bertanggung jawab atas berbagai fungsi saat menyiapkan jaringan pod. Plugin CNI adalah file yang dapat dieksekusi yang sesuai dengan spesifikasi (kami akan membahas beberapa plugin di bawah).
Host subnetting untuk menetapkan alamat IP ke pod
Karena setiap pod di cluster harus memiliki alamat IP, penting untuk memastikan bahwa alamat ini unik. Ini dilakukan dengan menetapkan setiap host subnet unik, dari mana alamat IP kemudian ditetapkan ke pod pada host tersebut.
Pengontrol IPAM Host
Saat
nodeipamditeruskan sebagai parameter ke tanda --controllers kube-controller-manager , ia mengalokasikan subnet terpisah (podCIDR) untuk setiap node dari cluster CIDR (yaitu kisaran alamat IP untuk jaringan cluster). Karena podCIDR ini tidak tumpang tindih, setiap pod dapat menetapkan alamat IP unik.
Node Kubernetes diberi podCIDR saat pertama kali mendaftar dengan cluster. Untuk mengubah podCIDR dari node, Anda perlu membatalkan pendaftarannya dan kemudian mendaftarkannya kembali, sementara itu membuat perubahan yang sesuai pada konfigurasi lapisan kontrol Kubernetes. Anda dapat menampilkan podCIDR dari sebuah node menggunakan perintah berikut:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, peluncur kontainer dan plugin CNI: bagaimana semuanya bekerja
Menjadwalkan sebuah pod per node melibatkan banyak langkah persiapan. Di bagian ini, saya hanya akan fokus pada mereka yang berhubungan langsung dengan jaringan pod.
Penjadwalan pod ke node memicu rangkaian kejadian berikut:
Bantuan: Berisi Arsitektur Plugin CRI .
Interaksi antara peluncur kontainer dan plugin CNI
Setiap penyedia jaringan memiliki plugin CNI-nya sendiri. Waktu proses penampung meluncurkannya untuk mengonfigurasi jaringan untuk pod saat dimulai. Dalam kasus containerd, plugin Containerd CRI bertanggung jawab untuk meluncurkan plugin CNI .
Apalagi setiap provider memiliki agennya masing-masing. Ini diinstal pada semua node Kubernetes dan bertanggung jawab untuk membuat jaringan pod. Agen ini dilengkapi dengan konfigurasi CNI, atau membuatnya di node itu sendiri. Config membantu plugin CRI untuk menentukan plugin CNI mana yang akan dipanggil.
Lokasi konfigurasi CNI dapat disesuaikan; secara default terletak di
/etc/cni/net.d/<config-file>. Administrator cluster juga bertanggung jawab untuk menginstal plugin CNI di setiap node cluster. Lokasi mereka juga dapat disesuaikan; direktori defaultnya adalah /opt/cni/bin.
Saat menggunakan containerd, jalur untuk binari config dan plugin dapat diatur di bagian
[plugins.«io.containerd.grpc.v1.cri».cni]di file konfigurasi containerd .
Karena kita menggunakan Flanel sebagai penyedia jaringan kita, mari kita bicara sedikit tentang pengaturannya:
- Flanneld (Flannel'a daemon) biasanya diinstal di cluster seperti DaemonSet
install-cnisebagai init-container . Install-cnimembuat file konfigurasi CNI (/etc/cni/net.d/10-flannel.conflist) di setiap node.- Flanneld membuat perangkat vxlan, mengambil metadata jaringan dari server API, dan memantau pod untuk pembaruan. Saat dibuat, ia menyebarkan rute untuk semua pod di seluruh kluster.
- Rute ini memungkinkan pod untuk berkomunikasi satu sama lain menggunakan alamat IP.
Untuk informasi lebih lanjut tentang cara kerja Flanel, saya sarankan menggunakan tautan di akhir artikel.
Berikut adalah diagram interaksi antara plugin Containerd CRI dan plugin CNI:
Seperti yang Anda lihat di atas, kubelet memanggil plugin Containerd CRI untuk membuat sebuah pod, dan memanggil plugin CNI untuk mengkonfigurasi jaringan pod. Dengan demikian, plugin CNI penyedia jaringan memanggil plugin CNI dasar lainnya untuk mengonfigurasi berbagai aspek jaringan.
Interaksi antara plugin CNI
Ada berbagai plugin CNI yang dirancang untuk membantu mengatur jaringan antar kontainer pada sebuah host. Artikel ini akan berfokus pada tiga di antaranya.
Plugin CNI Flanel
Saat menggunakan Flanel sebagai penyedia jaringan, komponen Containerd CRI memanggil plugin Flanel CNI menggunakan file konfigurasi CNI
/etc/cni/net.d/10-flannel.conflist.
$ cat /etc/cni/net.d/10-flannel.conflist
{
"name": "cni0",
"plugins": [
{
"type": "flannel",
"delegate": {
"ipMasq": false,
"hairpinMode": true,
"isDefaultGateway": true
}
}
]
}
Plugin Flannel CNI bekerja sama dengan Flanneld. Saat memulai, Flanneld mengekstrak podCIDR dan detail terkait jaringan lainnya dari server API dan menyimpannya ke sebuah file
/run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
Plugin CNI Flanel menggunakan data dari
/run/flannel/subnet.envuntuk mengkonfigurasi dan menjalankan plugin CNI bridge.
Jembatan plugin CNI
Plugin ini dipanggil dengan konfigurasi berikut:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Pada panggilan pertama, ini membuat jembatan Linux dengan
«name»: «cni0», yang ditunjukkan dalam konfigurasi. Kemudian pasangan veth dibuat untuk setiap pod. Salah satu ujungnya terhubung ke namespace jaringan wadah, yang lainnya masuk ke jembatan Linux di jaringan host. Plugin CNI Bridge menghubungkan semua wadah host ke jembatan Linux di jaringan host.
Setelah selesai mengkonfigurasi pasangan veth, plugin Bridge memanggil plugin IPAM CNI lokal-host. Jenis plugin IPAM dapat dikonfigurasi di konfigurasi CNI, yang digunakan plugin CRI untuk memanggil plugin Flannel CNI.
Plugin CNI IPAM lokal host
Bridge CNI memanggil plugin CNI IPAM lokal-host dengan konfigurasi berikut:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Host-local IPAM-plug ( IP A ddress M anagement - IP-address management) mengembalikan alamat IP untuk subnet wadah dan menyimpan IP yang dipilih di host dalam direktori yang ditentukan di bagian
dataDir- /var/lib/cni/networks/<network-name=cni0>/<ip>. File ini berisi ID wadah yang diberikan alamat IP ini.
Saat plugin IPAM host-lokal dipanggil, ia mengembalikan data berikut:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Ringkasan
Kube-controller-manager memberikan podCIDR ke setiap node. Pod dari setiap node mendapatkan alamat IP dari ruang alamat dalam rentang podCIDR yang dialokasikan. Karena podCIDR dari node tidak tumpang tindih, semua pod menerima alamat IP unik.
Administrator cluster Kubernetes mengonfigurasi dan menginstal kubelet, container launcher, agen penyedia jaringan, dan menyalin plugin CNI ke setiap node. Selama startup, agen penyedia jaringan menghasilkan konfigurasi CNI. Ketika sebuah pod dijadwalkan untuk sebuah node, kubelet memanggil plugin CRI untuk membuatnya. Lebih lanjut, jika containerd digunakan, plugin Containerd CRI memanggil plugin CNI yang ditentukan dalam konfigurasi CNI untuk mengkonfigurasi jaringan pod. Ini memberi pod sebuah alamat IP.
Butuh beberapa waktu bagi saya untuk memahami semua seluk-beluk dan nuansa dari semua interaksi ini. Saya harap pengalaman yang didapat akan membantu Anda lebih memahami cara kerja Kubernetes. Jika saya salah tentang sesuatu, silakan hubungi saya di Twitter atau di hello@ronaknathani.com . Jangan ragu untuk menghubungi jika Anda ingin mendiskusikan aspek artikel ini atau yang lainnya. Saya akan senang berbicara dengan Anda!
Tautan
Kontainer dan Jaringan
Bagaimana Flanel bekerja
CRI dan CNI
PS dari penerjemah
Baca juga di blog kami: