Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第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. ホストの健全性
リンクのコピー

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

$ 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,SchedulingDisabled   1h        v1.6.1+5115d708d7
ocp-master-gjkm       Ready,SchedulingDisabled   1h        v1.6.1+5115d708d7
ocp-master-wc8w       Ready,SchedulingDisabled   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 の健全性のステータスは、任意のマスターインスタンスから etcdctl2 コマンドを実行して確認できます。 

# etcdctl2 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 ホストについての詳細情報を取得するには、以下を実行します。 

# etcdctl2 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.3. ルーターおよびレジストリーの健全性
リンクのコピー

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

$ 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.4. ネットワーク接続
リンクのコピー

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

注記

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

3.4.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
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 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.4.2. ノードインスタンスでの接続性
リンクのコピー

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

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

手順

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

    $ oc new-project sdn-test

  2. httpd アプリケーションをデプロイします。 

    $ oc new-app centos/httpd-24-centos7~https://github.com/openshift/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/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.5. ストレージ
リンクのコピー

マスターインスタンスでは、/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.6. 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.access.redhat.com/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
 127.0.0.0/8
Registries: registry.access.redhat.com (secure), registry.access.redhat.com (secure), docker.io (secure)

3.7. API サービスのステータス
リンクのコピー

OpenShift API サービスの atomic-openshift-master-api.service はすべてのマスターインスタンスで実行されます。サービスのステータスを確認するには、以下を実行します。 

$ systemctl status atomic-openshift-master-api.service
● atomic-openshift-master-api.service - Atomic OpenShift Master API
   Loaded: loaded (/usr/lib/systemd/system/atomic-openshift-master-api.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2017-11-30 11:40:19 EST; 5 days ago
     Docs: https://github.com/openshift/origin
 Main PID: 30047 (openshift)
   Memory: 65.0M
   CGroup: /system.slice/atomic-openshift-master-api.service
           └─30047 /usr/bin/openshift start master api --config=/etc/origin/master/ma...

Dec 06 09:15:49 ocp-master-94zd atomic-openshift-master-api[30047]: I1206 09:15:49.85...
Dec 06 09:15:50 ocp-master-94zd atomic-openshift-master-api[30047]: I1206 09:15:50.96...
Dec 06 09:15:52 ocp-master-94zd atomic-openshift-master-api[30047]: I1206 09:15:52.34...

API サービスは、以下を使用して外部でクエリーできるヘルスチェックを公開します。 

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

3.8. コントローラーロールの検証
リンクのコピー

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

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

cluster-admin ユーザーとして、atomic-openshift-master-controllers サービスを実行するマスターホストを確認します。 

$ 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.9. 適切な最大転送単位 (MTU) サイズの確認
リンクのコピー

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

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

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

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

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

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

前提条件

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

    $ oc get dc docker-registry -o jsonpath='{.spec.template.spec.containers[].env[?(@.name=="OPENSHIFT_DEFAULT_REGISTRY")].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 の初期化を証明書パスで完了できないことを示しています。この問題は、/etc/origin/node/node-config.yaml ファイルに設定される不適切な MTU サイズに関連するものです。

    この問題を解決するには、/etc/origin/node/node-config.yaml 内の 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 サイズを変更するには、/etc/origin/node/node-config.yaml ファイルを変更し、ip コマンドで提供される出力よりも 50 バイト小さい値を設定します。

    たとえば、MTU サイズが 1500 に設定されている場合、MTU サイズを /etc/origin/node/node-config.yaml ファイル内で 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 バイト単位で調整し、このプロセスを繰り返します。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る