Kubernetesをsystemdで置き換える（2024年）

 (blog.yaakov.online)
2 ポイント 投稿者 GN⁺ 2025-05-06 | 1件のコメント | WhatsAppで共有
  • 筆者は個人サーバー運用における Kubernetesの複雑さとリソース消費 に辟易し、これを systemdとPodman の組み合わせで置き換えた経験を共有している
  • Kubernetesは GitOpsと自動化 の面で魅力的だが、小規模な環境では過剰に重いシステムである
  • Podmanの自動更新機能 と systemdサービス生成 を活用すれば、従来Kubernetesが担っていた主要機能をシンプルに実現できる
  • systemctlとloginctlを組み合わせたユーザーレベルサービスの自動実行 についても説明し、VPSのリソース消費が大幅に減ったことを強調している
  • ただし、Podmanのsystemd統合は まもなく「Quadlet」という新しい方式に置き換えられる予定 だと述べている

序論: Kubernetesとの最初の出会い

  • 2018年にKubernetesを試し、個人用NUCにクラスターを構築 しようとした経験を紹介している
  • Kubernetesは複雑だが、基本的には次のような 反復ループ構造 で動作する:
    • 現在の状態を把握 → 望ましい状態を計算 → 差分を計算 → 適用
  • cert-manager などのさまざまなコンポーネントを活用した自動化機能は 非常に印象的 だった

Kubernetesの過大なリソース要求

  • 個人サーバー（NUC）上でKubernetesは 継続的なCPU使用、ファンの騒音、発熱 を引き起こした
  • Azure、MicroK8s、K3Sなどのさまざまなディストリビューションも かなりのリソース を消費した
    • MicroK8s: CPU使用率 12%（2vCPU VPS）
    • K3S: CPU使用率 6%（2vCPU Ampere A1）

GitOps自動化の誘惑

  • Fluxのようなツールにより Gitベースのデプロイ自動化 が可能で、とても便利だった
  • GitHubにコンテナイメージをプッシュするだけで、サーバーが自動的に最新アプリをデプロイしてくれた
  • しかし、Kubernetesなしでこのような 自動化を実装するのは非常に難しかった

Podmanとsystemdの登場

  • PodmanはDockerの代替ツールであり、コンテナをsystemdサービスに変換 する機能を持っている
  • podman generate systemd により、自動的にserviceファイルを生成できる
  • io.containers.autoupdate タグを通じて 1日1回の自動イメージ更新 が可能
  • Fedora Magazineでこの方法を参考にし、Kubernetes代替環境の構築 に成功した

必要な3つの構成要素

  1. systemctl --user enable mycontainer.service

    • ログイン時にコンテナが自動実行されるよう設定

  2. loginctl enable-linger

    • サーバー起動時にユーザーセッションが有効になるよう設定

  3. Podmanのauto-update機能

  • この3つによって、Kubernetesが提供していた機能の99%を よりシンプルかつ軽量に置き換える ことができた

移行結果

  • 既存のVPSから新しいVPSへ、全サービスを移行した
  • リソースは半分に減った一方で性能はむしろ向上 し、サービス密度の向上とコスト削減効果も確認できた

今後の課題: Quadlet

  • 残念ながら、Podmanのsystemd統合は まもなく廃止予定 である
  • 代わりに Quadletファイル という新しい定義方式へ移行する予定だ
  • 新しい技術を学ぶ準備が必要だと付け加えて締めくくっている

関連記事

1件のコメント

 
GN⁺ 2025-05-06
Hacker Newsの意見

  • Kubernetesを単にコンテナイメージの実行と更新のためだけに見るなら、過剰な利用かもしれない

    • Kubernetesは、コンテナが状態を共有し、相互接続し、設定やシークレットにアクセスできるように必要なリソースを提供する
    • CPUとメモリのコストは、コンテナ管理と必要なリソース提供から発生する
    • 分散システムでは、すべてのシステムが望むとおりに動作するわけではないため、管理者は継続的に望ましい状態を実現しようと努める

  • Dockerを使っていくつかの小さなWebサイトを運用しようとしたが、イメージの更新とテストが難しかった

    • Debianでsystemdユニットを生成するスクリプトですべてを置き換え、サービス変更時に再起動する
    • テスト用VMを使って変更をデプロイホストにrsyncし、デプロイスクリプトを実行する
    • システム全体は2GBのVPSで動作しており、WordpressがSQLiteを公式サポートすれば1GBまで減らせる
    • Mariadbを使ってサポート要件を最小限にしている

  • Kubernetesクラスターの管理自体に問題はないが、趣味プロジェクトではリソース要件のため使いづらい

    • Kubernetesは月額10ドルのVPSで動かすにはリソース集約的すぎる
    • 手動でdocker composeコマンドを使い、Ingressの代わりにTraefikのコンテナ検出機能を使う
    • CronJobsの代わりに小さなスクリプトを書いてcrontabを管理する
    • Kubernetesがすでに解決した問題を、より非効率な形で解決しようとしている
    • 安価なVPSインスタンス上でうまく動く、Kubernetes互換APIを提供する軽量な代替を望んでいる

  • systemdは多くの問題を解決するので、無視すべきではない

    • machinectl、nspawn、vmspawn、importctlなど多様な機能を提供する
    • homed/homectlはユーザー管理の拡張、mountsはドライブの自動マウント、bootはサービス開始/停止の制御、timersはcronの代替
    • サービスユニットはジョブを制御し、systemctl editで設定ファイルを編集できる

  • Podman-systemdを使ってhomelabを運用しており、新しいKubernetes派生を調べるたびに追加の面倒は感じない

    • Ansibleプレイブックを使ってイメージを事前に取得し、ユニットファイルを適切な場所に配置する
    • Voron 3Dプリンタースタックをpodman-systemdで運用しており、mkosiとsystemd-sysupdateへの移行を検討している
    • Docker-composeファイルをsystemdユニットに変換しなければならない煩わしさがある
    • Podmanはユーザー/権限設定の複雑さを減らしてくれる

  • Quadletを使ってsystemd内でコンテナを管理するのが次の段階である

    • 詳細はRed Hatブログで確認できる

  • Skateを作って、マルチホストとKubernetesマニフェストをサポートするシステムを構築した

    • 内部的にはpodmanとsystemdを使っている

  • Docker composeコマンドとCaddyを使えば、証明書を自動取得できる

    • docker compose up -d --pull always コマンドで簡単に設定できる
    • CI設定はscpとsshを使って構成されている
    • シンプルで、開発マシンでも動作する

  • systemdは現在、不変ワークフロー向けの公式サポートOSディストリビューションであるParticleOSを提供している

  • 単一サーバーへのデプロイは複雑であるべきではないと考え、Harbormasterというツールを書いた

    • YAMLファイルを使ってリポジトリを検出し、Docker Composeファイルを実行する
    • すべての状態を単一ディレクトリに保持するため、バックアップが容易である
    • 単一サーバーに必要な最も簡単なコンテナオーケストレーションツールである