kubesphere 问题解决

1、镜像下载不下来，到对应节点 docker pull

2、重启节点后，无监控数据，因为你没有正确退出节点，这样退链接

其实就是
停止调度，
kubectl cordon node1

重启kubectl,docker
然后静静地等待

journalctl -xef -u kubelet
journalctl -xef -u docker
# 也能查看docker的问题所在，可能是daemon.json文件写错了 
dockerd 

kubectl cordon node1

systemctl stop kubelet 
systemctl stop docker

恢复 docker 和 kubelet

systemctl start docker
systemctl status docker
systemctl start kubelet
systemctl status kubelet

恢复调度
kubectl uncordon node1

3、kubelet (code=exited, status=1/FAILURE)

因为中途重装了下docker，通过 journalctl -f -u kubelet 查看日志
在/etc/docker/daemon.json 中加入

"exec-opts":["native.cgroupdriver=systemd"]

配置dev用户使用kubectl使用权限

1、切换到普通用户操作：
su - dev
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.kubeconfig $HOME/.kube/config
sudo chown dev:dev $HOME/.kube/config
　　2、配置环境变量：

export KUBECONFIG=/etc/kubernetes/admin.conf （看情况，有时候可以不需要）
export KUBECONFIG=/home/dev/.kube/config
echo “source <(kubectl completion bash)” >> ~/.bashrc （看情况，有时候可以不需要）
给dev加docker使用权限
usermod -G docker dev

4、docker迁移之前严格按照节点启停操作

mkdir   -p   /data/docker   
systemctl   stop docker

/bin/cp   -R   /var/lib/docker/*   /data/docker/ 
vi /etc/docker/daemon.json #graph那个改成 /data/docker/

systemctl daemon-reload 
systemctl restart  docker 

集群部署版本

./kk create cluster --with-kubernetes v1.21.5 --with-kubesphere v3.2.1
./kk create config --from-cluster
vi sample.yaml
./kk add nodes -f sample.yaml

5、k8s官网中文介绍

6、线程数限制

ps -ef |grep kubelet
vi /var/lib/kubelet/config.yaml
# 然后修改 podPidsLimit
systemctl restart kubelet
#测试
# 在pod里
 for x in {1..10000};do sleep 1000 & done
# 在宿主机 
ps faux | grep fork | wc -l

8 环境变量

vi ~/.bashrc
export PATH=$PATH:/usr/local/bin/
source ~/.bashrc

9、kubelet has insufficient PID available k8s节点一直有PIDPresure的问题，导致很多pod被驱逐了

vim /etc/sysctl.conf
kernel.pid_max = 4194303
sysctl -p

10、unable to retrieve the complete list of server API

kubectl get apiservice
#删除出问题的apiservice
kubectl delete apiservice <service-name>

11、大量pod terminating

我删除了这个节点，然后删除了/etc/kubernetes这个文件夹，然后加入这个节点，之前的pod都复原了

修改IP

主节点的ip不能动
node节点的ip可动，

./kk create config --from-cluster
vim sample.yaml # 修改ip
./kk add nodes -f sample.yaml

主节点如果换ip
保持局域网，先卸载ceph，再卸载k8s, 然后换ip，重新再来装一遍

12 k8s failed to watch file “/var/log/pods/xxx.log“: no space

sysctl fs.inotify.max_user_watches
# 默认是
fs.inotify.max_user_watches = 8192
vi /etc/sysctl.conf
fs.inotify.max_user_watches = 2097152
/sbin/sysctl -p

首先，我们需要理解什么是 inotify。你可以把 inotify想象成一个邮差，它的工作就是监控你想要关注的房子（在这里，房子就是文件或者目录），并在房子发生任何变动（如有新邮件，有人进出等）时向你报告。

fs.inotify.max_user_watches 这个参数就像是你可以雇佣的邮差的最大数量。如果你想监控的房子太多，超过了你可以雇佣的邮差的数量，你就需要增加你可以雇佣的邮差的数量，也就是增大fs.inotify.max_user_watches 的值。

以一个实际的例子来说，比如你运行了一个大型的网站，这个网站有数以百万计的用户，每个用户的数据都存放在一个文件里。你希望在用户数据发生变化时立刻得到通知，以便做出相应的处理（比如更新缓存，发送通知等）。你就需要为每个用户文件都创建一个inotify 监视器。

然而，如果 fs.inotify.max_user_watches的值设得太小，比如只有8192，那么当你需要创建第8193个监视器时，操作系统就会拒绝，并返回一个 “No space left on device” 的错误，即使你的硬盘上还有大量的空闲空间。此时，你就需要增大 fs.inotify.max_user_watches 的值，以便你可以创建更多的 inotify 监视器。

“Writing labels to output file” 这个操作是在 GPU Feature Discovery (GFD) 工作过程中的一个关键步骤。这是将发现的 GPU 特性（标签）写入到一个特定的输出文件中。

在 Kubernetes 的环境中，节点特性发现器 (Node Feature Discovery, NFD) 使用这些输出文件来收集和公开节点级别的特性信息。NFD 会读取这些文件，然后将文件中的标签添加到对应的 Kubernetes 节点上，以便调度器可以使用这些信息进行更智能的调度决策。

如果你看到 “Writing labels to output file” 一直在进行，可能是 GFD 在定期刷新这些输出文件。因为 GPU 的状态可能会发生变化，例如新的 GPU 被添加，或者存在的 GPU 的状态发生了变化（比如负载、温度、功率状态等），GFD 需要定期更新输出文件以反映这些变化。

另外，也有可能是出现了某种错误或异常情况，导致 GFD 一直在尝试写入这些文件但是没有成功。你可以查看 GFD 的日志以获取更详细的信息。

13

Jun 07 10:19:03 node3 kubelet[2009]: E0607 10:19:03.424860 2009 manager.go:1123] Failed to create existing container: /kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod532a2c99_e777_46b0_8c95_2e6fa6c54850.slice/docker-23281015deb9d0c43ad86bd508d415e5c33fb21d2f6d59fe6fb63432f8c1d9b8.scope: failed to identify the read-write layer ID for container “23281015deb9d0c43ad86bd508d415e5c33fb21d2f6d59fe6fb63432f8c1d9b8”. - open /var/lib/docker/image/overlay2/layerdb/mounts/23281015deb9d0c43ad86bd508d415e5c33fb21d2f6d59fe6fb63432f8c1d9b8/mount-id: no such file or directory
Jun 07 10:19:03 node3 kubelet[2009]: E0607 10:19:03.427018 2009 manager.go:1123] Failed to create existing container: /kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod6cdf55c1_7cfd_4f1e_869d_04e62a91f923.slice/docker-67c38c802c972ef480c73b4db1809d071be1fddbc46c1e19bcd9a74997d8754f.scope: failed to identify the read-write layer ID for container “67c38c802c972ef480c73b4db1809d071be1fddbc46c1e19bcd9a74997d8754f”. - open /var/lib/docker/image/overlay2/layerdb/mounts/67c38c802c972ef480c73b4db1809d071be1fddbc46c1e19bcd9a74997d8754f/mount-id: no such file or directory
Jun 07 10:19:05 node3 kubelet[2009]: E0607 10:19:05.586979 2009 remote_runtime.go:334] “ContainerStatus from runtime service failed” err=“rpc error: code = Unknown desc = Error: No such container: fec9861cf564dc0d7a1440e0dc6ecb2ab4e3ae01ab519dd6292904cbc365838f” containerID=“fec9861cf564dc0d7a1440e0dc6ecb2ab4e3ae01ab519dd6292904cbc365838f”
Jun 07 10:19:05 node3 kubelet[2009]: E0607 10:19:05.587052 2009 kuberuntime_manager.go:1018] “getPodContainerStatuses for pod failed” err=“rpc error: code = Unknown desc = Error: No such container: fec9861cf564dc0d7a1440e0dc6ecb2ab4e3ae01ab519dd6292904cbc365838f” pod=“triton/face-triton-server-deployment-59b694f4d7-jtmml”

这些错误信息看起来像是 Kubernetes 在尝试访问一些 Docker 容器时遇到了问题，但是无法找到这些容器的读写层。这可能是由于容器已经被删除，或者容器的元数据被损坏。

systemctl restart docker 
systemctl restart kubelet 

14 fork:cannot allocate memory

查看最大进程数 sysctl kernel.pid_max
ps -eLf | wc -l查看 进 程数
修改最大进程数 永久生效
echo "kernel.pid_max=1000000 " >> /etc/sysctl.conf
sysctl -p

15

gpu-feature-discovery: 2023/06/14 08:42:27 Exiting
gpu-feature-discovery: 2023/06/14 08:42:27 Error: error creating NVML labeler: failed to initialize NVML: unexpected failure calling nvml.Init: error opening libnvidia-ml.so.1: libnvidia-ml.so.1: cannot open shared object file: No such file or directory

自己装docker和nvidia-docker2，注意下面这两点改好

Error: Package: nvidia-docker2-2.13.0-1.noarch (libnvidia-container)
Requires: docker-ce >= 18.06.3.ce-3.el7
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
这个问题，你就自己装docker解决

16 删除节点

 kubectl drain node01 --delete-local-data --force --ignore-daemonsets
 kubectl delete nodes node01
 添加节点的时候按官网的操作就行了，它自己会解决那些目录问题

17 Error: unable to retrieve the complete list of server APIs: custom.metrics.k8s.io/v1beta1: the server is currently unable to handle the request

2023/06/15 13:27:15 unable to retrieve the complete list of server APIs: custom.metrics.k8s.io/v1beta1: the server is currently unable to handle the request

kubectl get apiservice
找到false那个
kubectl delete apiservce <service-name>

下面的没啥用
【kubectl get pods -n kube-system 看看有没有 metrics-server，没有的话下面
metrics-server部署一下，在 Kubernetes 上安装
kubectl get po -A -o wide|grep api 找下 kubesphere-system下的ks-api
kubectl logs -f -p pod-name -n kubesphere-system 看下日志什么问题
用11号问题解决】

18 节点设置污点，让新来的pod不调度到这台机器上

# 在node1上添加一个污点
kubectl taint nodes node1 key=value:NoSchedule
# 查看污点
kubectl describe node node1 | grep Taint
# 取消这个污点
kubectl taint nodes node1 key:NoSchedule-

19 docker build卡死

因为IO满了，
通过查看谁占用满了IO iotop -o
如何进程频繁地启停，PID总变 通过 ps -o pid,ppid,comm -p $(pgrep 进程的名字) 查看它的父进程是谁

20 部署K8s报错 failed to get container info for"/system.slice/kubelet.service"

vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
加上这两句
[Service]
CPUAccounting=true ## 添加 CPUAccounting=true 选项，开启 systemd CPU 统计功能
MemoryAccounting=true ## 添加 MemoryAccounting=true 选项，开启 systemd Memory 统计功能

21 查看/var/lib/kubelet/pods/ 文件夹下的文件夹属于哪个pod

kubectl get pods --all-namespaces -o json | jq '.items[] | select(.status.hostIP == "Node_IP_Address" and .status.phase == "Running" and .metadata.uid == "24af747f-9190-43fc-8c9c-cd242e4f937a") | {name: .metadata.name, namespace: .metadata.namespace}'

kubectl logs

du -h --max-depth=1  # 按文件夹大小排列的就在下面
du -sh ./*
du -h --max-depth=1 /data/home/lisen/
# 删除镜像即其容器
IMAGE_NAME_OR_ID=<镜像id>
docker ps -aq --filter ancestor=$IMAGE_NAME_OR_ID | xargs -r docker stop && docker ps -aq --filter ancestor=$IMAGE_NAME_OR_ID | xargs -r docker rm && docker rmi $IMAGE_NAME_OR_ID

lb.kubesphere.local解析到了.5的服务器，应该是.4，看看是不是configmap里的问题

docker因为断电不能重启了，找回原来的代码在
/home/docker/overlay2/xxx/diff/

7、overlay占用过大问题

根据overlay2文件名查找容器
收藏里也有，还能根据文件夹大小排序

# 文件夹里的所有文件从小到大排列
find . -type f -printf "%p %k\n" | sort -n -k 2  
# 找到大于5G的文件
find / -type f -size +5G 
# 首先进入到 /var/lib/docker/overlay2 目录下,查看谁占用的较多
du -s ./* | sort -rn | more
# 输出依次为，进程pid、容器ID、容器名、存储work路径，即可确定是哪个容器。
docker ps -q | xargs docker inspect --format '{{.State.Pid}}, {{.Id}}, {{.Name}}, {{.GraphDriver.Data.WorkDir}}' | grep bff25099a59b0fc8addd06f9223872f2904256f0432b3c3c47b58faef167115f

如何查看 /var/lib/docker/containers下的fa7fc77b69d870957cf26f9405b7a1a208ea6d5f7af8527b02e66ae118f05f8d文件夹对应的是哪个容器，哪个镜像？

要查看 /var/lib/docker/containers/fa7fc77b69d870957cf26f9405b7a1a208ea6d5f7af8527b02e66ae118f05f8d 文件夹对应的容器和镜像，可以通过以下几个步骤来完成：

1. 查看容器 ID 的详细信息：
   使用 docker inspect 命令来查看容器的详细信息。容器 ID 通常是文件夹名称的前12个字符。

   docker inspect fa7fc77b69d8
   

   该命令将输出包含容器详细信息的 JSON 数据。

2. 查找容器名称：
   在 docker inspect 命令的输出中，查找 Name 字段，该字段显示容器的名称。

3. 查找镜像名称：
   在 docker inspect 命令的输出中，查找 Image 字段，这将显示镜像的 SHA256 哈希值。

   为了将 SHA256 哈希值转换为镜像名称，可以使用以下命令：

   docker images --no-trunc
   

   在输出结果中找到与 Image 字段匹配的 SHA256 哈希值对应的镜像名称。

具体步骤示例

1. 查看容器 ID 的详细信息：

   docker inspect fa7fc77b69d8
   

   示例输出（部分）：

   [
       {
           "Id": "fa7fc77b69d870957cf26f9405b7a1a208ea6d5f7af8527b02e66ae118f05f8d",
           "Name": "/my-container",
           "Image": "sha256:abcd1234efgh5678ijkl9101mnopqrstuvwx2345yz6789abcdef0123456789"
           ...
       }
   ]
   

2. 查找镜像名称：

   docker images --no-trunc
   

   示例输出：

   REPOSITORY          TAG                 IMAGE ID                                                           CREATED             SIZE
   my-image            latest              sha256:abcd1234efgh5678ijkl9101mnopqrstuvwx2345yz6789abcdef0123456789   2 weeks ago         500MB
   

通过以上步骤，您可以确定 /var/lib/docker/containers/fa7fc77b69d870957cf26f9405b7a1a208ea6d5f7af8527b02e66ae118f05f8d 文件夹对应的容器名称是 my-container，镜像名称是 my-image:latest。

22 查看谁占用内存多

ps aux | awk '{print $6/1024 " MB\t\t" $2 "\t\t" $11}' | sort -n

查看命名空间app下哪个pod占用内存大

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# 安装完成后，你需要稍等片刻，让 metrics-server 有足够的时间收集到相关的指标

kubectl top pods -n app --sort-by=memory | head -n 5
# 或者
kubectl top pods -n app

8、把版本也去掉查的，不加版本查的。将有关的images都删了。把有问题的overlay2移走了。然后重新docker pull image就行了。

9、
可以直接 kubectl create -f xxx.yaml
也可以分两步 curl -O xxx.yaml kubectl create -f 无网址的xxx.yaml
删除时用kubectl delete -f xxx.yaml就能删除干净

10、查看没有运行容器的image的overlay2
diff中保存的就是差分信息，merged是在容器运行时才会出现的存储情况集合

path="/home/docker/overlay2/"
for file in `ls $path`
do
  #echo $file
  cd ${path}${file}
  if [ ! -d "./merged" ];then
    echo `pwd`
  fi
done

23、k8s.gcr.io 镜像拉不下来的问题

在docker hub上找一个能用的

docker pull v5cn/prometheus-adapter:v0.10.0
docker tag v5cn/prometheus-adapter:v0.10.0 k8s.gcr.io/prometheus-adapter/prometheus-adapter:v0.10.0
kubectl get apiservice | grep metrics

24、

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
Loaded plugins: fastestmirror, nvidia
adding repo from: https://download.docker.com/linux/centos/docker-ce.repo
grabbing file https://download.docker.com/linux/centos/docker-ce.repo to /etc/yum.repos.d/docker-ce.repo
Could not fetch/save url https://download.docker.com/linux/centos/docker-ce.repo to file /etc/yum.repos.d/docker-ce.repo: [Errno 14] curl#7 - “Failed to connect to 2600:9000:2135:5600:3:db06:4200:93a1: Network is unreachable”

解决之道
你的错误提示显示，你的系统试图通过IPv6地址来访问Docker的仓库，但是无法建立连接。这可能是因为你的网络环境不支持IPv6，或者对IPv6的支持有问题。

你可以尝试以下的解决方法：

禁用IPv6：你可以临时或永久地禁用IPv6，以强制你的系统使用IPv4。以下是在CentOS系统中临时禁用IPv6的方法：

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

25 镜像下载不下来

在daemon.json里加这个 “registry-mirrors”: [“https://ustc-edu-cn.mirror.aliyuncs.com”],

26 pod删除不掉

因为关联的pv没有删除掉

kubectl patch pv xxx -p '{"metadata":{"finalizers":null}}'
kubectl delete pv xxx
kubectl delete pod xxx

一直处于 terminating

kubectl patch pod xxx -n xxx -p '{"metadata":{"finalizers":null}}'
kubectl delete pod xxx -n xxx --force --grace-period=0
# 删除命名空间下所有资源
kubectl delete --all --namespace=xxx

27 如果kubesphere原装监控和你的监控冲突，重装kubesphere的监控

集成你自己的监控
把它原来的prometheus-operator干掉
概览监控看不到？这样搞 学习链接e

cd kube-prometheus/kustomize
sed -i 's/kubesphere-monitoring-system/monitoring/g' prometheus-rulesEtcd.yaml
sed -i 's/kubesphere-monitoring-system/monitoring/g' prometheus-rules.yaml
kubectl apply -f prometheus-rules.yaml -f prometheus-rulesEtcd.yaml

28 镜像丢失

驱逐详解
磁盘空间不够15%，会驱逐 不用的images

ks-apiserver CrashLoopBackOff

kubesphere论坛解决之道
github解决之道

原因是Prometheus adaptor 没起来，因为拉 k8s.gcr.io 拉不来，拉完后，
kubectl -n kubesphere-system rollout restart deployment/ks-apiserver

29 节点NotReady

用上面的方法，查看kubelet和docker 日志
这次我是删除了有问题的pod，遇见一个删不掉的容器，我重启了kubelet和docker后正常了

systemctl status kubelet
kubectl describe node NodeName

30 docker 自动删除镜像

这跟k8s的自动回收机制有关，看看内存，磁盘使用率，
注意这个目录，看看toot空间是否超过85%。 注意这个目录 /var/lib/kubelet/pods

31 Prometheus wal

kubectl edit prometheus k8s -n kubesphere-monitoring-system
修改rentention=7h

Prometheus是一个开源的监控系统，其中WAL是指写前日志，用于持久化Prometheus的时间序列数据。下面是一些配置Prometheus WAL的方法：

WAL目录的位置：可以通过在Prometheus配置文件中设置--wal-dir参数来指定WAL目录的位置。例如：--wal-dir=/var/lib/prometheus/wal。

WAL segment的最大大小：可以通过在Prometheus配置文件中设置--storage.tsdb.wal.max-segment-size参数来指定WAL segment的最大大小。例如：--storage.tsdb.wal.max-segment-size=100MB。

WAL segment的保留期限：可以通过在Prometheus配置文件中设置--storage.tsdb.wal.retention参数来指定WAL segment的保留期限。例如：--storage.tsdb.wal.retention=6h。

WAL compression的开启：可以通过在Prometheus配置文件中设置--storage.tsdb.wal.compress参数来开启WAL的压缩。例如：--storage.tsdb.wal.compress=true。

WAL bypassing的关闭：可以通过在Prometheus配置文件中设置--storage.tsdb.wal.bypass-cache参数来关闭WAL的缓存绕过。例如：--storage.tsdb.wal.bypass-cache=false。

这些是一些配置Prometheus WAL的常见方法，可以根据具体需求进行调整。需要注意的是，修改Prometheus的WAL配置可能会对性能和存储需求产生影响，因此需要仔细评估并测试配置变更的影响。

32 安装时候报etcd问题—清理etcd重装

清理
rm .kube/* -rf
rm -rf /var/lib/etcd
rm -rf /etc/ssl/etcd
sudo kk delete cluster -f sample.yaml
在这下面会有以虚拟机hostname命名的目录,删掉,里面存放了etcd的一些配置信息(旧IP相关)
同时kubekey目录下还有一个pki/etcd的目录,这个目录存放了一些证书信息,也可以删掉,在下次创建集群时会生成

33 新pod加不进去，总是containercreating

如果存储空间占用超过85%，会影响 Kubernetes 集群的正常运行，并可能会导致 pod 的部署数量受到限制。

当存储空间使用率超过某个阈值时，可能会发生以下情况：

1、Kubernetes 节点上的磁盘空间不足，无法为新的 pod 创建足够的空间。这可能会导致 pod 的调度失败，并且无法在节点上启动。

2、存储卷的容量不足，无法为 pod 提供足够的存储空间。这可能会导致 pod 启动失败，因为它们无法获得所需的存储空间。

3、如果使用的是 Kubernetes 集群级别的存储系统，例如 NFS 或
GlusterFS，存储空间使用率的增加可能会影响集群的性能和可用性。如果存储系统达到其容量极限，可能会导致 pod 在集群中无法正常运行。

因此，建议定期检查 Kubernetes 集群的存储空间使用率，并确保有足够的可用空间来支持 pod 的正常运行。如果存储空间使用率已经超过85%，可以考虑增加存储空间或删除不需要的数据来释放空间，以确保 Kubernetes 集群的正常运行。

32 container里不用gpu的配置方法

env:

• name: NVIDIA VISIBLE DEVICES
  value: none

33 列出imageA相关所有容器

docker ps -a --filter ancestor=imageA

docker ps: 列出容器。
-a: 显示所有容器，包括那些没有运行的容器。
–filter ancestor=imageA: 这会过滤结果，只显示那些基于 imageA 镜像的容器。
该命令会列出所有与 imageA 镜像相关的容器，包括其容器ID、创建时间、状态、名称等信息。

34 查看io 网络带宽，网卡信息

sudo yum install sysstat
iostat -xz 1

sudo yum install iftop
iftop

ethtool eno1
10000Mb/s   四个零代表10000兆比特每秒，10 Gbps

35 Ubuntu20.04关掉或者修改dns

vim /etc/netplan/01-netcfg.yaml
把nameserver注释掉

systemctl restart systemd-resolved
systemctl enable systemd-resolved
 
mv /etc/resolv.conf  /etc/resolv.conf.bak
ln -s /run/systemd/resolve/resolv.conf /etc/

# 重启网络
netplan apply

36 istio 的 bookinfo pod在 init的时候总报crashbackoff

通过查看之前嗝屁的container的日志找到问题

kubectl logs details-v1-79f774bdb9-6m8rq -c istio-init --previous

2023-10-24T06:45:34.460083Z error Command error output: xtables parameter problem: iptables-restore: unable to initialize table ‘nat’

解决之道
缺少内核模块：在某些系统上，特别是那些基于最小化的自定义操作系统的系统，可能缺少必要的内核模块来支持 iptables 中的 NAT 功能。您可能需要手动加载这些模块或更改系统配置以自动加载它们。

通常，您可以使用如下命令查看可用模块：

lsmod | grep iptable

并使用 modprobe 命令来加载缺少的模块，例如：

modprobe iptable_nat

37

在node节点上运行kubectl get node的时候报错error: You must be logged in to the server (Unauthorized)

把行的那台机器上的/etc/kubernetes/admin.conf 里的内容替换掉 $HOME/.kube/config里的内容

查看日志错误error: You must be logged in to the server (the server has asked for the client to provide credentials

这个是我改完高可用后，重启kube-system下的apiserver就好了

无编号 杂

“There were many similar errors. Turn up verbosity to see them.” err=“orphaned pod “84bce63e-cc2d-42a4-ab15-3692270bfa4f” found, but error not a directory occurred when trying to remove the volumes dir” numErrs=2
这个错误表明 Kubernetes 在尝试清理孤立的 Pod 时遇到了问题。具体来说，当它试图删除 Pod 的卷目录时，发生了“错误不是目录（error not a directory）”。

sudo rm -rf /var/lib/kubelet/pods/84bce63e-cc2d-42a4-ab15-3692270bfa4f/volumes/*
# 如果设备忙，先umount
sudo umount -l /var/lib/kubelet/pods/5785ff9e-7e16-4999-9662-5e35160a2385/volumes/kubernetes.io~local-volume/pvc-b2cdb8f2-df0c-42d3-9956-a1cf90e013fe

# 这句可以查看pod名字，也可以cd进去 volumes里面的文件夹cat json文件
kubectl get pods --all-namespaces -o jsonpath='{.items[?(@.metadata.uid=="84bce63e-cc2d-42a4-ab15-3692270bfa4f")].metadata.name}'

Failed to create existing container: /kubepods/burstable/pod1d904848-0384-45cd-9a8b-be523b87c0d3/6be8651561f2bc3d0b7ec3715294bd60d005b9263439bd7a6c204b52deeefca0: failed to identify the read-write layer ID for container “6be8651561f2bc3d0b7ec3715294bd60d005b9263439bd7a6c204b52deeefca0”. - open /var/lib/docker/image/overlay2/layerdb/mounts/6be8651561f2bc3d0b7ec3715294bd60d005b9263439bd7a6c204b52deeefca0/mount-id: no such file or directory
这个错误信息表示在尝试创建一个已存在的容器时遇到了问题。具体来说，Docker 无法识别容器 “6be8651561f2bc3d0b7ec3715294bd60d005b9263439bd7a6c204b52deeefca0” 的读写层 ID。这可能是因为 Docker 的镜像层数据损坏或缺失。

docker rm -f 6be8651561f2bc3d0b7ec3715294bd60d005b9263439bd7a6c204b52deeefca0

“Failed to get system container stats” err=“failed to get cgroup stats for “/system.slice/docker.service”: failed to get container info for “/system.slice/docker.service”: unknown container “/system.slice/docker.service”” containerName=“/system.slice/docker.service”
这个错误信息表示 Kubernetes 在尝试获取与 /system.slice/docker.service 相关的 cgroup 统计信息时遇到了问题。出现此问题可能是由于 cAdvisor（Kubernetes 内置的节点监视组件）在解析 cgroup 时遇到了问题。
如果装k8s之前装好没有装好docker，那么k8s装的docker就是默认的systemd

“exec-opts”: [“native.cgroupdriver=systemd”] 是 Docker 配置文件（通常为
/etc/docker/daemon.json）中的一项设置。它表示将 Docker 的 cgroup 驱动程序设置为
systemd。Cgroup（控制组）是 Linux 内核中的一个功能，用于限制、控制和隔离进程使用的系统资源（如 CPU、内存、磁盘
I/O 等）。

Docker 支持两种 cgroup 驱动程序：cgroupfs 和
systemd。这两种驱动程序之间的主要区别在于它们如何在系统上创建和管理 cgroup。cgroupfs 使用 cgroup
文件系统在系统上直接创建和管理 cgroup，而 systemd 使用系统的 systemd 服务管理 cgroup。

在 Kubernetes 环境中，通常建议将 Docker 的 cgroup 驱动程序设置为 systemd，因为这样可以更好地与
kubelet 配合工作。Kubernetes 使用 systemd 管理 Pod 和容器的资源限制和隔离，因此使用相同的 cgroup
驱动程序可以确保系统的一致性和稳定性。

要将 Docker 的 cgroup 驱动程序设置为 systemd

/etc/docker/daemon.json
加入
{
“exec-opts”: [“native.cgroupdriver=systemd”]
}

Cgroupfs 和 Systemd 都与 Cgroups（控制组）有关，但它们在管理和实现 Cgroups 时有所不同。让我们通过比喻和示例来解释它们之间的区别。

Cgroupfs：Cgroupfs 是一个文件系统，用于通过文件系统操作（如创建目录、读写文件）直接管理和操作 Cgroups。你可以把 Cgroupfs 想象成一家餐厅的自助餐。顾客可以根据自己的需求自由选择和搭配食物。同样，Cgroupfs 允许用户和应用程序直接操作 Cgroups 的层次结构和参数，提供了很高的灵活性。例如，通过 Cgroupfs，你可以创建一个新的目录代表一个新的控制组，然后通过写入任务文件将进程添加到该控制组中。

Systemd：Systemd 是 Linux 系统的初始化系统和服务管理器。它也提供了一种间接管理 Cgroups 的方法。Systemd 将 Cgroups 与服务单位（Unit）结合起来，使得 Cgroups 的管理更加简化和自动化。你可以把 Systemd 中的 Cgroups 管理想象成一家餐厅的套餐服务。顾客只需选择套餐，餐厅就会按照预定的组合提供食物。在这种情况下，Systemd 通过服务单位为用户提供了预先配置好的 Cgroups 设置。例如，你可以创建一个 Systemd 服务单位，定义 CPU 和内存限制，当该服务启动时，Systemd 会自动为其应用相应的 Cgroups 配置。

总之，Cgroupfs 和 Systemd 都可以用来管理 Cgroups，但它们的方法和侧重点不同。Cgroupfs 提供了直接和灵活的 Cgroups 操作，而 Systemd 通过服务单位简化了 Cgroups 的管理和配置。这两种方法可以根据具体需求和场景进行选择。

vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_EXTRA_ARGS=--node-ip=x.x.x.x --hostname-override=node3 --cgroup-driver=systemd"
sudo systemctl daemon-reload
systemctl restart kubelet

38 no space left in device

发现df -i inode, df -h,docker system df 都没问题，修改文件描述符限制，解决问题

ulimit -n
vim /etc/security/limits.conf
#加入
* soft nofile 65535
* hard nofile 65535
# 重启会话发现生效

文件描述符（File Descriptor，简称 FD）是操作系统用于访问文件、目录、套接字等对象的抽象表示。在类 Unix 操作系统（如
Linux）中，文件描述符是一个非负整数，用于在内核和用户空间之间传递文件和其他 I/O
资源的引用。当程序打开、读取、写入或关闭文件时，都会使用文件描述符。

每个运行中的进程都有一个文件描述符表，用于存储当前进程打开的文件和套接字。文件描述符限制是每个进程可以同时打开的文件描述符的最大数量。

以餐馆为比喻，文件描述符就像餐馆中的服务员。当顾客（进程）需要点菜、上菜、买单（打开、读取、写入文件）等操作时，他们会与服务员（文件描述符）进行交互。而文件描述符限制就像是餐馆可以容纳的服务员数量上限。

修改文件描述符限制会影响进程可以同时处理的文件和套接字数量。增加文件描述符限制可以让进程同时处理更多的 I/O 操作，这对于 I/O
密集型应用（如数据库和 Web
服务器）非常有用。然而，如果将限制设置得过高，可能会导致系统资源的过度分配，因为操作系统需要为每个可能的文件描述符分配内存和其他资源。

文件描述符限制不直接影响磁盘空间，但如果达到文件描述符限制，可能会导致程序无法创建新的文件或打开现有的文件。在某些情况下，错误消息可能类似于磁盘空间不足的错误，例如
“no space left on device”。这种情况下，通过增加文件描述符限制可以解决问题。

39 修改openebs默认存储空间，sc local

# 获得name
kubectl get sc
kubectl get sc name -o yaml > openebs-hostpath.yaml
vim openebs-hostpath.yaml 把/var/openebs/local 改成你想要的路径
kubectl delete sc name
kubectl create -f openebs-hostpath.yaml
# 把数据都拷过去
cp -R /var/openebs/local/* /home/openebs/local/

40 minikube

minikube start --vm-driver=none --kubernetes-version=v1.21.5

41 关于内存碎片 重启后解决

内存碎片是计算机内存中未被有效利用的空间，它产生于计算机在运行程序、分配和回收内存的过程中。内存碎片主要有两种类型：外部碎片和内部碎片。为了便于理解，我们可以借用一个仓库的比喻来解释内存碎片的产生过程。

假设计算机内存就像一个仓库，其中的货物（数据和程序）需要存储在不同的货架上（内存分区）。当货物进出仓库时，货架上会出现空位（可用内存空间）。

1、外部碎片：当货物不断进出仓库，货架上的空位可能会分散在各个地方，导致没有足够的连续空间来存储新的货物。这种情况就像仓库里的货架间隙里有很多空位，但没有一个空位足够大，能够放下新的货物。在计算机内存中，这种现象就是外部碎片，它导致内存空间无法被有效利用。
例如，在运行多个程序时，每个程序可能占用不同大小的内存空间。当程序结束运行并释放内存时，这些内存空间可能会变成碎片化的小块。当新的程序需要较大的连续内存空间时，尽管总的可用内存足够，但可能无法找到足够的连续空间，从而导致内存分配失败。

2、内部碎片：有时候，货物不能完全填满货架的空位，剩余的空间就会被浪费。在计算机内存中，这种现象就是内部碎片。它是指已分配给程序的内存空间中，未被实际使用的部分。
例如，假设一个程序需要150字节的内存空间，但是内存管理系统按照200字节的块分配内存。这将导致50字节的内存空间被浪费，形成内部碎片。

内存碎片会降低计算机的性能和内存利用率。为了解决这个问题，可以采用内存整理（内存碎片整理或内存压缩）技术，将分散的空闲内存整合到一起，从而提高内存利用率。

重启后解决的原因
重启计算机相当于清空仓库，重新整理货架，然后重新摆放货物。当计算机重启时，内存中的所有数据和程序都会被清除，操作系统会重新加载。在这个过程中，内存得到重新整理，之前存在的内存碎片也会被清除。因此，在重启之后，内存中的空闲空间会变得连续，提高了内存利用率。

此外，重启还有以下几个方面的好处：

1、关闭悬空进程：有时，程序在运行过程中可能会出现错误，导致无法正常关闭。这些悬空进程会占用系统资源，可能导致内存碎片的产生。重启计算机可以结束这些悬空进程，从而释放占用的资源。

2、清理缓存：操作系统和应用程序在运行过程中会产生临时数据（缓存），用于提高性能。随着时间的推移，这些缓存数据可能会占用大量内存。重启计算机可以清除这些缓存，释放内存空间。

3、修复系统错误：某些系统错误可能导致计算机性能下降，包括内存管理方面的问题。重启计算机可以重置操作系统，修复这些错误。

需要注意的是，虽然重启计算机可以暂时解决内存碎片问题，但它不能完全避免内存碎片的产生。要减少内存碎片，可以定期运行内存整理工具，优化内存分配策略，并升级硬件和软件以提高计算机性能。

42 /var/log/messages

在 CentOS 7.9 系统中，位于 /var/log/ 目录下的 messages 文件通常是由系统日志守护进程（syslogd 或 rsyslogd）产生的。这个文件记录了系统的各种消息和事件，包括系统启动、服务启动、登录、关机、硬件故障等等。

要确认 messages 文件是由哪个进程产生的，您可以使用以下方法：

1. 查看日志文件头部信息：可以通过查看日志文件的开头几行，通常会包含一些标识信息，如日志的生成时间、主机名、日志守护进程的版本等等。这些信息可以帮助您确定是哪个进程产生的日志文件。

   head /var/log/messages
   

2. 查看日志守护进程配置文件：您可以查看日志守护进程的配置文件，了解它是如何配置的，以及它会将哪些日志信息写入到 messages 文件中。

   • 如果使用的是 rsyslogd，配置文件通常位于 /etc/rsyslog.conf 或 /etc/rsyslog.d/ 目录下。
   • 如果使用的是 syslogd，配置文件通常位于 /etc/syslog.conf。

3. 查看进程信息：您可以查看系统中正在运行的日志守护进程的相关信息，了解它们的进程名称、PID 等等。

   ps aux | grep syslog
   

通过以上方法，您应该能够确定 messages 文件是由哪个进程产生的，并了解它的产生原因。

2

可以通过编辑日志守护进程的配置文件，将日志写入目录修改为 /home/admin/log。在 CentOS 中使用的是 rsyslogd，所以下面的说明适用于 rsyslogd。

1. 首先，您需要编辑 rsyslogd 的配置文件，通常是 /etc/rsyslog.conf 或者 /etc/rsyslog.d/*.conf 文件。

2. 在配置文件中，找到将日志写入 /var/log/messages 的相关配置行，通常类似于：

   *.info;mail.none;authpriv.none;cron.none                /var/log/messages
   

3. 将该行修改为您希望的目录路径，例如：

   *.info;mail.none;authpriv.none;cron.none                /home/admin/log/messages
   

4. 保存修改并退出编辑器。

5. 重启 rsyslogd 服务，以使配置生效：

   sudo systemctl restart rsyslog
   

现在，rsyslogd 将会将日志写入到 /home/admin/log/messages 文件中。确保目标目录存在，并且 rsyslogd 进程有权限将日志写入该目录。

43 防止某个程序内存占用过多导致死机

在Rocky Linux 8中，您可以通过修改内核参数来设置最低内存阈值。以下是一种可能的操作方法：

1. 打开终端或SSH连接到服务器。

2. 使用文本编辑器（如vi或nano）打开/etc/sysctl.conf文件。例如，在终端中运行以下命令：

   sudo vi /etc/sysctl.conf
   

3. 在sysctl.conf文件中添加以下行来设置最低内存阈值：

   vm.min_free_kbytes = 10485760
   

   这里的 vm.min_free_kbytes 参数指定了以字节为单位的最低空闲内存阈值。上面的示例值 10485760 字节表示大约10GB的内存。您可以根据需要调整此值。

4. 保存并关闭文件。在vi编辑器中，按下Esc键，然后输入:wq并按下Enter键来保存并退出。

5. 运行以下命令使设置生效：

   sudo sysctl -p
   

   这将重新加载sysctl.conf文件以应用新的参数设置。

现在，您已经成功设置了最低内存阈值。操作系统会尽量保持至少这个阈值的空闲内存，以确保系统正常运行，并减少因内存不足而导致的死机风险。请注意，这只是一种示例方法，在实际操作中，请根据您自己的需求和环境进行调整。

44. 证书问题

其实不是证书过期，更新证书是为了安全问题。而是node节点无法使用kubectl的问题
kubectl 与 apiserver通信用的。
master的admin.conf的内容给node节点的/root/.kube/config就可以了
在某些情况下，admin.conf 可以作为初始配置文件，然后被复制或合并到个别用户的 .kube/config 文件中。

45、nvidia 插件在没有gpu的节点让它不调度上去

明白了，要确保 nvidia-device-plugin-daemonset 不会在没有 GPU 的节点上运行，同时不修改其他节点的标签，可以通过以下步骤实现：

1. 给没有 GPU 的节点添加一个特定的标签。
2. 修改 nvidia-device-plugin-daemonset 的配置，使其不在打了这个标签的节点上运行。

步骤 1：给没有 GPU 的节点添加标签

首先，给没有 GPU 的节点（例如 nodeA）添加一个特定的标签，例如 no-gpu=true。

kubectl label nodes nodeA no-gpu=true

步骤 2：修改 DaemonSet 的配置

修改 nvidia-device-plugin-daemonset 的配置，添加 nodeAffinity，使其避免在打了 no-gpu=true 标签的节点上运行。

1. 获取并编辑 DaemonSet：

   kubectl edit daemonset nvidia-device-plugin-daemonset -n kube-system
   

2. 在编辑器中，添加 nodeAffinity 配置，使 DaemonSet 只在没有 no-gpu=true 标签的节点上调度。

   修改后的配置如下：

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: nvidia-device-plugin-daemonset
     namespace: kube-system
   spec:
     template:
       spec:
         affinity:
           nodeAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: no-gpu
                   operator: NotIn
                   values:
                   - "true"
         tolerations:
           - key: "nvidia.com/gpu"
             operator: "Exists"
   

46、如何把一个pod的副本数先变为0，等需要它的时候再变为1

1. 确认当前 Deployment 状态

首先，确认你的 Deployment 名称和当前副本数。以 Nginx Deployment 为例：

kubectl get deployment nginx

输出示例：

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   3/3     3            3           10m

2. 将副本数缩减为 0

使用 kubectl scale 命令将副本数缩减为 0：

kubectl scale deployment nginx --replicas=0

确认副本数已变为 0：

kubectl get deployment nginx

输出示例：

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   0/0     0            0           10m

3. 需要时将副本数增加到 1

当需要再次启用该 Deployment 时，可以将副本数增加到 1：

kubectl scale deployment nginx --replicas=1

确认副本数已变为 1：

kubectl get deployment nginx

输出示例：

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           10m

47、