Systemctlのデバッグ方法
システムctl start kube-apiserverなどのシステムctlコマンドを使用すると、エラーが表示されることがあります.
ヒントに従ってsystemctl status kube-apiserverを再実行します.サービスでは、類似のプロンプトが表示されます.
ExecStartを見て
実際には、このkube-apiserverコマンドに後続のパラメータを加えて実行中にエラーが発生したことを知っています.だから、手動でこのコマンドを実行すれば、エラーがどこにあるか分かりますが、ここの環境変数は$KUBE_に似ています.LOG_LEVELという変数は、コンパイルされたものではなく、デバッグしにくい.
ここでは、システムサービスのサービスプロファイルを編集し、サービス選択に次のようなものを追加するテクニックがあります.
実稼働時ここ$YOUR_ASRGSは、システムctl statusの後に自分で見たパラメータに置き換えられます.
その後systemctl daemon-reload、startサービスを行うとcat/tmp/systemctlを実行することができる.debugは、特定の実行コマンドを表示し、コピーしてコマンドラインの実行下で特定のエラーを知ることができます.
[root@vultr kubenetes]# systemctl start kube-apiserver
Job for kube-apiserver.service failed because the control process exited with error code. See "systemctl status kube-apiserver.service" and "journalctl -xe" for details.ヒントに従ってsystemctl status kube-apiserverを再実行します.サービスでは、類似のプロンプトが表示されます.
● kube-apiserver.service - Kubernetes API Service
Loaded: loaded (/usr/lib/systemd/system/kube-apiserver.service; disabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Fri 2018-07-20 06:37:05 UTC; 1min 17s ago
Docs: https://github.com/GoogleCloudPlatform/kubernetes
Process: 8208 ExecStart=/usr/bin/kube-apiserver $KUBE_LOGTOSTDERR $KUBE_LOG_LEVEL $KUBE_ETCD_SERVERS $KUBE_API_ADDRESS $KUBE_API_PORT $KUBELET_PORT $KUBE_ALLOW_PRIV $KUBE_SERVICE_ADDRESSES $KUBE_ADMISSION_CONTROL $KUBE_API_ARGS (code=exited, status=203/EXEC)
Jul 20 06:37:05 vultr.guest systemd[1]: kube-apiserver.service: main process exited, code=exited, status=203/EXEC
Jul 20 06:37:05 vultr.guest systemd[1]: Failed to start Kubernetes API Service.
Jul 20 06:37:05 vultr.guest systemd[1]: Unit kube-apiserver.service entered failed state.
Jul 20 06:37:05 vultr.guest systemd[1]: kube-apiserver.service failed.
Jul 20 06:37:05 vultr.guest systemd[1]: kube-apiserver.service holdoff time over, scheduling restart.
Jul 20 06:37:05 vultr.guest systemd[1]: start request repeated too quickly for kube-apiserver.service
Jul 20 06:37:05 vultr.guest systemd[1]: Failed to start Kubernetes API Service.
Jul 20 06:37:05 vultr.guest systemd[1]: Unit kube-apiserver.service entered failed state.
Jul 20 06:37:05 vultr.guest systemd[1]: kube-apiserver.service failed.ExecStartを見て
ExecStart=/usr/bin/kube-apiserver $KUBE_LOGTOSTDERR $KUBE_LOG_LEVEL $KUBE_ETCD_SERVERS $KUBE_API_ADDRESS $KUBE_API_PORT $KUBELET_PORT $KUBE_ALLOW_PRIV $KUBE_SERVICE_ADDRESSES $KUBE_ADMISSION_CONTROL $KUBE_API_ARGS実際には、このkube-apiserverコマンドに後続のパラメータを加えて実行中にエラーが発生したことを知っています.だから、手動でこのコマンドを実行すれば、エラーがどこにあるか分かりますが、ここの環境変数は$KUBE_に似ています.LOG_LEVELという変数は、コンパイルされたものではなく、デバッグしにくい.
ここでは、システムサービスのサービスプロファイルを編集し、サービス選択に次のようなものを追加するテクニックがあります.
ExecStartPre=/bin/bash -l -c 'echo "/usr/bin/kube-apiserver $YOUR_ARGS">/tmp/systemctl.debug'実稼働時ここ$YOUR_ASRGSは、システムctl statusの後に自分で見たパラメータに置き換えられます.
その後systemctl daemon-reload、startサービスを行うとcat/tmp/systemctlを実行することができる.debugは、特定の実行コマンドを表示し、コピーしてコマンドラインの実行下で特定のエラーを知ることができます.