最近k8s遇到的一些问题

OOM killed  			内存溢出杀死,java堆溢出，找开发查
拉取镜像失败			节点测试手动拉取，重新docker login
running ，但是不可用     ping，节点查看kubelet服务，异常，cordon掉，重启服务
unkonwn		 ping，查看节点pod，节点查看docker  kubelet服务，cordon掉重启
NotReady       ping，节点查看docker  kubelet服务，cordon掉重启
UnexpectedAdmissionError     kubectl get pod -A |grep  UnexpectedAdmissionError| awk '{printf("kubectl delete pod ",$1,"-n",namespace)}'  | /bin/bash

journalctl  -u kubelet  --nopager
journalctl  -xefu kubelet  

statefuset pod存储空间清理不释放

磁盘空间满了。有很多core.xxx的大文件，判断为OOM产生。删除了几个，发现空间没有变化，mv走，gzip压缩空间都没有释放。删除句柄lsof -n |grep delete |awk '{print $2}' | xargs kill -9   还是没释放。

看目录名字应该是statefulset服务。查询statefulset确定绑定关系，进入pod清理，发现释放了部分空间。但是之前在节点上的空间没有释放。清理数据，delete pod后空间释放出来了。

k8s service访问异常

上午做压测，下午测试就不行了服务1访问服务2拒绝。
查询服务2两个od，都是running状态，监控显示一个死掉了，另一个无法进入。尝试重启pod，依然无法访问查看kube-dns，pod状态running，进入pod手动配置域名解析，满足临时访问。问题仍然在排查
后发现别的服务pod访问上也不正常，查看deployment发现可用为0。

[root@master ~]# kubectl  get deployment -nkube-system
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
kube-dns          2/2     2            0          154d
[root@master ~]# kubectl  delete pod kube-dns-b75-whqnx

进入pod注释掉之前的解析配置，nslookup服务名解析正常，解析其他服务正常

kubectl 集群切换

方法一
kubectl --kubeconfig .kube/config  get node
kubectl --kubeconfig ./config2  get node

方法二
export   KUBECONFIG=$HOME/.kube/config:$HOME/.kube/config2
kubectl  config use-context   cluster1     //user.name
kubectl   get node    //config里集群的信息
cat .kube/config
...
users:
- name: cluster1

gluster 日志问题

一个节点的磁盘告警，对应的volume都会告警，进而影响到所有绑定这些volume的pod节点告警
查找方法  随便进入一个节点 df -h  查看挂载的哪个volume,对应的IP。
gluster volume  info  | grep -C5   IP   查看组成volume的节点，分别查看每个节点的使用状态。
找到达到告警要求的节点。清理磁盘的空间。如果需要清理的是volume里的空间。根据volume名，进入pod里删除。

gluster的占用空间大

查看 .gluster 这个隐藏目录使用的空间，删除长期不使用的块
find .gluster  -type f -links l -atime +30 | xargs rm -f

gluster服务一起的pod pending

describe pod     //发现  无法挂载到enpoints   查看enponits确定是gluster volume挂载
gluster peer  status  发现有一台 disconnect
/etc/init.d/glusterfs-server start 
gluster peer  status  //检查链接ok，稍等查看pod的状态发现已经running
如果无法启动gluster-server，
查看enpoints对应的gluster volume 服务，gluster volume info 服务名  ，确定volume组成的节点ip。
把enpoints的ip指向可以连接的那个，观察pod的状态，再去想办法修复disconnect的节点，或者替换该节点的块。

回滚deployment

kubectl rollout restart deployment   test -n namespace    重启

helm安装显示不支持apiVersion

[root@master ~]# helm install --dry-run test2 sensu
Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"

查一下支持的apiVersion，修改

[root@master ~]# kubectl api-resources|grep deployment
deployments     deploy       apps/v1               true         Deployment

[root@master ~]# grep -r kind sensu/
sensu/templates/deployment.yaml:kind: Deployment    //修改这两个
sensu/charts/redis/templates/deployment.yaml:kind: Deployment  

修改完，测试，发现缺少 required field “selector”

[root@master ~]# helm install --dry-run test2 sensu
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

查看缺少的字段值，添加进去，

[root@master ~]# kubectl explain deployment.spec.selector

[root@master ~]# vim sensu/templates/deployment.yaml
...
spec:
  replicas: {{ .Values.replicaCount }}   
####添加的是一下三行配置
  selector:
    matchLabels:
      app: {{ template "sensu.fullname" . }}

重新测试，ok

[root@master ~]# helm install --dry-run test2 sensu
NAME: test2
LAST DEPLOYED: Mon May  2 10:20:30 2022

ingress发布出去的服务504 time out

查看服务ingress，查域名定位到vip 10.10.10.10，RIP： 10.10.10.11,10.10.10.12，也正是ingress-controller的节点机器，pod running状态。
curl -v -H "www.baidu.com" 10.10.10.10    not ok
curl -v -H "www.baidu.com" 10.10.10.11    not ok
curl -v -H "www.baidu.com" 10.10.10.12    ok
查看10.10.10.11主机，vip在它上面，重启它上面的ingress-controller后，服务访问正常

防火墙问题服务504 time out

直接curl -v  显示401报错，需要登录，在浏览器里登录一下，并找到cookie（很长）
curl -v -H "name" -H "cookie"  pod ip：端口      #发现卡主了
进入容器，netstat，发现SYNSENT状态的连接，说明连接发出没有建立。


/server # netstat
Active Internet connections (w/o servers)
Proto Recv-Q send-Q Local Address   Foreign Address   state
tcp 0 0 server-pod-7553-rgmw0:35964 10.116.26.167:mysql ESTABLISHED
tcp 1 0 server-pod-7553-rgmw0:8000 172.17.82.0:53484  CLOSE WA工T
tcp 0 1 server-pod-7553-rgmw0:39026 172.30.75.45:http  SYNSENT   卡主
tcp
0
/ server # telnet 172.30.75.45 80    #telnet 果然不通
/ server # ping  域名               #发现解析的正是这个ip，开完防火墙，服务就ok了

外网服务访问不到  服务正常   排查一圈发现
ingress-controller  异常，ingress异常  重启后访问正常

证书重新设置后    服务无法正常访问，部署未受影响，更新了所有节点的证书，重新部署了服务后正常

eks插件prometheus支持对外与入远程段地址
http://10.244.15.82:9090/api/v1/write通过Remote write协议接入Prometheus监控数据

健康检查的失败pod一致重启

k8s  pod  启动，容器始终处于running  0/1，最终因为健康检查的失败pod一直重启。
首先，进入pod，查看服务的日志，发现没有日志，感觉是entrypont没有执行。
由于熟悉健康检查的服务，直接对服务进行了启动，此时服务正常了。但是约十分钟，pod自动重启了。
接下来看下来:详细去看entrypoint。发现执行的是脚本，于是把脚本里的命令执行一遍，发现卡住了。
重启pod，再次进入容器，ps一下，发现chmod进程卡主了，杀死这些卡主的进程后，pod running了。
但是这并没有从根本上解决问题，date;chmod ..;date 统计了一下命令执行的时间，发现用时约5min。
由于是挂载的pvc，ping了一下pvc关联的主机，发现时延30ms，这已经很大了，节点与他因为是跨ragion。
暂时的解决方案，增减了执行健康检查等待的时间，长期的解决方案：迁移提供pvc的节点。