高并发下报错 "java.net.UnknownHostException" 案例分析
流量走向
错误日志
Client 报错
应用的报错日志为:java.net.UnknownHostException:
代理服务报错
Client 报错
应用的报错日志为:java.net.UnknownHostException:
代理服务报错
本文目录:
顾名思义:负责将 Pod 调度到 Node 上。
架构
上篇,我们 从0开始装一套 KubeVirt 1.2.1
单点登录失败,但是其他接口正常
问题要点是:单点登录失败,看代码是 request 和 response 的 RedirectUri 不一样导致的。
目前的南北流量架构为:
上篇 “深入了解 kube-scheduler” ,已经知道 kube-scheduler 的工作流程,以及如何实现自定义插件。koordinator 和 crane 都是基于Scheduler Framework 进行实现的 负载感知插件。本文不再赘述,感兴趣可以看上篇文章。
原生 Kubernetes 调度器仅基于资源的 Request 进行调度,在生产环境资源的真实使用率和申请率往往相差巨大,造成资源浪费的同时也会造成节点的负载不均衡。
上次发文 K8s 无备份,不运维,文章开篇,插入了一张 K8s 集群巡检的图片,好多小伙伴私信留言,问我要开源地址。由于其通用性不高,大多数公司需要结合自身的架构情况进行不同的巡检,所以我没有开源。
今天发现有小伙伴还在群里讨论,有没有类似的工具/平台,虽然没有开源,我把其关键的 巡检指标 和 后端核心伪代码 分享出来,供各位同行参考。
受内核调度控制周期(cfs_period)影响,容器的 CPU 利用率往往具有一定的欺骗性,下图展示了某容器一段时间的 CPU 使用情况(单位为0.01核),可以看到在 1s 级别的粒度下(图中紫色折线),容器的 CPU 用量较为稳定,平均在 2.5 核左右。根据经验,管理员会将 CPU Limit设置为 4 核。本以为这已经保留了充足的弹性空间,然而若我们将观察粒度放大到 100ms 级别(图中绿色折线),容器的 CPU 用量呈现出了严重的毛刺现象,峰值达到 4 核以上。此时容器会产生频繁的 CPU Throttle,进而导致应用性能下降、RT 抖动,但我们从常用的 CPU 利用率指标中竟然完全无法发现!
从一个 SRE 角度看, Pod 驱逐分为两种情况: