在使用kuboard学习k8s的时候,突然发现资源不能调度。如下所示:
出现了这个问题真是百思不得其解。
按照问题解决办法。逐步检查可能的问题:
确认 metrics-server 是否正常运行
Metrics server 是 Kubernetes 中的一个重要组件,但是却不是内置组件。Kubernetes 许多特性都依赖于 metrics server,
kubectl top nodes / kubectl top pods 指令,查看节点/容器组的资源利用率;
Kuboard 集群概览页显示节点资源利用率;
HPA 水平自动伸缩,依据节点/容器组资源利用率情况自动执行水平伸缩;
当 metrcis-server 出现异常时,相关依赖组件都会受到影响,例如:
在安装了kubectl的客户端或者master节点上检查:
# kubectl top nodes
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)
进入容器检查metrics-server状态
状态显示无异常。进入日志查看
也无异常输出
基本断定 metrics-server无异常
确认 ApiService 是否正常
出现这个错误,是因为的 Kubernetes ApiServer 不能访问到 metrics-server,通常可能是因为如下几类原因:
使用二进制安装方式安装 Kubernetes 集群,但是未在 Master 节点上启用 kube-proxy 组件;
master 节点与 metrics-server 所在的 worker 节点之间有防火墙,或者不在同一个安全组;
具体 URL 请从您自己实际得到的消息提示中获得
curl -ik https://10.96.106.114:443/apis/metrics.k8s.io/v1beta1
首选确认kube-proxy节点状态
发现kube-proxy都是正常的,但是calico-node有一个没有处于ready状态
说明calico一个容器可能存在问题,由此导致网络不通。
Calico是Kubernetes生态系统中另一种流行的网络选择。虽然Flannel被公认为是最简单的选择,但Calico以其性能、灵活性而闻名。Calico的功能更为全面,不仅提供主机和pod之间的网络连接,还涉及网络安全和管理。Calico CNI插件在CNI框架内封装了Calico的功能。
尽管部署Calico所需的操作看起来相当简单,但它创建的网络环境同时具有简单和复杂的属性。与Flannel不同,Calico不使用overlay网络。相反,Calico配置第3层网络,该网络使用BGP路由协议在主机之间路由数据包。这意味着在主机之间移动时,不需要将数据包包装在额外的封装层中。BGP路由机制可以本地引导数据包,而无需额外在流量层中打包流量。
检查caclico
在kubeboard中,可以看到cailco-node少部署了一个副本
下面可以看到日志
说明calico存在问题
检查各个节点的iptables,防火墙等,发现一个节点selinux处于enable状态
关闭selinux后,重启该节点
caico组件故障排查
在关闭节点selinux并重启后,也尝试多次将容器重启,但是故障依旧。
进入容器后,可以看到pod报错信息
Readiness probe failed: calico/node is not ready: BIRD is not ready: BGP not established with 172.18.0.1
然后开始通过kubectl logs -f pod calico-node-fg6bn及kubectl describe pod calico-node-fg6bn进行查看日志输出,发现信息如下:
Readiness probe failed: calico/node is not ready: BIRD is not ready: BGP not established with 172.18.0.1
然后再github上找到相关描述信息https://github.com/projectcalico/calico/issues/2561
计是calico绑定网卡时,没有绑定到主机上用于群集通信的网卡(ens33),而是绑定到了lo、virbr*等这样的网卡上。
解决办法的话,就是调整calicao 网络插件的网卡发现机制,修改 IP_AUTODETECTION_METHOD 对应的value值。官方提供的yaml文件中,ip识别策略(IPDETECTMETHOD)没有配置,即默认为first-found,这可能会导致一个网络异常的ip作为nodeIP被注册,从而影响 node-to-node mesh 。我们可以修改成 can-reach 或者 interface 的策略,尝试连接某一个Ready的node的IP,以此选择出正确的IP。
修改calico配置文件
kubectl get daemonset -n kube-system #获取daemonset资源名称
$ kubectl edit daemonset calico-node -n kube-system # 编辑calico资源对象
进入后在末行模式下搜索:name: CLUSTER_TYPE
,定位到name: CLUSTER_TYPE位置后,添加以下两行配置:
- name: IP_AUTODETECTION_METHOD
value: "interface=ens192" # 指定用于k8s集群中节点之间通信的网卡名称,我这里是ens192
#上面的value值,支持通配符,可以写成ens*,但不建议这么写,尤其是多网卡主机,最好只写用于群集通信的就行
#修改后的部分配置如下:
............... # 省略部分内容
- name: CLUSTER_TYPE
value: k8s,bgp
- name: IP_AUTODETECTION_METHOD
value: "interface=ens33"
- name: IP
value: autodetect
- name: CALICO_IPV4POOL_IPIP
value: Always
- name: FELIX_IPINIPMTU
............... # 省略部分内容
修改后保存退出,执行指令watch kubectl get pods -A -o wide即可动态观察calico相关的pod重启过程,直至所有pod全部Running,并且READY列为1/1,如下:
至此问题解决
关于calico的wiki详细见:
https://docs.projectcalico.org/about/about-networking
关于kuboard见:
https://kuboard.cn/install/install-dashboard.html
问题解决参考:
来源:oschina
链接:https://my.oschina.net/u/4410144/blog/4941978