Kubernetesの概要

1 Kubernetesの概要

Kubernetesは、コンテナ化されたアプリケーションのデプロイメント、スケーリングおよび管理を自動化するためのオープン・ソース・システムです。 Kubernetesは、主に、コンテナ化されたアプリケーションを必要に応じてデプロイおよびスケーリングできるシステムのクラスタを簡単に作成できるようにするツールを提供します。

Kubernetesプロジェクトは、次の場所で管理運営されています。

https://kubernetes.io/

Kubernetesは、Oracle Linuxで完全にテストされ、Kubernetesクラスタの構成とデプロイメントを容易にするためにOracleで開発された追加のツールが含まれています。

Kubernetesのコンポーネント

Oracle Cloud Native EnvironmentでKubernetesの使用を開始すると、次の共通コンポーネントを満たす可能性があります。記載された説明は簡単なもので、用語集と一般的なKubernetes環境のアーキテクチャの概要を示すことを主な目的としています。アップストリームのドキュメントは、次の場所にあります。

https://kubernetes.io/docs/concepts/

Nodes

Kubernetesノードのアーキテクチャについては、次の場所に詳しい説明があります。

https://kubernetes.io/docs/concepts/architecture/nodes/

コントロール・プレーン・ノード

コントロール・プレーン・ノードは、クラスタ管理、およびKubernetesクラスタ内のリソースの構成および管理に使用されるAPIの提供を担当します。 Kubernetesコントロール・プレーン・ノードのコンポーネントは、専用ポッド内のコンテナのセットとしてKubernetes自体で実行されます。これらのコンポーネントは、高可用性(HA)コントロール・プレーン・ノード機能を実現するためにレプリケートできます。

コントロール・プレーン・ノードには、次のコンポーネントが必要です。

API Server (kube-apiserver): Kubernetes REST APIは、API Serverによって公開されます。このコンポーネントは、操作の処理と検証を実行し、ワーカー・ノードの操作をトリガーするためにCluster State Storeの情報を更新します。 APIはクラスタへのゲートウェイでもあります。
「クラスタ状態ストア」 (etcd): クラスタ状態に関連する構成データはクラスタ状態ストアに格納され、コントローラ・マネージャやスケジューラなどの調整コンポーネントへの変更をロールアウトできます。このクラスタ・コンポーネントに格納されたデータに適切なバックアップ・プランがあることを確認します。
「クラスタ・コントローラ・マネージャ」 (kube-controller-manager): このマネージャは、クラスタ・ステート・ストアおよびAPIサーバーからの入力に基づいて、多くのクラスタ・レベルの機能およびアプリケーション管理を実行するために使用されます。
「スケジューラ」 (kube-scheduler): スケジューラ・ハンドルは、リソースの可用性、サービス品質およびアフィニティ仕様をモニタリングすることで、コンテナが実行される場所を自動的に決定します。

コントロール・プレーン・ノードは、クラスタ内のワーカー・ノードとして構成できます。したがって、コントロール・プレーン・ノードは標準ノード・サービスも実行: kubeletサービス、コンテナ・ランタイムおよびkube-proxyサービス。ノードを調整して、不適切なノードでワークロードが実行されないようにできます。 kubeadmユーティリティは、コントロール・プレーン・ノードを自動的に調整して、このノード上で他のワークロードまたはコンテナを実行できないようにします。これは、コントロール・プレーン・ノードに不要な負荷が加わらなくなり、クラスタのコントロール・プレーン・ノードのバックアップとリストアの簡略化に役立ちます。

一定期間にわたってコントロール・プレーン・ノードが使用不能になると、クラスタ機能は一時停止しますが、ワーカー・ノードは中断することなくコンテナ・アプリケーションの実行を継続します。

単一ノード・クラスタの場合、コントロール・プレーン・ノードがオフラインの場合、APIは使用できないため、環境はノードの障害に対応できず、新しいリソースの作成や既存のリソースの編集や移動などの新しい操作は実行できません。

多くのコントロール・プレーン・ノードを備えた高可用性クラスタにより、コントロール・プレーン・ノード機能に対するより多くのリクエストを処理でき、コントロール・プレーン・レプリカ・ノードを利用することで稼働時間が改善されます。

コントロール・プレーンのレプリカ・ノード

コントロール・プレーンのレプリカ・ノードは、高可用性用に構成されたKubernetesクラスタ内のコントロール・プレーン・ノードに含まれる機能およびデータを複製する役割を果たします。稼働時間と回復力の向上を利用するために、異なるゾーンでコントロール・プレーン・レプリカ・ノードをホストし、Kubernetesクラスタのロード・バランシングを行うように構成できます。

レプリカ・ノードは、コントロール・プレーン・ノードの構成と現在のクラスタ状態をリアルタイムでミラー化するように設計されており、コントロール・プレーン・ノードが使用できなくなった場合、Kubernetesクラスタは必要なときに自動的にレプリカ・ノードにフェイルオーバーできます。コントロール・プレーン・ノードに障害が発生しても、APIは引き続き使用可能であり、クラスタは他のノードの障害に自動的に応答でき、クラスタ内の既存のリソースの作成および編集に対して通常の操作を実行できます。

ワーカー・ノード

Kubernetesクラスタ内のワーカー・ノードは、コンテナ化されたアプリケーションを実行し、ネットワークを処理して、クラスタ全体およびクラスタ外部からのアプリケーション間のトラフィックが発生できるようにするために使用されます。ワーカー・ノードは、コントロール・プレーン・ノードで実行されるKubernetes APIによってトリガーされるアクションを実行します。

Kubernetesクラスタ内のすべてのノードで、次のサービスを実行する必要があります。

「Kubeletサービス」 (kubelet): 各ワーカー・ノードがコントロール・プレーン・ノードで実行されているAPIサーバーと通信できるようにするエージェント。このエージェントは、ポッドの要件(ボリュームのマウント、コンテナの起動、ステータスの報告など)を設定する役割もあります。
Container Runtime: コンテナを実行できる環境。このリリースでは、コンテナ・ランタイムはrunCまたはKata Containersのどちらかです。コンテナ・ランタイムの詳細は、コンテナ・ランタイムを参照してください。
「Kubeプロキシ・サービス」 (kube-proxy): ポッド・ネットワーク外部からのネットワーク・トラフィックをサービス内のポッドに透過的にプロキシできるように、ポート転送およびIPリダイレクトを処理するルールをプログラムするサービス。

いずれの場合も、これらのサービスはデーモンとしてsystemdから実行されます。

ポッド

Kubernetesでは、1つ以上のコンテナとその共有ストレージのグループである「ポッド」の概念と、これらを一緒に実行する方法に関する特定のオプションが導入されています。ポッドは、通常は同じ論理ホスト上で実行され、同じシステム・リソースへのアクセスが必要になる可能性がある、緊密に結合されたアプリケーションに使用されます。一般に、ポッド内のコンテナは同一のネットワークとメモリー領域を共有し、ストレージの共有ボリュームにアクセスできます。こうした共有リソースにより、ポッド内のコンテナは、単一の論理ホストにインストールされているようにシームレスな方法で内部的に通信できるようになります。

ポッドは、コンテナのセットとしての簡単に作成または破棄できます。これにより、デプロイメントのスケーリングを制御することでローリング更新の実行が可能になります。レプリカ・ポッドを作成または削除することで、簡単にスケール・アップまたはスケール・ダウンできます。ポッドの詳細は、アップストリームの「Kubernetesドキュメント」を参照してください。

ReplicaSet、Deployment、StatefulSetコントローラ

Kubernetesには、ポッドの設定方法およびKubernetesクラスタ内でのデプロイ方法の定義に使用できる様々なコントローラが用意されています。こうしたコントローラは、実行時のニーズに応じてポッドをグループ化することと、ポッドのレプリケーションとポッドの開始順序を定義することを目的に使用できます。

ReplicaSetを使用してレプリケートするポッドのセットを定義できます。グループ内の各ポッドの正確な構成と、それらがアクセスできるリソースを定義します。 ReplicaSetsを使用すると、アプリケーションの簡単なスケーリングおよび再スケジュールに対応できるだけでなく、アプリケーションへのローリング更新またはマルチ・トラックの更新も実行できます。 ReplicaSetsの詳細は、アップストリームの「Kubernetesドキュメント」を参照してください。

「デプロイメント」を使用して、ポッドおよびReplicaSetを管理できます。 Deploymentは、ReplicaSetに変更をロール・アウトする必要があるときに役立ちます。「デプロイメント」を使用してReplicaSetを管理することで、以前の「デプロイメント」リビジョンに簡単にロールバックできます。「デプロイメント」を使用すると、ReplicaSetの新しいリビジョンを作成し、既存のポッドを以前のReplicaSetから新しいリビジョンに移行できます。「デプロイメント」は、古い未使用のReplicaSetのクリーンアップを管理できます。デプロイメントの詳細は、アップストリームの「Kubernetesドキュメント」を参照してください。

StatefulSetを使用して、起動順序および一意の識別子を保証するポッドを作成できます。このポッドは、ポッドがStatefulSetのライフサイクル全体にわたってアイデンティティを維持するために使用されます。この機能により、一般的な永続コンポーネント(ストレージやネットワーキング)が保証されるため、Kubernetes内でステートフル・アプリケーションを実行できるようになります。さらに、ポッドの作成時に、ポッドは常に同じ順序で作成され、ホスト名と内部クラスタDNSに適用される識別子が割り当てられます。これらの識別子により、安定した予測可能なネットワーク・アイデンティティが、環境内のポッドに対して保証されます。 StatefulSetsの詳細は、アップストリームの「Kubernetesドキュメント」を参照してください。

サービス

サービスを使用すると、相互に互換可能な1つ以上のポッドへのアクセスを公開できます。ローリング更新およびスケーラビリティのためにポッドをレプリケートできるため、アプリケーションにアクセスするクライアントは、正しいアプリケーションを実行しているポッドに転送する必要があります。ポッドは、Kubernetes以外のアプリケーションへのアクセスも必要になる場合があります。どちらの場合も、実際のバックエンドが変更されたとしても、そうした機能へのアクセスを透過的にするサービスを定義できます。

一般に、サービスはポートとIPのマッピングによって構成されます。ネットワーク空間でサービスが機能する方法は、サービスの作成時のサービス・タイプによって定義します。

デフォルトのサービス・タイプはClusterIPです。このタイプは、クラスタの内部IPでサービスを公開する場合に使用できます。このオプションは、サービスをクラスタ内からのみアクセスできるようにします。したがって、このオプションを使用して、クラスタ内から相互にアクセスする必要があるアプリケーションのサービスを公開します。

多くの場合、Kubernetesクラスタ外のクライアントは、クラスタ内のサービスにアクセスする必要があります。これは、NodePortサービス・タイプを作成することで実現できます。このサービス・タイプを使用すると、すべてのワーカー・ノードで実行されるKubeプロキシ・サービスを利用して、NodePortサービスとともに自動的に作成されるClusterIPにトラフィックを再ルーティングできます。このサービスは、NodePortという静的ポートで各ノードIPに公開されます。 Kube ProxyはNodePort宛てのトラフィックをクラスタにルーティングします。そのトラフィックは、クラスタ内で実行中のポッドによって処理されます。つまり、クラスタ内でNodePortサービスが実行されている場合は、ポッドが実行されている場所に関係なく、クラスタ内の任意のノードからアクセスできます。

これらのサービスの上部に構築されているLoadBalancerサービス・タイプでは、クラウド・プロバイダのロード・バランサを使用することで外部にサービスを公開することが可能になります。外部ロード・バランサは、クラスタ内のポッドへのトラフィックのKube Proxyからの直接リダイレクトを処理できます。 NodePortサービスとClusterIPサービスは、LoadBalancerサービスの設定時に自動的に作成されます。

重要:

異なるポッドにサービスを追加するときには、サービス宣言のたびに、トラフィックがフローすることを許可するようにネットワークが構成されていることを確認してください。 NodePortサービスまたはLoadBalancerサービスを作成する場合は、公開されるポートも所定のファイアウォールを通過してアクセスできる必要があります。

いずれかのノードでfirewalldを実行している場合は、作成したサービスの外部接続ポートのトラフィックを許可するルールを追加してください。

サービスの詳細は、アップストリームの「Kubernetesドキュメント」を参照してください。

ボリューム

Kubernetesでは、ボリュームとは、ポッドの存続中にポッド内のコンテナ全体に永続するストレージのことです。ポッド内のコンテナが再起動されたときにも、Kubernetesボリューム内のデータは保持されます。さらに、Kubernetesボリュームはポッド内のコンテナ間で共有できるため、異なるコンテナがローカルにアクセスできるファイル・ストアを提供することになります。

Kubernetesは、データの格納方法と永続化方法を定義する様々なボリューム・タイプを提供します。これらの詳細は、アップストリームの「Kubernetesドキュメント」を参照してください。

Kubernetesボリュームは、通常、ポッドの存続期間と一致する存続期間を持ち、ボリューム内のデータは、そのボリュームを使用するポッドが存在している間は保持されます。コンテナはポッド内で再起動できますが、データは永続しています。ポッドが破棄されると、通常は、それと一緒にデータも破棄されます。

場合によっては、ボリュームのライフサイクルがポッドのライフサイクルから分離されるように、さらに永続性が必要になることがあります。 Kubernetesでは、PersistentVolumeおよびPersistentVolumeClaimの概念が導入されています。 PersistentVolumeは、ポッドから独立して存在することを除き、「ボリューム」と似ています。これらは、NFSやiSCSIなどのストレージ・リソース・タイプにアクセスする方法を定義します。 PersistentVolumeClaimは、PersistentVolumeで使用可能なリソースを使用するように構成でき、PersistentVolumeClaimは、コンシューマのリソースに適用される割当ておよびアクセス・モードを指定します。作成したポッドは、PersistentVolumeClaimを使用して、適切なアクセス・モードおよびサイズ制限を適用してこれらのリソースにアクセスできます。

ボリュームの詳細、およびKubernetesアプリケーションでの永続ストレージの設定および使用の詳細は、「Oracle Cloud Infrastructure Cloud Controller Managerモジュール」および「Rookモジュール」を参照してください。

ネームスペース

Kubernetesは、ネームスペースを使用してリソースの強力な分離を実装し、維持します。ネームスペースは、実質的に同一の物理クラスタで支援される仮想クラスタとして実行されます。これは、ユース・ケースでKubernetesリソースを共有する必要がある環境内で使用することを目的としています。

Kubernetesでは、クラスタ管理と特定のKubernetesコントロールを別のユーザー固有の構成から分離するためにネームスペースを利用しています。したがって、Kubernetesシステムに固有のすべてのポッドおよびサービスは、kube-systemネームスペース内にあります。その他のネームスペースが設定されていないすべてのデプロイメントを実行するために、defaultネームスペースも作成されます。

ネームスペースの詳細は、アップストリームの「Kubernetesドキュメント」を参照してください。

CRI-Oについて

Kubernetesワーカー・ノードのデプロイ時に、CRI-Oもデプロイされます。 CRI-Oは、Open Container Initiative (OCI)準拠のランタイムを使用できるようにする、Kubernetes Container Runtime Interface (CRI)の実装です。 CRI-Oは、KubernetesのランタイムとしてDockerを使用する軽量の代替手段です。 CRI-Oを使用すると、Kubernetesは、ポッドのコンテナ・ランタイムとしてOCI準拠のランタイムを使用できます。

CRI-Oは、ポッド・ファイルの構成設定に基づいて、適切なノードにコンテナの実行を委託します。「特権」ポッドは、runCランタイム・エンジン(runc)を使用して実行でき、unprivilegedポッドはKata Containersランタイム・エンジン(kata-runtime)を使用して実行できます。コンテナが信頼できるかどうかの定義は、Kubernetesポッドまたはデプロイメント・ファイルで設定します。

コンテナ・ランタイムの設定方法の詳細は、コンテナ・ランタイムを参照してください。