Perbandingan Mesh Layanan Kubernetes

Saat membahas arsitektur layanan mikro dan penampung, satu set alat yang terbukti produksi telah menarik sebagian besar perhatian dalam beberapa tahun terakhir: mesh layanan.

Memang, arsitektur layanan mikro dan Kubernetes (seringkali bergaya "K8s") dengan cepat menjadi norma untuk aplikasi yang dapat diskalakan, menjadikan masalah pengelolaan komunikasi antar layanan menjadi topik hangat—dan jaringan layanan menjadi solusi yang menarik. Saya sendiri pernah menggunakan service mesh dalam produksi, khususnya Linkerd, Istio, dan bentuk Ambassador sebelumnya. Tapi apa sebenarnya yang dilakukan service mesh? Yang mana yang terbaik untuk digunakan? Bagaimana Anda tahu apakah Anda harus menggunakannya sama sekali?

Untuk menjawab pertanyaan-pertanyaan ini, ada baiknya untuk memahami mengapa jejaring layanan dikembangkan. Secara historis, infrastruktur TI tradisional memiliki aplikasi yang berjalan sebagai monolit. Satu layanan berjalan di satu server; jika membutuhkan kapasitas lebih, solusinya adalah menskalakannya secara vertikal dengan menyediakan mesin yang lebih besar.

Mencapai batas pendekatan ini, perusahaan teknologi besar dengan cepat mengadopsi arsitektur tiga tingkat, memisahkan penyeimbang beban dari server aplikasi dan tingkat basis data. Meskipun arsitektur ini tetap dapat diskalakan, mereka memutuskan untuk memecah tingkat aplikasi menjadi layanan mikro. Komunikasi antara layanan ini menjadi penting untuk dipantau dan diamankan agar aplikasi dapat diskalakan.

Untuk memungkinkan komunikasi antar layanan, perusahaan-perusahaan ini mengembangkan perpustakaan internal: Finagle di Twitter, Hystrix di Netflix, dan Stubby di Google (yang menjadi gRPC pada 2016). Pustaka ini bertujuan untuk memperbaiki masalah yang ditimbulkan oleh arsitektur layanan mikro: keamanan antara layanan, latensi, pemantauan, dan penyeimbangan beban. Tetapi mengelola perpustakaan besar sebagai ketergantungan—dalam berbagai bahasa—adalah rumit dan memakan waktu.

Pada akhirnya, jenis perpustakaan itu diganti dengan proxy yang lebih ringan dan lebih mudah digunakan. Proxy tersebut secara eksternal independen dari lapisan aplikasi—berpotensi transparan untuk aplikasi—dan lebih mudah untuk memperbarui, memelihara, dan menyebarkan. Dengan demikian, jaring layanan lahir.

Apa itu Jaring Layanan?

Jala layanan adalah lapisan infrastruktur perangkat lunak untuk mengontrol komunikasi antar layanan; itu umumnya terbuat dari dua komponen:

1. Data plane , yang menangani komunikasi di dekat aplikasi. Biasanya ini digunakan dengan aplikasi sebagai satu set proxy jaringan, seperti yang diilustrasikan sebelumnya.
2. Bidang kontrol, yang merupakan "otak" dari mesh layanan. Bidang kontrol berinteraksi dengan proxy untuk mendorong konfigurasi, memastikan penemuan layanan, dan memusatkan observabilitas.

Jejaring layanan memiliki tiga tujuan utama seputar komunikasi antarlayanan:

1. Konektivitas
2. Keamanan
3. Observabilitas

Konektivitas

Aspek arsitektur mesh layanan ini memungkinkan penemuan layanan dan perutean dinamis. Ini juga mencakup ketahanan komunikasi , seperti percobaan ulang, batas waktu, pemutusan sirkuit, dan pembatasan kecepatan.

Sebuah fitur pokok dari mesh layanan adalah load balancing . Semua layanan yang disatukan oleh proxy memungkinkan penerapan kebijakan penyeimbangan beban antar layanan, seperti permintaan round robin, acak, dan paling sedikit. Kebijakan tersebut adalah strategi yang digunakan oleh mesh layanan untuk memutuskan replika mana yang akan menerima permintaan asli, sama seperti jika Anda memiliki penyeimbang beban kecil di depan setiap layanan.

Akhirnya, mesh layanan menawarkan kontrol perutean dalam bentuk pengalihan lalu lintas dan pencerminan.

Keamanan

Dalam arsitektur layanan mikro tradisional, layanan berkomunikasi di antara mereka sendiri dengan lalu lintas yang tidak terenkripsi. Lalu lintas internal yang tidak terenkripsi saat ini dianggap sebagai praktik buruk dalam hal keamanan, terutama untuk infrastruktur cloud publik dan jaringan tanpa kepercayaan.

Selain melindungi privasi data klien di mana tidak ada kontrol langsung atas perangkat keras, mengenkripsi lalu lintas internal menambahkan lapisan kerumitan ekstra yang disambut baik jika terjadi pelanggaran sistem. Oleh karena itu, semua mesh layanan menggunakan enkripsi mutual TLS (mTLS) untuk komunikasi antar layanan, yaitu, semua komunikasi interproksi.

Jejaring layanan bahkan dapat menerapkan matriks kebijakan otorisasi yang kompleks , mengizinkan atau menolak lalu lintas berdasarkan kebijakan yang menargetkan lingkungan dan layanan tertentu.

Observabilitas

Tujuan dari layanan mesh adalah untuk membawa visibilitas ke komunikasi antar layanan. Dengan mengontrol jaringan, mesh layanan memberlakukan observabilitas, menyediakan metrik tujuh lapis , yang pada gilirannya memungkinkan peringatan otomatis saat lalu lintas mencapai beberapa ambang yang dapat disesuaikan.

Biasanya didukung oleh alat atau plugin pihak ketiga seperti Jaeger atau Zipkin, kontrol semacam itu juga memungkinkan pelacakan dengan menyuntikkan header penelusuran HTTP .

Manfaat Jala Layanan

Jala layanan dibuat untuk mengimbangi beberapa beban operasional yang dibuat oleh arsitektur layanan mikro. Mereka yang berpengalaman dalam arsitektur layanan mikro tahu bahwa mereka membutuhkan banyak pekerjaan untuk beroperasi setiap hari. Mengambil keuntungan penuh dari potensi layanan mikro biasanya memerlukan alat eksternal untuk menangani logging terpusat, manajemen konfigurasi, dan mekanisme skalabilitas, antara lain. Menggunakan mesh layanan menstandarkan kemampuan ini, serta penyiapan dan integrasinya .

Observabilitas mesh layanan, khususnya, menyediakan metode debug dan pengoptimalan yang sangat serbaguna. Berkat visibilitas yang terperinci dan lengkap pada pertukaran antar layanan, engineer—khususnya SRE—dapat lebih cepat memecahkan masalah bug dan kesalahan konfigurasi sistem yang mungkin terjadi. Dengan penelusuran mesh layanan, mereka dapat mengikuti permintaan dari entrinya ke dalam sistem (pada penyeimbang beban atau proxy eksternal) hingga layanan pribadi di dalam tumpukan. Mereka dapat menggunakan logging untuk memetakan permintaan dan merekam latensi yang ditemuinya di setiap layanan. Hasil akhirnya: wawasan mendetail tentang kinerja sistem .

Manajemen lalu lintas memberikan kemungkinan yang kuat sebelum meningkatkan ke rilis penuh versi baru layanan:

1. Rutekan ulang sebagian kecil permintaan.
2. Lebih baik lagi, permintaan produksi cermin ke versi baru untuk menguji perilakunya dengan lalu lintas waktu nyata.
3. Uji A/B layanan atau kombinasi layanan apa pun.

Jejaring layanan menyederhanakan semua skenario di atas, membuatnya lebih mudah untuk menghindari dan/atau mengurangi kejutan apa pun dalam produksi.

Perbandingan Mesh Layanan Kubernetes

Dalam banyak hal, mesh layanan adalah perangkat utama untuk arsitektur layanan mikro; banyak dari mereka berjalan di salah satu alat orkestrasi kontainer teratas, Kubernetes. Kami memilih tiga mesh layanan utama yang berjalan di Kubernetes hari ini: Linkerd (v2), Istio, dan Consul Connect. Kami juga akan membahas beberapa mesh layanan lainnya: Kuma, Traefik Mesh, dan AWS App Mesh. Meskipun saat ini kurang menonjol dalam hal penggunaan dan komunitas, mereka cukup menjanjikan untuk ditinjau di sini dan untuk mengawasi secara umum.

Catatan Singkat Tentang Proksi Sespan

Tidak semua mesh layanan Kubernetes menggunakan pendekatan arsitektur yang sama, tetapi yang umum adalah memanfaatkan pola sidecar. Ini melibatkan melampirkan proxy (sidecar) ke aplikasi utama untuk mencegat dan mengatur lalu lintas jaringan masuk dan keluar dari aplikasi. Dalam praktiknya, ini dilakukan di Kubernetes melalui container sekunder di setiap pod aplikasi yang akan mengikuti siklus hidup container aplikasi.

Ada dua keuntungan utama dari pendekatan sespan untuk jaring servis:

• Proxy sidecar independen dari runtime dan bahkan bahasa pemrograman aplikasi.
  • Ini berarti mudah untuk mengaktifkan semua fitur mesh layanan di mana pun itu akan digunakan, di seluruh tumpukan.
• Sespan memiliki tingkat izin dan akses yang sama ke sumber daya seperti aplikasi.
  • Sidecar dapat membantu memantau sumber daya yang digunakan oleh aplikasi utama, tanpa perlu mengintegrasikan pemantauan ke dalam basis kode aplikasi utama.

Tetapi sespan adalah berkah campuran karena bagaimana mereka berdampak langsung pada aplikasi:

• Inisialisasi sidecar dapat membuat mekanisme awal aplikasi menjadi buntu.
• Proxy sidecar menambahkan potensi latensi di atas aplikasi Anda.
• Proxy sidecar juga menambahkan jejak sumber daya yang dapat menghabiskan banyak uang dalam skala besar.

Mengingat kelebihan dan kekurangan tersebut, pendekatan sespan sering menjadi bahan perdebatan di komunitas jaringan layanan. Yang mengatakan, empat dari enam mesh layanan yang dibandingkan di sini menggunakan proxy sespan Envoy, dan Linkerd menggunakan implementasi sespannya sendiri; Traefik Mesh tidak menggunakan sespan dalam desainnya.

Ulasan Linkerd

Linkerd, yang memulai debutnya pada tahun 2017, adalah mesh layanan tertua di pasar. Dibuat oleh Buoyant (perusahaan yang dimulai oleh dua mantan insinyur Twitter), Linkerd v1 didasarkan pada Finagle dan Netty.

Linkerd v1 digambarkan sebagai yang terdepan karena merupakan mesh layanan yang lengkap dan siap produksi. Pada saat yang sama, itu agak berat dalam hal penggunaan sumber daya. Juga, kesenjangan yang signifikan dalam dokumentasi membuatnya sulit untuk diatur dan dijalankan dalam produksi.

Dengan itu, Buoyant memiliki kesempatan untuk bekerja dengan model produksi yang lengkap, mendapatkan pengalaman darinya, dan menerapkan kebijaksanaan itu. Hasilnya adalah Conduit, Linkerd lengkap menulis ulang perusahaan yang dirilis pada 2018 dan berganti nama menjadi Linkerd v2 akhir tahun itu. Linkerd v2 membawa beberapa peningkatan yang menarik; sejak pengembangan aktif Linkerd v1 Buoyant berhenti sejak lama, penyebutan kami tentang "Linkerd" di seluruh artikel ini mengacu pada v2.

Sepenuhnya open source, Linkerd bergantung pada proxy buatan sendiri yang ditulis dalam Rust untuk bidang data dan pada kode sumber yang ditulis dalam Go untuk bidang kontrol.

Konektivitas

Proxy Linkerd memiliki fitur coba lagi dan batas waktu tetapi tidak memiliki pemutusan sirkuit atau injeksi penundaan pada tulisan ini. Dukungan masuk sangat luas; Linkerd menawarkan integrasi dengan pengontrol ingress berikut:

• Traefik
• Nginx
• GCE
• Duta besar
• gelap
• Kontur
• Kong

Profil layanan di Linkerd menawarkan kemampuan perutean yang ditingkatkan, memberikan metrik pengguna, penyetelan ulang, dan pengaturan batas waktu, semuanya berdasarkan per-rute. Untuk load balancing, Linkerd menawarkan injeksi proxy otomatis, dasbornya sendiri, dan dukungan asli untuk Grafana.

Keamanan

Dukungan mTLS di Linkerd nyaman karena pengaturan awalnya otomatis, seperti halnya rotasi kunci harian otomatis.

Observabilitas

Di luar kotak, statistik dan rute Linkerd dapat diamati melalui CLI. Di sisi GUI, opsi termasuk dasbor Grafana yang sudah jadi dan dasbor Linkerd asli.

Linkerd dapat dihubungkan ke instance Prometheus.

Pelacakan dapat diaktifkan melalui add-on dengan OpenTelemetry (sebelumnya OpenCensus) sebagai kolektor, dan Jaeger melakukan pelacakan itu sendiri.

Instalasi

Instalasi Linkerd dilakukan dengan menyuntikkan proxy sidecar, yang dilakukan dengan menambahkan anotasi ke resource Anda di Kubernetes. Ada dua cara untuk melakukannya:

1. Menggunakan grafik Helm. (Bagi banyak orang, Helm adalah konfigurasi masuk dan pengelola template untuk sumber daya Kubernetes.)
2. Menginstal Linkerd CLI, kemudian menggunakannya untuk menginstal Linkerd ke dalam sebuah cluster.

Metode kedua dimulai dengan mengunduh dan menjalankan skrip instalasi:

 curl -sL https://run.linkerd.io/install | sh

Dari sana, alat Linkerd CLI linkerd menyediakan alat yang berguna yang membantu menginstal sisa Linkerd dan berinteraksi dengan kluster aplikasi dan bidang kontrol.

linkerd check --pre akan menjalankan semua pemeriksaan awal yang diperlukan untuk pemasangan Linkerd Anda, memberikan log yang jelas dan tepat tentang mengapa pemasangan Linkerd potensial mungkin belum berfungsi. Tanpa --pre , perintah ini dapat digunakan untuk debugging pasca-instalasi.

Langkah selanjutnya adalah menginstal Linkerd di cluster dengan menjalankan:

 linkerd install | kubectl apply -f -

Linkerd kemudian akan menginstal banyak komponen berbeda dengan jejak sumber daya yang sangat kecil; karenanya, mereka sendiri memiliki pendekatan layanan mikro:

• linkerd-controller , yang menyediakan API publik tempat CLI dan dasbor berinteraksi
• linkerd-identity , yang memberikan otoritas sertifikat untuk mengimplementasikan mTLS
• linkerd-proxy-injector , yang menangani injeksi proxy dengan mengubah konfigurasi pod
• linkerd-web , yang menyajikan dasbor yang memungkinkan pemantauan penerapan dan pod, serta komponen Linkerd internal

Linkerd mendasarkan sebagian besar konfigurasinya pada CustomResourceDefinitions (CRDs). Ini dianggap sebagai praktik terbaik saat mengembangkan perangkat lunak tambahan Kubernetes—seperti memasang plug-in secara tahan lama di kluster Kubernetes.

Menambahkan pelacakan terdistribusi—yang mungkin atau mungkin bukan apa yang sebenarnya diinginkan oleh pengguna Linkerd, karena beberapa mitos umum—memerlukan langkah lain dengan linkerd-collector dan linkerd-jaeger. Untuk itu, pertama-tama kita akan membuat file konfigurasi:

 cat >> config.yaml << EOF tracing: enabled: true EOF

Untuk mengaktifkan pelacakan, kami akan menjalankan:

 linkerd upgrade --config config.yaml | kubectl apply -f -

Seperti halnya jaring layanan apa pun yang didasarkan pada proxy sespan, Anda perlu memodifikasi kode aplikasi Anda untuk mengaktifkan pelacakan. Sebagian besar dari ini hanyalah menambahkan pustaka klien untuk menyebarkan header penelusuran; itu kemudian perlu dimasukkan dalam setiap layanan.

Fitur pemisahan lalu lintas Linkerd, yang diekspos melalui API yang sesuai dengan Service Mesh Interface (SMI), sudah memungkinkan rilis canary. Tetapi untuk mengotomatisasi mereka dan manajemen lalu lintas, Anda juga memerlukan alat eksternal seperti Flagger.

Flagger adalah alat pengiriman progresif yang akan menilai apa yang disebut Linkerd sebagai metrik "emas" : "volume permintaan, tingkat keberhasilan, dan distribusi latensi." (Awalnya, Google SRE menggunakan istilah sinyal emas dan menyertakan yang keempat—saturasi—tetapi Linkerd tidak mencakupnya karena itu akan memerlukan metrik yang tidak dapat diakses secara langsung, seperti penggunaan CPU dan memori.) Flagger melacak ini sambil membagi lalu lintas menggunakan loop umpan balik; oleh karena itu, Anda dapat menerapkan rilis kenari otomatis dan sadar metrik.

Setelah mempelajari proses instalasi, menjadi jelas bahwa untuk memiliki jaringan layanan Linkerd yang beroperasi dan mengeksploitasi kemampuan yang diinginkan secara umum, mudah untuk mengakhiri setidaknya selusin layanan yang berjalan. Yang mengatakan, lebih dari mereka dipasok oleh Linkerd pada saat instalasi dibandingkan dengan jerat layanan lainnya.

Ringkasan Mesh Layanan Linkerd

Keuntungan:

Linkerd mendapat manfaat dari pengalaman pembuatnya, dua mantan insinyur Twitter yang pernah mengerjakan alat internal, Finagle, dan kemudian belajar dari Linkerd v1. Sebagai salah satu jaringan layanan pertama, Linkerd memiliki komunitas yang berkembang (Slack-nya memiliki lebih dari 5.000 pengguna, ditambah lagi memiliki milis aktif dan server Discord) dan serangkaian dokumentasi dan tutorial yang ekstensif. Linkerd matang dengan rilis versi 2.9, sebagaimana dibuktikan oleh adopsi oleh perusahaan besar seperti Nordstrom, eBay, Strava, Expedia, dan Subspace. Dukungan berbayar tingkat perusahaan dari Buoyant tersedia untuk Linkerd.

Kekurangan:

Ada kurva pembelajaran yang cukup kuat untuk menggunakan jaringan layanan Linkerd secara maksimal. Linkerd hanya didukung di dalam container Kubernetes (yaitu, tidak ada mode “universal” berbasis VM). Proksi sespan Linkerd bukan Utusan. Meskipun ini memungkinkan Buoyant untuk menyetelnya sesuai keinginan mereka, ini menghilangkan ekstensibilitas bawaan yang ditawarkan Envoy. Ini juga berarti Linkerd kehilangan dukungan untuk pemutusan sirkuit, injeksi penundaan, dan pembatasan kecepatan. Tidak ada API tertentu yang diekspos untuk mengontrol bidang kontrol Linkerd dengan mudah. (Namun, Anda dapat menemukan pengikatan API gRPC.)

Linkerd telah membuat kemajuan besar sejak v1 dalam kegunaan dan kemudahan instalasi. Kurangnya API yang diekspos secara resmi adalah kelalaian yang mencolok. Namun berkat dokumentasi yang dipikirkan dengan matang, fungsionalitas out-of-the-box di Linkerd mudah untuk diuji.

Ulasan Konsul Connect

Pesaing mesh layanan kami berikutnya, Consul Connect, adalah hybrid yang unik. Konsul dari HashiCorp lebih dikenal dengan penyimpanan nilai kuncinya untuk arsitektur terdistribusi, yang telah ada selama bertahun-tahun. Setelah evolusi Consul menjadi rangkaian lengkap alat layanan, HashiCorp memutuskan untuk membangun jaringan layanan di atasnya: Consul Connect.

Lebih tepatnya tentang sifat hibridanya:

Data plane Consul Connect didasarkan pada Envoy, yang ditulis dalam C++. Bidang kontrol Konsul Connect ditulis dalam Go. Ini adalah bagian yang didukung oleh Konsul KV, toko nilai kunci.

Seperti kebanyakan mesh layanan lainnya, Consul Connect bekerja dengan menyuntikkan proxy sespan ke dalam pod aplikasi Anda. Dalam hal arsitektur, Consul Connect berbasis di sekitar agen dan server . Di luar kotak, Konsul Connect dimaksudkan untuk memiliki ketersediaan tinggi (HA) menggunakan tiga atau lima server sebagai StatefulSet yang menentukan pod anti-afinitas. Anti-afinitas pod adalah praktik memastikan pod dari sistem perangkat lunak terdistribusi tidak akan berakhir di node (server) yang sama, sehingga menjamin ketersediaan jika ada satu node yang gagal.

Konektivitas

Tidak banyak yang membuat Konsul Connect menonjol di area ini; ini menyediakan apa yang dilakukan oleh setiap mesh layanan (yang cukup sedikit), ditambah fitur lapisan tujuh untuk perutean berbasis jalur, pengalihan lalu lintas, dan penyeimbangan beban.

Keamanan

Seperti mesh layanan lainnya, Consul Connect menyediakan kemampuan mTLS dasar. Ini juga menampilkan integrasi asli antara Consul dan Vault (juga oleh HashiCorp), yang dapat digunakan sebagai penyedia CA untuk mengelola dan menandatangani sertifikat dalam sebuah cluster.

Observabilitas

Consul Connect mengambil pendekatan observabilitas yang paling umum dengan memasukkan Envoy sebagai proxy sespan untuk menyediakan kemampuan lapisan tujuh. Mengonfigurasi UI Consul Connect untuk mengambil metrik melibatkan perubahan file konfigurasi bawaan dan juga mengaktifkan penyedia metrik seperti Prometheus. Anda juga dapat mengonfigurasi beberapa dasbor Grafana untuk menampilkan metrik khusus layanan yang relevan.

Instalasi

Consul Connect diinstal ke dalam cluster Kubernetes menggunakan diagram Helm:

 helm repo add hashicorp https://helm.releases.hashicorp.com

Anda perlu mengubah nilai values.yaml jika Anda ingin mengaktifkan UI atau membuat modul Consul Connect menyuntikkan proxy sespannya:

 helm install -f consul-values.yml hashicorp hashicorp/consul

Untuk berkonsultasi dengan anggota dan memeriksa berbagai node, Consul merekomendasikan untuk exec ke salah satu wadah kemudian menggunakan alat CLI consul .

Untuk menyajikan UI web siap pakai yang disediakan Konsul, jalankan kubectl port-forward service/hashicorp-consul-ui 18500:80 .

Ringkasan Jala Layanan Konsul Connect

Keuntungan:

• Konsul didukung oleh HashiCorp; sebagai produk freemium, ada juga versi perusahaan dengan fitur tambahan yang menawarkan dukungan tingkat perusahaan. Dalam hal pengalaman tim pengembangan, Konsul adalah salah satu alat tertua di pasar.
• Consul memiliki komunitas perusahaan yang solid dan dikenal berjalan di infrastruktur dengan 50.000 node. Juga, sudah ada sejak 2014, menjadikannya produk yang matang relatif terhadap pasar.
• Consul Connect berjalan dengan baik di dalam VM, berkat dukungan asli.
• Dengan Consul Connect, adalah mungkin untuk mencapai integrasi aplikasi sedalam implementasi pra-layanan-mesh di perusahaan teknologi tingkat atas. Ini berkat pemaparan API tingkat perpustakaan yang terdokumentasi sepenuhnya.

Kekurangan:

• Consul Connect memiliki kurva pembelajaran yang lebih curam daripada jaringan layanan lainnya dan akan membutuhkan lebih banyak penyesuaian untuk menjalankan dasbor dan metrik visual.
• Dokumentasi HashiCorp tidak mudah, membuat pengguna harus menggali dan bereksperimen untuk mengkonfigurasinya dengan benar.
• Dokumentasi manajemen lalu lintas sulit ditemukan dan sebagian besar terdiri dari tautan ke dokumentasi Envoy, yang tidak memberikan detail tentang manajemen lalu lintas Konsul Connect secara khusus.
• Antarmuka SMI Konsul Connect masih eksperimental.

Consul Connect dapat menjadi pilihan yang sangat baik bagi mereka yang mencari produk kelas perusahaan. HashiCorp dikenal dengan kualitas produknya, tidak terkecuali Konsul Connect. Saya dapat melihat dua keunggulan kuat di sini dibandingkan dengan jaringan layanan lainnya: dukungan kuat dari perusahaan dengan versi perusahaan dan alat yang siap untuk semua jenis arsitektur (bukan hanya Kubernetes).

Ulasan Istio

Pada Mei 2017, Google, IBM, dan Lyft mengumumkan Istio. Ketika Istio memasuki perlombaan alat jala layanan, ia memperoleh eksposur yang sangat baik di ruang teknologi. Penulisnya telah menambahkan fitur berdasarkan umpan balik pengguna hingga versi 1.9.

Istio menjanjikan fitur-fitur baru yang penting dibandingkan para pesaingnya saat itu: penyeimbangan muatan otomatis, injeksi kesalahan, dan banyak lagi. Hal ini mendapatkan banyak perhatian dari komunitas, tetapi seperti yang akan kami jelaskan di bawah ini, menggunakan Istio jauh dari hal yang sepele: Istio telah diakui sangat rumit untuk diproduksi.

Secara historis, proyek Istio sering terpental dalam hal perubahan kode sumber. Setelah mengadopsi arsitektur layanan mikro untuk bidang kontrol, Istio kini (sejak versi 1.5) pindah kembali ke arsitektur monolitik. Alasan Istio untuk kembali ke sentralisasi adalah bahwa layanan mikro sulit untuk dipantau oleh operator, basis kode terlalu berlebihan, dan proyek telah mencapai kematangan organisasi—tidak perlu lagi memiliki banyak tim kecil yang bekerja dalam silo.

Namun, di sepanjang jalan, Istio menjadi terkenal karena memiliki salah satu masalah GitHub terbuka dengan volume tertinggi. Pada tulisan ini, hitungan berdiri di sekitar 800 masalah terbuka dan sekitar 12.000 ditutup. Meskipun jumlah masalah dapat menipu, dalam hal ini, jumlah masalah menunjukkan peningkatan yang berarti dalam hal fitur yang sebelumnya rusak dan penggunaan sumber daya yang tidak terkendali.

Konektivitas

Istio cukup kuat dalam manajemen lalu lintas dibandingkan dengan Konsul Connect dan Linkerd. Ini berkat penawaran ekstensif dari sub-fitur: perutean permintaan, injeksi kesalahan, pengalihan lalu lintas, batas waktu permintaan, pemutusan sirkuit, dan pengendalian lalu lintas masuk dan keluar ke mesh layanan. Pengertian layanan virtual dan aturan tujuan membuatnya sangat lengkap dalam hal manajemen lalu lintas.

Namun, semua kemungkinan itu datang dengan kurva pembelajaran, ditambah pengelolaan sumber daya baru tersebut di klaster Kubernetes Anda.

Keamanan

Istio menawarkan seperangkat alat terkait keamanan yang komprehensif, dengan dua sumbu utama: otentikasi dan otorisasi. Istio dapat menerapkan berbagai tingkat kebijakan pada cakupan yang berbeda: spesifik beban kerja, namespacewide, atau meshwide. Semua sumber daya keamanan tersebut dikelola melalui Istio CRD seperti AuthorizationPolicy atau PeerAuthentication .

Di luar dukungan mTLS standar, Istio juga dapat dikonfigurasi untuk menerima atau menolak lalu lintas yang tidak terenkripsi.

Observabilitas

Di sini, Istio cukup canggih di luar kotak, dengan beberapa jenis telemetri yang menawarkan wawasan yang solid ke dalam jaringan layanan. Metrik didasarkan pada empat sinyal emas (latensi, lalu lintas, kesalahan, dan, sampai batas tertentu, saturasi).

Khususnya, Istio menyediakan metrik untuk bidang kontrol itu sendiri. Ini juga melayani pelacakan terdistribusi dan log akses, menawarkan kompatibilitas eksplisit dengan Jaeger, Lightstep, dan Zipkin untuk mengaktifkan pelacakan.

Tidak ada dasbor asli, tetapi ada dukungan resmi untuk konsol manajemen Kiali.

Instalasi

Instalasi semudah mengikuti langkah-langkah resmi. Istio juga terintegrasi secara native ke GKE sebagai fitur beta, tetapi di sana GKE menggunakan Istio 1.4.X, versi layanan mikro yang lebih lama sebagai lawan dari versi monolit terbaru.

Penginstalan asli dimulai dengan mengunduh rilis terbaru:

 curl -L https://istio.io/downloadIstio | sh -

Setelah cd ke folder istio-* yang baru dibuat, Anda dapat menambahkannya ke jalur Anda sehingga Anda dapat menggunakan alat utilitas istioctl :

 export PATH=$PWD/bin:$PATH

Dari sana, Anda dapat menginstal Istio ke cluster Kubernetes Anda melalui istioctl :

 istioctl install

Ini akan menginstal Istio dengan profil default . Profil istioctl memungkinkan Anda untuk membuat konfigurasi instalasi yang berbeda dan beralih di antara mereka jika perlu. Tetapi bahkan dalam skenario profil tunggal, Anda dapat menyesuaikan instalasi Istio secara mendalam dengan memodifikasi beberapa CRD.

Sumber daya Istio akan lebih sulit untuk dikelola karena Anda perlu mengelola beberapa jenis CRD— VirtualService , DestinationRule , dan Gateway minimal—untuk memastikan manajemen lalu lintas sudah ada.

• Sumber daya VirtualService adalah konfigurasi yang mendeklarasikan layanan dan aturan perutean berbeda yang diterapkan pada permintaan.
• Resource DestinationRule digunakan untuk mengelompokkan dan menerapkan kebijakan traffic spesifik target.
• Sumber daya Gateway dibuat untuk mengelola lalu lintas mesh layanan masuk dan keluar (yaitu, proxy utusan tambahan, tetapi berjalan di tepi daripada sebagai sidecars.)

Detail semantik berada di luar cakupan ulasan ini, tetapi mari kita lihat contoh singkat yang menunjukkan masing-masing bekerja bersama. Misalkan kita memiliki situs web e-niaga dengan layanan yang disebut products . VirtualService kami mungkin terlihat seperti ini:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

DestinationRule yang sesuai dapat berupa:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

Terakhir, Gateway kami:

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

Dengan tiga file ini, instalasi Istio akan siap menangani lalu lintas dasar.

Ringkasan Mesh Layanan Istio

Keuntungan:

• Di antara jaringan layanan yang berbeda, Istio adalah yang memiliki komunitas online terbesar pada tulisan ini. Dengan lebih dari 10 kali hasil Stack Overflow sebagai salah satu pesaing utamanya, ini adalah mesh layanan yang paling banyak dibicarakan di web; kontributor GitHub-nya juga merupakan urutan besarnya di luar yang dimiliki Linkerd.
• Istio mendukung mode Kubernetes dan VM; yang terakhir dalam versi beta pada versi 1.9.

Kekurangan:

• Istio tidak bebas, dalam dua pengertian:
  • Persyaratannya tinggi dalam hal waktu yang dibutuhkan untuk membaca dokumentasi, mengaturnya, membuatnya bekerja dengan benar, dan memeliharanya. Bergantung pada ukuran infrastruktur dan jumlah layanan, Istio akan membutuhkan waktu beberapa minggu hingga beberapa bulan untuk bekerja penuh waktu agar berfungsi penuh dan diintegrasikan ke dalam produksi.
  • Ini juga menambahkan sejumlah besar overhead sumber daya: Dibutuhkan 350 milicore (mCPU) untuk wadah Envoy per 1.000 permintaan per detik (RPS). Bahkan control plane itu sendiri dapat memakan sumber daya. (Sebelumnya, penggunaan sumber daya akan sulit diprediksi, tetapi setelah beberapa upaya, istiod telah stabil dengan menggunakan 1 vCPU dan memori 1,5 GB.)
• Itu tidak memiliki dasbor admin asli, tidak seperti Linkerd.
• Istio membutuhkan penggunaan gateway masuknya sendiri.
• Bidang kontrol Istio hanya didukung dalam wadah Kubernetes (yaitu, tidak ada mode VM, tidak seperti bidang data Istio).

Istio adalah contoh hebat dari raksasa teknologi yang bersatu untuk membuat proyek sumber terbuka untuk mengatasi tantangan yang mereka semua hadapi. Butuh beberapa waktu untuk proyek Istio secara keseluruhan untuk menyusun dirinya sendiri (mengingat pergeseran arsitektur microservices-to-monolith) dan menyelesaikan banyak masalah awalnya. Hari ini, Istio benar-benar melakukan semua yang diharapkan dari jaringan layanan dan dapat sangat diperluas. Tapi semua kemungkinan ini datang dengan persyaratan curam dalam hal pengetahuan, jam kerja, dan sumber daya komputasi untuk mendukung penggunaannya dalam lingkungan produksi.

Ulasan Cepat Kuma

Dibuat oleh Kong dan kemudian open-source, Kuma mencapai 1.0 pada akhir 2020. Sampai batas tertentu, itu dibuat sebagai tanggapan terhadap mesh layanan pertama yang agak berat dan sulit dioperasikan.

Daftar fiturnya menunjukkan bahwa itu sangat modular; ide di balik Kuma adalah mengarahkannya ke integrasi dengan aplikasi yang sudah berjalan di Kubernetes atau infrastruktur lainnya.

• Di bidang manajemen lalu lintas , Kuma menawarkan fitur jala layanan umum seperti injeksi kesalahan dan pemutusan sirkuit.
• Di luar enkripsi mTLS antarlayanan, pertukaran antara bidang data dan bidang kontrol diamankan di Kuma melalui token proxy bidang data .
• Observabilitas didefinisikan di Kuma melalui kebijakan lalu lintas yang berbeda seputar metrik, penelusuran, dan pencatatan.
• Penemuan layanan tersedia melalui Kuma berkat resolver DNS-nya sendiri yang berjalan pada port 5653 bidang kontrol.
• Kuma memiliki penekanan kuat pada fungsionalitas multimesh : Anda dapat dengan mudah menggabungkan beberapa cluster Kubernetes atau lingkungan VM ke dalam cluster Kuma umum dengan tipe penerapan multizonanya.
• Kuma dengan mudah terintegrasi dengan Kong Gateway untuk pengguna Kong yang sudah ada.

Kuma versi universal (non-Kubernetes) membutuhkan PostgreSQL sebagai dependensi, dan CTO Kong sangat menentang dukungan SMI. Tetapi Kuma dikembangkan dengan ide penerapan multicloud dan multicluster sejak awal, dan dasbornya mencerminkan hal ini.

Sementara Kuma masih muda di ruang mesh layanan, dengan beberapa kasus penggunaan produksi sejauh ini, ini adalah pesaing yang menarik dan menjanjikan.

Ulasan Singkat Traefik Mesh

Awalnya bernama Maesh, Traefik Mesh (oleh Traefik Labs) adalah pendatang baru lainnya dalam perlombaan perkakas mesh layanan. Misi proyek adalah mendemokratisasikan mesh layanan dengan membuatnya mudah digunakan dan dikonfigurasi; pengalaman pengembang dengan Traefik Proxy yang dipikirkan dengan matang menempatkan mereka pada posisi utama untuk mencapainya.

• Fitur manajemen lalu lintas di Traefik Mesh termasuk pemutusan sirkuit dan pembatasan kecepatan.
• Dalam hal observabilitas , Traefik Mesh menampilkan Dukungan OpenTracing asli dan metrik yang siap pakai (instalasi standar secara otomatis menyertakan Prometheus dan Grafana), yang menghemat waktu penyiapan.
• Untuk keamanan — selain dari mTLS — spesifikasinya sesuai dengan SMI dan Traefik Mesh memungkinkan penyetelan izin lalu lintas melalui kontrol akses.

Traefik Mesh membutuhkan CoreDNS untuk diinstal di cluster. (Meskipun Azure telah menggunakan CoreDNS secara default sejak 1.12, GKE default ke kube-dns pada tulisan ini, yang berarti ada langkah ekstra signifikan yang terlibat dalam kasus itu.) Ini juga tidak memiliki kemampuan multicluster.

Yang mengatakan, Traefik Mesh unik dalam perbandingan mesh layanan kami karena tidak menggunakan injeksi sespan. Sebagai gantinya, ini digunakan sebagai DaemonSet di semua node untuk bertindak sebagai proxy antar layanan, menjadikannya non-invasif. Secara keseluruhan, Traefik Mesh mudah dipasang dan digunakan.

Ulasan Cepat AWS App Mesh

Di dunia penyedia cloud, AWS adalah yang pertama menerapkan layanan mesh pluggable asli dengan Kubernetes (atau EKS khususnya) tetapi juga layanan lainnya. AWS App Mesh dirilis pada November 2018 dan AWS telah melakukan iterasi sejak saat itu. Keuntungan utama AWS App Mesh adalah ekosistem AWS dan posisi pasar yang sudah ada sebelumnya; komunitas besar di belakang AWS secara keseluruhan akan terus mendorong penggunaan dan kegunaannya.

• Manajemen lalu lintas di AWS App Mesh mencakup pemutusan sirkuit di atas fitur-fitur umum.
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

Infrastruktur

Traffic Management

Observability

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

Penyebaran

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.