Mengganti Kubernetes dengan systemd (2024)

• Di server pribadi dan VPS kecil, otomatisasi deklaratif Kubernetes memang menarik, tetapi beban CPU dan memori serta kompleksitas operasionalnya bisa melampaui manfaat nyatanya
• Kubernetes mengotomatisasi hal seperti penyesuaian Pod dan pembaruan sertifikat TLS dengan terus menjaga kondisi agar sesuai dengan keadaan yang diinginkan, tetapi untuk itu ia harus terus menjalankan runtime yang cukup besar
• Dalam eksperimen dengan Azure Kubernetes Service, Microk8s, K3S, dan Raspberry Pi, penggunaan resource saat idle serta panas dan kebisingan kipas berulang kali menjadi masalah
• Podman dapat membuat container menjadi layanan systemd dan mendeteksi serta mengganti image baru dengan io.containers.autoupdate dan podman auto-update
• Kombinasi Podman, systemd, dan user lingering menyediakan sebagian besar otomatisasi yang diinginkan dari Kubernetes dengan cara yang lebih sederhana, tetapi integrasi systemd kini bergerak ke arah Quadlet

---

Mengapa otomatisasi Kubernetes terasa terlalu berat untuk server pribadi

• Kubernetes terdiri dari banyak komponen, layanan web, sidecar, dan webhook, tetapi perilaku intinya lebih mirip loop yang terus membandingkan kondisi saat ini dengan kondisi yang diinginkan lalu menerapkan perbedaannya
  • Jika seharusnya ada Pod tetapi tidak ada, maka dibuat
  • Jika replica seharusnya 3 tetapi ada 4, maka satu dihapus
• Model ini sangat berguna terutama pada ekstensi seperti cert-manager
  • Dideklarasikan bahwa harus ada sertifikat TLS yang valid untuk domain tertentu
  • Jika cara meminta sertifikat sudah ditentukan, maka saat sertifikat belum ada atau masa berlakunya hampir habis, sistem akan mengambil sertifikat baru dan memasangnya ke server web
• Untuk eksperimen pribadi ini menyenangkan dan bernilai sebagai pembelajaran, tetapi untuk tujuan operasional nyata, ini terasa seperti alat yang berlebihan
• Beban resource terus muncul berulang di berbagai lingkungan
  • Di NUC, komputer terus menyala, menjadi panas, dan menimbulkan suara kipas sehingga sulit tidur
  • Di Azure Kubernetes Service, implementasi Kubernetes memakan RAM besar, dan di worker node CPU idle terpakai sekitar 7~10%
  • Pada Microk8s single-instance di VPS x86_64 2 vCPU, CPU idle berada di kisaran 12%
  • K3S pada mesin Ampere A1 2 vCPU dikenal sebagai implementasi yang lebih ringan, tetapi tetap memakai CPU konstan sekitar 6%
  • Bahkan di Raspberry Pi pun tidak ditemukan implementasi yang bisa menyisakan CPU cukup untuk workload tanpa masalah panas dan kipas

Pendekatan otomatisasi setelah beralih ke Podman dan systemd

• Alasan terbesar tetap memakai Kubernetes adalah otomatisasi deployment
  • Dengan GitOps dan Flux, perubahan menjadi mudah dilakukan
  • Dengan otomatisasi image container dan webhook Flux v2, saat image baru di-push, dalam hitungan detik server mengambil image baru dan menjalankan aplikasi produksi
• Alternatif lama yang ditemukan di luar Kubernetes tidak memuaskan
  • Pendekatan yang harus mengingat semua argumen command line asli untuk membuat ulang container menambah beban pengelolaan
  • Alat yang meminta kontrol penuh atas docker.sock juga tidak disukai
• Podman auto-updating lebih mendekati fungsi yang dibutuhkan
  • Podman bisa dipandang sebagai alternatif Docker CLI
  • Setelah membuat container, kita bisa menghasilkan file layanan systemd
  • Saat layanan dimulai, container dibuat atau diganti, dan saat layanan dihentikan, container dihapus
• Pembaruan otomatis bekerja melalui tag io.containers.autoupdate
  • Bisa dijalankan lewat timer sekali sehari atau dengan langsung menjalankan podman auto-update
  • Jika ada image baru, container akan dibuat ulang menggunakan image tersebut
• Artikel Fedora Magazine Auto-updating Podman containers with systemd memberikan sebagian besar cara implementasinya, dan tambahan dua pengaturan lagi diperlukan
  • systemctl --user enable mycontainer.service agar container otomatis mulai saat login
  • loginctl enable-linger agar sesi pengguna berjalan saat server dinyalakan
• Dengan kombinasi Podman, systemd, dan user lingering, sekitar 99% manfaat yang sebelumnya didapat dari Kubernetes bisa diperoleh dengan kompleksitas serta beban CPU dan memori yang jauh lebih rendah
• Seluruh layanan dipindahkan dari VPS lama ke VPS baru dengan vCPU dan RAM setengahnya, dan setelah berjalan selama beberapa jam, hasilnya lebih ringan, lebih cepat, dan biaya komputasinya juga lebih rendah
• Namun, integrasi systemd di Podman tampaknya sudah deprecated, dan definisi container kini dibahas menuju penggunaan file Quadlet

[GN⁺]

Opini Hacker News

• Saya sepenuhnya memahami perasaan penulis asli. Di tempat kerja, kami mengelola beberapa cluster Kubernetes yang menjalankan puluhan microservice dengan relatif mudah, tetapi untuk proyek hobi yang tidak menghasilkan pendapatan, anggarannya kecil sehingga meski ingin memakai Kubernetes, saya tidak bisa
  Di VPS $10 per bulan dengan 1 vCPU bersama dan RAM 2GB, Kubernetes terlalu berat. Alih-alih Deployment, saya menjalankan docker compose up/down secara manual lewat SSH; alih-alih Ingress, saya mengandalkan fitur penemuan container Traefik; dan karena tidak bisa memakai CronJobs, saya bahkan membuat sendiri skrip kecil untuk mengelola crontab secara idempoten
  Yang benar-benar saya inginkan adalah alternatif ringan yang menyediakan API kompatibel Kubernetes dan tetap berjalan baik di VPS murah. Kesenjangan antara orkestrasi container kelas enterprise dan hosting murah untuk hobi masih terlalu besar

  • Bergantung pada cakupan Kube API yang dibutuhkan, Podman bisa mengisi peran itu. Podman dapat membuat container dan pod dari manifest Kubernetes, sehingga berperilaku seperti docker compose yang memakai manifest Kubernetes
    Seperti pendekatan yang dijelaskan di tulisan itu, Podman juga bisa digunakan bersama unit systemd. Podman juga mendukung sebagian besar atau seluruh Docker API, jadi docker compose pun berjalan, dan Anda juga bisa bekerja dengan menghubungkan ke soket jarak jauh lewat SSH
    https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
    https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
  • Saya penasaran apakah Anda sudah melihat k0s atau k3s. Ada cukup banyak contoh penggunaannya yang berhasil pada skala kecil: https://news.ycombinator.com/item?id=43593269
  • Saya tidak ingin terdengar seperti promosi Oracle, tetapi Oracle Cloud Free Tier luar biasa murah hati. Anda bisa menjalankan cukup banyak hal, termasuk cluster k8s kecil, dan layanan control plane k8s-nya juga gratis
    Mereka memberi 4 core ARM64 dan RAM 24GB secara gratis, dan bisa dibagi menjadi 1–4 node sesuai cara yang Anda inginkan
    https://www.oracle.com/cloud/free/
  • Pakai saja cara lama seperti Ansible. Saya mengelola sepenuhnya beberapa server dedicated dengan Ansible, dan itu bisa dipakai seperti semacam docker compose versi lebih kuat
    Dengan Traefik dan label, reverse proxy serta sertifikat TLS bisa digeneralisasi, lalu Authelia dapat ditambahkan sebagai penyedia autentikasi sederhana. Ada banyak proyek contoh di GitHub, dan setelah disetel kira-kira selama akhir pekan, sistemnya menjadi cukup mudah dikelola
  • Anda sudah mengatakan bahwa biaya memakai Kubernetes terlalu tinggi, jadi bergantung pada sumbu apa yang dipakai untuk mengukur efisiensi, solusi buatan sendiri justru bisa lebih efisien

• systemd memang sering dicaci, tetapi ia menyelesaikan sangat banyak masalah, jadi tidak boleh diremehkan begitu saja. Saat mulai menjadi bawaan di berbagai distro, sebagian besar orang tidak suka karena mereka harus berubah
  Ada container, machinectl, nspawn sebagai chroot yang lebih kuat, vmspawn saat butuh virtualisasi penuh, importctl untuk mengunduh, mengimpor, dan mengekspor mesin, serta homed/homectl yang memudahkan enkripsi direktori home dan kontrol izin
  systemd menangani mount sebagai unit alih-alih fstab, mengontrol urutan boot serta start/stop service, dan juga menyediakan timer yang lebih kuat daripada cron. Misalnya, bisa mengetahui job yang terlewat karena mesin sedang mati, atau menjalankan dengan penundaan setelah boot dalam kondisi tertentu
  Unit service memungkinkan kontrol pekerjaan secara rinci dan pembatasan hak akses, dan dengan systemctl edit Anda bisa membuat konfigurasi override tanpa menyentuh konfigurasi asli. Awalnya memang agak merepotkan untuk dipelajari, tetapi kalau ingin melakukan hal yang kompleks, toh tidak ada alat yang sama sekali tidak perlu membaca dokumentasi

  • Alasan systemd dicaci selama beberapa tahun awalnya, mungkin hampir 10 tahun, bukan karena proyek itu sendiri buruk. Sebaliknya, ia cukup unggul sampai berhasil meski punya berbagai masalah
    Masalahnya adalah sikap para maintainer. Mereka dengan santai merusak hal-hal yang sebelumnya berjalan baik tanpa menyediakan perbaikan yang memadai. Jika Anda tidak merasakan penderitaan karena systemd, mungkin Anda bergabung belakangan, atau kebutuhan Anda kebetulan selaras dengan kebutuhan para maintainer inti
  • Satu-satunya hal yang tidak saya sukai dari systemd adalah binary dari codebase yang luar biasa besar mengambil peran sebagai PID 1, lalu melakukan perilaku yang lebih kompleks saat upgrade karena mencoba melakukan exec terhadap dirinya sendiri di tempat
    Program yang melakukan 100% tepat apa yang harus dilakukan PID 1 dan tidak melakukan apa pun selain itu bisa dibuat jauh lebih kecil. Jika systemd dijalankan di atasnya, sesuatu yang bermasalah pada systemd tidak langsung berujung pada kernel panic
    Sumber: https://ewontfix.com/14/
  • Sulit menerima ajakan untuk melupakan cron. Ia sudah bekerja dengan baik selama 50 tahun, lalu tiba-tiba dianggap sangat salah dan seolah sudah sewajarnya diganti oleh systemd
  • Jika melupakan fstab dan memakai mount systemd, aturan automount-nya rumit, dan meskipun dicocokkan 1:1 dengan dokumentasi, kadang-kadang tetap saja tidak berjalan, sehingga filesystem bisa tidak ter-mount tepat waktu
  • systemd sangat bagus untuk desktop atau server Linux modern, atau penggunaan yang mirip dengannya. Namun jika Anda mencoba melakukan sesuatu yang keluar dari cara yang diasumsikan proyek itu, Anda akan menghadapi ejekan dan penolakan. Tanyakan saja kepada tim musl
    Bagi distro atau upstream, ia membuat hidup jauh lebih mudah, tetapi sebagai gantinya menambahkan kompleksitas yang terus membesar di lapisan paling bawah sistem. Bergantung pada sudut pandang, hal-hal seperti journalctl, timedatectl, dependensi atau pengganti dbus bisa dianggap tidak sesuai dengan filosofi Unix
    Jika tujuannya hanya mengoordinasikan proses, menjalankannya dalam urutan yang benar, dan memastikan aktivasi otomatis, menurut saya ini alat pada level yang lebih tepat daripada k8s atau Docker

• Saya sudah cukup lama menjalankan homelab dengan podman-systemd, yaitu Quadlet, dan setiap kali melihat varian k8s baru, rasanya tidak sepadan dengan kerepotan tambahan yang harus ditanggung. Playbook Ansible lama yang sudah ada sudah cukup: mengambil image terlebih dahulu lalu menaruh file unit di tempatnya
  Seluruh stack printer 3D Voron juga dijalankan dengan podman-systemd, sehingga semua komponennya bisa diperbarui dan di-rollback sekaligus. Namun sekarang juga sedang mempertimbangkan pendekatan memperbarui dan me-rollback seluruh image disk sekaligus dengan mkosi dan systemd-sysupdate
  Masalah utamanya adalah orang-orang umumnya hanya mendistribusikan file docker-compose, sehingga harus dikonversi menjadi unit systemd, dan sebagian image Docker memiliki kerumitan yang tidak perlu bagi Podman dalam pengaturan pengguna dan izin. Terutama jika kontainer menolak berjalan sebagai root atau beralih ke pengguna lain, kadang diperlukan pemetaan ID userns yang merepotkan
  Meski begitu, secara keseluruhan ini jauh lebih tidak rumit dibanding konfigurasi k8s atau varian k8s mana pun. Integrasinya dengan systemd dan journald juga menyenangkan karena tidak terpecah ke dua tempat

  • Sudah beberapa tahun memakai pendekatan serupa: https://github.com/Mati365/hetzner-podman-bunjs-deploy. Berbasis Podman dan systemd, dan selama ini tidak ada yang rusak
    Cukup menaruh unit saja, jadi sangat stabil dan sederhana
  • Saat mengonversi file compose menjadi file Quadlet, bisa memakai podlet: https://github.com/containers/podlet
  • Pada akhirnya sepertinya ini hanyalah satu node, atau sekumpulan node independen. Podman/systemd/Quadlet bisa saja menjadi detail implementasi cara node k8s menjalankan kontainer, semacam CRI
    Namun itu tidak menggantikan abstraksi orkestrasi dan penjadwalan di atas banyak node yang disediakan k8s. Bagian “ini ada mesin-mesin yang bisa menjalankan file Podman-systemd, dan ini spesifikasi yang ingin dijalankan, tolong tempatkan sendiri” masih hilang
  • Pengalaman saya mirip. Alur kerjanya adalah menjalankan kontainer dulu dengan perintah podman run, memastikan berjalan dengan benar, lalu membuat file kontainer dasar dengan podlet, kemudian memodifikasi file kontainer dengan memisahkan volume dan jaringan ke file Quadlet lain; selesai
    Proyek podman-compose tampaknya juga masih aktif dipelihara dan bisa menjadi alternatif yang bagus untuk docker-compose. Namun integrasi Podman dengan systemd memang sangat memuaskan

• Langkah berikutnya untuk membuat ini lebih sederhana adalah mengelola kontainer di dalam systemd dengan Quadlet. Detailnya ada di https://www.redhat.com/en/blog/quadlet-podman

  • Quadlet memang jalan ke arah itu. Cara yang sangat bagus untuk menjalankan kontainer, dan setelah dikonfigurasi terasa seperti bisa dilupakan. Di Fedora atau Rocky Linux, setidaknya tidak perlu memasang paket tambahan
  • Ini dibahas di bagian akhir tulisan, tetapi penulisnya belum sempat melihatnya. Integrasi systemd milik Podman sudah terlihat seperti deprecated, dan sekarang ada pembicaraan untuk mendefinisikan kontainer dengan file “Quadlet”, jadi itu semacam bahan yang ditinggalkan untuk dipelajari nanti
  • Alasan datang melihat komentar adalah untuk memastikan apakah ada yang menyebut Quadlet. Minggu lalu saya memindahkan home server dari docker compose ke rootless Podman Quadlet; transisinya sulit, tetapi saya sangat puas dengan hasilnya
  • Tulisan ini juga sangat membantu untuk memigrasikan homelab ke Quadlet dengan mulus: https://news.ycombinator.com/item?id=43456934

• Saya membuat skate: https://github.com/skateco/skate. Pada dasarnya untuk tujuan seperti ini, tetapi mendukung banyak host dan juga mendukung manifest k8s. Secara internal memakai Podman dan systemd

  • Saya sangat suka pendekatan ini. Sangat menyebalkan karena tidak ada cara sederhana untuk menjalankan Docker/Podman di banyak host. Docker Swarm sayangnya praktis terbengkalai sejak 2019
    Namun menurut saya k8s punya API dan pengalaman pengguna yang buruk sekali. Spesifikasi Docker Compose jauh lebih ramah pengguna, jadi saat ini saya sedang bereksperimen dengan docker-compose untuk banyak host: https://github.com/psviderski/uncloud

• Saya kembali membungkusnya sebagai paket deb dan menjalankannya langsung dengan systemd di instans EC2, tidak lagi memakai kontainer. Instans dimasukkan ke Auto Scaling Group yang terhubung ke ALB, dan saat boot ansible-pull sederhana memasang deb tersebut
  Ini memang pendekatan yang cukup mentah, tetapi saya lelah dengan HCL di dalam YAML di dalam JSON tanpa akhir. Sekarang saya hanya ingin berurusan dengan YAML Ansible saja

  • Hal bagus dari pendekatan ini adalah ketika ada bug di library umum, cukup menjalankan apt full-upgrade dan me-restart hanya proses yang sedang berjalan untuk terlindungi
    Tidak perlu membangun ulang apa pun, atau mencari cara memperbarui library yang terkubur jauh di dalam kontainer yang mungkin dibuat sendiri atau mungkin juga tidak
  • Saya mengambil jalan yang sama untuk aplikasi yang sangat sederhana. systemd ternyata menyenangkan, dan menjalankan layanan dengan hak minimum menggunakan akun pengguna yang dialokasikan sistem terasa cukup bagus
    Berkat dukungan cgroup, menjalankan beberapa layanan di satu VPS juga enak
  • Membayangkan umur manusia yang terbuang pada ranah masalah “mengelola YAML skala besar” itu bikin merinding

• Karena tulisan ini sudah lebih dari setahun, sekarang bahkan sudah ada ParticleOS, distribusi OS dukungan resmi dari systemd untuk alur kerja immutable
  https://github.com/systemd/particleos
  https://news.ycombinator.com/item?id=43649088

  • Langkah logis berikutnya mungkin mengganti kernel Linux dengan systemd-kernel, dan saat itu semuanya lengkap

• Setelah membacanya, sepertinya semua ini bisa diganti dengan perintah docker compose dan sesuatu seperti Caddy yang otomatis mengambil sertifikat
  Selama ada compose.yaml, pada dasarnya cukup satu baris: docker compose up -d --pull always. Konfigurasi CI juga cukup dengan scp compose.yaml user@remote-host:~/ lalu ssh user@remote-host 'docker compose up -d --pull always'
  Keunggulannya adalah sederhana dan juga berjalan di mesin pengembangan. Tentu saja kalau tujuan tambahannya adalah mencoba hal menarik dan belajar, Quadlet, k8s, maupun systemd juga pilihan yang bagus

  • Cukup jalankan sekali docker context create --docker 'host=ssh://user@remote-host' remote-host
    Setelah itu, gunakan docker -c remote-host compose -f compose.yaml up -d --pull always sehingga tidak perlu menyalin file. Selain itu, jika informasi pengguna diatur di ~/.ssh/config, tidak perlu menulis user@ saat memanggil SSH, sehingga tim lebih mudah menyalin dokumentasi atau perintah
  • Bisa mengikuti cara di komentar saudara, atau mengatur variabel lingkungan DOCKER_HOST. Namun perlu diperhatikan bahwa interpolasi file compose menggunakan variabel lingkungan lokal

• Karena menurut saya deployment ke satu server tidak seharusnya serumit ini, saya membuat alat untuk melakukan deployment sesuai cara yang saya inginkan: https://harbormaster.readthedocs.io/
  Harbormaster mencari repositori lewat file YAML, secara berkala melakukan clone dan update, lalu menjalankan file Docker Compose di dalamnya. Semua state juga disimpan dalam satu direktori, sehingga mudah dicadangkan
  Jika yang dibutuhkan hanya satu server, ini adalah alat orkestrasi container paling mudah dan bagus yang pernah saya lihat sejauh ini. Saya suka karena seluruh konfigurasi dideklarasikan di repositori, semua state ada di satu direktori, dan semuanya hanyalah file Compose

• Membaca komentar-komentar di sini membuat saya merasa tua. Rasanya sekarang tidak ada lagi yang hanya memakai ssh dan nginx
  Masukkan semuanya ke satu box, lalu backup box itu secara agresif, selesai. Untuk pemakaian di rumah, benar-benar tidak perlu sampai mengelola microservices

  • Saya hanya memakai nginx dan beberapa layanan kustom, tetapi itu memungkinkan karena kebutuhannya sangat kecil. Begitu sedikit lebih kompleks atau perlu menjalankan beberapa node untuk redundansi, container mulai sangat masuk akal