第3章 環境ヘルスチェック
このトピックでは、OpenShift Container Platform クラスターおよび各種コンポーネントの全体的な健全性を確認する手順について、また予想される動作について説明します。
各種コンポーネントの検証プロセスについて把握することは、問題のトラブルシューティングにおける最初のステップになります。問題が発生している場合には、このセクションで提供されるチェックを使用して問題を診断できます。
3.1. 全体的な環境ヘルスチェック
OpenShift Container Platform クラスターの全体的な機能を確認するために、アプリケーションのサンプルをビルドし、デプロイします。
手順
validate
という名前の新規プロジェクト、およびcakephp-mysql-example
テンプレートからアプリケーションのサンプルを作成します。$ oc new-project validate $ oc new-app cakephp-mysql-example
ログを確認してからビルドに進みます。
$ oc logs -f bc/cakephp-mysql-example
ビルドが完了すると、データベースとアプリケーションの 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
-
アプリケーション URL にアクセスします。Cake PHP フレームワークの welcome ページが表示されるはずです。URL では
cakephp-mysql-example-validate.<app_domain>
という形式を使用しています。 機能の確認後は、
validate
プロジェクトを削除できます。$ oc delete project validate
プロジェクト内のすべてのリソースも削除されます。
3.2. Prometheus を使用した警告の作成
OpenShift Container Platform と Prometheus を統合して、ビジュアルや警告を作成し、環境の問題が発生する前に診断できるようにします。このような問題として考えられるのは、ノードのダウン、Pod による CPU またはメモリーの過剰使用などです。
詳細は、『クラスター設定ガイド』の「OpenShift Container Platform での Prometheus の設定」セクションを参照してください。
OpenShift Container Platform 上での Prometheus はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
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,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.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
コンテナーレジストリーのインスタンスを複数実行するには、複数プロセスによる書き込みをサポートするバックエンドストレージが必要です。選択したインフラストラクチャープロバイダーにこの機能が含まれていない場合には、コンテナーレジストリーのインスタンスを 1 つ実行できます。
すべての 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 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
を使用します。
ノードホストの機能を確認するには、新規アプリケーションを作成します。以下の例では、ノードがインフラストラクチャーノードで実行されている docker レジストリーに到達できるようになっています。
手順
新規プロジェクトを作成します。
$ oc new-project sdn-test
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
実行中の Pod に接続します。
$ oc rsh po/<pod-name>
例:
$ oc rsh po/httpd-ex-1-205hz
内部レジストリーサービスの
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
応答は、ノードが適切に接続されていることを示しています。テストプロジェクトをクリーンアップします。
$ oc delete project sdn-test project "sdn-test" deleted
ノードホストは
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
ステータスで表されています。最後のサービスは、通信のルートを 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.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.8. 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.9. コントローラーロールの検証
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.10. 適切な最大転送単位 (MTU) サイズの確認
最大転送単位 (MTU) を確認することにより、SSL 証明書の問題としてマスカレードを生じさせる可能性のあるネットワークの誤設定を防ぐことができます。
パケットが HTTP で送信される MTU サイズよりも大きくなる場合、物理ネットワークルーターはデータを送信するためにパケットを複数のパケットに分割できます。ただし、パケットが HTTPS で送信される MTU サイズよりも大きいと、ルーターはそのパケットのドロップを強制的に実行します。
インストールでは、以下を含む複数コンポーネントへのセキュアな通信を提供する証明書を生成します。
- マスターホスト
- ノードホスト
- インフラストラクチャーノード
- レジストリー
- ルーター
これらの証明書は、マスターノードの場合は /etc/origin/master
ディレクトリーに、インフラおよびアプリケーションノード場合は /etc/origin/node
ディレクトリーに配置されています。
インストール後に、「ネットワーク接続」のセクションに説明されているプロセスを使用して REGISTRY_OPENSHIFT_SERVER_ADDR
への接続を確認できます。
前提条件
マスターホストから 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
の出力が生成されます。/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 サイズが設定されています。
この問題を解決するには、OpenShift SDN Ethernet デバイスが使用する MTU サイズよりも 50 バイト小さい値に、ノード設定マップ内で MTU サイズを調節します。
必要なイーサネットデバイスの 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 に設定されていることを示しています。
MTU サイズを変更するには、適切な「ノード設定マップ」を修正し、
ip
コマンドの出力よりも 50 バイト少ない値に設定します。たとえば、MTU サイズが 1500 の場合は、ノード設定マップ内で MTU サイズを 1450 に調節します。
networkConfig: mtu: 1450
変更を保存し、ノードを再起動します。
注記OpenShift Container Platform SDN を構成するすべてのマスターおよび ノードで MTU サイズを変更する必要があります。また、tun0 インターフェースの MTU サイズはクラスターを構成するすべてのノードで同一である必要があります。
ノードが再度オンラインになった後に、元の
curl
コマンドを再度実行して問題が存在しなくなっていることを確認します。$ curl -v https://docker-registry.default.svc:5000/healthz
タイムアウトが持続する場合、引き続き MTU サイズを 50 バイト単位で調整し、このプロセスを繰り返します。