ネットワーク設定

手順

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

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: <name> 

   1

   
     namespace: default 

   2

   
   spec:
     config: '{
       "cniVersion": "0.4.0", 

   3

   
       "name": "<name>", 

   4

   
       "plugins": [{
          "type": "<main_CNI_plugin>" 

   5

   
         },
         {
          "type": "tuning", 

   6

   
          "sysctl": {
               "net.ipv4.conf.IFNAME.accept_redirects": "1" 

   7

   
           }
         }
        ]
   }

   Copy to Clipboard Toggle word wrap

   1

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

   2

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

   3

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

   4

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

   5

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

   6

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

   7

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

   YAML ファイルの例を次に示します。

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

   Copy to Clipboard Toggle word wrap

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

   $ oc apply -f tuning-example.yaml

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

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

   apiVersion: v1
   kind: Pod
   metadata:
     name: tunepod
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/networks: tuningnad 

   1

   
   spec:
     containers:
     - name: podexample
       image: centos
       command: ["/bin/bash", "-c", "sleep INF"]
       securityContext:
         runAsUser: 2000 

   2

   
         runAsGroup: 3000 

   3

   
         allowPrivilegeEscalation: false 

   4

   
         capabilities: 

   5

   
           drop: ["ALL"]
     securityContext:
       runAsNonRoot: true 

   6

   
       seccompProfile: 

   7

   
         type: RuntimeDefault

   Copy to Clipboard Toggle word wrap

   1

   設定済みの NetworkAttachmentDefinition の名前を指定します。

   2

   runAsUser は、コンテナーが実行されるユーザー ID を制御します。

   3

   runAsGroup は、コンテナーが実行されるプライマリーグループ ID を制御します。

   4

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

   5

   capabilities は、完全なルートアクセスを許可せずに権限操作を許可します。このポリシーにより、すべての機能が Pod から削除されます。

   6

   runAsNonRoot: true は、コンテナーが 0 以外の任意の UID を持つユーザーで実行されることを要求します。

   7

   RuntimeDefault は、Pod またはコンテナーワークロードのデフォルトの seccomp プロファイルを有効にします。

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

   $ oc apply -f examplepod.yaml

   Copy to Clipboard Toggle word wrap

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

   $ oc get pod

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

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

   $ oc rsh tunepod

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   予想される出力

   net.ipv4.conf.net1.accept_redirects = 1

   Copy to Clipboard Toggle word wrap

手順

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

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: <name> 

   1

   
     namespace: default 

   2

   
   spec:
     config: '{
       "cniVersion": "0.4.0", 

   3

   
       "name": "<name>", 

   4

   
       "plugins": [{
          "type": "<main_CNI_plugin>" 

   5

   
         },
         {
          "type": "tuning", 

   6

   
          "allmulti": true 

   7

   
           }
         }
        ]
   }

   Copy to Clipboard Toggle word wrap

   1

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

   2

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

   3

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

   4

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

   5

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

   6

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

   7

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

   YAML ファイルの例を次に示します。

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

   Copy to Clipboard Toggle word wrap

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

   $ oc apply -f tuning-allmulti.yaml

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

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

   apiVersion: v1
   kind: Pod
   metadata:
     name: allmultipod
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/networks: setallmulti 

   1

   
   spec:
     containers:
     - name: podexample
       image: centos
       command: ["/bin/bash", "-c", "sleep INF"]
       securityContext:
         runAsUser: 2000 

   2

   
         runAsGroup: 3000 

   3

   
         allowPrivilegeEscalation: false 

   4

   
         capabilities: 

   5

   
           drop: ["ALL"]
     securityContext:
       runAsNonRoot: true 

   6

   
       seccompProfile: 

   7

   
         type: RuntimeDefault

   Copy to Clipboard Toggle word wrap

   1

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

   2

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

   3

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

   4

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

   5

   コンテナーのケイパビリティーを指定します。drop: ["ALL"] ステートメントは、すべての Linux ケイパビリティーが Pod からドロップされ、より制限的なセキュリティープロファイルが提供されていることを示します。

   6

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

   7

   コンテナーの seccomp プロファイルを指定します。この場合、タイプは RuntimeDefault に設定されます。Seccomp は、プロセスで使用できるシステムコールを制限し、攻撃対象領域を最小化してセキュリティーを強化する Linux カーネル機能です。

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

   $ oc apply -f examplepod.yaml

   Copy to Clipboard Toggle word wrap

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

   $ oc get pod

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

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

   $ oc rsh allmultipod

   Copy to Clipboard Toggle word wrap

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

   sh-4.4# ip link

   Copy to Clipboard Toggle word wrap

   出力例

   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 

   1

   
   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 

   2

   Copy to Clipboard Toggle word wrap

   1

   eth0@if22 は、プライマリーインターフェイスです。

   2

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

手順

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

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

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

   <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"
       }
     }'

   Copy to Clipboard Toggle word wrap

   出力例

   network.config.openshift.io/cluster patched

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

手順

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

   $ oc create sa ipfailover

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

      Copy to Clipboard Toggle word wrap

      出力例

      *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'

      Copy to Clipboard Toggle word wrap

   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

      Copy to Clipboard Toggle word wrap

   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"
      # ...

      Copy to Clipboard Toggle word wrap

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

   注記

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

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

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: ipfailover-keepalived 

   1

   
     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.17
           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 

   2

   
             value: "1.1.1.1-2"
           - name: OPENSHIFT_HA_VIP_GROUPS 

   3

   
             value: "10"
           - name: OPENSHIFT_HA_NETWORK_INTERFACE 

   4

   
             value: "ens3" #The host interface to assign the VIPs
           - name: OPENSHIFT_HA_MONITOR_PORT 

   5

   
             value: "30060"
           - name: OPENSHIFT_HA_VRRP_ID_OFFSET 

   6

   
             value: "0"
           - name: OPENSHIFT_HA_REPLICA_COUNT 

   7

   
             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 

   8

   
             value: "INPUT"
           #- name: OPENSHIFT_HA_NOTIFY_SCRIPT 

   9

   
           #  value: /etc/keepalive/mynotifyscript.sh
           - name: OPENSHIFT_HA_CHECK_SCRIPT 

   10

   
             value: "/etc/keepalive/mycheckscript.sh"
           - name: OPENSHIFT_HA_PREEMPTION 

   11

   
             value: "preempt_delay 300"
           - name: OPENSHIFT_HA_CHECK_INTERVAL 

   12

   
             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 

   13

   Copy to Clipboard Toggle word wrap

   1

   IP フェイルオーバーデプロイメントの名前。

   2

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

   3

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

   4

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

   5

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

   6

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

   7

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

   8

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

   9

   状態が変更されるたびに実行されるスクリプトの Pod ファイルシステム内の完全パス名。

   10

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

   11

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

   12

   check スクリプトが実行される期間 (秒単位)。デフォルト値は 2 です。

   13

   デプロイメントを作成する前にプルシークレットを作成します。作成しない場合には、デプロイメントの作成時にエラーが発生します。

手順

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

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

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

   Copy to Clipboard Toggle word wrap

2. ConfigMap オブジェクトを作成します。

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

   Copy to Clipboard Toggle word wrap

3. スクリプトを Pod に追加します。マウントされた ConfigMap オブジェクトファイルの defaultMode は、oc コマンドを使用するか、デプロイメント設定を編集することで実行できる必要があります。通常は、0755、493 (10 進数) の値が使用されます。

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap
   注記

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

   ヒント

   または、ipfailover-keepalived デプロイメント設定を編集することもできます。

   $ oc edit deploy ipfailover-keepalived

   Copy to Clipboard Toggle word wrap

       spec:
         containers:
         - env:
           - name: OPENSHIFT_HA_CHECK_SCRIPT  

   1

   
             value: /etc/keepalive/mycheckscript.sh
   ...
           volumeMounts: 

   2

   
           - mountPath: /etc/keepalive
             name: config-volume
         dnsPolicy: ClusterFirst
   ...
         volumes: 

   3

   
         - configMap:
             defaultMode: 0755 

   4

   
             name: customrouter
           name: config-volume
   ...

   Copy to Clipboard Toggle word wrap

   1

   spec.container.env フィールドで、マウントされたスクリプトファイルを参照する OPENSHIFT_HA_CHECK_SCRIPT 環境変数を追加します。

   2

   spec.container.volumeMounts フィールドを追加してマウントポイントを作成します。

   3

   新規の spec.volumes フィールドを追加して config map に言及します。

   4

   これはファイルの実行パーミッションを設定します。読み取られる場合は 10 進数 (493) で表示されます。

   変更を保存し、エディターを終了します。これにより 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}"

      Copy to Clipboard Toggle word wrap

      出力例

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

      Copy to Clipboard Toggle word wrap

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

      $ oc delete configmap <configmap_name>

      Copy to Clipboard Toggle word wrap

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

   $ oc get deployment -l ipfailover

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

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

   $ oc delete deployment <ipfailover_deployment_name>

   Copy to Clipboard Toggle word wrap

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

   $ oc delete sa ipfailover

   Copy to Clipboard Toggle word wrap

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.17
              command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
            nodeSelector: 

      1

      
              kubernetes.io/hostname: <host_name>  

      2

      
            restartPolicy: Never

      Copy to Clipboard Toggle word wrap

      1

      nodeSelector は、古い IP フェイルオーバーデプロイメントで使用されていたセレクターと同じである可能性があります。

      2

      IP フェイルオーバー用に設定されたクラスター内の各ノードのジョブを実行し、毎回ホスト名を置き換えます。

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

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

      Copy to Clipboard Toggle word wrap

      出力例

      job.batch/remove-ipfailover-2h8dm created

      Copy to Clipboard Toggle word wrap

手順

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

      Copy to Clipboard Toggle word wrap

      1

      このデータキーは ca-bundle.crt という名前にする必要があります。

      2

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

      3

      Proxy オブジェクトから参照される config map 名。

      4

      config map は openshift-config namespace に存在する必要があります。

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

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

      Copy to Clipboard Toggle word wrap

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

   $ oc edit proxy/cluster

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   1

   クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。

   2

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

   3

   プロキシーを除外するための宛先ドメイン名、ドメイン、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 フィールドのいずれも設定されていない場合に、このフィールドは無視されます。

   4

   httpProxy および httpsProxy の値をステータスに書き込む前の readiness チェックに使用するクラスター外の 1 つ以上の URL。

   5

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

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

手順

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

   $ oc edit proxy/cluster

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap
3. 変更を適用するためにファイルを保存します。

手順

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

   $ oc get proxy/cluster -o yaml

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

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

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

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

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)

   Copy to Clipboard Toggle word wrap
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)

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

手順

1. install-config.yaml ファイルを編集し、プロキシー設定を追加します。以下に例を示します。

   apiVersion: v1
   baseDomain: my.domain.com
   proxy:
     httpProxy: http://<username>:<pswd>@<ip>:<port> 

   1

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

   2

   
     noProxy: example.com 

   3

   
   additionalTrustBundle: | 

   4

   
       -----BEGIN CERTIFICATE-----
       <MY_TRUSTED_CA_CERT>
       -----END CERTIFICATE-----
   additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 

   5

   Copy to Clipboard Toggle word wrap

   1

   クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。

   2

   クラスター外で HTTPS 接続を作成するために使用するプロキシー URL。

   3

   プロキシーから除外するための宛先ドメイン名、IP アドレス、または他のネットワーク CIDR のコンマ区切りのリスト。サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.com は x.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。

   4

   指定されている場合、インストールプログラムは HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書が含まれる user-ca-bundle という名前の設定マップを openshift-config namespace に生成します。次に Cluster Network Operator は、これらのコンテンツを Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージする trusted-ca-bundle 設定マップを作成し、この設定マップは Proxy オブジェクトの trustedCA フィールドで参照されます。additionalTrustBundle フィールドは、プロキシーのアイデンティティー証明書が RHCOS 信頼バンドルからの認証局によって署名されない限り必要になります。

   5

   オプション: trustedCA フィールドの user-ca-bundle 設定マップを参照する Proxy オブジェクトの設定を決定するポリシー。許可される値は Proxyonly および Always です。Proxyonly を使用して、http/https プロキシーが設定されている場合にのみ user-ca-bundle 設定マップを参照します。Always を使用して、常に user-ca-bundle 設定マップを参照します。デフォルト値は Proxyonly です。

   注記

   インストールプログラムは、プロキシーの readinessEndpoints フィールドをサポートしません。

   注記

   インストーラーがタイムアウトした場合は、インストーラーの wait-for コマンドを使用してデプロイメントを再起動してからデプロイメントを完了します。以下に例を示します。

   $ ./openshift-install wait-for install-complete --log-level debug

   Copy to Clipboard Toggle word wrap
2. ファイルを保存し、OpenShift Container Platform のインストール時にこれを参照します。

手順

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

      Copy to Clipboard Toggle word wrap

      1

      このデータキーは ca-bundle.crt という名前にする必要があります。

      2

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

      3

      Proxy オブジェクトから参照される config map 名。

      4

      config map は openshift-config namespace に存在する必要があります。

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

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

      Copy to Clipboard Toggle word wrap

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

   $ oc edit proxy/cluster

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   1

   クラスター外の HTTP 接続を作成するために使用するプロキシー URL。URL スキームは http である必要があります。

   2

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

   3

   プロキシーを除外するための宛先ドメイン名、ドメイン、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 フィールドのいずれも設定されていない場合に、このフィールドは無視されます。

   4

   httpProxy および httpsProxy の値をステータスに書き込む前の readiness チェックに使用するクラスター外の 1 つ以上の URL。

   5

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

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