パブリック・クラウド・サービス・エンドポイントのみを使用する非 VRF 対応アカウントまたは VRF 対応アカウント

次の図は、パブリック・クラウド・サービス・エンドポイントのみを有効にした場合のクラスターの各コンポーネントと、非 VRF 対応アカウントまたは VRF 対応アカウントでのコンポーネント間の対話を示しています。

プライベート・クラウド・サービス・エンドポイントとパブリック・クラウド・サービス・エンドポイントを使用する VRF 対応アカウント

次の図は、パブリックおよびプライベート・クラウド・サービス・エンドポイントが有効化されている場合の VRF 対応アカウントで、クラスターの各コンポーネントがどのように相互作用するのかを示しています。

Kubernetes マスター・コンポーネント

Kubernetes マスターは、すべてのコンピュート・リソース、ネットワーク・リソース、ストレージ・リソースの管理を担い、コンテナー化されたアプリとサービスがクラスター内のワーカー・ノードに均等にデプロイされるようにします。 マスターは、アプリとサービスの構成方法に応じて、アプリの要件を満たせるだけのリソースがあるワーカー・ノードを決定します。

Kubernetes マスターおよびすべてのマスター・コンポーネントは、お客様ごとに専用のものがあり、他の IBM のお客様と共有することはありません。

次の表に、Kubernetes マスターの各コンポーネントについての説明を記載しています。

kube-apiserver

Kubernetes API サーバーは、ワーカー・ノードから Kubernetes マスターへのすべてのクラスター管理要求のメインエントリー・ポイントとして機能します。 Kubernetes API サーバーは、ポッドやサービスなどの Kubernetes リソースの状態を変更する要求を検証および処理してから、この状態を etcd に保管します。

konnectivity-server

KonnectivityサーバーはKonnectivityエージェントと連携し、マスターをワーカーノードに安全に接続します。 この接続は、ポッドやサービスに対する apiserver proxy 呼び出しと、kubelet に対する kubectl exec、attach、logs 呼び出しをサポートしています。

etcd

etcd は、クラスターのすべての Kubernetes リソース (サービス、デプロイメント、ポッドなど) の状態を保管する、可用性の高いキー値ストアです。 etcd 内のデータは、IBM が管理する暗号化ストレージ・インスタンスにバックアップされます。

kube-scheduler

Kubernetes スケジューラーは、新しく作成されたポッドを監視し、容量、パフォーマンスのニーズ、ポリシー制約、アンチアフィニティー仕様、およびワークロード要件に基づいて、それらのポッドをデプロイする場所を決定します。 要件に合致するワーカー・ノードが見つからなければ、ポッドはクラスターにデプロイされません。

kube-controller-manager

Kubernetes コントローラー・マネージャーは、レプリカ・セットなどのクラスター・リソースの状態を監視するデーモンです。 リソースの状態が変化する (例えば、レプリカ・セット内のポッドがダウンする) と、コントローラー・マネージャーは、必要な状態を実現するための修正アクションを開始します。

ワーカー・ノード・コンポーネント

各ワーカー・ノードは、物理マシン (ベア・メタル) であるか、クラウド環境内の物理ハードウェアで実行される仮想マシンです。 ワーカー・ノードをプロビジョンする際に、そのワーカー・ノード上でホストされるコンテナーで使用できるリソースを決定します。 お客様が特に何かを設定しなくても、ワーカー・ノードに対して、IBM が管理するコンテナー・ランタイム、別個の計算リソース、ネットワーキング、およびボリューム・サービスがセットアップされます。 標準装備のセキュリティー機能は、分離機能、リソース管理機能、そしてワーカー・ノードのセキュリティー・コンプライアンスを提供します。

ワーカー・ノードおよびすべてのワーカー・ノード・コンポーネントは、お客様ごとに専用のものがあり、他の IBM のお客様と共有することはありません。 ただし、仮想マシンのワーカー・ノードを使用する場合、選択したハードウェア分離のレベルによっては、基盤ハードウェアを他のお客様と共有することがあります。

デフォルト・ワーカー・ノード・コンポーネント (kubelet など) の変更はサポートされていないため、これらのコンポーネントを変更すると予期せぬ結果が生じる可能性があります。

下表で、ワーカー・ノードのコンポーネントについて説明します。

kube-system 名前空間

ibm-master-proxy

ibm-master-proxy が、ワーカー・ノードからの要求を、可用性の高い複数のマスター・レプリカの各 IP アドレスに転送します。 単一ゾーン・クラスターのマスターの場合は、別々のホスト上に 3 つのレプリカが存在しますが、マスターの IP アドレスとドメイン名は 1 つです。 複数ゾーン対応ゾーンにあるクラスターの場合、マスターの 3 つのレプリカがゾーン間に分散されます。 そのため、ドメイン・ネームはクラスター・マスター全体で 1 つですが、IP アドレスはマスターごとに独自のものが登録されます。

konnectivity-agent

KonnectivityエージェントはKonnectivityサーバーと連携し、マスターをワーカーノードに安全に接続します。 この接続は、ポッドやサービスに対する apiserver proxy 呼び出しと、kubelet に対する kubectl exec、attach、logs 呼び出しをサポートしています。

kubelet

kubelet は、ワーカー・ノードごとに実行されるポッドで、ワーカー・ノードで実行される各ポッドの正常性のモニタリングと、Kubernetes API サーバーが送信するイベントの監視を行うポッドです。 イベントに基づいて、kubelet は、ポッドを作成または削除し、Liveness Probe と Readiness Probe を確保し、Kubernetes API サーバーに応答としてポッドの状況を報告します。

coredns

デフォルトでは、Kubernetes は CoreDNS のポッド (またはバージョン 1.12 以前の KubeDNS ポッド) とサービスをクラスター上でスケジュールします。 コンテナーは、DNS サービスの IP を自動的に使用して、そのコンテナーによる他のポッドとサービスの検索で DNS 名を解決します。

calico

Calico はクラスターのネットワーク・ポリシーを管理し、以下のようないくつかのコンポーネントで構成されています。

calico-cni: Calico コンテナー・ネットワーク・インターフェース (CNI) は、コンテナーのネットワーク接続を管理し、コンテナーが削除されると、割り振られたリソースを削除します。

calico-ipam: Calico IPAM は、コンテナーの IP アドレス割り当てを管理します。

calico-node: Calico ノードは、ネットワーキング・コンテナーに必要な各種コンポーネントを Calico にバンドルするコンテナーです。

calico-policy-controller: Calico ポリシー・コントローラーは、設定されたネットワーク・ポリシーへの準拠について、インバウンドおよびアウトバウンドのネットワーク・トラフィックを監視します。 トラフィックがクラスター内で許可されていない場合は、クラスターへのアクセスはブロックされます。 Calico ポリシー・コントローラーは、クラスターのネットワーク・ポリシーを作成および設定するためにも使用されます。

kube-proxy

Kubernetes ネットワーク・プロキシーは、ワーカー・ノードごとに実行され、クラスター内で実行される各サービスの TCP および UDP のネットワーク・トラフィックの転送やロード・バランシングを行うデーモンです。

kube-dashboard

Kubernetes ダッシュボードは、クラスター内で実行中のアプリケーションとクラスターをユーザーが管理およびトラブルシューティングできるようにする Web ベースの GUI です。

heapster

Heapster は、モニタリングとイベント・データのクラスター全体の統合機能です。 Heapster ポッドは、クラスター内のすべてのノードを検出し、各ノードの kubelet から使用量情報を照会します。 Kubernetes ダッシュボードに各種使用状況グラフがあります。

Ingress ALB

Ingress は、パブリック要求またはプライベート要求をクラスター内の複数のアプリに転送することで、クラスター内のネットワーク・トラフィックのワークロードのバランスを取るために使用できる Kubernetes サービスです。 パブリック・ネットワークまたはプライベート・ネットワークを介してアプリを公開するには、Ingress リソースを作成して、Ingress アプリケーション・ロード・バランサー (ALB) にアプリを登録する必要があります。 これにより、単一の URL または IP アドレスを使用して、複数のアプリケーションへのアクセスが可能になります。

ストレージ・プロバイダー

すべてのクラスターは、ファイル・ストレージをプロビジョンするために、それぞれプラグインを使用してセットアップされます。 ブロック・ストレージなどの他のアドオンのインストールを選択できます。

ibm-system 名前空間

ロギングおよびメトリック

統合された IBM Cloud Logs サービスと IBM Cloud® Monitoring サービスを使用して、ログとメトリックを処理する際に収集および保存の機能を拡張できます。 ロード・バランサー

ロード・バランサーは、パブリック要求またはプライベート要求をアプリに転送することで、クラスター内のネットワーク・トラフィックのワークロードのバランスを取るために使用できる Kubernetes サービスです。

default 名前空間

アプリ・ポッドとアプリ・サービス

default 名前空間または作成した名前空間に、ポッドおよびサービス内のアプリをデプロイして、それらのポッドと通信することができます。