第3章 環境ヘルスチェック

このトピックでは、OpenShift Container Platform クラスターおよび各種コンポーネントの全体的な健全性を確認する手順について、また予想される動作について説明します。

各種コンポーネントの検証プロセスについて把握することは、問題のトラブルシューティングにおける最初のステップになります。問題が発生している場合には、このセクションで提供されるチェックを使用して問題を診断できます。

3.1. 全体的な環境ヘルスチェック

OpenShift Container Platform クラスターの全体的な機能を確認するために、アプリケーションのサンプルをビルドし、デプロイします。

手順
  1. validate という名前の新規プロジェクト、および cakephp-mysql-example テンプレートからアプリケーションのサンプルを作成します。

    $ oc new-project validate
    $ oc new-app cakephp-mysql-example

    ログを確認してからビルドに進みます。

    $ oc logs -f bc/cakephp-mysql-example
  2. ビルドが完了すると、データベースとアプリケーションの 2 つの Pod が実行されるはずです。

    $ oc get pods
    NAME                            READY     STATUS      RESTARTS   AGE
    cakephp-mysql-example-1-build   0/1       Completed   0          1m
    cakephp-mysql-example-2-247xm   1/1       Running     0          39s
    mysql-1-hbk46                   1/1       Running     0          1m
  3. アプリケーション URL にアクセスします。Cake PHP フレームワークの welcome ページが表示されるはずです。URL では cakephp-mysql-example-validate.<app_domain> という形式を使用しています。
  4. 機能の確認後は、validate プロジェクトを削除できます。

    $ oc delete project validate

    プロジェクト内のすべてのリソースも削除されます。

3.2. Prometheus を使用したアラートの作成

OpenShift Container Platform と Prometheus を統合して、ビジュアル情報やアラートを作成し、環境に関する問題が発生する前に診断できるようにします。これらの問題には、ノードの障害、Pod による CPU またはメモリーの過剰な使用などが含まれます。

詳細は、「Prometheus Cluster Monitoring」を参照してください。

3.3. ホストの健全性

クラスターが稼働していることを確認するには、マスターインスタンスに接続し、以下を実行します。

$ oc get nodes
NAME                  STATUS                     AGE       VERSION
ocp-infra-node-1clj   Ready                      1h        v1.6.1+5115d708d7
ocp-infra-node-86qr   Ready                      1h        v1.6.1+5115d708d7
ocp-infra-node-g8qw   Ready                      1h        v1.6.1+5115d708d7
ocp-master-94zd       Ready                      1h        v1.6.1+5115d708d7
ocp-master-gjkm       Ready                      1h        v1.6.1+5115d708d7
ocp-master-wc8w       Ready                      1h        v1.6.1+5115d708d7
ocp-node-c5dg         Ready                      1h        v1.6.1+5115d708d7
ocp-node-ghxn         Ready                      1h        v1.6.1+5115d708d7
ocp-node-w135         Ready                      1h        v1.6.1+5115d708d7

上記のクラスターサンプルから、3 つのマスターホスト、3 つのインフラストラクチャーノードホスト、および 3 つのノードホストで構成されていること、すべて実行中であることが分かります。クラスター内のホストはすべて、この出力に表示されているはずです。

Ready ステータスは、マスターホストがノードホストと通信でき、ノードが Pod を実行できる状態にあることを示します (スケジューリングが無効にされているノードを除く)。

etcd コマンドを実行する前に、etcd.conf ファイルを取得します。

# source /etc/etcd/etcd.conf

etcdctl コマンドを使用して、すべてのマスターインスタンスから基本的な etcd のヘルスステータスを確認できます。

# etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \
  --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS cluster-health
member 59df5107484b84df is healthy: got healthy result from https://10.156.0.5:2379
member 6df7221a03f65299 is healthy: got healthy result from https://10.156.0.6:2379
member fea6dfedf3eecfa3 is healthy: got healthy result from https://10.156.0.9:2379
cluster is healthy

ただし、関連付けられたマスターホストを含め、etcd ホストについての詳細情報を取得するには、以下を実行します。

# etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \
  --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member list
295750b7103123e0: name=ocp-master-zh8d peerURLs=https://10.156.0.7:2380 clientURLs=https://10.156.0.7:2379 isLeader=true
b097a72f2610aea5: name=ocp-master-qcg3 peerURLs=https://10.156.0.11:2380 clientURLs=https://10.156.0.11:2379 isLeader=false
fea6dfedf3eecfa3: name=ocp-master-j338 peerURLs=https://10.156.0.9:2380 clientURLs=https://10.156.0.9:2379 isLeader=false

etcd クラスターがマスターサービスと同じ場所に配置されている場合はすべての etcd ホストにマスターホスト名が含まれますが、etcd サービスが別々のホストで実行されている場合はそれらの etcd ホスト名がすべて一覧表示されます。

注記

etcdctl2 は、v2 データモデルの etcd クラスターのクエリーに使用するフラグが含まれる etcdctl ツールのエイリアスです (v3 データモデルの場合は etcdctl3)。

3.4. ルーターおよびレジストリーの健全性

ルーターサービスが実行されているかどうかを確認するには、以下を実行します。

$ oc -n default get deploymentconfigs/router
NAME      REVISION   DESIRED   CURRENT   TRIGGERED BY
router    1          3         3         config

DESIRED および CURRENT 列の値はノードホストの数に一致しているはずです。

レジストリーのステータスを確認する場合も同じコマンドを使用します。

$ oc -n default get deploymentconfigs/docker-registry
NAME              REVISION   DESIRED   CURRENT   TRIGGERED BY
docker-registry   1          3         3         config
注記

コンテナーイメージレジストリーのインスタンスを複数実行するには、複数プロセスによる書き込みをサポートするバックエンドストレージが必要です。選択したインフラストラクチャープロバイダーにこの機能が含まれていない場合には、コンテナーイメージレジストリーの単一インスタンスの実行が許可されます。

すべての Pod が実行中であること、およびどのホストで実行中であるかを確認するには、以下を実行します。

$ oc -n default get pods -o wide
NAME                       READY     STATUS    RESTARTS   AGE       IP            NODE
docker-registry-1-54nhl    1/1       Running   0          2d        172.16.2.3    ocp-infra-node-tl47
docker-registry-1-jsm2t    1/1       Running   0          2d        172.16.8.2    ocp-infra-node-62rc
docker-registry-1-qbt4g    1/1       Running   0          2d        172.16.14.3   ocp-infra-node-xrtz
registry-console-2-gbhcz   1/1       Running   0          2d        172.16.8.4    ocp-infra-node-62rc
router-1-6zhf8             1/1       Running   0          2d        10.156.0.4    ocp-infra-node-62rc
router-1-ffq4g             1/1       Running   0          2d        10.156.0.10   ocp-infra-node-tl47
router-1-zqxbl             1/1       Running   0          2d        10.156.0.8    ocp-infra-node-xrtz
注記

OpenShift Container Platform が外部コンテナーイメージレジストリーを使用している場合、内部レジストリーサービスは実行中である必要がありません。

3.5. ネットワーク接続

ネットワーク接続には、ノードの対話用のクラスターネットワークと Pod の対話用の SDN (Software Defined Network) という 2 つの主要なネットワーク層が含まれます。OpenShift Container Platform は複数のネットワーク設定をサポートし、これらの設定は特定のインフラストラクチャープロバイダー向けに最適化されることがよくあります。

注記

ネットワークが複雑であることから、本書ではすべての検証シナリオについては扱いません。

3.5.1. マスターホストでの接続性

etcd およびマスターホスト

マスターサービスは etcd キー値ストアを使用してそれらの同期状態を維持します。マスターと etcd サービス間の通信は、それらの etcd サービスがマスターホストの同じ場所に置かれている場合でも、etcd サービス用にのみ指定されるホストで実行されている場合でも重要になります。この通信は TCP ポート 2379 および 2380 で実行されます。この通信をチェックする方法については、「ホストの健全性」のセクションを参照してください。

SkyDNS

SkyDNS は、OpenShift Container Platform で実行されるローカルサービスの名前解決を行います。このサービスは TCP および UDP ポート 8053 を使用します。

名前解決を確認するには、以下を実行します。

$ dig +short docker-registry.default.svc.cluster.local
172.30.150.7

応答が以下の出力に一致する場合、SkyDNS サービスは適切に機能していることになります。

$ oc get svc/docker-registry -n default
NAME              CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
docker-registry   172.30.150.7   <none>        5000/TCP   3d

API サービスおよび Web コンソール

API サービスおよび Web コンソールはどちらも同じポート (セットアップによって異なりますが、通常は TCP 8443 または 443) を共有します。このポートはクラスター内で、またデプロイされた環境で作業する必要のあるすべてのユーザーにとって利用可能な状態である必要があります。このポートに到達するために使用される URL は内部クラスターおよび外部クライアント用に異なる場合があります。

以下の例では、https://internal-master.example.com:443 URL は内部クラスターによって使用され、https://master.example.com:443 URL は外部クライアントによって使用されています。任意のノードホストで以下を実行します。

$ curl -k https://internal-master.example.com:443/version
{
  "major": "1",
  "minor": "6",
  "gitVersion": "v1.6.1+5115d708d7",
  "gitCommit": "fff65cf",
  "gitTreeState": "clean",
  "buildDate": "2017-10-11T22:44:25Z",
  "goVersion": "go1.7.6",
  "compiler": "gc",
  "platform": "linux/amd64"
}

これはクライアントのネットワークから到達可能である必要があります。

$ curl -k https://master.example.com:443/healthz
ok

3.5.2. ノードインスタンスでの接続性

Pod の通信に使用されるノードでの SDN 接続は、デフォルトで UDP ポート 4789 を使用します。

ノードホストの機能を確認するには、新規アプリケーションを作成します。以下の例では、ノードがインフラストラクチャーノードで実行されているコンテナーイメージレジストリーに到達できるようになっています。

手順
  1. 新規プロジェクトを作成します。

    $ oc new-project sdn-test
  2. httpd アプリケーションをデプロイします。

    $ oc new-app centos/httpd-24-centos7~https://github.com/sclorg/httpd-ex

    ビルドが完了するまで待機します。

    $ oc get pods
    NAME               READY     STATUS      RESTARTS   AGE
    httpd-ex-1-205hz   1/1       Running     0          34s
    httpd-ex-1-build   0/1       Completed   0          1m
  3. 実行中の Pod に接続します。

    $ oc rsh po/<pod-name>

    例:

    $ oc rsh po/httpd-ex-1-205hz
  4. 内部レジストリーサービスの healthz パスを確認します。

    $ curl -kv https://docker-registry.default.svc.cluster.local:5000/healthz
    * About to connect() to docker-registry.default.svc.cluster.locl port 5000 (#0)
    *   Trying 172.30.150.7...
    * Connected to docker-registry.default.svc.cluster.local (172.30.150.7) port 5000 (#0)
    * Initializing NSS with certpath: sql:/etc/pki/nssdb
    * skipping SSL peer certificate verification
    * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    * Server certificate:
    * 	subject: CN=172.30.150.7
    * 	start date: Nov 30 17:21:51 2017 GMT
    * 	expire date: Nov 30 17:21:52 2019 GMT
    * 	common name: 172.30.150.7
    * 	issuer: CN=openshift-signer@1512059618
    > GET /healthz HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: docker-registry.default.svc.cluster.local:5000
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Cache-Control: no-cache
    < Date: Mon, 04 Dec 2017 16:26:49 GMT
    < Content-Length: 0
    < Content-Type: text/plain; charset=utf-8
    <
    * Connection #0 to host docker-registry.default.svc.cluster.local left intact
    
    sh-4.2$ *exit*

    HTTP/1.1 200 OK 応答は、ノードが適切に接続されていることを示しています。

  5. テストプロジェクトをクリーンアップします。

    $ oc delete project sdn-test
    project "sdn-test" deleted
  6. ノードホストは TCP ポート 10250 をリッスンしています。このポートはノード上のすべてのマスターからアクセスできる必要があり、モニターがクラスターにデプロイされる場合には、インフラストラクチャーノードがすべてのインスタンスのこのポートにアクセスできる必要もあります。このポートで中断されている通信は以下のコマンドで検出できます。

    $ oc get nodes
    NAME                  STATUS                     AGE       VERSION
    ocp-infra-node-1clj   Ready                      4d        v1.6.1+5115d708d7
    ocp-infra-node-86qr   Ready                      4d        v1.6.1+5115d708d7
    ocp-infra-node-g8qw   Ready                      4d        v1.6.1+5115d708d7
    ocp-master-94zd       Ready,SchedulingDisabled   4d        v1.6.1+5115d708d7
    ocp-master-gjkm       Ready,SchedulingDisabled   4d        v1.6.1+5115d708d7
    ocp-master-wc8w       Ready,SchedulingDisabled   4d        v1.6.1+5115d708d7
    ocp-node-c5dg         Ready                      4d        v1.6.1+5115d708d7
    ocp-node-ghxn         Ready                      4d        v1.6.1+5115d708d7
    ocp-node-w135         NotReady                   4d        v1.6.1+5115d708d7

    上記の出力では、ocp-node-w135 ノードのノードサービスにマスターサービスが到達できません。これは NotReady ステータスで表されています。

  7. 最後のサービスは、通信のルートを OpenShift Container Platform クラスターで実行される適切なサービスに指定するルーターです。ルーターは ingress トラフィック用のインフラストラクチャーノードの TCP ポート 80 および 443 をリッスンします。ルーターを機能させる前に、DNS が設定される必要があります。

    $ dig *.apps.example.com
    
    ; <<>> DiG 9.11.1-P3-RedHat-9.11.1-8.P3.fc27 <<>> *.apps.example.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45790
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;*.apps.example.com.	IN	A
    
    ;; ANSWER SECTION:
    *.apps.example.com. 3571	IN	CNAME	apps.example.com.
    apps.example.com.	3561	IN	A	35.xx.xx.92
    
    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Tue Dec 05 16:03:52 CET 2017
    ;; MSG SIZE  rcvd: 105

    IP アドレス (この場合は 35.xx.xx.92) は、ingress トラフィックをすべてのインフラストラクチャーノードに分散させるロードバランサーをポイントするはずです。ルートの機能を確認するには、レジストリーサービスを再度チェックする必要がありますが、今回はこれをクラスター外から実行します。

    $ curl -kv https://docker-registry-default.apps.example.com/healthz
    *   Trying 35.xx.xx.92...
    * TCP_NODELAY set
    * Connected to docker-registry-default.apps.example.com (35.xx.xx.92) port 443 (#0)
    ...
    < HTTP/2 200
    < cache-control: no-cache
    < content-type: text/plain; charset=utf-8
    < content-length: 0
    < date: Tue, 05 Dec 2017 15:13:27 GMT
    <
    * Connection #0 to host docker-registry-default.apps.example.com left intact

3.6. ストレージ

マスターインスタンスでは、/var ディレクトリーに 40 GB 以上のディスク容量が必要です。df コマンドを使用してマスターホストのディスク使用量を確認します。

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sda1      xfs        45G  2.8G   43G   7% /
devtmpfs       devtmpfs  3.6G     0  3.6G   0% /dev
tmpfs          tmpfs     3.6G     0  3.6G   0% /dev/shm
tmpfs          tmpfs     3.6G   63M  3.6G   2% /run
tmpfs          tmpfs     3.6G     0  3.6G   0% /sys/fs/cgroup
tmpfs          tmpfs     732M     0  732M   0% /run/user/1000
tmpfs          tmpfs     732M     0  732M   0% /run/user/0

ノードインスタンスでは /var ディレクトリーに 15 GB 以上を、Docker ストレージ (この場合は /var/lib/docker) にさらに 15 GB 以上が必要です。クラスターのサイズや Pod に必要な一時的なストレージの容量に応じて、別のパーティションをノード上の /var/lib/origin/openshift.local.volumes に作成する必要があります。

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sda1      xfs        25G  2.4G   23G  10% /
devtmpfs       devtmpfs  3.6G     0  3.6G   0% /dev
tmpfs          tmpfs     3.6G     0  3.6G   0% /dev/shm
tmpfs          tmpfs     3.6G  147M  3.5G   4% /run
tmpfs          tmpfs     3.6G     0  3.6G   0% /sys/fs/cgroup
/dev/sdb       xfs        25G  2.7G   23G  11% /var/lib/docker
/dev/sdc       xfs        50G   33M   50G   1% /var/lib/origin/openshift.local.volumes
tmpfs          tmpfs     732M     0  732M   0% /run/user/1000

Pod の永続ストレージは OpenShift Container Platform クラスターを実行するインスタンス以外で処理される必要があります。Pod の永続ボリュームはインフラストラクチャープロバイダーによってプロビジョニングされるか、または Container Native Storage または Container Ready Storage を使用してプロビジョニングできます。

3.7. Docker ストレージ

Docker ストレージは 2 つのオプションのどちらかでサポートされます。1 つ目のオプションはデバイスマッパーを使用したシンプール論理ボリュームで、2 つ目のオプションは overlay2 ファイルシステム (Red Hat Enterprise Linux バージョン 7.4 以降) です。通常はセットアップが容易でパフォーマンスが強化されるので、overlay2 ファイルシステムが推奨されます。

Docker ストレージディスクは /var/lib/docker としてマウントされ、xfs ファイルシステムでフォーマットされます。Docker ストレージは overlay2 ファイルシステムを使用するように設定されます。

$ cat /etc/sysconfig/docker-storage
DOCKER_STORAGE_OPTIONS='--storage-driver overlay2'

このストレージドライバーが Docker によって使用されることを確認するには、以下を実行します。

# docker info
Containers: 4
 Running: 4
 Paused: 0
 Stopped: 0
Images: 4
Server Version: 1.12.6
Storage Driver: overlay2
 Backing Filesystem: xfs
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: overlay host bridge null
 Authorization: rhel-push-plugin
Swarm: inactive
Runtimes: docker-runc runc
Default Runtime: docker-runc
Security Options: seccomp selinux
Kernel Version: 3.10.0-693.11.1.el7.x86_64
Operating System: Employee SKU
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 3
CPUs: 2
Total Memory: 7.147 GiB
Name: ocp-infra-node-1clj
ID: T7T6:IQTG:WTUX:7BRU:5FI4:XUL5:PAAM:4SLW:NWKL:WU2V:NQOW:JPHC
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://registry.redhat.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
 127.0.0.0/8
Registries: registry.redhat.io (secure), registry.redhat.io (secure), docker.io (secure)

3.8. API サービスのステータス

OpenShift API サービスはすべてのマスターインスタンスで実行されす。サービスのステータスを確認するには、kube-system プロジェクトで master-api Pod を表示します。

oc get pod -n kube-system -l openshift.io/component=api

NAME                             READY     STATUS    RESTARTS   AGE
master-api-myserver.com          1/1       Running   0          56d

API サービスはヘルスチェックを公開します。これは、API ホスト名を使用して外部からクエリーできます。 API サービスと Webコンソールの両方が、セットアップに応じて同じポート(通常はTCP 8443 または 443)を共有します。このポートは、クラスター内で利用可能にし、またデプロイされた環境で作業する必要があるすべての人が利用できる必要があります。

oc get pod -n kube-system -o wide
NAME                                               READY     STATUS    RESTARTS   AGE       IP            NODE
master-api-myserver.com                            1/1       Running   0          7h        10.240.0.16   myserver.com

$ curl -k https://myserver.com:443/healthz 1
ok
1
これは、クライアントのネットワークから到達可能でなければなりません。この例の Web コンソールポートは 443 です。 OpenShift Container Platformをデプロイする前に、ホストインベントリーファイルで openshift_master_console_port に設定された値を指定します。openshift_master_console_port がインベントリーファイルに含まれていない場合、ポート 8443 がデフォルトで設定されます。

3.9. コントローラーロールの検証

OpenShift Container Platform コントローラーサービスはすべてのマスターホストで利用できます。このサービスはアクティブ/パッシブモードで実行され、常に 1 つのマスターでのみ実行されます。

OpenShift Container Platform コントローラーは、このサービスを実行するホストを選択する手順を実行します。現在実行されている値は、kube-system プロジェクトに保存される特殊な configmap のアノテーションに保存されます。

cluster-admin ユーザーとしてコントローラーサービスを実行するマスターホストを確認します。

$ oc get -n kube-system cm openshift-master-controllers -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"master-ose-master-0.example.com-10.19.115.212-dnwrtcl4","leaseDurationSeconds":15,"acquireTime":"2018-02-17T18:16:54Z","renewTime":"2018-02-19T13:50:33Z","leaderTransitions":16}'
  creationTimestamp: 2018-02-02T10:30:04Z
  name: openshift-master-controllers
  namespace: kube-system
  resourceVersion: "17349662"
  selfLink: /api/v1/namespaces/kube-system/configmaps/openshift-master-controllers
  uid: 08636843-0804-11e8-8580-fa163eb934f0

コマンドは、以下のように control-plane.alpha.kubernetes.io/leader アノテーションの holderIdentity プロパティー内に現在のマスターコントローラーを出力します。

master-<hostname>-<ip>-<8_random_characters>

以下のコマンドを使用して出力をフィルターし、マスターホストのホスト名を検索します。

$ oc get -n kube-system cm openshift-master-controllers -o json | jq -r '.metadata.annotations[] | fromjson.holderIdentity | match("^master-(.*)-[0-9.]*-[0-9a-z]{8}$") | .captures[0].string'
ose-master-0.example.com

3.10. 適切な最大転送単位 (MTU) サイズの確認

最大転送単位 (MTU) を確認することにより、SSL 証明書の問題としてマスカレードを生じさせる可能性のあるネットワークの誤設定を防ぐことができます。

パケットが HTTP で送信される MTU サイズよりも大きくなる場合、物理ネットワークルーターはデータを送信するためにパケットを複数のパケットに分割できます。ただし、パケットが HTTPS で送信される MTU サイズよりも大きいと、ルーターはそのパケットのドロップを強制的に実行します。

インストールでは、以下を含む複数コンポーネントへのセキュアな通信を提供する証明書を生成します。

  • マスターホスト
  • ノードホスト
  • インフラストラクチャーノード
  • レジストリー
  • ルーター

これらの証明書は、マスターノードの場合は /etc/origin/master ディレクトリーに、インフラおよびアプリケーションノード場合は /etc/origin/node ディレクトリーに配置されています。

インストール後に、「ネットワーク接続」のセクションに説明されているプロセスを使用して REGISTRY_OPENSHIFT_SERVER_ADDR への接続を確認できます。

前提条件
  1. マスターホストから HTTPS アドレスを取得します。

    $ oc -n default get dc docker-registry -o jsonpath='{.spec.template.spec.containers[].env[?(@.name=="REGISTRY_OPENSHIFT_SERVER_ADDR")].value}{"\n"}'
    docker-registry.default.svc:5000

    上記により、docker-registry.default.svc:5000 の出力が生成されます。

  2. /healthz を上記で指定される値に追加し、これを使用してすべてのホスト (マスター、インフラストラクチャー、ノード) で確認します。

    $ curl -v https://docker-registry.default.svc:5000/healthz
    * About to connect() to docker-registry.default.svc port 5000 (#0)
    *   Trying 172.30.11.171...
    * Connected to docker-registry.default.svc (172.30.11.171) port 5000 (#0)
    * Initializing NSS with certpath: sql:/etc/pki/nssdb
    *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
      CApath: none
    * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    * Server certificate:
    * 	subject: CN=172.30.11.171
    * 	start date: Oct 18 05:30:10 2017 GMT
    * 	expire date: Oct 18 05:30:11 2019 GMT
    * 	common name: 172.30.11.171
    * 	issuer: CN=openshift-signer@1508303629
    > GET /healthz HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: docker-registry.default.svc:5000
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Cache-Control: no-cache
    < Date: Tue, 24 Oct 2017 19:42:35 GMT
    < Content-Length: 0
    < Content-Type: text/plain; charset=utf-8
    <
    * Connection #0 to host docker-registry.default.svc left intact

    上記の出力例は、SSL 接続が正常であることを確認するために使用されている MTU サイズを示しています。接続の試行が正常に実行されると接続が確立し、証明書パスと docker-registry に関するすべてのサーバー証明書情報を使った NSS の初期化が完了します。

    MTU サイズが不適切に設定されているとタイムアウトが生じます。

    $ curl -v https://docker-registry.default.svc:5000/healthz
    * About to connect() to docker-registry.default.svc port 5000 (#0)
    *   Trying 172.30.11.171...
    * Connected to docker-registry.default.svc (172.30.11.171) port 5000 (#0)
    * Initializing NSS with certpath: sql:/etc/pki/nssdb

    上記の例では、接続が確立されていますが、証明書パスが指定された NSS の初期化を完了できません。この問題は、ノード設定マップに設定される不適切な MTU サイズに関連するものです。

    この問題を解決するには、ノード設定マップ内の MTU サイズを OpenShift SDN イーサネットデバイスで使用されている MTU サイズよりも 50 バイト小さい値に調整します。

  3. 必要なイーサネットデバイスの MTU サイズを表示します (例: eth0)。

    $ ip link show eth0
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
        link/ether fa:16:3e:92:6a:86 brd ff:ff:ff:ff:ff:ff

    上記は MTU が 1500 に設定されていることを示しています。

  4. MTU サイズを変更するには、適切なノード設定マップを変更し、ip コマンドの出力よりも 50 バイト小さい値に設定します。

    たとえば、MTU サイズが 1500 の場合、ノード設定マップ内で MTU サイズを 1450 に調整します。

    networkConfig:
       mtu: 1450
  5. 変更を保存し、ノードを再起動します。

    注記

    OpenShift Container Platform SDN を構成するすべてのマスターおよび ノードで MTU サイズを変更する必要があります。また、tun0 インターフェースの MTU サイズはクラスターを構成するすべてのノードで同一である必要があります。

  6. ノードが再度オンラインになった後に、元の curl コマンドを再度実行して問題が存在しなくなっていることを確認します。

    $ curl -v https://docker-registry.default.svc:5000/healthz

    タイムアウトが持続する場合、引き続き MTU サイズを 50 バイト単位で調整し、このプロセスを繰り返します。