ネットワーク

手順

1. openshift-install コマンドで作成される仮想プライベートクラウド (VPC) に対する SSH アクセスを可能にするセキュリティーグループを作成します。
2. インストーラーが作成したパブリックサブネットのいずれかに Amazon EC2 インスタンスを作成します。

3. パブリック IP アドレスを、作成した Amazon EC2 インスタンスに関連付けます。

   OpenShift Container Platform のインストールとは異なり、作成した Amazon EC2 インスタンスを SSH キーペアに関連付ける必要があります。これにはインターネットを OpenShift Container Platform クラスターの VPC にブリッジ接続するための SSH bastion としてのみの単純な機能しかないため、このインスタンスにどのオペレーティングシステムを選択しても問題ありません。どの Amazon Machine Image (AMI) を使用するかについては、注意が必要です。たとえば、Red Hat Enterprise Linux CoreOS (RHCOS) では、インストーラーと同様に、Ignition でキーを指定することができます。

4. Amazon EC2 インスタンスをプロビジョニングし、これに対して SSH を実行した後に、OpenShift Container Platform インストールに関連付けた SSH キーを追加する必要があります。このキーは bastion インスタンスのキーとは異なる場合がありますが、異なるキーにしなければならない訳ではありません。

   注記

   直接の SSH アクセスは、障害復旧を目的とする場合にのみ推奨されます。Kubernetes API が応答する場合、特権付き Pod を代わりに実行します。

5. oc get nodes を実行し、出力を検査し、マスターであるノードのいずれかを選択します。ホスト名は ip-10-0-1-163.ec2.internal に類似したものになります。

6. Amazon EC2 に手動でデプロイした bastion SSH ホストから、そのコントロールプレーンホストに SSH を実行します。インストール時に指定したものと同じ SSH キーを使用するようにします。

   $ ssh -i <ssh-key-path> core@<master-hostname>

1. 以下のコマンドを実行して Deployment のステータスを表示します。

   $ oc get -n openshift-network-operator deployment/network-operator

   出力例

   NAME               READY   UP-TO-DATE   AVAILABLE   AGE
   network-operator   1/1     1            1           56m

2. 以下のコマンドを実行して、Cluster Network Operator の状態を表示します。

   $ oc get clusteroperator/network

   出力例

   NAME      VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   network   4.5.4     True        False         False      50m

   以下のフィールドは、Operator のステータス (AVAILABLE、PROGRESSING、および DEGRADED) に関する情報を提供します。AVAILABLE フィールドは、Cluster Network Operator が Available ステータス条件を報告する場合に True になります。

1. oc get コマンドを使用してデプロイメントのステータスを表示します。

   $ oc get -n openshift-dns-operator deployment/dns-operator

   出力例

   NAME           READY     UP-TO-DATE   AVAILABLE   AGE
   dns-operator   1/1       1            1           23h

2. oc get コマンドを使用して DNS Operator の状態を表示します。

   $ oc get clusteroperator/dns

   出力例

   NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
   dns       4.1.0-0.11  True        False         False      92m

   AVAILABLE、PROGRESSING および DEGRADED は、Operator のステータスについての情報を提供します。AVAILABLE は、CoreDNS デーモンセットからの 1 つ以上の Pod が Available ステータス条件を報告する場合は True になります。

手順

1. oc describe コマンドを使用してデフォルトの dns を表示します。

   $ oc describe dns.operator/default

   出力例

   Name:         default
   Namespace:
   Labels:       <none>
   Annotations:  <none>
   API Version:  operator.openshift.io/v1
   Kind:         DNS
   ...
   Status:
     Cluster Domain:  cluster.local 1
     Cluster IP:      172.30.0.10 2
   ...

   1

   Cluster Domain フィールドは、完全修飾 Pod およびサービスドメイン名を作成するために使用されるベース DNS ドメインです。

   2

   クラスター IP は、Pod が名前解決のためにクエリーするアドレスです。IP は、サービス CIDR 範囲の 10 番目のアドレスで定義されます。

2. クラスターのサービス CIDR を見つけるには、oc get コマンドを使用します。

   $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'

手順

1. default という名前の DNS Operator オブジェクトを変更します。

   $ oc edit dns.operator/default

   以前のコマンドを実行した後に、Operator は Server に基づく追加のサーバー設定ブロックを使用して dns-default という名前の config map を作成して更新します。クエリーに一致するゾーンがサーバーにない場合には、名前解決はアップストリーム DNS サーバーにフォールバックします。

   DNS 転送の設定

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     servers:
     - name: example-server 1
       zones: 2
       - example.com
       forwardPlugin:
         policy: Random 3
         upstreams: 4
         - 1.1.1.1
         - 2.2.2.2:5353
     upstreamResolvers: 5
       policy: Random 6
       upstreams: 7
       - type: SystemResolvConf 8
       - type: Network
         address: 1.2.3.4 9
         port: 53 10

   1

   rfc6335 サービス名の構文に準拠する必要があります。

   2

   rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。

   3

   アップストリームリゾルバーを選択するためのポリシーを定義します。デフォルト値はRandomです。RoundRobin および Sequential の値を使用することもできます。

   4

   forwardPlugin ごとに最大 15 の upstreams が許可されます。

   5

   オプション: これを使用して、デフォルトポリシーを上書きし、デフォルトドメインで指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを指定しない場合に、DNS 名のクエリーは /etc/resolv.conf のサーバーに送信されます。

   6

   クエリー用にアップストリームサーバーが選択される順序を決定します。Random、RoundRobin、またはSequential のいずれかの値を指定できます。デフォルト値はSequentialです。

   7

   オプション: これを使用して、アップストリームリゾルバーを指定できます。

   8

   SystemResolvConfとNetworkの 2 種類のアップストリームを指定できます。SystemResolvConf で、アップストリームが /etc/resolv.conf を使用するように設定して、Network で Networkresolver を定義します。1 つまたは両方を指定できます。

   9

   指定したタイプがNetworkの場合には、IP アドレスを指定する必要があります。address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。

   10

   指定したタイプが Network の場合、必要に応じてポートを指定できます。port フィールドの値は 1 〜 65535 である必要があります。アップストリームのポートを指定しない場合、デフォルトでポート 853 が試行されます。

2. 任意: 高度に規制された環境で作業する場合は、要求をアップストリームリゾルバーに転送する際に DNS トラフィックのセキュリティーを確保して、追加の DNS トラフィックおよびデータのプライバシーを確保できるようにする必要がある場合があります。クラスター管理者は、転送された DNS クエリーに Transport Layer Security (TLS) を設定できるようになりました。

   TLS を使用した DNS 転送の設定

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     servers:
     - name: example-server 1
       zones: 2
       - example.com
       forwardPlugin:
         transportConfig:
           transport: TLS 3
           tls:
             caBundle:
               name: mycacert
             serverName: dnstls.example.com  4
         policy: Random 5
         upstreams: 6
         - 1.1.1.1
         - 2.2.2.2:5353
     upstreamResolvers: 7
       transportConfig:
         transport: TLS
         tls:
           caBundle:
             name: mycacert
           serverName: dnstls.example.com
       upstreams:
       - type: Network 8
         address: 1.2.3.4 9
         port: 53 10

   1

   rfc6335 サービス名の構文に準拠する必要があります。

   2

   rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。クラスタードメインの cluster.local は、zones の無効な subdomain です。

   3

   転送された DNS クエリーの TLS を設定する場合、transport フィールドの値を TLS に設定します。デフォルトでは、CoreDNS は転送された接続を 10 秒間キャッシュします。要求が発行されない場合、CoreDNS はその 10 秒間、TCP 接続を開いたままにします。大規模なクラスターでは、ノードごとに接続を開始できるため、DNS サーバーが多くの新しい接続を開いたまま保持する可能性があることを認識しているか確認してください。パフォーマンスの問題を回避するために、それに応じて DNS 階層を設定します。

   4

   転送された DNS クエリー用に TLS を設定する場合、これは、アップストリーム TLS サーバー証明書を検証するための Server Name Indication (SNI) の一部として使用される必須のサーバー名です。

   5

   アップストリームリゾルバーを選択するためのポリシーを定義します。デフォルト値はRandomです。RoundRobin および Sequential の値を使用することもできます。

   6

   必須。これを使用して、アップストリームリゾルバーを指定できます。forwardPlugin エントリーごとに最大 15 の upstreams エントリーが許可されます。

   7

   オプション: これを使用して、デフォルトポリシーを上書きし、デフォルトドメインで指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを指定しない場合に、DNS 名のクエリーは /etc/resolv.conf のサーバーに送信されます。

   8

   Network タイプは、このアップストリームリゾルバーが /etc/resolv.conf にリストされているアップストリームリゾルバーとは別に転送されたリクエストを処理する必要があることを示します。TLS を使用する場合、Network タイプのみが許可され、IP アドレスを指定する必要があります。

   9

   address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。

   10

   オプションでポートを指定できます。port の値は 1 〜 65535 である必要があります。アップストリームのポートを指定しない場合、デフォルトでポート 853 が試行されます。

   注記

   servers が定義されていないか無効な場合、config map にはデフォルトサーバーのみが含まれます。

検証

1. config map を表示します。

   $ oc get configmap/dns-default -n openshift-dns -o yaml

   以前のサンプル DNS に基づく DNS ConfigMap の例

   apiVersion: v1
   data:
     Corefile: |
       example.com:5353 {
           forward . 1.1.1.1 2.2.2.2:5353
       }
       bar.com:5353 example.com:5353 {
           forward . 3.3.3.3 4.4.4.4:5454 1
       }
       .:5353 {
           errors
           health
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods insecure
               upstream
               fallthrough in-addr.arpa ip6.arpa
           }
           prometheus :9153
           forward . /etc/resolv.conf 1.2.3.4:53 {
               policy Random
           }
           cache 30
           reload
       }
   kind: ConfigMap
   metadata:
     labels:
       dns.operator.openshift.io/owning-dns: default
     name: dns-default
     namespace: openshift-dns

   1

   forwardPlugin への変更により、CoreDNS デーモンセットのローリング更新がトリガーされます。

手順

1. 次のコマンドを実行して、default という名前の DNS Operator オブジェクトを編集します。

   $ oc edit dns.operator.openshift.io/default

2. Time-to-Live (TTL) キャッシュ値を変更します。

   DNS キャッシングの設定

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     cache:
       positiveTTL: 1h 1
       negativeTTL: 0.5h10m 2

   1

   文字列値 1h は、CoreDNS によってそれぞれの秒数に変換されます。このフィールドを省略した場合、値は 0 と見なされ、クラスターはフォールバックとして内部デフォルト値の 900 を使用します。

   2

   文字列値は、0.5h10m などの単位の組み合わせにすることができ、CoreDNS によってそれぞれの秒数に変換されます。このフィールドを省略した場合、値は 0 と見なされ、クラスターはフォールバックとして内部デフォルト値の 30 を使用します。

   警告

   TTL フィールドを低い値に設定すると、クラスター、上流のリゾルバー、またはその両方の負荷が増加する可能性があります。

手順

1. カスタム IngressController オブジェクトを定義する YAML ファイルを作成します。

   custom-ingress-controller.yaml ファイルの例

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
       name: <custom_name> 1
       namespace: openshift-ingress-operator
   spec:
       defaultCertificate:
           name: <custom-ingress-custom-certs> 2
       replicas: 1 3
       domain: <custom_domain> 4

   1

   IngressController オブジェクトのカスタム 名 を指定します。

   2

   カスタムワイルドカード証明書でシークレットの名前を指定します。

   3

   最小レプリカは ONE である必要があります

   4

   ドメイン名のドメインを指定します。IngressController オブジェクトで指定されるドメインと、証明書に使用されるドメインが一致する必要があります。たとえば、ドメイン値が "custom_domain.mycompany.com" の場合、証明書には SAN *.custom_domain.mycompany.com が必要です (*. がドメインに追加されます)。

2. 以下のコマンドを実行してオブジェクトを作成します。

   $ oc create -f custom-ingress-controller.yaml

1. ingressnodefirewallconfig という名前の openshift-ingress-node-firewall namespace 内に IngressNodeFirewallConfig を作成します。

2. 次のコマンドを実行して、Ingress Node Firewall Operator ルールをデプロイします。

   $ oc apply -f rule.yaml

手順

1. 次のコマンドを実行して、現在のルールをすべて表示します。

   $ oc get ingressnodefirewall

2. 返された <resource> 名のいずれかを選択し、次のコマンドを実行してルールまたは設定を表示します。

   $ oc get <resource> <name> -o yaml

手順

1. 以下を含む sample-ingress.yaml という名前のカスタムリソース (CR) ファイルを作成します。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: <name> 1
   spec:
     domain: <domain> 2
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: External 3
         dnsManagementPolicy: Unmanaged 4

   1

   IngressController オブジェクトの名前で <name> を指定します。

   2

   前提として作成した DNS レコードをもとに domain を指定します。

   3

   scope を External として指定して、ロードバランサーを外部に公開します。

   4

   dnsManagementPolicy は、Ingress Controller がロードバランサーに関連付けられたワイルドカード DNS レコードのライフサイクルを管理しているかどうかを示します。有効な値は Managed および Unmanaged です。デフォルト値は Managed です。

2. 変更を適用するためにファイルを保存します。

   oc apply -f <name>.yaml 1

手順

1. 選択した IngressController を変更して dnsManagementPolicy を設定します。

   SCOPE=$(oc -n openshift-ingress-operator get ingresscontroller <name> -o=jsonpath="{.status.endpointPublishingStrategy.loadBalancer.scope}")
   
   oc -n openshift-ingress-operator patch ingresscontrollers/<name> --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"dnsManagementPolicy":"Unmanaged", "scope":"${SCOPE}"}}}}'

2. オプション: クラウドプロバイダーで関連付けられている DNS レコードを削除できます。

手順

1. 現在の PodNetworkConnectivityCheck オブジェクトをリスト表示するには、以下のコマンドを入力します。

   $ oc get podnetworkconnectivitycheck -n openshift-network-diagnostics

   出力例

   NAME                                                                                                                                AGE
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0   75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1   73m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2   75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-service-cluster                               75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-default-service-cluster                                 75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-external                                         75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-load-balancer-api-internal                                         75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-0            75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-1            75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-master-2            75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh      74m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-c-n8mbf      74m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-ci-ln-x5sv9rb-f76d1-4rzrp-worker-d-4hnrz      74m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-network-check-target-service-cluster                               75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0    75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-1    75m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-2    74m
   network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-openshift-apiserver-service-cluster                                75m

2. 接続テストログを表示します。

   1. 直前のコマンドの出力から、接続ログを確認するエンドポイントを特定します。

   2. オブジェクトを表示するには、以下のコマンドを入力します。

      $ oc get podnetworkconnectivitycheck <name> \
        -n openshift-network-diagnostics -o yaml

      ここで、<name> は PodNetworkConnectivityCheck オブジェクトの名前を指定します。

      出力例

      apiVersion: controlplane.operator.openshift.io/v1alpha1
      kind: PodNetworkConnectivityCheck
      metadata:
        name: network-check-source-ci-ln-x5sv9rb-f76d1-4rzrp-worker-b-6xdmh-to-kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0
        namespace: openshift-network-diagnostics
        ...
      spec:
        sourcePod: network-check-source-7c88f6d9f-hmg2f
        targetEndpoint: 10.0.0.4:6443
        tlsClientCert:
          name: ""
      status:
        conditions:
        - lastTransitionTime: "2021-01-13T20:11:34Z"
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnectSuccess
          status: "True"
          type: Reachable
        failures:
        - latency: 2.241775ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
            to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
            connection refused'
          reason: TCPConnectError
          success: false
          time: "2021-01-13T20:10:34Z"
        - latency: 2.582129ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
            to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
            connection refused'
          reason: TCPConnectError
          success: false
          time: "2021-01-13T20:09:34Z"
        - latency: 3.483578ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: failed
            to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443: connect:
            connection refused'
          reason: TCPConnectError
          success: false
          time: "2021-01-13T20:08:34Z"
        outages:
        - end: "2021-01-13T20:11:34Z"
          endLogs:
          - latency: 2.032018ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              tcp connection to 10.0.0.4:6443 succeeded'
            reason: TCPConnect
            success: true
            time: "2021-01-13T20:11:34Z"
          - latency: 2.241775ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:10:34Z"
          - latency: 2.582129ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:09:34Z"
          - latency: 3.483578ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:08:34Z"
          message: Connectivity restored after 2m59.999789186s
          start: "2021-01-13T20:08:34Z"
          startLogs:
          - latency: 3.483578ms
            message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0:
              failed to establish a TCP connection to 10.0.0.4:6443: dial tcp 10.0.0.4:6443:
              connect: connection refused'
            reason: TCPConnectError
            success: false
            time: "2021-01-13T20:08:34Z"
        successes:
        - latency: 2.845865ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:14:34Z"
        - latency: 2.926345ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:13:34Z"
        - latency: 2.895796ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:12:34Z"
        - latency: 2.696844ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:11:34Z"
        - latency: 1.502064ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:10:34Z"
        - latency: 1.388857ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:09:34Z"
        - latency: 1.906383ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:08:34Z"
        - latency: 2.089073ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:07:34Z"
        - latency: 2.156994ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:06:34Z"
        - latency: 1.777043ms
          message: 'kubernetes-apiserver-endpoint-ci-ln-x5sv9rb-f76d1-4rzrp-master-0: tcp
            connection to 10.0.0.4:6443 succeeded'
          reason: TCPConnect
          success: true
          time: "2021-01-13T21:05:34Z"

1. クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。

   $ oc describe network.config cluster

   出力例

   ...
   Status:
     Cluster Network:
       Cidr:               10.217.0.0/22
       Host Prefix:        23
     Cluster Network MTU:  1400
     Network Type:         OpenShiftSDN
     Service Network:
       10.217.4.0/23
   ...

2. ハードウェア MTU の設定を準備します。

   • ハードウェア MTU が DHCP で指定されている場合は、次の dnsmasq 設定などで DHCP 設定を更新します。

     dhcp-option-force=26,<mtu>

     ここでは、以下のようになります。

     <mtu>

     DHCP サーバーがアドバタイズするハードウェア MTU を指定します。

   • ハードウェア MTU が PXE を使用したカーネルコマンドラインで指定されている場合は、それに応じてその設定を更新します。

   • ハードウェア MTU が NetworkManager 接続設定で指定されている場合は、以下のステップを実行します。OpenShift Container Platform では、これは、DHCP、カーネルコマンドラインなどの方法でネットワーク設定を明示的に指定していない場合のデフォルトのアプローチです。変更なしで次の手順を機能させるには、全クラスターノードで、同じ基盤となるネットワーク設定を使用する必要があります。

     1. プライマリーネットワークインターフェイスを見つけます。

        • OpenShift SDN ネットワークプラグインを使用している場合は、次のコマンドを入力します。

          $ oc debug node/<node_name> -- chroot /host ip route list match 0.0.0.0/0 | awk '{print $5 }'

          ここでは、以下のようになります。

          <node_name>

          クラスター内のノードの名前を指定します。

        • OVN-Kubernetes ネットワークプラグインを使用している場合は、次のコマンドを入力します。

          $ oc debug node/<node_name> -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0

          ここでは、以下のようになります。

          <node_name>

          クラスター内のノードの名前を指定します。

     2. <interface>-mtu.conf ファイルに次の NetworkManager 設定を作成します。

        NetworkManager 接続設定の例

        [connection-<interface>-mtu]
        match-device=interface-name:<interface>
        ethernet.mtu=<mtu>

        ここでは、以下のようになります。

        <mtu>

        新しいハードウェア MTU 値を指定します。

        <interface>

        プライマリーネットワークインターフェイス名を指定します。

     3. 1 つはコントロールプレーンノード用、もう 1 つはクラスター内のワーカーノード用に、2 つのMachineConfigオブジェクトを作成します。

        1. control-plane-interface.bu ファイルに次の Butane 設定を作成します。

           variant: openshift
           version: 4.14.0
           metadata:
             name: 01-control-plane-interface
             labels:
               machineconfiguration.openshift.io/role: master
           storage:
             files:
               - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf 1
                 contents:
                   local: <interface>-mtu.conf 2
                 mode: 0600

           1 1

           プライマリーネットワークインターフェイスの NetworkManager 接続名を指定します。

           2

           前の手順で更新された NetworkManager 設定ファイルのローカルファイル名を指定します。

        2. worker-interface.bu ファイルに次の Butane 設定を作成します。

           variant: openshift
           version: 4.14.0
           metadata:
             name: 01-worker-interface
             labels:
               machineconfiguration.openshift.io/role: worker
           storage:
             files:
               - path: /etc/NetworkManager/conf.d/99-<interface>-mtu.conf 1
                 contents:
                   local: <interface>-mtu.conf 2
                 mode: 0600

           1

           プライマリーネットワークインターフェイスの NetworkManager 接続名を指定します。

           2

           前の手順で更新された NetworkManager 設定ファイルのローカルファイル名を指定します。

        3. 次のコマンドを実行して、Butane 設定から MachineConfig オブジェクトを作成します。

           $ for manifest in control-plane-interface worker-interface; do
               butane --files-dir . $manifest.bu > $manifest.yaml
             done

           警告

           これらのマシン設定は、後で明示的に指示されるまで適用しないでください。これらのマシン設定を適用すると、クラスターの安定性が失われます。

3. MTU 移行を開始するには、次のコマンドを入力して移行設定を指定します。Machine Config Operator は、MTU の変更に備えて、クラスター内のノードをローリングリブートします。

   $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
     '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'

   ここでは、以下のようになります。

   <overlay_from>

   現在のクラスターネットワークの MTU 値を指定します。

   <overlay_to>

   クラスターネットワークのターゲット MTU を指定します。この値は、 <machine_to>の値を基準にして設定され、それぞれ、OVN-Kubernetes の場合は100 を、OpenShift SDN の場合は50 を引いた値に指定します。

   <machine_to>

   基盤となるホストネットワークのプライマリーネットワークインターフェイスの MTU を指定します。

   クラスター MTU を増やす例

   $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
     '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'

4. MCO がそれぞれのマシン設定プールのマシンを更新すると、各ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

   $ oc get mcp

   正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。

   注記

   デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。

5. ホスト上の新規マシン設定のステータスを確認します。

   1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。

      $ oc describe node | egrep "hostname|machineconfig"

      出力例

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

      以下のステートメントが true であることを確認します。

      • machineconfiguration.openshift.io/state フィールドの値は Done です。
      • machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。

   2. マシン設定が正しいことを確認するには、以下のコマンドを入力します。

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart

      ここで、<config_name> は machineconfiguration.openshift.io/currentConfig フィールドのマシン設定の名前になります。

      マシン設定には、systemd 設定に以下の更新を含める必要があります。

      ExecStart=/usr/local/bin/mtu-migration.sh

6. 基盤となるネットワークインターフェイスの MTU 値を更新します。

   • NetworkManager 接続設定で新しい MTU を指定する場合は、次のコマンドを入力します。MachineConfig Operator は、クラスター内のノードのローリングリブートを自動的に実行します。

     $ for manifest in control-plane-interface worker-interface; do
         oc create -f $manifest.yaml
       done

   • DHCP サーバーオプションまたはカーネルコマンドラインと PXE を使用して新しい MTU を指定する場合は、インフラストラクチャーに必要な変更を加えます。

7. MCO がそれぞれのマシン設定プールのマシンを更新すると、各ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

   $ oc get mcp

   正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。

   注記

   デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。

8. ホスト上の新規マシン設定のステータスを確認します。

   1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。

      $ oc describe node | egrep "hostname|machineconfig"

      出力例

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

      以下のステートメントが true であることを確認します。

      • machineconfiguration.openshift.io/state フィールドの値は Done です。
      • machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。

   2. マシン設定が正しいことを確認するには、以下のコマンドを入力します。

      $ oc get machineconfig <config_name> -o yaml | grep path:

      マシン設定が正常にデプロイされた場合、前の出力には /etc/NetworkManager/conf.d/99-<interface>-mtu.conf ファイルパスと ExecStart=/usr/local/bin/mtu-migration.sh 行が含まれます。

9. MTU 移行を完了するには、次のいずれかのコマンドを入力します。

   • OVN-Kubernetes ネットワークプラグインを使用している場合:

     $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
       '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'

     ここでは、以下のようになります。

     <mtu>

     <overlay_to> で指定した新しいクラスターネットワーク MTU を指定します。

   • OpenShift SDN ネットワークプラグインを使用している場合:

     $ oc patch Network.operator.openshift.io cluster --type=merge --patch \
       '{"spec": { "migration": null, "defaultNetwork":{ "openshiftSDNConfig": { "mtu": <mtu> }}}}'

     ここでは、以下のようになります。

     <mtu>

     <overlay_to> で指定した新しいクラスターネットワーク MTU を指定します。

10. MTU の移行が完了すると、各 MCP ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

    $ oc get mcp

    正常に更新されたノードには、UPDATED=true、UPDATING=false、DEGRADED=false のステータスがあります。

1. クラスターネットワークの現在の MTU を取得するには、次のコマンドを入力します。

   $ oc describe network.config cluster

2. ノードのプライマリーネットワークインターフェイスの現在の MTU を取得します。

   1. クラスター内のノードをリスト表示するには、次のコマンドを入力します。

      $ oc get nodes

   2. ノードのプライマリーネットワークインターフェイスの現在の MTU 設定を取得するには、次のコマンドを入力します。

      $ oc debug node/<node> -- chroot /host ip address show <interface>

      ここでは、以下のようになります。

      <node>

      前のステップの出力をもとに、ノードを指定します。

      <interface>

      ノードのプライマリーネットワークインターフェイス名を指定します。

      出力例

      ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8051

手順

1. ノードのポート範囲を拡張するには、以下のコマンドを入力します。<port> を、新規の範囲内で最大のポート番号に置き換えます。

   $ oc patch network.config.openshift.io cluster --type=merge -p \
     '{
       "spec":
         { "serviceNodePortRange": "30000-<port>" }
     }'

   ヒント

   または、以下の YAML を適用してノードのポート範囲を更新することもできます。

   apiVersion: config.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     serviceNodePortRange: "30000-<port>"

   出力例

   network.config.openshift.io/cluster patched

2. 設定がアクティブであることを確認するには、以下のコマンドを入力します。更新が適用されるまでに数分の時間がかかることがあります。

   $ oc get configmaps -n openshift-kube-apiserver config \
     -o jsonpath="{.data['config\.yaml']}" | \
     grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'

   出力例

   "service-node-port-range":["30000-33000"]

手順

1. クラスターのクラスターネットワーク範囲とホスト接頭辞を取得するには、次のコマンドを入力します。

   $ oc get network.operator.openshift.io \
     -o jsonpath="{.items[0].spec.clusterNetwork}"

   出力例

   [{"cidr":"10.217.0.0/22","hostPrefix":23}]

2. クラスターネットワークの IP アドレス範囲を拡張するには、次のコマンドを入力します。前のコマンドの出力から返された CIDR IP アドレス範囲とホスト接頭辞を使用します。

   $ oc patch Network.config.openshift.io cluster --type='merge' --patch \
     '{
       "spec":{
         "clusterNetwork": [ {"cidr":"<network>/<cidr>","hostPrefix":<prefix>} ],
         "networkType": "OVNKubernetes"
       }
     }'

   ここでは、以下のようになります。

   <network>

   前の手順で取得した cidr フィールドのネットワーク部分を指定します。この値は変更できません。

   <cidr>

   ネットワーク接頭辞長を指定します。たとえば、14 です。この値を前の手順の出力の値よりも小さい数値に変更して、クラスターネットワークの範囲を拡大します。

   <prefix>

   クラスターの現在のホスト接頭辞を指定します。この値は、前の手順で取得した hostPrefix フィールドの値と同じである必要があります。

   コマンドの例

   $ oc patch Network.config.openshift.io cluster --type='merge' --patch \
     '{
       "spec":{
         "clusterNetwork": [ {"cidr":"10.217.0.0/14","hostPrefix": 23} ],
         "networkType": "OVNKubernetes"
       }
     }'

   出力例

   network.config.openshift.io/cluster patched

3. 設定がアクティブであることを確認するには、以下のコマンドを入力します。この変更が有効になるまで、最大 30 分かかる場合があります。

   $ oc get network.operator.openshift.io \
     -o jsonpath="{.items[0].spec.clusterNetwork}"

   出力例

   [{"cidr":"10.217.0.0/14","hostPrefix":23}]