k8s pod的服务发现依赖于dns解析，本文简单介绍下dns的几种策略。

这是从golang官网转载的一篇文章，对理解golang的内存管理和go应用程序调优有很大帮助。

随着国产化和信创的推进，为应用适配多个操作系统和处理器架构的需求越来越普遍。常见做法是为不同平台单独构建一个版本，当用来开发的平台与部署的目标平台不同时，实现这一目标并不容易。例如在 x86 架构上开发一个应用程序并将其部署到 ARM 平台的机器上，通常需要准备 ARM 平台的基础设施用于开发和编译。 一次构建多处部署的镜像分发大幅提高了应用的交付效率，对于需要跨平台部署应用的场景，利用 docker buildx 构建跨平台的镜像也是一种快捷高效的解决方案。

理解K8s的网络模型对于排查诸如service访问，pod通信等问题排查有很大帮助。本文在总结了k8s网络基础知识，并给出一些案例学习。

使用docker可以基于所在的环境指令架构构建目标指令架构的镜像，可以大大方便镜像的构建工作。比如当前云计算arm架构终端比较多，而开发环境往往是am64的linux系统环境，这样便可以参考本文的方法。

在一些场景下，daemonset pod需要拿到所在node节点的uuid作为自己的不变标识，比如日志采集agent，需要提供后端一个agentid作为日志查询上下文的来源标识，这个时候不能那pod的uuid或者每次启动生成一个唯一ID，因为每次pod重建这个都不能保证id不变。有个方案就是用所在宿主机节点的UUID作为这个ID。

跟踪为我们提供了向应用程序发出请求时发生的情况的总体情况。无论您的应用程序是具有单个数据库的整体应用程序还是复杂的服务网格，跟踪对于了解请求在应用程序中采用的完整“路径”都至关重要。

指标的 OpenTelemetry 数据模型由用于交付预聚合指标时间序列数据的协议规范和语义约定组成。该数据模型旨在从现有系统导入数据并将数据导出到现有系统，以及支持内部 OpenTelemetry 用例，以从跨度或日志流生成指标。

ipv6是必然趋势，开发需要对这个格式有所了解，在此转载一个文章对此进行个简要介绍

在Prometheus支持的众多服务发现的实现方式中，基于文件的服务发现是最通用的方式。本文简单介绍下使用方式。

上一篇介绍了基于静态文件的服务发现模式，本文继续介绍基于consual模式的服务发现

前两文介绍了Promethues的服务发现机制，本文介绍下Relabel机制

Prometheus在云原生监控领域炙手可热，提供了数据采集到存储到查询的完善的系统；而Otel在监控数据采集，除了指标数据Metrics以外，还有Trace和Logs，集成了OpenCensus和opentracing，形成了通用的一套标准，而且开源生态也越来越丰富。本文对比了二者在Metrics上的共同和不同之处。

分布式微服务架构的流行，带来了新的挑战：如何有效地诊断分布式系统中的问题，如何找到问题的根本原因。分布式追踪系统可以帮助开发人员在复杂的系统中快速地诊断问题。本文将介绍如何使用OpenTelemetry实现分布式微服务链路追踪。