四姑娘山第八届登山大会传统攀登
25年6月的时候刷到拓路者一条推送:四姑娘山第八届登山大会报名通道开启,想着2月份在萨武留下的遗憾,这次有机会可以弥补了,看了下日期在10.25 ,恰好周末,和媳妇商量了下,便直接缴费报名了,价格比商团便宜了些,1899,有参赛包,但不含来回成都的大交通,但参赛包的价值已经有五六百了,整体打平,大会分为:传统攀登组/速攀组,本次报名的事传统组,速攀挑战太大了,还需要再沉淀下心肺能力

25年6月的时候刷到拓路者一条推送:四姑娘山第八届登山大会报名通道开启,想着2月份在萨武留下的遗憾,这次有机会可以弥补了,看了下日期在10.25 ,恰好周末,和媳妇商量了下,便直接缴费报名了,价格比商团便宜了些,1899,有参赛包,但不含来回成都的大交通,但参赛包的价值已经有五六百了,整体打平,大会分为:传统攀登组/速攀组,本次报名的事传统组,速攀挑战太大了,还需要再沉淀下心肺能力

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米左右),瞬间觉得以前去过的景点都白去了,近距离接触雪山的压迫感,久久不能忘怀,回程的时候再次途径四姑娘山镇(这次四姑娘山四座山峰全部被云层遮住),碰到了很多攀登大二峰提前下撤的背包客,第一次意识到雪山攀登这项运动,也不是那么遥不可及,心里也种下了一颗种子