web-dev-qa-db-ja.com

kubernetesノードを再起動する方法は？

ノードのステータスはunknownとして報告されます

"conditions": [
          {
            "type": "Ready",
            "status": "Unknown",
            "lastHeartbeatTime": "2015-11-12T06:03:19Z",
            "lastTransitionTime": "2015-11-12T06:04:03Z",
            "reason": "Kubelet stopped posting node status."
          }

kubectl get nodesがNOTReadyステータスを返す場合。これは何を意味し、これを修正する方法は？

nodeskubernetes
28
user_mda

ノードを取得する

kubectl get nodes

結果：

NAME            STATUS     AGE
192.168.1.157   NotReady   42d
192.168.1.158   Ready      42d
192.168.1.159   Ready      42d

ノードの説明

192.168.1.157のノードにあるNotReadyです。次に、このnotreadyノードをデバッグすると、公式ドキュメントを読むことができます- アプリケーションのイントロスペクションとデバッグ 。

kubectl describe node 192.168.1.157

部分的な結果：

Conditions:
Type          Status          LastHeartbeatTime                       LastTransitionTime                      Reason                  Message
----          ------          -----------------                       ------------------                      ------                  -------
OutOfDisk     Unknown         Sat, 28 Dec 2016 12:56:01 +0000         Sat, 28 Dec 2016 12:56:41 +0000         NodeStatusUnknown       Kubelet stopped posting node status.
Ready         Unknown         Sat, 28 Dec 2016 12:56:01 +0000         Sat, 28 Dec 2016 12:56:41 +0000         NodeStatusUnknown       Kubelet stopped posting node status.

私のノードにOutOfDiskがあり、Kubeletがノードステータスの投稿を停止しました。だから、Ubuntu14.04でdfのコマンドを使用して、ディスク領域を解放する必要がありますメモリの詳細を確認し、docker rmi image_id/image_nameのコマンドを使用しますsuの役割の下で、役に立たない画像を削除できます。

ノードにログイン

192.168.1.157のようにsshを使用してssh [email protected]にログインし、Sudo suで「su」に切り替えます。

Kubeletを再起動します

/etc/init.d/kubelet restart

結果：

stop: Unknown instance: 
kubelet start/running, process 59261

ノードを再度取得する

マスターで：

kubectl get nodes

結果：

NAME            STATUS    AGE
192.168.1.157   Ready     42d
192.168.1.158   Ready     42d
192.168.1.159   Ready     42d

OK、そのノードは正常に動作します。

リファレンスは次のとおりです。 Kubernetes

24
CHENJIAN

次を発行することにより、マスターからノードを削除できます。

kubectl delete node hostname.company.net

NOTReadyステータスは、おそらくマスターがkubeletサービスにアクセスできないことを意味します。クライアントですべてが正常かどうかを確認します。

2
cristi
GET all Nodes

kubectl get nodes

not readyステータスのノードを確認します

そのノードを削除して新しいノードを作成し、クラスターに参加するだけです

Kubectl delete node <node name>

AWS EKSなどの管理サービスを使用している場合、新しいノードが自動的に表示されます。awsconsole reboot node（ec2）から再起動することもできます。

0
Harsh Manvar

私もこの問題を抱えていましたが、Kubernetesの提供内容とすべてのインストール方法に依存しているようです。 Azureでは、acs-engineインストールを使用している場合、実際に実行されているシェルスクリプトを見つけてプロビジョニングできます：

/opt/Azure/containers/provision.sh

より詳細な理解を得るには、それを読み通して、指定されたコマンドを実行してください。私にとっては、ルートとして実行する必要がありました。

systemctl enable kubectl
systemctl restart kubectl

イネーブルが必要かどうかはわかりませんし、これらが特定のインストールで機能するかどうかはわかりませんが、私にとっては確実に機能しました。

0
Chad

ノードが異常であるため、マスターがステータスを取得できない場合-Kubernetesはノードを再起動できない可能性があります。また、ヘルスチェックが機能しない場合、SSHでノードにアクセスすることについて何を期待していますか？

この場合、hard-rebootが必要な場合があります。または、ハードウェアがクラウドにある場合は、プロバイダーに任せることができます。

たとえば、AWS EC2ダッシュボードを使用すると、インスタンスを右クリックして「インスタンス状態」メニューを表示できます。このメニューから、応答しないノードを再起動/終了できます。

これを行う前に、適切な尺度として kubectl cordon node を選択できます。また、ノードが再起動後にクラスターに自動的に再参加しない場合は、 kubectl delete node が正常に戻すプロセスの重要な部分であることがわかります。

ノードが応答しなくなるのはなぜですか？おそらく、ホストオペレーティングシステムが新しい要求をタイムリーに処理することを妨げる方法で、いくつかのリソースが使い果たされた可能性があります。これはディスクでもネットワークでもかまいませんが、より潜行性の高いケースはメモリ不足（OOM）です。これは Linuxの処理が不十分 です。

Kubernetesがノードメモリを安全に管理できるようにするには、次の両方を行うことをお勧めします。

  • 予約 システムのメモリ。
  • ポッドの日和見メモリの指定には十分に注意してください（避けてください）。つまり、メモリに requestsとlimits の異なる値を許可しないでください。

ここでの考え方は、メモリが 非圧縮 であり、bothLinuxとKubernetesであるため、 memory overcommit に関連する複雑さを回避することです。 OOMキラーは、ノードがすでに正常で到達不能になる前にトリガーしない場合があります。

0
nobar