谢谢！
有无数的文章、讨论、以及很多社区喋喋不休地比较 Docker、Kubernetes 和 Mesos。如果你只是听信了只言片语，你可能会认为这三个开源项目正为了称霸容器界而殊死搏斗。你可能还相信从他们中选出一个如宗教信仰般神圣——真正的信徒会忠于他们的信仰，而且会烧死那些敢于考虑替代方案的异教徒。
那都是废话。
虽然所有这三种技术都使得使用容器来部署、管理和伸缩应用成为可能，但实际上它们各自解决了不同的问题，并且根植于迥异的上下文环境中。事实上，这三种被广泛采用的工具链，都是有差别的。
让我们重新审视每个项目的原始任务、技术架构，以及它们是如何相互补充和交互的，而不是纠结于比较这些快速迭代的技术之间重叠的特性。
默认情况下，Harbor不提供证书。可以在没有安全性的情况下部署Harbor，这样您就可以通过HTTP连接到它。但是，只有在没有连接到外部internet的空间隙测试或开发环境中才可以使用HTTP。在没有空间隙的环境中使用HTTP会暴露给中间人攻击。在生产环境中，始终使用HTTPS。如果启用带公证人的内容信任对所有images进行正确签名，则必须使用HTTPS。要配置HTTPS，必须创建SSL证书。您可以使用由受信任的第三方CA签名的证书，也可以使用自签名证书。本节介绍如何使用OpenSSL创建CA，以及如何使用CA签署服务器证书和客户端证书。
本文介绍了通过 Docker 配置 OpenTelemetry 和 Jaeger，实现分布式链路追踪。详细讲解了如何使用 OpenTelemetry Agent 和 Collector 配置尾部采样策略，识别慢请求和错误。结合 Prometheus 和 Grafana，构建全面的监控和追踪系统。提供了具体的 `docker-compose.yml` 配置文件示例，适合需要全链路可观测性的分布式应用开发环境。
本文介绍了如何使用 Docker 和 EFK（Elasticsearch、Fluentd、Kibana）套件构建日志管理系统，通过 Fluentd 将 NACOS 和业务日志集中发送至 Elasticsearch，方便数据分析和故障排查。文章提供了 `docker-compose.yml` 配置文件示例，解决了插件安装、权限设置和健康检查等常见问题，为构建灵活高效的日志管理系统提供了实用方法。
本文介绍了使用 Docker 构建开发环境的步骤，涵盖 MySQL 数据库配置、Nacos 服务发现与配置管理、Prometheus 监控及 Grafana 可视化。通过 Docker Compose 结构化配置，实现了多组件集成。文章提供了详细的 `docker-compose.yml` 文件示例，并探讨了自动接入监控、应用打包等优化方向，适用于需要集中管理多项开发工具的场景。
随着微服务以及云原生的发展，越来越多的企业都将业务部署运行到Kubernetes中，主要是想依托Kubernetes的可扩展、可伸缩、自动化以及高稳定性来保障业务的稳定性。
然而，Kubernetes本身是一个复杂的管理系统，它既然是作为企业业务的基础设施，其本身以及运行在集群内部的业务系统对于企业来说都变得非常重要。
在整个大环境的降本增效的熏陶下，我们也不得不做好应对方案。
根据对线上流量、存储以及系统资源的占用，发现我们的 Pulsar 集群有许多的冗余，所以考虑进行缩容从而减少资源浪费，最终也能省一些费用。
不过在缩容之前很有必要先聊聊扩容，Pulsar 一开始就是存算分离的架构（更多关于 Pulsar 架构的内容本文不做过多介绍，感兴趣的可以自行搜索），天然就非常适合 kubernetes 环境，也可以利用 kubernetes 的能力进行快速扩容。
本文对比游戏服务器中C++搭配脚本语言（Lua、Python）以及纯编译型语言（C++、Golang）来进行开发时，进行线上服务器热更新的方案。
Kubernetes Pods被驱逐是什么意思？它们被终止了，通常是由于没有足够的资源，但是为什么会发生这种情况呢？
驱逐是一个过程，分配给一个节点的Pod被要求终止。Kubernetes中最常见的情况之一是抢占，为了在资源有限的节点上安排一个新的Pod，通常需要终止另外一个Pod。
另外，Kubernetes会不断检查资源使用情况，当节点压力过大的时候，会触发节点压力驱逐。
每天，数以千计的Pod被驱逐出他们的家园。搁浅和迷茫，他们不得不放弃以前的生活方式。他们中的一些人甚至会无家可归。当前的社会，对CPU和内存的要求会越来越高。
使用 Kubernetes 时，内存不足 (OOM) 错误和 CPU 节流是云应用程序中资源处理的主要难题。
这是为什么？
云应用程序中的 CPU 和内存要求变得越来越重要，因为它们与您的云成本直接相关。
通过 limits 和 requests ，您可以配置 pod 应如何分配内存和 CPU 资源，以防止资源匮乏并调整云成本。
如果节点没有足够的资源， Pod 可能会通过抢占或节点压力被驱当一个进程运行内存不足 (OOM) 时，它会被终止，因为它没有所需的资源。
如果 CPU 消耗高于实际限制，进程将开始节流。
但是，如何主动监控 Kubernetes Pod 到达 OOM 和 CPU 节流的距离有多近？
在这篇文章中，我们将在Kubernetes中使用Grafana、Prometheus、Loki、Tempo、OpenTelemetry来搭建可观测性平台。其中Grafana作为操作面板，Prometheus、Loki、Tempo作为数据源，分别用来获取指标、日志以及跟踪数据。同时，我们还将使用Exemplars将trace_id与Java指标相关联，使用OpenTelemetry对应用进行检测。