jjzjj

kubernetes(K8S)容器部署，重新启动后，node节点提示notready无法正常工作。

争做倒数第二 2023-05-21 原文

打开服务器，查看容器部署k8s组件节点是否正常。

[root@k8s-master01 ~]# kubectl get pod -n kube-system
NAME                                   READY   STATUS        RESTARTS   AGE
coredns-5c98db65d4-28krg               1/1     Terminating   0          47h
coredns-5c98db65d4-7f526               1/1     Running       0          5m18s
coredns-5c98db65d4-dmxnm               1/1     Terminating   0          47h
coredns-5c98db65d4-rx4zk               1/1     Running       0          5m8s
etcd-k8s-master01                      1/1     Running       2          47h
kube-apiserver-k8s-master01            1/1     Running       2          47h
kube-controller-manager-k8s-master01   1/1     Running       2          47h
kube-flannel-ds-amd64-25zmd            1/1     Running       0          22h
kube-flannel-ds-amd64-4b74f            1/1     Running       1          22h
kube-flannel-ds-amd64-s5p55            1/1     Running       0          22h
kube-proxy-2j97j                       1/1     Running       2          47h
kube-proxy-7cvzq                       1/1     Running       0          23h
kube-proxy-cd2fz                       1/1     Running       0          23h
kube-scheduler-k8s-master01            1/1     Running       2          47h

查看状态后，coredns容器组件，有两个为Terminating，但是还是有两个组件corendns为running。可以判断，搭建k8s组件没有问题。

接下来我们查看一下master端和node端节点。

通过命令查看，我们的master节点是准备状态，但是可以看到node节点名反馈的status信息为notready。这样我们可以简单判断去从主机启动到启动k8s组件环节定位问题。

[root@k8s-master01 ~]# kubectl get nodes
NAME           STATUS     ROLES    AGE   VERSION
k8s-master01   Ready      master   47h   v1.15.1
k8s-node01     NotReady   <none>   23h   v1.15.1
k8s-node02     NotReady   <none>   23h   v1.15.1

我们先选择一个node节点去查看一下kubelet启动日志 

[root@root@k8s-master01 ~]# journalctl -f -u kubelet

nodes节点反馈节点为如下：

[root@k8s-node01 ~]# journalctl -f -u kubelet
-- Logs begin at 二 2022-04-19 09:00:31 CST. --
4月 20 15:17:20 k8s-node01 kubelet[4049]: W0420 15:17:20.399757    4049 cni.go:213] Unable to update cni config: No networks found in /etc/cni/net.d
4月 20 15:17:23 k8s-node01 kubelet[4049]: I0420 15:17:23.787316    4049 reconciler.go:203] operationExecutor.VerifyControllerAttachedVolume started for volume "run" (UniqueName: "kubernetes.io/host-path/55c5127c-bc19-41f7-9a2c-9d6d76a9000d-run") pod "kube-flannel-ds-amd64-25zmd" (UID: "55c5127c-bc19-41f7-9a2c-9d6d76a9000d")
4月 20 15:17:23 k8s-node01 kubelet[4049]: I0420 15:17:23.787360    4049 reconciler.go:203] operationExecutor.VerifyControllerAttachedVolume started for volume "cni" (UniqueName: "kubernetes.io/host-path/55c5127c-bc19-41f7-9a2c-9d6d76a9000d-cni") pod "kube-flannel-ds-amd64-25zmd" (UID: "55c5127c-bc19-41f7-9a2c-9d6d76a9000d")
4月 20 15:17:23 k8s-node01 kubelet[4049]: I0420 15:17:23.787391    4049 reconciler.go:203] operationExecutor.VerifyControllerAttachedVolume started for volume "flannel-cfg" (UniqueName: "kubernetes.io/configmap/55c5127c-bc19-41f7-9a2c-9d6d76a9000d-flannel-cfg") pod "kube-flannel-ds-amd64-25zmd" (UID: "55c5127c-bc19-41f7-9a2c-9d6d76a9000d")
4月 20 15:17:23 k8s-node01 kubelet[4049]: I0420 15:17:23.787413    4049 reconciler.go:203] operationExecutor.VerifyControllerAttachedVolume started for volume "flannel-token-xwzkz" (UniqueName: "kubernetes.io/secret/55c5127c-bc19-41f7-9a2c-9d6d76a9000d-flannel-token-xwzkz") pod "kube-flannel-ds-amd64-25zmd" (UID: "55c5127c-bc19-41f7-9a2c-9d6d76a9000d")
4月 20 15:17:24 k8s-node01 kubelet[4049]: E0420 15:17:24.544451    4049 kubelet.go:2169] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
4月 20 15:17:35 k8s-node01 kubelet[4049]: I0420 15:17:35.744285    4049 reconciler.go:203] operationExecutor.VerifyControllerAttachedVolume started for volume "config-volume" (UniqueName: "kubernetes.io/configmap/52817037-d7b1-4d7f-8e21-7b6a8743fb5e-config-volume") pod "coredns-5c98db65d4-28krg" (UID: "52817037-d7b1-4d7f-8e21-7b6a8743fb5e")
4月 20 15:17:35 k8s-node01 kubelet[4049]: I0420 15:17:35.744346    4049 reconciler.go:203] operationExecutor.VerifyControllerAttachedVolume started for volume "coredns-token-j46q8" (UniqueName: "kubernetes.io/secret/52817037-d7b1-4d7f-8e21-7b6a8743fb5e-coredns-token-j46q8") pod "coredns-5c98db65d4-28krg" (UID: "52817037-d7b1-4d7f-8e21-7b6a8743fb5e")
4月 20 15:21:26 k8s-node01 systemd[1]: Stopping kubelet: The Kubernetes Node Agent...
4月 20 15:21:26 k8s-node01 systemd[1]: Stopped kubelet: The Kubernetes Node Agent.

从最后两条日志我们可以判断出，node节点已经停止被代理，那我们可以从kubelet着手去排查一下。因为主机中k8s的master启动顺序为：systemd > kubelet > 容器组件 > kubernetes，而且我们可以通过上述可以看到，我们到第三步容器组件已经全部是running状态，那我们可以从systemd到kubelet来判断一下，因为kubelet是一个应用进程，所以我们查看一下kubelet的状态。

[root@k8s-node01 ~]# systemctl status  kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/usr/lib/systemd/system/kubelet.service; disabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: inactive (dead)
     Docs: https://kubernetes.io/docs/

通过命令行我们看出，kubelet是没有加载起来的。

固我们用重启启动服务的命令，启动一下。

[root@k8s-node01 ~]# systemctl restart kubelet
[root@k8s-node01 ~]# systemctl status  kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/usr/lib/systemd/system/kubelet.service; disabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since 四 2022-04-21 14:15:52 CST; 2s ago
     Docs: https://kubernetes.io/docs/
 Main PID: 1620 (kubelet)
    Tasks: 15
   Memory: 149.4M
   CGroup: /system.slice/kubelet.service
           └─1620 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kube...

4月 21 14:15:54 k8s-node01 kubelet[1620]: E0421 14:15:54.108699    1620 remote_runtime.go:295] ContainerStatus "0...bd418
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.702549    1620 reconciler.go:177] operationExecutor.Unmo...b5e")
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.702603    1620 reconciler.go:177] operationExecutor.UnmountVo...
4月 21 14:15:54 k8s-node01 kubelet[1620]: W0421 14:15:54.702826    1620 empty_dir.go:421] Warning: Failed to clea...abled
4月 21 14:15:54 k8s-node01 kubelet[1620]: W0421 14:15:54.702893    1620 empty_dir.go:421] Warning: Failed to clea...abled
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.702944    1620 operation_generator.go:860] UnmountVolume.Tear...
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.702969    1620 operation_generator.go:860] UnmountVolume.Tear...
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.703035    1620 reconciler.go:297] Volume detached for vo...th ""
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.703043    1620 reconciler.go:297] Volume detached for vo...th ""
4月 21 14:15:55 k8s-node01 kubelet[1620]: W0421 14:15:55.003981    1620 kuberuntime_container.go:691] No ref for ...0e4"}
Hint: Some lines were ellipsized, use -l to show in full.

重启服务以后，我们再次查看kubelet状态，是运行状态。我们看一下node节点的日志。

[root@k8s-node01 ~]# journalctl -f -u kubelet
-- Logs begin at 二 2022-04-19 09:00:31 CST. --
4月 21 14:15:54 k8s-node01 kubelet[1620]: E0421 14:15:54.108699    1620 remote_runtime.go:295] ContainerStatus "0e2e13612e055551f0c33bea49979d5ee2f198e99ca8005618853250397bd418" from runtime service failed: rpc error: code = Unknown desc = Error: No such container: 0e2e13612e055551f0c33bea49979d5ee2f198e99ca8005618853250397bd418
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.702549    1620 reconciler.go:177] operationExecutor.UnmountVolume started for volume "config-volume" (UniqueName: "kubernetes.io/configmap/52817037-d7b1-4d7f-8e21-7b6a8743fb5e-config-volume") pod "52817037-d7b1-4d7f-8e21-7b6a8743fb5e" (UID: "52817037-d7b1-4d7f-8e21-7b6a8743fb5e")
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.702603    1620 reconciler.go:177] operationExecutor.UnmountVolume started for volume "coredns-token-j46q8" (UniqueName: "kubernetes.io/secret/52817037-d7b1-4d7f-8e21-7b6a8743fb5e-coredns-token-j46q8") pod "52817037-d7b1-4d7f-8e21-7b6a8743fb5e" (UID: "52817037-d7b1-4d7f-8e21-7b6a8743fb5e")
4月 21 14:15:54 k8s-node01 kubelet[1620]: W0421 14:15:54.702826    1620 empty_dir.go:421] Warning: Failed to clear quota on /var/lib/kubelet/pods/52817037-d7b1-4d7f-8e21-7b6a8743fb5e/volumes/kubernetes.io~configmap/config-volume: ClearQuota called, but quotas disabled
4月 21 14:15:54 k8s-node01 kubelet[1620]: W0421 14:15:54.702893    1620 empty_dir.go:421] Warning: Failed to clear quota on /var/lib/kubelet/pods/52817037-d7b1-4d7f-8e21-7b6a8743fb5e/volumes/kubernetes.io~secret/coredns-token-j46q8: ClearQuota called, but quotas disabled
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.702944    1620 operation_generator.go:860] UnmountVolume.TearDown succeeded for volume "kubernetes.io/secret/52817037-d7b1-4d7f-8e21-7b6a8743fb5e-coredns-token-j46q8" (OuterVolumeSpecName: "coredns-token-j46q8") pod "52817037-d7b1-4d7f-8e21-7b6a8743fb5e" (UID: "52817037-d7b1-4d7f-8e21-7b6a8743fb5e"). InnerVolumeSpecName "coredns-token-j46q8". PluginName "kubernetes.io/secret", VolumeGidValue ""
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.702969    1620 operation_generator.go:860] UnmountVolume.TearDown succeeded for volume "kubernetes.io/configmap/52817037-d7b1-4d7f-8e21-7b6a8743fb5e-config-volume" (OuterVolumeSpecName: "config-volume") pod "52817037-d7b1-4d7f-8e21-7b6a8743fb5e" (UID: "52817037-d7b1-4d7f-8e21-7b6a8743fb5e"). InnerVolumeSpecName "config-volume". PluginName "kubernetes.io/configmap", VolumeGidValue ""
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.703035    1620 reconciler.go:297] Volume detached for volume "config-volume" (UniqueName: "kubernetes.io/configmap/52817037-d7b1-4d7f-8e21-7b6a8743fb5e-config-volume") on node "k8s-node01" DevicePath ""
4月 21 14:15:54 k8s-node01 kubelet[1620]: I0421 14:15:54.703043    1620 reconciler.go:297] Volume detached for volume "coredns-token-j46q8" (UniqueName: "kubernetes.io/secret/52817037-d7b1-4d7f-8e21-7b6a8743fb5e-coredns-token-j46q8") on node "k8s-node01" DevicePath ""
4月 21 14:15:55 k8s-node01 kubelet[1620]: W0421 14:15:55.003981    1620 kuberuntime_container.go:691] No ref for container {"docker" "92e81d86339b20f5558d2ebe341e46df56fdb411b31cef164bba2b6591a790e4"}

日志显示node1节点正常访问状态。

接下来我们再去回到master节点，使用命令查看一下KS8集群状态。

[root@k8s-master01 ~]# kubectl  get nodes
NAME           STATUS     ROLES    AGE   VERSION
k8s-master01   Ready      master   47h   v1.15.1
k8s-node01     Ready      <none>   23h   v1.15.1
k8s-node02     NotReady   <none>   23h   v1.15.1

可以看到，我们的node1节点通过重启kubelet，已经成为ready状态，那我们接下来只需要把node2节点进行与node1节点同样的操作即可。

[root@k8s-node02 ~]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/usr/lib/systemd/system/kubelet.service; disabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since 四 2022-04-21 14:19:08 CST; 2s ago
     Docs: https://kubernetes.io/docs/
 Main PID: 1637 (kubelet)
    Tasks: 16
   Memory: 147.1M
   CGroup: /system.slice/kubelet.service
           └─1637 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kube...

4月 21 14:19:09 k8s-node02 kubelet[1637]: I0421 14:19:09.686045    1637 reconciler.go:203] operationExecutor.VerifyCon...
4月 21 14:19:09 k8s-node02 kubelet[1637]: I0421 14:19:09.686058    1637 reconciler.go:203] operationExecutor.VerifyCon...
4月 21 14:19:09 k8s-node02 kubelet[1637]: I0421 14:19:09.686070    1637 reconciler.go:203] operationExecutor.Veri...5bb")
4月 21 14:19:09 k8s-node02 kubelet[1637]: I0421 14:19:09.686082    1637 reconciler.go:203] operationExecutor.VerifyCon...
4月 21 14:19:09 k8s-node02 kubelet[1637]: I0421 14:19:09.686093    1637 reconciler.go:203] operationExecutor.Veri...b10")
4月 21 14:19:09 k8s-node02 kubelet[1637]: I0421 14:19:09.686104    1637 reconciler.go:203] operationExecutor.Veri...5bb")
4月 21 14:19:09 k8s-node02 kubelet[1637]: I0421 14:19:09.686210    1637 reconciler.go:203] operationExecutor.Veri...5bb")
4月 21 14:19:09 k8s-node02 kubelet[1637]: I0421 14:19:09.686236    1637 reconciler.go:150] Reconciler: start to s...state
4月 21 14:19:10 k8s-node02 kubelet[1637]: W0421 14:19:10.218389    1637 kuberuntime_container.go:691] No ref for ...28b"}
4月 21 14:19:11 k8s-node02 kubelet[1637]: W0421 14:19:11.336287    1637 pod_container_deletor.go:75] Container "1...iners
Hint: Some lines were ellipsized, use -l to show in full.

最后在查看一下mster节点。

[root@k8s-master01 ~]# kubectl  get nodes
NAME           STATUS   ROLES    AGE   VERSION
k8s-master01   Ready    master   47h   v1.15.1
k8s-node01     Ready    <none>   23h   v1.15.1
k8s-node02     Ready    <none>   23h   v1.15.1

已经启动了，我们的kubetnetes可以正常进行工作了。

到这里，此次故障漏洞可能在于，我们个人通过容器安装kubernetes时，容易忽略kubelet启动服务。所以我们可以在部署的时候，直接将服务设置成开机自启。

[root@k8s-node01 ~]# systemctl enable  kubelet
Created symlink from /etc/systemd/system/multi-user.target.wants/kubelet.service to /usr/lib/systemd/system/kubelet.service.

最后可以关注一下K8S启动流程， 包括部署的时候多注意一些的话，我们是可以避免问题发生。

容器kuberneteskubeletk8s-nodenode云计算

有关kubernetes(K8S)容器部署，重新启动后，node节点提示notready无法正常工作。的更多相关文章

  1. ruby - 如何在续集中重新加载表模式？ - 2

    鉴于我有以下迁移:Sequel.migrationdoupdoalter_table:usersdoadd_column:is_admin,:default=>falseend#SequelrunsaDESCRIBEtablestatement,whenthemodelisloaded.#Atthispoint,itdoesnotknowthatusershaveais_adminflag.#Soitfails.@user=User.find(:email=>"admin@fancy-startup.example")@user.is_admin=true@user.save!ende

  2. ruby-on-rails - active_admin 目录中的常量警告重新声明 - 2

    我正在使用active_admin，我在Rails3应用程序的应用程序中有一个目录管理，其中包含模型和页面的声明。时不时地我也有一个类，当那个类有一个常量时，就像这样:classFooBAR="bar"end然后，我在每个必须在我的Rails应用程序中重新加载一些代码的请求中收到此警告:/Users/pupeno/helloworld/app/admin/billing.rb:12:warning:alreadyinitializedconstantBAR知道发生了什么以及如何避免这些警告吗？ 最佳答案 在纯Ruby中:classA

  3. ruby-on-rails - 启动 Rails 服务器时 ImageMagick 的警告 - 2

    最近，当我启动我的Rails服务器时，我收到了一长串警告。虽然它不影响我的应用程序，但我想知道如何解决这些警告。我的估计是imagemagick以某种方式被调用了两次？当我在警告前后检查我的git日志时。我想知道如何解决这个问题。-bcrypt-ruby(3.1.2)-better_errors(1.0.1)+bcrypt(3.1.7)+bcrypt-ruby(3.1.5)-bcrypt(>=3.1.3)+better_errors(1.1.0)bcrypt和imagemagick有关系吗？/Users/rbchris/.rbenv/versions/2.0.0-p247/lib/ru

  4. ruby-on-rails - 每次我尝试部署时，我都会得到 - (gcloud.preview.app.deploy) 错误响应 : [4] DEADLINE_EXCEEDED - 2

    我是Google云的新手，我正在尝试对其进行首次部署。我的第一个部署是RubyonRails项目。我基本上是在关注thisguideinthegoogleclouddocumentation.唯一的区别是我使用的是我自己的项目，而不是他们提供的“helloworld”项目。这是我的app.yaml文件runtime:customvm:trueentrypoint:bundleexecrackup-p8080-Eproductionconfig.ruresources:cpu:0.5memory_gb:1.3disk_size_gb:10当我转到我的项目目录并运行gcloudprevie

  5. ruby - 在 Ruby 中重新分配常量时抛出异常？ - 2

    我早就知道Ruby中的“常量”(即大写的变量名)不是真正常量。与其他编程语言一样，对对象的引用是唯一存储在变量/常量中的东西。(侧边栏:Ruby确实具有“卡住”引用对象不被修改的功能，据我所知，许多其他语言都没有提供这种功能。)所以这是我的问题:当您将一个值重新分配给常量时，您会收到如下警告:>>FOO='bar'=>"bar">>FOO='baz'(irb):2:warning:alreadyinitializedconstantFOO=>"baz"有没有办法强制Ruby抛出异常而不是打印警告？很难弄清楚为什么有时会发生重新分配。 最佳答案

  6. ruby-on-rails - Ruby on Rails 可以部署在 Azure 网站上吗？ - 2

    我可以在Azure网站上部署RubyonRails吗？ 最佳答案 还没有。目前仅支持.NET和PHP。 关于ruby-on-rails-RubyonRails可以部署在Azure网站上吗？，我们在StackOverflow上找到一个类似的问题： https://stackoverflow.com/questions/12964010/

  7. UE4 源码阅读：从引擎启动到Receive Begin Play - 2

    一、引擎主循环UE版本：4.27一、引擎主循环的位置：Launch.cpp:GuardedMain函数二、、GuardedMain函数执行逻辑：1、EnginePreInit：加载大多数模块int32ErrorLevel=EnginePreInit(CmdLine);PreInit模块加载顺序：模块加载过程：（1）注册模块中定义的UObject，同时为每个类构造一个类默认对象（CDO，记录类的默认状态，作为模板用于子类实例创建）（2）调用模块的StartUpModule方法2、FEngineLoop::Init()1、检查Engine的配置文件找出使用了哪一个GameEngine类（UGame

  8. jenkins部署1--jenkins+gitee持续集成 - 2

    前置步骤我们都操作完了，这篇开始介绍jenkins的集成。话不多说，看操作1、登录进入jenkins后会让你选择安装插件，选择第一个默认的就行。安装完成后设置账号密码，重新登录。2、配置JDK和Git都需要执行路径，所以需要先把执行路径找到，先进入服务器的docker容器，2.1JDK的路径root@69eef9ee86cf:/usr/bin#echo$JAVA_HOME/usr/local/openjdk-82.2Git的路径root@69eef9ee86cf:/#whichgit/usr/bin/git3、先配置JDK和Git。点击：ManageJenkins>>GlobalToolCon

  9. 深度学习部署：Windows安装pycocotools报错解决方法 - 2

    深度学习部署：Windows安装pycocotools报错解决方法1.pycocotools库的简介2.pycocotools安装的坑3.解决办法更多Ai资讯：公主号AiCharm本系列是作者在跑一些深度学习实例时，遇到的各种各样的问题及解决办法，希望能够帮助到大家。ERROR:Commanderroredoutwithexitstatus1:'D:\Anaconda3\python.exe'-u-c'importsys,setuptools,tokenize;sys.argv[0]='"'"'C:\\Users\\46653\\AppData\\Local\\Temp\\pip-instal

  10. Ruby，使用包含 TK GUI 的 ocra 部署一个 exe - 2

    Ocra无法处理需要“tk”的应用程序require'tk'puts'nope'用奥克拉http://github.com/larsch/ocra不起作用(如链接中的一个问题所述)问题:https://github.com/larsch/ocra/issues/29(Ocra是1.9的"new"rubyscript2exe，本质上它用于将rb脚本部署为可执行文件)唯一的问题似乎是缺少tcl的DLL文件我不认为这是一个问题据我所知，问题是缺少tk的DLL文件如果它们是已知的，则可以在执行ocra时将它们包括在内有没有办法知道tk工作所需的DLL依赖项？ 最佳答

随机推荐