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

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

第1章 Kubernetesと使用するOracle Linux Container Servicesについて

重要

このドキュメントは非推奨です。

Oracle Linux Cloud Native Environmentを使用してKubernetesをインストールし、コンテナのオーケストレーションを容易にすることをお薦めします。

Oracle Linux Cloud Native Environmentリリース1.2のリリースでは、Kubernetesと使用するOracle Linux Container Servicesでエラー修正更新が提供されなくなります。更新を継続するために、Oracle Linux Cloud Native Environmentへの移行をお薦めします。

Oracle Linux Cloud Native Environmentは、オープン・ソースのCloud Native Computing Foundation (CNCF)プロジェクトから厳選されたセットで、簡単にデプロイでき、相互運用性がテスト済で、エンタープライズ・グレードのサポートが提供されています。Oracle Linux Cloud Native Environmentにより、オラクルは、オープン・スタンダードと仕様をサポートする環境にデプロイできるマイクロサービスベースのアプリケーションを開発するための機能をお客様に提供します詳細は、次を参照してください。

https://docs.oracle.com/en/operating-systems/olcne/

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

Kubernetesプロジェクトは、https://kubernetes.io/で維持されます。

Kubernetesと使用するOracle Linux Container ServicesはOracle Linux 7で十分にテストされ、これにはKubernetesクラスタの構成およびデプロイメントを容易にするためにオラクル社で開発された追加ツールが含まれています。

1.1 Kubernetesと使用するOracle Linux Container Servicesのリリース情報

Kubernetesと使用するOracle Linux Container Services 1.1.12は、リリース済のアップストリームとしてKubernetesバージョン1.12.5に基づいています。完全な変更ログおよびソースとバイナリへのリンクは、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.12.mdで提供されます。この項では、Oracle Linux上のKubernetesリリースの重要な機能および既知の問題について詳しく説明します。

警告

オラクル社は、ol7_preview、ol7_developerまたはol7_developer_EPEL yumリポジトリあるいはULNチャネルが有効になっているシステム、またはKubernetesが実行されるシステムにこれらのリポジトリやチャネルのソフトウェアが現在インストールされているシステムで、Kubernetesをサポートしていません。このドキュメントの指示に従っても、これらのリポジトリまたはチャネルが有効化されている場合や、これらのチャネルまたはリポジトリのソフトウェアがシステムにインストールされている場合は、プラットフォームがサポートされないことがあります。

1.1.1 新機能および重要な機能

Kubernetesと使用するOracle Linux Container Services 1.1.12

Kubernetesと使用するOracle Linux Container Servicesのこのリリースの機能は、次のとおりです。

Oracle Linux用にパッケージされたアップストリームKubernetes 1.12ソフトウェア
設定および構成のユーティリティに対する改善と更新
高可用性マルチマスター・クラスタのサポート
Kubernetesダッシュボード・ソフトウェアの更新
クラスタのバックアップおよびリストアのツールに対する改善
Oracle Cloud Infrastructureで使用する統合テスト
新しいクラスタDNSサービス

オラクル社では、kubeadmクラスタ構成ユーティリティを活用して3つのマスター・ノードを持つ高可用性クラスタを作成する、新しい設定および構成ユーティリティを提供およびテストしました。詳細は、第3章 Kubernetesと使用する高可用性Oracle Linux Container Servicesのインストールを参照してください。

オラクル社は、CoreDNSがクラスタDNSサービスとして機能するためのサポートを提供しています。CoreDNSはすべての新しいクラスタにデフォルトでインストールされ、KubeDNSのサポートは非推奨です。CoreDNSサポートには、Unbreakable Enterprise Kernelリリース5 (UEK R5)が必要であることに注意してください。以前のバージョンからアップグレードする際は、KubeDNSおよびUnbreakable Enterprise Kernelリリース4 (UEK R4)のサポートを使用できますが、この構成は非推奨となりました。今後のアップグレードでは、KubeDNSが自動的にCoreDNSに置換されるため、ホスト・プラットフォームでUEK R5を実行することが必要になります。

重要

Kubernetesと使用するOracle Linux Container Services 1.1.9からのアップグレードを容易にするために、1.10および1.11リリースのKubernetesについてパッケージを使用できます。これらのパッケージは、第2.5項「1.1.9から1.1.12へのアップグレード」で説明するアップグレード・プロセスのコンテキスト外ではサポートされていません。

サポートされていない開発者プレビュー・ビルドは、ol7_previewリポジトリでリリースされなくなりました。詳細は、付録A 開発者プレビュー・リリースを参照してください。

Kubernetesと使用するOracle Linux Container Services 1.1.9

このリリースは、Kubernetesと使用するOracle Linux Container Servicesの最初のサポート対象リリースです。このリリースは、Oracle® Linux 7ライセンス情報ユーザー・マニュアルで定義されている、適切なOracle Linuxサポート・レベルでサポートされます。

Kubernetesと使用するOracle Linux Container Servicesのこのリリースは、Oracle Linux 7でのみ使用可能であり、Oracle Container Runtime for Dockerとのみ統合されるよう設計されています。Oracle Container Runtime for Dockerの詳細は、Oracle® Linux: Oracle Container Runtime for Dockerユーザー・ガイドを参照してください。

Kubernetesと使用するOracle Linux Container Servicesのこのリリースには、次のものが含まれます。

Oracle Linux用にパッケージされたアップストリームKubernetes 1.9ソフトウェア
設定および構成のユーティリティ
Kubernetesダッシュボード・ソフトウェア
クラスタのバックアップおよびリストアのツール
Oracle Cloud Infrastructureで使用する統合テスト

オラクル社では、kubeadmクラスタ構成ユーティリティを活用する、設定および構成スクリプトを提供およびテストしました。この設定スクリプトは、Oracle Linuxでの構成および設定のプロセスを簡素化し、バックアップおよびリカバリの追加サポートを提供します。

Oracle LinuxでのKubernetesの設定および構成は、このドキュメント内で説明されている提供済のスクリプトおよびユーティリティのパラメータに制限する必要があります。

1.1.2 テクニカル・プレビュー

次の項目は、現在のリリース内のテクニカル・プレビュー機能として強調表示されています。

Oracle Cloud Infrastructure用のFlexvolumeドライバ。oci-flexvolume-driverパッケージを使用すると、Oracle Cloud Infrastructureでホストされているブロック・ストレージ・ボリュームをKubernetesクラスタに追加できます。
IPVSスイッチング。この機能により、一意の仮想IPアドレスおよびカーネルレベルのプロキシを使用して、Kubernetesクラスタでのロード・バランシングおよびファイアウォール管理を自動化できます。
テクニカル・プレビューとして使用可能なAPIサーバー関数。APIサーバーには、Kubernetesで使用可能な機能の全範囲に対応する多くの関数が含まれています。これらの詳細は、https://kubernetes.io/docs/reference/にあるアップストリームのドキュメントを参照してください。

APIについて記述されているすべての機能が、オラクル社によって完全にサポートされているわけではありません。次の項目は、テクニカル・プレビューとしてのみ使用可能です。
ワークロード
- CronJob v1beta1バッチ
- ジョブv1バッチ
- ReplicationController v1コア
検出およびロード・バランシング
- イングレスv1beta1拡張
メタデータ
- ControllerRevision v1アプリケーション
- CustomResourceDefinition v1beta1 apiextension
- LimitRange v1コア
- HorizontalPodAutoscaler v1自動スケーリング
- InitializerConfiguration v1alpha1 admissionregistration
- PodDisruptionBudget v1beta1ポリシー
- PriorityClass v1beta1スケジューリング
- PodPreset v1alpha1設定
- PodSecurityPolicy v1beta1拡張機能
クラスタ
- APIService v1 apiregistration.k8s.io
- v1コアのバインド
- CertificateSigningRequest v1beta1証明書
- LocalSubjectAccessReview v1認可
- ResourceQuota v1コア
- ロールv1 rbac
- RoleBinding v1 rbac
- SelfSubjectAccessReview v1認可
- SelfSubjectRulesReview v1認可
- SubjectAccessReview v1認可
- TokenReview v1認証
- NetworkPolicy v1拡張機能

1.1.3 既知の問題

VM 2.xシェイプを使用したOracle Cloud Infrastructureコンピュート・インスタンスでのオーバーレイ・ネットワーキングの問題。コンピュート・ノードでVM 2.xシェイプを使用するOracle Cloud Infrastructure内のコンピュート・ノードでオーバーレイ・ネットワーキングを使用するKubernetesクラスタを設定する場合、クラスタのvxlan構成で問題が発生する可能性があります。通常、この問題は、bnxt_enドライバ・モジュールでtxオフロード機能が有効になっている場合に発生します。この問題の影響を受けたノードのdmesg出力には、次のようなエラーが表示されます。
```
[  610.495450] bnxt_en 0000:00:03.0 ens3: hwrm req_type 0xa1 seq id 0x67
error 0xf
[  610.498246] bnxt_en 0000:00:03.0 ens3: hwrm_tunnel_dst_port_alloc failed.
rc:15
```
この問題は、ethtoolコマンドを使用してtxオフロード機能を無効にすることで解決できます。次に例を示します。
```
# ethtool --offload $(ip -o -4 route show to default | awk '{print $5}') tx off
```
このシェイプを使用するすべてのノードが影響を受けるわけではありません。

1.2 Kubernetesコンポーネント

Oracle LinuxでKubernetesの操作を開始すると、次の共通コンポーネントの存在に気付くことがあります。ここに示す説明は簡潔で、用語集と一般的なKubernetes環境のアーキテクチャの概要を示すことを主な目的としています。アップストリームのドキュメントは、https://kubernetes.io/docs/concepts/にあります。

1.2.1 ノード

Kubernetesノードのアーキテクチャの詳細は、次を参照してください。

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

1.2.1.1 マスター・ノード

マスター・ノードでは、クラスタ管理、およびKubernetesクラスタ内のリソースを構成して管理するために使用するAPIの提供を行います。Kubernetesマスター・ノードのコンポーネントは、専用ポッド内のコンテナのセットとしてKubernetes自体で実行されます。

マスター・ノードには、次のコンポーネントが必要です。

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

通常、マスター・ノードはクラスタ内のワーカー・ノードとしても構成されます。したがって、マスター・ノードでは、標準的なノード・サービス(kubeletサービス、コンテナ・ランタイム(この場合はDockerエンジン)およびkubeプロキシ・サービス)も実行されます。ワークロードが不適切なノードで実行されないように、ノードを汚染できることに注意してください。kubeadmユーティリティは、自動的にマスター・ノードを汚染して、このノードでその他のワークロードやコンテナが実行されないようにします。これにより、マスター・ノードに不要な負荷がかからないようにすると同時に、クラスタのマスター・ノードのバックアップとリストアを簡略化します。

一定の期間マスター・ノードが使用不可になると、クラスタ機能は一時停止されますが、ワーカー・ノードでは、コンテナ・アプリケーションの実行が中断することなく続行されます。

単一ノード・クラスタの場合、マスター・ノードがオフラインになると、APIは使用不可となります。そのため、環境はノード障害に対応できなくなり、新規リソースの作成や既存リソースの編集および移動などの新しい操作を実行する手段がなくなります。

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

1.2.1.2 マスター・レプリカ・ノード

マスター・レプリカ・ノードは、可用性が高まるように構成されたKubernetesクラスタ内のマスター・ノードに含まれる機能とデータを複製する役割を担います。稼働時間とレジリエンスの改善によるメリットを得るには、マスター・レプリカ・ノードを異なるゾーンでホストして、それらがKubernetesクラスタのロード・バランシングを行うように構成します。

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

kubeadm-ha-setupユーティリティを使用すると、すべてのマスター・ノードが相互のレプリカであるマルチマスター・クラスタを作成できます。

1.2.1.3 ワーカー・ノード

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

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

Kubeletサービス: ワーカー・ノードごとに、マスター・ノードで実行中のAPIサーバーと通信できるようにするエージェント。このエージェントでは、ポッドの要件(ボリュームのマウント、コンテナの起動、ステータスの報告など)の設定も行います。
コンテナ・ランタイム: コンテナを実行可能な環境。このリリースでは、Dockerのみがサポートされています。したがって、この場合のランタイムはDockerエンジンと同等です。
Kubeプロキシ・サービス: iptablesルールをプログラムしてポート転送およびIPリダイレクトを処理し、ポッド・ネットワークの外部からのネットワーク・トラフィックが透過的にサービス内のポッドにプロキシされるようにするサービス。

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

1.2.2 ポッド

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

ポッドは、コンテナのセットとして簡単に作成または破棄できます。これにより、デプロイメントのスケーリングを制御することで、アプリケーションの順次更新を実行できます。さらに、レプリカ・ポッドの作成や削除により、簡単にスケール・アップまたはスケール・ダウンできます。

詳細は、https://kubernetes.io/docs/concepts/workloads/pods/を参照してください。

1.2.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のライフサイクルを通じてポッドのアイデンティティを維持するために使用されます。この機能により、一般的な永続コンポーネント(記憶域やネットワーキングなど)が保証されるため、Kubernetes内でステートフル・アプリケーションを実行できます。さらに、ポッドの作成時、これらのポッドは常に同じ順序で作成され、ホスト名と内部クラスタDNSに適用される識別子が割り当てられます。これらの識別子により、安定した予測可能なネットワーク・アイデンティティが、確実に環境内のポッドに存在するようになります。

StatefulSetの詳細は、https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/を参照してください。

1.2.4 サービス

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

一般的に、サービスは、iptablesを使用して管理されるポートとIPのマッピングで構成されます。ネットワーク空間でサービスがどのように機能するかは、サービスが作成されるとき、サービス・タイプによって定義されます。

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

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

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

重要

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

Oracle Cloud Infrastructureを使用している場合は、仮想クラウド・ネットワーク(VCN)のセキュリティ・リストに、コンピュート・インスタンス接続用のイングレス・ルールを追加する必要があります。それぞれのルールで、サービスに対して公開したポートへのアクセスを許可する必要があります。

同様に、いずれかのノードでfirewalldを実行する場合は、作成するサービスの外部向けポートについて、トラフィックを許可するルールを確実に追加する必要があります。

詳細は、https://kubernetes.io/docs/concepts/services-networking/service/を参照してください。

1.2.5 ボリューム

Kubernetesにおいて、ボリュームは、ポッド自体の存続期間中、ポッド内のコンテナ全体で維持される記憶域です。ポッド内のコンテナの再起動時、Kubernetesボリューム内のデータは保持されます。さらに、Kubernetesボリュームはポッド内のコンテナ間で共有でき、異なるコンテナがローカルにアクセス可能なファイル・ストアを提供します。

Kubernetesでは、データの格納方法とその永続方法を定義する様々なボリューム・タイプがサポートされています。その詳細は、https://kubernetes.io/docs/concepts/storage/volumes/を参照してください。

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

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

PersistentVolumeの詳細は、https://kubernetes.io/docs/concepts/storage/persistent-volumes/を参照してください。PersistentVolumeの使用例も、第5.2項「YAMLデプロイメントを使用したポッド構成」および第5.3項「永続記憶域の使用方法」に記載されています。

1.2.6 名前空間

Kubernetesでは、名前空間を使用することで、リソースの強力な分離を実装および維持します。名前空間は、同じ物理クラスタでサポートされる仮想クラスタとして効率的に実行され、ユースケース全体にわたりKubernetesリソースを共有する必要がある環境内で使用することを目的としています。

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

名前空間の詳細は、https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/を参照してください。