确认 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

问题解决参考：

https://lvjianzhao.gitee.io/lvjianzhao/2020/06/21/calico%E7%BB%84%E4%BB%B6%E6%95%85%E9%9A%9C%E6%8E%92%E6%9F%A5/