Edit This Page

Jaringan Kluster

Jaringan adalah bagian utama dari Kubernetes, tetapi bisa menjadi sulit untuk memahami persis bagaimana mengharapkannya bisa bekerja. Ada 4 masalah yang berbeda untuk diatasi:

  1. Komunikasi antar kontainer yang sangat erat: hal ini diselesaikan oleh Pod dan komunikasi localhost.
  2. Komunikasi antar Pod: ini adalah fokus utama dari dokumen ini.
  3. Komunikasi Pod dengan Service: ini terdapat di Service.
  4. Komunikasi eksternal dengan Service: ini terdapat di Service.

Kubernetes adalah tentang berbagi mesin antar aplikasi. Pada dasarnya, saat berbagi mesin harus memastikan bahwa dua aplikasi tidak mencoba menggunakan port yang sama. Mengkoordinasikan port di banyak pengembang sangat sulit dilakukan pada skala yang berbeda dan memaparkan pengguna ke masalah tingkat kluster yang di luar kendali mereka.

Alokasi port yang dinamis membawa banyak komplikasi ke sistem - setiap aplikasi harus menganggap port sebagai flag, server API harus tahu cara memasukkan nomor port dinamis ke dalam blok konfigurasi, Service-Service harus tahu cara menemukan satu sama lain, dll. Sebaliknya daripada berurusan dengan ini, Kubernetes mengambil pendekatan yang berbeda.

Model jaringan Kubernetes

Setiap Pod mendapatkan alamat IP sendiri. Ini berarti kamu tidak perlu secara langsung membuat tautan antara Pod dan kamu hampir tidak perlu berurusan dengan memetakan port kontainer ke port pada host. Ini menciptakan model yang bersih, kompatibel dengan yang sebelumnya dimana Pod dapat diperlakukan seperti halnya VM atau host fisik dari perspektif alokasi port, penamaan, service discovery, load balancing, konfigurasi aplikasi, dan migrasi.

Kubernetes memberlakukan persyaratan mendasar berikut pada setiap implementasi jaringan (kecuali kebijakan segmentasi jaringan yang disengaja):

  • Pod pada suatu Node dapat berkomunikasi dengan semua Pod pada semua Node tanpa NAT
  • agen pada suatu simpul (mis. daemon sistem, kubelet) dapat berkomunikasi dengan semua Pod pada Node itu

Catatan: Untuk platform yang mendukung Pod yang berjalan di jaringan host (mis. Linux):

  • Pod di jaringan host dari sebuah Node dapat berkomunikasi dengan semua Pod pada semua Node tanpa NAT

Model ini tidak hanya sedikit kompleks secara keseluruhan, tetapi pada prinsipnya kompatibel dengan keinginan Kubernetes untuk memungkinkan low-friction porting dari aplikasi dari VM ke kontainer. Jika pekerjaan kamu sebelumnya dijalankan dalam VM, VM kamu memiliki IP dan dapat berbicara dengan VM lain di proyek yang sama. Ini adalah model dasar yang sama.

Alamat IP Kubernetes ada di lingkup Pod - kontainer dalam Pod berbagi jaringan namespace mereka - termasuk alamat IP mereka. Ini berarti bahwa kontainer dalam Pod semua dapat mencapai port satu sama lain di _localhost_. Ini juga berarti bahwa kontainer dalam Pod harus mengoordinasikan penggunaan port, tetapi ini tidak berbeda dari proses di VM. Ini disebut model "IP-per-pod".

Bagaimana menerapkan model jaringan Kubernetes

Ada beberapa cara agar model jaringan ini dapat diimplementasikan. Dokumen ini bukan studi lengkap tentang berbagai metode, tetapi semoga berfungsi sebagai pengantar ke berbagai teknologi dan berfungsi sebagai titik awal.

Opsi jaringan berikut ini disortir berdasarkan abjad - urutan tidak menyiratkan status istimewa apa pun.

ACI

Infrastruktur Sentral Aplikasi Cisco menawarkan solusi SDN overlay dan underlay terintegrasi yang mendukung kontainer, mesin virtual, dan bare metal server. ACI menyediakan integrasi jaringan kontainer untuk ACI. Tinjauan umum integrasi disediakan di sini.

AOS dari Apstra

AOS adalah sistem Jaringan Berbasis Intent yang menciptakan dan mengelola lingkungan pusat data yang kompleks dari platform terintegrasi yang sederhana. AOS memanfaatkan desain terdistribusi sangat scalable untuk menghilangkan pemadaman jaringan sambil meminimalkan biaya.

Desain Referensi AOS saat ini mendukung host yang terhubung dengan Lapis-3 yang menghilangkan masalah peralihan Lapis-2 yang lama. Host Lapis-3 ini bisa berupa server Linux (Debian, Ubuntu, CentOS) yang membuat hubungan tetangga BGP secara langsung dengan top of rack switches (TORs). AOS mengotomatisasi kedekatan perutean dan kemudian memberikan kontrol yang halus atas route health injections (RHI) yang umum dalam deployment Kubernetes.

AOS memiliki banyak kumpulan endpoint REST API yang memungkinkan Kubernetes dengan cepat mengubah kebijakan jaringan berdasarkan persyaratan aplikasi. Peningkatan lebih lanjut akan mengintegrasikan model Grafik AOS yang digunakan untuk desain jaringan dengan penyediaan beban kerja, memungkinkan sistem manajemen ujung ke ujung untuk layanan cloud pribadi dan publik.

AOS mendukung penggunaan peralatan vendor umum dari produsen termasuk Cisco, Arista, Dell, Mellanox, HPE, dan sejumlah besar sistem white-box dan sistem operasi jaringan terbuka seperti Microsoft SONiC, Dell OPX, dan Cumulus Linux.

Detail tentang cara kerja sistem AOS dapat diakses di sini: http://www.apstra.com/products/how-it-works/

AWS VPC CNI untuk Kubernetes

AWS VPC CNI menawarkan jaringan AWS Virtual Private Cloud (VPC) terintegrasi untuk kluster Kubernetes. Plugin CNI ini menawarkan throughput dan ketersediaan tinggi, latensi rendah, dan jitter jaringan minimal. Selain itu, pengguna dapat menerapkan jaringan AWS VPC dan praktik keamanan terbaik untuk membangun kluster Kubernetes. Ini termasuk kemampuan untuk menggunakan catatan aliran VPC, kebijakan perutean VPC, dan grup keamanan untuk isolasi lalu lintas jaringan.

Menggunakan plugin CNI ini memungkinkan Pod Kubernetes memiliki alamat IP yang sama di dalam Pod seperti yang mereka lakukan di jaringan VPC. CNI mengalokasikan AWS Elastic Networking Interfaces (ENIs) ke setiap node Kubernetes dan menggunakan rentang IP sekunder dari setiap ENI untuk Pod pada Node. CNI mencakup kontrol untuk pra-alokasi ENI dan alamat IP untuk waktu mulai Pod yang cepat dan memungkinkan kluster besar hingga 2.000 Node.

Selain itu, CNI dapat dijalankan bersama Calico untuk penegakan kebijakan jaringan. Proyek AWS VPC CNI adalah open source dengan dokumentasi di GitHub.

Big Cloud Fabric dari Big Switch Networks

Big Cloud Fabric adalah arsitektur jaringan asli layanan cloud, yang dirancang untuk menjalankan Kubernetes di lingkungan cloud pribadi / lokal. Dengan menggunakan SDN fisik & virtual terpadu, Big Cloud Fabric menangani masalah yang sering melekat pada jaringan kontainer seperti penyeimbangan muatan, visibilitas, pemecahan masalah, kebijakan keamanan & pemantauan lalu lintas kontainer.

Dengan bantuan arsitektur multi-penyewa Pod virtual pada Big Cloud Fabric, sistem orkestrasi kontainer seperti Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm akan terintegrasi secara alami bersama dengan sistem orkestrasi VM seperti VMware, OpenStack & Nutanix. Pelanggan akan dapat terhubung dengan aman berapa pun jumlah klusternya dan memungkinkan komunikasi antar penyewa di antara mereka jika diperlukan.

Terbaru ini BCF diakui oleh Gartner sebagai visioner dalam Magic Quadrant. Salah satu penyebaran BCF Kubernetes di tempat (yang mencakup Kubernetes, DC/OS & VMware yang berjalan di beberapa DC di berbagai wilayah geografis) juga dirujuk di sini.

Cilium

Cilium adalah perangkat lunak open source untuk menyediakan dan secara transparan mengamankan konektivitas jaringan antar kontainer aplikasi. Cilium mengetahui L7/HTTP dan dapat memberlakukan kebijakan jaringan pada L3-L7 menggunakan model keamanan berbasis identitas yang dipisahkan dari pengalamatan jaringan.

CNI-Genie dari Huawei

CNI-Genie adalah plugin CNI yang memungkinkan Kubernetes [secara bersamaan memiliki akses ke berbagai implementasi](https://github.com/Huawei-PaaS /CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) dari [model jaringan Kubernetes] (https://git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model) dalam runtime. Ini termasuk setiap implementasi yang berjalan sebagai plugin CNI, seperti Flannel, Calico, Romana, Weave-net.

CNI-Genie juga mendukung menetapkan beberapa alamat IP ke sebuah Pod, masing-masing dari plugin CNI yang berbeda.

cni-ipvlan-vpc-k8s

cni-ipvlan-vpc-k8s berisi satu set plugin CNI dan IPAM untuk menyediakan kemudahan, host-lokal, latensi rendah, throughput tinggi , dan tumpukan jaringan yang sesuai untuk Kubernetes dalam lingkungan Amazon Virtual Private Cloud (VPC) dengan memanfaatkan Amazon Elastic Network Interfaces (ENI) dan mengikat IP yang dikelola AWS ke Pod-Pod menggunakan driver IPvlan kernel Linux dalam mode L2.

Plugin ini dirancang untuk secara langsung mengkonfigurasi dan deploy dalam VPC. Kubelet melakukan booting dan kemudian mengkonfigurasi sendiri dan memperbanyak penggunaan IP mereka sesuai kebutuhan tanpa memerlukan kompleksitas yang sering direkomendasikan untuk mengelola jaringan overlay, BGP, menonaktifkan pemeriksaan sumber/tujuan, atau menyesuaikan tabel rute VPC untuk memberikan subnet per instance ke setiap host (yang terbatas hingga 50-100 masukan per VPC). Singkatnya, cni-ipvlan-vpc-k8s secara signifikan mengurangi kompleksitas jaringan yang diperlukan untuk menggunakan Kubernetes yang berskala di dalam AWS.

Contiv

Contiv menyediakan jaringan yang dapat dikonfigurasi (native l3 menggunakan BGP, overlay menggunakan vxlan, classic l2, atau Cisco-SDN / ACI) untuk berbagai kasus penggunaan. Contiv semuanya open sourced.

Contrail / Tungsten Fabric

Contrail, berdasarkan Tungsten Fabric, adalah platform virtualisasi jaringan dan manajemen kebijakan multi-cloud yang benar-benar terbuka. Contrail dan Tungsten Fabric terintegrasi dengan berbagai sistem orkestrasi seperti Kubernetes, OpenShift, OpenStack dan Mesos, dan menyediakan mode isolasi yang berbeda untuk mesin virtual, banyak kontainer / banyak Pod dan beban kerja bare metal.

DANM

[DANM] (https://github.com/nokia/danm) adalah solusi jaringan untuk beban kerja telco yang berjalan di kluster Kubernetes. Dibangun dari komponen-komponen berikut:

  • Plugin CNI yang mampu menyediakan antarmuka IPVLAN dengan fitur-fitur canggih
  • Modul IPAM built-in dengan kemampuan mengelola dengan jumlah banyak, cluster-wide, discontinous jaringan L3 dan menyediakan skema dinamis, statis, atau tidak ada permintaan skema IP
  • Metaplugin CNI yang mampu melampirkan beberapa antarmuka jaringan ke kontainer, baik melalui CNI sendiri, atau mendelegasikan pekerjaan ke salah satu solusi CNI populer seperti SRI-OV, atau Flannel secara paralel
  • Pengontrol Kubernetes yang mampu mengatur secara terpusat antarmuka VxLAN dan VLAN dari semua host Kubernetes
  • Pengontrol Kubernetes lain yang memperluas konsep service discovery berbasis servis untuk bekerja di semua antarmuka jaringan Pod

Dengan toolset ini, DANM dapat memberikan beberapa antarmuka jaringan yang terpisah, kemungkinan untuk menggunakan ujung belakang jaringan yang berbeda dan fitur IPAM canggih untuk Pod.

Flannel

[Flannel] (https://github.com/coreos/flannel#flannel) adalah jaringan overlay yang sangat sederhana yang memenuhi persyaratan Kubernetes. Banyak orang telah melaporkan kesuksesan dengan Flannel dan Kubernetes.

Google Compute Engine (GCE)

Untuk skrip konfigurasi kluster Google Compute Engine, perutean lanjutan digunakan untuk menetapkan setiap VM subnet (standarnya adalah /24 - 254 IP). Setiap lalu lintas yang terikat untuk subnet itu akan dialihkan langsung ke VM oleh fabric jaringan GCE. Ini adalah tambahan untuk alamat IP "utama" yang ditugaskan untuk VM, yang NAT'ed untuk akses internet keluar. Sebuah linux bridge (disebut cbr0) dikonfigurasikan untuk ada pada subnet itu, dan diteruskan ke flag -bridge milik docker.

Docker dimulai dengan:

DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"

Jembatan ini dibuat oleh Kubelet (dikontrol oleh flag --network-plugin=kubenet) sesuai dengan .spec.podCIDR yang dimiliki oleh Node.

Docker sekarang akan mengalokasikan IP dari blok cbr-cidr. Kontainer dapat menjangkau satu sama lain dan Node di atas jembatan cbr0. IP-IP tersebut semuanya dapat dirutekan dalam jaringan proyek GCE.

GCE sendiri tidak tahu apa-apa tentang IP ini, jadi tidak akan NAT untuk lalu lintas internet keluar. Untuk mencapai itu aturan iptables digunakan untuk menyamar (alias SNAT - untuk membuatnya seolah-olah paket berasal dari lalu lintas Node itu sendiri) yang terikat untuk IP di luar jaringan proyek GCE (10.0.0.0/8).

iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE

Terakhir IP forwarding diaktifkan di kernel (sehingga kernel akan memproses paket untuk kontainer yang dijembatani):

sysctl net.ipv4.ip_forward=1

Hasil dari semua ini adalah bahwa semua Pod dapat saling menjangkau dan dapat keluar lalu lintas ke internet.

Jaguar

Jaguar adalah solusi open source untuk jaringan Kubernetes berdasarkan OpenDaylight. Jaguar menyediakan jaringan overlay menggunakan vxlan dan Jaguar CNIPlugin menyediakan satu alamat IP per Pod.

Knitter

Knitter adalah solusi jaringan yang mendukung banyak jaringan di Kubernetes. Solusi ini menyediakan kemampuan manajemen penyewa dan manajemen jaringan. Knitter mencakup satu set solusi jaringan kontainer NFV ujung ke ujung selain beberapa pesawat jaringan, seperti menjaga alamat IP untuk aplikasi, migrasi alamat IP, dll.

Kube-OVN

Kube-OVN adalah fabric jaringan kubernetes berbasis OVN untuk enterprises. Dengan bantuan OVN/OVS, solusi ini menyediakan beberapa fitur jaringan overlay canggih seperti subnet, QoS, alokasi IP statis, mirroring traffic, gateway, kebijakan jaringan berbasis openflow, dan proksi layanan.

Kube-router

Kube-router adalah solusi jaringan yang dibuat khusus untuk Kubernetes yang bertujuan untuk memberikan kinerja tinggi dan kesederhanaan operasional. Kube-router menyediakan Linux LVS/IPVS berbasis proksi layanan, solusi jaringan berbasis penerusan pod-to-pod Linux kernel tanpa overlay, dan penegak kebijakan jaringan berbasis iptables/ipset.

L2 networks and linux bridging

Jika Anda memiliki jaringan L2 yang "bodoh", seperti saklar sederhana di environment "bare-metal", kamu harus dapat melakukan sesuatu yang mirip dengan pengaturan GCE di atas. Perhatikan bahwa petunjuk ini hanya dicoba dengan sangat sederhana - sepertinya berhasil, tetapi belum diuji secara menyeluruh. Jika kamu menggunakan teknik ini dan telah menyempurnakan prosesnya, tolong beri tahu kami.

Ikuti bagian "With Linux Bridge devices" dari tutorial yang sangat bagus ini dari Lars Kellogg-Stedman.

Multus (plugin Multi-Jaringan)

Multus adalah plugin Multi CNI untuk mendukung fitur Banyak Jaringan di Kubernetes menggunakan objek jaringan berbasis CRD di Kubernetes.

Multus mendukung semua plugin referensi (mis. Flannel, DHCP, [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main / macvlan)) yang mengimplementasikan spesifikasi CNI dan plugin pihak ke-3 (mis. Calico, Weave, Cilium, Contiv). Selain itu, Multus mendukung SRIOV, DPDK, OVS- DPDK & VPP beban kerja di Kubernetes dengan aplikasi cloud asli dan aplikasi berbasis NFV di Kubernetes.

NSX-T

VMware NSX-T adalah virtualisasi jaringan dan platform keamanan. NSX-T dapat menyediakan virtualisasi jaringan untuk lingkungan multi-cloud dan multi-hypervisor dan berfokus pada kerangka kerja dan arsitektur aplikasi yang muncul yang memiliki titik akhir dan tumpukan teknologi yang heterogen. Selain hypervisor vSphere, lingkungan ini termasuk hypervisor lainnya seperti KVM, wadah, dan bare metal.

NSX-T Container Plug-in (NCP) menyediakan integrasi antara NSX-T dan pembuat wadah seperti Kubernetes, serta integrasi antara NSX-T dan platform CaaS / PaaS berbasis-kontainer seperti Pivotal Container Service (PKS) dan OpenShift.

Nuage Networks VCS (Layanan Cloud Virtual)

Nuage menyediakan platform SDN (Software-Defined Networking) berbasis kebijakan yang sangat skalabel. Nuage menggunakan Open vSwitch open source untuk data plane bersama dengan SDN Controller yang kaya fitur yang dibangun pada standar terbuka.

Platform Nuage menggunakan overlay untuk menyediakan jaringan berbasis kebijakan yang mulus antara Kubernetes Pod-Pod dan lingkungan non-Kubernetes (VM dan server bare metal). Model abstraksi kebijakan Nuage dirancang dengan mempertimbangkan aplikasi dan membuatnya mudah untuk mendeklarasikan kebijakan berbutir halus untuk aplikasi. Mesin analisis real-time platform memungkinkan pemantauan visibilitas dan keamanan untuk aplikasi Kubernetes.

OpenVSwitch

OpenVSwitch adalah cara yang agak lebih dewasa tetapi juga rumit untuk membangun jaringan overlay. Ini didukung oleh beberapa "Toko Besar" untuk jaringan.

OVN (Open Virtual Networking)

OVN adalah solusi virtualisasi jaringan opensource yang dikembangkan oleh komunitas Open vSwitch. Ini memungkinkan seseorang membuat switch logis, router logis, ACL stateful, load-balancers dll untuk membangun berbagai topologi jaringan virtual. Proyek ini memiliki plugin dan dokumentasi Kubernetes spesifik di ovn-kubernetes.

Project Calico

Project Calico adalah penyedia jaringan wadah sumber terbuka dan mesin kebijakan jaringan.

Calico menyediakan solusi jaringan dan kebijakan kebijakan jaringan yang sangat berskala untuk menghubungkan Pod Kubernetes berdasarkan prinsip jaringan IP yang sama dengan internet, untuk Linux (open source) dan Windows (milik - tersedia dari Tigera). Calico dapat digunakan tanpa enkapsulasi atau overlay untuk menyediakan jaringan pusat data skala tinggi yang berkinerja tinggi. Calico juga menyediakan kebijakan keamanan jaringan berbutir halus, berdasarkan niat untuk Pod Kubernetes melalui firewall terdistribusi.

Calico juga dapat dijalankan dalam mode penegakan kebijakan bersama dengan solusi jaringan lain seperti Flannel, alias kanal, atau jaringan GCE, AWS atau Azure asli.

Romana

Romana adalah jaringan sumber terbuka dan solusi otomasi keamanan yang memungkinkan kamu menggunakan Kubernetes tanpa jaringan hamparan. Romana mendukung Kubernetes Kebijakan Jaringan untuk memberikan isolasi di seluruh ruang nama jaringan.

Weave Net dari Weaveworks

Weave Net adalah jaringan yang tangguh dan mudah digunakan untuk Kubernetes dan aplikasi yang dihostingnya. Weave Net berjalan sebagai plug-in CNI atau berdiri sendiri. Di kedua versi, itu tidak memerlukan konfigurasi atau kode tambahan untuk dijalankan, dan dalam kedua kasus, jaringan menyediakan satu alamat IP per Pod - seperti standar untuk Kubernetes.

Selanjutnya

Desain awal model jaringan dan alasannya, dan beberapa rencana masa depan dijelaskan secara lebih rinci dalam dokumen desain jaringan.