Kubernetes アーキテクチャとは何ですか? 重要性 + ベストプラクティス

Kubernetes は 2014 年以来、導入が大幅に増加しました。Google の内部クラスタ管理ソリューションである Borg からインスピレーションを得た Kubernetes は、アプリケーションのデプロイと管理を簡素化します。 すべてのコンテナ オーケストレーション ソフトウェアと同様に、Kubernetes は安全で簡単であるため、IT プロフェッショナルの間で人気が高まっています。 ただし、他のツールと同様に、そのアーキテクチャがどのように役立つかを認識すると、ツールをより効果的に使用できます。

Kubernetes アーキテクチャとは何か、何をするのか、なぜ重要なのかということから始めて、Kubernetes アーキテクチャの基礎について学びましょう。

Google は、さまざまな環境でコンテナ化されたアプリケーションを処理する、適応性のある Kubernetes コンテナ管理システムを作成しました。 これは、コンテナ化されたアプリケーションのデプロイを自動化し、変更を加え、これらのアプリケーションをスケールアップおよびスケールダウンするのに役立ちます。

ただし、Kubernetes は単なるコンテナ オーケストレーターではありません。 同様に、デスクトップ アプリは MacOS、Windows、または Linux 上で動作します。 クラウド ネイティブ アプリケーションのオペレーティング システムは、それらのプログラムのクラウド プラットフォームとして機能するためです。

コンテナとは何ですか?

コンテナーは、アプリケーションとその依存関係をパッケージ化するための標準的なアプローチであり、アプリケーションをランタイム環境間で簡単に実行できるようにします。 コンテナーを使用すると、アプリのコード、依存関係、構成を単一の使いやすいビルディング ブロックにパッケージ化することで、デプロイ時間を短縮し、アプリケーションの信頼性を高めるために重要な措置を講じることができます。

企業アプリケーション内のコンテナーの数が管理できなくなる可能性があります。 コンテナを最大限に活用するために、Kubernetes はコンテナのオーケストレーションを支援します。

Kubernetes は何に使用されますか?

Kubernetes は、コンテナー ワークロードを実行するための、非常に適応性と拡張性に優れたプラットフォームです。 Kubernetes プラットフォームは、クラウドネイティブ アプリケーションを作成する環境を提供するだけでなく、そのデプロイメントの管理と自動化にも役立ちます。

これは、アプリケーションのオペレーターと開発者が基盤となるコンピューティング、ネットワーク、ストレージ インフラストラクチャを調整する労力から解放され、セルフサービス運用のためのコンテナ中心のプロセスのみに集中できるようにすることを目的としています。 開発者は、複数のコンテナで構成されるアプリケーションのより高度な自動化とともに、特殊な展開および管理手順を作成することもできます。

Kubernetes は、モノリシック アプリケーション、ステートレスまたはステートフル プログラム、マイクロサービス、サービス、バッチ ジョブなど、すべての重要なバックエンド ワークロードを処理できます。

Kubernetes は、次のような利点があるために選択されることがよくあります。

• Kubernetes のインフラストラクチャは、多くの DevOps テクノロジのインフラストラクチャよりも優れています。
• Kubernetes は、コンテナをより小さなコンポーネントに分割して、正確に管理します。
• Kubernetes はソフトウェア更新を迅速かつ定期的に展開します。
• Kubernetes は、クラウドネイティブ アプリを開発するためのプラットフォームを提供します。

Kubernetes のアーキテクチャとコンポーネント

基本的な Kubernetes アーキテクチャは、K8s コンポーネントとしても知られる多くのコンポーネントで構成されているため、本題に入る前に、次の概念を覚えておくことが重要です。

• 基本的な Kubernetes アーキテクチャは、ノードを管理するコントロール プレーンと、コンテナ化されたアプリを実行するワーカー ノードで構成されます。
• コントロール プレーンが実行と通信を管理する一方で、ワーカー ノードは実際にこれらのコンテナを実行します。
• Kubernetes クラスターはノードのグループであり、各クラスターには少なくとも 1 つのワーカー ノードがあります。

Kubernetes アーキテクチャ図

Kubernetes コントロール プレーン

コントロール プレーンは、Kubernetes クラスター設計の中枢神経系の中心であり、クラスターの制御コンポーネントを収容します。 また、クラスター内のすべての Kubernetes オブジェクトの構成とステータスも記録します。

Kubernetes コントロール プレーンは、クラスターが期待どおりに動作するように、コンピューティング ユニットとの定期的な通信を維持します。 コントローラーはオブジェクトの状態を監視し、クラスターの変化に応じてシステム オブジェクトの物理的な観察された状態や現在の状態を望ましい状態や仕様に合わせます。

コントロール プレーンは、アプリケーション プログラミング インターフェイス (API) サーバー、スケジューラー、コントローラー マネージャー、etcd など、いくつかの重要な要素で構成されています。 これらの基本的な Kubernetes コンポーネントは、コンテナが適切なリソースで実行されることを保証します。 これらのコンポーネントはすべて単一のプライマリ ノード上で機能しますが、多くの企業では高可用性を実現するために多数のノードにコンポーネントを複製しています。

1. Kubernetes API サーバー

Kubernetes API サーバーは、Kubernetes コントロール プレーンのフロントエンドです。 さまざまなアプリケーションに API 管理を提供することで、更新、スケーリング、データの構成、その他のタイプのライフサイクル オーケストレーションを容易にします。 API サーバーはゲートウェイであるため、ユーザーはクラスターの外部から API サーバーにアクセスできる必要があります。 この場合、API サーバーはポッド、サービス、ノードへのトンネルになります。 ユーザーは API サーバーを通じて認証します。

2. Kubernetes スケジューラー

kube-scheduler は、各コンピューティング ノードのリソース使用率の統計を記録し、クラスターが正常かどうかを評価し、新しいコンテナーをデプロイするかどうか、またどこにデプロイするかを決定します。 スケジューラーは、クラスターの全体的な健全性と、中央処理装置 (CPU) やメモリーなどのポッドのリソース要求を評価します。 次に、リソースの制約や保証、データの局所性、サービス品質の要件、反アフィニティ、またはアフィニティの標準を考慮して、適切なコンピューティング ノードを選択し、タスク、ポッド、またはサービスをスケジュールします。

3. Kubernetes コントローラーマネージャー

Kubernetes 環境では、複数のコントローラーがエンドポイント (ポッドとサービス)、トークンとサービス アカウント (名前空間)、ノード、レプリケーション (自動スケーリング) の状態を管理します。 kube コントローラー マネージャーは、クラウド コントローラー マネージャーまたは単にコントローラーとして知られることが多く、さまざまなコントローラーの役割を実行することで Kubernetes クラスターを管理するデーモンです。

コントローラーは、Kubernetes コア制御ループの実行中にクラスター内のオブジェクトを監視します。 API サーバー経由で、望ましい状態と既存の状態を監視します。 管理対象オブジェクトの現在の状態と意図した状態が一致しない場合、コントローラーはオブジェクトのステータスを望ましい状態に近づけるための修正措置を講じます。 Kubernetes コントローラーは、重要なライフサイクル タスクも処理します。

4.etcd

etcd は、構成データとクラスターのステータス情報を保持する、分散型のフォールトトレラントなキー/値ストア データベースです。 etcd は独立してセットアップすることもできますが、多くの場合、Kubernetes コントロール プレーンの一部として機能します。

raft コンセンサス アルゴリズムは、etcd でクラスターの状態を維持するために使用されます。 これは、レプリケートされたステート マシンのコンテキストでの典型的な問題に対処するのに役立ち、多くのサーバーが値に同意する必要があります。 Raftではリーダー、候補者、フォロワーの3つの役割を設定し、リーダーへの投票を通じて合意形成を行います。

その結果、etcd はすべての Kubernetes クラスター コンポーネントにとって唯一の信頼できる情報源 (SSOT) となり、コントロール プレーンのクエリに応答し、コンテナー、ノード、ポッドの状態に関するさまざまな情報を収集します。 etcd は、ConfigMap、サブネット、シークレット、クラスター状態データなどの構成情報を保存するためにも使用されます。

Kubernetes ワーカー ノード

ワーカー ノードは、コントロール プレーンが管理するコンテナを実行するシステムです。 kubelet (Kubernetes のコア コントローラー) は、コントロール プレーンと対話するためのエージェントとして各ノードで実行されます。 さらに、各ノードは Docker や rkt などのコンテナー ランタイム エンジンを実行します。 監視、ロギング、サービス検出、およびオプションのその他のコンポーネントもノード上で実行されます。

いくつかの主要な Kubernetes クラスター アーキテクチャ コンポーネントは次のとおりです。

ノード

Kubernetes クラスターには少なくとも 1 つのコンピューティング ノードが必要ですが、容量要件に応じてさらに多くのコンピューティング ノードを含めることもできます。 ポッドはノード上で実行されるように調整され、スケジュールされるため、クラスターの容量を増やすには追加のノードが必要です。 ノードは Kubernetes クラスターの作業を実行します。 これらは、アプリケーションだけでなく、ネットワーキング、コンピューティング、ストレージ リソースもリンクします。

データ センター内のノードは、クラウド ネイティブの仮想マシン (VM) またはベア メタル サーバーの場合があります。

コンテナランタイムエンジン

各コンピューティング ノードは、コンテナー ランタイム エンジンを使用してコンテナーのライフ サイクルを操作および管理します。 Kubernetes は、Docker、CRI-O、rkt などのオープン コンテナ イニシアティブに準拠したランタイムをサポートします。

Kubeletサービス

kubelet は各計算ノードに含まれています。 これは、ポッド内のコンテナーが動作していることを保証するためにコントロール プレーンと通信するエージェントです。 コントロール プレーンがノードで特定のアクションの実行を要求すると、kubelet は API サーバー経由でポッドの仕様を取得して動作します。 次に、関連するコンテナーが正常に動作していることを確認します。

Kubeプロキシサービス

各計算ノードには、kube-proxy として知られるネットワーク プロキシがあり、Kubernetes ネットワーキング サービスを支援します。 クラスター内外のネットワーク接続を管理するために、kube-proxy はトラフィックを転送するか、オペレーティング システムのパケット フィルター層に依存します。

kube-proxy プロセスは各ノードで動作し、他のパーティがサービスを利用できるようにし、特定のホストのサブネット化に対処します。 これはノード上でネットワーク プロキシおよびサービス ロード バランサとして機能し、ユーザー データグラム プロトコル (UDP) および伝送制御プロトコル (TCP) トラフィックのネットワーク ルーティングを処理します。 実際には、kube-proxy はすべてのサービス エンドポイントのトラフィックをルーティングします。

ポッド

これまで、内部およびインフラストラクチャ関連のアイデアについて説明してきました。 ただし、ポッドは開発者がやり取りする主要な外部コンポーネントであるため、Kubernetes にとって重要です。

ポッドは、Kubernetes コンテナー モデルの最も単純な単位であり、アプリケーションの単一インスタンスを表します。 各ポッドは、論理的に適合し、コンテナの機能を管理するルールを実行する 1 つのコンテナまたは複数の密接に関連したコンテナで構成されます。

ポッドの寿命は有限であり、アップグレードまたはスケールダウン後に最終的には停止します。 一時的ではありますが、永続ストレージに接続することでステートフル アプリケーションを実行します。

ポッドは水平方向に拡張することもできます。これは、動作するインスタンスの数を増減できることを意味します。 また、ローリング アップデートやカナリア デプロイメントも実行できます。

ポッドはノード上で一緒に動作するため、コンテンツとストレージを共有し、ローカルホストを通じて他のポッドと通信する場合があります。 コンテナーは複数のコンピューターにまたがる場合があり、ポッドも同様です。 1 つのノードで複数のポッドを操作でき、それぞれが多数のコンテナーを収集します。

ポッドは、Kubernetes エコシステムの中央管理単位であり、リソースとコンテキストを共有するコンテナーの論理境界として機能します。 ポッドのグループ化方法により、複数の依存プロセスを同時に実行できるようになり、仮想化とコンテナー化の違いが軽減されます。

その他の Kubernetes アーキテクチャ コンポーネント

Kubernetes はアプリケーションのコンテナを維持しますが、クラスター内の関連するアプリケーション データも管理する場合があります。 Kubernetes のユーザーは、基盤となるストレージ インフラストラクチャを理解していなくても、ストレージ リソースを要求できます。

Kubernetes ボリュームは、ポッドがデータにアクセスしてデータを保存できるディレクトリです。 ボリューム タイプによって、ボリュームの内容、その成り立ち、およびボリュームをサポートするメディアが決まります。 永続ボリューム (PV) は、多くの場合管理者によって提供されるクラスター固有のストレージ リソースです。 PV は、特定のポッドを超えて存続することもあります。

Kubernetes は、コンテナー レジストリに保存されているコンテナー イメージに依存しています。 サードパーティのレジスターまたは組織が作成したレジスターである可能性があります。

ネームスペースは、物理クラスター内に存在する仮想クラスターです。 これらは、多数のユーザーやチームのために独立した作業環境を作成するように設計されています。 また、アクセスできる Kubernetes オブジェクトを制限することで、チームが相互に干渉するのを防ぎます。 ポッド内の Kubernetes コンテナは、localhost を通じて他のポッドと通信し、IP アドレスとネットワーク名前空間を共有できます。

Kubernetes 対 Docker Swarm

Kubernetes と Docker はどちらも、コンテナー管理とアプリケーションのスケーリングを提供するプラットフォームです。 Kubernetes は、複雑なセットアップを必要とする高要求アプリケーションに最適な効果的なコンテナ管理ソリューションを提供します。 対照的に、 Docker Swarmはシンプルさを重視して構築されているため、迅速にデプロイして保守できる重要なアプリには最適です。

• Docker Swarm は、Kubernetes よりもデプロイと構成が簡単です。
• Kubernetes はトラフィックに基づいたオールインワンのスケーラビリティを提供しますが、Docker Swarm は迅速なスケーリングを優先します。
• 自動負荷分散は Docker Swarm では利用できますが、Kubernetes では利用できません。 ただし、サードパーティのソリューションは外部ロード バランサーを Kubernetes にリンクする場合があります。

会社の要求によって適切なツールが決まります。

コンテナ オーケストレーション ソリューション

コンテナ オーケストレーション システムを使用すると、開発者はアプリケーションを展開するために複数のコンテナを起動できます。 IT 管理者はこれらのプラットフォームを使用して、インスタンスの管理、ホストの調達、コンテナの接続を自動化できます。

以下に、デプロイを容易にし、失敗したコンテナ実装を特定し、アプリケーション構成を管理するための最良のコンテナ オーケストレーション ツールの一部を示します。

Kubernetes アーキテクチャのベスト プラクティスと設計原則

セキュリティ、ガバナンス、モニタリング、ストレージ、ネットワーキング、コンテナのライフサイクル管理、オーケストレーションを考慮したプラットフォーム戦略を導入することが重要です。 ただし、Kubernetes は、特にオンプレミスとパブリック クラウドの両方のインフラストラクチャを管理する企業にとって、導入と拡張が非常に困難です。 簡素化するために、Kubernetes クラスターを設計する際に考慮する必要があるいくつかのベスト プラクティスについて以下で説明します。

• 常に最新バージョンの Kubernetes を使用していることを確認してください。
• 開発チームと運用チームのトレーニングに投資します。
• 全社的なガバナンスを確立します。 ツールとプロバイダーが Kubernetes オーケストレーションと互換性があることを確認してください。
• 継続的インテグレーションおよびデリバリー (CI/CD) ワークフローにイメージ スキャン技術を組み込むことで、セキュリティを強化します。 GitHub リポジトリからダウンロードしたオープンソース コードは、常に注意して扱う必要があります。
• クラスター全体にロールベースのアクセス制御(RBAC) を実装します。 最小特権とゼロトラストに基づくモデルが標準となるべきです。
• コンテナをさらに保護するために、非 root ユーザーのみを使用し、ファイル システムを読み取り専用にします。
• 単純な宣言の方がエラーが発生しにくく、目的をよりよく伝えることができるため、デフォルト値は避けてください。
• 基本的な Docker Hub イメージを利用する場合は、マルウェアが含まれたり、不要なコードで肥大化したりする可能性があるため、注意してください。 無駄のないクリーンなコードから始めて、徐々にレベルを上げていきます。 画像が小さいほど、成長が早くなり、ストレージ上の占有スペースが減り、画像の取得が速くなります。
• コンテナはできるだけシンプルにしてください。 コンテナーごとに 1 つのプロセスを使用すると、オーケストレーターはそのプロセスが正常かどうかを報告できます。
• 疑わしいときはクラッシュします。 Kubernetes は失敗したコンテナを再起動するため、失敗時に再起動しないでください。
• 説明的なものにしてください。 説明的なラベルは、現在および将来の開発者に利益をもたらします。
• マイクロサービスに関しては、あまり具体的にしないでください。 論理コード コンポーネント内のすべての関数がそのマイクロサービスであってはなりません。
• 可能な場合は自動化します。 CI/CD ワークフローを自動化することで、手動による Kubernetes デプロイを完全にスキップできます。
• liveiness プローブと readiness プローブを使用して、ポッドのライフサイクルの管理を支援します。 そうしないと、初期化中またはユーザー要求の受信中に、準備が整う前にポッドが終了される可能性があります。

コンテナを検討してください

コンテナ中心の管理ソフトウェアである Kubernetes は、企業内でコンテナが広く使用されているため、コンテナ化されたアプリケーションのデプロイと運用の事実上の標準となっています。 Kubernetes アーキテクチャはシンプルで直感的です。 これにより、IT 管理者はインフラストラクチャとアプリケーションのパフォーマンスをより細かく制御できるようになりますが、テクノロジーを最大限に活用するには学ぶべきことがたくさんあります。

このテーマについてさらに詳しく知りたいですか? クラウド コンピューティングにおけるコンテナ化の関連性が高まっていることについて学びましょう。