方法1：dial 使用 net.DialTimeout 去检查端口的技巧： 在通过Dial检查端口占用时，需要知道网络中常见的报错状态，而不是 err != nil 都为可用 Connection reset by peer connection reset by peer 这种错误情况下有以下几种场景： 基于包过滤的防火墙给予 RST；对于此情况，基于网络模型来说处于网络层与传输层之间的netfilter，如果是防火墙拒绝那么未到应用层无法确认端口 对端应用资源限制而reset，通常为负载过高；对于此场景是已到达应用层 客户端关闭了连接，而服务器还在给客户端发送数据；对于端口检查来说不会到这步 由上面可知，这种错误一定为占用 Connection timed out Connection timed out 这种场景根本就dial不成功，go中给出了一个专门的事件 opErr.Timeout() 来说明这个错误，故此错误将不能确认端口是否占用 Connection refused Connection refused 这种场景催在两种情况 对于 local 场景来说，这将表示端口未监听 对于远端场景来说，这种基本上表示 client 发往 remote ，remote不能接受 host:port 这个连接 通常对于存在两种情况，但多数为端口为监听 Misconfiguration, such as where a user has mistyped the port number, or is using stale information about what port the service they require is running on....

haproxy1 VS haproxy2 haproxy2由 2019-06-16 被发布，对于与haproxy1版本来说，haproxy 2.0 增加了对云原生的支持，这使得haproxy 2.0 更适用于云原生环境，对比于 haproxy1.0 在2001年发布来，到 1.9.16 在 2020/07/31 最后一次更新也代表haproxy1.0的结束维护 为什么选择haproxy2.0 haproxy2.0的核心功能就是集成了云原生架构的支持。包含L7重试, Prometheus metrics, 流量镜像 (traffic shadowing), 多语言可扩展性, gRPC 。haproxy2.0 还增加 基于haproxy2.0 的 Kubernetes Ingress Controller 和强大的 HAProxy Data Plane API，这提供了用于配置和管理 HAProxy 的 REST API 安装haproxy2.0 对于 Ubuntu/Debian 来说，社区版haproxy提供了更友好的安装方式，用户直接添加对应仓库可以直接安装最新版本的haproxy Debian/Ubuntu HAProxy packages 对于 CentOS/Fedora 来说，只有Fedora 仓库提供了较为新版的haproxy，通常来在这类平台的Linux都是通过编译安装haproxy 下载haproxy2.6源码 [ haproxy下载 ] 安装依赖包 bash 1 yum install gcc pcre-devel openssl-devel tar make -y 编译程序 bash 1 2 3 4 5 6 7 8 9 tar xf haproxy-2....

工具命令集合 长期总结 - Linux日志查询命令 长期总结 - Linux网络命令合集 长期总结 - Linux性能分析命令 awk常用案例 bash shell常用示例 探索kubectl - 巧用jsonpath提取有用数据 探索kubectl - kubectl诊断命令集合 perf [1] perf 是基于内核子系统的Linux的性能计数器，也被称为 perf_events，它提供了为所有事件进行性能分析的框架，perf 由两部分组成： 内核系统调用，用于提供对这些性能数据的访问 用户空间工具，用于提供收集，显示分析这些性能数据的用户空间程序 由于 perf 是内核的一部分，但要想使用 perf 还需要安装另外一部分，通常情况下安装的版本是Linux内核版本，如操作系统内核版本为 5.10 那么安装 linux-tool 后则为 5.10 bash 1 2 3 4 $ apt-get install linux-perf $ perf --version perf version 5.10.149 各系统下的包名与安装 Ubuntu/Debian: linux-perf | linux-tools ；apt-get install linux-perf CentOS/Fedora: perf ；yum install -y perf list - 列出可用事件描述符 使用 perf 子命令 list 可以列出所有的 perf 可测量事件...

搜索linux 内核 image bash 1 apt-cache search linux-image 然后安装对应image bash 1 sudo apt install linux-image-<flavour> 安装完成后可以看到对应的image bash 1 2 3 4 $ dpkg -l|grep linux-image ri linux-image-5.10.0-16-amd64 5.10.127-2 amd64 Linux 5.10 for 64-bit PCs (signed) ii linux-image-5.10.0-16-amd64-dbg 5.10.127-2 amd64 Debug symbols for linux-image-5.10.0-16-amd64 ii linux-image-amd64 5.10.127-2 amd64 Linux for 64-bit PCs (meta-package) 可以通过命令查看拥有的内核启动项 bash 1 grep -e "menuentry " -e submenu -e linux /boot/grub/grub.cfg 需要修改至新内核可以修改 /etc/default/grub 下的 GRUB_DEFAULT= 这里要填的值为上面命令查询出的，例如 menuentry 'Debian GNU/Linux, with Linux 5....

服务质量 Quality of Service (QoS)，在Kubernetes是用于解决资源抢占，延迟等方向的一种技术，是服务于调度与抢占之间的条件。 QoS 级别 QoS 与 资源限制紧密相关，正如下属展示，是一个Pod资源限制部分的配置 yaml 1 2 3 4 5 6 7 resources: limits: cpu: 200m memory: 1G requests: cpu: 500m memory: 1G 而Kubernetes 将Pod QoS 根据 CPU 与 内存的配置，将QoS分为三个等级： Guaranteed：确保的，只设置 limits 或者 requests 与 limits 为相同时则为该等级 Burstable：可突发的，只设置 requests 或 requests 低于 limits 的场景 Best-effort： 默认值，如果不设置则为这个等级 为什么要关心Pod QoS级别 在Kubernetes中，将资源分为两类：可压缩性资源 “CPU”，不可压缩性资源 “内存”。当可压缩性资源用尽时，不会被终止与驱逐，而不可压缩性资源用尽时，即Pod内存不足，此时会被OOMKiller杀掉，也就是被驱逐等操作，而了解Pod 的QoS级别可以有效避免关键Pod被驱逐。 图：Pod QoS分类 Source：https://doc.kaas.thalesdigital.io/docs/BestPractices/QOS 有上图可知，BestEffort 级别的 Pod 能够使用节点上所有资源，浙江导致其他 Pod 出现资源问题。所以这类 Pod 优先级最低，如果系统没有内存，将首先被杀死。 Pod是如何被驱逐的 当节点的计算资源不足时，kubelet 会发起驱逐，这个操作是为了避免系统OOM事件，而QoS的等级决定了驱逐的优先级，没有限制资源的 BestEffort 类型的Pod最先被驱逐，接下来资源使用率低于 Requests 的 Guaranteed 与 Burstable 将不会被其他Pod的资源使用量而驱逐，其次对于此类Pod而言，如果Pod使用了比配置（Requests）更多的资源时，会根据这两个级别Pod的优先级进行驱逐。 BestEffort 与 **Burstable **将按照先优先级，后资源使用率顺序进行驱逐...