Kubernetesはステートレスではないので、バックアップツールが必要です

すべてが「Gitops」になり、すべてのワークロードが「ステートレス」になった今、 Kubernetes バックアップ ツールはまだ必要ですか?これは初心者がよく犯す重大な誤解だということをお見せしたいと思います…

Michael Courcy による「Kubernetes はステートレスではないので、バックアップ ツールが必要です」からの翻訳です。

奇妙な仮定

Kubernetes を使用している顧客や見込み客から、次のような奇妙な思い込みをよく耳にします。

Kubernetes を使用すると、すべてが Gitops になり、ステートレスになります。

したがって：

すべてが「Gitops」になり、すべてのワークロードが「ステートレス」になった今、Kubernetes バックアップ ツールはまだ必要ですか?

これは初心者がよく犯す重大な誤解であることをお見せしたいと思います。彼らは、災害復旧管理がツール チェーンを再起動するのと同じくらい簡単になり、バックアップ ツールに投資する必要がなくなることを期待しています。

ここではサーバーレスとステートレスが混同されていますが、開発者の観点から見ると、Kubernetes はサーバーレスですが、決してステートレスではありません...

しかし、これに踏み込む前に、まず Gitops、ステートレス、ツールチェーンという異なる用語を明確にしておきましょう。

ギトプスと無国籍

Gitops は、GIT と CI/CD ツールを使用してインフラストラクチャの自動化を適用する DevOps プラクティスです。 GIT で新しいコード変更をコミットすることでインフラストラクチャを宣言し、CI/CD ツールによって変更が自動的にデプロイ/適用されます。

ステートレスとは、アプリケーションに永続的な値がないことを意味し、アプリケーションを最初から再デプロイしても、以前と同じように動作し続けます。ステートレス アプリケーションは、どのストレージ メディアにもデータを保持しません。

ツールチェーンは、GIT からコードを取得し、それに対してさまざまな操作を実行してインフラストラクチャを構築するツールのセットです。ツールチェーンは、生成される結果が以前の実行の状態に依存しない場合、べき等であると呼ばれます。優れたツールチェーンはべき等性を持つ必要があります。

コンテナは無国籍感を強める

コンテナ化では、アプリケーションの実行に必要なすべての依存関係がコンテナに「含まれる」ため、このステートレス性の考え方が強化されます。イメージはこの依存関係のリストを定義し、コンテナはこのイメージの一時的なインスタンスです。コンテナを実行しているマシンを失っても、大きな問題にはなりません。別のマシンのイメージから新しいコンテナ インスタンスを再デプロイするだけです。コンテナ ランタイムはイメージ定義からすべてのファイルを再構築するため、長期的に実行し続けることができます。

ただし、コンテナーがボリュームを使用する場合は、これは当てはまりません。たとえば、データベース コンテナーはボリュームを使用してデータを書き込みます。この場合、コンテナはステートフルです。ボリュームが失われると、再起動時にデータベースは空になります。

コンテナは、ステートフルでない限りステートレスです。馬鹿げているように聞こえますか?同意します...

2023 年の Datadog の最新レポート (事実 6) に次のような結果が示されていることを知ったら、驚かれるかもしれません。

データベースと Web サーバーは、コンテナの主なワークロード カテゴリです。

はい、その通りです。コンテナのワークロードの主なクラスはステートフルです。

Kubernetes を使用すると、「ステートレス」の感覚が新たな限界に達し、どのコンテナがどのマシンにデプロイされているかを覚えておく必要さえなくなります。Kubernetes がこれを処理し、必要な状態を動的に処理するからです。 Kubernetes を使用すると、インフラストラクチャを完全に抽象化でき、コードだけが重要になるという強い感覚が得られます。

アプリケーションを公開するためのロードバランサー、レプリカの数、メモリと CPU、シークレット、構成ファイルなど、Kubernetes で「望ましい状態」を定義する必要があります。ただし、これらはすべて Kubernetes に適用する YAML ファイルで定義され、GIT で管理されます。

でも待ってください！まだ Kubernetes クラスターを構築して保護する必要があります。複雑な作業ですよね？

もうない！クラウドでは、1 分以内に Kubernetes クラスターを構築できるようになりました。 AWS または Azure コンソールで 1 回クリックするか、単純な「glcoud containers create...」コマンドを実行するか、GIT で新しいクラスター定義とクラウド API に接続された CI/CD ツールを実行するだけで完了です。

すべてが「無国籍」であるという感覚が今、劇的に高まっています。

Kubernetes でのバックアップについて話すと、本当に困惑している潜在的な顧客に遭遇します...

今こそ、現実をもう一度見つめ直し、現状の現実について話し合うべき時です。

ステートレスアプリケーションは現実には存在しない

アプリケーション全体を見ると、ステートレス アプリケーションは実際には存在しないことがすぐにわかります。注文を管理せず、顧客の住所も管理しないオンライン ストアを想像してみてください。取引を管理しない銀行アプリケーションを想像してみてください。こう言うと馬鹿げているし当たり前のように聞こえるかもしれませんが、現実に再びつながることが重要です。

アプリケーションが本当にステートレスであれば、役に立たなくなる可能性が高くなります。

では、なぜ私たちは無国籍について話しているのでしょうか?アプリケーションの一部がステートレスであるためです。たとえば、ステートレス Node.js フロントエンドがステートフル PostgreSQL データベースにリクエストを送信しているとします。機能の観点から見ると、アプリケーション全体はかなりステートフルです。アプリケーションをステートレスとステートフルの 2 つの部分に分割したからといって、データを管理する必要がなくなるわけではありません。

はい、しかしデータベースは Kubernetes クラスターの外部にあり、スキーマは引き続き機能しますか?

データベースが Kubernetes クラスターの外部にある場合、GitOps アプローチに重大な影響を与えるいくつかの現実的な課題に直面することになります。詳しく見てみましょう。

他のコンポーネントと同様に、データベースを Kubernetes の一部として扱う必要があります。

共存の課題

データベースが Kubernetes クラスターの外部にある場合、コロケーションの課題に直面し、「ステートレス」アプローチが破綻します。確かに、データベースをワークロードからあまり遠くに配置することはできません。そうしないと、深刻なパフォーマンスの問題が発生します。

したがって、データベースと Kubernetes クラスターが同じネットワーク上にあるのには、十分な理由があります。今、インフラを破壊する災害が発生しています。 Kubernetes クラスターの再構築は他の場所では簡単です (完全にステートレスで GitOps であることに留意してください)。しかし、データベースはどうでしょうか?新しいデータベース マシンをインスタンス化し、ダンプを再適用する必要があります。これはあまりきれいではなく、あまり「GitOps」的ではありません。

だから何？データベースが起動すると GitOps の実践は停止しますか? DevOps とは開発と運用が懸念を共有することを意味しますが、このルールに違反していませんか?

移行の課題

災害によるものではないが、コストを節約するために別のプロバイダーに移行したい場合、Kubernetes の部分は簡単ですが、データベースの部分は依然として古い方法で管理されているためリスクがあります。移行によって節約できる費用と、データベースにかかるリスクを比較検討する必要があります。このアーキテクチャは選択の自由を本当に制限します。

テスト可能性の課題

開発者と QA チームは実際のデータを使用してアプリケーションをテストする必要があり、データベースのコピーを別のマシンまたはマシンのセットに作成し、テスト インスタンスが運用データベースを指すように構成されていないことを確認する必要があります。現在、開発チームと QA チームの数を増やしたい場合は、マシンの数を増やして構成を変更する必要があります。データベースがアプリケーションと同じ名前空間の Kubernetes で管理されている場合、この問題について考える必要すらありません。バックアップ ツールを使用すると、1 分以内にアプリケーションを別の場所に復元できます。

データベースとアプリケーションのバージョン不一致の課題

イメージ バージョンをデータベース スキーマ バージョンにマップする必要もあります。これは管理が簡単ではなく、開発者としてのキャリアの中で、データベース スキームとアプリケーション バージョン間の不一致を何度も目にしてきました。予期しないスキーマの変更やデータ変換によりデータが破損し、壊滅的な結果を招く可能性があります。

マイクロサービスの課題

開発チームは非常に機敏であり、マイクロサービス アーキテクチャへの進化を望んでいます。このアーキテクチャでは、多くの場合、異なる目的で複数のデータベースを構築する必要があります (たとえば、Elasticsearch、Redis、MongoDB、PostgreSQL はそれぞれ異なる機能を提供します)。ただし、データベースが古い方法で管理されている場合、この多様性を受け入れることは困難です。これまでに挙げたすべての課題は、データベースの数とデータベースの種類によって倍増します。アプリケーションが進化するにつれて、この変化に抵抗し、データベースを事実上のモノリスにすることでアプリケーションのモノリシックな性質を強化する可能性が高くなります。

データベースを Kubernetes に移行しないと、アプリケーションは進化するにつれてよりモノリシックになります。

コストの課題

Kubernetes にアプリケーションをデプロイすると、アプリケーションのコストが大幅に削減されます。しかし、これはデータベース部分には当てはまりません。 Kubernetes はコンピューティング リソースを最適化しますが、データベースはなぜ例外になるのでしょうか?

現場で観察したもの

これらすべての理由から、Kubernetes クラスター内でデータベースを配置する場所がますます一般的になりつつあります。これは私たちが現場で観察したものです。

最初のステップは、より安価で管理が容易な Kubernetes でのデータベースの展開を可能にするためのテストと開発でした。

その後、チームはそれが非常にうまく機能していることに気づき、Kubernetes の外部でデータベースを維持する意味がなくなったと感じました。異なる機能を持つ別のデータベースを使用したいのですが、DBA チームが同期するのを待つのに時間がかかりすぎることが多いため、独自のアプリケーション名前空間に新しいデータベースを作成するだけです。

すぐに、データベースの一部が Kubernetes の外部にあり、一部が Kubernetes の内部にあるという統合失調症モデルを維持していることに気付くでしょう。

最終的には、ほとんどのデータベースを Kubernetes 内に移行することは避けられません。

今、強力な Kubernetes バックアップ ツールが必要です...

すべてが GitOps です… 真実ではありません (ほとんどの場合)

理論的には、すべてがコードであり、すべてのレベルで「コードとして」の精神で自動化します。言い換えると、100% 宣言的になるように努めます。

例えば：

• Terraform コードを使用して、ネットワーク、クラウド サービス、Kubernetes クラスターなどを作成します。
• Argo CD を使用して、cert-manager、Istio などの主要な Kubernetes ツールをデプロイします。
• Tektonを使用してアプリケーションイメージを構築、テスト、プッシュします
• Helm Chartを使用してアプリケーションとその特定の構成をデプロイします。

これらはすべて素晴らしいことですが、もちろん私たちはこれらの実践の実施を承認することしかできません。しかし、現実は見た目ほど明るくはありません...

• これらすべてのチェーンツールを構築するには多大な労力が必要です。必ずしも人材が揃っているわけではない
• 場合によっては、1時間以内に修正プログラムが絶対に必要であり、チェーンツールではこの状況に対応できないことがあります。
• ツールチェーンは、あまりにも多くのコンポーネントを再デプロイするように設計されており、再デプロイを許可することはできません。特定のコンポーネントのみを再デプロイしたいので、手動で行います。
• 同じインフラストラクチャの複数のインスタンスを展開するように求められますが、一部のパラメータ化ではこれが考慮されておらず、ツールチェーン全体を再開発するか手動で変更するかのどちらかを選択することになります。
• 開発者による時折のバグ修正を除いて、アプリケーションは進化し​​なくなりました。ツールチェーンに再投資する必要はありません。開発者は、場合によっては数年にわたって手動で変更を適用します。
• 多くのツールチェーン (異なるチームによって管理されている) は単一のアプリケーションを対象としており、さまざまなツールチェーンのコードが進化するにつれて、特定の時点でのアプリケーションの正確な状態を再構築することは容易ではありません。

このリストは網羅的なものではなく、プロジェクトをじっくりと検討するたびに、さまざまなレベルですべてが「コードどおり」であるとは限らないことがわかります。この理論的プロセスを妨げる異常（時には大きな異常）が常に存在します。

結局のところ、真実の源は Kubernetes であり、それを適切にキャプチャできるツールが必要です。

GitOps は思ったよりも頻繁に壊れる

これらすべてのツールチェーン (Terraform、ArgoCD、Tekton など)、さらにはクラウド プロバイダーによって提供されるツールチェーン (Azure DevOps、GitHub Actions、CodeFresh、AWS など) は、マシン上で実行されるプログラムにすぎず、さまざまな理由で機能しなくなる可能性があります。また、単に人為的なエラーや依存関係が機能しなくなったことが原因で破損する可能性もあります。

たとえば、Docker イメージの脆弱性をスキャンするためのツールチェーンがあったことを覚えていますが、デプロイメント プロセスを続行するには、ツールがすべてのイメージをパスする必要がありました。残念ながら、このツールは一時的に中断され、別の理由 (災害は常に同時に発生することはご存じのとおりです) により、クラスターが中断され、アプリケーションを復元する必要がありました。当時は、セキュリティ スキャンを実行せずにツールチェーンを再構築する方法を誰も知りませんでした。アプリケーションは既にデプロイされているため、再度デプロイする場合は、この手順を実行する必要があります。

アプリケーションを回復できなかったため、チームはセキュリティ スキャンなしでツールチェーンを再構築する方法を誰かが見つけるまで待たなければなりませんでした。最終的に、 SLA要件は満たされませんでした。

チームは、ツールチェーンから独立してアプリケーションを再インストールできるバックアップ ツールに投資することを決定しました。

さらに、ハッカーは GIT リポジトリとツールチェーンの重要性を十分に認識しており、それらを侵害したり破壊したりする可能性があります。このような場合は、再利用する前に修正する必要があります。これは、回復時間の目標に重大な影響を及ぼす可能性があります。 GIT リポジトリを完全に失ってしまった場合、夜中に開発者の 1 人を起こして、ラップトップにマスター ブランチがまだ残っているかどうかを尋ねなければなりません。こんなことは一度も起こっていないと思うなら、もう一度考え直してください…

GitOps ツールチェーンは開発とデプロイメント用であり、バックアップ ツールではありません。

たとえば、Kasten には不変のバックアップがあり、悪意のある管理者であってもバックアップを破壊することはできません。 GIT とツールチェーンはこの目的のために設計されていません。覚えておいてください、ほとんどの攻撃は内部者による攻撃です。

オペレーターはゲームチェンジャー

Operator は、Kubernetes 上のデータベース専用のコントローラーです。現在、ほぼすべての主要データベース ベンダーが Operator のバージョンを提供しています。 Operator はデータベースの専門家の知識をカプセル化し、Kubernetes 上のデータベース管理を非常にシンプルかつサポートされたものにします。

オペレーターがスケールアップまたはスケールダウンをお手伝いします。カスタム リソースのフィールド (レプリカの数など) を変更するだけで、Operator はサービスを中断することなく、目的の状態を満たすための複雑な操作をすべて実行します。

Operator を使用すれば、データベースを Kubernetes に移行しない理由はありません (ベンダーを信頼している場合) 。ただし、注意すべき点の 1 つは、Operator が Kubernetes に多くの変更 (シークレット、証明書、PVC など) を加えるため、これまで以上に Operator API で動作するバックアップ ツールが必要であるということです。 Kasten の Kanister ベースの拡張メカニズムにより、Operator API とバックアップ操作間の調整が非常に簡単になります。

Kasten は GitOps の実践を否定しているわけではありません。むしろその逆です。

このトピックを要約する目的は、GitOps プラクティスによってもたらされる価値を否定することではありません。 Kasten では、2 週間ごとにデプロイを行い、多くの自動デプロイと自動テストを実行しています。 DevOps (GitOps を含む) プラクティスを採用しなければ、これらはすべて不可能でした。

この Tekton デモでは、新しいバージョンをデプロイする前にアプリケーションのスナップショットをキャプチャするための Kasten バックアップ操作を組み込む方法も示しました。同じことを実行しますが、Azure DevOps タスクを使用する Azure DevOps サンプルもあります。そのため、Kasten は GitOps プラクティスと非常にうまく連携します。

しかし、GitOps を導入した今、Kubernetes にバックアップ ツールは必要ないと考えているなら、それは間違いです。

主な結論

• 依然として、Kubernetes 以外の何物でもない、究極の真実のソースをキャプチャする必要があります。
• アプリケーションとデータ管理の運用が容易になり、コストが削減されるため、データベースは最終的に Kubernetes に移行されます。つまり、アプリケーション スタックの残りの部分と一緒にバックアップすることになります。
• すべてが一度に故障した場合、開発リソースに依存しない別の場所ですぐに再構築するためのプラン B が必要になります。