このコンテンツを正しく表示するにはJavaScriptを有効にする必要があります

このドキュメントで説明されているソフトウェアは、サポートされなくなったか、拡張サポートされています。
Oracleでは、現在サポートされているリリースにアップグレードすることをお勧めします。

第1章 Kubernetesの概要

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

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

https://kubernetes.io/

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

Kubernetesのリリース、ハードウェアとソフトウェアの要件、新機能と注目機能および既知の問題の詳細は、『リリース・ノート』を参照してください。

1.1 Kubernetesのコンポーネント

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

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

1.1.1 ノード

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

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

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

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

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

API Server (kube-apiserver): Kubernetes REST APIは、API Serverによって公開されます。このコンポーネントは、操作の処理と検証を実行し、ワーカー・ノードの操作をトリガーするためにCluster State Storeの情報を更新します。 APIはクラスタへのゲートウェイでもあります。
Cluster State Store (etcd): クラスタ状態に関連する構成データはCluster State Storeに保存されます。ここから、調整コンポーネント(Controller ManagerやSchedulerなど)に変更をロールアウトできます。このクラスタ・コンポーネントに保存されたデータに適したバックアップ計画を用意することが重要です。
Cluster Controller Manager (kube-controller-manager): このマネージャは、Cluster State StoreとAPI Serverからの入力に基づいて、多数のクラスタレベルの機能とアプリケーション管理を実行するために使用します。
Scheduler (kube-scheduler): Schedulerは、リソースの可用性、サービスの品質およびアフィニティとアンチアフィニティの指定内容を監視することで、コンテナを実行する必要のある状況の自動的な決定を処理します。

コントロール・プレーン・ノードは、通常、クラスタ内のワーカー・ノードとしても構成されます。そのため、コントロール・プレーン・ノードでは標準的なノードのサービス(kubeletサービス、コンテナ・ランタイム、kubeプロキシ・サービス)も実行されます。ワークロードが不適切なノードで実行されないように、ノードをテイント(taint)にすることが可能です。 kubeadmユーティリティは、自動的にコントロール・プレーン・ノードをテイントにして、このノードでその他のワークロードやコンテナが実行されないようにします。これは、コントロール・プレーン・ノードに不要な負荷が加わらなくなり、クラスタのコントロール・プレーン・ノードのバックアップとリストアの簡略化に役立ちます。

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

単一ノードのクラスタでは、コントロール・プレーン・ノードがオフラインになるとAPIが使用できなくなります。そのため、環境はノードの障害に対応できなくなり、新しいリソースの作成や既存のリソースの編集または削除などの新規操作を実行する手段がなくなります。

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

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

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

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

1.1.1.3 ワーカー・ノード

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

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

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

どのような場合でも、これらのサービスは相互依存するデーモンとしてsystemdから実行されます。

1.1.2 ポッド

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

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

https://kubernetes.io/docs/concepts/workloads/pods/pod/

1.1.3 ReplicaSet、Deployment、StatefulSetコントローラ

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

レプリケートする必要があるポッドのセットは、ReplicaSetで定義できます。これにより、グループ内の各ポッドに整合性のある構成を定義することと、それらのポッドがアクセスするリソースを定義することが可能になります。 ReplicaSetを使用することで、アプリケーションのスケーリングと再スケジュールが簡単になるのみでなく、アプリケーションのローリング更新やマルチトラック更新の実行も可能になります。 ReplicaSetの詳細は、次の場所にあるアップストリームのドキュメントを参照してください。

https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/

Deploymentは、ポッドとReplicaSetを管理するために使用できます。 Deploymentは、ReplicaSetに変更をロール・アウトする必要があるときに役立ちます。 DeploymentをReplicaSetの管理に使用することで、以前のDeploymentリビジョンに簡単にロールバックできます。 Deploymentを使用すると、ReplicaSetの新しいリビジョン作成して、既存のポッドを以前のReplicaSetから新しいリビジョンに移行できます。その後、Deploymentでは、不要になった古いReplicaSetのクリーン・アップを管理できます。 Deploymentの詳細は、次の場所にあるアップストリームのドキュメント参照してください。

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

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

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

1.1.4 サービス

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

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

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

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

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

重要

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

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

サービスの詳細は、次の場所にあるアップストリームのドキュメントを参照してください。

https://kubernetes.io/docs/concepts/services-networking/service/

1.1.5 ボリューム

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

Kubernetesは、データの保存方法と永続方法を定義する様々なボリューム・タイプをサポートしています。その詳細は、次の場所にあるアップストリームのドキュメントを参照してください。

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

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

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

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

1.1.6 ネームスペース

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

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

ネームスペースの詳細は、次の場所にあるアップストリームのドキュメントを参照してください。

https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/

1.2 CRI-Oについて

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

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

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