プログラマーの精神修養への道 - Kubernetesはマイクロサービス開発の必然的な産物

[[283629]]

[[283630]]

Kubernetes入門

開発の初期段階では、多くのプロジェクトは小規模または大規模な単一プロジェクトであり、単一または複数のサーバーに展開され、単一のプロセスとして実行されます。これらのプロジェクトの需要が増加するにつれて、リリース サイクルは徐々に長くなり、反復速度は大幅に低下します。従来のリリース方法では、開発者がプロ​​ジェクトをパッケージ化して運用および保守担当者に送信し、担当者が展開やリソースの割り当てなどの操作を実行します。

ソフトウェア業界のアーキテクチャアプローチが変化するにつれて、これらの大規模なモノリシックアプリケーションは、ビジネスやその他の次元に基づいて独立して実行されるコンポーネントに徐々に分解され、これをマイクロサービスと呼びます。マイクロサービスは互いに独立して開発、展開、アップグレード、拡張され、大規模なアプリケーションの分離を真に実現します。

ソフトウェア開発業界はとても奇妙です。それぞれの問題が解決すると、必ず別の問題が現れます。プログラマーがバグを修正するとき、なぜ修正すべきバグがいつまでも尽きないのでしょうか?本当に頭が痛いです！！！

[[283632]]

マイクロサービスによっていくつかの問題は解決されましたが、マイクロサービスの数が増えるにつれて、構成、管理、容量拡張、高可用性などの要件を実装することがますます困難になります。これには、運用および保守チームがハードウェア リソースをより有効に活用してサーバー コストを削減する方法や、展開の自動化と障害処理がますます困難になる可能性がある方法などが含まれます。

上記の問題こそが、Kubernetes が解決することを目指し、優れている点です。Kubernetes により、開発者はアプリケーションを独立してデプロイし、反復の頻度を独立して制御し、運用および保守チームを完全に解放できます。運用保守チームの重点は、これまでのサーバーリソース管理から Kubernetes リソース管理に移行しました。 Kubernetes の最も強力な点は、ハードウェア インフラストラクチャをカプセル化して抽象化することで、開発者がハードウェアの基本原理を理解したり、基盤となるサーバーに注意を払ったりする必要がないことです。 Kubernetes は構成されたサーバーをリソース プールとして抽象化します。アプリケーションを展開すると、適切かつ合理的なサーバー リソースがアプリケーションに自動的に割り当てられ、これらのアプリケーションが他のアプリケーションと正常に通信できるようになります。 Kubernetes クラスターの一般的な構造は次のとおりです。

[[283634]]

Kubernetesの利点

マイクロサービスは良いのですが、数が多すぎると量による問題が発生します。システム コンポーネントの数が増え続けると、これらのコンポーネントの管理が徐々に問題になります。まず、Kubernetes は Linux コンテナの特性を利用してコンポーネントを管理するソフトウェア システムであることを理解する必要があります (Kubernetes とコンテナは同じ概念ではないので、混同しないでください)。 Kubernetes を介してアプリケーションをデプロイする場合、クラスターに含まれるノードの数に関係なく、Kubernetes には違いはありません。これは完全に基盤となるインフラストラクチャの抽象化によるもので、実行時には複数のノードが 1 つのノードのように動作します。

自動拡張[[283631]]

Kubernetes システムでは、各アプリケーションをリアルタイムで監視し、戦略に従って突発的なトラフィックに対応できます。たとえば、トラフィックのピーク時に、Kubernetes は各ノードのリソース使用率に基づいてノードを自動的に追加または削減できますが、これは従来のアプリケーション展開方法では簡単には実行できません。

導入プロセスを簡素化する[[283631]]

従来、従来のアプリケーションがリリースされる際、開発者はプロジェクトをパッケージ化し、プロジェクト構成ファイルが正しいかどうかを確認し、運用および保守担当者に送信する必要がありました。その後、運用保守担当者はオンライン アプリケーション バージョンをバックアップし、更新のためにサービスを停止しました。 Kubernetes では、ほとんどの場合、アプリケーションを最新バージョンにアップグレードするには 1 つの指示またはボタンのクリックのみが必要であり、アップグレード プロセス中に中断のないサービスを保証できます。もちろん、プロセス全体にはコンテナ操作も含まれますが、ここでは詳細には説明しません。

しかし、ここで予想外の事態が起こります。 Kubernetes クラスター内に異なる CPU アーキテクチャを持つサーバーが存在し、アプリケーションが特定の CPU アーキテクチャ用のソフトウェアである場合、アプリケーションを実行するには Kubernetes でノードを指定する必要がある場合があります。

サーバーリソースの利用率を向上させる[[283631]]

従来のアプリケーションを導入する場合、ほとんどの場合、トラフィックのピークに対処するために、一定の割合のリソースがリソース バッファーとして常に予約されます。単一サーバーのリソース使用率を 90% 以上に上げる人はほとんどいません。サーバー障害の確率に関して言えば、サーバー リソースの使用率が 90% であれば 50% よりもはるかに高くなります。さらに、サーバーに障害が発生すると、問題を解決し、責任を負うのは運用および保守担当者になります。したがって、物理マシンまたは仮想マシンにアプリケーションを展開する従来の方法では、ハードウェア リソースの使用率が比較的低くなります。

Kubernetes のクラスター管理では、基盤となるハードウェア機能を抽象化することで、アプリケーションとインフラストラクチャを分離しています。 Kubernetes にアプリケーションを実行するように指示すると、プログラムのリソース要件とクラスター内の各ノードの使用可能なリソースに基づいて、アプリケーションを実行する適切なノードが選択されます。また、コンテナ テクノロジーにより、アプリケーションをいつでもクラスター内の任意のマシンに移行できます。サーバー選択の最適な組み合わせに関しては、Kubernetes は人間よりも優れた仕事をします。クラスター内の各サーバーの負荷に基づいてハードウェアの使用率を最大化します。

自動修復[[283631]]

従来のアプリケーション アーキテクチャでは、サーバーに障害が発生すると、そのサーバー上のすべてのアプリケーションが停止し、ほとんどの場合、運用および保守担当者が対処する必要があります。これは、運用および保守担当者が 24 時間 365 日待機する必要がある重要な理由でもあります。夜中に故障が起きたために保守担当者が悪態をついているのを見たことがあると思います。 Kubernetes では、すべてのノードとアプリケーションを監視および管理します。ノードに障害が発生すると、Kubernetes はノード上のアプリケーションを他の正常なノードに自動的に移行し、障害が発生したノードをリソース プールから除外できます。 Kubernetes クラスター インフラストラクチャにシステムの通常の操作をサポートするのに十分な予備リソースがある場合、運用および保守担当者はトラブルシューティングを通常の勤務時間まで完全に延期することができ、プログラマーと運用および保守担当者は 965 の作業リズムを得ることができます。 [[283635]]

これは、崩壊させるという原則を主張するアクター モデルの設計理論に少し似ています。

一貫した運用環境[[283631]]

開発者であっても運用スタッフであっても、従来のデプロイメント ソリューションでは、動作環境の違いによって常に悩まされることになります。こうした違いは、各サーバー間の違いから、開発環境、シミュレーション環境、本番環境まで多岐にわたります。さらに、各環境のサーバーは時間の経過とともに変化します。開発環境ではプログラムが正常に動作しているのに、本番環境では異常が発生する、という状況に遭遇したことがあるかと思います。この違いは、運用環境が運用保守チームによって管理され、開発環境が開発者によって管理されるという理由だけでなく、さらに重要なのは、これら 2 つのグループの人々がシステムに対して異なる要件を持っていることです。運用保守チームは、オンライン本番環境に定期的にパッチを適用し、セキュリティ監視などの操作を実行しますが、開発者はこれらの問題について心配する必要すらない場合があります。さらに、アプリケーション システムが依存するサードパーティ ライブラリは、開発環境、シミュレーション環境、および運用環境でバージョンが異なる場合があります。私もそのような問題に遭遇しました。

Kubernetes が使用するコンテナ技術は、アプリケーションと動作環境をパッケージにまとめることで、同じバージョンのコンテナ パッケージ (イメージ) であればどのサーバーでも同じ動作環境が確保されます。

Kubernetes では、開発者がコンテナ技術とネットワークの知識について一定の理解を持っていることが求められるため、チームの総合的なスキルとプロジェクトに基づいて Kubernetes を採用するかどうかを検討する必要があります。すべてのプロジェクトが Kubernetes を採用することで利益を得られるわけではありません。