背景

在前面三节中已经讲到如何将我们的应用部署到 k8s 集群并提供对外访问的能力，x现在可以满足基本的应用开发需求了。

现在我们需要更进一步，使用 k8s 提供的一些其他对象来标准化我的应用开发。
首先就是 ConfigMap，从它的名字也可以看出这是用于管理配置的对象。

背景

前两天 Golang 的官方博客更新了一篇文章：Fixing For Loops in Go 1.22

看这个标题的就是修复了 Go 循环的 bug，这真的是史诗级的更新；我身边接触到的大部分 Go 开发者都犯过这样的错误，包括我自己，所以前两年我也写过类似的博客：
简单的 for 循环也会踩的坑

背景

前段时间给 VictoriaLogs 提交了一个 PR：
https://github.com/VictoriaMetrics/VictoriaMetrics/pull/4934

本来一切都很顺利，只等合并了，但在临门一脚的时候社区维护人员问我可否给 git commit 加上签名。

于是我就默默的调试到了凌晨四点😭

背景

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

这一步类似于我们以前配置 Nginx 和绑定域名，提供这个能力的服务在 k8s 中成为 Ingress。

通过这个描述其实也能看出 Ingress 是偏运维的工作，但也不妨碍我们作为研发去了解这部分的内容；了解整个系统是如何运转的也是研发应该掌握的技能。

背景

在之前的文章中分享了 k8s 相关的面试题，本文我们重点来讨论和 k8s 密切相关的 Go 语言面试题。

这几年随着云原生的兴起，大部分后端开发者，特别是 Java 开发者都或多或少的想学习一些 Go 相关的技能，所以今天分享的内容比较初级，适合 Go 语言初学者。

本文内容依然来自于这个仓库
https://github.com/bregman-arie/devops-exercises

背景

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

背景

最近这这段时间更新了一些 k8s 相关的博客和视频，也收到了一些反馈；大概分为这几类：

• 公司已经经历过服务化改造了，但还未接触过云原生。
• 公司部分应用进行了云原生改造，但大部分工作是由基础架构和运维部门推动的，自己只是作为开发并不了解其中的细节，甚至 k8s 也接触不到。
• 还处于比较传统的以虚拟机部署的传统运维为主。

其中以第二种占大多数，虽然公司进行了云原生改造，但似乎和纯业务研发同学来说没有太大关系，自己工作也没有什么变化。

恰好我之前正好从业务研发的角度转换到了基础架构部门，两个角色我都接触过，也帮助过一些业务研发了解公司的云原生架构；

为此所以我想系统性的带大家以研发的角度对 k8s 进行实践。

因为 k8s 部分功能其实是偏运维的，对研发来说优先级并不太高；
所以我不太会涉及一些 k8s 运维的知识点，比如安装、组件等模块；主要以我们日常开发会使用到的组件讲起。

背景

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

消息列表

背景

前段时间我们想实现 Pulsar 消息的追踪流程，追踪实现的效果图如下：

实现其实比较简单，其中最重要的就是如何存储消息。

消息的读取我们是通过 Pulsar 自带的 BrokerInterceptor 实现的，对这个感兴趣的朋友后面会单独做一个分享。

前段时间在这个视频中分享了 https://github.com/bregman-arie/devops-exercises 这个知识仓库。

这次继续分享里面的内容，本次主要以 k8s 相关的问题为主。