crossoverJie的内卷小课堂

在整个大环境的降本增效的熏陶下，我们也不得不做好应对方案。 根据对线上流量、存储以及系统资源的占用，发现我们的 Pulsar 集群有许多的冗余，所以考虑进行缩容从而减少资源浪费，最终也能省一些费

今天是春节的最后一天，因为工作上临时有点事，很不情愿的打开电脑看着也就 10 天没看代码觉得非常陌生。 之后便准备将迟迟未写的 2023 总结补完，这个传统从16年至今已经坚持将近 7 年时间了，今年

前段时间无意间看到一篇公众号 招贤令：一起来搞一个新开源项目，作者介绍他想要做一个开源项目：cprobe 用于整合目前市面上散落在各地的 Exporter，统一进行管理。 比如我们常用的 bla

最近我们的 Pulsar 存储有很长一段时间数据一直得不到回收，但消息确实已经是 ACK 了，理论上应该是会被回收的，随着时间流逝不但没回收还一直再涨，最后在没找到原因的情况下就只有一直不停的扩容。

在上一篇 Pulsar3.0新功能介绍中提到，在升级到 3.0 的过程中碰到一个致命的问题，就是升级之后 topic 被删除了。 正好最近社区也补充了相关细节，本次也接着这个机会再次复盘一下，毕竟这是

在上一篇文章 Pulsar3.0 升级指北讲了关于升级 Pulsar 集群的关键步骤与灾难恢复，本次主要分享一些 Pulsar3.0 的新功能与可能带来的一些问题

Pulsar3.0 是 Pulsar 社区推出的第一个 LTS 长期支持版本。 如图所示，LTS 版本会最长支持到 36 个月，而 Feature 版本最多只有六个月；类似于

前段时间在使用 Pulsar 的 admin API 时，发现其中的一个接口响应非常慢： 使用 curl 拿到的响应结果非常大

之前写过一篇文章 VictoriaLogs：一款超低占用的 ElasticSearch 替代方案讲到了我们使用 Victorialogs 来存储 Pulsar 消息队列的消息 trace 信息。

当我们在生产环境发布应用时，必须要考虑到当前系统还有用户正在使用的情况，所以尽量需要做到不停机发版。 所以在发布过程中理论上之前的 v1 版本依然存在

今天进入 kubernetes 的运维部分（并不是运维 kubernetes，而是运维应用），其实日常我们大部分使用 kubernetes 的功能就是以往运维的工作，现在云原生将运维和研发关系变得更紧

最近在测试将 Pulsar 2.11.2 升级到 3.0.1的过程中碰到一个鉴权问题，正好借着这个问题充分了解下 Pulsar 的鉴权机制是如何运转的。 Pulsar 支持 Namespace/

在上一期 k8s-服务网格实战-配置 Mesh 中讲解了如何配置集群内的 Mesh 请求，Istio 同样也可以处理集群外部流量，也就是我们常见的网关。 其实和之前讲到的k8s入门到实战-使用Ingr

在上一篇 k8s-服务网格实战-入门Istio中分享了如何安装部署 Istio，同时可以利用 Istio 实现 gRPC 的负载均衡。 今天我们更进一步，深入了解使用 Istio 的功能。

终于进入大家都比较感兴趣的服务网格系列了，在前面已经讲解了： 如何部署应用到 kubernetes 服务之间如何调用 如何通过域名访问我们的服务 如何使用 kubernetes

最近在升级服务网格 Istio，升级后有个必要的流程就是需要重启数据面的所有的 Pod，也就是业务的 Pod，这样才能将这些 Pod 的 sidecar 更新为新版本。 方案 1 因为我们不同环境的

前段时间写过一篇 gRPC 的入门文章，在最后还留了一个坑没有填： 也就是 gRPC 的负载均衡问题，因为当时的业务请求量不算大，再加上公司没有对 Istio 这类服务网格比较熟悉的大牛，所以我

Helm 是一个 Kubernetes 的包管理工具，有点类似于 Mac 上的 brew，Python 中的 PIP；可以很方便的帮我们直接在 kubernetes 中安装某个应用。 比如我们可

在前面三节中已经讲到如何将我们的应用部署到 k8s 集群并提供对外访问的能力，x现在可以满足基本的应用开发需求了。 现在我们需要更进一步，使用 k8s 提供的一些其他对象来标准化我的应用开发。

前段时间给 VictoriaLogs 提交了一个 PR： https://github.com/VictoriaMetrics/VictoriaMetrics/pull/4934 本来一切都很顺