容器运行的NodeExporter出现异常的 CloseWait
1. 故障背景最近在对家里的 PVE（Proxmox VE）环境做功耗优化。为了省电，我通过 cpupower 命令限制了宿主机的 CPU 频率，并使用了节能模式。同时，为了防止监控组件占用过多资源，之前我已经在 NodeExporter 的 Docker 容器中配置了极低的 CPU 限制。 环境设置： 监控组件： NodeExporter (Docker 容器部署) -> Prometheus -> Grafana 宿主机功耗调整命令：12cpupower frequency-set -g powersavecpupower frequency-set -u 2GHz Docker 限制配置 (docker-compose.yml)：1234deploy: resources: limits: cpus: '0.1' # 限制只使用 0.1 核 2. 问题现象晚上回家查看 Grafana 面板时，发现有三台 VM 的监控数据突然中断了（No Data）。 初步排查： 检查容器状态： 第一反应是 NodeExporter ...
Linux open()调用的理解
原本的问题最近看 OSTEP 的内容， 慢慢看， 搞了一点点代码， 还挺有意思的。一边写一边尝试回答后面的思考问题。 在自己的环境中发现程序会报错 read failed: Bad file descriptor. 2．编写一个打开文件的程序（使用 open()系统调用），然后调用 fork()创建一个新进程。 子进程和父进程都可以访问 open()返回的文件描述符吗？当它我并发（即同时）写入文件时， 会发生什么？ 第一个版本的代码这第一个版本的代码是我提需求 Copilot 写的. 所以我并不理解其中的意思, 解释的也比较粗糙, 我即便提供给他报错的部分, 它还是坚信这个代码没有问题, 子进程可以访问父进程的文件描述符…… 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293...
Harbor 的升级记录
这次更新的目的是, 将原来的 LVM 切换成 btrfs (真香! 存储主要将两个部分迁移到 [[Linux_btrfs|btrfs]] 上。 docker daemon 的工作目录. harbor 的数据 日志和证书. 下载源代码从官方的项目下载这个版本的 offline 安装包.不用 online 的原因是 : online 还需要从 dockerhub 下载镜像, 国内实在一言难尽. https://github.com/goharbor/harbor/releases/tag/v2.9.4 12cd /opt/wget https://github.com/goharbor/harbor/releases/download/v2.9.4/harbor-offline-installer-v2.9.4.tgz 解压1tar zxvf ./harbor-offline-installer-v2.10.2.tgz 复制之前版本的配置文件1cp /opt/harbor-2.10.0/harbor.yml . 确认配置文件中的几个参数已经改为正确的路径, 其他位置不变: ...
GKE 专有集群创建BastionHost连接apiserver的方式
需求一个GKE集群使用了autopilot创建专有集群, 创建完成之后, 怎么在另一个VPC下的实例内使用 kubectl 管理集群.两个实例: instance-20240430-111240: 和 GKE 在相同的VPC内, 可以直接访问控制平面进行集群管理. instance-20240430-053004: 在另一个VPC内, 无法直接访问. 使用 Kubectl Proxy 直接暴露 Apiserver 端口 和GKE相同VPC内启动一个新的实例, 在实例中配置 kubectl 可以正常连接到控制平面. 使用 kubectl 命令创建 proxy 监听在本机的所有地址: 1root@instance-20240430-111240:~ kubectl proxy --address=0.0.0.0 --kubeconfig .kube/config --accept-hosts "^.*" & 在另一个VPC内的节点上, 使用kubectl 命令进行连接: 1root@instance-20240430-053004:~ ku...
Portainer 使用记录
创建并启动 Portainer在这里直接使用了dockercompose直接运行, 这个dockercompose 是自己配置的, 其他的服务可以托管给 portainer , 但是 portainer 自己貌似不太能托管自己. 创建compose文件: touch /opt/portainer/docker-compose.yaml 写入配置文件: 1234567891011121314151617---version: "3.8"services: portainer: image: portainer/portainer-ce:latest restart: always environment: - UUID=0 - GUID=0 - TZ=Asia/Shanghai volumes: - /run/docker.sock:/var/run/docker.sock - /etc/localtime:/etc/localtime:ro - /opt/Porta...
MySQL 无法重连问题的分析
复现方法我的测试环境是完全使用容器的, 还是遇到了一点点小差异. 案例来自一次故障的诊断过程–实验重现 2024年必做实验 的过程, 看看自己差在哪儿. 使用下面的命令运行并进行测试:分离了 server 和 client 在不同的实例上, 开始是放在一起的, 后来为了方便确认范围, 就给分开了. 创建 docker 容器, 运行 MySQL. 1docker run -it -d --net=host -e MYSQL_ROOT_PASSWORD=123 --name=mysql-server regprox.liarlee.site/docker.io/mysql 连接并创建数据库. 1mysql -h127.1 --ssl-mode=DISABLED -utest -p123 -e "create database test" sysbench 12345docker run --net=host --privileged -it regprox.liarlee.site/docker.io/phantooom/plantegg:sys...
AWS-CNI 集成 Calico 并启用 WireGuard 加密
看了下说明， 这个东西的主要作用是用于节点间 Pod 流量的加密。 启动集群略 Helm 命令安装 Calico 添加一个helm repo 1helm repo add projectcalico https://docs.tigera.io/calico/charts 创建一个 value.yaml 1234567cat > values.yaml <<EOFinstallation: kubernetesProvider: EKS registry: reg.liarlee.site/docker.ioEOFhelm show values projectcalico/tigera-operator --version v3.27.2 通过命令安装 12345kubectl create namespace tigera-operatorhelm install calico projectcalico/tigera-operator --version v3.27.2 -f values.yaml --namespace tigera-op...
使用 nsenter 从Kubernetes Node 进入容器网络 Namespace
记录一下使用 nsenter 进入容器的 network namespace 中抓包。在 TroubleShooting 的过程中可能是需要这个方法的。 进入容器ns的步骤 选中一个pod 1default haydenarch-68865d5b56-cblc6 ● 1/1 Running 0 172.31.48.162 ip-172-31-53-61.cn-north-1.compute.internal 在节点上找到这个pod的容器id ： 02182f3e9137 12[root@ip-172-31-53-61 ~]$ nerdctl ps| grep archlinux 02182f3e9137 1234567.dkr.ecr.cn-north-1.amazonaws.com.cn/archlinux:latest "sleep infinity" 23 hours ago Up ...
源地址检查造成丢包的分析
问题网络访问路径：Client –> NLB –> Application Pod 特别的部分：NLB 开启了保留源地址就意味着 NLB 在转发网络流量的时候不会改变数据包五元组内的SourceIP， 这时候对于后端的Pod和节点来说， 收到的数据包的ip地址来源直接是Client 的IP 地址， 这会导致所有的流量其实都是来自于VPC之外的。 NLB在这其中变成了一个透明代理。从 NLB 发到后端application pod 中的流量会有偶尔timeout的情况， 并不是所有的请求都会timeout ，从客户端抓包显示tcp握手的时候就没有成功， 第一个syn包出去就一直没有回复，然后继续重发等待。 由于后端的pod比较多， 并且nlb在四层做了负载均衡，很难定位到某次的请求具体到了哪个后端pod上面。 写下这些的时候我已经知道了问题的答案是由于 VPC CNI 的一个 env ， AWS_VPC_K8S_CNI_EXTERNALSNAT 会指定是否做 SNAT， 比较早的版本， cni 插件没有对 SNAT 在iptables上面进行标记和处理， 这样会导...
安装 headscale 建立自己的 Tailnet
Tailscale 虽然是 mesh 的网络模式, 可以点对点的连接所有设备, 能直连会尽量直接连接, 然鹅还是需要一个默认的 server 来进行服务发现和临时中转流量. 那么大概的配置框架就已经出现了, 一个服务发现中心, 和多个不同的客户端.开始的时候直接使用的 tailscale + github 账户登录的方式使用, 然后发现 github 账户直接托管的中心服务不能关闭国外的中转服务器, 这就比较难受, 本来可以直通的线路走了国外的中转不稳定, 会断, 最后还是走国内的便宜云服务器自己维护了一个开源的 headscale 作为中心服务. 安装 Headscaleheadscale 官方文档现在的 headscale 容器镜像的是有问题的， 不太好用， 还得花时间修。 Update: 看起来现在是修复了, 并且费点儿劲可以用起来, 但是不确定稳定性如何. 我准备了这些: 域名 和 域名证书 一台 Debian 的云服务器 公网 ip 地址 具体的安装步骤就是按照官方网站走下来就可以了.一些条件:需要注意的地方就是备案, 不备案会导致无法使用 443.那么...