问题通过 docker images 命令查询本地镜像列表,有可能看到 repository 和 tag 均为 none 的镜像，这种镜像在 Docker 官方文档中被称作 dangling images 。 原因根据官方解释，该镜像的产生是由于通过 docker build -t [image_name:image_version] . -f dockerfile 构造新镜像时， [image_name:image_version] 与本地已有镜像重名导致的。新生成镜像的 名称+版本号 与本地原有镜像相同时， docker 引擎会自动将名称和版本号分配给新镜像，则原来的镜像会变成 none:none 形式。 解决方法方法一官方给出，执行命令 docker image prune 来清理，如果镜像被容器使用则报错。 docker image prune [OPTIONS] <选项>--all , -a Remove all unused images, not just dangling ones -----删除所有未使用的映像，而不仅仅是悬空映像--filter Pr ...

# hexo new post <title># -p 参数可以指定文章的路径hexo new post -p hello/hello-world # 注意里面的title为post# 此时里面的title为hello-world# hexo new post title -p dir/filenamehexo new post hello-world -p hello/hello-world## 当然了手动将文章放到指定的文件夹中也可以

Keepalived + Nginx 实现高可用原理如果杀掉 MASTER（主）节点的 nginx如果nginx进程不存在脚本返回1，nginx进程存在脚本返回0 脚本返回0，表示nginx进程存在，由于上面配置的weight为负数，priority 不会改变。 脚本返回1，表示nginx进程不存在，由于上面配置的weight为负数，priority 会减少，减少后的值 priority = priority+weight失败一次，将自己的优先级-20，我这里MASTER的priority=100，BACKUP的priority=99那么MASTER要失败1次后变为80，低于BACKUP的99，MASTER节点会降级为BACKUP，而BACKUP节点升级为MASTER #!/bin/bash# keepalived会定时执行脚本并对脚本执行的结果进行分析,动态调整vrrp_instance的优先级。# 如果脚本执行结果为0,并且weight配置的值大于0,则优先级相应的增加。# 如果脚本执行结果非0,并且weight配置的值小于 0,则优先级相应的减少。# ...

title: Nginx 1.26 编译安装与高级配置 nginx编译安装下载源码包 wget http://nginx.org/download/nginx-1.24.0.tar.gz 下载依赖包 yum install gcc pcre-devel zlib-devel openssl-devel -y 创建一个不可以远程登录的没有家目录的用户 useradd -s /sbin/nologin -M nginx 解压安装包 tar zxf nginx-1.24.0.tar.gz 关闭debug cd nginx-1.24.0/vim auto/cc/gcc 编译安装的程序 ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_stub_status_module --with-http_gzip_static_module - ...

激活常用软件的激活配置 goland 激活链接: https://pan.baidu.com/s/1trj3tmMbnyFpK3Y0_KxzoA 提取码: rpie pycharm 激活链接: https://pan.baidu.com/s/1trj3tmMbnyFpK3Y0_KxzoA 提取码: rpie

查看kubernetes的proxy模式 看到当前运行的kube-proxy pod ~ # kubectl get pods -n kube-system | grep proxy root@k8s-master01kube-proxy-9ssmd 1/1 Running 0 16mkube-proxy-prs8j 1/1 Running 0 16mkube-proxy-tp9vf 1/1 Running 0 16mkube-proxy-x8xtr 1/1 ...

这个问题其实是在考察对 k8s service 的使用和底层原理的理解。。。 实验环境搭建使用 kind (k8s.io) 可以很方便的在本地搭建实验环境，修改配置即可创建 kubeProxyMode 为 iptables 或 ipvs。 实验涉及的 config 和 yaml 可以在我的 github repo 找到： win5do/k8s-svc-test (github.com) 网络调试工具可以通过创建 netshoot 容器 attach 到目标 network namespace：nicolaka/netshoot: a Docker + Kubernetes network trouble-shooting swiss-army container (github.com) ClusterIP/NodePort这类 svc 都会分配 ClusterIP，这个 IP 地址是 VIP（虚拟 IP），是在所有 node 上添加一些 netfilter 规则，主要有 iptables 和 ipvs 两种方案，能不能 ping 通要看具体实现。 ...

场景在k8s+containerd的环境上删除容器失败，容器一直保持在terminating状态。 containerd日志显示”failed to check network namespace closed: remove netns：unlinkat *: device or resource busy” ，不影响新创建的容器运行。 ip netns list 报错 Invalid argument 寻找解决办法百度搜索出来mount信息显示netns还是被mount的，但是umount时又显示not mount查看代码，测试验证都无效果。真的坑！根因其实时 ip netns add命令搞的鬼，和这个命令的行为有关，之前执行过这个命令导致containerd创建的netns不可见。解决办法其实只有umount下/run/netns就好了。 能解决就不会单独写一篇文章了，还是Google搜索引擎强大！ echo 1 > /proc/sys/fs/may_detach_mounts 注：在CentOS7.4引入了一个新的参数来控制内核的行为。 ...

刚接手一个测试集群，一个平台项目测试，部署到该k8s集群上。部署上去之后就发现各种坑，所以在这里总结一下遇到的问题，及排查思路。。。 基础环境kubernetes：1.16.xcni：calico + BGPuname：3.10.xxx 遇到的坑 跨节点 pod 之间某些可以ping通，某些不能ping通 不能ping通的pod都是在别的主机上 同一个 主机上的pod，有的可以ping通，有的不能ping通 dns svc 的ip 53 端口，不能telnet通。 某些 pod 无法解析svc地址。 使用 busybox 容器，无法解析所有的svc地址。 busybox容器ping命令可以解析出svc IP地址。 故障结论pod内部或者说是集群内部无法解析service ip，不能通过service ip或者service name通信访问 故障分析一般宿主机网络有限制，kube-proxy、calico问题。 故障排查主机网络排查排查防火墙，selinux是否关闭 systemctl status firewalldgetenforce 修改内核参数 net.ip ...

Kubernetes集群内置DNS插件CoreDNS，为集群内的工作负载提供域名解析服务。业务在高并发调用场景下，如果使用到域名解析服务，可能会触及到CoreDNS的性能瓶颈，导致DNS请求概率失败，影响用户业务正常运行。在Kubernetes使用的过程中，发现有些场景下工作负载的域名解析存在冗余的DNS查询，使得高并发场景更容易触及DNS的性能瓶颈。根据业务使用场景，对工作负载的DNS配置进行优化，能够在一定程度上减少DNS请求概率失败的问题。 POD DNS 配置项说明在容器里执行cat /etc/resolv.conf命令，能够查看到DNS配置，以Kubernetes集群的容器DNS配置为例： nameserver 10.247.x.xsearch default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5 配置项说明： nameserver：容器解析域名时查询的DNS服务器的IP地址列表。如果设置为10.247.x.x说明DNS对接到Kube-DNS/CoreDNS，如果是 ...