神话还是现实？Docker 和 Kubernetes 架构

任何 Docker 容器使其日志可访问的唯一方法是将它们写入容器中运行的根进程的标准输出或标准错误设备(STDOUT 或 STDERR)。微服务的开发人员并不真正关心日志数据接下来会发生什么，只需要保证它们应该在必要时可用，并且最好包含过去某个时刻的记录。Kubernetes 和支持这个生态的工程师负责这一切的实现。

在 官方文档 中，你可以找到处理日志的基本(也是一个好的)策略的描述，这将有助于你选择用于聚合和存储大量文本数据的服务。

在日志记录系统的推荐服务中，相同的文档提到了用于收集数据的 fluentd (作为代理在集群的每个节点上启动)和存储和索引数据的 Elasticsearch 。即使你可能不同意这种解决方案的效率，但它是可靠且易于使用的，所以我认为这至少是一个好的开始。

Elasticsearch 是一个资源密集型解决方案，但是它可以很好地扩展，并且有现成的 Docker 镜像来运行单个节点或所需大小的集群。

追踪系统

尽管你的代码尽可能完美，但失败确实会发生，然后你想在生产环境中仔细研究它们，并尝试理解“在我的本地机器上一切工作都是正常的呀，现在到底是哪里出了什么问题呢?”。数据库查询速度慢、缓存不当、磁盘速度慢或与外部资源的连接速度慢、生态系统中的事务、瓶颈和规模不足的计算服务，这些都是你必须跟踪和估计在实际负载下执行代码所花费的时间的原因。

Opentracing 和 Zipkin 可以支持在大多数现代编程语言中完成这一任务，并且在 埋点(instrumenting)代码之后不会增加任何额外的负担。当然，所有收集的数据都应该存储在一个合适的地方，被 组件 之一所使用。

在代码中埋点并通过所有服务、消息队列、数据库等转发 “跟踪标识”(Trace Id)时带来的复杂性由上述开发标准和服务模板解决。后者还负责保证方法的一致性。

监控和报警

Prometheus 已经成为现代系统中事实上的监控和报警标准，更重要的是，它在 Kubernetes 中几乎 开箱即用 。你可以参考 官方 Kubernetes 文档 ，了解更多有关监控和报警的信息。

监控是必须安装在群集内的少数辅助系统之一。集群是一个受监控的实体。但是监控系统的监控(请原谅重复)只能从外部执行(例如，从相同的 “预生产”(Staging)环境)。在这种情况下，交叉检查对于任何分布式环境来说都是一个方便的解决方案，不会使高度统一的生态系统的架构复杂化。

整个监控范围分为三个完全逻辑隔离的级别。以下是我认为在每个级别跟踪点的最重要的例子：

• 物理资源级别：
• 网络资源及其可用性
• 磁盘 (I/O，可用空间)
• 单个节点的基本资源(CPU、RAM、LA)
• 集群级别：
• 主集群系统中每个节点的可用性(kubelet、kubeAPI、DNS、etcd 等)
• 监控服务允许的和实际的资源消耗
• Pod 的重新加载
• 服务级别：
• 任何类型的应用程序监控
• 从数据库内容到应用编程接口调用的频率
• API 网关上的 HTTP 调用错误数
• 队列的大小和 worker 节点的利用率
• 数据库的多个指标(复制延迟、事务的时间和数量、慢速请求等)
• 非 HTTP 协议进程的错误分析
• 监控发送到日志系统的请求(你可以将任意请求转换为度量值)

至于每个级别的报警通知，我建议你使用无数外部服务之一，这些服务可以通过电子邮件、短信发送通知或拨打手机号码。我还要提到另一个系统 — OpsGenie ，它可以 与 Prometheus 的报警管理器紧密集成 。

OpsGenie 是一种灵活的报警工具，有助于处理故障升级报告、全天候工作、通知渠道选择等。在团队之间分发报警信息也很容易。例如，不同级别的监控应该向不同的团队/部门发送通知：物理资源 —> 基础设施 + Devops，集群 —> Devops，应用 — > 向相关团队发送通知。

API 网关和单点登录

为了处理授权、身份验证、用户注册(外部用户——公司的客户)和其他类型的访问控制等任务，你需要一个高度可靠的服务，它可以与您的 API 网关保持灵活的集成。使用与“身份服务”相同的解决方案没有害处，但是您可能希望将这两种资源分开，以实现不同级别的可用性和可靠性。

服务间集成不应该很复杂，你的服务不应该担心用户的授权和认证。相反，架构和生态系统应该有一个代理服务来处理所有的通信和 HTTP 流量。

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!