如何对 kubernetes 应用做 e2e(端到端) 测试
背景
最近在给 opentelemetry-operator提交一个标签选择器的功能时,因为当时修改的函数是私有的,无法添加单测函数,所以社区建议我补充一个 e2e test
.
因为在当前的版本下,只要给 deployment 打上了
instrumentation.opentelemetry.io/inject-java: "true"
这类注解就会给该 deployment 注入 agent。
但没办法指定不同的 agent 版本(或者不同的环境变量),所以希望可以新增一个选择器,同时可以针对不同的 deployment 维护不同版本的Instrumentation
(是用于控制需要注入 deployment 的资源);这样就可以灵活控制了。
一次消息队列异常堆积的排查
在 kubernetes 环境下如何采集日志
当我们没有使用云原生方案部署应用时采用的日志方案往往是 ELK 技术栈。
这套技术方案比较成熟,稳定性也很高,所以几乎成为了当时的标配。
可是随着我们使用 kubernetes 步入云原生的时代后, kubernetes 把以往的操作系统上的许多底层都屏蔽,再由他提供了一些标准接口。
同时在 kubernetes 中的日志来源也比传统虚拟机多,比如可能有容器、kubernetes 自身的事件、日志等。
实战:如何编写一个 OpenTelemetry Extensions
前言
前段时间我们从 SkyWalking
切换到了 OpenTelemetry
,与此同时之前使用 SkyWalking 编写的插件也得转移到 OpenTelemetry 体系下。
我也写了相关介绍文章:
实战:如何优雅的从 SkyWalking 切换到 OpenTelemetry
好在 OpenTelemetry 社区也提供了 Extensions 的扩展开发,我们可以不用去修改社区发行版:opentelemetry-javaagent.jar
的源码也可以扩展其中的能力。
比如可以:
- 修改一些 trace,某些 span 不想记录等。
- 新增 metrics
2024年的云原生架构需要哪些技术栈
背景
时间过得很快啊,一转眼已经到了 2024 年,还记得 15 年刚工作那会掌握个 SSM/H(Spring/Struts2/Mybatis/Hibernate)
框架就能应付大部分面试了。
现在 CS 专业的新同学估计都没听说过 SSM😢
恰好从我刚开始工作时的移动互联网热潮到电商->共享经济->toB 大热->如今我都经历了一遍,技术栈也有由最开始的单体应用+物理机发展到现在的 kubernetes 云原生架构。
当然中途也经历了几个大的阶段:
SOA服务化-> 微服务-> 云原生-> 服务网格-> 无服务等几个阶段。
最近一份工作又主要是在做基础架构,我认为了解的还算是比较全面的,所以本文我就以我的视角分享下我们在 2024 年应当使用哪些云原生技术栈,因为涉及到的技术组件比较多,就不过多讨论细节了。
但可以保证的是提到的技术栈都是我所用过的,优缺点都会提到,主打一个真实体验。
在 kubernetes 环境下如何优雅扩缩容 Pulsar
顶级开源社区都能吵起来?
起因
因为订阅了 Pulsar 的开发者邮件,前段时间看到一封标题为《(Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika》的邮件。
乍一看以为是欢迎 Asaf Mesika
成为 Committer,但仔细一看不太对劲,这内容也太多了,以往的欢迎都是简单的 Congratulations!
作为回复,这篇内容明显有点多了,于是便仔细看了下。
技术阅读周刊第十四期:常用的 Git 配置
技术阅读周刊,每周更新。