问题一：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

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

image-20220725175143197

问题二：ImagePullBackOff 缺少镜像

image-20220731175827268

解决方法步骤

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

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
再次查看pod报错已经解决
kubectl get po --all-namespaces -o wide |grep state

image-20220731184922347

问题三：部署Elasticsearch错报

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

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
删除html方式启动pod
helm install elasticsearch -f values.yaml elastic/elasticsearch --namespace elk  #uninstall卸载的意思

最终解决方法

原因是因为 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
端口不通进入容器内部查看

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

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

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

问题五：

解决：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"

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
最终解决

查看node节点的

root@k8s-node1:/var/data# cat /etc/kubernetes/kubelet.conf | grep user
    user: default-auth
users:
  user:
root@k8s-node1:/var/data#

执行第一步

kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user default-auth

image-20220802165543301

执行第二步

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

image-20220802165634997

下载yaml文件

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

image-20220802165751765

sed全局修改配置文件

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

image-20220802165855125

执行yaml文件

kubectl apply -f 7bm6x2cwvtrwlx8m2k2n8n5v655gzjpgglqvgvg8rpbwxjl68w9r8j.yaml

image-20220802165926604

删除重新添加就执行

kubectl delete clusterrolebinding cluster-admin-binding

第一步跟第三步就可以了

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

问题状态

image-20220802175121945

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

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

image-20220802175333969

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

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

image-20220802180006656

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

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

vim /etc/docker/daemon.json
{
    "bip":"192.168.0.1/24"
}

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

问题七：日常错误排查

状态查看

查看 Pod 状态以及运行节点
kubectl get pods -o wide

kubectl -n kube-system get pods -o wide
查看 Pod 事件
kubectl describe pod <pod-name>
查看 Node 状态
kubectl get nodes

kubectl describe node <node-name>

二、日志查看

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

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

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

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

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

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

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

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

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

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

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

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

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
# kubernetes # docker # 容器
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes