Geekly articles weekly

Buku “Menguasai Kubernet. Orkestrasi arsitektur wadah "

gambar Hai, habrozhiteli! Kami baru-baru ini menerbitkan buku tentang Kubernetes versi 1.10. Posting meninjau bagian "Solusi Jaringan untuk Kubernetes"

Jaringan adalah topik yang luas. Ada banyak cara untuk mengkonfigurasi jaringan dengan perangkat, perapian, dan wadah. Kubernetes tidak membatasi Anda untuk ini. Semua yang ditentukan oleh platform ini adalah model jaringan tingkat tinggi dengan ruang alamat datar untuk perapian. Dalam ruang ini, Anda dapat menerapkan banyak solusi bagus dengan kemampuan berbeda dan untuk lingkungan yang berbeda. Pada bagian ini, kita akan melihat beberapa dari mereka dan mencoba memahami bagaimana mereka masuk ke dalam model jaringan Kubernetes.

Membuat jembatan di kluster perangkat keras


Lingkungan paling sederhana adalah bare metal cluster, yang merupakan jaringan fisik L2-level biasa. Untuk menghubungkan kontainer ke jaringan seperti itu, Anda dapat menggunakan jembatan Linux standar. Ini adalah prosedur yang agak melelahkan yang membutuhkan pengalaman dengan perintah jaringan Linux tingkat rendah, seperti brctl, ip addr, rute ip, tautan ip, nsenter, dll. Anda dapat mulai menerapkan solusi seperti itu dengan membaca panduan berikut: blog.oddbit.com/
2014/08/11 / four-ways-to-connect-a-docker / (lihat bagian Dengan perangkat Linux Bridge).

Contiv


Contiv adalah add-on jaringan tujuan umum. Ini dirancang untuk menghubungkan kontainer melalui CNI dan dapat digunakan dengan Docker (langsung), Mesos, Docker Swarm dan, tentu saja, Kubernetes. Contiv berurusan dengan kebijakan jaringan dan menduplikasi sebagian objek serupa di Kubernet. Berikut ini adalah beberapa fitur dari add-on jaringan ini:

  • dukungan untuk CNM di libnetwork dan spesifikasi CNI;
  • Mesin kebijakan kaya fitur yang menyediakan keamanan dan penyebaran aplikasi yang dapat diprediksi.
  • kinerja wadah terbaik di kelasnya;
  • multi-tenancy, isolasi, dan subnet yang tumpang tindih;
  • Integrasi IPAM dan penemuan layanan;
  • berbagai pilihan topologi fisik:

    a) protokol layer 2 (VLAN);
    b) protokol layer 3 (BGP);
    c) jaringan overlay;
    d) Cisco SDN (ACI);
  • Dukungan IPv6;
  • kebijakan terukur dan alokasi rute;
  • Integrasi dengan templat aplikasi, termasuk yang berikut:

    a) Susunan Docker;
    b) manajer penyebaran Kubernet;
    c) load balancing pada layanan, dibangun ke dalam penyeimbang layanan microser dari tipe "timur-barat" (timur-barat);
    d) isolasi lalu lintas selama penyimpanan, kontrol akses (misalnya, etcd / consul), transmisi dan manajemen jaringan.

Contiv memiliki banyak fitur. Alat ini mengimplementasikan berbagai tugas dan mendukung berbagai platform, jadi saya tidak yakin apakah ini akan menjadi pilihan terbaik untuk Kubernetes.

Buka vswitch


Open vSwitch adalah solusi sakelar virtual (peranti lunak) matang yang didukung oleh banyak pemain pasar utama. Sistem Open Virtualization Network (OVN) memungkinkan Anda membangun berbagai topologi jaringan virtual. Dia memiliki add-on khusus untuk Kubernetes, tetapi sangat sulit untuk dikonfigurasikan (lihat manual github.com/openvswitch/ovn-kubernetes ). Add-on Linen CNI memiliki lebih sedikit fitur, tetapi konfigurasinya jauh lebih mudah: github.com/John-Lin/linen-cni . Struktur Linen CNI ditunjukkan pada Gambar. 10.6.

gambar

Open vSwitch dapat mengintegrasikan server fisik, VM, dan pod / wadah ke dalam satu jaringan logis. Sistem ini mendukung mode overlay dan fisik.

Berikut adalah beberapa fitur utamanya:

  • VLAN 802.1Q standar dengan port trunk dan publik
  • NIC mengikat dengan atau tanpa LACP untuk sakelar level yang lebih tinggi
  • NetFlow, sFlow® dan mirroring untuk meningkatkan visibilitas;
  • Konfigurasi QoS (Kualitas Layanan) plus kebijakan;
  • penerowongan melalui Geneve, GRE, VXLAN, STT dan LISP;
  • break control di 802.1ag;
  • OpenFlow 1.0 plus banyak add-on;
  • database transaksional untuk menyimpan konfigurasi dengan binding untuk C dan Python;
  • pengalihan kinerja tinggi menggunakan modul kernel Linux.

Nuage Networks VCS


Layanan Cloud Virtualisasi (VCS) adalah produk dari Nuage, yang merupakan platform berbasis kebijakan yang dapat diskalakan dengan baik untuk membangun jaringan yang ditentukan perangkat lunak (Software-Defined Networking, SDN). Ini adalah solusi tingkat perusahaan, yang didasarkan pada sistem terbuka Open vSwitch (untuk pengalihan data) dan pengontrol SDN multifungsi berdasarkan standar terbuka.

Platform Nuage menggabungkan pod Kubernetes dan lingkungan pihak ketiga (virtual dan perangkat keras) ke dalam jaringan overlay transparan dan memungkinkan Anda untuk menggambarkan kebijakan terperinci untuk berbagai aplikasi. Mesin analisis waktu nyata memungkinkan Anda untuk memantau visibilitas dan keamanan aplikasi Kubernetes.

Selain itu, semua komponen VCS dapat dipasang sebagai wadah. Tidak ada persyaratan perangkat keras khusus.

Kanal


Canal adalah campuran dari dua proyek open source: Calico dan Flannel. Karena itulah namanya. Proyek Flannel, yang dikembangkan oleh tim CoreOS, berkaitan dengan kemampuan jaringan wadah, sementara Calico bertanggung jawab atas kebijakan jaringan. Awalnya, mereka dikembangkan secara terpisah satu sama lain, tetapi pengguna ingin menggunakannya bersama. Proyek open source Canal sekarang menjadi templat penyebaran untuk menginstal Calico dan Flannel sebagai tambahan CNI terpisah. Diciptakan oleh pendiri Calico, Tigera telah mendukung kedua proyek dan bahkan merencanakan integrasi yang lebih ketat, tetapi sejak merilis solusi sendiri untuk jaringan aman antara aplikasi di Kubernetes, prioritas telah bergeser ke arah penyederhanaan konfigurasi dan integrasi Flannel dan Calico daripada mengembangkan solusi terpadu. Dalam gbr. 10.7 menunjukkan status sistem Canal saat ini dan bagaimana hubungannya dengan platform orkestrasi seperti Kubernetes dan Mesos.

gambar

Perhatikan bahwa ketika berintegrasi dengan Kubernetes, Canal tidak mengakses etcd secara langsung, tetapi server API Kubernetes.

Kain flanel


Flannel adalah jaringan virtual yang menyediakan setiap node dengan jaringan virtual untuk bekerja dengan runtimes kontainer. Pada setiap node, agen flaneld diluncurkan, menaikkan subnet berdasarkan ruang alamat yang disimpan yang disimpan dalam cluster etcd. Pertukaran paket antara kontainer dan, pada umumnya, node dibuat oleh salah satu dari beberapa server. Paling sering, server menggunakan UDP melalui perangkat TUN, yang secara default terowongan lalu lintas melalui port 8285 (jangan lupa untuk membukanya di firewall Anda).

Dalam gbr. 10.8 menjelaskan secara rinci berbagai komponen jaringan Flannel, perangkat jaringan virtual yang dibuatnya, dan bagaimana mereka berkomunikasi dengan tuan rumah dan perapian melalui jembatan docker0. Di sini Anda juga dapat melihat proses enkapsulasi paket UDP dan perpindahannya antar node.

gambar

Teknologi jaringan lain didukung:

  • vxlan - mengenkapsulasi paket menggunakan VXLAN di dalam kernel;
  • host-gw - membuat rute IP ke subnet melalui alamat IP server jarak jauh. Perlu dicatat bahwa ini memerlukan koneksi langsung pada lapisan jaringan kedua antara server yang menjalankan Flannel;
  • aws-vpc - Membuat rute IP di tabel routing Amazon VPC
  • gce - membuat rute IP di jaringan Google Compute Engine
  • mengalokasikan - hanya melakukan pemilihan subnet, tetapi bukan pengalihan paket;
  • ali-vpc - Membuat rute IP di tabel perutean VPC Alicloud.

Proyek Calico


Calico adalah solusi lengkap untuk jaringan antara wadah dan keamanan jaringan. Ini dapat diintegrasikan dengan semua platform dan runtime orkestrasi utama:

  • Kubernetes (add-on untuk CNI);
  • Mesos (add-on untuk CNI);
  • Docker (add-on for libnework);
  • OpenStack (add-on untuk Neutron).

Calico juga dapat digunakan secara lokal atau di cloud publik sambil mempertahankan semua fitur. Penerapan kebijakan jaringan dapat bergantung pada beban, yang menyediakan kontrol lalu lintas yang jelas dan memastikan bahwa paket selalu mencapai tujuan yang diinginkan. Calico dapat secara otomatis mengimpor kebijakan jaringan dari platform orkestrasi. Bahkan, dia bertanggung jawab untuk mengimplementasikan kebijakan jaringan di Kubernetes.

Romana


Romana adalah solusi modern untuk jaringan antar wadah. Awalnya dirancang untuk digunakan di cloud dan beroperasi di lapisan jaringan ketiga, mengandalkan metode standar untuk mengelola alamat IP. Romana memungkinkan Anda untuk mengisolasi seluruh jaringan dengan membuat gateway dan rute untuk mereka menggunakan server berbasis Linux. Bekerja di lapisan jaringan ketiga tidak memerlukan enkapsulasi. Kebijakan jaringan diterapkan ke semua titik akhir dan layanan sebagai firewall terdistribusi. Romana memfasilitasi penyebaran hibrida di lokasi dan di antara berbagai platform cloud, karena Anda tidak perlu lagi mengkonfigurasi jaringan hamparan virtual.

Baru-baru ini muncul di Romana alamat IP virtual memungkinkan pengguna lokal untuk membuka akses ke layanan mereka di jaringan lokal tingkat kedua, menggunakan alamat eksternal dan spesifikasi layanan.

Pengembang Romana mengklaim bahwa pendekatan mereka secara signifikan meningkatkan kinerja. Dalam gbr. Gambar 10.9 menunjukkan bagaimana, bersama-sama dengan menghindari enkapsulasi VXLAN, Anda dapat menyingkirkan banyak overhead.

gambar

Menenun jaring


Fitur utama dari proyek Weave Net adalah kemudahan penggunaan dan kurangnya konfigurasi. Ia menggunakan enkapsulasi VXLAN dan menginstal micro-DNS pada setiap node. Sebagai pengembang, Anda akan berurusan dengan abstraksi tingkat tinggi. Setelah Anda memberi nama kontainer Anda, Weave Net akan memungkinkan Anda untuk terhubung ke port standar dan mengaktifkan layanan yang sesuai. Ini membantu dalam memigrasi aplikasi yang sudah ada ke platform layanan-layanan mikro dan wadah. Weave Net menyediakan add-on CNI untuk bekerja dengan Kubernetes dan Mesos. Dimulai dengan Kubernetes 1.4, integrasi dengan Weave Net dapat dilakukan dengan satu perintah yang menggunakan DaemonSet:

kubectl apply -f https://git.io/weave-kube

Pod Weave Net yang di-host pada setiap node bertanggung jawab untuk menghubungkan instance pod lainnya ke jaringan Weave. Weave Net mendukung API dengan kebijakan jaringan, menyediakan solusi yang lengkap dan mudah dikonfigurasikan.

Penggunaan kebijakan jaringan secara efektif


Kebijakan jaringan Kubernetes dirancang untuk mengontrol lalu lintas yang diarahkan ke pod dan ruang nama tertentu. Ketika mengelola ratusan microservices yang dikerahkan (seperti yang sering terjadi dengan Kubernetes), jaringan antara perapian datang ke permukaan. Penting untuk dipahami bahwa mekanisme ini hanya secara tidak langsung terkait dengan keamanan. Jika seorang penyerang dapat menembus jaringan internal, ia kemungkinan besar akan dapat membuat contoh perapian sendiri yang akan mematuhi kebijakan jaringan dan memungkinkan komunikasi bebas dengan perapian lainnya. Pada bagian sebelumnya, kami melihat berbagai solusi jaringan di Kubernetes, yang berfokus pada antarmuka jaringan. Di sini kita akan fokus pada kebijakan jaringan yang diterapkan di atas solusi ini, meskipun kedua komponen tersebut saling terkait erat.

Arsitektur Kebijakan Jaringan di Kubernetes


Kebijakan jaringan menentukan bagaimana himpunan bagian perapian dapat berinteraksi satu sama lain dan dengan titik akhir jaringan lainnya. Sumber daya NetworkPolicy menggunakan label untuk memilih perapian dan mendefinisikan daftar aturan izin yang memungkinkan lalu lintas diarahkan ke mesin virtual perapian tertentu (selain apa yang sudah diizinkan oleh kebijakan isolasi di ruang nama yang diberikan).

»Informasi lebih lanjut tentang buku ini dapat ditemukan di situs web penerbit
» Isi
» Kutipan

Kupon diskon 20% untuk Khabrozhitel - Kubernetes

Setelah pembayaran versi kertas buku, versi elektronik buku dikirim melalui email.

PS: 7% dari biaya buku akan masuk ke terjemahan buku komputer baru, daftar buku yang diserahkan ke percetakan ada di sini .

Source: https://habr.com/ru/post/id441910/

More articles:


All Articles