Kubernetes को systemd से बदलना (2024)

 (blog.yaakov.online)
2 पॉइंट द्वारा GN⁺ 2025-05-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • निजी servers और छोटे VPS में Kubernetes की declarative automation आकर्षक लगती है, लेकिन CPU और memory का बोझ और operational complexity वास्तविक फायदे से आगे निकल सकते हैं
  • Kubernetes desired state को लगातार मिलाते रहने के तरीके से Pod adjustment और TLS certificate renewal जैसी automation करता है, लेकिन इसके लिए काफी बड़ा runtime हमेशा चालू रखना पड़ता है
  • Azure Kubernetes Service, Microk8s, K3S, और Raspberry Pi experiments में idle resource usage, heat और fan noise बार-बार समस्या बने
  • Podman containers को systemd services में बदल सकता है और io.containers.autoupdate व podman auto-update के जरिए नई images detect करके replace कर सकता है
  • Podman, systemd और user lingering का combination Kubernetes से अपेक्षित ज्यादातर automation को ज्यादा सरल तरीके से देता है, लेकिन systemd integration अब Quadlet की दिशा में जा रहा है

Kubernetes automation निजी server के लिए भारी क्यों थी

  • Kubernetes कई components, web services, sidecars और webhooks से बना है, लेकिन इसका core behavior काफी हद तक ऐसे loop जैसा है जो current state और desired state की लगातार तुलना करके अंतर लागू करता है
    • अगर Pod होना चाहिए लेकिन नहीं है, तो उसे create करता है
    • अगर replicas 3 होने चाहिए लेकिन 4 हैं, तो एक को हटा देता है
  • यह model cert-manager जैसे extensions में खास तौर पर उपयोगी था
    • declare किया जाता है कि किसी specific domain के लिए valid TLS certificate होना चाहिए
    • certificate request करने का तरीका बता देने पर, अगर certificate नहीं है या expiry करीब है, तो नया certificate लेकर web server में install कर देता है
  • निजी experiments के लिए यह मजेदार था और learning value भी थी, लेकिन actual operations के उद्देश्य से यह लगभग overkill tool था
  • resource burden कई environments में बार-बार दिखा
    • NUC पर computer लगातार चलता रहा, गर्म हुआ और fan noise के कारण सोना मुश्किल हो गया
    • Azure Kubernetes Service में Kubernetes implementation ने काफी RAM ली, और worker node पर idle CPU लगभग 7–10% इस्तेमाल हुआ
    • 2 vCPU x86_64 VPS पर single-instance Microk8s में idle CPU लगभग 12% स्तर पर था
    • 2 vCPU Ampere A1 machine पर K3S को lighter implementation माना जाता है, लेकिन उसने लगातार लगभग 6% CPU इस्तेमाल किया
    • Raspberry Pi पर भी ऐसा implementation नहीं मिला जो heat और fan issues के बिना workloads के लिए पर्याप्त CPU छोड़ सके

Podman और systemd से बदली गई automation पद्धति

  • Kubernetes चलाते रहने की सबसे बड़ी वजह deployment automation थी
    • GitOps और Flux इस्तेमाल करने पर changes करना आसान था
    • container image automation और Flux v2 के webhooks के साथ, नई image push करते ही server कुछ सेकंड में नई image लेकर production application चलाने लगता था
  • Kubernetes के बाहर मिले existing alternatives संतोषजनक नहीं थे
    • original command-line arguments सब याद रखकर container दोबारा बनाने वाला तरीका management burden बढ़ाता था
    • docker.sock पर पूरा control मांगने वाले tools भी पसंद नहीं थे
  • Podman auto-updating जरूरत के करीब था
    • Podman को Docker CLI alternative माना जा सकता है
    • container बनाने के बाद systemd service file generate की जा सकती है
    • service start करने पर container create या replace होता है, और service stop करने पर container remove होता है
  • automatic updates io.containers.autoupdate tag से काम करते हैं
    • इसे दिन में एक बार timer से चलाया जा सकता है या podman auto-update सीधे run किया जा सकता है
    • नई image होने पर container उसी image से recreate होता है
  • Fedora Magazine के Auto-updating Podman containers with systemd ने implementation का अधिकांश तरीका दिया, और इसके अलावा दो settings की जरूरत थी
    • systemctl --user enable mycontainer.service से login के समय container auto-start कराया जाता है
    • loginctl enable-linger से server start होने पर user session चलने लगता है
  • Podman, systemd और user lingering के combination से Kubernetes से मिलने वाले फायदों का लगभग 99% बहुत कम complexity और CPU/memory burden के साथ मिला
  • सभी services को पुराने VPS से ऐसे नए VPS पर migrate किया गया जिसमें vCPU और RAM आधे थे, और कुछ घंटे चलाने के आधार पर यह ज्यादा हल्का, तेज और compute cost में भी कम था
  • हालांकि Podman का systemd integration पहले ही deprecated लगता है, और container definitions के लिए Quadlet files की दिशा में discussion हो रहा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-06
Hacker News की राय

  • मैं मूल लेखक की भावना से पूरी तरह सहमत हूँ। काम पर हम दर्जनों microservices चलाने वाले कई Kubernetes clusters को अपेक्षाकृत आसानी से मैनेज करते हैं, लेकिन बिना कमाई वाले hobby projects में बजट इतना छोटा होता है कि Kubernetes इस्तेमाल करना चाहें तब भी नहीं कर पाते
    1 shared vCPU और 2GB RAM वाले $10/महीना VPS पर Kubernetes बहुत भारी पड़ता है। Deployment की जगह SSH से docker compose up/down हाथ से चलाना पड़ता है, Ingress की जगह Traefik के container discovery फीचर पर निर्भर रहना पड़ता है, और CronJobs नहीं चला सकते, इसलिए crontab को idempotent तरीके से मैनेज करने के लिए छोटा script भी खुद बनाना पड़ा
    असल में चाहिए एक हल्का विकल्प जो सस्ते VPS पर भी ठीक से चले और Kubernetes-compatible API दे सके। enterprise-grade container orchestration और hobby-use low-cost hosting के बीच का अंतर अभी भी बहुत बड़ा है

    • ज़रूरी Kube API की सीमा के हिसाब से Podman यह भूमिका निभा सकता है। यह Kubernetes manifests से containers और pods बना सकता है, इसलिए यह Kubernetes manifests इस्तेमाल करने वाले docker compose की तरह काम करता है
      लेख में बताए गए तरीके की तरह इसे systemd units के साथ भी इस्तेमाल किया जा सकता है। Podman ज़्यादातर या पूरा Docker API भी सपोर्ट करता है, इसलिए docker compose भी चलता है, और SSH के ज़रिए remote socket से कनेक्ट करके काम भी किया जा सकता है
      https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
      https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
    • सोच रहा हूँ कि क्या आपने k0s या k3s देखा है। छोटे scale पर इन्हें अच्छे से इस्तेमाल करने के काफ़ी उदाहरण हैं: https://news.ycombinator.com/item?id=43593269
    • Oracle का प्रचार करता हुआ नहीं लगना चाहता, लेकिन Oracle Cloud Free Tier बेहद उदार है। इसमें छोटे k8s cluster समेत काफ़ी कुछ चलाया जा सकता है, और k8s control plane service भी मुफ़्त है
      इसमें मुफ़्त में 4 ARM64 cores और 24GB RAM मिलती है, और आप चाहें तो इसे 1 से 4 nodes में बाँट सकते हैं
      https://www.oracle.com/cloud/free/
    • पुराने तरीके से Ansible जैसी किसी चीज़ का इस्तेमाल कर सकते हैं। मैं कुछ dedicated servers को Ansible से पूरी तरह मैनेज करता हूँ, और इसे एक तरह के उन्नत docker compose की तरह इस्तेमाल किया जा सकता है
      Traefik और labels से reverse proxy और TLS certificates को सामान्यीकृत किया जा सकता है, और Authelia को एक सरल auth provider के रूप में जोड़ा जा सकता है। GitHub पर example projects भी बहुत हैं, और एक weekend सेटअप करने के बाद यह काफ़ी आसान-से-मैनेज होने वाला system बन जाता है
    • आपने पहले ही कहा है कि Kubernetes चलाने की लागत बहुत ज़्यादा है, इसलिए efficiency किस आधार पर नापते हैं, उसके हिसाब से आपका खुद का बनाया समाधान शायद ज़्यादा efficient भी हो सकता है

  • systemd को बहुत गालियाँ मिलती हैं, लेकिन यह वाकई बहुत-सी समस्याएँ हल करता है, इसलिए इसे आसानी से नज़रअंदाज़ नहीं करना चाहिए। जब यह distros में default के रूप में आने लगा था, तब लोगों को बदलाव पसंद नहीं आया, यह भी एक बड़ा कारण था
    इसमें containers, machinectl, अधिक शक्तिशाली chroot जैसा nspawn, पूरी virtualization चाहिए तो vmspawn, machines को डाउनलोड, import और export करने के लिए importctl, और home directories की encryption व permissions control को आसान बनाने वाले homed/homectl जैसी चीज़ें हैं
    fstab की जगह mounts को units के रूप में संभाला जा सकता है, boot order और service start/stop को नियंत्रित किया जा सकता है, और cron से अधिक शक्तिशाली timers भी मिलते हैं। उदाहरण के लिए, अगर machine बंद होने की वजह से कोई job नहीं चल सकी हो तो यह पता चल सकता है, या boot के बाद कुछ conditions में delayed execution किया जा सकता है
    service units कामों को बारीकी से नियंत्रित कर सकते हैं और permissions सीमित कर सकते हैं, और systemctl edit से मूल config को छेड़े बिना override config बनाया जा सकता है। शुरुआत में सीखना थोड़ा झंझट भरा है, लेकिन जटिल काम करने हों तो वैसे भी कोई tool ऐसा नहीं होता जिसे बिना docs देखे इस्तेमाल किया जा सके

    • systemd को शुरुआती कुछ सालों तक, शायद लगभग 10 साल तक जो गालियाँ मिलीं, वह इसलिए नहीं था कि project खुद खराब था। उल्टा, कई समस्याओं के बावजूद वह इतना अच्छा था कि सफल हो गया
      समस्या maintainers के रवैये में थी। वे ठीक-ठाक चल रही चीज़ों को बेफ़िक्री से तोड़ देते थे और उसके लिए उचित workaround भी नहीं देते थे। अगर systemd की वजह से आपको कभी तकलीफ़ नहीं हुई, तो हो सकता है आप बाद में जुड़े हों, या आपकी ज़रूरतें संयोग से core maintainers की ज़रूरतों से मेल खाती रही हों
    • systemd में मुझे जो एकमात्र बात पसंद नहीं है, वह यह है कि एक गिनती से बाहर विशाल codebase से निकला binary PID 1 की भूमिका निभाता है, और upgrade के समय खुद को उसी जगह exec करने जैसी और भी जटिल हरकतें करता है
      PID 1 का काम 100% सही तरीके से करे और उसके अलावा कुछ भी न करे, ऐसा program कहीं छोटा हो सकता है। यहाँ यदि systemd के ऊपर कुछ चलाया जाए, तो systemd में कोई दिक्कत आने पर भी वह तुरंत kernel panic में नहीं बदलेगा
      स्रोत: https://ewontfix.com/14/
    • यह कहना कि cron को भूल जाओ, मानना मुश्किल है। यह 50 साल से ठीक से काम कर रहा है, और अचानक ऐसा मान लिया जाए कि यह बहुत गलत चीज़ है और स्वाभाविक रूप से systemd से बदल दिया जाना चाहिए
    • fstab छोड़कर systemd mounts इस्तेमाल करने पर automount rules जटिल हो जाते हैं, और docs से 1:1 मिलाने पर भी कभी-कभी वे बस काम नहीं करते, जिससे filesystem समय पर mount नहीं हो पाता
    • systemd आधुनिक desktop या server Linux, या उसी तरह के उपयोगों के लिए शानदार है। लेकिन अगर आप project द्वारा मानकर चले गए रास्ते से हटकर कुछ करना चाहें, तो आपको उपहास और विरोध का सामना करना पड़ेगा। musl team से पूछ लीजिए
      distro या upstream के नज़रिए से यह ज़िंदगी बहुत आसान बना देता है, लेकिन इसकी कीमत सिस्टम की सबसे निचली परत में लगातार बढ़ती जटिलता के रूप में चुकानी पड़ती है। नज़रिए के हिसाब से journalctl, timedatectl, dbus dependency या replacement जैसी चीज़ें Unix philosophy के ख़िलाफ़ लग सकती हैं
      अगर मकसद सिर्फ processes को orchestrate करना, सही क्रम में चलाना और automatic activation सुनिश्चित करना है, तो यह k8s या Docker की तुलना में ज़्यादा उपयुक्त स्तर का tool लगता है

  • मैं कुछ समय से अपने homelab को podman-systemd, यानी Quadlet, पर चला रहा हूँ, और जब भी किसी नए k8s variant को देखता हूँ तो लगा कि अतिरिक्त झंझट उठाने लायक नहीं है। पुरानी Ansible playbook में images पहले से pull कर लेना और unit files को उनकी सही जगह पर रख देना ही काफी है
    मैंने पूरा Voron 3D printer stack भी podman-systemd पर चलाया है, ताकि सभी components को एक साथ update और rollback किया जा सके। हालांकि अब mkosi और systemd-sysupdate के साथ पूरे disk image को एक बार में update/rollback करने का तरीका भी देख रहा हूँ
    मुख्य समस्या यह है कि लोग आमतौर पर सिर्फ docker-compose files ही वितरित करते हैं, इसलिए उन्हें systemd units में बदलना पड़ता है, और कुछ Docker images user/permission settings के मामले में Podman के लिए अनावश्यक जटिलता लेकर आती हैं। खासकर जब कोई container root में चलने से मना करे या किसी दूसरे user पर switch करे, तब परेशान करने वाली userns ID mapping की जरूरत पड़ सकती है
    फिर भी, कुल मिलाकर यह किसी भी k8s या k8s variant setup की तुलना में बहुत कम जटिल है। यह भी अच्छा है कि सब कुछ systemd और journald में integrated रहता है, दो अलग जगहों में बंटा नहीं रहता

    • मैं भी कई वर्षों से ऐसा ही approach इस्तेमाल कर रहा हूँ: https://github.com/Mati365/hetzner-podman-bunjs-deploy. यह Podman और systemd आधारित है, और अब तक कुछ भी टूटा नहीं है
      सिर्फ units डालने होते हैं, इसलिए यह बहुत स्थिर और सरल है
    • compose files को Quadlet files में बदलने के लिए आप podlet का उपयोग कर सकते हैं: https://github.com/containers/podlet
    • आखिरकार, यह single-node या स्वतंत्र nodes के समूह जैसा ही है। Podman/systemd/Quadlet को उस implementation detail की तरह देखा जा सकता है जिससे k8s node containers चलाता है, यानी कुछ हद तक CRI जैसा
      लेकिन यह k8s द्वारा दिए जाने वाले कई nodes पर orchestration·scheduling abstraction का विकल्प नहीं है। इसमें वह हिस्सा गायब है जो कहे: “ये machines हैं जो Podman-systemd files चला सकती हैं, और यह वह spec है जिसे मैं चलाना चाहता हूँ, अब इसे अपने-आप deploy कर दो”
    • मेरा अनुभव भी ऐसा ही है। workflow यह है कि पहले podman run command से container चलाकर देखते हैं, ठीक से काम करता है या नहीं यह जांचते हैं, फिर podlet से base container file बनाते हैं, और volumes व networks को अलग Quadlet files में बाँटते हुए container file को modify कर देते हैं, बस काम हो जाता है
      podman-compose project भी अब भी सक्रिय रूप से maintained लगता है और docker-compose का अच्छा विकल्प हो सकता है। लेकिन Podman और systemd का integration इतना संतोषजनक है कि वही ज्यादा पसंद आता है

  • इसे और सरल बनाने का अगला कदम systemd के भीतर Quadlet से containers manage करना है। अधिक जानकारी https://www.redhat.com/en/blog/quadlet-podman में है

    • Quadlet ही सही रास्ता है। containers चलाने के तरीके के रूप में यह वास्तव में बहुत अच्छा है, और एक बार configure कर देने पर भूल जाने जैसा है। Fedora या Rocky Linux पर तो कम से कम कोई extra package install करने की भी जरूरत नहीं होती
    • लेख के अंत में इसका जिक्र था, लेकिन लेखक ने अभी तक इसे देखा नहीं था। Podman का systemd integration पहले से ही deprecated जैसा दिख रहा है और अब “Quadlet” files से containers define करने की बात हो रही है, इसलिए इसे बाद में सीखने वाली चीज़ समझकर छोड़ दिया गया था
    • मैं comments देखने इसलिए आया था कि क्या किसी ने Quadlet का जिक्र किया है। पिछले हफ्ते मैंने अपने home server को docker compose से rootless Podman Quadlet पर migrate किया, और migration कठिन था, लेकिन नतीजे से बहुत संतुष्ट हूँ
    • homelab को Quadlet पर smoothly migrate करने में यह पोस्ट भी बहुत मददगार है: https://news.ycombinator.com/item?id=43456934

  • मैंने skate बनाया है: https://github.com/skateco/skate. मूल रूप से यह इसी उद्देश्य के लिए है, लेकिन यह कई hosts और k8s manifests को भी support करता है। अंदरूनी तौर पर यह Podman और systemd का उपयोग करता है

    • यह approach मुझे बहुत पसंद है। कई hosts पर Docker/Podman को सरल तरीके से चलाने का कोई आसान साधन न होना वाकई निराशाजनक है। Docker Swarm दुर्भाग्य से 2019 के बाद से लगभग छोड़ दिया गया है
      लेकिन मेरी नज़र में k8s का API और user experience बहुत खराब है। Docker Compose spec कहीं अधिक user-friendly है, इसलिए मैं अभी multi-host docker-compose पर प्रयोग कर रहा हूँ: https://github.com/psviderski/uncloud

  • मैं फिर से deb package बनाकर EC2 instances पर सीधे systemd से चलाने वाले तरीके पर लौट आया हूँ, और अब containers का उपयोग नहीं करता। instances को ALB लगे हुए Auto Scaling Group में रखा जाता है, और boot के समय एक साधारण ansible-pull deb install कर देता है
    यह काफी raw तरीका है, लेकिन JSON के अंदर YAML के अंदर HCL के अंतहीन ढेर से मैं थक गया था। अब मैं सिर्फ Ansible YAML जैसा कुछ ही संभालना चाहता हूँ

    • इस approach की अच्छी बात यह है कि अगर किसी shared library में bug हो, तो apt full-upgrade चलाकर सिर्फ running processes को restart करना काफी है और आप सुरक्षित हो जाते हैं
      आपको कुछ दोबारा build करने की जरूरत नहीं पड़ती, न ही यह खोजने की कि किसी container के भीतर गहराई में दबी library को कैसे update करें, जिसे आपने खुद बनाया भी हो सकता है या नहीं भी
    • बहुत साधारण applications के लिए मैंने भी यही रास्ता चुना। systemd उम्मीद से ज्यादा सुखद निकला, और यह बात काफी अच्छी लगी कि services को system-assigned user accounts के साथ least privilege में चलाया जा सकता है
      cgroup support की वजह से एक ही VPS पर कई services चलाना भी अच्छा रहता है
    • “बड़े पैमाने पर YAML प्रबंधन” जैसी समस्या-श्रेणी में जितना मानवीय जीवन बर्बाद हुआ है, उसे सोचकर ही डर लगता है

  • यह लेख 1 साल से ज़्यादा पुराना है, इसलिए अब systemd के लिए immutable workflow हेतु आधिकारिक सपोर्ट देने वाला OS distribution ParticleOS भी मौजूद है
    https://github.com/systemd/particleos
    https://news.ycombinator.com/item?id=43649088

    • अगला तार्किक कदम शायद Linux kernel को systemd-kernel से बदलना होगा, फिर तो काम पूरा हो जाएगा

  • इसे पढ़कर लगा कि यह सब कुछ docker compose कमांड और अपने-आप certificate ले आने वाली किसी चीज़, जैसे Caddy, से बदला जा सकता है
    अगर सिर्फ compose.yaml हो, तो मूल रूप से docker compose up -d --pull always की एक लाइन काफी है। CI setup भी scp compose.yaml user@remote-host:~/ के बाद ssh user@remote-host 'docker compose up -d --pull always' से हो जाता है
    फ़ायदा यह है कि यह सरल है और dev machine पर भी चलता है। बेशक, अगर अतिरिक्त लक्ष्य कुछ मज़ेदार करना और सीखना हो, तो Quadlet, k8s, systemd भी अच्छे विकल्प हैं

    • बस एक बार docker context create --docker 'host=ssh://user@remote-host' remote-host चलाना होता है
      उसके बाद docker -c remote-host compose -f compose.yaml up -d --pull always इस्तेमाल कर सकते हैं, और फ़ाइल कॉपी करने की ज़रूरत नहीं रहती। साथ ही, अगर ~/.ssh/config में user जानकारी सेट कर दी जाए, तो SSH calls में user@ लिखने की भी ज़रूरत नहीं पड़ती, जिससे टीम में docs या commands को copy-paste करना आसान हो जाता है
    • sibling comment वाले तरीके से करें या DOCKER_HOST environment variable सेट कर दें। बस ध्यान रहे कि compose file interpolation में local environment variables इस्तेमाल होते हैं

  • मुझे लगा कि single server पर deploy करना इतना जटिल नहीं होना चाहिए, इसलिए मैंने अपनी पसंद के तरीके से deploy करने के लिए एक टूल बनाया: https://harbormaster.readthedocs.io/
    Harbormaster YAML files में repositories ढूँढता है, उन्हें समय-समय पर clone और update करता है, फिर उनमें मौजूद Docker Compose files चलाता है। सारा state भी एक ही directory में रखता है, इसलिए backup लेना आसान है
    अगर सिर्फ single server चाहिए, तो अब तक देखे गए container orchestration tools में यह सबसे आसान और अच्छा लगता है। पूरी config repository में declarative रहती है, सारा state एक directory में रहता है, और सब कुछ बस Compose files होने की बात मुझे पसंद है

  • यहाँ के comments पढ़कर उम्र का एहसास होने लगा। क्या अब कोई सिर्फ ssh और nginx का इस्तेमाल नहीं करता?
    सब कुछ एक ही box में ठूँस दो, और उस box का आक्रामक तरीके से backup लेते रहो, बस। घर में इस्तेमाल के लिए microservices manage करना सच में ज़रूरी नहीं है

    • मैं भी nginx और कुछ custom services ही इस्तेमाल करता हूँ, लेकिन यह इसलिए संभव है क्योंकि requirements बहुत छोटी हैं। जैसे ही चीज़ें थोड़ी जटिल हों या कई nodes चलाने पड़ें और redundancy चाहिए हो, containers बहुत ज़्यादा समझदारी भरे लगने लगते हैं