kubectl get node慢问题排查

于 2023-03-30 23:02:49 发布
阅读量1.5k 收藏
点赞数 1
分类专栏： k8s 文章标签： k8s
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_40579389/article/details/129868865
版权

问题描述
在k8s集群第一个master节点(node1)上执行kubectl get node大概需要8s的时间才有数据返回，而另外的master上执行同样的命令却是很快返回。通过kube-apiserver的日志来看，是无法连接上cert-manager、metrics-server等服务，从而导致超时。pod网络无法ping通网关
排查结果
本集群环境中使用的cni是kube-ovn，pod网络的网卡为bond-data，之前为单网卡，后来服务器关机新加了一块网卡，导致bond-data 和ovn-host设备MAC地址发生变化，ovn数据库中ip和mac对应关系没有更新过来，在第一个master(node1)节点丢失了mac地址。

ovn-host实际就是一个tap设备，用于 pod--host 之间的连通性（社区版是ovn0，有点出入）

排查过程

  • 在node1上执行kubectl get node
[root@node1 ~]# time kubectl get node
NAME    STATUS   ROLES                         AGE   VERSION
node1   Ready    control-plane,master,worker   2d    v1.23.6
node2   Ready    control-plane,master,worker   2d    v1.23.6
node3   Ready    control-plane,master,worker   2d    v1.23.6

real	0m7.934s     ####花费时间将近8s
user	0m0.210s
sys	0m0.095s
  • 在node2上执行kubectl get node
[root@node2 ~]#  time kubectl get node
NAME    STATUS   ROLES                         AGE   VERSION
node1   Ready    control-plane,master,worker   2d    v1.23.6
node2   Ready    control-plane,master,worker   2d    v1.23.6
node3   Ready    control-plane,master,worker   2d    v1.23.6

real	0m0.116s   ###node2显示正常
user	0m0.155s
sys	0m0.086s
  • 查看node1上api日志
    kubectl logs kube-apiserver-node1 -n kube-system
Trace[1214208296]: [2.069305201s] [2.069305201s] END
W0330 07:20:33.165661       1 reflector.go:324] storage/cacher.go:/cert-manager.io/certificaterequests: failed to list cert-manager.io/v1alpha2, Kind=CertificateRequest: conversion webhook for cert-manager.io/v1, Kind=CertificateRequest failed: Post "https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s": dial tcp 10.233.31.151:443: connect: no route to host
W0330 07:20:33.165667       1 reflector.go:324] storage/cacher.go:/cert-manager.io/issuers: failed to list cert-manager.io/v1alpha3, Kind=Issuer: conversion webhook for cert-manager.io/v1, Kind=Issuer failed: Post "https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s": dial tcp 10.233.31.151:443: connect: no route to host
E0330 07:20:33.165684       1 cacher.go:424] cacher (*unstructured.Unstructured): unexpected ListAndWatch error: failed to list cert-manager.io/v1alpha3, Kind=Issuer: conversion webhook for cert-manager.io/v1, Kind=Issuer failed: Post "https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s": dial tcp 10.233.31.151:443: connect: no route to host; reinitializing...
I0330 07:20:33.165689       1 trace.go:205] Trace[1452509263]: "List etcd3" key:/cert-manager.io/certificates,resourceVersion:,resourceVersionMatch:,limit:10000,continue: (30-Mar-2023 07:20:31.094) (total time: 2071ms):
Trace[1452509263]: [2.071338582s] [2.071338582s] END
E0330 07:20:33.165671       1 cacher.go:424] cacher (*unstructured.Unstructured): unexpected ListAndWatch error: failed to list cert-manager.io/v1alpha2, Kind=CertificateRequest: conversion webhook for cert-manager.io/v1, Kind=CertificateRequest failed: Post "https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s": dial tcp 10.233.31.151:443: connect: no route to host; reinitializing...
W0330 07:20:33.165709       1 reflector.go:324] storage/cacher.go:/cert-manager.io/certificates: failed to list cert-manager.io/v1alpha2, Kind=Certificate: conversion webhook for cert-manager.io/v1, Kind=Certificate failed: Post "https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s": dial tcp 10.233.31.151:443: connect: no route to host
E0330 07:20:33.165722       1 cacher.go:424] cacher (*unstructured.Unstructured): unexpected ListAndWatch error: failed to list cert-manager.io/v1alpha2, Kind=Certificate: conversion webhook for cert-manager.io/v1, Kind=Certificate failed: Post "https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s": dial tcp 10.233.31.151:443: connect: no route to host; reinitializing...
E0330 07:34:15.506727       1 available_controller.go:524] v1beta1.metrics.k8s.io failed with: failing or missing response from https://10.233.31.198:443/apis/metrics.k8s.io/v1beta1: Get "https://10.233.31.198:443/apis/metrics.k8s.io/v1beta1": dial tcp 10.233.31.198:443: connect: no route to host

通过日志不难看出，node1节点无法连接metrics以及cert-manager等其他服务

下面的排查过程以metrics-server 10.233.31.198:443为例

  • 在node1节点telnet测试服务连通性
[root@node1 ~]# telnet 10.233.31.198 443
Trying 10.233.31.198...
telnet: connect to address 10.233.31.198: No route to host
[root@node1 ~]# 

###测试ping网络能通
[root@node1 ~]# ping 10.233.31.198
PING 10.233.31.198 (10.233.31.198) 56(84) bytes of data.
64 bytes from 10.233.31.198: icmp_seq=1 ttl=64 time=0.085 ms
64 bytes from 10.233.31.198: icmp_seq=2 ttl=64 time=0.043 ms
^C
--- 10.233.31.198 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1028ms
rtt min/avg/max/mdev = 0.043/0.064/0.085/0.021 ms

###测试ping pod网络的网关，不通
[root@node1 ~]# ping 172.10.0.1
PING 172.10.0.1 (172.10.0.1) 56(84) bytes of data.


From 172.10.255.2 icmp_seq=1 Destination Host Unreachable
From 172.10.255.2 icmp_seq=2 Destination Host Unreachable
From 172.10.255.2 icmp_seq=3 Destination Host Unreachable
  • 在node2节点telnet测试服务连通性
[root@node2 ~]# telnet 10.233.31.198 443
Trying 10.233.31.198...
Connected to 10.233.31.198.
Escape character is '^]'.
^CConnection closed by foreign host.
[root@node2 ~]# 

###测试ping pod网络的网关可以通
[root@node2 ~]# ping 172.10.0.1
PING 172.10.0.1 (172.10.0.1) 56(84) bytes of data.
64 bytes from 172.10.0.1: icmp_seq=1 ttl=254 time=1.70 ms
64 bytes from 172.10.0.1: icmp_seq=2 ttl=254 time=0.592 ms
^C
--- 172.10.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.592/1.145/1.699/0.554 ms
  • 查看node1和node2节点的arp
[root@node1 ~]# ip neigh |grep  ovn-host
172.10.0.52 dev ovn-host  INCOMPLETE
172.10.0.84 dev ovn-host  INCOMPLETE
172.10.0.77 dev ovn-host  FAILED
172.10.0.57 dev ovn-host  INCOMPLETE
172.10.0.62 dev ovn-host  FAILED
172.10.0.38 dev ovn-host  FAILED
172.10.0.72 dev ovn-host  INCOMPLETE
172.10.0.118 dev ovn-host  INCOMPLETE
172.10.255.4 dev ovn-host  FAILED
172.10.0.124 dev ovn-host  INCOMPLETE
172.10.255.3 dev ovn-host  FAILED
172.10.0.76 dev ovn-host  INCOMPLETE
172.10.0.2 dev ovn-host  FAILED
172.10.0.60 dev ovn-host  INCOMPLETE
172.10.0.127 dev ovn-host  INCOMPLETE
172.10.0.24 dev ovn-host  INCOMPLETE
172.10.0.80 dev ovn-host  INCOMPLETE

#######下面是node2的arp信息
root@node2 ~]# ip neigh |grep  ovn-host
172.10.0.84 dev ovn-host lladdr 00:00:00:eb:f4:ec REACHABLE
172.10.0.127 dev ovn-host lladdr 00:00:00:44:ca:b9 REACHABLE
172.10.0.83 dev ovn-host lladdr 00:00:00:3b:ee:a3 STALE
172.10.0.64 dev ovn-host lladdr 00:00:00:fb:1b:a0 REACHABLE
172.10.0.24 dev ovn-host lladdr 00:00:00:a8:de:5a REACHABLE
172.10.255.4 dev ovn-host lladdr 00:1b:21:be:0d:9f DELAY
172.10.0.76 dev ovn-host lladdr 00:00:00:29:ac:f4 REACHABLE
172.10.0.3 dev ovn-host lladdr 00:00:00:40:dd:ab REACHABLE
172.10.0.42 dev ovn-host lladdr 00:00:00:59:c1:16 REACHABLE
172.10.0.70 dev ovn-host lladdr 00:00:00:9a:b9:37 REACHABLE
172.10.0.119 dev ovn-host lladdr 00:00:00:6c:75:4c REACHABLE
172.10.0.30 dev ovn-host lladdr 00:00:00:23:15:18 REACHABLE
172.10.0.114 dev ovn-host lladdr 00:00:00:7a:e8:f4 REACHABLE
172.10.0.60 dev ovn-host lladdr 00:00:00:30:7a:a5 REACHABLE
172.10.0.59 dev ovn-host lladdr 00:00:00:b2:53:7e REACHABLE
172.10.0.68 dev ovn-host lladdr 00:00:00:6f:8a:4e REACHABLE
172.10.0.28 dev ovn-host lladdr 00:00:00:93:6a:56 REACHABLE
172.10.0.67 dev ovn-host lladdr 00:00:00:06:af:03 REACHABLE
172.10.0.34 dev ovn-host lladdr 00:00:00:06:27:06 REACHABLE
172.10.0.79 dev ovn-host lladdr 00:00:00:ed:3a:96 REACHABLE
172.10.0.22 dev ovn-host lladdr 00:00:00:5c:1e:62 REACHABLE
172.10.0.57 dev ovn-host lladdr 00:00:00:43:de:aa REACHABLE
172.10.255.2 dev ovn-host lladdr e8:61:1f:13:1b:01 DELAY
172.10.0.74 dev ovn-host lladdr 00:00:00:3b:d5:2d REACHABLE
172.10.0.52 dev ovn-host lladdr 00:00:00:2b:20:12 REACHABLE
172.10.0.80 dev ovn-host lladdr 00:00:00:f7:ca:5b REACHABLE
172.10.0.65 dev ovn-host lladdr 00:00:00:eb:3a:fd REACHABLE
172.10.0.32 dev ovn-host lladdr 00:00:00:f6:16:f0 REACHABLE
172.10.0.20 dev ovn-host lladdr 00:00:00:3d:0e:d7 STALE
172.10.0.44 dev ovn-host lladdr 00:00:00:5a:12:2d STALE
172.10.0.58 dev ovn-host lladdr 00:00:00:c4:6b:c8 DELAY
172.10.0.49 dev ovn-host lladdr 00:00:00:41:c0:da REACHABLE
172.10.0.66 dev ovn-host lladdr 00:00:00:5b:ac:69 REACHABLE
172.10.0.26 dev ovn-host lladdr 00:00:00:a0:4b:47 DELAY



######################
以上得知node1上丢失了所有的mac地址
  • 确认pod网络的网卡mac地址
[root@node1 ~]# ip a | grep bond-data -A  2
5: enp113s0f1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond-data state UP group default qlen 1000
    link/ether e8:61:1f:13:1b:01 brd ff:ff:ff:ff:ff:ff
6: enp115s0f0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond-data state UP group default qlen 1000
    link/ether e8:61:1f:13:1b:01 brd ff:ff:ff:ff:ff:ff
7: enp115s0f1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond-manage state UP group default qlen 1000
--
20: bond-data: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
    link/ether e8:61:1f:13:1b:01 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ea61:1fff:fe13:1b01/64 scope link
    
    
 ###查看ovn-host 信息
[root@node1 ~]# ip a | grep ovn-host -A  2
40: ovn-host: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether e8:61:1f:13:1b:01 brd ff:ff:ff:ff:ff:ff
    inet 172.10.255.2/16 brd 172.10.255.255 scope global noprefixroute ovn-host
       valid_lft forever preferred_lft forever
    inet6 fe80::b439:cff:fe9b:a0ba/64 scope link

由于我们是bond-data添加了一块网卡而且出现过关机的情况，bond-data的mac地址可能和之前的不一样，试着看一下数据库中ip 和mac是否正确对应

  • 查看ovn数据库信息
[root@node2 ~]# kubectl ko nbctl show | grep 255.2 -C 5
    port virt-operator-756d76994-hmrqf.kubevirt
        addresses: ["00:00:00:59:C1:16 172.10.0.42 fd00:10:16::2a"]
    port kube-ovn-webhook-5874f47bdd-hhjvt.kube-system
        addresses: ["00:00:00:93:6A:56 172.10.0.28 fd00:10:16::1c"]
    port ovn-default-node-node1
        addresses: ["e8:61:1f:13:48:df 172.10.255.2"]    ###果然，此处可以看到ovn数据库中的mac地址和ovn-host的mac地址不对应,没有自动更新
    port metrics-server-64b7dfb7d5-hfvfb.kube-system
        addresses: ["00:00:00:2B:20:12 172.10.0.52 fd00:10:16::34"]
    port lmg-statefulset-1.upf
        addresses: ["00:00:00:D9:EF:A6 172.10.0.118 fd00:10:16::76"]
    port kube-sriov-cni-ds-amd64-b5l4k.kube-system
  • 更新ovn数据库 mac地址对应关系
[root@node2 ~]# kubectl ko nbctl lsp-set-addresses ovn-default-node-node1 "e8:61:1f:13:1b:01 172.10.255.2"

###确认修改成功
[root@node2 ~]# kubectl ko nbctl show | grep 255.2 -C 5
    port virt-operator-756d76994-hmrqf.kubevirt
        addresses: ["00:00:00:59:C1:16 172.10.0.42 fd00:10:16::2a"]
    port kube-ovn-webhook-5874f47bdd-hhjvt.kube-system
        addresses: ["00:00:00:93:6A:56 172.10.0.28 fd00:10:16::1c"]
    port ovn-default-node-node1
        addresses: ["e8:61:1f:13:1b:01 172.10.255.2"]    ###ovn-host的ip地址和实际的mac地址对应上  
    port metrics-server-64b7dfb7d5-hfvfb.kube-system
        addresses: ["00:00:00:2B:20:12 172.10.0.52 fd00:10:16::34"]
    port lmg-statefulset-1.upf
        addresses: ["00:00:00:D9:EF:A6 172.10.0.118 fd00:10:16::76"]
    port kube-sriov-cni-ds-amd64-b5l4k.kube-system
  • node1节点测试
###测试访问业务正常
[root@node1 ~]# telnet 10.233.31.198 443   
Trying 10.233.31.198...
Connected to 10.233.31.198.
Escape character is '^]'.
^CConnection closed by foreign host.
[root@node1 ~]# 

###和网关正常通信
[root@node1 ~]# ping 172.10.0.1
PING 172.10.0.1 (172.10.0.1) 56(84) bytes of data.
64 bytes from 172.10.0.1: icmp_seq=1 ttl=254 time=0.326 ms
64 bytes from 172.10.0.1: icmp_seq=2 ttl=254 time=0.299 ms
^C
--- 172.10.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1062ms
rtt min/avg/max/mdev = 0.299/0.312/0.326/0.022 ms
[root@node1 ~]# 

####get时间正常
[root@node1 ~]# time kubectl get po 
NAME                       READY   STATUS    RESTARTS   AGE
busybox-86b69dd785-4kl8z   1/1     Running   0          5h4m
busybox-86b69dd785-8t6x7   1/1     Running   0          90m
busybox-86b69dd785-h4xft   1/1     Running   0          5h4m

real	0m0.089s
user	0m0.141s
sys	0m0.057s
  • 查看node1的arp表显示正常
[root@node1 ~]# ip neigh |grep  ovn-host
172.10.0.52 dev ovn-host lladdr 00:00:00:2b:20:12 STALE
172.10.0.28 dev ovn-host lladdr 00:00:00:93:6a:56 STALE
172.10.0.84 dev ovn-host lladdr 00:00:00:eb:f4:ec REACHABLE
172.10.0.77 dev ovn-host lladdr 00:00:00:96:1b:52 DELAY
172.10.0.57 dev ovn-host lladdr 00:00:00:43:de:aa REACHABLE
172.10.0.83 dev ovn-host lladdr 00:00:00:3b:ee:a3 STALE
172.10.0.62 dev ovn-host lladdr 00:00:00:86:ab:38 REACHABLE
172.10.0.38 dev ovn-host  FAILED
172.10.0.72 dev ovn-host lladdr 00:00:00:44:e3:17 REACHABLE
172.10.0.118 dev ovn-host lladdr 00:00:00:d9:ef:a6 STALE
172.10.255.4 dev ovn-host lladdr 00:1b:21:be:0d:9f STALE
172.10.0.124 dev ovn-host lladdr 00:00:00:60:0a:a5 STALE
172.10.255.3 dev ovn-host lladdr 00:1b:21:be:0d:a1 STALE
172.10.0.76 dev ovn-host lladdr 00:00:00:29:ac:f4 REACHABLE
172.10.0.2 dev ovn-host lladdr 00:00:00:61:05:f3 STALE
172.10.0.54 dev ovn-host lladdr 00:00:00:df:9f:f6 STALE
172.10.0.1 dev ovn-host lladdr 00:00:00:00:69:8b STALE
172.10.0.60 dev ovn-host lladdr 00:00:00:30:7a:a5 REACHABLE
172.10.0.127 dev ovn-host lladdr 00:00:00:44:ca:b9 REACHABLE
172.10.0.53 dev ovn-host lladdr 00:00:00:a0:8b:05 STALE
172.10.0.29 dev ovn-host lladdr 00:00:00:19:af:22 STALE
172.10.0.24 dev ovn-host lladdr 00:00:00:a8:de:5a REACHABLE
172.10.255.1 dev ovn-host  FAILED
172.10.0.80 dev ovn-host lladdr 00:00:00:f7:ca:5b REACHABLE
魏志标
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
解决k8s的kubectl get cs 显示不健康的问题
06-27
解决k8s的kubectl get cs 显示不健康的问题,k8s故障处理
干货！K8S之kubectl命令详解
时光慢旅的博客
05-10 2107
文章目录一、概述二、kubectl命令的使用1、pod创建2、pod发布3、更新版本4、回滚5、查看资源的详细信息（可以看到该资源日志信息）6、进入pod7、删除pod资源（删除控制器和nginx服务） 一、概述 Kubectl是管理k8s集群的命令行工具，通过生成的json格式传递给apiserver进行创建、查看、管理的操作。 对于kubectl命令，我们可以使用kubectl --help来看下帮助手册，查看相关参数的使用 [root@k8s_master ~]# kubectl --help k
生产环境k8s偶发超时问题排查及解决
Jerry_Pan1990的博客
11-25 9632
前言： 凡是有明确报错的问题，都是能很快解决的，真正难以解决和排查的，是偶发且笼统报错的问题。 这里记录整个解决的过程，期间有走过弯路，有思维局限，但庆幸最终找到了原因，正常把我们系统上线到 k8s 平台了。 问题表现： 生产某套应用访问时，偶尔会报 timed out 。相同的配置在 开发、测试、预生产都能正常运行。 排查思路： 1、 首先，因为这个问题是偶发性的...
kubectl查看node状态_K8S常用命令
weixin_35282313的博客
12-23 7504
1、master查看待审批node信息：[k8s@database_1 dns]$ kubectl get csrNAME AGE REQUESTOR CONDITIONnode-csr-QOrUGcKDtAip5-k0MU3KFoY4hD0It3wXRh2uGURB...
添加node成功，但是在master运行kubectl get nodes 看不到子节点
热门推荐
qq_35837864的博客
05-31 1万+
查看日志 tail /var/logs/message May 31 17:25:07 node01 kubelet: I0531 17:25:07.790880 21533 docker_service.go:249] Docker Info: &{ID:J66N:IQ7Z:JZXT:D2QX:IHQZ:QGWR:YBFT:QGF3:NPR2:Z7CS:XFDZ:QNNV Conta...
k8s问题处理：1）kubectl get node 耗时15秒
qq_34482492的博客
02-20 529
kubectl get node 耗时15秒，问题详细处理过程。
kubectl get nodes缓慢问题排查
wanger5354的博客
01-04 4679
微信公众号：运维开发故事，作者：华仔 问题描述 最近在某个k8s集群其中一个节点(master1)上执行kubectl get nodes大概需要45s的时间才有数据返回，而在另外的master上执行同样的命令却是很快返回。通过kube-apiserver的日志来看，是无法连接上metrics-server，从而导致超时。进而发现这个master无法与其他节点的flannel.1的IP互相ping通。于是就有了这一篇文章。 排查结果 因为我们的网络组件使用的canal，跨主机通信时，通过flannel(.
错误集——k8s，kubectl get node 查看集群节点状态：NotReady
愿你成为自己喜欢的模样，不抱怨，不将就，有自由，有光芒！
04-14 1026
错题集——k8s，查看集群节点状态：NotReady [root@hellolic ~/k8s/kubeconfig] # kubectl get node NAME STATUS ROLES AGE VERSION 192.168.184.12 NotReady <none> 9h v1.12.3 原因： 查看查询中的节点的flannel服务是否自动关闭了 [root@hellokiki ~] # systemctl status
rke2集群安装完成之后使用kubectl反应很慢
JamesCurtis的博客
03-17 430
rke2集群安装完成之后使用kubectl反映很慢
kubectl get node执行提示error: no configuration has been provided, try setting KUBERNETES_MASTER environ
白凤银刺的博客
03-30 1388
kubectl get node执行提示"error: no configuration has been provided, try setting KUBERNETES_MASTER environ" 网络资料：https://blog.csdn.net/afriendlyman/article/details/105360148 在/etc/profile末尾增加 export KUBECONFIG=/etc/kubernetes/admin.conf 添加完后执行 source /etc/prof
解决Python selenium get页面很慢时的问题
09-19
今天小编就为大家分享一篇解决Python selenium get页面很慢时的问题，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧
node.js中的http.get方法使用说明
10-25
主要介绍了node.js中的http.get方法使用说明,本文介绍了http.get的方法说明、语法、接收参数、使用实例和实现源码,需要的朋友可以参考下
node.js处理前端提交的GET请求
10-16
主要为大家详细介绍了node.js处理前端提交的GET请求，具有一定的参考价值，感兴趣的小伙伴们可以参考一下
k8s集群node节点运行kubectl命令
wmx1992的博客
12-05 2718
k8s集群，node节点执行kubectl命令配置
k8s使用过程中输入kubectl命令偶发性卡顿
任我行的博客
06-18 1905
现象： 用户在命令行中输入kubectl命令偶发性卡顿 分析过程： 1. 使用命令行和kubectl发请求都会卡顿 2. tcpdump 抓包分析，发现当到了序列号为236的包时会发生重传现象，在目的主机网卡和交换机中没有抓到数据包 3. 因为目的主机网卡采用双网卡进行bond0，检查网卡的bond配置，发现配置的bond的MTU不一致，后来改成统一的1600 4. 问题继续存在，怀疑是不是网卡或者内核参数的设置的原因，打开net.ipv4.ip_no_pmtu_disc = 1开关，然后sysctl -p
Kubernetes集群管理常用命令
liqingbing12的专栏
09-11 144
集群信息的各种查看基本上是在Master节点操作 0、查看集群信息 kubectl cluster-info 1、查看 Node状态 kubectl get nodes kubectl get node [IP] //节点IP可以用空格隔开写多个 kubectl describe node [IP] kubectl delete node [IP] 2、查看 Service 信息 kubectl get service 3、查看POD kubectl get pods --all..
Kubernetes入门——Kubernetes权威指南（第一章）
imba_xuetu的博客
04-20 637
第一章 Kubernetes入门 在K8S中，Service是分布式集群架构的核心，一个Service对象拥有如下关键特征。 拥有唯一指定的名称（比如mysql-server） 拥有一个虚拟IP（Cluster IP\Servcie IP\VIP）和端口号。 能够提供某种远程服务能力。 被映射到提供这种服务能力的一组容器应用上。 Service的服务进程目前都基于Socket通信方式对外提供服...
Kubernetes安装配置指南以及kubectl命令行示例——Kubernetes权威指南（第二章）
imba_xuetu的博客
04-20 1015
Kubernetes安装配置指南以及kubectl命令行示例 安装配置环境为CentOS7。使用Systemd系统完成对Kubernetes的配置。为了便于管理，常见的做法是将K8S服务程序配置为Linux系统开机自动启动的服务。Master和Node间会有大量通信，CentOS7又开启了firewalld，安全的做法是在防火墙上配置各组件需要相互通信的端口号。内网中可以关闭防火墙服务： syst...
node-v4.8.6-win-x64.zip
最新发布
05-07
Node.js，简称Node，是一个开源且跨平台的JavaScript运行时环境，它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立，旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎，可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型，这使得它非常适合处理大量并发连接，从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外，Node.js使用了模块化的架构，通过npm（Node package manager，Node包管理器）,社区成员可以共享和复用代码，极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展，它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等，因此，开发者可以用JavaScript编写全栈应用程序，这一点大大提高了开发效率和便捷性。 在实践中，许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台，如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能，简化了开发流程，并且能更快地响应市场需求。
kubectl get nodes notready
08-08
您好！对于节点状态为"not ready"，一般是有几种可能的原因： 1. 网络问题：请确保节点能够正常与集群信。您可以尝试使用命令` describe node <node_name>`来查看节点的详细信息，特别关注网络相关的错误或警告信息。 2. 节点资源不足：检查节点的资源使用情况，包括 CPU、内存和磁盘空间。如果资源使用超过了节点的限制，可能导致节点状态为"not ready"。 3. 容器运行时问题：如果您使用的是 Docker，可以尝试重启 Docker 服务，或者检查 Docker 容器运行时的日志，查看是否有任何错误信息。 4. Kubernetes 组件问题：如果其他节点处于正常状态，可能是该节点上的某个 Kubernetes 组件出现了故障。您可以检查 kubelet、kube-proxy 和 kube-controller-manager 的日志，查找相关错误信息。 请根据具体情况逐一排查以上可能的原因，并采取相应的解决方法。如果问题仍然存在，请提供更多详细信息，以便我能够给出更准确的建议。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值