工作-k8s问题处理篇

前言：公司这边为集团，所以项目较多，我目前总负责的项目架构有十六个，其中还有海外项目，不过底下也有一定的细分，同事解决不了的问题会升级到我这，只k8s容器平台常用的就有三种，一种是技术中心部门研发的二开版，一种是国产XC化推广的xc容器平台，还有一种就是开源的-红帽公司研发的OpenShift (OKD)， 下面容器图片我只展示OKD，另外两种就不分享了，毕竟安全第一嘛！接下来我挑几个工作中遇到的比较有印象k8s方面的问题分享下处理方法和心得。



一、k8s集群以及云监控平台离线部署
公司这边的k8s集群有庞大的，也有微小集群，根据具体的业务需求来，这里我讲的是为某个项目拿三台云服务器，单独部署k8s集群后部署运行云监控平台，因为这个项目涉及金融，所以网络很特殊，无法连接我们的镜像仓库，只能给离线部署。
第一步：将原部署好的云监控平台的镜像都save下来
命令：docker save $(docker images | grep -v REPOSITORY | awk 'BEGIN{OFS=":";ORS=" "}{print $1,$2}') -o 自定义名字.tar
第二步：升级内核
挂载磁盘和配置逻辑卷不谈了，得给他服务器升级内核，因为内核版本太低了，这里我不详细说明操作了，如果有需要的话请评论告知，我会专门出一期。

第三步：部署docker本地镜像仓库
部署安装 Docker 本地镜像仓库（生产环境建议搭建Harbor）

1、部署安装Docker
2、上传 registry 的镜像到 Docker服务器上
3、创建本地镜像仓库存储卷
   mkdir -p /data/registry
   docker load -i registry-2.7.1.tar
4、运行 registry 服务
   docker run -d --name registry -p 5000:5000 -v /data/registry:/var/lib/registry --restart=always registry.szlanyou.com/lke/registry:2.7.1

5、修改 docker 配置文件，增加以下配置
   vi /etc/docker/daemon.json
   {
     "insecure-registries": ["<ip>:5000"]
   }

6、重启 docker 服务让配置生效
  systemctl daemon-reload
  systemctl restart docker

7、上传本地镜像到Docker服务器上，并执行以下命令，生成imagelist.txt文件
  docker images | grep -v REPOSITORY | awk '{OFS=":";print $1,$2}' > imagelist.txt

8、执行脚本将镜像服务上传到本地仓库
  修改 image_push.sh 中的new_registry为 <ip>:5000
  保存后执行 sh image_push.sh 脚本，等待镜像上传到本地仓库后即可

准备工作最好后，剩下的就不需要讲了，一步步的执行yaml文件运行起来就行

二、k8s节点内存告警处理
接收到监控机器人告警，同事回复后，升级到我这处理

第一步：查看各节点内存
在云监控web页面上或者后台使用命令查看各节点使用情况
参考命令：
kubectl top nodes：查看各个节点的 CPU 和内存使用情况基本命令
kubectl describe node <node-name>：查看详细指标
kubectl get nodes -o wide：显示节点的资源分配情况
kubectl top pods --all-namespaces：显示节点的 CPU 和内存容量以及它们的分配情况
kubectl top pod <pod-name> -n <namespace>：查看某个特定 Pod 的内存使用情况

第二步：发现问题
输入kubectl describe node 命令后发现，是因为某个节点打了污点，使用率只有30%多，而其他节点都达到80%往上。

第三步：解决方法
1、删除污点
kubectl taint nodes --all <taint-key>:<taint-effect>-
2、然后重启各项目的oap服务
OAP（Observability Analysis Platform）服务通常是一种可观测性分析平台服务，用于对应用程序和系统进行监控、追踪、日志分析等操作，以提供对系统运行状态的深入洞察。
Apache SkyWalking 的服务器端组件，负责接收来自应用的监控数据，进行处理和分析，是 SkyWalking 的核心部分。OAP 服务可以接收探针（如 Java Agent）发送的追踪数据，进行数据的存储、分析和聚合，并提供查询接口供 SkyWalking UI 使用，以便用户可以在 UI 界面上看到服务的监控数据。
3、重启lop命名空间下的deployment
命令：kubectl get deployments -n lop -o wide
将查询的pod重启，令集群重新分配资源

三、解决mysql、redis、中间件、自定义sql等监控不生效问题
1、有状态服务处理
根据集群上独有项目编号以及关键字来查询：
命令：kubectl -n <projectid> get pods | grep <pod-name> 查看pod状态
命令：kubectl -n <projectid> logs <pod-name> 查看日志信息，另外如果有那种有直接关联的服务的pod的日志也需要查询
以上是后台k8s节点服务器上，也可以在容器平台web界面上查询
分析：这里发现问题是同事初次纳入有状态信息录入错误，导致只是在云平台上删除后再重新纳入无法生效，需要清理节点上的缓存
解决方法：这里在后台或者容器平台web页面上删除对应的pod，重新根据正确的信息来配置纳入监控
2、自定义sql处理
邮件告警信息：

初步判定和数据链接有关系，这里很明显，不是去直接查看自定义sql的pod，而是先要查看采集器的pod日志信息，查询发现和确实是和数据库有关系。

分析原因：根据 telnet 命令输出，可以判断出网络是通的。但是下面错误信息报主机 ip 因为多次连接错误被封锁了。连接错误数超过了 MySQL 服务器设置的 max_connect_errors 值，导致MySQL 服务器封锁了这个 IP 。
解决方法：
①在对应的数据库服务器上命令：
命令：find / -name mysqladmin 2>/dev/null
搜索mysqladmin的路径，如下：
/www/server/mysql/bin/mysqladmin
②进入/www/server/mysql/bin/mysqladmin路径
执行命令：./mysqladmin -u root -p flush-hosts
清除 MySQL 服务器的 host cache 并解锁被封锁的 IP 地址
③查询及处理
show global variables like 'max_connect_errors';

用管理员账号，在MySQL的主库和从库都执行以下命令：set global max_connect_errors=100000;
经过判断发现此次问题是由于之前为处理 k8s 节点的内存告警，使得自定义 SQL 的pod发生了漂移，转移到了其他节点上

心得：处理 Kubernetes 问题时，首先需要确认问题影响范围，包括服务和 Pod 层面受影响的情况。接着检查集群和节点状态，查看 Pod 是否运行并就绪，通过查看 Pod 日志和事件进行诊断。同时，检查资源限制和服务配置，确保部署和标签选择器正确。若涉及网络或存储问题，需检查相关配置和状态。具体而言，在服务层面确定受影响的服务数量和可用性；在节点状态方面，查看节点是否 Ready 以及资源使用情况；对 Pod 的运行和就绪状态进行分析，包括查看日志和事件、检查资源请求与限制、服务配置、部署及标签选择器等。对于网络问题，检查网络插件、策略和 Pod 内部网络配置；对于存储问题，检查存储类、持久卷和存储挂载点等。