（k8s）部署redis，mysql与tomcat项目，同时干爆了服务器
1.项目环境主节点：2h4g，
从节点：2h2g
2.现在情况
从节点已无响应
https://i-blog.csdnimg.cn/direct/f053565148e94ef689de6bc2f36efb37.png
主节点还可以支撑一会
https://i-blog.csdnimg.cn/direct/48defb9305c6476eb1d51933772f5b5c.png
第一次能把服务器用满，接下来得去检查一些问题，尝试释放一些资源来稳固一下worker节点，这个
https://i-blog.csdnimg.cn/direct/255b5d4078414891b941c6780b1ef8a3.png
3.释放资源
https://i-blog.csdnimg.cn/direct/5341e212f9c24ede81170b80b633d229.png
使用htop下令查看哪些步伐正在运行
我们还可以采用下面这段代码将资源占用排前十的步伐列出来
然后再使用kill -9 pid指令删除它们
ps aux --sort=-%cpu | head -n 10 # 显示 CPU 占用前 10 的进程
ps aux --sort=-%mem | head -n 10 # 显示内存占用前 10 的进程
https://i-blog.csdnimg.cn/direct/4f10f54c96ef492a828c46ec30616fb8.png
对于k8s应用步伐可以使用下面这段代码查看k8s应用是否有正常退出，
sudo crictl ps -a https://i-blog.csdnimg.cn/direct/eab27e2b8519486cb294250991574708.png
如果想要删除可以采用下面的下令，对于runing应用先停止再删除，不外一般不怎么灵验，对于已经exit的容器可以成功删除，但对于正在运行中的应用连停止都会被拒绝。
sudo crictl inspect 33a9e8f75d800 https://i-blog.csdnimg.cn/direct/a19d01feecfa491197eca3588a6477d4.png
这种时候只能根据历程id然后使用kill下令停止了，两种方法
1.inspect，使用它根据容器id来查看容器的详细信息，然后找到pid，直接kill-9！
sudo crictl inspect 33a9e8f75d800 https://i-blog.csdnimg.cn/direct/405caee9c9244611bc655eb74517ebdb.png
如上图所示，pid在这里，
https://i-blog.csdnimg.cn/direct/220cbc9881084f269b1944591506ca10.png
CONTAINER便是我们需要查询的容器id，
2.查看主机上的所有容器历程
ps aux | grep -E 'docker|containerd|kube-proxy|mysql|redis'
清理之后就好多了
https://i-blog.csdnimg.cn/direct/40298e55481f4f59a2b5b2efc815e478.png
3.这几天踩过的坑
1.要留意k8s的镜像仓库和docker deamn的镜像仓库不是一个地方，k8s是访问不到docker本地自己打的包的，需要自己搭建一个docker的私有仓库或者上传到docker hub上去供k8s下载，
更改拉取策略的结果只能是在本地有私有仓库的情况下才能运行起来
为什么呢？
在 Kubernetes 中，默认情况下，它会使用容器运行时（如 containerd、CRI-O 或 Docker）来拉取和运行容器镜像。固然 Kubernetes 本身可以与多个容器运行时（如 Docker）举行交互，但 Kubernetes 与本地 Docker 镜像仓库的通信并不是自动的。这是因为 Kubernetes 的容器运行时和 Docker 之间存在一些不同的工作机制和隔离，下面是原因和解释：
1. Kubernetes 与 Docker 镜像仓库的隔离
Kubernetes 的容器运行时（比方 containerd、CRI-O）与 Docker 是不同的组件，并且它们有自己的镜像存储和管理体系。纵然在你的机器上运行 Docker，Kubernetes 的运行时（如 containerd 或 CRI-O）并不会直接访问 Docker 的镜像存储位置。这是因为 Kubernetes 使用的是符合容器运行时接口（CRI）的容器运行时，而 Docker 本身并不完全实现 CRI。
2. Kubernetes 无法直接访问 Docker 本地镜像
[*] 镜像存储位置不同：Docker 会将镜像存储在本地的 /var/lib/docker 目次下，而 Kubernetes 使用不同的存储目次，如 /var/lib/containerd 或 /var/lib/crio。这意味着 Docker 镜像的存储和 Kubernetes 的镜像存储是隔离的，Kubernetes 运行时无法直接访问 Docker 存储中的镜像。
[*] 容器运行时不同：Kubernetes 的容器运行时管理镜像和容器生命周期。通常情况下，Kubernetes 会使用 containerd、CRI-O 或 Docker（作为 Kubernetes 的运行时，早期版本中）来运行容器。这些容器运行时都独立于 Docker，而 Docker 镜像存储的路径和管理方式与 Kubernetes 使用的容器运行时不兼容。
3. 需要私有仓库的原因
为了让 Kubernetes 可以或许拉取自定义构建的 Docker 镜像，你需要将这些镜像上传到一个 Kubernetes 可以或许访问的镜像仓库。通常有以下几种方式：
[*]Docker Hub：将镜像上传到 Docker Hub，使得 Kubernetes 可以从 Docker Hub 拉取镜像。
[*]私有镜像仓库：如果你有一个私有镜像仓库（如 Harbor、Nexus 或自建的 Docker Registry），你可以配置 Kubernetes 来从这个仓库拉取镜像。
4. 更改拉取策略的结果
Kubernetes 的拉取策略（imagePullPolicy）控制着 Kubernetes 是否以及何时从长途仓库拉取镜像。它有三个值：
[*]IfNotPresent：如果本地已经存在镜像，则不拉取。
[*]Always：每次都拉取镜像。
[*]Never：永远不拉取镜像。
然而，更改拉取策略并不能解决本地 Docker 镜像无法访问的问题，因为纵然设置了正确的拉取策略，Kubernetes 的容器运行时仍然无法访问本地 Docker 仓库。要让 Kubernetes 正常拉取镜像，你必须确保：
[*]镜像已经被上传到 Kubernetes 能访问的镜像仓库。
[*]如果是私有镜像仓库，还需要配置镜像仓库的凭证（通常通过 Kubernetes Secret 举行认证）。
5. 总结
Kubernetes 需要从可以或许访问的镜像仓库拉取镜像，而 Docker 本地仓库并不直接被 Kubernetes 访问。因此，需要：
[*]将镜像上传到 Docker Hub、私有仓库或其他可访问的镜像仓库。
[*]配置 Kubernetes 与私有仓库的毗连（如使用镜像拉取凭证）。
2.apply ***.yaml偶然候不是很好用，如果是大更改还是delete，然后重新create好，不然上一个版本的配置还是会有遗留，（如果是公司项目的话请审慎操纵）
累死 下节继续更新一下近来常用的下令
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]