CDN 的Fetch行为经常在一些场景行为会非常迷惑，本文记录了最近碰到的两起因为对Fetch行为不太理解，而导致的配置异常
先说下链路架构
graph TD A[用户] --> B[DNS 阿里云] B --> C[CDN 腾讯云] C --> D[AWS源站Nginx] D --> E[EKS Svc] E --> F[Pod]
整个环境较为复杂，其中一些细节的地方未展开，比如SVC到Pod 还会经过 istio 的sidecar，本文主要聚焦在CDN与Ng层
aws 从kubernetes 1.33 开始将不再提供 AL2的节点镜像，如果要使用 1.33 必须要升级操作系统镜像到 AL2023，但很多用户发现升级到1.33 & AL2023 后，以前跑的好好的 java 程序，经常会出现 OOM ，本文将详细分析其原因，以及解决方法/原理
spot 实例价格虽然相比于正常的便宜一倍之多，但是也会面临随时中断的情况，而新Pod从机器启动到进入ready，往往又要数分钟。即使对业务进行了针对性改造，适应随时Pod替换的场景，也无法百分百确保不会有影响，但Spot从收到中断信号，会留2分钟的时间给用户处理资源回收，目前主流的是依赖 karpenter 进行管理，如申请机器，处理中断等，但karpenter处理 spot 中断也是很干脆的直接驱逐所有Pod，难免影响可用率，那我们在这两分钟能不能在做点什么？ —–注意：本文只是初步代码验证，笔者尚未在生产环境中使用
还记得第一次见到雪山是19年走318去稻城亚丁，途径四姑娘山镇的是眺望了一眼幺妹峰，当时还被云层厚厚的遮住，但也被其雄伟的身姿独特的形态所震撼，后续又进入稻城亚丁，看到了仙乃日等雪山，还尝试了第一次高原徒步（稻城亚丁长线，来回大致10公里，海拔上升1000米左右），瞬间觉得以前去过的景点都白去了，近距离接触雪山的压迫感，久久不能忘怀，回程的时候再次途径四姑娘山镇（这次四姑娘山四座山峰全部被云层遮住），碰到了很多攀登大二峰提前下撤的背包客，第一次意识到雪山攀登这项运动，也不是那么遥不可及，心里也种下了一颗种子
