前言k8s node 节点 join master 后，状态报错：NOT READY查看 kubelet 日志journalctl -xeu kubelet报错如下：Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:docke...

根据 tag 创建 git分支，git checkout -b 分支名 标签名。启动 grafana，通过。

创建文件，启用持久化存储并指定spec:resources:requests:storage:spec:resources:requests:grafana:size: 8Gi。

如果你经常使用 Docker Compose 来管理多容器应用，一定会遇到这样的场景：在项目目录下直接敲，然后它就“神奇地”找到了你的配置文件。但如果你没指定-f参数，它到底是怎么找到文件的呢？Docker Compose 的配置文件查找规则其实非常人性化：既保留了对老项目的兼容性，又在推动大家向更现代的命名方式迁移。建议所有新项目立即切换到，既符合官方推荐，也能避免未来可能的兼容性困扰。下次运行

在实际运维中，我们经常会遇到不同机器上 Docker 版本不一致的情况，尤其是很多生产服务器还在运行较老的 Docker Engine 版本(如 19.03.x)。方式一：独立二进制版(docker-compose，带连字符)—— 经典的 Compose V1方式二：CLI 插件版(docker compose，无连字符)—— 现代的 Compose V2/V5本文以 Docker 19.03.1

在使用命令停止Nginx容器时，出现报错，常规操作难以解决。

在 Ubuntu 20.04 上的一台曾作为 Kubernetes 节点的服务器，退役后直接用于运行 docker-compose 部署的业务容器。使用自定义桥接网络的容器无法解析外部域名，且无法访问外部网络(ping 外部 IP 100% 丢包)，而使用模式的容器一切正常。

在查看pod运行状态时，发现有的pod的状态是Evicted，通过describe去查看发现了的报错原因是kubelet检测到本地磁盘使用率超过了85%，这是kubelet方法只有两种，要么清理磁盘或者磁盘扩容，要么就是修改 kubelet 的配置。

在使用 Docker Compose 部署微服务架构时，发现部分服务无法通过容器名称解析其他服务，导致服务启动失败并进入重启循环。分层排查：从基础设施(Elasticsearch)到网络层(DNS)逐步排查日志分析：通过容器日志快速定位问题类型网络测试：使用简单的测试容器验证网络连通性配置检查：检查 Docker 守护进程的配置参数。

最近遇到一个很头疼的问题：但奇怪的是：从容器里ping目标域名/IP 是通的，而且延迟也很正常用测试，也卡在 TLS 握手阶段，半天出不来结果乍一看像网络不通，但 ping 又没问题，DNS 也解析正常，简直让人怀疑人生。容器 HTTPS 握手超时 + ping 通 → 十有八九是 MTU 惹的祸尤其是用云主机、自建 K8s、OpenStack、VPN、Overlay 网络的时候，优先检查宿主机