crossoverJie的内卷小课堂

在上一篇 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 本来一切都很顺

前两章中我们将应用部署到了 k8s 中，同时不同的服务之间也可以通过 service 进行调用，现在还有一个步骤就是将我们的应用暴露到公网，并提供域名的访问。 这一步类似于我们以前配置 Ngin

在做传统业务开发的时候，当我们的服务提供方有多个实例时，往往我们需要将对方的服务列表保存在本地，然后采用一定的算法进行调用；当服务提供方的列表变化时还得及时通知调用方。 这样自然是对双方都带来不

最近这这段时间更新了一些 k8s 相关的博客和视频，也收到了一些反馈；大概分为这几类： 公司已经经历过服务化改造了，但还未接触过云原生。 公司部分应用进行了云原生改造，但大部分工作是由基础架构和

为了让业务团队可以更好的跟踪自己消息的生产和消费状态，需要一个类似于表格视图的消息列表，用户可以直观的看到发送的消息；同时点击详情后也能查到消息的整个轨迹

前段时间我们想实现 Pulsar 消息的追踪流程，追踪实现的效果图如下： 实现其实比较简单，其中最重要的就是如何存储消息。 根据这里的显示内容我们大概需要存储这些信息： 客户端地址 消息发布时间

前段时间在这个视频中分享了 https://github.com/bregman-arie/devops-exercises 这个知识仓库。 这次继续分享里面的内容，本次主要以 k8s 相关的问题为主

开源这件事情在软件开发领域一直是一个高频话题，我们工作中不管是使用到的工具还是第三方库都离不开开源的支持。 近期由于工作的原因，我需要经常和 Apache Pulsar 社区沟通，同时也会将日常

前段时间业务团队偶尔会碰到一些 Pulsar 使用的问题，比如消息阻塞不消费了、生产者消息发送缓慢等各种问题。 虽然我们有个监控页面可以根据 topic 维度查看他的发送状态，比如速率、流量、消

蛮久没更新了，本次我想聊聊找工作的事情，相信大家都能感受到从去年开始到现在市场是一天比一天差，特别是在我们互联网 IT 行业。 已经过了 18 年之前的高速发展的红利期

前段时间业务研发反馈说是他的应用内存使用率很高，导致频繁的重启，让我排查下是怎么回事； 在这之前我也没怎么在意过这个问题，正好这次排查分析的过程做一个记录。

最近接手维护了公司的指标监控系统，之后踩到坑就没站起来过。。 本次问题的起因是我们配置了一些指标的删除策略没有生效： 与这两个容易引起误解的配置relabel_configs/metric_re

最近真是和 Pulsar 杠上了，业务团队反馈说是线上有个应用消息重复消费。 而且在测试环境是可以稳定复现的，根据经验来看一般能稳定复现的都比较好解决。 定位问题 接着便是定位问题了，根据之前的

今天收到业务团队反馈线上有个应用往 Pulsar 中发送消息失败了，经过日志查看得知是发送消息时候抛出了 java.lang.InterruptedException 异常。 和业务沟通后得知是