ネットワーク設定

手順

1. 次の内容を含む、tuning-example.yaml などのネットワークアタッチメント定義を作成します。

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: <name>
     namespace: default
   spec:
     config: '{
       "cniVersion": "0.4.0",
       "name": "<name>",
       "plugins": [{
          "type": "<main_CNI_plugin>"
         },
         {
          "type": "tuning",
          "sysctl": {
               "net.ipv4.conf.IFNAME.accept_redirects": "1"
           }
         }
        ]
   }

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

   metadata.name

   作成する追加のネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。

   metadata.namespace

   オブジェクトが関連付けられている namespace を指定します。

   spec.config.cniVersion

   CNI 仕様のバージョンを指定します。

   spec.config.name

   設定の名前を指定します。設定名をネットワークアタッチメント定義の名前の値と一致させることを推奨します。

   spec.config.plugins.type

   設定するメイン CNI プラグインの名前を指定します。

   spec.config.plugins.tuning.sysctl

   設定する sysctl を指定します。インターフェイス名は IFNAME トークンで表され、ランタイム時にインターフェイスの実際の名前に置き換えられます。

   ネットワーク接続定義の例

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: tuningnad
     namespace: default
   spec:
     config: '{
       "cniVersion": "0.4.0",
       "name": "tuningnad",
       "plugins": [{
         "type": "bridge"
         },
         {
         "type": "tuning",
         "sysctl": {
            "net.ipv4.conf.IFNAME.accept_redirects": "1"
           }
       }
     ]
   }'

2. 以下のコマンドを実行して YAML を適用します。

   $ oc apply -f tuning-example.yaml

   出力例

   networkattachmentdefinition.k8.cni.cncf.io/tuningnad created

3. 次のようなネットワークアタッチメント定義を使用して、examplepod.yaml などの Pod を作成します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: tunepod
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/networks: tuningnad
   spec:
     containers:
     - name: podexample
       image: centos
       command: ["/bin/bash", "-c", "sleep INF"]
       securityContext:
         runAsUser: 2000
         runAsGroup: 3000
         allowPrivilegeEscalation: false
         capabilities:
           drop: ["ALL"]
     securityContext:
       runAsNonRoot: true
       seccompProfile:
         type: RuntimeDefault

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

   metadata.annotations.k8s.v1.cni.cncf.io/networks

   設定された NetworkAttachmentDefinition の名前を指定します。

   spec.containers.securityContext.runAsUser

   コンテナーを実行するユーザー ID を指定します。

   spec.containers.securityContext.runAsGroup

   コンテナーの実行に使用するプライマリーグループ ID を指定します。

   spec.containers.securityContext.allowPrivilegeEscalation

   Pod が特権昇格を許可するよう要求できるかどうかを指定します。指定しない場合、デフォルトで true に設定されます。このブール値は、no_new_privs フラグがコンテナープロセスに設定されるかどうかを直接制御します。

   spec.containers.securityContext.capabilities

   完全なルートアクセス権限を与えずに、特権的な操作を指定します。このポリシーにより、すべての機能が Pod から削除されます。

   spec.securityContext.runAsNonRoot: true

   UID が 0 以外のユーザーでコンテナーが実行されるように指定します。

   spec.securityContext.seccompProfile

   Pod またはコンテナーワークロードのデフォルトの seccomp プロファイルを指定します。

4. 以下のコマンドを実行して yaml を適用します。

   $ oc apply -f examplepod.yaml

5. 次のコマンドを実行して、Pod が作成されていることを確認します。

   $ oc get pod

   出力例

   NAME      READY   STATUS    RESTARTS   AGE
   tunepod   1/1     Running   0          47s

6. 次のコマンドを実行して、Pod にログインします。

   $ oc rsh tunepod

7. 設定された sysctl フラグの値を確認します。たとえば、次のコマンドを実行して、値 net.ipv4.conf.net1.accept_redirects を見つけます。

   sh-4.4# sysctl net.ipv4.conf.net1.accept_redirects

   予想される出力

   net.ipv4.conf.net1.accept_redirects = 1

手順

1. 次の内容を含む、tuning-example.yaml などのネットワークアタッチメント定義を作成します。

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: <name>
     namespace: default
   spec:
     config: '{
       "cniVersion": "0.4.0",
       "name": "<name>",
       "plugins": [{
          "type": "<main_CNI_plugin>"
         },
         {
          "type": "tuning",
          "allmulti": true
           }
         }
        ]
   }

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

   <name>

   作成する追加のネットワーク割り当ての名前を指定します。名前は指定された namespace 内で一意である必要があります。

   default

   オブジェクトが関連付けられている namespace を指定します。

   0.4.0

   CNI 仕様のバージョンを指定します。

   < 名前 >

   設定の名前を指定します。設定の名前は、ネットワークアタッチメント定義の名前の値と一致させてください。

   "<main_CNI_plugin>"

   設定するメイン CNI プラグインの名前を指定します。

   " チューニング "

   CNI メタプラグインの名前を指定します。

   " 真実 "

   インターフェイスのオールマルチキャストモードを指定します。有効にすると、ネットワーク上のすべてのマルチキャストパケットがそのインターフェイスで受信されます。

   ネットワーク接続定義の例

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: setallmulti
     namespace: default
   spec:
     config: '{
       "cniVersion": "0.4.0",
       "name": "setallmulti",
       "plugins": [
         {
           "type": "bridge"
         },
         {
           "type": "tuning",
           "allmulti": true
         }
       ]
     }'

2. 次のコマンドを実行して、YAML ファイルで指定された設定を適用します。

   $ oc apply -f tuning-allmulti.yaml

   出力例

   networkattachmentdefinition.k8s.cni.cncf.io/setallmulti created

3. 次の examplepod.yaml サンプルファイルで指定されているものと同様のネットワークアタッチメント定義を使用して Pod を作成します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: allmultipod
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/networks: setallmulti
   spec:
     containers:
     - name: podexample
       image: centos
       command: ["/bin/bash", "-c", "sleep INF"]
       securityContext:
         runAsUser: 2000
         runAsGroup: 3000
         allowPrivilegeEscalation: false
         capabilities:
           drop: ["ALL"]
     securityContext:
       runAsNonRoot: true
       seccompProfile:
         type: RuntimeDefault

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

   metadata.annotations.k8s.v1.cni.cncf.io/networks

   設定された NetworkAttachmentDefinition の名前を指定します。

   spec.containers.securityContext.runAsUser

   コンテナーを実行するユーザー ID を指定します。

   spec.containers.securityContext.runAsGroup

   コンテナーの実行に使用するプライマリーグループ ID を指定します。

   spec.containers.securityContext.allowPrivilegeEscalation

   Pod が特権昇格を許可するよう要求できるかどうかを指定します。指定しない場合、デフォルトで true に設定されます。このブール値は、no_new_privs フラグがコンテナープロセスに設定されるかどうかを直接制御します。

   spec.containers.securityContext.capabilities

   完全なルートアクセス権限を与えずに、特権的な操作を指定します。このポリシーにより、すべての機能が Pod から削除されます。

   spec.containers.securityContext.runAsNonRoot: true

   UID が 0 以外のユーザーでコンテナーが実行されるように指定します。

   spec.containers.securityContext.seccompProfile

   Pod またはコンテナーワークロードのデフォルトの seccomp プロファイルを指定します。

4. 次のコマンドを実行して、YAML ファイルで指定された設定を適用します。

   $ oc apply -f examplepod.yaml

5. 次のコマンドを実行して、Pod が作成されていることを確認します。

   $ oc get pod

   出力例

   NAME          READY   STATUS    RESTARTS   AGE
   allmultipod   1/1     Running   0          23s

6. 次のコマンドを実行して、Pod にログインします。

   $ oc rsh allmultipod

7. 次のコマンドを実行して、Pod に関連付けられているすべてのインターフェイスをリスト表示します。

   sh-4.4# ip link

   出力例

   1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   2: eth0@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8901 qdisc noqueue state UP mode DEFAULT group default
       link/ether 0a:58:0a:83:00:10 brd ff:ff:ff:ff:ff:ff link-netnsid 0
   3: net1@if24: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
       link/ether ee:9b:66:a4:ec:1d brd ff:ff:ff:ff:ff:ff link-netnsid 0

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

   eth0@if22

   プライマリーインターフェイスを指定します。

   net1@if24

   全マルチキャストモード (ALLMULTI フラグ) をサポートするネットワーク接続定義で設定されたセカンダリーインターフェイスを指定します。

手順

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}]

手順

1. IP フェイルオーバーのサービスアカウントを作成します。

   $ oc create sa ipfailover

2. hostNetwork の Security Context Constraints (SCC) を更新します。

   $ oc adm policy add-scc-to-user privileged -z ipfailover

   $ oc adm policy add-scc-to-user hostnetwork -z ipfailover

3. Red Hat OpenStack Platform (RHOSP) のみ: フェイルオーバー仮想 IP アドレスが RHOSP ポートに到達できるように、次の手順を実行します。

   1. RHOSP CLI を使用して、RHOSP クラスターの allowed_address_pairs パラメーターのデフォルトの RHOSP API および仮想 IP アドレスを表示します。

      $ openstack port show <cluster_name> -c allowed_address_pairs

      出力例

      *Field*                  *Value*
      allowed_address_pairs    ip_address='192.168.0.5', mac_address='fa:16:3e:31:f9:cb'
                               ip_address='192.168.0.7', mac_address='fa:16:3e:31:f9:cb'

   2. RHOSP CLI で次のコマンドを入力して、IP フェイルオーバーのデプロイメントに別の仮想 IP アドレスを設定し、RHOSP のポートでそのアドレスに到達できるようにします。デフォルトの RHOSP API および仮想 IP アドレスを、IP フェイルオーバーのデプロイメントのフェイルオーバー仮想 IP アドレスとして設定しないでください。

      1.1.1.1 フェイルオーバー IP アドレスを RHOSP ポートの許可されたアドレスとして追加する例

      $ openstack port set <cluster_name> --allowed-address ip-address=1.1.1.1,mac-address=fa:fa:16:3e:31:f9:cb

   3. デプロイメントの IP フェイルオーバーを設定するためのデプロイメント YAML ファイルを作成します。後の手順の「IP フェイルオーバー設定のデプロイメント YAML の例」を参照してください。

   4. IP フェイルオーバーのデプロイメントで次の仕様を指定して、フェイルオーバー仮想 IP アドレスを OPENSHIFT_HA_VIRTUAL_IPS 環境変数に渡します。

      OPENSHIFT_HA_VIRTUAL_IPS に 1.1.1.1 仮想 IP アドレスを追加する例

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: ipfailover-keepalived
      # ...
            spec:
                env:
                - name: OPENSHIFT_HA_VIRTUAL_IPS
                value: "1.1.1.1"
      # ...

4. IP フェイルオーバーを設定するためのデプロイメント YAML ファイルを作成します。

   注記

   Red Hat OpenStack Platform (RHOSP) の場合、デプロイメント YAML ファイルを再作成する必要はありません。このファイルは、以前の手順ですでに作成されています。

   IP フェイルオーバー設定のデプロイメント YAML の例

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: ipfailover-keepalived
     labels:
       ipfailover: hello-openshift
   spec:
     strategy:
       type: Recreate
     replicas: 2
     selector:
       matchLabels:
         ipfailover: hello-openshift
     template:
       metadata:
         labels:
           ipfailover: hello-openshift
       spec:
         serviceAccountName: ipfailover
         privileged: true
         hostNetwork: true
         nodeSelector:
           node-role.kubernetes.io/worker: ""
         containers:
         - name: openshift-ipfailover
           image: registry.redhat.io/openshift4/ose-keepalived-ipfailover-rhel9:v4.20
           ports:
           - containerPort: 63000
             hostPort: 63000
           imagePullPolicy: IfNotPresent
           securityContext:
             privileged: true
           volumeMounts:
           - name: lib-modules
             mountPath: /lib/modules
             readOnly: true
           - name: host-slash
             mountPath: /host
             readOnly: true
             mountPropagation: HostToContainer
           - name: etc-sysconfig
             mountPath: /etc/sysconfig
             readOnly: true
           - name: config-volume
             mountPath: /etc/keepalive
           env:
           - name: OPENSHIFT_HA_CONFIG_NAME
             value: "ipfailover"
           - name: OPENSHIFT_HA_VIRTUAL_IPS
             value: "1.1.1.1-2"
           - name: OPENSHIFT_HA_VIP_GROUPS
             value: "10"
           - name: OPENSHIFT_HA_NETWORK_INTERFACE
             value: "ens3" #The host interface to assign the VIPs
           - name: OPENSHIFT_HA_MONITOR_PORT
             value: "30060"
           - name: OPENSHIFT_HA_VRRP_ID_OFFSET
             value: "10"
           - name: OPENSHIFT_HA_REPLICA_COUNT
             value: "2" #Must match the number of replicas in the deployment
           - name: OPENSHIFT_HA_USE_UNICAST
             value: "false"
           #- name: OPENSHIFT_HA_UNICAST_PEERS
             #value: "10.0.148.40,10.0.160.234,10.0.199.110"
           - name: OPENSHIFT_HA_IPTABLES_CHAIN
             value: "INPUT"
           #- name: OPENSHIFT_HA_NOTIFY_SCRIPT
           #  value: /etc/keepalive/mynotifyscript.sh
           - name: OPENSHIFT_HA_CHECK_SCRIPT
             value: "/etc/keepalive/mycheckscript.sh"
           - name: OPENSHIFT_HA_PREEMPTION
             value: "preempt_delay 300"
           - name: OPENSHIFT_HA_CHECK_INTERVAL
             value: "2"
           livenessProbe:
             initialDelaySeconds: 10
             exec:
               command:
               - pgrep
               - keepalived
         volumes:
         - name: lib-modules
           hostPath:
             path: /lib/modules
         - name: host-slash
           hostPath:
             path: /
         - name: etc-sysconfig
           hostPath:
             path: /etc/sysconfig
         # config-volume contains the check script
         # created with `oc create configmap keepalived-checkscript --from-file=mycheckscript.sh`
         - configMap:
             defaultMode: 0755
             name: keepalived-checkscript
           name: config-volume
         imagePullSecrets:
           - name: openshift-pull-secret

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

   IP フェイルオーバーキープ

   IP フェイルオーバーデプロイメントの名前を指定します。

   OPENSHIFT_HA_VIRTUAL_IPS

   複製する IP アドレス範囲のリストを指定します。これは指定する必要があります。例: 1.2.3.4-6,1.2.3.9

   OPENSHIFT_HA_VIP_GROUPS

   VRRP 用に作成するグループ数を指定します。これが設定されていない場合、グループは OPENSHIFT_HA_VIP_GROUPS 変数で指定されている仮想 IP 範囲ごとに作成されます。

   OPENSHIFT_HA_NETWORK_INTERFACE

   IP フェイルオーバーが VRRP トラフィックを送信するために使用するインターフェイス名を指定します。デフォルトで eth0 が使用されます。

   OPENSHIFT_HA_MONITOR_PORT

   IP フェイルオーバー Pod が、各仮想 IP 上のこのポートへの TCP 接続を開こうとすることを指定します。接続が設定されると、サービスは実行中であると見なされます。このポートが 0 に設定される場合、テストは常にパスします。デフォルト値は 80 です。

   OPENSHIFT_HA_VRRP_ID_OFFSET

   仮想ルーター ID を設定する際に使用するオフセット値を指定します。異なるオフセット値を使用すると、複数の IP フェイルオーバー設定が同じクラスター内に存在できるようになります。デフォルトのオフセットは 10 で、許可される範囲は 0 から 255 までです。

   OPENSHIFT_HA_REPLICA_COUNT

   作成するレプリカの数を指定します。これは、IP フェイルオーバー設定の spec.replicas の 値と一致する必要があります。デフォルト値は 2 です。

   OPENSHIFT_HA_USE_UNICAST

   VRRP でユニキャストモードを使用するかどうかを指定します。デフォルト値は false です。

   OPENSHIFT_HA_UNICAST_PEERS

   ユニキャストピアの IP アドレスのリストを指定します。OPENSHIFT_HA_USE_UNICAST が true に設定されている場合は、これを提供する必要があります。

   OPENSHIFT_HA_IPTABLES_CHAIN

   VRRP トラフィックを許可するための iptables ルールを自動的に追加する iptables チェーンの名前を指定します。この値が設定されていない場合、iptables ルールは追加されません。チェーンが存在しない場合は作成されず、Keepalived はユニキャストモードで動作します。デフォルトは INPUT です。

   OPENSHIFT_HA_NOTIFY_SCRIPT

   状態が変化するたびに実行されるスクリプトの、Pod ファイルシステム内の完全なパス名を指定します。

   OPENSHIFT_HA_CHECK_SCRIPT

   アプリケーションが正常に動作していることを確認するために定期的に実行されるスクリプトの、Pod ファイルシステム内の完全なパス名を指定します。

   OPENSHIFT_HA_PREEMPTION

   優先度の高い新しいホストを処理するためのストラテジーを指定します。デフォルト値は preempt_delay 300 で、優先順位の低いマスターが VIP を保持する場合に、Keepalived インスタンスが VIP を 5 分後に引き継ぎます。

   OPENSHIFT_HA_CHECK_INTERVAL

   チェックスクリプトが実行される期間を秒単位で指定します。デフォルト値は 2 です。

   openshift-pull-secret

   IP フェイルオーバーデプロイメントに使用するプルシークレットの名前を指定します。デプロイメントを作成する前にプルシークレットを作成します。作成しない場合には、デプロイメントの作成時にエラーが発生します。

手順

1. 必要なスクリプトを作成し、それを保持する ConfigMap オブジェクトを作成します。スクリプトには入力引数は指定されず、OK の場合は 0 を、fail の場合は 1 を返す必要があります。

   チェックスクリプト mycheckscript.sh:

   #!/bin/bash
       # Whatever tests are needed
       # E.g., send request and verify response
   exit 0

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

   $ oc create configmap mycustomcheck --from-file=mycheckscript.sh

3. スクリプトを Pod に追加します。マウントされた ConfigMap オブジェクトファイルの defaultMode は、oc コマンドを使用するか、IP フェイルオーバー設定を編集することによって実行できる必要があります。

   1. 以下のコマンドを実行して、スクリプトを Pod に追加してください。0755( 10 進数で 493) という値が一般的です。以下に例を示します。

      $ oc set env deploy/ipfailover-keepalived \
          OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh

      $ oc set volume deploy/ipfailover-keepalived --add --overwrite \
          --name=config-volume \
          --mount-path=/etc/keepalive \
          --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'

      注記

      oc set env コマンドは空白を区別します。= 記号の両側に空白を入れることはできません。

   2. または、以下のコマンドを実行して ipfailover-keepalived の 設定を編集します。

      $ oc edit deploy ipfailover-keepalived

      ipfailover-keepalived の 設定例

          spec:
            containers:
            - env:
              - name: OPENSHIFT_HA_CHECK_SCRIPT
                value: /etc/keepalive/mycheckscript.sh
      ...
              volumeMounts:
              - mountPath: /etc/keepalive
                name: config-volume
            dnsPolicy: ClusterFirst
      ...
            volumes:
            - configMap:
                defaultMode: 0755
                name: customrouter
              name: config-volume
      ...

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

      spec.container.env.name

      OPENSHIFT_HA_CHECK_SCRIPT 環境変数がマウントされたスクリプトファイルを指すように指定します。

      spec.container.volumeMounts

      マウントポイントを作成する spec.container.volumeMounts フィールドを指定します。

      spec.volumes

      config map を参照するための新しい spec.volumes フィールドを指定します。

      spec.volumes.configMap.defaultMode

      ファイルに対する実行権限を指定します。読み取られる場合は 10 進数 (493) で表示されます。

   3. 変更を保存し、エディターを終了します。これにより 、ipfailover-keepalived の 設定が再起動されます。

手順

1. オプション: config map として保存されるチェックおよび通知スクリプトを特定し、削除します。

   1. IP フェイルオーバーの Pod が config map をボリュームとして使用するかどうかを決定します。

      $ oc get pod -l ipfailover \
        -o jsonpath="\
      {range .items[?(@.spec.volumes[*].configMap)]}
      {'Namespace: '}{.metadata.namespace}
      {'Pod:       '}{.metadata.name}
      {'Volumes that use config maps:'}
      {range .spec.volumes[?(@.configMap)]}  {'volume:    '}{.name}
        {'configMap: '}{.configMap.name}{'\n'}{end}
      {end}"

      出力例

      Namespace: default
      Pod:       keepalived-worker-59df45db9c-2x9mn
      Volumes that use config maps:
        volume:    config-volume
        configMap: mycustomcheck

   2. 前述の手順でボリュームとして使用される config map の名前が提供されている場合は、config map を削除します。

      $ oc delete configmap <configmap_name>

2. IP フェイルオーバーの既存デプロイメントを特定します。

   $ oc get deployment -l ipfailover

   出力例

   NAMESPACE   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
   default     ipfailover   2/2     2            2           105d

3. デプロイメントを削除します。

   $ oc delete deployment <ipfailover_deployment_name>

4. ipfailover サービスアカウントを削除します。

   $ oc delete sa ipfailover

5. IP フェイルオーバーの設定時に追加された IP テーブルルールを削除するジョブを実行します。

   1. 以下の例のような内容で remove-ipfailover-job.yaml などのファイルを作成します。

      apiVersion: batch/v1
      kind: Job
      metadata:
        generateName: remove-ipfailover-
        labels:
          app: remove-ipfailover
      spec:
        template:
          metadata:
            name: remove-ipfailover
          spec:
            containers:
            - name: remove-ipfailover
              image: registry.redhat.io/openshift4/ose-keepalived-ipfailover-rhel9:v4.20
              command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
            nodeSelector:
              kubernetes.io/hostname: <host_name>
            restartPolicy: Never

      • nodeSelector は、古い IP フェイルオーバーデプロイメントで使用されていたセレクターと同じである可能性があります。
      • IP フェイルオーバー用に設定されたクラスター内の各ノードのジョブを実行し、毎回ホスト名を置き換えます。

   2. ジョブを実行します。

      $ oc create -f remove-ipfailover-job.yaml

      出力例

      job.batch/remove-ipfailover-2h8dm created

手順

1. HTTPS 接続のプロキシーに必要な追加の CA 証明書が含まれる config map を作成します。

   注記

   プロキシーのアイデンティティー証明書が Red Hat Enterprise Linux CoreOS (RHCOS) トラストバンドルの認証局によって署名されている場合は、この手順をスキップできます。

   1. user-ca-bundle.yaml というファイルを作成し、PEM でエンコードされた証明書の値を指定します。

      apiVersion: v1
      data:
        ca-bundle.crt: | 

      1

      
          <MY_PEM_ENCODED_CERTS> 

      2

      
      kind: ConfigMap
      metadata:
        name: user-ca-bundle 

      3

      
        namespace: openshift-config 

      4

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

      data.ca-bundle.crt

      ca-bundle.crt という名前でなければならないデータキーを指定します。

      <MY_PEM_ENCODED_CERTS>

      プロキシーのアイデンティティー証明書に署名するために使用される、PEM エンコードされた 1 つ以上の X.509 証明書を指定します。

      ユーザー CA バンドル

      Proxy オブジェクトから参照される config map 名を指定します。

      openshift-config

      config map が存在する必要のある名前空間を指定します。

   2. 次のコマンドを入力して、user-ca-bundle.yaml ファイルから config map を作成します。

      $ oc create -f user-ca-bundle.yaml

2. oc edit コマンドを使用して Proxy オブジェクトを変更します。

   $ oc edit proxy/cluster

3. プロキシーに必要なフィールドを設定します。

   apiVersion: config.openshift.io/v1
   kind: Proxy
   metadata:
     name: cluster
   spec:
     httpProxy: http://<username>:<pswd>@<ip>:<port> 

   1

   
     httpsProxy: https://<username>:<pswd>@<ip>:<port> 

   2

   
     noProxy: example.com 

   3

   
     readinessEndpoints:
     - http://www.google.com 

   4

   
     - https://www.google.com
     trustedCA:
       name: user-ca-bundle 

   5

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

   httpProxy

   クラスター外部からの HTTP 接続を作成する際に使用するプロキシー URL を指定します。URL スキームは http である必要があります。

   httpsProxy

   クラスター外部で HTTPS 接続を作成する際に使用するプロキシー URL を指定します。URL スキームは http または https である必要があります。URL スキームをサポートするプロキシーの URL を指定します。たとえば、プロキシーが https を使用するように設定されていても、http しかサポートしていない場合、ほとんどのプロキシーはエラーを報告します。このエラーメッセージはログに反映されず、代わりにネットワーク接続エラーのように見える場合があります。クラスターからの https 接続をリッスンするプロキシーを使用する場合は、プロキシーが使用する CA と証明書を受け入れるようにクラスターを設定する必要がある場合があります。

   noProxy

   プロキシーを除外する宛先ドメイン名、ドメイン、IP アドレス (またはその他のネットワーク CIDR)、およびポート番号をコンマ区切りで指定します。ポート番号は IPv6 アドレスを設定する場合にのみサポートされることに注意してください。IPv4 アドレスを設定する場合、ポート番号はサポートされません。

   サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.com は x.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。

   noproxy フィールドにドメインアドレスを含める必要がある場合は、noproxy フィールドにその FQDN または接頭辞が一致するサブドメインを明示的に指定する必要があります。ドメインをカプセル化する IP アドレスまたは CIDR 範囲は使用できません。なぜなら、クラスターは DNS が IP アドレスを返すのを待たずにルート接続を割り当て、実行されているリクエストを明示的にチェックするからです。たとえば、noproxy フィールドに 10.0.0.0/24 などの CIDR ブロック値がある場合、フィールドが https://10.0.0.11 にアクセスしようとすると、アドレスが正常にマッチします。しかし、A レコードのエントリーが 10.0.0.11 である https://exampleserver.externaldomain.com にアクセスしようとすると、失敗します。noproxy フィールドに .externaldomain.com という追加の値が必要です。

   インストール設定の networking.machineNetwork[].cidr フィールドで定義されたネットワークに含まれていないコンピュートノードをスケールアップする場合は、接続の問題を防ぐために、そのノードをこのリストに追加する必要があります。

   httpProxy または httpsProxy フィールドのいずれも設定されていない場合に、このフィールドは無視されます。

   readinessEndpoints

   クラスター外部の 1 つ以上の URL を指定し、httpProxy および httpsProxy の 値を status に書き込む前に、準備状況チェックを実行します。

   trustedCA

   HTTPS 接続のプロキシーに必要な追加の CA 証明書を含む、openshift-config 名前空間内の config map への参照を指定します。ここで参照する前に config map が存在している必要があります。このフィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。

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

手順

1. oc edit コマンドを使用してプロキシーを変更します。

   $ oc edit proxy/cluster

2. プロキシーオブジェクトからすべての spec フィールドを削除します。以下に例を示します。

   apiVersion: config.openshift.io/v1
   kind: Proxy
   metadata:
     name: cluster
   spec: {}

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

手順

1. oc コマンドを使用してプロキシー設定のステータスを確認します。

   $ oc get proxy/cluster -o yaml

2. 出力内のプロキシーフィールドを検証して、設定と一致していることを確認します。具体的には、spec.httpProxy、spec.httpsProxy、spec.noProxy、および spec.trustedCA フィールドを確認します。

3. Proxy オブジェクトのステータスを検査します。

   $ oc get proxy/cluster -o jsonpath='{.status}'

   出力例

   {
   status:
       httpProxy: http://user:xxx@xxxx:3128
       httpsProxy: http://user:xxx@xxxx:3128
       noProxy: .cluster.local,.svc,10.0.0.0/16,10.128.0.0/14,127.0.0.1,169.254.169.254,172.30.0.0/16,localhost,test.no-proxy.com
   }

4. Machine Config Operator (MCO) のログをチェックして、設定の変更が正常に適用されたことを確認します。

   $ oc logs -n openshift-machine-config-operator $(oc get pods -n openshift-machine-config-operator -l k8s-app=machine-config-operator -o name)

5. 必要に応じて、プロキシー設定が適用され、ノードが再起動されたことを示すメッセージを確認します。

6. 外部リクエストを行うコンポーネント (Cluster Version Operator (CVO) など) のログをチェックして、システムコンポーネントがプロキシーを使用していることを確認します。

   $ oc logs -n openshift-cluster-version $(oc get pods -n openshift-cluster-version -l k8s-app=machine-config-operator -o name)

7. 外部リクエストがプロキシー経由でルーティングされたことを示すログエントリーを確認します。

手順

1. install-config.yaml ファイルを開きます。

2. PEM でエンコードされた CA 証明書に additionalTrustBundle パラメーターを追加します。

   apiVersion: v1
   baseDomain: my.domain.com
   metadata:
     name: my-cluster
   additionalTrustBundle: |
     -----BEGIN CERTIFICATE-----
     <MY_PEM_ENCODED_CA_CERT>
     -----END CERTIFICATE-----

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

   additionalTrustBundle

   クラスターが信頼するカスタム CA 証明書を指定します。インストールプログラムは証明書を使用して、openshift-config namespace に user-ca-bundle ConfigMap オブジェクトを生成します。

3. install-config.yaml ファイルを保存し、クラスターのインストールを続行します。

手順

1. CA 証明書を使用して ConfigMap オブジェクトを作成します。

   1. ConfigMap オブジェクトを定義するために、custom-ca.yaml という名前の YAML ファイルを作成します。

   2. 以下の内容をファイルに追加します。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: custom-ca-bundle
        namespace: openshift-config
      data:
        ca-bundle.crt: |
          -----BEGIN CERTIFICATE-----
          <MY_PEM_ENCODED_CA_CERT>
          -----END CERTIFICATE-----

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

      metadata.name

      Proxy オブジェクトから参照する ConfigMap オブジェクトの名前を指定します。

      metadata.namespace

      ConfigMap オブジェクトの名前空間を指定します。

      data.ca-bundle.crt

      証明書バンドルのデータキーを指定します。

2. 以下のコマンドを実行して、マニフェストを適用し、クラスター内に ConfigMap オブジェクトを作成します。

   $ oc apply -f custom-ca.yaml

3. クラスター Proxy オブジェクト内の ConfigMap オブジェクトを参照します。

   1. 次のコマンドを実行して、クラスターの プロキシー オブジェクトを更新し、先ほど作成した ConfigMap オブジェクトを参照するようにします。

      $ oc patch proxy/cluster --type=merge --patch='{"spec":{"trustedCA":{"name":"custom-ca-bundle"}}}'

      このコマンドを実行すると、Machine Config Operator (MCO) が変更を検出し、クラスター内の全ノードに信頼された新規 CA の配布を開始します。

手順

1. クラスター全体の CA トラストバンドルの内容を表示するには、次のコマンドを実行します。

   $ oc get configmap trusted-ca-bundle -n openshift-config -o yaml

2. YAML 出力で、data.ca-bundle.crt フィールドを調べます。このフィールドには、クラスターのすべての信頼済み証明書が含まれます。

3. 追加した PEM エンコードされた証明書が証明書のリストに含まれていることを確認します。出力の構造は、以下のようになります。

   kind: ConfigMap
   metadata:
     name: trusted-ca-bundle
     namespace: openshift-config
   data:
     ca-bundle.crt: |
       -----BEGIN CERTIFICATE-----
       <A_SYSTEM_CA_CERTIFICATE>
       -----END CERTIFICATE-----
       -----BEGIN CERTIFICATE-----
       <ANOTHER_SYSTEM_CA_CERTIFICATE>
       -----END CERTIFICATE-----
       -----BEGIN CERTIFICATE-----
       <YOUR_CUSTOM_CA_CERTIFICATE_SHOULD_BE_HERE>
       -----END CERTIFICATE-----

   出力に証明書が存在する場合は、クラスターはカスタム PKI を信頼します。