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

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

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

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-daemonsetskubectl 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 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-

部署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 统计功能

查看/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/

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

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

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 $filecd ${path}${file}if [ ! -d "./merged" ];thenecho `pwd`fi
done

11、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

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

如果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

镜像丢失

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

ks-apiserver CrashLoopBackOff

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

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

节点NotReady

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

systemctl status kubelet
kubectl describe node NodeName

docker 自动删除镜像

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

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配置可能会对性能和存储需求产生影响，因此需要仔细评估并测试配置变更的影响。

新pod加不进去，总是containercreating

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

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

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

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

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

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

杂

“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

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”。这种情况下，通过增加文件描述符限制可以解决问题。

修改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/

minikube

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

关于内存碎片 重启后解决

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

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

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

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

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

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

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

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

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

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

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

kubesphere 问题解决相关推荐

1. ultimate grid_Ultimate Kubernetes资源规划指南

   ultimate grid Understanding allocatable CPU/memory on Kubernetes nodes and optimizing resource usage ...

2. 在 Linux 上以 All-in-One 模式安装 KubeSphere

   前言 最近部门内需要进行私有化部署,所以这个系列主要是以docker+Kubernetes 技术选型和的调研为主了. 很久没有更新博客,这里把自己的随笔记录到博客中,后续再进行详细整理吧 一.在 Li ...

3. 在 KubeSphere 中监控集群外部 Etcd

   作者:张延英(老Z),电信系统集成公司山东分公司运维架构师,云原生爱好者,目前专注于云原生运维. 1. 本文简介 本文源于 KubeSphere 开源社区 8 群里的一个小伙伴 @Jam 提到的 Ec ...

4. undefined reference to 'pthread_create'问题解决(转)

   undefined reference to 'pthread_create' undefined reference to 'pthread_join' 问题原因:     pthread 库不是 ...

5. mysql 4.0.27 下载,CentOS编译Mysql 4.0.27数据库问题解决

   CentOS编译Mysql 4.0.27数据库问题解决以下文字资料是由(历史新知网www.lishixinzhi.com)小编为大家搜集整理后发布的内容,让我们赶快一起来看一下吧! 现在好多人都用起了 ...

6. oracle实例没有连到监听上6,oracle LISTENER未监听到oracle实例问题解决

   oracle LISTENER未监听到oracle实例问题解决 LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = ...

7. linux+bin+写入引导区,CentOS 6.4 U盘启动盘制作、安装及遇到的问题解决

   用UltraISO Premium Edition  9.3 制作的CentOS 6.4 U盘安装盘, 安装时提示Press the key to begin the installation pro ...

8. Oracle不能在本地计算机启动,Windows 不能在本地计算机启动 OracleDBConsoleorcl的问题解决方法...

   解决步骤如下: 1.开始->运行cmd 2.执行 emctl start dbconsole 输入:C:\Documents and Settings\xcl>emctl start db ...

9. 【python】 OSError:sift not found 问题解决

   [python] OSError: XXXX.sift not found 问题解决 在python环境下通过sift描述子对图像进行特征匹配时出现错误(心累):mpire.sift not foun ...

最新文章

1. [LeetCode] Combinations
2. [网络开发]服务器开发
3. BGP——BGP优化技术（总结+配置）
4. Node.js与网络：Node.js对TCP、UDP、Socket、HTTP等协议的实现和支持
5. mysql 安装 权限_MySQL的安装、使用及权限管理
6. php多级控制,thinkphp5多级控制器是什么？怎么使用？
7. ospf学习笔记-7种状态
8. springboot(五) 加载配置文件优先级顺序
9. java怎么测试接口测试_java怎么测试接口
10. 计算机审计学心得思考,计算机审计学习心得体会范文
11. 微信小程序长按识别二维码
12. 基于XMPP协议的Android即时通信系（http://blog.csdn.net/lnb333666/article/details/7471292）...
13. 第三方CNAS验收评测的重要意义
14. Excel：文本型日期转化为数值型日期
15. 产品经理必须要懂的十种亚文化
16. 安卓手机重启日志_[手机维修自学教程]苹果安卓 手机无线重启故障原因维修技巧...
17. 信道编码：分组码和卷积码
18. 重装系统后磁盘分区不显示该怎么办？教你这样解决方法
19. 解除计算机屏保密码设置密码,屏保密码怎么取消
20. Linux 基金会发布《开源软件供应链安全报告》

热门文章

1. 免费P2P穿透通信(6) P2P穿透模块使用注意事项
2. 父类转换成子类， 或者是类之间属性拷贝
3. Linux 内核顶层 Makefile 详解
4. 价值网络和策略网络的简单融合
5. 世界500强和行业龙头企业再聚上海，第三届进博会亮点抢先看！
6. 软考-进度网络图计算知识点(二)
7. 论文排版神器——Texlive + TexStudio
8. java开源博客系统solo_Solo Java 开源博客
9. mysql计算时间差（时/分/秒）函数
10. 迈克尔逊干涉计算光强matlab,迈克尔逊干涉仪的MATLAB仿真