zhangguanzhang's Blog

zhangguanzhang's Blog

站在巨人的肩膀上

鲲鹏920的麒麟v10物理服务器断电后无法启动处理
前情提要珠海园区升压前置检查,上周六整个园区关电检查,然后今天来后连不上我们在 鲲鹏920的麒麟v10机器上开的虚拟机了,进 bmc 的 web 看了下是开机进入后卡住。 信息同步是当初安装系统的同事去处理这个事情的,他 bmc 的 web 上去重启在菜单那里按 e 编辑准备改 boot cmdline 进单用户,结果按 e 后要输入用户名和密码,询问了麒麟他们。很久也没给答复。然后就在那干等,上面的虚机有我的环境,我就过去看了下。 尝试的处理麒麟那边的人员没有回复,我打算这边同步尝试下其他手段,而且不只一台无法开机,哪怕麒麟的回复了密码也能同步尝试不同手段。Linux 无法开机的就搞个...
dlv命令行的远程调试 golang 进程步骤(包含容器进程)
前情提要记录下 dlv 的远程调试,建议不要在代码里加 fmt 去调试。不谈 goland 啥的远程调试,本文章目前只写 dlv 的命令行配合远端调试。 一些前提须知符号链接路径1234567891011package mainimport ( "fmt" "os")func main() { f, _ := os.Open("asdasdasd") fmt.Println(f.Name())} 上面代码你编译了后,在其他机器上运行,panic 的堆栈信息会是你机器上的路径信息,路径信息是保留的,例如下面的...
编译mips64le架构的consul
编译建议使用容器编译,否则建议 clone 进 GOPATH 里 clone12git clone https://github.com/hashicorp/consul.gitcd consul 线上使用的是 v1.8 版本,这里我以 v1.8.14 (2021/07/19 发布的)搞的。 1git checkout v1.8.14 准备工作拉取需要的镜像。貌似 golang 1.16 更好的支持 mips64 了,所以条件允许的话,这里可以下改下 golang 的版本试试 1234$ head -n2 build-support/docker/Build-G...
机器重启后 kube-apiserver 无法启动,etcd刷(error "EOF", ServerName "")
环境信息三个 master (etcd 也在 master 上,master上也有 kubelet)和 n 个 node。master 上组件(kube-controller-manager,kube-scheduler,kubelet)的 apiserver 的ip 都是 127.0.0.1:6443。kube-apiserver的 etcd 地址写了三个 etcd 的。k8s 版本为 v1.15.5 故障现象93 这台 master 机器重启后,发现 93 节点 NotReady,上去看了下 kubelet 无法连上本机的 kube-apiserver。kube-apiserver ...
Job for docker.service canceled
故障现象内部安装 docker 的脚本报错 docker 安装失败。然后启动发现下面奇怪的问题: 1234567$ systemctl status docker● docker.service - Docker Application Container Engine Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: http://docs.docker.io$ systemctl start...
openshift 4.5.9 etcd损坏+脑裂修复过程
前言介绍内部机器和环境都是在 vcenter 里,之前的 ocp 集群是 3 master + 1 worker,也就是之前的openshift 4.5.9 离线安装后的环境,后面有几台宿主机负载太高,同事看我机器负载最高,关了几台,这几天需要用下 openshift 环境。登录到 bastion 上 get 超时,看了下 haproxy 的 stat web,全部红了。。然后把所有机器开机后发现还是起不来。 操作openshift 的 master 节点和 kubeadm 很像,几个组件都是 staticPod 形式起的。客户端也不是 docker,使用 crictl 就行了 查看 k...
docker-ce 18.09.3 启动panic: invalid freelist page: 56, page type is leaf的解决处理
这个问题和之前的docker-18.06.3-ce启动panic: invalid page type: 0: 0的解决处理差不多,不过 db 文件不同。客户停止 docker 后起不来了,查看日志: 1journalctl -xe -u docker 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879805月 26 18:42:17 xxx...
一次单节点单个pod网络问题排查过程
about现场反馈客户环境上业务不正常,根据调用链去看某个业务A日志,发现无法请求另一个业务B,把业务 A 的探针取消了,加上 12tty: truecommand: ["bash"] 起来后进去 curl 了下 B 对应的 svcIP 接口是能通的。然后手动起业务进程,再开个窗口 exec 进去 curl 发现就不通了,k8s node数量是只有一个,并且只有这一个 pod 有问题。后面排查到是用户的安全软件导致的。软件名是 1234567$ ps aux | grep agentroot 6349 0.3 0.1 21046316 116820 ?...
kubelet 和 runc 编译关闭 kmem
前提详情在 3.x 的内核上,cgroup 的 kmem account 特性有内存泄露问题。kubelet 和 runc 都需要修复。 网上有言论说升级 Linux 内核至 kernel-3.10.0-1075.el7 及以上就可以修复这个问题,详细可见 slab leak causing a crash when using kmem control group。但是我测试了下面的都不行: CentOS7.4 CentOS7.6 CentOS7.7的 3.10.0-1062.el7.x86_64 CentOS Linux release 7.8.2003 (Core) - 3.1...
iptables --wait -t nat -A DOCKER...: iptables NO chain/target/match by that name
由来我们内部有套部署的工具, 我们部署的流程是先在部署机器(部署机器可能也是node1 )上用脚本安装好 docker,然后进容器里去起我们部署平台,有个很久的 bug 就是,部署机器上端口映射起容器会有如下报错 1iptables --wait -t nat -A DOCKER -p tcp -d 0/8 --dport 8089 -j DNAT --to-destination 172.25.0.2:80 ! -i docker0: iptables NO chain/target/match by that name 排查也很简单,缺少链,添加上即可: 123sudo iptab...
Internal error occurred: jsonpatch add operation does not apply: doc is missing path: xxx
由来今天在折腾 admission webhook 注入一些属性的时候遇到了 Error from server (InternalError): error when creating "xxx.yml": Internal error occurred: jsonpatch add operation does not apply: doc is missing path: "/spec/template/spec/dnsConfig/options"。折腾半天才发现在代码里使用 jsonPatch 的话不能直接绕过结构体实例去 patch。 ...
使用github action 配合 docker buildx 编译 arm64 docker-compose
说明git 上搜索了很多 docker-compose 的 arm64 的编译基本都是使用 qemu-user-static 之类的设置下后编译的,也看到过用特权容器启动 qemu-user-static 或者 binfmt 之类的,但是我自己机器上试了无效,貌似是因为我操作系统是低版本内核的 centos ,github 上搜了下,其他很多人的编译感觉太啰嗦了。就在 action 上整了下,测试是可用的,而且非常简单。 docker-practice/actions-setup-docker@master 将会在在 action 的 runner 里安装 docker,创建 build...
集群节点关机导致dns在eviction pod之前几率不可用
由来这几天我们内部在做新项目的容灾测试,业务都是在 K8S 上的。容灾里就是随便选节点 shutdown -h now。关机后同事便发现了(页面有错误,最终问题是)集群内 DNS 解析会有几率无法解析(导致的)。 根据 SVC 的流程,node 关机后,由于 kubelet 没有 update 自己。node 和 pod 在 apiserver get 的时候显示还是正常的。在 kube-controller-manager 的 --node-monitor-grace-period 时间后再过 --pod-eviction-timeout 时间开始 eviction pod,大概流程是...