Orang-orang Datawire dan saya baru-baru ini kembali dari konferensi KubeCon dan CloudNativeCon yang menakjubkan di Barcelona. Kami berpartisipasi dalam 6 pertunjukan di KubeCon, membagikan banyak kaus keren (tanpa kesederhanaan palsu) di stan kami, berbicara dengan lusinan orang dan menghadiri pertunjukan keren. Ada begitu banyak hal menarik di KubeCon EU sehingga saya memutuskan untuk menulis posting dengan hasil utama.
Dan inilah kesimpulan yang saya buat (bukan dalam urutan kepentingan):
- Cross-platform dan hybrid cloud (masih) sangat populer.
- Integrasi teknologi mendapatkan momentum.
- Pengumuman Service Mesh Interface (SMI): Tetap pantau.
- (Hazy?) Masa depan Istio.
- Politik sebagai kode naik tumpukan.
- Cloud DevEx masih bukan tanpa masalah.
- Perusahaan (masih) pada tahap awal adopsi teknologi.
- Kubernet lokal nyata (tapi mudah diingat).
- Pertimbangkan kelompok dan kelompok.
- Keberhasilan Kubernetes masih bergantung pada komunitas.
Ada beberapa presentasi di konferensi tentang multi-cloud (dan isu-isu terkait: jaringan dan keamanan ), tetapi saya perhatikan bahwa banyak slide pengantar tentang laporan pengguna akhir menggambarkan infrastruktur atau arsitektur dengan setidaknya dua penyedia cloud. Di stan Datawire, kami berbicara tentang tren transisi multi-cloud lebih sering daripada di konferensi sebelumnya.
Keberhasilan Kubernetes telah sangat menyederhanakan strategi multi-cloudnya, memberikan abstraksi yang sangat baik untuk pengiriman dan orkestrasi. Dalam dua tahun terakhir, fungsionalitas dan API Kubernet menjadi jauh lebih stabil, dan banyak vendor menggunakan platform ini. Kemampuan manajemen penyimpanan dan konektivitas jaringan telah meningkat, dan ada cukup banyak produk dan solusi komersial open source di bidang ini. Dalam ceramahnya, "Membongkar Mitos: Sulit Membangun Penyimpanan di Kubernetes," Saad Ali, pengembang senior Google, berbicara tentang fasilitas penyimpanan dengan cara yang menarik, dan Eran Yanay dari Twistlock menyajikan tinjauan yang baik tentang koneksi dalam "Koneksi di Kubernetes: cara menulis plugin CNI dari awal . "
Saya terutama menyukai berbagai percakapan tentang menggabungkan Azure dengan infrastruktur lokal yang ada. Saya baru-baru menulis sebuah artikel di InfoQ tentang bagaimana arsitektur multi-platform berhubungan dengan bekerja pada peningkatan aplikasi . Saya berbicara tentang tiga pendekatan: memperluas cloud ke pusat data, seperti pada Azure Stack , AWS Outposts dan GCP Anthos ; memastikan keseragaman struktur pasokan (orkestrasi) di antara beberapa pemasok atau cloud menggunakan platform seperti Kubernetes; memastikan keseragaman struktur layanan (jaringan) menggunakan gateway API dan service mesh, seperti Duta Besar dan Konsul .
Kami di Datawire bekerja keras pada gateway API dan, jelas, condong ke arah pendekatan ketiga yang fleksibel. Ini memungkinkan Anda untuk secara bertahap dan aman bermigrasi dari tumpukan tradisional yang lebih dekat ke cloud. HashiCorp dan Nick Jackson dan saya berbicara di KubeCon dengan kuliah tentang "Memastikan konektivitas cloud dari pengguna akhir ke layanan . "
Teknologi Menggabungkan Mendapatkan Momentum
Banyak vendor menawarkan paket dengan alat Kubernetes dan teknologi tambahan. Saya menarik perhatian pada pengumuman Rio MicroPaaS dari Rancher Labs - baru-baru ini mereka telah menghasilkan hal-hal yang menarik. Saya menulis ulasan di InfoQ tentang Submariner , yang menghubungkan banyak kluster, dan k3 distribusi ringan Kubernet . Dan saya ingin sekali belajar Kubernetes Toolkit Supergiant . Ini adalah "seperangkat utilitas untuk mengotomatisasi pasokan dan manajemen kluster Kubernetes di cloud."
Dalam lingkungan perusahaan, paket diarahkan ke penyimpanan. Contoh yang baik adalah VMware Velero 1.0 (berdasarkan pengembangan yang dibeli dari Heptio ), yang dengannya pengembang dapat memesan dan memigrasi sumber daya Kubernetes dan volume persisten.
Banyak operator lain untuk menyimpan dan mengelola data di Kubernetes, seperti CockroachDB , ElasticCloud, dan StorageOS , diwakili di konferensi . Red Hat Rob Szumski dari Red Hat berbicara tentang evolusi SDK Operator dan masyarakat dan memperkenalkan Hub Operator . Rupanya, dukungan operator adalah salah satu manfaat utama rangkaian perusahaan OpenShift Red Hat .
Pengumuman Service Mesh Interface (SMI): Tetap pantau
Pengumuman Service Mesh Interface (SMI) dalam laporan Gabe Monroy dari Microsoft jelas membuat banyak kebisingan . Tidak ada yang akan menyangkal bahwa mesh layanan telah sangat populer akhir-akhir ini, dan SMI akan menggabungkan fitur-fitur utama ke dalam antarmuka standar dan menyediakan "satu set API portabel umum yang akan memastikan interoperabilitas antara berbagai teknologi layanan mesh, termasuk Istio, Linkerd dan Consul Connect".
Dalam demo tersebut, Gabe menunjukkan fitur-fitur utama: kebijakan lalu lintas untuk menerapkan kebijakan seperti kredensial dan enkripsi transit antara layanan (menggunakan Konsul dan Intensi sebagai contoh); pemantauan lalu lintas - mengumpulkan metrik utama, misalnya, jumlah kesalahan dan keterlambatan bertukar data antara layanan (menggunakan Linkerd dan server metrik SMI sebagai contoh); dan manajemen lalu lintas - mengukur dan mentransfer lalu lintas antara berbagai layanan (misalnya, Istio dengan Weaveworks Flagger ).
Akan menarik untuk mendefinisikan antarmuka dalam lingkungan yang sangat kompetitif ini, tetapi saya pergi ke situs web SMI , membaca spesifikasi dan menduga bahwa abstraksi ini dapat dikurangi menjadi sekumpulan fungsi umum minimal (ini selalu sulit untuk dihindari dalam solusi seperti yang saya tahu dengan cara saya sendiri. Pengalaman Proses Komunitas Jawa). Bahaya potensial adalah bahwa meskipun semua orang akan menerapkan spesifikasi ini, vendor akan memberikan fitur yang paling menarik melalui ekstensi khusus.
Saya membicarakan hal ini dengan orang-orang dari Datawire dan saya berpikir bahwa service mesh ada di pasar yang bekerja berdasarkan prinsip "pemenang mendapatkan segalanya", jadi pada akhirnya, SMI akan mengalihkan perhatian, dan teknologi lain hanya akan muncul dan mengumpulkan semua manfaat ( sesuatu seperti Kubernet lakukan dengan Mesos, Docker Swarm, dll.). Ikuti berita, lihat apa yang terjadi.
(Hazy?) Masa depan Istio
Meskipun banyak yang telah dikatakan tentang service mesh, tema Istio - mungkin service mesh yang paling terkenal - telah dicampur. Seseorang percaya bahwa Istio dan service mesh adalah sinonim (seperti Docker dan wadah) dan hanya melihat solusi, bukan masalah; Seseorang menyukai fitur Istio; dan seseorang tidak terlalu senang dengan teknologi ini.
Ada banyak diskusi tentang tolok ukur Istio baru-baru ini , dan dalam Rilis 1.1, beberapa masalah dengan komponen Mixer sengaja diselesaikan . Menariknya, saya berbicara dengan orang yang berbeda yang mengevaluasi Istio selama beberapa bulan (satu tim menghabiskan waktu hampir setahun untuk ini), dan mereka mengklaim bahwa Istio masih sangat kompleks dan padat sumber daya. Seseorang mengatakan bahwa mengeluarkan Istio yang dihosting melalui GKE memecahkan banyak masalah, tetapi tidak semua orang dapat menggunakan GCP.
Perwakilan Google ditanya apa yang akan terjadi pada Istio, apakah ia akan menjadi proyek CNCF. Jawabannya sangat halus, tetapi samar: Istio sekarang memiliki kode sumber terbuka, orang-orang dapat mengerjakannya, dan tentang CNCF, tunggu dan lihat. Sejauh ini, hanya Linkerd yang merupakan proyek resmi layanan mesh di CNCF, meskipun Utusan Proksi juga merupakan proyek CNCF (dan Istio, gateway API Duta Besar dan banyak teknologi lain didasarkan padanya). Di stan kami, banyak yang bertanya tentang integrasi Linkerd 2 dan Duta Besar (terima kasih kepada Oliver Gould, direktur teknis Buoyant, yang menyebut Duta Besar dalam ulasan Linkerdnya yang terperinci ), dan peserta menyukai kemudahan penggunaan Linkerd.
Ngomong-ngomong, saya senang ketika orang-orang dari Knative dalam pidatonya "Extending Knative for Fun and Profit" menunjukkan bahwa mereka mengganti Istio dengan Ambassador di Knative, karena Ambassador lebih mudah digunakan (perhatikan t-shirt mereka di foto dan baca tugas yang sesuai di GitHub: “Menghapus Istio sebagai ketergantungan” ):
Politik sebagai kode naik tumpukan
Dalam industri kami, semua orang sudah terbiasa menyajikan politik sebagai kode sehubungan dengan identitas dan sistem manajemen akses (IAM), konfigurasi iptable, ACL, dan kelompok keamanan, tetapi sejauh ini telah dilakukan pada tingkat rendah, dekat dengan infrastruktur. Ketika saya mendengar Netflix berbicara tentang penggunaan Open Policy Agent (OPA) di KubeCon di Austin pada tahun 2017 , saya bertanya-tanya bagaimana cara menggunakan proyek ini untuk mendefinisikan kebijakan sebagai kode.
Pada KubeCon ini, saya melihat politik sebagai kode naik, dan semakin banyak orang membahas penggunaan OPA, misalnya, selama pembicaraan oleh Rita Zhang dan Max Smythe , dan lebih banyak pada laporan "Konfigurasi Pengujian Unit Kubernetes" menggunakan Agen Kebijakan Terbuka » Gareth Rushgrove (ia memiliki bakat untuk proyek-proyek dengan potensi besar).
Saya telah mengikuti kebijakan penetapan kebijakan HashiCorp Sentinel di tingkat infrastruktur, dan sekarang menggunakan Intention dalam jala layanan Konsul, teknologi ini semakin tinggi. Dengan Intention, suatu kebijakan dapat didefinisikan pada tingkat layanan. Misalnya, layanan A dapat berkomunikasi dengan layanan B, tetapi tidak dengan layanan C. Ketika tim Datawire mulai bekerja dengan HashiCorp untuk mengintegrasikan Duta Besar dan Konsul, kami dengan cepat menyadari manfaat menggabungkan Intensi dengan mTLS (untuk mengidentifikasi layanan) dan ACL (untuk mencegah spoofing dan untuk perlindungan multi-level).
Cloud DevEx Masih Tidak Dapat Melakukannya
Selama komentar penutup, "Jangan Berhenti Percaya," Bryan Liles, pengembang senior di VMware, berbicara tentang pentingnya alur kerja pengembang (pengalaman pengembang, DevEx), dan topik ini telah diangkat dalam beberapa pembicaraan. Kubernetes dan ekosistemnya berkembang dengan baik, tetapi siklus pengembangan internal dan integrasi pipa pasokan dengan Kubernetes jelas membutuhkan perbaikan.
Christian Roggia berbicara tentang hal ini dalam laporannya “Pengembangan dan Penyampaian yang Dapat Diproduksi Kembali dengan Bazel dan Telepresence” . Dia berbicara tentang bagaimana Engel dan Volkers menggunakan alat Telepresence CNCF dalam siklus pengembangan internal mereka sehingga mereka tidak harus mengumpulkan dan mengirimkan kontainer setelah setiap perubahan.
Ada diskusi kelompok yang menarik dengan orang-orang dari Weaveworks dan Cloudbees, "GitOps dan Best Practices untuk CI / CD di Cloud," yang membahas pengiriman berkelanjutan secara terperinci. GitOps berkembang cukup sukses, jadi ketika bekerja di Datawire dan di konferensi saya sering menemukan tim yang menggunakan pendekatan ini untuk konfigurasi dan pengiriman. Sebagai contoh, Jonathan dan Rodrigo menyebutkan ini dalam laporan mereka yang menarik, "Operasi Scaling Edge di Onefootball dengan Duta Besar: 0 hingga 6.000 permintaan per detik" :
Perusahaan (masih) pada tahap awal adopsi teknologi
Ini adalah KubeCon pertama, di stan Datawire saya banyak berbicara dengan pengembang dari perusahaan besar yang baru mulai mempelajari teknologi cloud. Hampir semua orang pernah mendengar atau bereksperimen dengan Kubernetes, tetapi banyak yang masih berpikir tentang bagaimana mengintegrasikan teknologi lama mereka ke dunia baru.
Cheryl Hung, direktur ekosistem di CNCF, mengadakan beberapa diskusi, termasuk "Mengubah Perusahaan dengan Cloud," dan itu menarik untuk didengar dari para perintis seperti Intuit. Laura Rehorst, dalam ceramahnya "Dari COBOL ke Kubernetes: Perjalanan Awan untuk Bank Berusia 250 Tahun , " menggambarkan bagaimana ABN AMRO menerapkan perencanaan dan sumber daya strategis.
Kami menempatkan gerbang Duta Besar API di tengah-tengah stan, jadi kami sering ditanya tentang bagaimana gerbang modern untuk Kubernet berbeda dari solusi yang ada untuk mengelola siklus hidup API lengkap. Sekarang kami sedang mengerjakan produk komersial berikutnya di area ini - Kode Duta Besar , dan menarik untuk mendiskusikan dengan pengembang persyaratan dan harapan sehubungan dengan paradigma cloud baru.
Kubernet lokal nyata (tapi mudah diingat)
Ada beberapa pengumuman tentang instalasi lokal Kubernetes, khususnya di lingkungan perusahaan, misalnya, Integrasi Kublr VMware dan VMware dan kubeadm . Red Hat berpartisipasi dalam semua diskusi tentang OpenShift, dan saya telah mendengar lebih dari sekali bagaimana orang-orang menyukai abstraksi OpenShift, dan potensi ketergantungan diimbangi oleh peningkatan alur kerja dan konvensi SLA yang menyertainya.
Tetapi semua orang mengulangi hal yang sama: Anda tidak perlu menginstal dan memelihara Kubernetes sendiri, jika ini tidak mutlak diperlukan. Dan bahkan jika Anda menganggap perusahaan Anda istimewa, luangkan waktu Anda: hampir semua perusahaan yang dapat menggunakan cloud publik dapat menggunakan Kubernet sebagai layanan.
Pertimbangkan kelompok kawanan
Dalam laporannya yang menarik, “Bagaimana Spotify secara tidak sengaja menghapus semua cluster dan pengguna Kube tidak memperhatikan apa pun,” pengembang Spotify, David Xia mengatakan apa yang mereka pelajari ketika mereka menghapus beberapa (!) Cluster Kerja. Saya tidak akan menggambarkan seluruh situasi (menonton video), tetapi pesan utama David adalah memperlakukan kelompok Kubernet sebagai kawanan. Saya pikir banyak dari kita telah mendengar ungkapan ini: "Perlakukan server seperti kawanan, bukan hewan peliharaan favorit Anda." Tetapi David percaya bahwa dengan pengembangan abstraksi komputasi (ketika kita memahami "Pusat Data sebagai komputer" ), kita harus menerapkan prinsip yang sama dan tidak terlalu terikat pada infrastruktur kita.
Dalam pembicaraan mereka, Pengembangan Bersama Kubernetes dan Jaringan GCP , Purvi Desai dan Tim Hockin, mengundang organisasi untuk secara permanen menghancurkan, menciptakan kembali, dan memigrasikan kluster Kubernetes agar tidak terkait dengan mereka. Argumen utama: jika Anda tidak terus-menerus memeriksa kemampuan untuk memulihkan cluster dan mentransfer data, Anda mungkin tidak berhasil ketika masalah muncul. Bayangkan ini adalah rekayasa kekacauan untuk cluster.
Keberhasilan Kubernetes masih bergantung pada komunitas.
Dalam laporan, saat makan siang dan sepanjang, salah satu topik utama adalah pentingnya komunitas dan keragaman. Pada hari Kamis pagi, Lucas Käldström dan Nikhita Raghunath dalam laporan mereka "Langkah Pertama di Komunitas Kubernetes" tidak hanya menceritakan dua kisah yang luar biasa, tetapi juga menghancurkan semua alasan mereka yang tidak terlibat dalam proyek sumber terbuka dan proyek CNCF .
Cheryl Hung, dalam laporan 2,66 Juta nya, berterima kasih kepadanya atas kontribusinya yang sangat besar untuk proyek dan membuat kasus yang kuat untuk keragaman dan kepemimpinan yang kuat. Saya terkejut ketika saya mengetahui bahwa lebih dari 300 beasiswa yang mendukung keragaman didanai oleh sumbangan dari berbagai organisasi di dalam CNCF.
Kesimpulan Uni Eropa KubeCon
Terima kasih sekali lagi kepada semua orang yang kami ajak bicara di Barcelona. Jika Anda tidak dapat menghadiri presentasi kami, saya memberikan daftar lengkap:
Di Datawire, kami mengikuti tren ini untuk memastikan bahwa Duta Besar terus berkembang dan memenuhi perubahan kebutuhan pengembang cloud. Jika Anda belum menggunakan Ambassador baru-baru ini, coba rilis terbaru kami - Ambassador 0.70 dengan dukungan jala layanan Konsul, dukungan definisi sumber daya khusus dan banyak fitur lainnya.
Jika Anda mengalami masalah saat memperbarui, buat tugas atau temukan kami di Slack . Jika Anda memerlukan instalasi Ambassador siap pakai dengan otentikasi terintegrasi, batasan kecepatan, dan dukungan, cobalah produk Ambassador Pro komersial kami.
Dan jika Anda suka bekerja dengan Duta Besar, beri tahu kami tentang itu. Tinggalkan komentar di bawah artikel atau kirim @getambassyio di Twitter.