背景在前面三节中已经讲到如何将我们的应用部署到 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 也接触不到。 还处于比较传统的以虚拟机部署的传统运维为主。 其中以第二种占大多数，虽然公司进行了云原生改造，但似乎和纯业务研发同学

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

背景前段时间我们想实现 Pulsar 消息的追踪流程，追踪实现的效果图如下： 实现其实比较简单，其中最重要的就是如何存储消息。 消息的读取我们是通过 Pulsar 自带的 BrokerInterceptor 实现的，对这个感兴趣的朋友后面会单独做一个分享。

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