• K8S-遇到问题-解决日记


    文章目录

    问题一:etcd和apiserver无法正常启动

    问题查看nodes节点发生报错

    image-20220725174108867

    解决方法/步骤

    步骤一:K8S集群节点异常重启后,再终端执行kubectl get nodes命令,出现报错dial tcp 10.200.18.100:6443: connect: connection refused。
    步骤二:通过docker ps -a可以看到api现在处于exit退出状态。

    image-20220725174251074

    步骤三:查看apiserver服务容器的启动日志, 发现又出现报错Error while dialing dial tcp 127.0.0.1:2379: connect: connection refused,2379是etcd的端口,那么apiserver是由于etcd无法连接而启动不了。

    image-20220725174342681

    步骤四:
    接着查看etcd的启动日志,发现报错mvcc: cannot unmarshal event: proto: wrong wireType = 0 for field Key。经查询资料,此报错是由于服务器非正常关机(意外掉电,强制拔电)后 etcd数据损坏导致的,这个节点之前确实是出现异常关机,etcd无法启动,那么解决此问题就行了。

    image-20220725174412210

    image-20220725174427092

    步骤五:
    按照指导进行操作,在故障节点上停止etcd服务并删除损坏的 etcd 数据,现在etcd服务本来就没有启动,删除前先备份数据,最后启动etcd服务。
    注:容器的数据在/var/lib目录下,按照下图操作。
    root@k8s-master:/var/lib/etcd# find ./ -type d -name member
    ./member
    root@k8s-master:/var/lib/etcd# cd ./member
    root@k8s-master:/var/lib/etcd/member# ls
    snap  wal
    root@k8s-master:/var/lib/etcd/member# mkdir ../bak
    root@k8s-master:/var/lib/etcd/member# mv * ../bak/
    root@k8s-master:/var/lib/etcd/member# ls
    
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9

    image-20220725174552022

    步骤六:最后先启动etcd服务,然后启动api-server,执行kubectl get nodes后可以正常显示节点状态,问题解决。

    可以重启容器

    root@k8s-master:/var/lib/etcd/member# docker start 37f1e8e68a81  重启 etcd
    
    root@k8s-master:/var/lib/etcd/member# docker start c32fbf338038  重启 api
    
    • 1
    • 2
    • 3

    image-20220725175143197

    问题二:ImagePullBackOff 缺少镜像

    image-20220731175827268

    解决方法步骤

    查看pod的详细信息
    root@k8s-master:~# kubectl describe -n monitoring po  prometheus-adapter-6455646bdc-d72zx  #举例查看详细信息
    
    • 1

    image-20220731184511577

    报错查看缺少kube-state-metrics镜像

    拉取镜像修改tag

    root@k8s-node2:~# docker pull registry.cn-wulanchabu.aliyuncs.com/moge1/kube-state-metrics:v2.3.0
    v2.3.0: Pulling from moge1/kube-state-metrics
    2df365faf0e3: Pull complete 
    bbb17218abce: Pull complete 
    Digest: sha256:caf70de8662486ff35ac74e8631e348981faad5dd0c4e370742a141b38acd720
    Status: Downloaded newer image for registry.cn-wulanchabu.aliyuncs.com/moge1/kube-state-metrics:v2.3.0
    registry.cn-wulanchabu.aliyuncs.com/moge1/kube-state-metrics:v2.3.0
    root@k8s-node2:~# docker tag registry.cn-wulanchabu.aliyuncs.com/moge1/kube-state-metrics:v2.3.0 k8s.gcr.io/kube-state-metrics/kube-state-metrics:v2.5.0
    root@k8s-node2:~# docker images|grep state
    k8s.gcr.io/kube-state-metrics/kube-state-metrics                              v2.5.0              6ffbf5a790d8        6 months ago        38.7MB
    registry.cn-wulanchabu.aliyuncs.com/moge1/kube-state-metrics                  v2.3.0              6ffbf5a790d8        6 months ago        38.7MB
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    再次查看pod报错已经解决
    kubectl get po --all-namespaces -o wide |grep state
    
    • 1

    image-20220731184922347

    问题三:部署Elasticsearch错报

    启动es报错
    helm install elasticsearch -f values.yaml elastic/elasticsearch --namespace elk 
    
    • 1

    image-20220731185416360

    删除非kubectl启动pod
    kubectl delete -n elk po elasticsearch-master-0  #删除指定命名空间pod
    kubectl delete -n elk po elasticsearch-master-0 --force --grace-period=0  #强制删除命名空间pod 
    
    • 1
    • 2
    删除html方式启动pod
    helm install elasticsearch -f values.yaml elastic/elasticsearch --namespace elk  #uninstall卸载的意思
    
    • 1

    最终解决方法

    原因是因为 es是集群方式,然后运行内存是很大的,我的是因为运行内存不够了,才一直起不来

    image-20220731190011482

    要么加内存,要么减少一点,尝试能不能起来

    问题四:部署rancher页面化错报

    访问 https页面报错

    image-20220802101155191

    访问不到

    image-20220802101257100

    解决方法:telnet查看端口通不通

    root@k8s-node1:/var/data# telnet 196.196.196.11 443
    Trying 196.196.196.11...
    telnet: Unable to connect to remote host: Connection refused
    root@k8s-node1:/var/data# telnet 196.196.196.11 80
    Trying 196.196.196.11...
    telnet: Unable to connect to remote host: Connection refused
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    端口不通进入容器内部查看

    rancher里面内置了迷你版k8s,他会联网安装一些组件

    root@k8s-master:~# docker exec -it edc3fd71a33c /bin/bash
    root@edc3fd71a33c:/var/lib/rancher# ls
    k3s  k3s.log  management-state
    
    • 1
    • 2
    • 3

    image-20220802105230852

    问题原因之一,怀疑是k8s-master这台服务器内存不够,因为启动的这个容器,里面是迷你版本的k8s,尝试加大内存,或者修改方式

    切换版本2.5.3的版本
    docker run -d --restart=always --privileged=true -v /opt/rancher/data:/var/lib/rancher -v /opt/rancher/auditlog:/var/log/auditlog -p 8081:80 -p 8443:443 --name rancher-v2.5.3 rancher/rancher:v2.5.3
    
    • 1

    问题五:

    解决:metrics-server启动时报unable to recognize ““: no matches for kind ““ in version “*“ 等错误

    相关报错问题

    unable to recognize "auth-delegator.yaml": no matches for kind "ClusterRoleBinding" in version "rbac.authorization.k8s.io/v1beta1"
    unable to recognize "auth-reader.yaml": no matches for kind "RoleBinding" in version "rbac.authorization.k8s.io/v1beta1"
    unable to recognize "metrics-apiservice.yaml": no matches for kind "APIService" in version "apiregistration.k8s.io/v1beta1"
    
    
    • 1
    • 2
    • 3
    • 4

    image-20220802140838001

    解决:

    报错的原因是因为资源文件的版本定义过期了,需要修改下版本

    #删除已创建的容器
    [root@k8s-master01 1.8+]# kubectl delete -f ./
    [root@k8s-master01 1.8+]# sed -i 's#rbac.authorization.k8s.io/v1beta1#rbac.authorization.k8s.io/v1#' auth-reader.yaml
    [root@k8s-master01 1.8+]# sed -i 's#rbac.authorization.k8s.io/v1beta1#rbac.authorization.k8s.io/v1#' auth-delegator.yaml
    [root@k8s-master01 1.8+]# sed -i 's#apiregistration.k8s.io/v1beta1#apiregistration.k8s.io/v1#' metrics-apiservice.yaml
     
    #重新创建
    [root@k8s-master01 1.8+]# kubectl apply -f ./
    clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
    clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
    rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
    apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created
    serviceaccount/metrics-server created
    deployment.apps/metrics-server created
    service/metrics-server created
    clusterrole.rbac.authorization.k8s.io/system:metrics-server created
    clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
     
    #查看pod是否运行成功
    [root@k8s-master01 1.8+]# kubectl get pods -n kube-system
    metrics-server-644778ff4f-87fgn        1/1     Running   0               16h
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    最终解决

    查看node节点的

    root@k8s-node1:/var/data# cat /etc/kubernetes/kubelet.conf | grep user
        user: default-auth
    users:
      user:
    root@k8s-node1:/var/data# 
    
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    执行第一步

    kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user default-auth
    
    
    • 1
    • 2

    image-20220802165543301

    执行第二步

    curl --insecure -sfL https://196.196.196.11:8443/v3/import/jtbz8lsk9hcl49ggtsrt2vqtqbtjj5b8qcprmbm8gf2sd44pj6stw8.yaml | kubectl apply -f -
    
    • 1

    image-20220802165634997

    下载yaml文件

    wget https://196.196.196.11:8443/v3/import/7bm6x2cwvtrwlx8m2k2n8n5v655gzjpgglqvgvg8rpbwxjl68w9r8j.yaml --no-check-certificate
    
    • 1

    image-20220802165751765

    sed全局修改配置文件

    sed -i 's#rbac.authorization.k8s.io/v1beta1#rbac.authorization.k8s.io/v1#' 7bm6x2cwvtrwlx8m2k2n8n5v655gzjpgglqvgvg8rpbwxjl68w9r8j.yaml
    
    • 1

    image-20220802165855125

    执行yaml文件

    kubectl apply -f 7bm6x2cwvtrwlx8m2k2n8n5v655gzjpgglqvgvg8rpbwxjl68w9r8j.yaml
    
    • 1

    image-20220802165926604

    删除重新添加就执行

    kubectl delete clusterrolebinding cluster-admin-binding
    
    • 1

    第一步跟第三步就可以了

    问题六:rancher显示0/1 Running问题排查

    问题状态

    image-20220802175121945

    发现k8s-node2节点的coredns出现0/1 Running状态;

    查看详细信息:
    kubectl describe  pod   cattle-cluster-agent-ccb7694db-htdk8 -n cattle-system
    
    • 1

    image-20220802175333969

    主要报错信息为:活动探测失败:HTTP探测失败状态码为:503 这个信息对我来说完全没用,目前只知道是node从机kubelet上部署的coreDNS组件工作异常,仅此而已。

    查看pod日志
     kubectl logs -f    cattle-cluster-agent-ccb7694db-htdk8 -n cattle-system
    
    • 1

    image-20220802180006656

    一、跑Rancher 的机器Docker和K8S Docker容器网段相同!
    昨天因为需求,所以需要部署新的环境,然后就创建了kubenetes,想着还是使用rancher来管理来着,但是在导入rancher的时候总是报错:websocket: bad handshake,百度了很久,有的说是因为插件的问题,有的说是计算机名的问题,还有的说是rancher的底层问题。但是我前段时间确实使用的同一个版本的rancher和kubenetes做导入是没有任何问题的。都正常了。没办法,只能一个一个的找了,我发现kubenetes中的pod无法和我node节点同一个网段的节点通信,这个就比较出来了,原来pod不是跟所有node节点,只是和rancher这个服务的节点不能通行,其他都正常,而且rancher客户端的日志出现内容如下:
    
    • 1
    • 2

    解决方法:
    我尝试着在pod里去ping一下rancher的节点ip,不能通信,和其他的节点正常,这个问题就比较明显了,rancher这个节点有问题。下面继续分析,在rancher这个服务上的docker的ip地址和node节点的ip地址是一个网段的,有冲突了。修改一下docker的节点ip端。

    vim /etc/docker/daemon.json
    {
        "bip":"192.168.0.1/24"
    }
    
    • 1
    • 2
    • 3
    • 4

    我这里docker默认的网断和宿主机是一个网段的,这里做一下修改,然后重启一下docker,在重新试一下问题解决。

    问题七:日常错误排查

    状态查看

    查看 Pod 状态以及运行节点
    kubectl get pods -o wide
    
    kubectl -n kube-system get pods -o wide
    
    • 1
    • 2
    • 3
    查看 Pod 事件
    kubectl describe pod 
    
    • 1
    查看 Node 状态
    kubectl get nodes
    
    kubectl describe node 
    
    • 1
    • 2
    • 3

    二、日志查看

    kube-apiserver 日志
    PODNAME=$(kubectl -n kube-system get pod -l component=kube-apiserver -o
    
    jsonpath='{.items[0].metadata.name}')
    
    kubectl -n kube-system logs $PODNAME --tail 100
    
    • 1
    • 2
    • 3
    • 4
    • 5

    以上命令操作假设控制平面以 Kubernetes 静态 Pod 的形式来运行。如果 kube-apiserver 是用 systemd 管理的,则需要登录到 master 节点上,然后使用

     journalctl -u kube-apiserver 查看其日志。
    
    • 1

    kube-controller-manager 日志

    PODNAME=$(kubectl -n kube-system get pod -l
    
    component=kube-controller-manager -o jsonpath='{.items[0].metadata.name}')
    
    kubectl -n kube-system logs $PODNAME --tail 100
    
    • 1
    • 2
    • 3
    • 4
    • 5

    ●以上命令操作假设控制平面以 Kubernetes 静态 Pod 的形式来运行。如果 kube-controller-manager 是用 systemd 管理的,则需要登录到 master 节点上,

    然后使用 journalctl -u kube-controller-manager 查看其日志。
    
    • 1

    kube-scheduler 日志

    PODNAME=$(kubectl -n kube-system get pod -l component=kube-scheduler -o
    
    jsonpath='{.items[0].metadata.name}')
    
    kubectl -n kube-system logs $PODNAME --tail 100
    
    • 1
    • 2
    • 3
    • 4
    • 5

    ●以上命令操作假设控制平面以 Kubernetes 静态 Pod 的形式来运行。如果 kube-scheduler 是用 systemd 管理的,则需要登录到 master 节点上,

    然后使用 journalctl -u kube-scheduler 查看其日志。
    
    • 1

    kube-dns 日志

    kube-dns 通常以 Addon 的方式部署,每个 Pod 包含三个容器,最关键的是 kubedns

    容器的日志:

    PODNAME=$(kubectl -n kube-system get pod -l k8s-app=kube-dns -o
    
    jsonpath='{.items[0].metadata.name}')
    
    kubectl -n kube-system logs $PODNAME -c kubedns
    
    • 1
    • 2
    • 3
    • 4
    • 5

    Kubelet 日志

    Kubelet 通常以 systemd 管理。查看 Kubelet 日志需要首先 SSH 登录到 Node

    上,推荐使用 kubectl-node-shell而不是为每个节点分配公网 IP 地址。比如:··

    [root@localhost ~]# cat kubectl-node_shell
    #!/bin/sh
    if [ -z "$1" ]; then
      echo "Please specify node name"
      exit 1
    fi
    
    NODE="$1"
    IMAGE="alpine"
    POD="nsenter-$(env LC_CTYPE=C tr -dc a-z0-9 < /dev/urandom | head -c 6)"
    NAMESPACE=""
    
    # Check the node
    kubectl get node "$NODE" >/dev/null || exit 1
    
    OVERRIDES="$(cat <<EOT
    {
      "spec": {
        "nodeName": "$NODE",
        "hostPID": true,
        "containers": [
          {
            "securityContext": {
              "privileged": true
            },
            "image": "$IMAGE",
            "name": "nsenter",
            "stdin": true,
            "stdinOnce": true,
            "tty": true,
            "command": [ "nsenter", "--target", "1", "--mount", "--uts", "--ipc", "--net", "--pid", "--", "bash", "-l" ]
          }
        ]
      }
    }
    EOT
    )"
    
    echo "spawning \"$POD\" on \"$NODE\""
    kubectl run --namespace "$NAMESPACE" --rm --image alpine --overrides="$OVERRIDES" --generator=run-pod/v1 -ti "$POD"
    chmod +x ./kubectl-node_shell
    sudo mv ./kubectl-node-shell /usr/local/bin/kubectl-node_shell
    [root@localhost ~]# ./kubectl-node_shell localhost.localdomain
    spawning "nsenter-i71opm" on "localhost.localdomain"
    If you don't see a command prompt, try pressing enter.
    [root@localhost /]# journalctl -l -u kubelet
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46

    Kube-proxy 日志

    Kube-proxy 通常以 DaemonSet 的方式部署,可以直接用 kubectl 查询其日志

    kubectl -n kube-system get pod -l component=kube-proxy
    NAME READY STATUS RESTARTS AGE
    kube-proxy-42zpn 1/1 Running 0 1d
    kube-proxy-7gd4p 1/1 Running 0 3d
    kube-proxy-87dbs 1/1 Running 0 4d
    $ kubectl -n kube-system logs kube-proxy-42zpn
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6

    ter-i71opm" on “localhost.localdomain”
    If you don’t see a command prompt, try pressing enter.
    [root@localhost /]# journalctl -l -u kubelet

    
    ### Kube-proxy 日志
    
    Kube-proxy 通常以 DaemonSet 的方式部署,可以直接用 kubectl 查询其日志
    
    ```shell
    kubectl -n kube-system get pod -l component=kube-proxy
    NAME READY STATUS RESTARTS AGE
    kube-proxy-42zpn 1/1 Running 0 1d
    kube-proxy-7gd4p 1/1 Running 0 3d
    kube-proxy-87dbs 1/1 Running 0 4d
    $ kubectl -n kube-system logs kube-proxy-42zpn
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
  • 相关阅读:
    Cosmopolitan:一次构建,多平台原生运行的C语言库行!
    guava本地缓存CacheLoader使用
    腾讯云服务器安装配置rabbitmq
    19、架构-虚拟化容器
    docker (网卡设置、namespace、网络互通)
    自我成长自学必备网站,终生学习平台
    TinyKv Project4 Transactions
    LeetCode 两数之和 & 三数之和& 四数之和
    Guava中的封装的Map操作
    各种符号地址,可以直接复制粘贴使用
  • 原文地址:https://blog.csdn.net/tianmingqing0806/article/details/126389651