ネットワーク

手順

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

   これにより、Server に基づく追加のサーバー設定ブロックを使用して dns-default という名前の ConfigMap を作成し、更新できます。クエリーに一致するゾーンを持つサーバーがない場合、名前解決は /etc/resolv.conf で指定されたネームサーバーにフォールバックします。

   DNS の例

   apiVersion: operator.openshift.io/v1
   kind: DNS
   metadata:
     name: default
   spec:
     servers:
     - name: foo-server 1
       zones: 2
         - example.com
       forwardPlugin:
         upstreams: 3
           - 1.1.1.1
           - 2.2.2.2:5353
     - name: bar-server
       zones:
         - bar.com
         - example.com
       forwardPlugin:
         upstreams:
           - 3.3.3.3
           - 4.4.4.4:5454

   1

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

   2

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

   3

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

   注記

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

2. ConfigMap を表示します。

   $ 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 {
               policy sequential
           }
           cache 30
           reload
       }
   kind: ConfigMap
   metadata:
     labels:
       dns.operator.openshift.io/owning-dns: default
     name: dns-default
     namespace: openshift-dns

   1

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

手順

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. ノードのポート範囲を拡張するには、以下のコマンドを入力します。<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. IP フェイルオーバーのサービスアカウントを作成します。

   $ oc create sa ipfailover

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

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

3. デプロイメント YAML ファイルを作成して IP フェイルオーバーを設定します。

   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: quay.io/openshift/origin-keepalived-ipfailover
           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

   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 を返す必要があります。

   check スクリプト 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 に追加します。マウントされた設定マップファイルの defaultMode は、oc コマンドを使用して、またはデプロイメント設定を編集して実行できる必要があります。通常は、0755、493 (10 進数) の値が使用されます。

   $ 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 コマンドは空白を区別します。= 記号の両側に空白を入れることはできません。

   ヒント

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

   $ oc edit deploy ipfailover-keepalived

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

   1

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

   2

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

   3

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

   4

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

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

手順

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

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

      $ 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. 前述の手順でボリュームとして使用される ConfigMap の名前が提供されている場合は、ConfigMap を削除します。

      $ 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: quay.io/openshift/origin-keepalived-ipfailover:4.9
              command: ["/var/lib/ipfailover/keepalived/remove-failover.sh"]
            nodeSelector:
              kubernetes.io/hostname: <host_name>  <.>
            restartPolicy: Never

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

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

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

      出力例

      job.batch/remove-ipfailover-2h8dm created

手順

1. 以下の YAML 定義が含まれる load-sctp-module.yaml という名前のファイルを作成します。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     name: load-sctp-module
     labels:
       machineconfiguration.openshift.io/role: worker
   spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
           - path: /etc/modprobe.d/sctp-blacklist.conf
             mode: 0644
             overwrite: true
             contents:
               source: data:,
           - path: /etc/modules-load.d/sctp-load.conf
             mode: 0644
             overwrite: true
             contents:
               source: data:,sctp

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

   $ oc create -f load-sctp-module.yaml

3. オプション: MachineConfig Operator が設定変更を適用している間にノードのステータスを確認するには、以下のコマンドを入力します。ノードのステータスが Ready に移行すると、設定の更新が適用されます。

   $ oc get nodes

手順

1. SCTP リスナーを起動する Pod を作成します。

   1. 以下の YAML で Pod を定義する sctp-server.yaml という名前のファイルを作成します。

      apiVersion: v1
      kind: Pod
      metadata:
        name: sctpserver
        labels:
          app: sctpserver
      spec:
        containers:
          - name: sctpserver
            image: registry.access.redhat.com/ubi8/ubi
            command: ["/bin/sh", "-c"]
            args:
              ["dnf install -y nc && sleep inf"]
            ports:
              - containerPort: 30102
                name: sctpserver
                protocol: SCTP

   2. 以下のコマンドを入力して Pod を作成します。

      $ oc create -f sctp-server.yaml

2. SCTP リスナー Pod のサービスを作成します。

   1. 以下の YAML でサービスを定義する sctp-service.yaml という名前のファイルを作成します。

      apiVersion: v1
      kind: Service
      metadata:
        name: sctpservice
        labels:
          app: sctpserver
      spec:
        type: NodePort
        selector:
          app: sctpserver
        ports:
          - name: sctpserver
            protocol: SCTP
            port: 30102
            targetPort: 30102

   2. サービスを作成するには、以下のコマンドを入力します。

      $ oc create -f sctp-service.yaml

3. SCTP クライアントの Pod を作成します。

   1. 以下の YAML で sctp-client.yaml という名前のファイルを作成します。

      apiVersion: v1
      kind: Pod
      metadata:
        name: sctpclient
        labels:
          app: sctpclient
      spec:
        containers:
          - name: sctpclient
            image: registry.access.redhat.com/ubi8/ubi
            command: ["/bin/sh", "-c"]
            args:
              ["dnf install -y nc && sleep inf"]

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

      $ oc apply -f sctp-client.yaml

4. サーバーで SCTP リスナーを実行します。

   1. サーバー Pod に接続するには、以下のコマンドを入力します。

      $ oc rsh sctpserver

   2. SCTP リスナーを起動するには、以下のコマンドを入力します。

      $ nc -l 30102 --sctp

5. サーバーの SCTP リスナーに接続します。

   1. ターミナルプログラムで新規のターミナルウィンドウまたはタブを開きます。

   2. sctpservice サービスの IP アドレスを取得します。以下のコマンドを入力します。

      $ oc get services sctpservice -o go-template='{{.spec.clusterIP}}{{"\n"}}'

   3. クライアント Pod に接続するには、以下のコマンドを入力します。

      $ oc rsh sctpclient

   4. SCTP クライアントを起動するには、以下のコマンドを入力します。<cluster_IP> を sctpservice サービスのクラスター IP アドレスに置き換えます。

      # nc <cluster_IP> 30102 --sctp

手順

1. PTP Operator の namespace を作成するには、以下のコマンドを入力します。

   $ cat << EOF| oc create -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-ptp
     annotations:
       workload.openshift.io/allowed: management
     labels:
       name: openshift-ptp
       openshift.io/cluster-monitoring: "true"
   EOF

2. Operator の Operator グループを作成するには、以下のコマンドを入力します。

   $ cat << EOF| oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: ptp-operators
     namespace: openshift-ptp
   spec:
     targetNamespaces:
     - openshift-ptp
   EOF

3. PTP Operator にサブスクライブします。

   1. 以下のコマンドを実行して、OpenShift Container Platform のメジャーおよびマイナーバージョンを環境変数として設定します。これは次の手順で channel の値として使用されます。

      $ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
          grep -o '[0-9]*[.][0-9]*' | head -1)

   2. PTP Operator のサブスクリプションを作成するには、以下のコマンドを入力します。

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ptp-operator-subscription
        namespace: openshift-ptp
      spec:
        channel: "${OC_VERSION}"
        name: ptp-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF

4. Operator がインストールされていることを確認するには、以下のコマンドを入力します。

   $ oc get csv -n openshift-ptp \
     -o custom-columns=Name:.metadata.name,Phase:.status.phase

   出力例

   Name                                        Phase
   ptp-operator.4.4.0-202006160135             Succeeded

手順

1. OpenShift Container Platform Web コンソールを使用して PTP Operator をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator の一覧から PTP Operator を選択してから Install をクリックします。
   3. Install Operator ページの A specific namespace on the cluster の下で openshift-ptp を選択します。次に、Install をクリックします。

2. オプション: PTP Operator が正常にインストールされていることを確認します。

   1. Operators → Installed Operators ページに切り替えます。

   2. PTP Operator が Status が InstallSucceeded の状態で openshift-ptp プロジェクトに一覧表示されていることを確認します。

      注記

      インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

      • Operators → Installed Operators ページに移動し、Operator Subscriptions および Install Plans タブで Status にエラーがあるかどうかを検査します。
      • Workloads → Pods ページに移動し、openshift-ptp プロジェクトで Pod のログを確認します。

手順

1. 以下の PtpConfig CR を作成してから、YAML を ordinary-clock-ptp-config.yaml ファイルに保存します。

   apiVersion: ptp.openshift.io/v1
   kind: PtpConfig
   metadata:
     name: ordinary-clock-ptp-config 1
     namespace: openshift-ptp
   spec:
     profile: 2
     - name: "profile1" 3
       interface: "ens787f1" 4
       ptp4lOpts: "-s -2" 5
       phc2sysOpts: "-a -r" 6
       ptp4lConf: "" 7
       ptpSchedulingPolicy: SCHED_OTHER 8
       ptpSchedulingPriority: 10 9
     recommend: 10
     - profile: "profile1" 11
       priority: 10 12
       match: 13
       - nodeLabel: "node-role.kubernetes.io/worker" 14
         nodeName: "compute-0.example.com" 15

   1

   PtpConfig CR の名前。

   2

   1 つ以上の profile オブジェクトの配列を指定します。

   3

   プロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。

   4

   ptp4l サービスで使用するネットワークインターフェイス名を指定します (例: ens787f1)。

   5

   ptp4l サービスのシステム設定オプションを指定します。たとえば、-2 で IEEE 802.3 ネットワークトランスポートを選択します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名 -i <interface> およびサービス設定ファイル -f /etc/ptp4l.conf を含めないでください。

   6

   phc2sys サービスのシステム設定オプション (例: -a -r) を指定します。このフィールドが空の場合、PTP Operator は phc2sys サービスを開始しません。

   7

   デフォルトの /etc/ptp4l.conf ファイルを置き換える設定が含まれる文字列を指定します。デフォルト設定を使用するには、フィールドを空のままにします。

   8

   ptp4l と phc2sys プロセスのスケジューリングポリシー。デフォルト値は SCHED_OTHER です。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO を使用してください。

   9

   ptp SchedulingPolicy が SCHED_FIFO に設定されている場合に、ptp4l および phc2sys プロセスの FIFO の優先度を設定するために使用される 1-65 の整数値。ptpSchedulingPriority フィールドは、ptpSchedulingPolicy が SCHED_OTHER に設定されている場合は使用されません。

   10

   profile がノードに適用される方法を定義する 1 つ以上の recommend オブジェクトの配列を指定します。

   11

   profile セクションに定義される profile オブジェクト名を指定します。

   12

   0 から 99 までの整数値で priority を指定します。数値が大きいほど優先度が低くなるため、99 の優先度は 10 よりも低くなります。ノードが match フィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。

   13

   match ルールを、nodeLabel または nodeName で指定します。

   14

   oc get nodes --show-labels コマンドを使用して、ノードオブジェクトのnode.LabelsのkeyでnodeLabelを指定します。

   15

   oc get nodesコマンドを使用して、ノードオブジェクトのnode.NameでnodeNameを指定します。

2. 以下のコマンドを実行して CR を作成します。

   $ oc create -f ordinary-clock-ptp-config.yaml

検証手順

1. PtpConfig プロファイルがノードに適用されていることを確認します。

   1. 以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

      $ oc get pods -n openshift-ptp -o wide

      出力例

      NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
      linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
      linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
      ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

   2. プロファイルが正しいことを確認します。PtpConfig プロファイルで指定したノードに対応する linuxptp デーモンのログを検査します。以下のコマンドを実行します。

      $ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

      出力例

      I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
      I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
      I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
      I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
      I1115 09:41:17.117616 4143292 daemon.go:102] Interface: ens787f1
      I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -s -2
      I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r
      I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

手順

1. 以下の PtpConfig CR を作成してから、YAML を boundary-clock-ptp-config.yaml ファイルに保存します。

   apiVersion: ptp.openshift.io/v1
   kind: PtpConfig
   metadata:
     name: boundary-clock-ptp-config 1
     namespace: openshift-ptp
   spec:
     profile: 2
     - name: "profile1" 3
       interface: "" 4
       ptp4lOpts: "-2" 5
       ptp4lConf: | 6
         [ens1f0] 7
         masterOnly 0
         [ens1f3] 8
         masterOnly 1
         [global]
         #
         # Default Data Set
         #
         twoStepFlag                       1
         #slaveOnly                        1
         priority1                         128
         priority2                         128
         domainNumber                      24
         #utc_offset                       37
         clockClass                        248
         clockAccuracy                     0xFE
         offsetScaledLogVariance         0xFFFF
         free_running                      0
         freq_est_interval               1
         dscp_event                        0
         dscp_general                      0
         dataset_comparison              G.8275.x
         G.8275.defaultDS.localPriority  128
         #
         # Port Data Set
         #
         logAnnounceInterval          -3
         logSyncInterval                -4
         logMinDelayReqInterval       -4
         logMinPdelayReqInterval      -4
         announceReceiptTimeout       3
         syncReceiptTimeout           0
         delayAsymmetry                 0
         fault_reset_interval         4
         neighborPropDelayThresh      20000000
         masterOnly                     0
         G.8275.portDS.localPriority  128
         #
         # Run time options
         #
         assume_two_step              0
         logging_level                6
         path_trace_enabled         0
         follow_up_info               0
         hybrid_e2e                   0
         inhibit_multicast_service  0
         net_sync_monitor           0
         tc_spanning_tree           0
         tx_timestamp_timeout       10
         #was 1 (default !)
         unicast_listen          0
         unicast_master_table  0
         unicast_req_duration  3600
         use_syslog              1
         verbose                   0
         summary_interval      -4
         kernel_leap             1
         check_fup_sync          0
         #
         # Servo Options
         #
         pi_proportional_const     0.0
         pi_integral_const         0.0
         pi_proportional_scale     0.0
         pi_proportional_exponent  -0.3
         pi_proportional_norm_max  0.7
         pi_integral_scale         0.0
         pi_integral_exponent      0.4
         pi_integral_norm_max      0.3
         step_threshold            2.0
         first_step_threshold      0.00002
         max_frequency               900000000
         clock_servo                 pi
         sanity_freq_limit         200000000
         ntpshm_segment              0
         #
         # Transport options
         #
         transportSpecific   0x0
         ptp_dst_mac          01:1B:19:00:00:00
         p2p_dst_mac          01:80:C2:00:00:0E
         udp_ttl                1
         udp6_scope           0x0E
         uds_address          /var/run/ptp4l
         #
         # Default interface options
         #
         clock_type             BC
         network_transport    UDPv4
         delay_mechanism        E2E
         time_stamping          hardware
         tsproc_mode            filter
         delay_filter           moving_median
         delay_filter_length  10
         egressLatency          0
         ingressLatency         0
         boundary_clock_jbod  0 9
         #
         # Clock description
         #
         productDescription    ;;
         revisionData            ;;
         manufacturerIdentity  00:00:00
         userDescription         ;
         timeSource              0xA0
       phc2sysOpts: "-a -r" 10
       ptpSchedulingPolicy: SCHED_OTHER 11
       ptpSchedulingPriority: 10 12
     recommend: 13
     - profile: "profile1" 14
       priority: 10 15
       match: 16
       - nodeLabel: "node-role.kubernetes.io/worker" 17
         nodeName: "compute-0.example.com" 18

   1

   PtpConfig CR の名前。

   2

   1 つ以上の profile オブジェクトの配列を指定します。

   3

   プロファイルオブジェクトを一意に識別するプロファイルオブジェクトの名前を指定します。

   4

   このフィールドは、境界クロックの場合は空のままにする必要があります。

   5

   ptp4l サービスのシステム設定オプション (例: -2) を指定します。ネットワークインターフェイス名とサービス設定ファイルが自動的に追加されるため、オプションには、ネットワークインターフェイス名 -i <interface> およびサービス設定ファイル -f /etc/ptp4l.conf を含めないでください。

   6

   ptp4l を境界クロックとして起動するために必要な設定を指定します。たとえば、ens1f0 はグランドマスタークロックから同期し、ens1f3 は接続されたデバイスを同期します。

   7

   同期元のインターフェイス名。

   8

   インターフェイスに接続されたデバイスを同期するインターフェイス。

   9

   Intel Columbiaville 800 Series NIC の場合、boundary_clock_jbod が 0 に設定されていることを確認します。Intel Fortville X710 シリーズ NIC の場合、boundary_clock_jbod が 1 に設定されていることを確認します。

   10

   phc2sys サービスのシステム設定オプション (例: -a -r) を指定します。このフィールドが空の場合、PTP Operator は phc2sys サービスを開始しません。

   11

   ptp4l と phc2sys プロセスのスケジューリングポリシー。デフォルト値は SCHED_OTHER です。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO を使用してください。

   12

   ptp SchedulingPolicy が SCHED_FIFO に設定されている場合に、ptp4l および phc2sys プロセスの FIFO の優先度を設定するために使用される 1-65 の整数値。ptpSchedulingPriority フィールドは、ptpSchedulingPolicy が SCHED_OTHER に設定されている場合は使用されません。

   13

   profile がノードに適用される方法を定義する 1 つ以上の recommend オブジェクトの配列を指定します。

   14

   profile セクションに定義される profile オブジェクト名を指定します。

   15

   0 から 99 までの整数値で priority を指定します。数値が大きいほど優先度が低くなるため、99 の優先度は 10 よりも低くなります。ノードが match フィールドで定義されるルールに基づいて複数のプロファイルに一致する場合、優先順位の高いプロファイルがそのノードに適用されます。

   16

   match ルールを、nodeLabel または nodeName で指定します。

   17

   oc get nodes --show-labels コマンドを使用して、ノードオブジェクトのnode.LabelsのkeyでnodeLabelを指定します。

   18

   oc get nodesコマンドを使用して、ノードオブジェクトのnode.NameでnodeNameを指定します。

2. 以下のコマンドを実行して CR を作成します。

   $ oc create -f boundary-clock-ptp-config.yaml

検証手順

1. PtpConfig プロファイルがノードに適用されていることを確認します。

   1. 以下のコマンドを実行して、openshift-ptp namespace の Pod の一覧を取得します。

      $ oc get pods -n openshift-ptp -o wide

      出力例

      NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE
      linuxptp-daemon-4xkbb           1/1     Running   0          43m   10.1.196.24      compute-0.example.com
      linuxptp-daemon-tdspf           1/1     Running   0          43m   10.1.196.25      compute-1.example.com
      ptp-operator-657bbb64c8-2f8sj   1/1     Running   0          43m   10.129.0.61      control-plane-1.example.com

   2. プロファイルが正しいことを確認します。PtpConfig プロファイルで指定したノードに対応する linuxptp デーモンのログを検査します。以下のコマンドを実行します。

      $ oc logs linuxptp-daemon-4xkbb -n openshift-ptp -c linuxptp-daemon-container

      出力例

      I1115 09:41:17.117596 4143292 daemon.go:107] in applyNodePTPProfile
      I1115 09:41:17.117604 4143292 daemon.go:109] updating NodePTPProfile to:
      I1115 09:41:17.117607 4143292 daemon.go:110] ------------------------------------
      I1115 09:41:17.117612 4143292 daemon.go:102] Profile Name: profile1
      I1115 09:41:17.117616 4143292 daemon.go:102] Interface:
      I1115 09:41:17.117620 4143292 daemon.go:102] Ptp4lOpts: -2
      I1115 09:41:17.117623 4143292 daemon.go:102] Phc2sysOpts: -a -r
      I1115 09:41:17.117626 4143292 daemon.go:116] ------------------------------------

手順

1. Ptp Config CR プロファイルを編集します。

   $ oc edit PtpConfig -n openshift-ptp

2. ptp Scheduling Policy と ptp Scheduling Priority フィールドを変更します。

   apiVersion: ptp.openshift.io/v1
   kind: PtpConfig
   metadata:
     name: <ptp_config_name>
     namespace: openshift-ptp
   ...
   spec:
     profile:
     - name: "profile1"
   ...
       ptpSchedulingPolicy: SCHED_FIFO 1
       ptpSchedulingPriority: 10 2

   1

   ptp4l と phc2sys プロセスのスケジューリングポリシー。FIFO スケジューリングをサポートするシステムでは、SCHED_FIFO を使用してください。

   2

   必須。ptp4l および phc2sys プロセスの FIFO 優先度の設定に使用する 1～65 の整数値を設定します。

3. 保存して終了すると、Ptp ConfigCR に変更が適用されます。

検証

1. Ptp ConfigCR が適用された linuxptp-daemon Pod と対応するノードの名前を取得します。

   $ oc get pods -n openshift-ptp -o wide

   出力例

   NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
   linuxptp-daemon-gmv2n           3/3     Running   0          1d17h   10.1.196.24   compute-0.example.com
   linuxptp-daemon-lgm55           3/3     Running   0          1d17h   10.1.196.25   compute-1.example.com
   ptp-operator-3r4dcvf7f4-zndk7   1/1     Running   0          1d7h    10.129.0.61   control-plane-1.example.com

2. ptp4l プロセスが、更新された chrtFIFO 優先度で実行されていることを確認します。

   $ oc -n openshift-ptp logs linuxptp-daemon-lgm55 -c linuxptp-daemon-container|grep chrt

   出力例

   I1216 19:24:57.091872 1600715 daemon.go:285] /bin/chrt -f 65 /usr/sbin/ptp4l -f /var/run/ptp4l.0.config -2  --summary_interval -4 -m

手順

1. Operator およびオペランドが、設定されたノードについてクラスターに正常にデプロイされていることを確認します。

   $ oc get pods -n openshift-ptp -o wide

   出力例

   NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
   linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
   linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
   ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

   注記

   PTP 高速イベントバスが有効な場合には、準備できた linuxptp-daemon Pod の数は 3/3 になります。PTP 高速イベントバスが有効になっていない場合、2/2 が表示されます。

2. サポートされているハードウェアがクラスターにあることを確認します。

   $ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io

   出力例

   NAME                                  AGE
   control-plane-0.example.com           10d
   control-plane-1.example.com           10d
   compute-0.example.com                 10d
   compute-1.example.com                 10d
   compute-2.example.com                 10d

3. ノードで利用可能な PTP ネットワークインターフェイスを確認します。

   $ oc -n openshift-ptp get nodeptpdevices.ptp.openshift.io <node_name> -o yaml

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

   <node_name>

   問い合わせるノードを指定します (例: compute-0.example.com )。

   出力例

   apiVersion: ptp.openshift.io/v1
   kind: NodePtpDevice
   metadata:
     creationTimestamp: "2021-09-14T16:52:33Z"
     generation: 1
     name: compute-0.example.com
     namespace: openshift-ptp
     resourceVersion: "177400"
     uid: 30413db0-4d8d-46da-9bef-737bacd548fd
   spec: {}
   status:
     devices:
     - name: eno1
     - name: eno2
     - name: eno3
     - name: eno4
     - name: enp5s0f0
     - name: enp5s0f1

4. 対応するノードの linuxptp-daemon Pod にアクセスし、PTP インターフェイスがプライマリークロックに正常に同期されていることを確認します。

   1. 以下のコマンドを実行して、linuxptp-daemon Pod の名前と、トラブルシューティングに使用するノードを取得します。

      $ oc get pods -n openshift-ptp -o wide

      出力例

      NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE
      linuxptp-daemon-lmvgn           3/3     Running   0          4d17h   10.1.196.24   compute-0.example.com
      linuxptp-daemon-qhfg7           3/3     Running   0          4d17h   10.1.196.25   compute-1.example.com
      ptp-operator-6b8dcbf7f4-zndk7   1/1     Running   0          5d7h    10.129.0.61   control-plane-1.example.com

   2. リモートシェルが必要な linuxptp-daemon コンテナーへのリモートシェルです。

      $ oc rsh -n openshift-ptp -c linuxptp-daemon-container <linux_daemon_container>

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

      <linux_daemon_container>

      診断するコンテナーです (例: linuxptp-daemon-lmvgn)。

   3. linuxptp-daemon コンテナーへのリモートシェル接続では、PTP 管理クライアント (pmc) ツールを使用して、ネットワークインターフェイスを診断します。以下の pmc コマンドを実行して、PTP デバイスの同期ステータスを確認します (例: ptp4l)。

      # pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

      ノードがプライマリークロックに正常に同期されたときの出力例

      sending: GET PORT_DATA_SET
          40a6b7.fffe.166ef0-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
              portIdentity            40a6b7.fffe.166ef0-1
              portState               SLAVE
              logMinDelayReqInterval  -4
              peerMeanPathDelay       0
              logAnnounceInterval     -3
              announceReceiptTimeout  3
              logSyncInterval         -4
              delayMechanism          1
              logMinPdelayReqInterval -4
              versionNumber           2