初心者のための Kubernetes の基礎: アーキテクチャとコンポーネント

複雑なアプリケーションを高可用性、スケーラビリティ、移植性を備え、小さなモジュールで独立してデプロイできるようにするという切迫したニーズから、Kubernetes が誕生しました。

今日は以下の内容を取り上げます:

• Kubernetes とは何ですか?
• なぜKubernetesなのか?
• Kubernetes アーキテクチャ
• Kubernetes の主要コンポーネント

[[395780]]

Kubernetes とは何ですか?

Kubernetes は一般に K8s として知られています。

K8s は、Google が開発した本番環境レベルのオープンソース コンテナ オーケストレーション ツールであり、ローカル、クラウド、仮想マシンなどの複数のデプロイメント環境をサポートするコンテナ化/Docker 化されたアプリケーションの管理に役立ちます。

K8s はコンテナ化されたイメージの展開を自動化し、水平方向に拡張して高いレベルのアプリケーション可用性をサポートします。

K8sを選ぶ理由

K8S はどのような問題を解決しますか?

K8s がこれほど普及した主な理由の 1 つは、マイクロサービス主導のアーキテクチャのニーズをサポートしたいという企業からの需要が高まっていることです。

マイクロサービス アーキテクチャは企業にとって次の点で役立ちます。

• 複雑なアプリケーションを小さくスケーラブルなモジュールに分割して独立して開発および展開する
• 複数の小規模チームで単一のアプリケーションモジュールをサポートし、必要なスピードと俊敏性で開発および展開できるように支援します。

従来のモノリシック サービスからマイクロサービスに移行したいという企業の要望により、大規模なコンテナ化されたアプリケーションが作成されるようになりました。各コンテナ イメージはそれ自体がマイクロサービスであり、オーバーヘッドを抑えて効率的に管理および拡張する必要があります。何千ものコンテナを処理するという要件は、組織にとって面倒な作業です。この問題により、K8s は人気のコンテナ オーケストレーション ツールの 1 つに進化しました。

組織は Kubernetes などのコンテナ オーケストレーション ツールを採用し、次のような主なメリットを得ました。

K8s はどのような機能を提供しますか?

• ダウンタイムなしで高可用性を確保
• 高いパフォーマンスと拡張性
• データ復旧を容易にサポートする信頼性の高いインフラストラクチャ

K8sを使用する理由がわかったので、次はK8sの基盤となるアーキテクチャを解読しましょう。

Kubernetes クラスターの基本的なアーキテクチャ:

Kubernetes クラスターの最も基本的なアーキテクチャには、次の 2 つのメインノードがあります。

• マスターノード
• セカンダリノードまたはスレーブノード

Kubernetes の公式ドキュメントに従うと、その概念を理解するのは非常に困難になります。したがって、必要な単純化を加えて同じことを理解しようとします。

まず、K8sのワーカーノードまたはスレーブノードがどのように機能するか、そしてワーカーノードの主要コンポーネントは何かを理解しましょう。

K8s クラスター内の作業ノード:

図 2.0: K8s クラスターのワーカーノードコンポーネント

開発者または K8s 管理者は、コンテナ化されたアプリケーションをデプロイして自動スケーリングする必要がある場合でも、実稼働グレードのサーバーで新しいアプリケーションの更新を展開する必要がある場合でも、ほとんどの場合、ワーカー ノードを扱うことになります。

このノードは、クラスター管理者または開発者が必要とする実際の作業を実行するため、ワーカー ノードと呼ばれます。ワーカー ノードには、コンテナー化されたアプリケーションを抽象化した 1 つ以上のポッドを含めることができます。図 2.0 に示すように、各ワーカーは次の 3 つの主要なプロセスを実行します。

• コンテナランタイム
• クベレット
• Kube プロキシ

コンテナランタイム:

デプロイする各マイクロサービス モジュール (マイクロ アプリ) は、独自のコンテナー ランタイムを持つ個別のコンテナーにパッケージ化されます。ポッドがクラスター内で実行できるように、コンテナー ランタイムをクラスター内の各ワーカー ノードにインストールする必要があります。

コンテナ ランタイムの例をいくつか示します。

• コンテナ
• クリオー
• ドッカー

クベレット:

kubelet はワーカーノードのメインノードエージェントであり、特定のワーカーノード内のノードおよびコンテナと対話します。

kubelet は次のことを行います。

• 1 つ以上のコンテナで構成される Pod のセットがローカル システム上で維持されます。
• Kubernetes クラスターにノードを登録し、イベントと Pod ステータスを送信し、リソース使用率を報告するために使用されます。

Kubernetes クラスターでは、kubelet は Kubernetes API サーバーを通じて PodSpecs を監視します。

PodSpec は、Pod を記述する YAML または JSON オブジェクトです。 kubelet は、さまざまなメカニズム (主に API サーバー経由) によって提供される一連の PodSpec を受け取り、それらの PodSpec で記述されているコンテナーが実行され、正常であることを確認します。

Kube プロキシ:

K8 クラスターには複数のワーカー ノードを含めることができ、各ノードでは複数のポッドが実行されているため、このポッドにアクセスする必要がある場合は、Kube-proxy を介してアクセスできます。

k8s サービスを通じて Pod にアクセスするために、クラスター内外のネットワーク セッションから Pod へのネットワーク通信を許可するネットワーク ポリシーがあります。これらのルールはkube-proxyによって処理されます

kube-proxy には、Pod アクセスに必要なネットワーク トラフィックを転送するインテリジェントなアルゴリズムがあり、オーバーヘッドを最小限に抑えてサービス通信をより効率的にします。

これまで、コンテナ化されたアプリケーションを効果的に管理するためには、これら3つのプロセスがワーカーノードに正常にインストールされ、実行されている必要があることを見てきましたが、より大きな問題は

• これらのワーカーノードが常に実行されていることを確認するために誰が管理するのでしょうか?
• K8s クラスターは、どの Pod をスケジュールする必要があるか、どの Pod を破棄または再起動する必要があるかをどのように認識するのでしょうか?
• k8s クラスターは、各コンテナ アプリケーションのリソース レベル要件をどのように認識するのでしょうか?

その答えは「マスターノード」という概念にあります。これについては以下で説明します。

K8s クラスターのマスターノード:

図: 3.0 K8 のマスターノードプロセス

マスター ノードはコントロール プレーンとも呼ばれ、ワーカー/スレーブ ノードを効率的に管理する役割を担います。ワーカーノードと対話して

• ポッドのスケジュール
• ワーカーノード/ポッドの監視
• ポッドの起動/再起動
• クラスターに参加する新しいワーカーノードの管理

マスターノードプロセス:

K8s クラスター内の各マスターノードは、次の主要なプロセスを実行します。

• kube-apiサーバー
• kubectl:kube-コントローラーマネージャー
• Kube スケジューラ
• など

それぞれのプロセスを詳しく見てみましょう。

kube-apiserver:

これは、k8s クラスターにアクセスするためのメインゲートウェイであり、クライアントレベルの認証のメインゲートキーパーとして機能します。つまり、kube-apiserver は Kubernetes コントロールプレーンのフロントエンドであると言えます。

したがって、次のことが必要な場合:

• 新しいアプリケーションを展開する
• ポッドをスケジュールするか、
• 新しいサービスを作成する
• ワーカーノードのステータスまたは健全性を照会する

マスター ノードの API サーバーにリクエストを送信し、ワーカー ノードのプロセスにアクセスする前にリクエストを認証する必要があります。

K8s マスターノードの kube-scheduler:

K8s 管理者/開発者として、ワーカー ノードで新しいポッドをスケジュールする場合は、マスター API サーバーにリクエストを送信して、Kube スケジューラ プロセスを呼び出します。ここでのスケジューラは、このポッドを配置するワーカーノードをインテリジェントに決定します。

したがって、kube-scheduler を次のように定義できます。

これにより、各ノードのリソース レベルの可用性に基づいて、新しく作成された Pod をどのワーカー ノードに配置するかが決定されます。スケジューラはリソース レベルのクエリを実行し、重要なスケジュール決定を行います。

スケジューラ レベルの決定の実際の実行は、特定のワーカー ノード内の kubelet プロセスによって行われます。

Pod のスケジュール設定の主な決定要因は次のとおりです。

• 個人および集団のリソース要件
• ハードウェア/ソフトウェア/ポリシーの制約
• ノードアフィニティとアンチアフィニティの仕様、
• データの局所性、ワークロード間の干渉、および期限。

k8s については後ほど詳しく説明し、上記の制限とポリシーについて学習します。

kube-controller-manager (Kubectl):

これは、ワーカー ノード レベルの障害ステータスを監視するマスター ノード内の重要なプロセスの 1 つです。このような出来事を注意深く見守るだろう

ワーカーノード内のいずれかのポッドのクラッシュ

そして、そのようなイベントを検出すると、スケジューラに、デッド/障害が発生したポッドを再起動または再スケジュールするように要求します。

• マスター コントロール プランナーのこれらのコントロール マネージャー コンポーネントには、次のタイプのコントローラーがあります。
• ノードコントローラ: ワーカーノードに障害が発生したときに応答する役割を担う
• レプリケーションコントローラ: ポッド展開のレプリカの正しい数が常に維持されるようにします。
• エンドポイント コントローラー: エンドポイント オブジェクトを設定します。デプロイメント、サービス、ポッド
• サービス アカウントとトークン コントローラー: ワーカー ノードに作成された新しい名前空間のデフォルトのアカウントと API アクセス トークンを作成します。

K8s マスターノードの etcd:

マスター コントロール プレーンの etcd は、さまざまなクラスター レベルの変更をキーと値のペアの形式で保存する役割を担います。

これは、クラスター内で発生する変更の詳細をすべて記録する、k8s クラスターの頭脳として簡単に考えることができます。

たとえば、ワーカーノードで Pod がクラッシュして再スケジュールする必要がある場合、それはキーと値のペアとして etcd に保存され、ノードでの Pod の再スケジュールのイベントもここに記録されます。

したがって、データは次のような重要な質問に関連しています。

• ノードではどのようなリソースが利用できますか?
• ノード障害によりクラスターの状態は変化しましたか?
• クラスターは正常ですか?

実際にここに保存されるのは、k8sクラスタがこれを認識し、それに応じてインテリジェントなアクションを実行するためです。

知らせ！

DB などのアプリケーション レベルのデータは etcd に保存されません。

Kubernetes コンポーネント:

K8s のアーキテクチャ プロセスを理解したので、次は、本番環境レベルのコンテナ オーケストレーションに役立つ K8s の主要コンポーネントをいくつか見てみましょう。

ここではこれらのコンポーネントをリストし、パート II でそれぞれについて詳しく説明します。

「パート 2: Kubernetes の主要コンポーネントと概念の紹介」

K8s の主要コンポーネントの一部は次のとおりです。

• ポッド: k8s の最小単位、コンテナ アプリケーションの抽象化
• サービスとイングレス: ノード間の外部通信と内部ポッドレベルの通信を管理する
• ConfigMaps: ポッド/DB を管理するために必要なエンドポイント URL
• シークレット: based64 エンコーディングを使用してアプリケーションレベルのパスワードと秘密鍵を安全に保存します
• ボリューム: 永久データ保存用
• デプロイメント: デプロイメントはレプリカを作成し、ステートレスアプリケーションを管理します
• ステートフルセット: ステートフルなアプリケーションとデータベース向け

次は何ですか？

上記の各コンポーネントの概念を学習し、各概念の実装を理解するためにいくつかの小さな実践的な演習を行います。

そこで、次のアイデアを検討してください。

「複雑なシステムでも、それを小さなモジュールに分解する方法がわかれば簡単に理解できます。この単純化の技術こそが、複雑なマイクロサービス アーキテクチャの背後にある中核的な考え方なのです。」