Masalah infrastruktur desktop yang akhirnya dipecahkan oleh Kubernetes
Disampaikan oleh Kasm TechnologiesTim infrastruktur perusahaan telah menghabiskan hampir satu dekade mendorong beban kerja ke Kubernetes. Aplikasi, API, pekerjaan batch, pipeline data — jika dijalankan dalam sebuah container, maka aplikasi tersebut termasuk dalam cluster. Manfaat operasionalnya sudah jelas: konfigurasi deklaratif, penskalaan horizontal, pemulihan mandiri, integrasi asli dengan pipeline CI/CD, dan alat observabilitas. Kubernetes telah menjadi model operasi default untuk beban kerja produksi. Kecuali untuk desktop. Desktop dan pengiriman aplikasi yang aman — jenis yang diandalkan oleh perusahaan untuk pekerjaan jarak jauh, akses istimewa, dan alur kerja industri yang diatur — masih tetap berada di luar model Kubernetes. Infrastruktur desktop virtual lama dibangun di era yang berbeda, dengan serangkaian asumsi berbeda: kumpulan VM yang telah dialokasikan sebelumnya, bidang manajemen yang dipesan lebih dahulu, peralatan berpemilik, dan peralatan operasional yang tidak ada hubungannya dengan cara kerja tim platform modern. Hasilnya adalah realitas infrastruktur yang terpisah: lapisan aplikasi cloud-native yang modern di satu sisi, dan lapisan desktop yang dikelola secara manual dan terisolasi secara operasional di sisi lain. Pemisahan ini memakan biaya yang besar. Hal ini berarti perkakas yang berbeda, perilaku penskalaan yang berbeda, pendekatan observabilitas yang berbeda, dan runbook operasional yang berbeda. Insinyur platform yang mahir dalam Kubernetes masih harus beralih ke model mental yang sama sekali berbeda ketika masalah infrastruktur desktop muncul. Masalah yang lebih mendasar adalah pemisahan ini tidak diperlukan. Pengiriman ruang kerja yang aman dan terkontainer adalah beban kerja yang secara arsitektural cocok untuk dijalankan oleh Kubernetes. Sesi adalah wadah. Penskalaan didorong oleh permintaan. Konfigurasi harus bersifat deklaratif. Satu-satunya hal yang hilang adalah platform yang dibangun untuk memanfaatkan keselarasan tersebut. Mengapa waktunya tepat Keinginan untuk menghadirkan ruang kerja asli Kubernetes telah tumbuh secara signifikan seiring dengan semakin matangnya investasi platform container mereka. Tim platform yang telah menghabiskan waktu bertahun-tahun untuk melakukan standarisasi pada Helm, alur kerja GitOps, dan observabilitas asli Kubernetes semakin tidak mau membuat pengecualian untuk infrastruktur desktop. Pertanyaannya telah bergeser dari “bisakah kita menjalankan ini di Kubernetes?” hingga “mengapa ini belum berjalan di Kubernetes?” Pada saat yang sama, kasus keamanan untuk pengiriman ruang kerja dalam container menjadi lebih mendesak. Ruang kerja dalam container yang dikirimkan melalui browser menyediakan isolasi sesi yang tidak dapat ditandingi oleh desktop berbasis VM — setiap sesi bersifat sementara, diisolasi pada batas container, dan berakhir dengan rapi tanpa status persisten. Bagi organisasi yang mengelola data sensitif, risiko orang dalam, atau skenario akses pihak ketiga, model isolasi ini merupakan kontrol keamanan yang berarti, bukan sekadar kenyamanan penerapan. Konvergensi kedua tren ini — ekspektasi infrastruktur asli Kubernetes dan keamanan sesi dalam container — menciptakan peluang yang jelas bagi platform yang dapat mengatasi keduanya secara bersamaan. model deklaratif yang digunakan di seluruh platform. Daripada mengandalkan peralatan manajemen khusus atau kumpulan desktop yang telah disediakan sebelumnya, infrastruktur dikelola melalui CI/CD, GitOps, observabilitas, dan alur kerja keamanan yang sama dengan yang sudah dioperasikan oleh tim platform. Hal ini memberi tim platform model operasional yang konsisten dibandingkan mempertahankan perangkat terpisah untuk infrastruktur desktop. Kasm Workspaces, platform ruang kerja yang dikirimkan melalui browser, dibuat khusus untuk menggunakan Kubernetes sebagai bidang kendali untuk orkestrasi dan pengiriman ruang kerja. Model penerapannya dirancang untuk lingkungan perusahaan nyata — bukan demo yang disederhanakan — dengan diagram Helm tingkat produksi yang mengikuti konvensi Kubernetes, jalur peningkatan yang diuji antar versi, dan arsitektur backend standar yang divalidasi di seluruh penerapan produksi. Komponen RDP Gateway yang dibuat khusus untuk topologi Kubernetes memungkinkan akses mesin virtual Windows dan Linux melalui platform yang sama. Kemampuan utama meliputi: Penskalaan sesi horizontal yang didorong oleh permintaan aktual, diatur oleh Kubernetes — tidak diperlukan kumpulan VM yang telah dihangatkan sebelumnya. Konfigurasi deklaratif melalui nilai Helm, memungkinkan integrasi GitOps dan CI/CD untuk infrastruktur ruang kerja. Isolasi dan kompatibilitas tingkat namespace dengan kebijakan RBAC, pengontrol ingress, dan integrasi manajemen rahasia yang ada. Ekspor metrik untuk integrasi dengan Prometheus dan tumpukan observabilitas yang ada. Rolling dibangun secara default, mengurangi jangka waktu pemeliharaan dan memungkinkan manajemen versi yang lebih dapat diprediksi. Aplikasi dunia nyata Akses jarak jauh industri yang diatur. Organisasi jasa keuangan yang menjalankan platform aplikasi berbasis Kubernetes dapat menyebarkan Kasm ke dalam cluster yang sama, menggunakan peralatan operasional yang sama, untuk memberikan sesi browser dan aplikasi yang terisolasi kepada analis dan penasihat. Sesi bersifat sementara, jalan keluar jaringan dikontrol, dan seluruh penerapan dikelola melalui pipeline GitOps yang sama dengan beban kerja aplikasinya. Akses kontraktor dan pihak ketiga. Organisasi yang secara teratur melakukan orientasi terhadap kontraktor atau vendor eksternal – dengan risiko akses istimewa yang terkait – dapat menyediakan sesi Kasm di Kubernetes yang ditingkatkan selama periode keterlibatan dan dikurangi selama periode permintaan rendah. Tidak ada akses persisten. Tidak ada ekstensi VPN ke pihak eksternal. Isolasi dalam container di setiap batas sesi. Lingkungan pengembangan AI/ML. Tim yang membangun dan menjalankan model AI memerlukan lingkungan pengembangan berkemampuan GPU dengan kontrol keamanan yang jarang disediakan oleh desktop cloud tujuan umum. Menerapkan Kasm di Kubernetes dengan dukungan GPU Multi-Instance NVIDIA MiG memungkinkan tim platform menyalurkan sumber daya GPU fraksional ke dalam sesi ruang kerja yang terisolasi — memberikan data scientist komputasi yang mereka perlukan tanpa paparan keamanan infrastruktur bersama. Pergeseran operasional Implikasi praktis dari platform ruang kerja asli Kubernetes adalah tim platform tidak lagi memperlakukan infrastruktur ruang kerja sebagai kasus khusus. Insinyur yang sama yang menyebarkan aplikasi juga dapat menyebarkan platform ruang kerja. Alur yang sama yang mengelola konfigurasi aplikasi juga dapat mengelola konfigurasi ruang kerja. Dasbor yang sama yang memantau kesehatan aplikasi juga dapat memantau kesehatan ruang kerja. Konsolidasi operasional tersebut mengurangi overhead, meningkatkan konsistensi, dan menghilangkan biaya peralihan konteks yang membuat infrastruktur desktop menjadi masalah yang terus-menerus bagi organisasi cloud-native. Bagi organisasi yang masih menjalankan VDI lama bersama infrastruktur cloud modern, pertanyaannya bukan lagi apakah ada alternatif asli Kubernetes. Memang benar. Pertanyaannya adalah kapan harus melakukan transisi. Organisasi yang tertarik untuk mengevaluasi penyampaian ruang kerja asli Kubernetes dapat menjelajahi platform di kasm.com dan mencoba sendiri edisi komunitas. Daniel Ben-Chitrit adalah Chief Product Officer di Kasm Technologies. Artikel bersponsor adalah konten yang diproduksi oleh perusahaan yang membayar untuk postingan tersebut atau memiliki hubungan bisnis dengan VentureBeat, dan artikel tersebut selalu ditandai dengan jelas. Untuk informasi lebih lanjut, hubungi sales@venturebeat.com.
Diterbitkan : 2026-07-13 07:00:00
sumber : venturebeat.com
