Kubernetes alternatives: 必要な制御を選ぶ

Kubernetes の代替は、マネージドなアプリホスト、別のスケジューラ、またはサーバーへコンテナをデプロイするよりシンプルな方法になり得ます。 何の管理をやめたいのかで選びましょう。API、worker、database だけが必要なら、アプリケーションプラットフォームで要件を満たせるかもしれません。カスタムスケジューリングやインフラポリシーが必要なら、スケジューラを評価するか、Kubernetes を維持してください。

このガイドは Lizard によるものです。リンク先の製品ドキュメントは 2026年9月9日 に確認しました。以下の選択肢はそれぞれ異なる問題を解決するものであり、Kubernetes の相互交換可能な実装ではありません。

なくしたい作業を特定する

現在チームが担っている作業を書き出してください。たとえば cluster upgrades、ingress、certificates、storage、networking、permissions、deployment policies、monitoring です。次に、その作業のうちアプリケーションに必要だから存在するものと、cluster を選んだために存在するものを切り分けましょう。

この区別により、運用負荷が同じ別のシステムへ高コストな移行をしてしまうのを防げます。managed control plane は cluster administration を助けられますが、workload や networking の判断は引き続き自分で行うことになります。managed app platform なら、それらの判断の多くを引き受ける一方で、低レベルの制御は少なくなります。

比較する 7 つのアプローチ

マネージドアプリケーションプラットフォーム

要件が public API、少数の workers、database であるなら、最初に試すべきモデルです。Lizard はこのワークフローを Lizard CLI で提供し、データサービスとして Managed Postgres と Managed Redis を利用できます。

このトレードオフは意図的なものです。使うのはプラットフォームがサポートする制御です。特定の operator、admission policy、または custom network setup に依存しているなら、移行前にその要件を確認してください。他のプロバイダーや課金モデルについては PaaS comparison を参照してください。

ECS と Cloud Run

Fargate は、worker hosts を自分で運用しなくても、対応する ECS および EKS workloads を実行できます。ECS では、引き続き tasks と services を定義し、その周辺にある AWS resources も考慮する必要があります。networking、load balancing、logs も予算に含めてください。

Cloud Run は、services、jobs、worker pools に対して異なる resource types を提供します。各 process を適切な type に対応させてください。HTTP service の scaling や billing の設定が、継続的な queue consumer も表しているとは考えないでください。

これらの選択肢は、対象 cloud の identity と networking model にすでに慣れているチームには適しています。Kubernetes を離れたい理由がその model を避けることにあるなら、魅力は下がります。

Nomad と Docker Swarm

Nomad は別の workload scheduler です。job model、supported drivers、operational requirements を、自分たちの workloads に照らして評価してください。別の scheduler を選んでも、service discovery、persistent data、recovery planning の必要がなくなるわけではありません。

Docker Swarm は Docker Engine に組み込まれており、複数 host の swarm 全体で services を管理します。すでに Docker を使っているチームには馴染みやすいかもしれませんが、それでも hosts の保守と manager availability の保護は必要です。host 障害時に persistent data と placement がどう振る舞うかをテストしてください。

設定行数が少ないデモだけを理由に、どちらかを選ぶべきではありません。有用な評価には upgrades、host 障害、実際の deployment rollback を含める必要があります。

Kamal、Coolify、Dokploy

Kamal は、用意したサーバーへ containerized web applications をデプロイします。汎用的な cluster scheduler を導入せずに、再現可能な deploy process を求めるチームに適しています。

Coolify と Dokploy は、自分で管理するインフラ上で deployment workflows を提供します。現在の app、database、domains、deployment source への対応状況を比較してください。

これらのツールでも、machine の所有責任を持つ人は必要です。OS updates、access control、monitoring、disk space、検証済み backups を計画してください。これらの作業の具体例は Django VPS guide にあります。

Kubernetes を維持するのが妥当な場合

アプリケーションが、チームがすでにうまく使いこなしている制御を必要とするなら、候補から外すべきではありません。たとえば custom resources、複雑な workload policy、共有の内部 deployment platform、または簡単な代替がないインフラ機能です。

また、すでに機能している automation や knowledge をどれだけ捨てることになるかも考慮してください。移行が有用なのは、現実のコストや制約を減らせるときです。置き換え先で別の手作業が増えるなら、YAML files の数を減らすだけでは不十分です。

すべての abstraction を写経せずに移行を試す

application contract から始めてください。image、start command、configuration、port、health check、data、shutdown behaviour です。これらの要件を新しい host に対応づけましょう。provider が同じ責務を担ってくれるなら、すべての Kubernetes object に対応する同等 object は不要です。

最初は stateless service を 1 つ移してください。user flow、error behaviour、resource consumption を確認します。workers と data の移行は、その lifecycle をテストしてからにしてください。新しい database writes を含む rollback plan ができるまでは、古い route を維持してください。

請求額だけでなく運用時間も比較してください。provider は cluster 作業を減らせても compute の料金は高いかもしれません。VPS は請求額を下げられても、チームに残る作業は増えるかもしれません。

FAQ

小規模なアプリケーションに Kubernetes は必要ですか？ デフォルトでは必要ありません。その制御が要件を解決し、かつチームが運用できるときに選んでください。標準的な API と worker であれば、よりシンプルなデプロイモデルで十分なことがよくあります。

managed Kubernetes は PaaS と同じですか？ いいえ。managed cluster では通常、workload configuration は引き続き自分で扱います。PaaS はよりアプリケーション中心の契約を提供しますが、責任分担の正確な境界は異なります。

application code を変更せずに移行できますか？ 場合によります。configuration、storage、cloud 固有の依存関係は引き続き見直しが必要です。image portability がそのまま運用上の等価性を意味すると考えるのではなく、app contract をテストしてください。

最もコストが低い代替はどれですか？ workload と、それを運用するために必要な作業で比較してください。databases、network、storage、monitoring、recovery を含めて評価し、control-plane の価格だけで製品を順位付けしないでください。