MS Learn を通して Kubernetes と Azure Kubernetes Service を本気で理解しにいく記録 1
このドキュメントの内容
MS Learn の コンテナー化されたアプリケーションを Azure Kubernetes Service にデプロイする というラーニング コンテンツを通して、Kubernetes と AKS について理解するための内容の記録です。
コンテナー アプリケーションはおろか、クラウドとは？と言うようなレベルだった私が、これらのことを理解するため学びまとめながら作成した記事です。
今回はラーニング内のユニット 2 の「Azure Kubernetes Service クラスターを作成する」を進めます。(ユニット 1 は「はじめに」と言うシナリオ付きの導入のため、AKS とは直接関係ないものでした)
あとがき - 結局 Kubernetes とはなんなのか
この記事を書き終えた後、結局 Kubernetes とはどんなものか？というのを自分なりにまとめてみました。
- コンテナー技術により実現されるマイクロサービス アーキテクチャによって構成されたアプリケーションを動作させるプラットフォーム。このプラットフォームの実態は複数の仮想マシンで構成されたコンピューティング リソース郡であり、Kuberenets はそれら仮想マシンを、コンテナーが動作する一つの大きなシステムのようなコンピューティング リソースとして扱えるようにしてくれる。
- アプリケーションの負荷に応じて自動または手動でコンテナー レベルやコンテナーをホストする仮想マシン レベルでスケール アウト/インを行なってくれる。
Kubernetes クラスター
Kubernetes はクラスターに基づいています。 単一の仮想マシン (VM) が使用されるのではなく、1 つのものとして動作する複数のマシンが使用されます。 これらの VM はノードと呼ばれます。 Kubernetes はクラスターベースのオーケストレーターです。 可用性、監視、スケーリング、ローリング更新など、アプリケーションにいくつかの利点が提供されます。
MS Learn あるあるの機械翻訳の名残のためか、「Kubernetes」と言う単語をはじめ、早速私には理解が曖昧な言葉がたくさん出てきました。以下に分からない単語と、それぞれがどんなものかを調べた内容を挙げます。
引用元のリファレンスと、それに基づいた私なりの解釈という流れで調べます。
Kubernetes
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させたGoogleの15年以上の経験と、コミュニティからの最高のアイディアや実践を組み合わせています。
Kubernetes 公式のドキュメントによると、「コンテナ化されたワークロードやサービスを管理するためのオープンソース プラットフォーム」であるとのことでした。
ワークロード を「Kubernetes 上で実行可能なアプリケーション」と広く考えると、コンテナー化されたアプリケーションを管理するためのプラットフォームと言えます。
コンテナは、アプリケーションを集約して実行する良い方法です。本番環境では、アプリケーションを実行しダウンタイムが発生しないように、コンテナを管理する必要があります。例えば、コンテナがダウンした場合、他のコンテナを起動する必要があります。このような動作がシステムに組込まれていると、管理が簡単になるのではないでしょうか？
そこを助けてくれるのがKubernetesです! Kubernetesは分散システムを弾力的に実行するフレームワークを提供してくれます。あなたのアプリケーションのためにスケーリングとフェイルオーバーの面倒を見てくれて、デプロイのパターンなどを提供します。例えば、Kubernetesはシステムにカナリアデプロイを簡単に管理することができます。 Kubernetesは以下を提供します。
- サービスディスカバリーと負荷分散
Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるため、デプロイが安定します。- ストレージ オーケストレーション
Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。- 自動化されたロールアウトとロールバック
Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用する作業を、Kubernetesで自動化できます。- 自動ビンパッキング
コンテナ化されたタスクを実行するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣言することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。- 自己修復
Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。- 機密情報と構成管理
Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。
非常にたくさん書いてあります。誤解を恐れず超噛み砕いて表現するならば、
Kubernetes はコンテナーの管理を勝手にやってくれる奴で、アプリケーションのスケーリングやフェールオーバーなど自動で行なってくれる。Kubernetes は以下の機能を提供する。
- DNS 名や IP アドレスでコンテナー アプリケーションを公開可能で、さらにコンテナーに対するリクエストを付加分散する機能あり
- 選択したストレージを自動でマウントすることができる
- アプリケーションを予め設定した状態に保つため、コンテナーの作成や削除などを自動で行ってくれる
- コンテナーを実行するリソースを最大限活用するためにコンテナーを調整可能
- 処理が失敗したコンテナーなどを削除するなどの自己修復機能を持つ
- Kubernetes はパスワードなどの機密情報を保持/管理可能
Kubernetes はクラスターに基づいている
Kubernetes 公式ページにある標準化用語集の クラスター の項目には下記のように記されています。
コンテナ化されたアプリケーションを実行する、ノードと呼ばれるワーカーマシンの集合です。すべてのクラスターには少なくとも1つのワーカーノードがあります。
ワーカーノードは、アプリケーションのコンポーネントであるPodをホストします。マスターノードは、クラスター内のワーカーノードとPodを管理します。複数のマスターノードを使用して、クラスターにフェイルオーバーと高可用性を提供します。 ワーカーノードは、アプリケーションワークロードのコンポーネントであるPodをホストします。コントロールプレーンは、クラスター内のワーカーノードとPodを管理します。本番環境では、コントロールプレーンは複数のコンピューターを使用し、クラスターは複数のノードを使用し、耐障害性や高可用性を提供します。
また、Kubernetesとは何か？ には次のようにあります。
仮想化を利用すると、物理リソースのセットを使い捨て可能な仮想マシンのクラスターとして提示することができます。
ドキュメントから、Kubernetes クラスターとは使い捨て可能なノードと呼ばれる 1 つ以上の仮想マシンの集合である事がわかります。
オーケストレーター
RedHat の オーケストレーションとは に下記のように記されています。
オーケストレーションとは、コンピュータシステム、アプリケーション、およびサービスにおける、設定、管理、調整の自動化を意味します。オーケストレーションを活用すると、IT は複雑なタスクやワークフローをより簡単に管理することができます。
つまり、オーケストレーターとは設定や管理や調整を自動化する立場である事がわかります。
上記を踏まえ、Kubernetes クラスターとは「ノードと呼ばれる 1 つ以上の仮想マシンの集合」であり、Kubernetes は「クラスター単位で設定、管理、調整の自動化を行う奴」であると言えます。
クラスター ノード
クラスターはノードが基になります。 Kubernetes クラスターには、特定の機能を提供する 2 種類のノードがあります。
- コントロール プレーン ノード: これらのノードは、クラスターのコントロール プレーンの側面をホストするために使用され、クラスターを制御するサービス用に予約されています。 これらには、ユーザーや他のすべてのノードが通信に使用する API を提供する役割があります。 これらのノードにワークロードがデプロイまたはスケジュールされることはありません。
- ノード: これらのノードには、クラウドベースのビデオ レンダリング サービスからのコンポーネントなど、カスタムのワークロードとアプリケーションを実行する役割があります。
コントロール プレーン
コントロール プレーン ノードの説明に「コントロール プレーン」が出てきました。
コンテナのライフサイクルを定義、展開、管理するためのAPIとインターフェイスを公開するコンテナオーケストレーションレイヤーです。 このレイヤーは、次のような多くの異なるコンポーネントから構成されます(しかし、これらに限定はされません)。
- etcd
- APIサーバー
- スケジューラー
- コントローラーマネージャー
- クラウドコントローラーマネージャー a これらのコンポーネントは従来のオペレーティングシステムサービス(デーモン)もしくはコンテナとして実行できます。これらのコンポーネントを実行するホストは歴史的にマスターと呼ばれていました。
Kubernetesマスターや kubeletプロセスといったKubernetesコントロールプレーンのさまざまなパーツは、Kubernetesがクラスターとどのように通信するかを統制します。コントロールプレーンはシステム内のすべてのKubernetesオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行します。コントロールプレーンの制御ループは常にクラスターの変更に反応し、システム内のすべてのオブジェクトの実際の状態が、指定した状態に一致するように動作します。
たとえば、Kubernetes APIを使用してDeploymentを作成する場合、システムには新しいdesired state (望ましい状態)が提供されます。Kubernetesコントロールプレーンは、そのオブジェクトの作成を記録します。そして、要求されたアプリケーションの開始、およびクラスターノードへのスケジューリングにより指示を完遂します。このようにしてクラスターの実際の状態を望ましい状態に一致させます。
コントロールプレーンはシステム内のすべてのオブジェクトの記録を保持し、それらのオブジェクトの状態を管理するために継続的制御ループを実行する奴であることがわかります。
しかしより一層不明な点が増えました。次にコントロール プレーンに含まれるそれぞれのコンポーネントについて調べます。
etcd
一貫性、高可用性を持ったキーバリューストアで、Kubernetesの全てのクラスター情報の保存場所として利用されています。
etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines. It gracefully handles leader elections during network partitions and can tolerate machine failure, even in the leader node. Learn more
etcd についてまとめると、Kubernetes は全てのクラスターの情報の保存に etcd を使用していて、etcd とはキーバリューストア (KVS (NoSQL に分類される)) のことであるようです。
API サーバー
APIサーバーは、Kubernetes APIを外部に提供するKubernetesコントロールプレーンのコンポーネントです。 APIサーバーはKubernetesコントロールプレーンのフロントエンドになります。
Kubernetes APIサーバーの主な実装はkube-apiserverです。 kube-apiserverは水平方向にスケールするように設計されています—つまり、インスタンスを追加することでスケールが可能です。 複数のkube-apiserverインスタンスを実行することで、インスタンス間でトラフィックを分散させることが可能です。
Kubernetesの中核である control planeはAPI server です。 APIサーバーは、エンドユーザー、クラスターのさまざまな部分、および外部コンポーネントが相互に通信できるようにするHTTP APIを公開します。
Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。
ほとんどの操作は、APIを使用しているkubectlコマンドラインインターフェースもしくはkubeadmのような別のコマンドラインツールを通して実行できます。 RESTコールを利用して直接APIにアクセスすることも可能です。
Kubernetes を操作するための API (Kubernetes API) を公開するためのコンポーネントが kube-apiserver であり、kubectl コマンドなどを通して Kubernetes API を利用することにより、Kubernetes を操作できるようです。
スケジューラー
コントロールプレーン上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。
スケジューリングの決定は、PodあるいはPod群のリソース要求量、ハードウェア/ソフトウェア/ポリシーによる制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉、有効期限などを考慮して行われます。
ポッドが作成される際にノードの割り当てを担うコンポーネントのようです。
コントローラーマネージャー
コントロールプレーン上で動作するコンポーネントで、複数のコントローラープロセスを実行します。
論理的には、各コントローラーは個別のプロセスですが、複雑さを減らすために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。
コントローラーには以下が含まれます。
- ノードコントローラー：ノードがダウンした場合の通知と対応を担当します。
- レプリケーションコントローラー：システム内の全レプリケーションコントローラーオブジェクトについて、Podの数を正しく保つ役割を持ちます。
- エンドポイントコントローラー：エンドポイントオブジェクトを注入します(つまり、ServiceとPodを紐付けます)。
- サービスアカウントとトークンコントローラー：新規の名前空間に対して、デフォルトアカウントとAPIアクセストークンを作成します。
ノードがダウンした場合の通知と対応を行う、レプリケーションを行うなどの複数のコントローラーのプロセスがまとめられた単一のプロセスのようです。
クラウドコントローラーマネージャー
クラウドインフラストラクチャー技術により、パブリック、プライベート、ハイブリッドクラウド上でKubernetesを動かすことができます。Kubernetesは、コンポーネント間の密なつながりが不要な自動化されたAPI駆動インフラストラクチャーを信条としています。
cloud-controller-managerは クラウド特有の制御ロジックを組み込むKubernetesのcontrol planeコンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
Kubernetesと下のクラウドインフラストラクチャー間の相互運用ロジックを分離することで、cloud-controller-managerコンポーネントはクラウドプロバイダを主なKubernetesプロジェクトと比較し異なるペースで機能をリリース可能にします。
cloud-controller-managerは、プラグイン機構を用い、異なるクラウドプロバイダーに対してそれぞれのプラットフォームとKubernetesの結合を可能にする構成になっています。
AKS などのクラウド サービスにおいて Kubernetes を実行する場合に動作するコンポーネントのようです。
クラウド プロバイダーが関連するコンポーネントのみ、API によってリンクされ、その他 Kubernetes オリジナルの操作は、そのままコントローラーマネージャーが対応する、というようですね。
クラスターのアーキテクチャ
クラスター アーキテクチャを使用すると、Kubernetes クラスターにデプロイするコントロール プレーンとノードの数を概念化できます。
たとえば、クラスター内のノードの数は、常に 2 つより多くする必要があります。 あるノードが使用できなくなると、Kubernetes スケジューラにより、このノードで実行されていたすべてのワークロードが、クラスター内の残りのノードに再スケジュールされます。
Kubernetes ベースのデプロイには、2 つの一般的なクラスター アーキテクチャがあります。
「クラスター内のノード数を 2 より多くする」という設定を行なっておくと、上記で調べたコントロール プレーンのスケジューラーなどのコンポーネントが動作し、ノード数に関する設定などを維持できる、ということですね。徐々につかめてきました。
単一のコントロール プレーンと複数のノード
単一のコントロール プレーンと複数のノードのアーキテクチャは、最も一般的なアーキテクチャ パターンです。 このパターンはデプロイするのが最も簡単ですが、クラスターのコア管理サービスに対して高可用性は提供されません。
何らかの理由でコントロール プレーン ノードが使用できなくなった場合、クラスターで他の操作を行うことはできません。 これは、少なくとも API サーバーがオンラインに戻るまでは、オペレーターの場合にも、通信に Kubernetes の API を使用するワークロードの場合にも当てはまります。
他より可用性は低くなりますが、ほとんどの状況にはこのアーキテクチャで十分なはずです。 コア管理サービスが使用できなくなる可能性は、ノードがオフラインになる可能性ほど高くありません。 コントロール プレーン ノードは、ノードより変更されることが少なく、高い回復性を備えています。
運用シナリオに対応している場合は、このアーキテクチャは最適なソリューションではない可能性があります。
Kubernetes の一般的なアーキテクチャは「単一のコントロール プレーンと複数のノード」のパターンであることが分かります。
また、もちろんコントロール プレーンが使用できない状況では、コントロール プレーン上で動作している Kubernetes API も使用出来ない、と言うことですね。kubectl コマンドをはじめ、スケーリングなども利用出来ないと思われます。
また、このトピックでは「単一のコントロール プレーンと複数のノードのアーキテクチャ」について述べられていますが、この表現からは「複数のコントロール プレーンを持つアーキテクチャ」や「単一のノードを持つアーキテクチャ」などが存在しうると読み取れます。
複数のコントロール プレーン
複数のコントロール プレーンを持つアーキテクチャに関してはこちらに述べられておりました。
このページでは、高可用性(HA)Kubernetesクラスターのトポロジーを設定するための2つのオプションについて説明します。
HAクラスターは次の方法で設定できます。
- 積層コントロールプレーンノードを使用する方法。こちらの場合、etcdノードはコントロールプレーンノードと同じ場所で動作します。
- 外部のetcdノードを使用する方法。こちらの場合、etcdがコントロールプレーンとは分離されたノードで動作します。
etcd が動作する場所がコントロール プレーン上である、または外部の etcd クラスター、と言う分け方で 2 つオプションがあるようです。
単一のコントロール プレーンと単一のノード
単一のコントロール プレーンと単一のノードのアーキテクチャは、前のアーキテクチャのバリエーションであり、開発環境で使用されます。 このアーキテクチャによって、コントロール プレーンとワーカー ノードの両方をホストするノードが 1 つだけ提供されます。 これは、Kubernetes のさまざまな概念をテストまたは実験するときに便利です。 単一コントロール プレーンと単一ノードのアーキテクチャによってクラスターのスケーリングが制限されるため、このアーキテクチャは運用環境やステージング環境での使用には適していません。
単一のコントロール プレーンと単一のノードと言うアーキテクチャも存在するようです。
このアーキテクチャは開発環境など前提であり、コンテナーのスケーリングに関しては、限られたコンピューティング リソースを利用したものであるため、運用環境では推奨されない構成ということです。
AKS クラスターを構成する
新しい AKS クラスターを作成するときは、複数の異なる情報項目を構成する必要があります。 各項目は、クラスターの最終的な構成に影響します。
次のような項目があります。
- ノード プール
- ノード数
- 自動ルーティング
Azure Kubernetes Service 上で Kubernetes クラスター (AKS クラスター) を構成する場合、上記の 3 つが必要です。次のセクション以降で詳細を確認して参ります。
ノード プール
AKS クラスター内のノードをグループ化するには、”ノード プール” を作成します。 ノード プールを作成するときは、アプリケーションの要件に基づいて、ノード プールの各ノードの VM サイズと OS の種類 (Linux または Windows) を指定します。 ユーザー アプリケーション ポッドをホストするには、ノード プールの [モード] が [ユーザー] または [システム] である必要があります。
既定では、AKS クラスターには、Azure portal または CLI を使用して作成するかどうかにかかわらず、Linux ノード プール (システム モード) が設定されます。 ただし、ポータルの作成ウィザード、CLI、または ARM テンプレートの実行時に、いつでも既定の Linux ノード プールと共に Windows ノード プールを追加できます。
ノード プールでは、基盤となるインフラストラクチャとして仮想マシン スケール セットを使用することにより、クラスターでノード プール内のノード数をスケーリングできるようにします。 ノード プールで作成される新しいノードは、常に、ノード プールの作成時に指定したサイズと同じサイズになります。
AKS クラスター内のノードをグループ化する仕組みとして、ノードプールが存在し、ノードプールのモードには システム モードとユーザー モードがあります。
Azure Kubernetes Service (AKS) でシステム ノード プールを管理する
システム ノード プールとユーザー ノードプールの 2 つの異なるノード プールのモードがあります。 システム ノード プールは、CoreDNS や metrics-server などの重要なシステム ポッドをホストするという主要な目的を果たします。 ユーザー ノード プールは、アプリケーション ポッドをホストするという主要な目的を果たします。 ただし、AKS クラスター内のプールを 1 つだけにする場合は、システム ノード プールでアプリケーション ポッドをスケジュールすることができます。 各 AKS クラスターには、少なくとも 1 つのノードを含むシステム ノード プールが、少なくとも 1 つ含まれている必要があります。
システム ノードプールは主に CoreDNS や metrics-server などの重要なシステム ポッドをホストするという用途で、ユーザー ノード プールは主に、アプリケーション ポッドをホストするという用途で利用され、システム ノードプール上でもユーザーアプリケーションのポッドを動作させることもできるという事ですね。
AKS ではノード レベルのスケール アウトを実現する際に、仮想マシンに対して同じ OS やコンピューティング サイズを設定するため、仮想マシンスケールセットを用いています。そのためノードプール数分、仮想マシンスケールセットが作成されます。
ノード数
ノード数は、クラスターのノード プール内に存在するノードの数です。 ノードは Azure VM です。 使用パターンに合わせてサイズと数を変更することができます。
ノード数は、クラスターの構成パネルを使用して後から変更できます。 また、不要なコストや未使用のコンピューティング能力を避けるため、この数をできるだけ少なくすることがベスト プラクティスです。
ノード数はノード プール (仮想マシンスケールセット) 内の仮想マシンの数です。スケーリングを実施するため、クラスターを構成するノード数を変更可能でき、自動または手動スケーリングによりできるだけノード数を少なくする事が良いとされています。
自動ルーティング
Kubernetes クラスターでは、すべての外部通信が既定でブロックされます。 たとえば、すべてのクライアントからアクセス可能な Web サイトをデプロイするとします。 特定のサービスへの受信クライアント接続を許可するものを除き、”イングレス” を手動で作成する必要があります。 このような構成にするには、クライアントからの要求をクラスターの内部 IP に転送し、最終的にアプリケーションに渡すように、ネットワーク関連の変更を行う必要があります。 特定の要件によっては、このプロセスは複雑になる場合があります。
AKS を使用すると、HTTP アプリケーション ルーティングと呼ばれるものを有効にして、複雑さを軽減できます。 このアドオンにより、自動的にデプロイされるイングレス コントローラーを通してクラスター上のアプリケーションに簡単にアクセスできるようになります。
Kubernetes クラスターは既定では外部からの通信がブロックされており、基本的にはコンテナーで動作しているアプリケーションと通信を行うにはイングレスを作成する必要があります。
Service
Podの集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法です。
KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
Service とは、複数の Pod 上で動作しているコンテナー アプリケーションに対し、DNS 名の提供や各 Pod への負荷分散、それぞれの Pod に対して IP アドレスの割り振りなどを行います。
HTTP アプリケーション ルーティング
HTTP アプリケーション ルーティング ソリューションを使用すると、Azure Kubernetes Service (AKS) にデプロイされたアプリケーションに簡単にアクセスできます。 ソリューションを有効にすると、AKS クラスター内にイングレス コントローラーが構成されます。 アプリケーションがデプロイされると、このソリューションは、アプリケーション エンドポイントのパブリックにアクセス可能な DNS 名も作成します。
HTTP アプリケーション ルーティング アドオンは Azure の Kubernetes のネットワーク アドオンであり、イングレス コントローラーを自動で作成し、インターネットへのアプリケーションの公開を簡単にします。
このアドオンは、現在、運用環境で使用できるように設計されていないため、運用環境で使用することはお勧めできません。
現在、HTTP アプリケーション ルーティング アドオンは運用環境での使用は推奨されていません。
イングレス コントローラー
イングレス コントローラーを使用すると、ネットワーク関連のサービスを構成することなく、アプリケーションをデプロイして世界に公開する機能が提供されます。
イングレス コントローラーにより、1 つの DNS 出力ですべての要求に自動的に対応できるようにするリバース プロキシ サーバーが作成されます。 新しいサービスをデプロイするたびに、DNS レコードを作成する必要はありません。 イングレス コントローラーによって処理されます。 新しいイングレスがクラスターにデプロイされると、イングレス コントローラーよって、Azure で管理される DNS ゾーンに新しいレコードが作成されて、既存のロード バランサーにリンクされます。 この機能により、インターネット経由でリソースに簡単にアクセスできるようになり、追加の構成は必要ありません。
この利点にもかかわらず、HTTP アプリケーションのルーティングは、より基本的なクラスターにいっそう適しています。 より複雑な構成に必要なカスタマイズが提供されていません。 より複雑なクラスターを扱う場合は、Kubernetes の公式のイングレス コントローラーなどのさらに適切なオプションがあります。
イングレスを作成することにより、アプリケーションをインターネットへ公開可能です。
Ingress
クラスター内のServiceに対する外部からのアクセス(主にHTTP)を管理するAPIオブジェクトです。
Ingressは負荷分散、SSL終端、名前ベースの仮想ホスティングの機能を提供します。
IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。Ingressコントローラーは通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。
Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、Service.Type=NodePortやService.Type=LoadBalancerのServiceタイプを一般的には使用します。
つまりイングレスは Service への HTTP 通信を管理するオブジェクトとであり、クラスターの外部から来た HTTP 通信をクラスターの内部へルーティングするものです。
また、URL レベルで負荷分散が可能であるため、OSI 参照モデルで言うところのレイヤー 7 で動作する L7 ロードバランサーの役割を果たす事が分かります。
参考文献
- コンテナー化されたアプリケーションを Azure Kubernetes Service にデプロイする
- Kubernetesとは何か？
- Kubernetesのコンポーネント
- オーケストレーションとは
- 高可用性トポロジーのためのオプション
本投稿が何かの役に立てば幸いです。
Toxumuharu
2022 年 7 月 30 日時点の内容となります。
本記事の内容は予告なく変更される場合がございますので予めご了承ください。