33 デュアルスタックに関する考慮事項と構成 #
前のセクションで示した例は、シングルスタック IPv4 管理クラスターをセットアップする方法に関するガイダンスと例を提供しています。このような管理クラスターは、ダウンストリームクラスターの動作状態とは独立しており、ダウンストリームクラスターはデプロイ後に IPv4/IPv6 シングルスタックまたはデュアルスタック構成のいずれかで動作するように個別に構成できます。ただし、管理クラスターの構成方法は、プロビジョニングフェーズで使用できる通信プロトコルに直接影響します。インバンド通信とアウト・オブ・バンド通信の両方が、管理クラスターとダウンストリームホストがサポートするプロトコルに従って行われる必要があるためです。BMC やダウンストリームの一部またはすべてで IPv6 を使用することが想定される場合は、管理クラスターのデュアルスタック設定が必要になります。
シングルスタック IPv6 管理クラスターは、現時点ではサポートされていません。
デュアルスタック機能を実現するには、Kubernetes に POD およびサービス用の IPv4 CIDR と IPv6 CIDR の両方を提供する必要があります。ただし、EIB を使用して管理クラスターイメージをビルドする前に、他のコンポーネントも特定の調整を行う必要があります。Metal3 プロビジョニングサービス (Ironic) は、インフラストラクチャや要件に応じて、さまざまな方法で構成できます。
Ironic サービスは、単一の IP アドレスではなく、システム上のすべてのインターフェースでリスン(する)ように構成できます。したがって、管理クラスターホストが関連するインターフェースに IPv4 アドレスと IPv6 アドレスの両方を割り当てられている限り、プロビジョニング中にそれらのいずれかを使用できる可能性があります。現時点では、URL 生成（他のサービス、例えば Baremetal Operator や BMC などによる消費用）にはこれらのアドレスのうち 1 つしか選択できないことに注意してください。その結果、BMC との IPv6 通信を有効にするには、IPv6 アドレスを含む BMH 定義を扱う際に、IPv6 URL を公開して渡すように Baremetal Operator に指示することができます。言い換えれば、BMC が IPv6 対応であると識別された場合、プロビジョニングは IPv6 経由でのみ実行され、それ以外の場合は IPv4 経由で実行されます。
IPv4 と IPv6 の両方に解決される単一のホスト名を Metal3 で使用することで、Ironic がバインディングと URL 作成にそれらのアドレスを使用できるようにすることができます。このアプローチにより、構成が容易になり、柔軟な動作が可能になります（各プロビジョニングステップで IPv4 と IPv6 の両方が有効なままになります）が、既存の DNS サーバー、IP 割り当て、およびレコードがすでに配置されているインフラストラクチャが必要になります。
いずれの場合も、Kubernetes は IPv4 と IPv6 の両方に使用する CIDR を認識する必要があるため、EIB ディレクトリ内の`kubernetes/config/server.yaml`に以下の行を追加します。その際、IPv4 を先に記述するようにしてください。
service-cidr: 10.96.0.0/12,fd12:4567:789c::/112
cluster-cidr: 193.168.0.0/18,fd12:4567:789b::/48一部のコンテナはホストネットワークを利用するため、`network`ディレクトリ配下のホストのネットワーク設定を変更し、IPv6接続を有効にします。
routes:
config:
- destination: 0.0.0.0/0
next-hop-address: ${MGMT_GATEWAY_V4}
next-hop-interface: eth0
- destination: ::/0
next-hop-address: ${MGMT_GATEWAY_V6}
next-hop-interface: eth0
dns-resolver:
config:
server:
- ${MGMT_DNS}
- 8.8.8.8
- 2001:4860:4860::8888
interfaces:
- name: eth0
type: ethernet
state: up
mac-address: ${MGMT_MAC}
ipv4:
address:
- ip: ${MGMT_CLUSTER_IP_V4}
prefix-length: 24
dhcp: false
enabled: true
ipv6:
address:
- ip: ${MGMT_CLUSTER_IP_V6}
prefix-length: 128
dhcp: false
autoconf: false
enabled: trueプレースホルダーを、ゲートウェイのIPアドレス、追加のDNSサーバー（必要な場合）、ネットワークインタフェースのMACアドレス、および管理クラスターのIPアドレスに置き換えてください。アドレスの自動設定を使用する場合は、以下の抜粋を参照し、`${MGMT_MAC}`変数を設定してください。
interfaces:
- name: eth0
type: ethernet
state: up
mac-address: ${MGMT_MAC}
ipv4:
enabled: true
dhcp: true
ipv6:
enabled: false
dhcp: true
autoconf: true次に、最初のオプションから始めて、シングルノード構成の残りのファイルを定義します。`kubernetes/helm/values/metal3.yaml`を以下のように作成してください。
global:
ironicIP: ${MGMT_CLUSTER_IP_V4}
enable_vmedia_tls: false
# trustedCAs: tls-ca-bundle # Optional: Uncomment and set to ConfigMap name for trusted CA bundle
metal3-ironic:
global:
predictableNicNames: true
listenOnAll: true
persistence:
ironic:
size: "5Gi"
service:
type: NodePort
metal3-baremetal-operator:
baremetaloperator:
externalHttpIPv6: ${MGMT_CLUSTER_IP_V6}さらに、`kubernetes/helm/values/rancher.yaml`を以下のように作成します。
hostname: rancher-${MGMT_CLUSTER_IP_V4}.sslip.io
bootstrapPassword: "foobar"
replicas: 1
global:
cattle:
systemDefaultRegistry: "registry.rancher.com"ここで、${MGMT_CLUSTER_IP_V4}`と${MGMT_CLUSTER_IP_V6}`は、以前にホストに割り当てられたIPアドレスです。
あるいは、IPアドレスの代わりにホスト名を使用する場合は、`kubernetes/helm/values/metal3.yaml`を以下のように変更します。
global:
provisioningHostname: `${MGMT_CLUSTER_HOSTNAME}`
enable_vmedia_tls: false
# trustedCAs: tls-ca-bundle # Optional: Uncomment and set to ConfigMap name for trusted CA bundle
metal3-ironic:
global:
predictableNicNames: true
persistence:
ironic:
size: "5Gi"
service:
type: NodePortさらに、`kubernetes/helm/values/rancher.yaml`を以下のように変更します。
hostname: rancher-${MGMT_CLUSTER_HOSTNAME}.sslip.io
bootstrapPassword: "foobar"
replicas: 1
global:
cattle:
systemDefaultRegistry: "registry.rancher.com"ここで、`${MGMT_CLUSTER_HOSTNAME}`にはホストのIPアドレスに解決される完全修飾ドメイン名を指定する必要があります。
詳細については、 SUSE Telco Cloud GitHubリポジトリの「dual-stack」フォルダを参照してください。そこにディレクトリ構造の例が記載されています。