1. Toy模板网首页
  2. >Toy博客

记录一次K8s 集群故障（路由&Calico）

1年前作者：树荫下的停留分类：Toy博客阅读(16)违法举报

这篇具有很好参考价值的文章主要介绍了记录一次K8s 集群故障（路由&Calico）。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

3节点测试集群 k8s 1.17 docker 19.03

每个节点2个网卡 ：

  • enp0s3  用来桥接无线网卡用来连接外网，因此IP不固定。
  • enp0s8  192.168.56.0/24 用来和其它节点互通

某一天开机 突然发现大量pod异常，异常的Pod 全部没有正常获取到IP, service也都打不开了。

检查控制平面

除了 kube-system下的api-server, etcd-admin, scheduler, controller manager, 以及各个3个节点的kube-proxy 处于running状态。这说明集群健康状态是正常的，节点OS和系统资源也没问题，POD都被正常调度到node了。kube-proxy和calico-node都是ds, 使用Hostnetwork，因此IP就是所在节点IP。

记录一次K8s 集群故障（路由&Calico）,kubernetes,java,容器

Coredns 处于completed ：

[root@admin ~ ]$k describe po  coredns-9d85f5447-sjs2j  -n kube-system

    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Thu, 15 Feb 2024 09:25:15 +0800
      Finished:     Thu, 15 Feb 2024 19:58:02 +0800
    Ready:          False
    Restart Count:  36
    Limits:
      memory:  170Mi
    Requests:
      cpu:        100m
      memory:     70Mi
    Liveness:     http-get http://:8080/health delay=60s timeout=5s period=10s #success=1 #failure=5
    Readiness:    http-get http://:8181/ready delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:  <none>
    Mounts:
      /etc/coredns from config-volume (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from coredns-token-j84s8 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
---
Events:
  Type    Reason          Age                    From            Message
  ----    ------          ----                   ----            -------
  Normal  SandboxChanged  4m3s (x575 over 129m)  kubelet, admin  Pod sandbox changed, it will be killed and re-created.

显示sandbox 退出Kill了，看日志

[root@admin ~ ]$k logs   coredns-9d85f5447-sjs2j  -n kube-system
.:53
[INFO] plugin/reload: Running configuration MD5 = 4e235fcc3696966e76816bcd9034ebc7
CoreDNS-1.6.5
linux/amd64, go1.13.4, c2fd1b2
[INFO] SIGTERM: Shutting down servers then terminating
[INFO] plugin/health: Going into lameduck mode for 5s

CNI组件calico-node 处于 Crashloopbackoff, 查看events 和Logs

Events:
  Type     Reason     Age                    From            Message
  ----     ------     ----                   ----            -------
  Warning  Unhealthy  11m (x304 over 176m)   kubelet, node2  Readiness probe failed: calico/node is not ready: felix is not ready: Get http://localhost:9099/readiness: dial tcp [::1]:9099: connect: connection refused
  Warning  BackOff    105s (x574 over 172m)  kubelet, node2  Back-off restarting failed container

[root@admin ~ ]$k logs  calico-node-7kvkf  -n kube-system
2024-02-16 04:58:08.483 [INFO][8] startup.go 259: Early log level set to info
2024-02-16 04:58:08.483 [INFO][8] startup.go 275: Using NODENAME environment for node name
2024-02-16 04:58:08.483 [INFO][8] startup.go 287: Determined node name: node2
2024-02-16 04:58:08.484 [INFO][8] k8s.go 228: Using Calico IPAM
2024-02-16 04:58:08.484 [INFO][8] startup.go 319: Checking datastore connection
2024-02-16 04:58:08.485 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: connect: network is unreachable
2024-02-16 04:58:09.486 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: connect: network is unreachable
2024-02-16 04:58:10.489 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: connect: network is unreachable
2024-02-16 04:58:11.499 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: connect: network is unreachable
2024-02-16 04:58:12.570 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: connect: network is unreachable
2024-02-16 04:58:13.571 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: connect: network is unreachable
2024-02-16 04:58:14.572 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: connect: network is unreachable
2024-02-16 04:58:15.578 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: connect: network is unreachable
2024-02-16 04:58:16.580 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: connect: network is unreachable
2024-02-16 04:58:17.581 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: connect: network is unreachable

查看calico contorller 日志，没发现有用信息

[root@admin ~ ]$k logs  calico-kube-controllers-7489ff5b7c-6nl5p  -n kube-system
2024-02-15 01:25:31.218 [INFO][1] main.go 87: Loaded configuration from environment config=&config.Config{LogLevel:"info", ReconcilerPeriod:"5m", CompactionPeriod:"10m", EnabledControllers:"node", WorkloadEndpointWorkers:1, ProfileWorkers:1, PolicyWorkers:1, NodeWorkers:1, Kubeconfig:"", HealthEnabled:true, SyncNodeLabels:true, DatastoreType:"kubernetes"}
2024-02-15 01:25:31.222 [INFO][1] k8s.go 228: Using Calico IPAM
W0215 01:25:31.222664       1 client_config.go:541] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
2024-02-15 01:25:31.223 [INFO][1] main.go 108: Ensuring Calico datastore is initialized
2024-02-15 01:25:31.228 [INFO][1] main.go 182: Starting status report routine
2024-02-15 01:25:31.228 [INFO][1] main.go 364: Starting controller ControllerType="Node"
2024-02-15 01:25:31.228 [INFO][1] node_controller.go 133: Starting Node controller
2024-02-15 01:25:31.329 [INFO][1] node_controller.go 146: Node controller is now running
2024-02-15 01:25:31.345 [INFO][1] kdd.go 167: Node and IPAM data is in sync

calico-node 日志发现报错连接datastore tcp 10.96.0.1:443 失败， 那么这里是etcd吗 这个IP是谁呢

检查api-server 配置 发现这是svc ip range的第一个地址

[root@admin ~ ]$ps -ef|grep apiserver
root      1121 17490  0 13:34 pts/0    00:00:00 grep --color=auto apiserver
root      2939  2885  1 09:59 ?        00:04:00 kube-apiserver --advertise-address=192.168.56.3 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/etc/kubernetes/pki/ca.crt --enable-admission-plugins=NodeRestriction --enable-bootstrap-token-auth=true --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key --etcd-servers=https://127.0.0.1:2379 --insecure-port=0 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6443 --service-account-key-file=/etc/kubernetes/pki/sa.pub --service-cluster-ip-range=10.96.0.0/12 --tls-cert-file=/etc/kubernetes/pki/apiserver.crt --tls-private-key-file=/etc/kubernetes/pki/apiserver.key

 检查SVC, 发现他是k8s本身这个服务

记录一次K8s 集群故障（路由&Calico）,kubernetes,java,容器

[root@admin ~ ]$k describe svc  kubernetes  
Name:              kubernetes
Namespace:         default
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP:                10.96.0.1
Port:              https  443/TCP
TargetPort:        6443/TCP
Endpoints:         192.168.56.3:6443
Session Affinity:  None
Events:            <none> 

它是一个clusterIP类型服务，指向的EP是 192.168.56.3:6443, 那么6443是谁暴露的呢

[root@admin ~ ]$lsof -i:6443
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
kubelet   1355 root   25u  IPv4  37928      0t0  TCP admin:40182->admin:sun-sr-https (ESTABLISHED)
kube-apis 2939 root    5u  IPv6  37530      0t0  TCP *:sun-sr-https (LISTEN)

记录一次K8s 集群故障（路由&Calico）,kubernetes,java,容器

确定它就是k8s kube-apiserver-admin这个pod所单独暴露出来的svc, 是单例的pod，不属于任何rs/ds/deployment/sts。

记录一次K8s 集群故障（路由&Calico）,kubernetes,java,容器

pod正常，svc故障导致calico无法访问apiserver，也更无法为pod分配IP以及在每个节点配置iptables规则。那为什么网络不可达呢，这就要从路由层面查了。

一番排查有

因为今天admin节点连接了有线网络，没连WIFI，导致用来桥接的wifi网卡没有通过DHCP获取到IP、默认网关路由信息，所以admin节点就会出现10.96.0.1 网络不可达

[root@admin /etc/kubernetes ]$ansible k8s-1  -m shell  -a 'traceroute 10.96.0.1'
[WARNING]: Invalid characters were found in group names but not replaced, use -vvvv to see details
192.168.56.3 | FAILED | rc=1 >>
traceroute to 10.96.0.1 (10.96.0.1), 30 hops max, 60 byte packets
connect: Network is unreachablenon-zero return code
192.168.56.4 | CHANGED | rc=0 >>
traceroute to 10.96.0.1 (10.96.0.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * node1 (192.168.31.226)  3008.015 ms !H
192.168.56.5 | CHANGED | rc=0 >>
traceroute to 10.96.0.1 (10.96.0.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * node2 (192.168.31.20)  3005.846 ms !H

 [root@admin /etc/kubernetes ]$ansible k8s-1  -m shell  -a 'ip route'
[WARNING]: Invalid characters were found in group names but not replaced, use -vvvv to see details
192.168.56.4 | CHANGED | rc=0 >>
default via 192.168.31.1 dev enp0s3 proto dhcp metric 102
10.10.0.0/26 via 192.168.56.5 dev tunl0 proto bird onlink
10.10.0.128/26 via 192.168.56.3 dev tunl0 proto bird onlink
blackhole 10.10.0.192/26 proto bird
10.10.0.196 dev cali2473e8d3fe5 scope link
10.10.0.199 dev cali931cf856fe5 scope link
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.31.0/24 dev enp0s3 proto kernel scope link src 192.168.31.226 metric 102
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.4 metric 101
192.168.56.3 | CHANGED | rc=0 >>  ## 默认路由缺失！！
10.10.0.0/26 via 192.168.56.5 dev tunl0 proto bird onlink
blackhole 10.10.0.128/26 proto bird
10.10.0.129 dev calib35f38918a6 scope link
10.10.0.130 dev cali3d6a8137e9b scope link
10.10.0.131 dev calief752050065 scope link
10.10.0.189 dev cali9cd0964c823 scope link
10.10.0.192/26 via 192.168.56.4 dev tunl0 proto bird onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.3 metric 101
192.168.56.5 | CHANGED | rc=0 >>
default via 192.168.31.1 dev enp0s3 proto dhcp metric 102
blackhole 10.10.0.0/26 proto bird
10.10.0.37 dev caliae17495c610 scope link
10.10.0.38 dev cali7c21225184f scope link
10.10.0.128/26 via 192.168.56.3 dev tunl0 proto bird onlink
10.10.0.192/26 via 192.168.56.4 dev tunl0 proto bird onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.31.0/24 dev enp0s3 proto kernel scope link src 192.168.31.20 metric 102
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.5 metric 101
[root@admin /etc/kubernetes ]$

此时去检查admin节点的路由表和iptables-nat表会发现，虽然针对这个svc的dnat规则已经配置，但是从网络流量的处理顺序来看，经过PREROUTING链后接着检查路由表，路由表匹配不到任何条目，也没有default gw的话，就直接unreachable了

Chain KUBE-SEP-G5V522HWZT6RKRAC (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 KUBE-MARK-MASQ  all  --  *      *       192.168.56.3         0.0.0.0/0           
    7   420 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp to:192.168.56.3:6443

那么已知我的无线路由器地址为192.168.31.1, 它已经是node1, node2的默认网关，显然，无线路由器的路由表里肯定没有我K8s集群内部这个svc ip的相关条目并不知道向哪转发，ip数据包从admin host传输到10.96.0.1后面的podIP 到底跟网关地址有没有关系呢？

很显然  没有，只需要有一个路由条目能匹配就行，手动把默认网关配置到任何一个可达IP 都可以让数据继续往下流动，路由决策后从enp0s3网卡out, 继续经过FORWARD--->POSTROUTING链， 然后从enp0s8 in ，自下而上流经协议栈，以太网-->IP-->socket 进入apiserver这个Pod。

PS：这里因为用了hostnetwork, pod跟主机在一个netns下面。

实现10.96.0.1-->dnat to 192.168.56.3:6443 成功

记录一次K8s 集群故障（路由&Calico）,kubernetes,java,容器

 Pod 日志里也能看到，在我手动配置默认gw成功的瞬间，访问恢复正常。

记录一次K8s 集群故障（路由&Calico）,kubernetes,java,容器

此后，所有资源对k8s svc的访问正常，scheduler 和各个controller开始负责实现目标状态，集群恢复正常。

当然，这个问题可能只有用vm测试会遇到吧，生产不会有这个问题。

但是对于理解k8s CNI, SVC以及iptables 工作过程还有所帮助的，所以记录一下。文章来源地址https://www.toymoban.com/news/detail-834496.html

到了这里，关于记录一次K8s 集群故障（路由&Calico）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处： 如若内容造成侵权/违法违规/事实不符，请点击违法举报进行投诉反馈，一经查实，立即删除！

分享到：
领支付宝红包赞助服务器费用

相关文章

  • 问题记录：K8s中安装calico，calico反复重启，原因：版本未匹配

    问题记录：K8s中安装calico，calico反复重启，原因：版本未匹配

    K8s版本1.23.6 calico-node-反复重启，READY状态一直为0，STATUS为CrashLoopBackOff， 查看节点日志 没有错误，只有info信息 但是一直反复重启，导致coredns一直处于未准备好状态 calico与k8s的版本未匹配 删除calico，重新安装对应k8s版本 先删除calico pod 删掉calico.yaml文件 重新下载 k8s版本1.

    2024年02月09日
    浏览(10)

  • ·[K8S：使用calico网络插件]：解决集群节点NotReady问题

    执行: wget --no-check-certificate https://projectcalico.docs.tigera.io/archive/v3.25/manifests/calico.yaml 1.2.1：查看本机ip 网卡相关信息： 1.2.2：修改calico.yaml网卡interface相关信息 1.3.1：异常日志抛出： 1.3.2：场景一：执行K8S admin config配置文件替换相关操作： 1.3.2：场景二：执行K8S admin config配置文

    2024年02月14日
    浏览(14)

  • 【大数据】kubernetes(k8s)calico跨节点网络不通的问题及排错过程

    进入节点 k8s-node27 的pod，ping k8s-node28 节点上的pod的ip都不通，k8s-node28 节点ping k8s-node27 也不通，但是k8s-node27，k8s-node28 之间他们各自节点上的pod的ip之间是可以相互ping通。 排查过程： 这种情况让我们想起了当时设置路由转发时候的配置，主机上有多个网卡，而k8s的calico网络

    2024年02月11日
    浏览(13)

  • K8s：Kubernetes 故障排除方法论

    博文内容为节译整理 文中提到的工具大部分是商业软件，不是开源的，作为了解 理解不足小伙伴帮忙指正 对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回

    2024年02月15日
    浏览(10)

  • Kubernetes 集群calico网络故障排查思路

    报错 calico/node is not ready: BIRD is not ready: BGP not established with 172.16.0.20,172.16.0.30 访问k8s的dashboard界面无法访问网站，查看pod，未知原因导致calico的Pod资源重新创建后无法启动，显示的是0/1状态  Calico的Pod报错内容 原因：calico没有发现实node节点实际的网卡名称 解决方法 调整cal

    2024年02月07日
    浏览(9)
  • 【云原生-K8s】kubeadm搭建安装k8s集群v1.25版本完整教程【docker、网络插件calico、中间层cri-docker】

    【云原生-K8s】kubeadm搭建安装k8s集群v1.25版本完整教程【docker、网络插件calico、中间层cri-docker】

    从 k8s 1.24开始，dockershim已经从kubelet中移除，但因为历史问题docker却不支持kubernetes主推的CRI（容器运行时接口）标准，所以docker不能再作为k8s的容器运行时了，即从k8s v1.24开始不再使用docker了 但是如果想继续使用docker的话，可以在kubelet和docker之间加上一个中间层cri-docker。

    2024年02月03日
    浏览(28)
  • K8S容器的一则故障记录

    K8S容器的一则故障记录

       kubelet 、pod持久化 metrics/vlalphal容器 kube-controller、apiserver     XXX反馈说某某业务服务异常，无法启动，需要进行协助排查。经常会接到这样一个需求，一开始无法清楚知道具体什么问题，需要跟一线运维人员详细做沟通，了解故障问题的细节。     根据一线运维人

    2024年02月02日
    浏览(8)
  • K8s(Kubernetes)学习（二）：k8s集群搭建

    K8s(Kubernetes)学习（二）：k8s集群搭建

    minikube 只是一个 K8S 集群模拟器，只有一个节点的集群，只为测试用，master 和 worker 都在一起。 裸机安装 至少需要两台机器（主节点、工作节点个一台），需要自己安装 Kubernetes 组件，配置会稍微麻烦点。 缺点：配置麻烦，缺少生态支持，例如负载均衡器、云存储。 直接用

    2024年02月09日
    浏览(17)

  • Kubernetes(k8s)一次性任务：Job

    目录 一.系统环境 二.前言 三.Kubernetes Job简介 四.创建一次性任务job 4.1 创建一个简单任务的job 4.2 创建需要执行多次的job任务 五.测试job失败重试次数 六.job任务使用示例：计算圆周率 七.总结 本文主要基于Kubernetes1.21.9和Linux操作系统CentOS7.4。 服务器版本 docker软件版本 Kubern

    2024年02月07日
    浏览(17)
  • Kubernetes(K8S)集群部署

    Kubernetes(K8S)集群部署

    目录 一、创建3台虚拟机 二、为每台虚拟机安装Docker 三、安装kubelet 3.1 安装要求 3.2 为每台服务器完成前置设置 3.3 为每台服务器安装kubelet、kubeadm、kubectl 四、使用kubeadm引导集群 4.1 master服务器 4.2 node1、node2服务器 4.3 初始化主节点 4.4 work节点加入集群 五、token过期怎么办？

    2024年02月07日
    浏览(59)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包，优惠每天领

二维码1

领取红包

二维码2

领红包