コンテナとKubernetesがあらゆるものを実行できる可能性を秘めている理由

[[281973]]

「Kubernetes がダンプ トラックである理由」では、ダンプ トラックがゴミを移動するのに適しているのと同様に、Kubernetes がアプリケーションの定義、共有、実行に適していることを説明しました。 Kubernetes の学習曲線を克服する方法では、Kubernetes の学習曲線は実際には実稼働環境でアプリケーションを実行するための学習曲線と同じであり、従来のコンポーネント (ロード バランサー、ルーター、ファイアウォール、スイッチ、クラスタリング ソフトウェア、クラスター ファイル システムなど) をすべて学習するよりも簡単であると説明しました。これは DevOps であり、開発者と運用担当者が協力して本番環境での実行方法を指定するものであり、双方に学習があることを意味します。

「まず使い方を学ぶ」では、Kubernetes の学習プロセスを再構成し、ダンプ トラックの構築や装備ではなく、ダンプ トラックの運転に重点を置きました。 4 番目の記事「Kubernetes の運用に役立つ 4 つのツール」では、Kubernetes でアプリケーションを構築する (ダンプ トラックを運転する) のに役立つお気に入りのツールを紹介しました。

この最後の投稿では、Kubernetes 上でアプリケーションを実行することの将来に私がなぜそれほど期待しているのかをお話しします。

Kubernetes は当初から、Web ベースのワークロード (コンテナ化) を非常にうまく実行できました。 Web サーバー、Java、関連アプリケーション サーバー (PHP、Python など) などのワークロードはすべて正常に動作します。プラットフォームは、DNS、負荷分散、SSH (kubectl exec に置き換えられました) などのサポート サービスを処理します。

これらは私がこれまでのキャリアのほとんどで本番環境で実行してきたワークロードだったので、DevOps や Agile に加えて Kubernetes を使用して本番環境のワークロードを実行することの威力をすぐに認識しました。たとえ文化的な習慣をほとんど変えなくても、効率を向上させることは可能です。従来の IT では非常に困難だったデバッグと廃止が非常に簡単になります。そのため、Kubernetes は初期の頃から、単一の構成言語 (Kube YAML/Json) で本番ワークロードをモデル化するために必要なすべての基本的なプリミティブを提供してくれました。

しかし、レプリケーションを使用してマルチマスター MySQL を実行する必要がある場合はどうなるでしょうか? Galera を使用した冗長データについてはどうでしょうか?スナップショットとバックアップはどのように行いますか? SAP のように複雑なものの場合はどうでしょうか? Kubernetes では、単純なアプリケーション (Web サーバーなど) の Day 0 (デプロイメント) は非常に簡単ですが、Day 2 の運用とワークロードには対処されていません。複雑なワークロードを伴う Day 2 運用の対応が従来の IT よりも難しいというわけではありませんが、Kubernetes を使用しても簡単になるわけではありません。これらの問題を解決するには、各ユーザーが独自の天才的なアイデアを考案する必要があります。これが基本的に現在の状況です。過去 5 年間で私が遭遇した最も大きな問題は、複雑なワークロードの Day 2 運用でした。 (LCTT 翻訳注: ソフトウェア ライフサイクルでは、Day 0 はソフトウェア設計フェーズ、Day 1 はソフトウェア開発および展開フェーズ、Day 2 は運用環境でのソフトウェア運用および保守フェーズを指します。)

ありがたいことに、Kubernetes Operators の登場により、この状況は変わりつつあります。 Operator の登場により、Day 2 の運用知識をプラットフォームに集約するフレームワークが実現しました。これで、「Kubernetes の基礎: まず学習方法」で説明したのと同じ定義済み状態、実際の状態のアプローチを適用できるようになり、さまざまなシステム管理タスクを定義、自動化、および維持できるようになりました。

私はよくオペレーターを「システム管理者ロボット」と呼んでいます。なぜなら、オペレーターは基本的に、2 日目の仕事で、主題専門家 (SME、例: DBA または SysAdmin) が対象とするワークロードの種類 (データベース、Web サーバーなど) に関連する一連の運用知識をキュレートしており、通常は wiki のどこかに文書化されているからです。この知識をウィキに入れることの問題点は、その知識を問題解決に適用するために、次のことが必要になることです。

イベントを生成すると、通常は監視システムが障害を発見し、トラブルチケットを作成します。

中小企業は、これまで何百万回も見てきた問題であるにもかかわらず、この問題を調査する必要がある。

SME 担当者は、この知識を実装する必要があります (バックアップ/復元の実行、Galera またはトランザクション レプリケーションの構成など)。

オペレーターを使用すると、このすべての SME の知識を、実際のワークロードの前に展開される単一のコンテナ イメージに埋め込むことができます。オペレーター コンテナをデプロイし、オペレーターが 1 つ以上のワークロード インスタンスをデプロイして管理します。次に、Operator Lifecycle Manager (Katacoda チュートリアル) などを使用して Operator を管理します。

したがって、Kubernetes をさらに活用していくと、アプリケーションの展開だけでなく、そのライフサイクル全体の管理も簡素化されます。オペレーターは、詳細な構成要件 (クラスタリング、レプリケーション、修復、バックアップ/復元) を備えた非常に複雑なステートフル アプリケーションを管理するためのツールも提供します。そして最も良い点は、コンテナを構築した人々は Day 2 運用を行う専門家である可能性が高いため、その知識を運用環境に組み込むことができることです。

このシリーズの要約

Kubernetes の将来は明るく、これまでの仮想化と同様に、ワークロードのスケーリングは避けられません。 Kubernetes の操作方法を学ぶことは、おそらく開発者やシステム管理者がキャリア開発において行うことができる最大の投資です。仕事量が増えるにつれて、キャリアのチャンスも増えます。ゴミを運ぶのにとても優雅な、素晴らしいダンプトラックを運転しましょう…

Twitter で私をフォローしてください。@fatherlinux でこのトピックについて多くのことを共有しています。