Kubernetes’i systemd ile değiştirmek (2024)

• Kişisel sunucular ve küçük VPS’ler için Kubernetes’in bildirimsel otomasyonu çekici olsa da CPU ve bellek yükü ile operasyonel karmaşıklık gerçek faydanın önüne geçebilir
• Kubernetes, istenen durumu sürekli tutturma yöntemiyle Pod ayarlaması ve TLS sertifikası yenileme gibi otomasyonlar sağlar; ancak bunun için oldukça büyük bir çalışma zamanını sürekli ayakta tutar
• Azure Kubernetes Service, Microk8s, K3S ve Raspberry Pi denemelerinde boşta kaynak kullanımı ile ısınma/fan sesi tekrar tekrar sorun oldu
• Podman, konteynerleri systemd servisi hâline getirebilir ve io.containers.autoupdate ile podman auto-update kullanarak yeni imajları algılayıp değiştirebilir
• Podman, systemd ve user lingering birleşimi, Kubernetes’ten beklenen otomasyonun büyük bölümünü daha basit şekilde sağlar; ancak systemd entegrasyonu Quadlet yönüne kayıyor

---

Kubernetes otomasyonunun kişisel sunucular için neden ağır kaldığı

• Kubernetes birçok bileşen, web servisi, sidecar ve webhook’tan oluşsa da temel çalışma biçimi, mevcut durum ile istenen durumu sürekli karşılaştırıp farkları uygulayan bir döngüye yakındır
  • Bir Pod’un var olması gerekirken yoksa oluşturur
  • Replica sayısı 3 olmalı ama 4 ise birini kaldırır
• Bu model özellikle cert-manager gibi eklentilerde yararlıydı
  • Belirli bir alan adı için geçerli bir TLS sertifikası olması gerektiği bildirilir
  • Sertifikanın nasıl talep edileceği tanımlanırsa, sertifika yokken veya süresi dolmaya yaklaşırken yeni sertifikayı alıp web sunucusuna kurar
• Kişisel denemeler için eğlenceli ve öğretici olsa da gerçek operasyon amaçları için aşırı büyük bir araç sayılırdı
• Kaynak yükü farklı ortamlarda tekrarlandı
  • NUC’ta bilgisayar sürekli çalışıp ısınıyor ve fan sesi çıkarıyor, bu da uyumayı zorlaştırıyordu
  • Azure Kubernetes Service’te Kubernetes uygulaması RAM’in büyük bölümünü kaplıyor, worker node’da boşta CPU’nun yaklaşık %7–10’unu kullanıyordu
  • 2 vCPU x86_64 VPS’te tek örnekli Microk8s’in boşta CPU kullanımı yaklaşık %12 düzeyindeydi
  • 2 vCPU Ampere A1 makinede K3S daha hafif bir uygulama olarak bilinse de sürekli yaklaşık %6 CPU kullanıyordu
  • Raspberry Pi’de de ısınma/fan sorunu olmadan iş yüklerine yeterli CPU bırakacak bir uygulama bulunamadı

Podman ve systemd ile değiştirilen otomasyon yöntemi

• Kubernetes’i kullanmaya devam ettiren en büyük neden dağıtım otomasyonuydu
  • GitOps ve Flux kullanıldığında değişiklik yapmak kolaydı
  • Konteyner imaj otomasyonu ve Flux v2 webhook’larıyla yeni imaj push edildiğinde sunucu birkaç saniye içinde yeni imajı alıp production uygulamasını çalıştırıyordu
• Kubernetes dışında bulunan mevcut alternatifler tatmin edici değildi
  • Orijinal komut satırı argümanlarının tamamını hatırlayıp konteyneri yeniden oluşturma yaklaşımı yüksek yönetim yükü getiriyordu
  • docker.sock üzerinde tam kontrol isteyen araçlar da tercih edilmiyordu
• Podman auto-updating ihtiyaç duyulan işleve yakındı
  • Podman, Docker CLI alternatifi olarak görülebilir
  • Konteyner oluşturulduktan sonra systemd servis dosyası üretilebilir
  • Servis başlatıldığında konteyneri oluşturur veya değiştirir; servis durdurulduğunda konteyneri kaldırır
• Otomatik güncelleme io.containers.autoupdate etiketiyle çalışır
  • Günde bir kez timer ile çalıştırılır ya da podman auto-update doğrudan yürütülür
  • Yeni imaj varsa konteyneri o imajla yeniden oluşturur
• Fedora Magazine’deki Auto-updating Podman containers with systemd uygulamanın büyük kısmını sağladı; ek olarak iki ayar gerekiyordu
  • systemctl --user enable mycontainer.service ile oturum açıldığında konteynerin otomatik başlaması sağlanır
  • loginctl enable-linger ile sunucu başlarken kullanıcı oturumunun çalışması sağlanır
• Podman, systemd ve user lingering birleşimiyle Kubernetes’ten elde edilen faydaların yaklaşık %99’u çok daha düşük karmaşıklık ve CPU/bellek yüküyle elde edildi
• Tüm servisler mevcut VPS’ten vCPU ve RAM’i yarı yarıya daha az olan yeni bir VPS’e taşındı; birkaç saatlik çalışma bazında daha hafif, daha hızlıydı ve işlem maliyeti de daha düşüktü
• Ancak Podman’ın systemd entegrasyonu görünüşe göre artık destek dışı; konteyner tanımları için Quadlet dosyaları yönünde tartışmalar sürüyor

[GN⁺]

Hacker News görüşleri

• Orijinal yazarın duygularına tamamen katılıyorum. İş yerinde onlarca mikroservisin çalıştığı birden çok Kubernetes kümesini nispeten kolay yönetiyoruz; ama gelir getirmeyen hobi projelerinde bütçe küçük olduğu için Kubernetes kullanmak istesem de kullanamıyorum.
  1 paylaşımlı vCPU ve 2GB RAM’li aylık 10 dolarlık bir VPS için Kubernetes fazla ağır. Deployment yerine SSH ile docker compose up/down komutunu elle çalıştırıyorum, Ingress yerine Traefik’in container keşif özelliğine güveniyorum; CronJobs kullanamadığım için crontab’ı idempotent biçimde yöneten küçük bir betiği bile kendim yazdım.
  Asıl istediğim, ucuz VPS’lerde de iyi çalışan Kubernetes uyumlu bir API sağlayan hafif bir alternatif. Kurumsal düzey container orkestrasyonu ile hobi amaçlı düşük maliyetli hosting arasındaki uçurum hâlâ çok büyük.

  • İhtiyaç duyulan Kube API kapsamına bağlı olarak Podman bu rolü üstlenebilir. Kubernetes manifestlerinden container ve pod oluşturabildiği için, Kubernetes manifestleri kullanan docker compose gibi davranır.
    Yazıda anlatılan yönteme benzer şekilde systemd unit’leriyle birlikte de kullanılabilir. Podman, Docker API’sinin de çoğunu ya da tamamını desteklediğinden docker compose da çalışır; SSH üzerinden uzak sokete bağlanıp işlem yapmak da mümkündür.
    https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
    https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
  • k0s veya k3s’e bakıp bakmadığını merak ediyorum. Küçük ölçekte bunları iyi kullanan epey örnek var: https://news.ycombinator.com/item?id=43593269
  • Oracle reklamı gibi konuşmak istemem ama Oracle Cloud Free Tier açık ara cömert. Küçük bir k8s kümesi dahil epey şeyi çalıştırabilirsiniz; k8s kontrol düzlemi hizmeti de ücretsiz.
    Ücretsiz olarak 4 ARM64 çekirdeği ve 24GB RAM veriyor; tercih ettiğiniz düzene göre bunları 1 ila 4 node’a bölebiliyorsunuz.
    https://www.oracle.com/cloud/free/
  • Eski usul Ansible gibi bir şey kullanabilirsiniz. Birkaç dedicated server’ı Ansible ile tamamen yönetiyorum; bir tür güçlendirilmiş docker compose gibi kullanılabiliyor.
    Traefik ve label’ları kullanarak reverse proxy ile TLS sertifikalarını genelleştirip, basit bir kimlik doğrulama sağlayıcısı olarak Authelia’yı eklemek yeterli. GitHub’da örnek proje de çok; bir hafta sonu kadar ayırıp kurarsanız yönetimi oldukça kolay bir sistem oluyor.
  • Kubernetes kullanmanın maliyetinin çok yüksek olduğunu zaten söylemişsiniz; bu yüzden verimliliği hangi eksende ölçtüğünüze bağlı olarak kendi yaptığınız çözüm aslında daha verimli olabilir.

• systemd çok eleştirilir ama gerçekten pek çok sorunu çözdüğü için kolayca göz ardı edilmemeli. Dağıtımlara varsayılan olarak girmeye başladığında insanların değişmek zorunda kalmaktan hoşlanmaması büyük etkendi.
  Container’lar, machinectl, daha güçlü bir chroot olan nspawn, tam sanallaştırma gerektiğinde kullanılan vmspawn, makineleri indirme, içe aktarma ve dışa aktarma için importctl, ev dizini şifreleme ve yetki kontrolünü kolaylaştıran homed/homectl gibi şeyler var.
  fstab yerine mount’ları unit olarak ele alır, boot sırasını ve servislerin başlatılıp durdurulmasını kontrol eder; crondan daha güçlü timer’lar da sunar. Örneğin makine kapalı olduğu için çalıştırılamayan işleri bilmek ya da boot sonrası belirli koşullarda gecikmeli çalıştırmak mümkündür.
  Service unit’leri işleri ayrıntılı biçimde denetleyebilir ve yetkileri kısıtlayabilir; systemctl edit ile asıl yapılandırmaya dokunmadan override ayarları oluşturabilirsiniz. Başta öğrenmesi biraz zahmetli, ama karmaşık işler yapacaksanız dokümantasyona hiç bakmayı gerektirmeyen bir araç zaten yok.

  • systemd’nin ilk yıllarında, belki de neredeyse 10 yıl boyunca eleştirilmesinin nedeni projenin kendisinin kötü olması değildi. Aksine, çeşitli sorunlara rağmen başarılı olacak kadar iyiydi.
    Sorun maintainer’ların tutumuydu. İyi çalışan şeyleri rahatça bozup buna uygun düzeltmeler sunmamak gibi bir yaklaşım vardı. systemd yüzünden acı çekmediyseniz ya geç katılmışsınızdır ya da ihtiyaçlarınız tesadüfen çekirdek maintainer’ların ihtiyaçlarıyla örtüşmüştür.
  • systemd’de hoşuma gitmeyen tek şey, sayılamayacak kadar büyük bir kod tabanından çıkan binary’nin PID 1 rolünü üstlenmesi ve yükseltme sırasında kendisini yerinde exec etmeye çalışarak daha karmaşık davranışlara girmesi.
    PID 1’in yapması gereken şeyi %100 doğru yapıp bunun dışında hiçbir şey yapmayan bir program çok daha küçük olabilir. Buradan systemd’yi başlatırsanız, systemd’de bir sorun çıksa bile bu hemen kernel panic’e dönüşmez.
    Kaynak: https://ewontfix.com/14/
  • cronu unutun demek bana ikna edici gelmiyor. 50 yıl boyunca gayet iyi çalıştı; şimdi birdenbire çok yanlış bir şeymiş ve doğal olarak systemd ile değiştirilmesi gerekiyormuş gibi davranılıyor.
  • fstabı unutup systemd mount’larını kullanırsanız, otomatik mount kuralları karmaşıktır ve dokümantasyonla bire bir eşleseniz bile bazen sadece çalışmaz; bu yüzden dosya sistemi zamanında mount edilmeyebilir.
  • systemd, modern masaüstü veya sunucu Linux’u ya da buna benzer kullanım alanları için harika. Ama projenin varsaydığı kullanım biçiminin dışına çıkmaya çalışırsanız alay ve dirençle karşılaşırsınız. musl ekibine sorabilirsiniz.
    Dağıtımlar veya upstream açısından hayatı çok kolaylaştırır; fakat bunun bedeli olarak sistemin en alt katmanlarına giderek büyüyen bir karmaşıklık ekler. Bakış açısına göre journalctl, timedatectl, dbus bağımlılığı veya alternatifi gibi şeylerin Unix felsefesine uymadığı düşünülebilir.
    Amaç yalnızca süreçleri koordine etmek, doğru sırayla çalıştırmak ve otomatik etkinleştirmeyi garanti etmekse, k8s veya Docker’dan daha uygun seviyede bir araç olduğunu düşünüyorum.

• Homelab’i bir süredir podman-systemd, yani Quadlet ile çalıştırıyorum; yeni k8s türevlerine her baktığımda ek zahmete değmediğini gördüm. Eski Ansible playbook’larında imajları önceden çekip unit dosyalarını doğru yere koymak yeterli oluyor.
  Voron 3D yazıcı stack’inin tamamını da podman-systemd ile çalıştırarak tüm bileşenleri tek seferde güncelleyip rollback yapabilir hale getirdim. Ancak şimdi mkosi ve systemd-sysupdate ile tüm disk imajını tek seferde güncelleyip rollback yapma yöntemini de değerlendiriyorum.
  Başlıca sorun, insanların genelde yalnızca docker-compose dosyaları dağıtması ve bunları systemd unit’lerine dönüştürmek gerekmesi; ayrıca bazı Docker imajlarının kullanıcı/izin ayarlarında Podman için gereksiz karmaşıklık taşıması. Özellikle container root olarak çalışmayı reddederse veya başka bir kullanıcıya geçerse can sıkıcı userns ID eşlemeleri gerekebiliyor.
  Yine de genel olarak herhangi bir k8s ya da k8s türevi kurulumdan çok daha az karmaşık. systemd ve journald ile tamamen entegre olup iki ayrı yere bölünmemesi de güzel.

  • Benzer bir yaklaşımı birkaç yıldır kullanıyorum: https://github.com/Mati365/hetzner-podman-bunjs-deploy. Podman ve systemd tabanlı; bu süre boyunca hiçbir şey bozulmadı.
    Sadece unit’leri koymanın yeterli olduğu bir yöntem, bu yüzden çok kararlı ve basit.
  • compose dosyalarını Quadlet dosyalarına dönüştürürken podlet kullanabilirsiniz: https://github.com/containers/podlet
  • Sonuçta bunun tek bir düğüm ya da bağımsız düğümler kümesi olduğunu düşünüyorum. Podman/systemd/Quadlet, k8s düğümünün container çalıştırmasına ilişkin bir uygulama detayı, bir bakıma CRI benzeri bir şey olabilir.
    Ama k8s’in birden çok düğüm üzerinde sunduğu orkestrasyon ve zamanlama soyutlamasının yerini tutmaz. “Podman-systemd dosyalarını çalıştırabilen makineler burada, çalıştırmak istediğim tanım da burada; bunları uygun şekilde yerleştir” kısmı eksik.
  • Benzer bir deneyim yaşadım. İş akışı şöyle: podman run komutuyla container’ı ayağa kaldırıp düzgün çalıştığını doğruluyorsunuz; ardından podlet ile temel container dosyasını oluşturuyor, volume ve network’leri başka Quadlet dosyalarına ayıracak şekilde container dosyasını düzenliyorsunuz; hepsi bu.
    podman-compose projesi de hâlâ aktif biçimde bakımı yapılıyor gibi görünüyor ve docker-compose için iyi bir alternatif olabilir. Ama Podman ile systemd entegrasyonu zaten son derece tatmin edici.

• Bunu daha da basitleştirmenin bir sonraki adımı, container’ları systemd içinde Quadlet ile yönetmek. Ayrıntılar https://www.redhat.com/en/blog/quadlet-podman adresinde.

  • Quadlet tam da bu yol. Container çalıştırmak için gerçekten iyi bir yöntem; ayarlayıp unutabileceğiniz türden. Fedora veya Rocky Linux’ta en azından ek paket kurmaya bile gerek yok.
  • Yazının son kısmında ele alınmıştı ama yazar henüz bakmamış durumdaydı. Podman’ın systemd entegrasyonu şimdiden deprecated gibi görünüyor ve artık container’ları “Quadlet” dosyalarıyla tanımlayalım deniyor; yani daha sonra öğrenilecek bir konu olarak bırakmış.
  • Yorumlara gelme sebebim birinin Quadlet’ten bahsedip bahsetmediğini kontrol etmekti. Geçen hafta ev sunucumu docker compose’dan rootless Podman Quadlet’e taşıdım; geçiş zordu ama sonuçtan çok memnunum.
  • Homelab’i Quadlet’e sorunsuz biçimde taşımamda şu yazı da çok yardımcı oldu: https://news.ycombinator.com/item?id=43456934

• skate’i yaptım: https://github.com/skateco/skate. Temelde bu amaç için, ama birden fazla host’u destekliyor ve k8s manifest’lerini de destekliyor. İçeride Podman ve systemd kullanıyor.

  • Bu yaklaşımı çok beğendim. Birden fazla host üzerinde Docker/Podman’ı basitçe çalıştırmanın bir yolu olmaması gerçekten sinir bozucu. Docker Swarm ne yazık ki 2019’dan beri fiilen sahipsiz bırakılmış durumda.
    Öte yandan k8s’in API’sinin ve kullanıcı deneyiminin berbat olduğunu düşünüyorum. Docker Compose spesifikasyonu çok daha kullanıcı dostu; şu anda birden fazla host için docker-compose denemesi yapıyorum: https://github.com/psviderski/uncloud

• Yeniden deb paketi olarak paketleyip EC2 instance’larında doğrudan systemd ile çalıştırma yöntemine döndüm; artık container kullanmıyorum. Instance’ları ALB bağlı bir Auto Scaling Group’a koyuyorum ve açılışta basit bir ansible-pull deb’i kuruyor.
  Oldukça ham bir yöntem ama sonsuz JSON içindeki YAML içindeki HCL’den bıktım. Artık yalnızca Ansible YAML civarında bir şeylerle uğraşmak istiyorum.

  • Bu yaklaşımın iyi yanı, ortak bir kütüphanede bug olduğunda apt full-upgrade çalıştırıp yalnızca çalışan süreçleri yeniden başlatarak korunabilmeniz.
    Bir şeyleri yeniden build etmeniz ya da sizin oluşturmuş olabileceğiniz veya olmayabileceğiniz bir container’ın derinlerine gömülü kütüphaneyi nasıl güncelleyeceğinizi araştırmanız gerekmiyor.
  • Çok basit bir uygulamada aynı yolu seçtim. systemd beklenmedik ölçüde keyifliydi; servisi sistemin atadığı kullanıcı hesabıyla en düşük yetkilerle çalıştırmak oldukça hoşuma gitti.
    cgroup desteği sayesinde tek bir VPS üzerinde birden fazla servis çalıştırmak da güzel.
  • “Büyük ölçekli YAML yönetimi” problem alanına harcanan insan ömrünü düşününce insanın başı dönüyor.

• Yazı bir yılı aşkın eski olduğu için, artık systemd tarafında değişmez (immutable) iş akışları için resmi destek sunan bir OS dağıtımı olan ParticleOS bile var
  https://github.com/systemd/particleos
  https://news.ycombinator.com/item?id=43649088

  • Bir sonraki mantıklı adım Linux çekirdeğini systemd-kernel ile değiştirmek olur; o zaman tamamlanmış olur

• Okuyunca tüm bunların docker compose komutu ve sertifikaları otomatik alan Caddy gibi bir şeyle değiştirilebileceği izlenimi veriyor
  Sadece compose.yaml varsa temelde docker compose up -d --pull always tek satırı yeter. CI ayarı da scp compose.yaml user@remote-host:~/ ardından ssh user@remote-host 'docker compose up -d --pull always' olsa yeterli
  Avantajı basit olması ve geliştirme makinesinde de çalışması. Elbette yan hedef eğlenceli bir şey denemek ve öğrenmekse Quadlet, k8s, systemd de iyi seçenekler

  • Bir kez docker context create --docker 'host=ssh://user@remote-host' remote-host çalıştırmak yeterli
    Sonrasında docker -c remote-host compose -f compose.yaml up -d --pull always kullanırsanız dosya kopyalamanıza gerek kalmaz. Ayrıca ~/.ssh/config içine kullanıcı bilgilerini ayarlarsanız SSH çağrılarında user@ yazmanız gerekmez; ekip içinde dokümanları veya komutları kopyalayıp kullanmak kolaylaşır
  • Kardeş yorumdaki yöntemle yapılabilir ya da DOCKER_HOST ortam değişkeni ayarlanabilir. Ancak compose dosyası interpolasyonunda yerel ortam değişkenlerinin kullanıldığına dikkat etmek gerekir

• Tek bir sunucuya dağıtım yapmanın bu kadar karmaşık olmaması gerektiğini düşündüğüm için, istediğim şekilde dağıtım yapan bir araç yaptım: https://harbormaster.readthedocs.io/
  Harbormaster, YAML dosyasıyla depoyu bulur, periyodik olarak klonlayıp günceller ve içindeki Docker Compose dosyasını çalıştırır. Tüm durumu da tek bir dizinde tuttuğu için yedeklemesi kolaydır
  Sadece tek bir sunucu gerekiyorsa, şimdiye kadar gördüğüm konteyner orkestrasyon araçları içinde en kolay ve en iyisi. Tüm yapılandırmanın depoda deklaratif olarak tanımlanması, tüm durumun tek dizinde olması ve her şeyin sadece Compose dosyası olması hoşuma gidiyor

• Buradaki yorumları okuyunca yaşlanmış gibi hissediyorum. Artık kimse sadece ssh ve nginx kullanmıyor mu diye düşünüyorum
  Her şeyi tek bir kutuya tıkıştırıp o kutuyu agresif biçimde yedeklersiniz, biter. Ev kullanımı için mikroservis yönetimine gerçekten gerek yok

  • Sadece nginx ve birkaç özel servis kullanıyorum ama gereksinimlerim çok küçük olduğu için mümkün. Biraz karmaşıklaşınca veya birden fazla düğüm çalıştırıp yedeklilik gerekince konteynerler inanılmaz derecede anlamlı hale gelmeye başlıyor