コンテンツにスキップ

Faq

faq.md# よくある質問

1 初回インストールで問題が発生し、クリーンアップ後に再インストールが必要な場合

注意：初回インストール時に問題が発生し、すべてを削除して再インストールする必要がある場合に限ります。以下のクリーンアップ手順を実行する前に、よく確認してください。

インストールで問題が発生し、すべてを削除して再インストールする必要がある場合は、以下の 3 か所をクリーンアップしてから、Launcher を使用して Guance を再インストールしてください。

1.1 インストール済みの Guance アプリケーションサービスをクリーンアップ

Kubernetes にインストールされた各種 Guance アプリケーションサービスをクリーンアップするには、運用操作マシンから Launcher コンテナに入り、Launcher に付属のクリーンアップスクリプトを実行します。 

kubectl exec -it launcher-xxxxxxxx-xxx -n launcher /bin/bash
launcher-xxxxxxxx-xxx は、お客様の launcher サービスの Pod 名です。

コンテナに入ると、Launcher サービスに付属の k8s-clear.sh スクリプト（1.47.103 以降のバージョンでは、このスクリプトは /config/tools ディレクトリにあります）が表示されます。このスクリプトを実行すると、すべての Guance アプリケーションサービスと k8s リソースがクリーンアップされます。

1.2 MySQL に自動的に作成されたデータベースをクリーンアップ

Launcher コンテナに入ります。Launcher コンテナには mysql クライアントツールが含まれているため、以下のコマンドを使用して Guance MySQL インスタンスに接続します。 

mysql -h <mysql インスタンス host> -u root -P <mysql ポート> -p
mysql 管理者アカウントを使用して接続する必要があります。接続後、以下の 6 つの MySQL データベースとユーザーのクリーンアップコマンドを実行します。 
drop database df_core;
drop user df_core;
drop database df_message_desk;
drop user df_message_desk;
drop database df_func;
drop user df_func;
drop database df_dialtesting;
drop user df_dialtesting;

1.3 InfluxDB に自動的に作成されたユーザーをクリーンアップ

時系列エンジンに InfluxDB を使用している場合は、influx クライアントツールを使用して InfluxDB に接続し、以下の 2 つのユーザークリーンアップコマンドを実行します。 

drop user user_wr;
drop user user_ro;

2 デプロイ時の注意事項

2.1 デプロイ完了後、インストーラーが自動生成した Kubernetes リソースを手動で変更できますか？

手動で変更しないでください。 次回の新バージョンリリース後に Launcher を使用してアップグレードインストールを行うと、インストール時に設定した情報に基づいて Deployment、Service、Ingress などのリソースが再生成されます（Configmap を除く。Configmap の設定項目の情報は手動で任意に変更できますが、変更するとプログラムの動作が異常になる可能性があります）。

3 独立コンテナ Rancher Server の証明書更新

3.1 証明書が期限切れでない場合の対処方法

Rancher Server は正常に動作します。Rancher v2.0.14+、v2.1.9+、v2.2.2+ にアップグレードすると、証明書の有効期限が自動的にチェックされ、期限が近づいていれば新しい証明書が自動的に生成されます。そのため、独立コンテナで動作する Rancher Server では、証明書の期限切れ前に Rancher のバージョンを SSL 証明書の自動更新をサポートするバージョンにアップグレードするだけでよく、他の操作は必要ありません。

3.2 証明書がすでに期限切れの場合の対処方法

Rancher Server は正常に動作しません。Rancher v2.0.14+、v2.1.9+、v2.2.2+ にアップグレードしても、証明書エラーが表示される可能性があります。このような場合は、以下の操作で対処します。

  1. Rancher のバージョンを v2.0.14+、v2.1.9+、v2.2.2+ に正常にアップグレードします。

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

  3. 2.0 または 2.1 バージョン

docker exec -ti <rancher_server_id>mv /var/lib/rancher/management-state/certs/bundle.json /var/lib/rancher/management-state/certs/bundle.json-bak
  • 2.2 +
docker exec -ti <rancher_server_id>mv /var/lib/rancher/management-state/tls/localhost.crt /var/lib/rancher/management-state/tls/localhost.crt-bak
  • 2.3 +
 docker exec -ti <rancher_server_id>mv /var/lib/rancher/k3s/server/tls /var/lib/rancher/k3s/server/tlsbak

 # 2回実行します。1回目は証明書の申請、2回目は証明書のロードと起動のためです。
 docker restart <rancher_server_id>
  • 2.4 +

​ a. Rancher Server に exec で入る

kubectl --insecure-skip-tls-verify -n kube-system delete secrets k3s-serving
kubectl --insecure-skip-tls-verify delete secret serving-cert -n cattle-system
rm -f /var/lib/rancher/k3s/server/tls/dynamic-cert.json

​ b. Rancher Server を再起動

docker restart <rancher_server_id>

​ c. 以下のコマンドを実行してパラメーターを更新

curl --insecure -sfL https://server-url/v3
  1. Rancher Server コンテナを再起動
docker restart <rancher_server_id>

4 Rancher Server の証明書が期限切れで K8s クラスターを管理できない場合の対処

クラスターの証明書がすでに期限切れの場合、Rancher v2.0.14、v2.1.9 以降のバージョンにアップグレードしても証明書を更新できません。Rancher は Agent を介して証明書を更新するため、証明書が期限切れになると Agent に接続できなくなります。

4.1 解決方法

ノードの時間を手動で設定し、時間を少し未来に調整します。Agent は K8S マスターと Rancher Server とのみ通信するため、Rancher Server の証明書が期限切れでない場合は、K8S マスターノードの時間のみを調整すればよいです。 調整コマンド： 

# ntp同期を無効にする。そうしないと時間が自動的に更新される
timedatectl set-ntp false
# ノード時間を変更
timedatectl set-time '2019-01-01 00:00:00'

その後、Rancher Server をアップグレードし、証明書の更新が完了したら時間を同期し直します。 

timedatectl set-ntp true
証明書の有効期限を確認 
openssl x509 -in /etc/kubernetes/ssl/kube-apiserver.pem -noout -dates

5 DataWay を作成したのにフロントエンドに表示されない理由

5.1 よくある原因の分析

  • Dataway サービスがサーバーにデプロイされた後、正常に動作していない。
  • Dataway サービスの設定ファイルが誤っており、正しいリスナーやワークスペーストークン情報が設定されていない。
  • Dataway サービスの実行設定が誤っている。具体的には、dataway のログを確認して特定できる。
  • Dataway をデプロイしたサーバーが kodo サービスと通信できない（Dataway サーバーの hosts に df-kodo サービスの正しい解決が追加されていない場合を含む）。
  • kodo サービスが異常。具体的には、kodo サービスのログを確認して確認できる。
  • df-kodo ingress サービスが正しく設定されていない。具体的には、http|https://df-kodo.<xxxx>:<port> にアクセスできない。

6 Synthetic テストサービスが使用できない理由

6.1 原因の分析

  • デプロイされた Guance アプリケーションがオフライン環境であり、物理ノードのネットワーク環境が外部に出られない。（よくあるケース）
  • 自建プローブノードのネットワークが異常。
  • 地域のプロバイダーネットワークが異常。
  • Synthetic テストの作成エラー。

7 デプロイに関するよくある問題と解決方法

7.1 describe pods で unbound immediate PersistentVolumeClaims エラーが発生する

  • pvc を確認
NAMESPACE    NAME                                     STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
default      opensearch-single-opensearch-single-0    Bound     pvc-0da2cb6f-1cb9-4630-b0ab-512ce57743a8   16Gi       RWO            openebs-hostpath   19d
launcher     persistent-data                          Pending                                                                        df-nfs-storage     6m3s
middleware   data-es-cluster-0                        Bound     pvc-36e48f5a-37b3-4c28-ad14-059265ee3009   50Gi       RWO            openebs-hostpath   18d

persistent-data のステータスが Pending であることを確認。

  • nfs-subdir-external-provisioner コンテナのステータスを確認
kubectl get pods -n kube-system  | grep nfs-subdir-external-provisioner
nfs-provisioner-nfs-subdir-external-provisioner-58b7cdf6f5dr5vr   0/1     ContainerCreating   0             7h7m
  • nfs-provisioner-nfs-subdir-external-provisioner-58b7cdf6f5dr5vr の情報を確認
kubectl describe  -n kube-system pods nfs-provisioner-nfs-subdir-external-provisioner-58b7cdf6f5dr5vr
....
  Type     Reason       Age                     From     Message
  ----     ------       ----                    ----     -------
  Warning  FailedMount  30m (x49 over 6h53m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[nfs-subdir-external-provisioner-root], unattached volumes=[kube-api-access-5p4qn nfs-subdir-external-provisioner-root]: timed out waiting for the condition
  Warning  FailedMount  5m27s (x136 over 7h4m)  kubelet  Unable to attach or mount volumes: unmounted volumes=[nfs-subdir-external-provisioner-root], unattached volumes=[nfs-subdir-external-provisioner-root kube-api-access-5p4qn]: timed out waiting for the condition
  Warning  FailedMount  74s (x217 over 7h6m)    kubelet  MountVolume.SetUp failed for volume "nfs-subdir-external-provisioner-root" : mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t nfs 10.200.14.112:/nfsdata /var/lib/kubelet/pods/3970ff5f-5dbf-419e-a6af-3080508d2524/volumes/kubernetes.io~nfs/nfs-subdir-external-provisioner-root
Output: mount: wrong fs type, bad option, bad superblock on 10.200.14.112:/nfsdata,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

wrong fs type, bad option の原因は nfs-utils がインストールされていないこと。

  • nfs-utils をインストール

ホストで以下のコマンドを実行：

yum install nfs-utils

フィードバック

このページは役に立ちましたか？