なぜ誰もが Kubernetes を使いたがるのでしょうか?

正直に言うと、私は Kubernetes の愛好家です。 Kubernetes はソフトウェア開発分野における大きな前進と言えます。 Kubernetes について知ったとき、これが本番環境でコンテナを使用する正しい方法だと思いました。私はためらうことなくKubernetesを採用しました。私のようにこの技術をうまく取り入れている建築家は何千人もいます。

まず、Kubernetes がクラウドにアプリケーションをデプロイする際に発生するほとんどの問題をどのように解決し、インフラストラクチャのクラウドへの移行をどのようにサポートするかを理解しましょう。

[[315634]]

目標を念頭に置いて

クラウド コンピューティングの時代では、すべての企業が共通の目標を持っています。

一般的に、次の目標は優先度が高くなります。

• できるだけ早くクラウドに移行する（クラウド移行）
• システム管理コスト、インフラコスト、人件費の削減（コスト削減）
• プロジェクトの完了に必要な時間を短縮する（市場投入までの時間を短縮）
• 高いシステム性能と高可用性（品質向上）
• これらの目標を念頭に置いて、クラウドに移行し、次のステップについて考えることができます。

なぜコンテナが必要なのでしょうか?

Kubernetes が必要な理由を考える前に、なぜコンテナが必要なのか自問する必要があります。コンテナは、実稼働環境を各開発者のローカル環境に持ち込み、Linux と Windows 間の互換性の問題を心配する必要がなくなるため、ソフトウェア開発の歴史において大きな変化をもたらします。コンテナを使用することで、どのワークステーションでも問題を簡単に再現できます。さらに、他の不要な操作を行わずに、コンテナを任意のプラットフォームに簡単に移行できます。コンテナが登場する前は、開発者は、依存コンポーネントをアプリケーションにパッケージ化するなど、アプリケーションを正常に実行する方法を知っていたため、配布用にアプリケーションをパッケージ化する方法を理解していました。 DevOps の観点から見ると、コンテナは非常にエレガントです。各リリース システムはコンテナという 1 つのものだけを処理すればよいからです。それだけでなく、すべてのコンテナ構築プロセスは開発者が Dockerfile を通じて記述できるため、ローカル開発環境でも継続的インテグレーション環境でも、同じ方法を使用してアプリケーションを構築できます。

コンテナを使用するとメンテナンスが少なくなり、シールドされた環境の詳細が区別されなくなるため、エラーが少なくなります。

コンテナイメージをレジストリにプッシュできます。レジストリを使用すると、ラップトップ、仮想マシン (ローカルまたはクラウド)、さらには Heroku などのサーバーレス シナリオなど、どこにでもダウンロードしてデプロイできます。仮想マシンと比較した場合、コンテナの本当の利点は、外部リソースではなくオペレーティング システムを仮想化することです。この高いレベルの抽象化により、より軽量でシンプル、かつ経済的な方法でアプリケーションを展開できるようになります。

なぜKubernetesが必要なのでしょうか?

前のセクションでは、誰もがコンテナを使用する理由について説明しましたが、Kubernetes が必要な理由については触れませんでした。いずれにせよ、私たちはコンテナの概念を受け入れるようになりました。これにより、コンテナをどのように管理するかという新たな要件が生じます。コンテナを確実にオーケストレーションするにはどうすればよいでしょうか?私たちの答えは Kubernetes です!

Kubernetes を使用する場合、必要なのはイメージをレジストリにプッシュし、Kubernetes が残りの処理を実行するのを待つことだけです。すべてのデプロイメントタスクは Kubernetes によって管理されるため、インフラストラクチャについてまったく心配する必要はありません。

Kubernetes は、業界をリードするコンテナ オーケストレーション ソリューションです。これは、Google のコンテナの実践の中で徐々に開発および改善され、オープンソースでもあります。そのアーキテクチャにより、コンテナ オーケストレーションが可能になり、レガシー システムとの統合も可能になります。つまり、Kubernetes をローカルまたはクラウドにインストールして使用することができ、ハイブリッド クラウド アーキテクチャを使用することもできます。

そのため、安定性、信頼性、使いやすさから Kubernetes を使用しています。簡単に言えば、Kubernetes はコンテナをデプロイする最良の方法です。

Kubernetes はサーバーレスですか?

Kubernetes はサーバーレスですか? Kubernetes と Serverless は異なる分野の言葉だと思います。サーバーレスは哲学に近いものですが、Kubernetes は特定のツールです。当初の目標を振り返ってみましょう。オペレーティング システムへの依存を減らし、その維持コストを削減する必要があると述べましたが、これがサーバーレスです。

すると疑問になるのは、Kubernetes を使用するとこの目標を達成できるかどうかです。簡単に答えると、イエスです。

サーバーレスの厳密な定義は、どのアプリケーション コンテナー、どのシステム、またはどのハードウェアがコードを実行しているかを気にする必要がなく、それが世界のどこにあるかさえ知らないということです。 Kubernetes は開発者から多くの複雑さを隠していますが、サーバーの関連部分を理解する必要があります。たとえば、特定のコンテナーによって提供されるオペレーティング システムに依然として依存しています。同時に、Kubernetes の特定のバージョンにも依存します。つまり、理論上、Kubernetes はサーバーレスではありません。

次に、いくつかのサーバーレス ソリューションを見てみましょう。

Heroku Runtime[1]の基盤となるレイヤーはコンテナに依存しています。もちろん、独自のコンテナをHeroku[2]に直接デプロイすることもできます。ほとんどの Lambda 関数はコンテナ内で実行されます。

Kubernetes はコンテナベースであり、オペレーティング システムにも依存するため、サーバーレスではなくクラウドにデプロイされる Kubernetes を検討しているのはこのためです。ただし、コンテナにも依存する Heroku Runtime または Lambda コンピューティング サービスは、サーバーレスと見なされます。

したがって、厳密な定義を満たしていなくても、Kubernetes は依然としてサーバーレス ソリューションであると私は考えています。世界は白か黒かではなく、Kubernetes のクラウド バージョンが提供する抽象化のレベル (オペレーティング システムや基礎となるリソースの保護など) は私にとって十分です。

ここで言い争いをするつもりはありません。 Kubernetes をサーバーレスと呼ぶべきかどうかという問題はさておき、Kubernetes を使用するとクラウドへの迅速な移行が可能になり、システム管理コストやインフラストラクチャ保守コストを削減し、ビジネス品質を向上させる強力なツールになります。したがって、実際にはそれらのラベルを気にする必要はありません。猫が黒くても白くても、ネズミを捕まえることができれば、それは良い猫です。

Kubernetesの利点

Kubernetes は、従来の仮想マシンのユニフォームを脱ぎ捨て、クラウドを採用することを可能にする優れたプラットフォームです。 Kubernetes は、活力をもたらし、システム管理コストを削減し、Kubernetes の誕生前には達成が困難だったサービス品質を新たなレベルに押し上げます。ネットワークやデータ保護などの従来の問題の多くは、Kubernetes の高度な構成によって解決できます。

Kubernetes がもたらす利点は次のとおりです。

• スケーラビリティ: コンテナを 1 つだけ展開すれば、障害なく拡張戦略を設定できます。次に、アカウントに十分な残高があることを確認する必要があります。
• 透明性: 各コンテナは 1 つのタスクのみを実行します。コンテナ間の関係は構成ファイルにマッピングされるため、何かが欠けていることを心配する必要はありませんが、もちろん詳細を隠すことはできません。
• 時間を節約: プロセスは非常に簡単で、すべての手順を繰り返すことができます。
• バージョン管理: 設計上、すべてのデプロイメントはバージョン管理されます。もちろん、少し時間をかければ、Git で設定ファイルを管理することもできます。

他の方法と比較して、Kubernetes は開発と運用に関するすべての事項を簡素化し、開発者に運用とメンテナンスがほとんど必要ない理想的な状態をもたらします。開発チームと運用保守チームの間で、もともとあいまいだった責任範囲が明確に定義され、システム自体の透明性が高まったため、両者間の摩擦も軽減されました。

その他の利点は以下のとおりです。

• 水平拡張: Kubernetes 自体は自動的に拡張でき、クラスター内のノードの追加や利用可能な物理リソースの調整をサポートします。同時に、サービスの Pod の数を調整するなど、論理リソースを拡張することもできます。
• スマートなアップグレード: コンテナ イメージをアップグレードするたびに、アップグレード プロセスがスムーズになります。古い Pod は、新しい Pod が起動されて破棄されるまで、引き続き使用できます。これは、ゼロ ダウンタイム デプロイメントと呼ばれるものです。
• ローカル構築またはクラウド サービスのサポート: クラウドを使用する以外にオプションはありますか?もちろん！私は常に完全にクラウドベースのソリューションを好みます。もちろん、シナリオによっては、ローカル環境やコンピュータ ルームに展開する必要がある場合もありますが、Kubernetes はそれを完全にサポートできます。
• ベンダーロックインを回避: Kubernetesは、すべての認定パブリッククラウドプラットフォームで一貫性があります[3]。サービスプロバイダーに満足できない場合は、最小限の労力でベンダーを切り替えることができます。
• 開発者に追加コストはかかりません。コンテナ化されたソフトウェアはすべてワンクリックでデプロイできます。開発チームは追加の知識を習得する必要はありません。

どうやって選ぶのでしょうか?

Kubernetes は非常に柔軟性が高く、クラウド ソリューションを使用して Kubernetes クラスターを簡単に管理できます。 Kubernetes について知ったとき、これは開発者の負担を効果的に軽減できる、実現可能で安全なソリューションだと思いました。従来のインフラストラクチャの利点をすべて備えながら、アプリケーションをリファクタリングせずに運用やメンテナンスが不要になる利便性も享受できます。他の多くの一見魅力的なソリューション (Serverless など) と比較すると、Kubernetes はより実用的です。サーバーレスは確かに非常に優れていますが、多くの複雑なシナリオを簡単に処理することはできません。そして論理的に言えば、Lambda のような最先端のテクノロジーを全面的に採用するには、考え方を大きく変える必要があります。このような変更は、運用保守チームにとって容易なことではありません。

今日では、システム管理の作業負荷を軽減し、導入が容易で、運用と保守の中心的な問題点を簡素化できるインフラストラクチャを備えることが、ほとんどのチームにとっての中心的な要件となっています。 Kubernetes はこれらすべての要件を満たしています。

今、アーキテクチャ、特にエンタープライズ向けのソリューションを設計するように求められたら、コンテナ テクノロジーと Kubernetes を選択します。運用・保守コストを削減するために、クラウドサービスプロバイダーが提供する Kubernetes を選択するかもしれません。 DevOps パイプラインに関連する構成を管理するために Git を使用する場合もあります。

このソリューションは、オペレーティング システムやクラウド ベンダーにほとんど依存しません。すべてのインフラストラクチャとその構成はコードに依存します。

このソリューションでは、運用と保守が完全に不要になるわけではなく、サーバーも完全に不要になるわけでもないと言う人もいるかもしれません。しかし、Kubernetes は安定しており、モジュール化され、スケーラブルであり、最も重要なアーキテクチャ設計目標を満たすことができます。では、Kubernetes を使用しないのはなぜでしょうか?

それで、もっと良いことができるでしょうか?間違いない。もっと負担を減らす努力をすることはできるでしょうか？もちろんできますよ。私たちは確かにさらに先へ進むことができます。しかし、私たちは星に目を向け、地に足をつけていなければなりません。 Kubernetes は優れた妥協案であることを認めなければなりません。ほとんどの場合、Kubernetes は成功を保証します。