企业级运维之云原生与Kubernetes实战课程
第四章第5讲 ACK集群故障处理与疑难处置
视频地址：
https://developer.aliyun.com/learning/course/913/detail/14609
一、存储疑难与故障
1. 在存储方面，常见的问题及可能的原因如下：
a. Pod挂载不上云盘
- 云盘卷是非共享存储，已经被其他Pod挂载；
- 云盘和ECS不在一个可用区；
- flexvolume/csi驱动使用错误；
b. Pod卸载不了云盘
- Pod所在的ECS将计费方式变为了包年包月(连带云盘也变成包年包月)，导致云盘无法从ECS卸载。
c. Pod挂载不了NAS
- NAS的权限组设置不对；
- 挂载点或者NAS挂载地址不存在；
2. 问题定位：查看驱动日志
为了准确定位问题原因，可以先查看驱动日志，阿里云提供的两个主要的存储组件是Flexvolum和CSI：
a. flexvolume:/var/loq/alicloud/flexvolume*;csi:
flexvolume插件是Kubernetes社区较早实现的存储卷扩展机制，插件包括以下三部分：
- Flexvolume：负责数据卷的挂载、卸载功能。ACK默认提供云盘、NAS、OSS三种存储卷的挂载能力；
- Disk-Controller：负责云盘卷的自动创建能力；
- Nas-Controller：负责NAS卷的自动创建能力；
b. CSI
CSI插件是当前Kubernetes社区推荐的插件实现方案，ACK集群提供的CSI存储插件兼容社区的CSI特性，插件包括以下两部分：
- CSI-Plugin：实现数据卷的挂载、卸载功能。ACK默认提供云盘、NAS、OSS三种存储卷的挂载能力；
- CSI-Provisioner：实现数据卷的自动创建能力，目前支持云盘、NAS两种存储卷创建能力；
查看csi-plugin Pod的日志;如果是动态存储，还需要查看nas-controller/disk-controller/csi-provisioner的日志。
3. 其他存储相关问题
a. NAS存储
- 现象：PVC无法创建，报错`waitingfor a volume to be created,either by external provisioner "nasplugin.csi.alibabacloud.com" or manually created by system administrator；
- 原因：创建阿里云Kubernetes 1.16之前版本的集群时，若存储插件选择为Flexvolume，则控制台默认安装Flexvolume与Disk-Controller组件，但控制台不会默认安装alicloud-nas-controller组件。
参考文档：https://help.aliyun.com/document_detail/86785.html
b. 挂载NAS的Pod无法启动
- 现象：查看pv和pvc同时为bound状态，describe pod显示挂载超时；
- 方法：查看flexvolume日志是否存在FsGroup字段；
- 原因：FsGroup:1000，表示mount使用uid=1000的特定用户进行挂载，Pod启动的时候，会把NAS挂载的目录下所有的文件权限改成1000，当文件较多的时候，会超过Pod的启动超时时间，导致Pod无法启动。
参考文档：https://help.aliyun.com/document_detail/286496.html
二、网络疑难与故障
常见的网络问题和可能的原因如下：
1. 访问slb不通
- 集群内访问不通，Service的externalTrafficPolicy策略为Local，非Service的后端Pod所在节点访问Service的slb IP就会不通；
- slb配置了黑白名单访问控制(常见的apiserver的slb配置了访问控制，控制台查看集群等信息失败)；
- ECS安全组出方向没有放通slb的IP；
2. 访问Ingress不通
- 集群内访问不通，原因同问题1中的第一种原因，因为Ingress IP也是Loadbalancer类型的Service的slb IP；
- nginx-ingress-controller所在的节点入方向安全组没有放通集群Pod网段；
- Ingress手动设置了白名单；
- Ingress的yaml配置有问题，导致ingress-controller无法正确加载配置，访问502；
3. 控制台访问异常
- apiserver出异常，或者apiserver的slb流量/连接数超过规格；
- apiserver的slb上设置了黑白名单；
4. Pod 不通
- Pod所在节点的网络设备没有开启forward；
- Pod里进程监听的回环地址；
三、Kubectl命令问题
Kubectl命令常见的问题和可能的原因如下：
1. 报 ** is forbidden;User ** cannot **错误
帐号的集群RBAC权限不够，从报错可以看到是缺少集群范围内的list某个资源的权限，且API Group为核心API组。
2. kubectl get可以，logs/exec不行
节点的安全组入方向没有放通kubelet的10250端口，kubectl和kubelet建联失败。kubectl会先和apiserver建连，然后 apiserver会访问Pod所在节点的kubelet(通过kubelet10250端口)建立连接，kubelet再和Pod通信。
3. kubectl 执行超时
- apiserver服务异常；
- apiserver的slb设置了访问控制；
- 其他问题：可以通过kubectl --v=8指定命令返回的日志级别来定位。
四、 节点自动伸缩问题
在节点自动伸缩方面，常见的问题和可能的原因如下：
1. 自动伸缩组件kube-autoscale异常
集群自动伸缩组件依赖集群的KubernetesWorkerRole-***的角色没有权限去调用弹性伸缩的相关接口。
2. 节点不自动扩容
- 集群未达到节点扩容的条件：pod因为节点资源不足而导致状态未pending的情况下才会触发节点扩容，而并非超过自动伸缩设定的阈值；
- 集群已经达到扩容的条件，但是由于自动伸缩的伸缩组配置的节点不满足Pod的要求，比如:
- Pod要求创建在杭州可用区D，但是配置的节点的交换机是可用区A ；
- Pod的request.cpu是4，但是伸缩组节点规格是2C；
- 如果上述两种情况都没有问题，可以通过检查cluster-autoscaler组件日志判断。
五、 Service问题
在Service方面常见的问题和可能的原因如下：
1. lb类型的service一直创建中
- slb可以挂载的backend server的数量已满；
- ECS可以重复挂载到slb的次数配额已满；
- cloud-controller-manager组件异常；
2. Service负载不均
- lb类型的service，是按照节点上Pod的数量比例来设置权重，保证Pod负载均衡，但是节点上会负载不均；
- 使用了长链接以及会话保持功能；
如下图所示，在V1.9.3.164-g2105d2e-aliyun之前版本，Local模式的Service其所有后端权重均为100，即所有流量平均分配到这三台ECS上，造成ECS1上Pod负载较重而ECS3上的Pod负载较轻，导致Pod负载不均。
解决方案：
- 如图所示，在V1.9.3.164-g2105d2e-aliyun之后及V1.9.3.276-g372aa98-aliyun之前版本，CCM会根据Node上部署的Pod数量计算Node权重。经计算三台ECS权重分别为16、33、50，因此流量将大致按照1：2：3的比例分配给三台ECS，Pod负载更加均衡。
计算公式如下：
- 在V1.9.3.276-g372aa98-aliyun及之后版本，CCM将Node上部署的Pod数量设置为Node权重，如下图所示，三台ECS的权重分别为1、2、3，流量会按照1：2：3的比例分配给三台ECS，Pod负载比上一种方式更加均衡。
计算公式如下：
3. 无法访问Service的虚拟IP
- 集群外无法访问：Service的虚拟IP在集群内是通过iptables或者ipvs转发来完成的，是虚拟IP，集群外不存在虚拟IP的路由，所以访问不通；
- 集群内无法ping通：Service的clusterlP是虚拟IP，只提供端口的转发，不提供icmp转发，所以访问不通；
- 集群内无法访问Service：Service的endpoint是空的，或者虽然有endpoint，但是Pod端口不对，或者Pod端口监听绑定的是回环地址。
