このドキュメントで説明されているソフトウェアは、サポートされなくなったか、拡張サポートされています。
Oracleでは、現在サポートされているリリースにアップグレードすることをお勧めします。
第2章 Oracle Cloud Native Environmentの前提条件
この章では、Oracle Cloud Native Environmentのインストールで使用するシステムの前提条件について説明します。 この章では、リポジトリでOracle Cloud Native Environmentパッケージをインストールできるようにする方法についても説明します。
2.1 Oracle Cloud Native Environmentパッケージへのアクセスの有効化
この項では、Oracle Cloud Native Environmentソフトウェア・パッケージをインストールするオペレーティング・システムのロケーションの設定について説明します。
2.1.1 Oracle Linux 8
Oracle Linux 8のOracle Cloud Native Environmentパッケージは、Oracle Linux yumサーバーのol8_olcne14
リポジトリ、またはol8_x86_64_olcne14
チャネルのUnbreakable Linux Network (ULN)で入手できます。 ただし、他のリポジトリおよびチャネルには依存関係があり、Oracle Cloud Native Environmentがインストールされている各システムでこれらの依存性も有効化する必要があります。
Oracleは、ol8_developer
またはol8_developer_EPEL
yumリポジトリまたはULNチャネルが有効化されているシステム、またはそれらのリポジトリやチャネルからのソフトウェアがKubernetesを実行しているシステムに現在インストールされているシステムでは、Kubernetesをサポートしていません。 このドキュメントの手順に従っていたとしても、該当するリポジトリまたはチャネルを有効化している場合や、該当するチャネルまたはリポジトリからのソフトウェアをシステムにインストールしている場合は、そのプラットフォームがサポートされない状態になります。
2.1.1.1 ULNによるチャネルの有効化
ULNの使用を登録している場合は、ULN Webインタフェースを使用して、システムを適切なチャネルにサブスクライブします。
-
自分のULNユーザー名とパスワードを使用して、https://linux.oracle.comにログインします。
-
「Systems」タブで、登録されたマシンのリストからシステムの名前に対応するリンクをクリックします。
-
「System Details」ページで、「Manage Subscriptions」をクリックします。
-
「System Summary」ページで、使用可能なチャネルのリストから必要なチャネルを1つずつ選択して右矢印をクリックし、そのチャネルをサブスクライブ済チャネルのリストに移動します。
次に示すチャネルにシステムをサブスクライブします。
-
ol8_x86_64_olcne14
-
ol8_x86_64_addons
-
ol8_x86_64_baseos_latest
-
ol8_x86_64_appstream
-
ol8_x86_64_kvm_appstream
-
ol8_x86_64_UEKR6
次のチャネルをサブスクライブしていないことを確認します。
-
ol8_x86_64_olcne13
-
ol8_x86_64_olcne12
-
ol8_x86_64_developer
-
2.1.1.2 Oracle Linux Yum Serverによるリポジトリの有効化
システムの更新にOracle Linux yumサーバーを使用する場合は、必要なyumリポジトリを有効にします。
-
oracle-olcne-release-el8
リリース・パッケージをインストールして、Oracle Cloud Native Environment yumリポジトリ構成をインストールします。sudo dnf install oracle-olcne-release-el8
-
インストールするリリースのリポジトリを設定します。
次のyumリポジトリを有効にします。
-
ol8_olcne14
-
ol8_addons
-
ol8_baseos_latest
-
ol8_appstream
-
ol8_kvm_appstream
-
ol8_UEKR6
dnf config-managerツールを使用して、yumリポジトリを有効にします。
sudo dnf config-manager --enable ol8_olcne14 ol8_addons ol8_baseos_latest ol8_appstream ol8_kvm_appstream ol8_UEKR6
ol8_olcne12
、ol8_olcne13
およびol8_developer
yumリポジトリが無効になっていることを確認します:sudo dnf config-manager --disable ol8_olcne12 ol8_olcne13 ol8_developer
-
2.1.2 Oracle Linux 7
Oracle Linux 7のOracle Cloud Native Environmentパッケージは、Oracle Linux yumサーバーのol7_olcne14
リポジトリ、またはol7_x86_64_olcne14
チャネルのUnbreakable Linux Network (ULN)で入手できます。 ただし、他のリポジトリおよびチャネルには依存関係があり、Oracle Cloud Native Environmentがインストールされている各システムでこれらの依存性も有効化する必要があります。
Oracleは、yumリポジトリ(ol7_preview
、ol7_developer
またはol7_developer_EPEL
)が有効化されているシステムやULNチャネルが有効化されているシステム、または、それらのリポジトリやチャネルからのソフトウェアがKubernetesを実行するシステムに現時点でインストールされているシステムではKubernetesをサポートしていません。 このドキュメントの手順に従っていたとしても、該当するリポジトリまたはチャネルを有効化している場合や、該当するチャネルまたはリポジトリからのソフトウェアをシステムにインストールしている場合は、そのプラットフォームがサポートされない状態になります。
2.1.2.1 ULNによるチャネルの有効化
ULNの使用を登録している場合は、ULN Webインタフェースを使用して、システムを適切なチャネルにサブスクライブします。
-
自分のULNユーザー名とパスワードを使用して、https://linux.oracle.comにログインします。
-
「Systems」タブで、登録されたマシンのリストからシステムの名前に対応するリンクをクリックします。
-
「System Details」ページで、「Manage Subscriptions」をクリックします。
-
「System Summary」ページで、使用可能なチャネルのリストから必要なチャネルを1つずつ選択して右矢印をクリックし、そのチャネルをサブスクライブ済チャネルのリストに移動します。
次に示すチャネルにシステムをサブスクライブします。
-
ol7_x86_64_olcne14
-
ol7_x86_64_kvm_utils
-
ol7_x86_64_addons
-
ol7_x86_64_latest
-
ol7_x86_64_UEKR6
次のチャネルをサブスクライブしていないことを確認します。
-
ol7_x86_64_olcne
-
ol7_x86_64_olcne11
-
ol7_x86_64_olcne12
-
ol7_x86_64_olcne13
-
ol7_x86_64_developer
-
2.1.2.2 Oracle Linux Yum Serverによるリポジトリの有効化
システムの更新にOracle Linux yumサーバーを使用する場合は、必要なyumリポジトリを有効にします。
-
oracle-olcne-release-el7
リリース・パッケージをインストールして、Oracle Cloud Native Environment yumリポジトリ構成をインストールします。sudo yum install oracle-olcne-release-el7
-
インストールするリリースのリポジトリを設定します。
次のyumリポジトリを有効にします。
-
ol7_olcne14
-
ol7_kvm_utils
-
ol7_addons
-
ol7_latest
-
ol7_UEKR6
yum-config-managerツールを使用して、yumリポジトリを有効にします。
sudo yum-config-manager --enable ol7_olcne14 ol7_kvm_utils ol7_addons ol7_latest ol7_UEKR6
ol7_olcne
,ol7_olcne11
,ol7_olcne12
,ol7_olcne13
およびol7_developer
yumリポジトリが無効になっていることを確認します:sudo yum-config-manager --disable ol7_olcne ol7_olcne11 ol7_olcne12 ol7_olcne13 ol7_developer
-
2.2 Oracle Container Registryへのアクセス
Platform CLIでデプロイしたコンテナ・イメージは、次の場所にあるOracle Container Registryでホストされます。 Oracle Container Registryの詳細は、『Oracle® Linux: Oracle Container Runtime for Dockerユーザー・ガイド』を参照してください。
Oracle Container Registryを使用するデプロイメントの場合は、環境内の各ノードがインターネットに直接アクセスできるようにプロビジョニングされている必要があります。
必要に応じて、Oracle Container Registryミラーを使用することも、ネットワーク内に独自のプライベート・レジストリ・ミラーを作成することもできます。
Kubernetesモジュールを作成する場合は、コンテナ・イメージを取得するレジストリを指定する必要があります。 これは、olcnectl module createコマンドの--container-registry
オプションを使用して設定します。 Oracle Container Registryを使用する場合は、コンテナ・レジストリを次のように設定する必要があります。
container-registry.oracle.com/olcne
Oracle Container RegistryのOracle Cloud Native Environmentコンテナ・イメージをミラー化するプライベート・レジストリを使用する場合は、コンテナ・レジストリをプライベート・レジストリのドメイン名とポートに設定します。次に例を示します:
myregistry.example.com:5000/olcne
コンテナ・レジストリをインストール時に使用するように設定すると、Kubernetesモジュールの更新およびアップグレード時にイメージを取得するデフォルト・レジストリになります。 --container-registry
オプションを使用して、更新またはアップグレード中に新しいデフォルト値を設定できます。
2.2.1 Oracle Container Registryミラーの使用
Oracle Container Registryには、世界中に多数のミラー・サーバーがあります。 グローバル・リージョンでレジストリ・ミラーを使用すると、コンテナ・イメージのダウンロード・パフォーマンスを改善できます。 Oracle Container RegistryミラーはOracle Cloud Infrastructureでホストされますが、Oracle Cloud Infrastructureの外部からもアクセスできます。 地理的な場所に最も近いミラーを使用すると、ダウンロード速度が速くなります。
Oracle Container Registryミラーを使用してイメージを取得するには、次の形式を使用します。
container-registry-
region-key
.oracle.com/olcne
たとえば、リージョン・キーがIAD
の米国東部(アッシュバーン)リージョンでOracle Container Registryミラーを使用するには、(--container-registry
オプションを使用して)レジストリを次のように設定する必要があります。
container-registry-iad.oracle.com/olcne
Oracle Container Registryのミラー化および使用している場所でのミラーのリージョン・キーの確認の詳細は、次のOracle Cloud Infrastructureドキュメントを参照してください。
https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm
2.2.2 プライベート・レジストリの使用
場合によっては、環境内のノードがインターネットに直接アクセスできるようにプロビジョニングされていないことがあります。 このような場合、Oracle Container RegistryのOracle Cloud Native Environmentコンテナ・イメージをミラー化するプライベート・レジストリを使用できます。 このシナリオでは、それぞれのノードがミラー・レジストリ・ホストに直接アクセスできる必要があります。
ネットワークで既存のコンテナ・レジストリを使用するか、Oracle Linux 8ホストのPodmanを使用してプライベート・レジストリを作成できます。 既存のプライベート・コンテナ・レジストリを使用する場合は、レジストリを作成する次の手順の最初のステップをスキップしてください。
-
Oracle Container Registryミラー・サービスに使用するOracle Linux 8ホストを選択します。 ミラー・ホストは、インターネットにアクセスできる必要があり、Oracle Container Registryからイメージを直接取り出せるようにする必要があります。または、ローカルに保存された適切なイメージ・ファイルにアクセスできる必要があります。 理想的には、ホストはOracle Cloud Native Environment内のノードではなく、環境の一部であるすべてのノードからアクセスできる必要があります。
ミラー・ホストで、Podmanをインストールし、「Oracle® Linux: Podmanユーザー・ガイド」の「ローカル・コンテナ・レジストリの設定」セクションの指示に従ってプライベート・レジストリを設定します。
-
ミラー・ホストで、Oracle Cloud Native Environmentソフトウェア・パッケージへのアクセスを有効にします。 パッケージへのアクセスの有効化の詳細は、第2.1項、「Oracle Cloud Native Environmentパッケージへのアクセスの有効化」を参照してください。
-
olcne-utils
パッケージをインストールして、レジストリ・ミラー化ユーティリティにアクセスできるようにします。sudo dnf install olcne-utils
Oracle Linux 7で実行されているネットワークで既存のコンテナ・レジストリを使用している場合は、dnfのかわりにyumを使用して
olcne-utils
をインストールします。 -
Oracle Container Registryから必要なコンテナ・イメージをプライベート・レジストリにコピーします。この操作は、registry-image-helper.shスクリプトに次のように必要なオプションを指定して実行します。
registry-image-helper.sh --to
host.example.com:5000
/olcnehost.example.com:5000
は、プライベート・レジストリが使用可能な解決できるドメイン名とポートです。必要に応じて、
--from
オプションを使用して、イメージの取得元の代替レジストリを指定できます。 たとえば、Oracle Container Registryミラーからイメージを取得するには、次のようにします。registry-image-helper.sh \ --from container-registry-iad.oracle.com/olcne \ --to
host.example.com:5000
/olcneこのスクリプトを実行するホストがインターネットにアクセスできない場合は、
--from
オプションを--local
オプションに置き換えて、コンテナ・イメージをローカル・ディレクトリから直接ロードするようにします。 イメージを格納するローカル・ディレクトリは、次のいずれかである必要があります。-
/usr/local/share/kubeadm/
-
/usr/local/share/olcne/
イメージ・ファイルは、TAR形式でアーカイブされています。
--local
オプションを指定してスクリプトを実行すると、ディレクトリ内のすべてのTARファイルがプライベート・レジストリにロードされます。--version
オプションは、ミラーするKubernetesのバージョンを指定する場合に使用できます。 指定しない場合は、最新のリリースが使用されます。 取得可能なバージョンは、リリース・ノートにリストされているバージョンです。 -
2.3 オペレーティング・システムの設定
次の項では、Oracle Linux 8およびOracle Linux 7システムでOracle Cloud Native Environmentをインストールして構成するために満たす必要がある要件について説明します。
2.3.1 ネットワーク・タイム・サービスの設定
クラスタリング環境として、Oracle Cloud Native Environmentでは、クラスタ内の各Kubernetesコントロール・プレーンおよびワーカー・ノード間でシステム時間が同期されている必要があります。 一般に、これを実現するために、各ノードにネットワーク・タイム・プロトコル(NTP)デーモンをインストールして構成します。 この場合の用途には、chronydデーモンをインストールして設定することをお薦めします。
Oracle Linux 8システムでは、chronyd
サービスがデフォルトで有効になり、起動されます。
Oracle Cloud Infrastructureで実行されるシステムは、デフォルトでchronyd
時間サービスを使用するように構成されるため、Oracle Cloud Infrastructure環境にインストールする場合は、NTPを追加または構成する必要はありません。
-
各Kubernetesコントロール・プレーン・ノードおよびワーカー・ノードで、
chrony
パッケージをインストールします(インストールされていない場合)。sudo yum install chrony
-
/etc/chrony.conf
のNTP構成を編集します。 それぞれの要件は異なることがあります。 各ノードのネットワークを構成するためにDHCPを使用している場合は、NTPサーバーを自動的に構成することが可能です。 システムの同期に使用できるNTPサービスがローカルに構成されていない場合は、そのシステムがインターネットにアクセスできれば、パブリックのpool.ntp.org
サービスを使用するように構成できます。 https://www.ntppool.org/を参照してください。 -
Oracle Cloud Native Environmentのインストールに進む前に、NTPが起動時に再起動可能で、起動していることを確認してください。 たとえば:
sudo systemctl enable --now chronyd.service
ネットワーク・タイム・サービスの構成方法の詳細は、『Oracle® Linux 7: 管理者ガイド』を参照してください。
2.3.2 スワップの無効化
Kubernetesコントロール・プレーン・ノードおよびワーカー・ノードで、スワップを無効にする必要があります。 スワップを無効にするには、次を入力します。
sudo swapoff -a
この設定が再起動しても永続されるよう、/etc/fstab
ファイルを編集してスワップ・ディスクを削除するかコメント・アウトします。 たとえば:
sudo sed -i '/ swap /d' /etc/fstab
2.4 ネットワークの設定
この項では、Oracle Cloud Native Environmentノードのネットワーク要件について説明します。
次の表に、環境内のKubernetesのデプロイメントでサービスによって使用されるネットワーク・ポートを示します。
通信元ノード・タイプ |
通信先ノード・タイプ |
ポート |
プロトコル |
事由 |
---|---|---|---|---|
ワーカー |
オペレータ |
8091 |
TCP(6) |
Platform API Server |
コントロール・プレーン |
オペレータ |
8091 |
TCP(6) |
Platform API Server |
コントロール・プレーン |
コントロール・プレーン |
2379-2380 |
TCP(6) |
Kubernetes etcd (高可用性クラスタ) |
オペレータ |
コントロール・プレーン |
6443 |
TCP(6) |
Kubernetes APIサーバー |
ワーカー |
コントロール・プレーン |
6443 |
TCP(6) |
Kubernetes APIサーバー |
コントロール・プレーン |
コントロール・プレーン |
6443 |
TCP(6) |
Kubernetes APIサーバー |
コントロール・プレーン |
コントロール・プレーン |
6444 |
TCP(6) |
代替Kubernetes APIサーバー(高可用性クラスタ) |
オペレータ |
コントロール・プレーン |
8090 |
TCP(6) |
Platform Agent |
コントロール・プレーン |
コントロール・プレーン |
10250 10251 10252 10255 |
TCP(6) TCP(6) TCP(6) TCP(6) |
Kubernetes
Kubernetes
Kubernetes
認証なしの読取り専用アクセス用Kubernetes |
コントロール・プレーン |
コントロール・プレーン |
8472 |
UDP(11) |
Flannel |
コントロール・プレーン |
ワーカー |
8472 |
UDP(11) |
Flannel |
ワーカー |
コントロール・プレーン |
8472 |
UDP(11) |
Flannel |
ワーカー |
ワーカー |
8472 |
UDP(11) |
Flannel |
コントロール・プレーン |
コントロール・プレーン |
該当なし |
VRRP(112) |
Kubernetes APIサーバー(高可用性クラスタ)のKeepalived |
オペレータ |
ワーカー |
8090 |
TCP(6) |
Platform Agent |
コントロール・プレーン |
ワーカー |
10250 10255 |
TCP(6) TCP(6) |
Kubernetes
認証なしの読取り専用アクセス用Kubernetes |
次の各項では、各ノードでネットワークを設定して、環境内のノード間の通信を有効にする方法について説明します。
2.4.1 ファイアウォール・ルールの設定
Oracle Linux により、デフォルトでfirewalldがインストールされて有効化されます。 Platform CLIにより、Kubernetesモジュールのデプロイメント時に追加が必要になるルールが通知されます。 また、Platform CLIには、要件を満たすようにファイアウォールの構成を変更する場合に実行するコマンドも用意されています。
すべての必要なポートが開かれていることを確認してください。 Kubernetesデプロイメントに必要なポートは次のとおりです。
-
2379/tcp: Kubernetes etcdサーバー・クライアントAPI (高可用性クラスタのコントロール・プレーン・ノード)
-
2380/tcp: Kubernetes etcdサーバー・クライアントAPI (高可用性クラスタのコントロール・プレーン・ノード)
-
6443/tcp: Kubernetes APIサーバー(コントロール・プレーン・ノード)
-
8090/tcp: Platform Agent (コントロール・プレーン・ノードおよびワーカー・ノード)
-
8091/tcp: Platform API Server (オペレータ・ノード)
-
8472/udp: Flannelオーバーレイ・ネットワーク、VxLANバックエンド(コントロール・プレーン・ノードおよびワーカー・ノード)
-
10250/tcp: Kubernetes
kubelet
APIサーバー(コントロール・プレーン・ノードおよびワーカー・ノード) -
10251/tcp: Kubernetes
kube-scheduler
(高可用性クラスタのコントロール・プレーン・ノード) -
10252/tcp: Kubernetes
kube-controller-manager
(高可用性クラスタのコントロール・プレーン・ノード) -
10255/tcp: Kubernetes
kubelet
APIサーバー: 認証なしの読取り専用アクセス用(コントロール・プレーン・ノードおよびワーカー・ノード)
次に、ポートを開くコマンドとファイアウォール・ルールを設定するコマンドを示します。
2.4.1.1 非高可用性クラスタ・ファイアウォール・ルール
単一のコントロール・プレーン・ノードを備えたクラスタでは、ファイアウォールで次のポートを開く必要があります。
オペレータ・ノード
オペレータ・ノードで次を実行します。
sudo firewall-cmd --add-port=8091/tcp --permanent
該当するルールが有効になるようにファイアウォールを再起動します。
sudo systemctl restart firewalld.service
ワーカー・ノード
Kubernetesワーカー・ノードで次を実行します。
sudo firewall-cmd --zone=trusted --add-interface=cni0 --permanent sudo firewall-cmd --add-port=8090/tcp --permanent sudo firewall-cmd --add-port=10250/tcp --permanent sudo firewall-cmd --add-port=10255/tcp --permanent sudo firewall-cmd --add-port=8472/udp --permanent
該当するルールが有効になるようにファイアウォールを再起動します。
sudo systemctl restart firewalld.service
コントロール・プレーン・ノード
Kubernetesコントロール・プレーン・ノードで、次のコマンドを実行します。
sudo firewall-cmd --zone=trusted --add-interface=cni0 --permanent sudo firewall-cmd --add-port=8090/tcp --permanent sudo firewall-cmd --add-port=10250/tcp --permanent sudo firewall-cmd --add-port=10255/tcp --permanent sudo firewall-cmd --add-port=8472/udp --permanent sudo firewall-cmd --add-port=6443/tcp --permanent
該当するルールが有効になるようにファイアウォールを再起動します。
sudo systemctl restart firewalld.service
2.4.1.2 高可用性クラスタ・ファイアウォール・ルール
高可用性クラスタの場合は、第2.4.1.1項、「非HAクラスタ・ファイアウォール・ルール」の説明に従ってすべてのファイアウォール・ポートと、コントロール・プレーン・ノードの次の「追加」ポートを開きます。
Kubernetesコントロール・プレーン・ノードで、次のコマンドを実行します。
sudo firewall-cmd --add-port=10251/tcp --permanent sudo firewall-cmd --add-port=10252/tcp --permanent sudo firewall-cmd --add-port=2379/tcp --permanent sudo firewall-cmd --add-port=2380/tcp --permanent
該当するルールが有効になるようにファイアウォールを再起動します。
sudo systemctl restart firewalld.service
2.4.2 その他のネットワーク・オプションの設定
この項では、Oracle Cloud Native Environmentデプロイメントに影響するその他のネットワーク関連構成について説明します。 この項による変更は不要なことがありますが、ネットワークの構成に関連する問題が発生したときの理解を助けるために示しています。
2.4.2.1 インターネット・アクセス
Platform CLIでは、コンテナ・レジストリに(場合によっては、その他のインターネット・リソースにも)アクセスできるかどうかをチェックして、必要なコンテナ・イメージを取り出せるようにします。 コンテナ・イメージにローカル・レジストリ・ミラーを設定する場合を除き、Oracle Cloud Native Environmentをインストールするシステムは、直接インターネット・アクセスを持つか、プロキシを使用するように構成する必要があります。
2.4.2.2 Flannelネットワーク
Platform CLIによって、Kubernetesポッド間の通信に使用するネットワーク・ファブリックとしてのflannelネットワークを構成します。 このオーバーレイ・ネットワークでは、ネットワーク接続を容易にするためにVxLANを使用します。 flannelの詳細は、次の場所にあるドキュメントを参照してください。
https://github.com/coreos/flannel
デフォルトでは、Platform CLIによって、このネットワークをホストするために、10.244.0.0/16
の範囲にネットワークを作成します。 Platform CLIには、インストール時に必要に応じてネットワーク範囲を別の範囲に設定するオプションがあります。 Oracle Cloud Native Environmentデプロイメント内のシステムには、この予約済IP範囲にネットワーク・デバイスが構成されていない必要があります。
2.4.2.3 br_netfilterモジュール
Platform CLIは、br_netfilter
モジュールがロードされているかどうかを確認し、そのモジュールが使用できない場合は終了します。 このモジュールは、クラスタ全体のKubernetesポッド間の通信のために、Virtual Extensible LAN (VxLAN)トラフィックの透過的マスカレードを有効にして、このトラフィックを円滑に進めるために必要です。 このモジュールがロードされているかどうかは、次のコマンドを実行して確認します。
sudo lsmod|grep br_netfilter
br_netfilter 24576 0 bridge 155648 2 br_netfilter,ebtable_broute
これと同様の出力が示された場合は、br_netfilter
モジュールがロードされています。 通常、カーネル・モジュールは必要に応じてロードされます。ほとんどの場合、このモジュールを手動でロードする必要はありません。 次のコマンドを実行することで、モジュールを必要に応じて手動でロードして、永続モジュールとして追加できます。
sudo modprobe br_netfilter sudo sh -c 'echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf'
2.4.2.4 ブリッジの調整可能なパラメータ
Kubernetesでは、ネットワーク・ブリッジを通過するパケットが、フィルタリングおよびポート転送のために処理されている必要があります。 そうするために、kubeadm
パッケージのインストール時にカーネル・ブリッジ・モジュールの調整可能なパラメータが自動的に設定され、次の行が含まれているsysctlファイルが/etc/sysctl.d/k8s.conf
に作成されます。
net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1
このファイルを変更する場合や、同様のものを自作する場合は、次のコマンドを実行してブリッジの調整可能なパラメータをロードします。
sudo /sbin/sysctl -p /etc/sysctl.d/k8s.conf
2.4.2.5 ネットワーク・アドレス変換
クラスタ内の1つ以上のKubernetesワーカー・ノードがNATゲートウェイの背後にある場合、ネットワーク・アドレス変換(NAT)が必要になることがあります。 たとえば、セキュアな会社ネットワークにコントロール・プレーン・ノードを配置し、公的にアクセス可能な非武装地帯(安全性が低い)に他のワーカー・ノードを配置できます。 コントロール・プレーン・ノードは、ワーカー・ノードのNATゲートウェイを介してワーカー・ノードにアクセスします。 または、主に新しいネットワーク上にあるクラスタで使用するレガシー・ネットワークにワーカー・ノードがある場合があります。 これらの場合、NATゲートウェイは、Kubernetesクラスタにアクセス可能なIPアドレスのリクエストをNATゲートウェイの背後にあるサブネット上のIPアドレスに変換します。
NATの背後に配置できるのはワーカー・ノードのみです。 コントロール・プレーン・ノードはNATの背後に配置できません。
NATゲートウェイの設定に使用するスイッチまたはネットワーク機器に関係なく、NATゲートウェイの背後にあるノードに対して次のことを構成する必要があります。
-
NATゲートウェイの背後にあるノードのインタフェースには、Kubernetesクラスタから到達可能な
/32
サブネット・マスクを使用するパブリックIPアドレスが必要です。/32
サブネットは、KubernetesクラスタからのすべてのトラフィックがこのパブリックIPアドレスを通過するように、サブネットを1つのIPアドレスに制限します。 -
また、ノードのインタフェースには、NATゲートウェイの背後にプライベートIPアドレスが含まれていることも必要です。NATゲートウェイでは、スイッチはNAT表を使用してパブリックIPアドレスを照合します。
たとえば、次のコマンドを使用して、ens5
インタフェースに到達可能なIPアドレスを追加できます。
sudo ip addr add 192.168.64.6/32 dev ens5
その後、次のコマンドを使用して、プライベートIPアドレスを同じインタフェースに追加できます。
sudo ip addr add 192.168.192.2/18 dev ens5
2.5 FIPSモードの設定
オプションで、「Oracle® Linux 8: システム・セキュリティの強化」の説明に従って、Oracle Cloud Native Environmentオペレータ、コントロール・プレーンおよびワーカー・ホストを連邦情報処理標準(FIPS)モードで実行するように構成できます。 ホストがFIPSモードで実行されている場合、Oracle Cloud Native EnvironmentはOracle Linux 8からのOpenSSLの暗号化バイナリを使用します。
FIPSモードで実行されているOracle Linux 7ホストでは、Oracle Cloud Native Environmentを使用できません。