Prometheus

在当今日益复杂和快速变化的环境中提供更可靠软件的分步指南 。 这篇文章基于最近一次与Cloud Native Computing Foundation合作，与OverOps工程团队的Brandon Groves和Ben Morrise合作创建的网络研讨会。 如果您认为向微服务和容器的转变是演变而不是革命，那么您来对地方了！在本文中，我们将对基于Kubernetes的应用程序领域采取务实的方法，并详细介绍一系列步骤，以确保整个管道的可靠性。 因为即使今天确保应用程序质量是过去的两倍，但我们还有很多改进方法。具体来说，在对基于Kuberenetes的应用程序进行故障排除的上下文中，我们将涉及持续可靠性的3个支柱：在CI管道中实现代码质量门，在CD管道中实现可观察性，以及创建上下文反馈循环回开发。 当今软件质量状况 首先，让我们尝试了解发生了什么变化以及为什么需要重新审视代码质量的基础。 就在最近，我们总结了年度 软件质量状况 调查，来自世界各地的开发人员提供了600多个答复。我们今年的目标是找出当今的工程团队如何解决速度与质量的难题。 好消息是，大多数调查参与者（70％）表示 质量至高无上 ，他们会优先考虑速度。不幸的是，受访者每周花费一天或更长时间来排查与代码相关的问题，其中超过50％的受访者每月至少一次遇到影响客户的问题。 尽管本次调查更广泛地关注于交付可靠软件的现实和挑战，但仍有

一、HPA HPA的全称为Horizontal Pod Autoscaling，它可以根据当前pod资源的使用率（如CPU、磁盘、内存等），进行副本数的动态的扩容与缩容，以便减轻各个pod的压力。当pod负载达到一定的阈值后，会根据扩缩容的策略生成更多新的pod来分担压力，当pod的使用比较空闲时，在稳定空闲一段时间后，还会自动减少pod的副本数量。 若要实现自动扩缩容的功能，还需要部署heapster服务，用来收集及统计资源的利用率，支持kubectl top命令，heapster服务集成在prometheus（普罗米修斯） MertricServer服务中，所以说，为了方便，我这里基于prometheus服务的环境上进行部署HPA（动态扩缩容）的服务。 可以参考博文： k8s群集的三种Web-UI界面部署 中的第三个部署Prometheus服务，来运行prometheus服务，如果不想部署prometheus，那么可以参考github上来单独 部署heapster服务 ， //要想实现pod副本数量的一个扩缩容，就必须保证，可以在master上执行下面的命令 //查看节点的资源使用情况 [root@docker-k8s01 kube-prometheus]# kubectl top nodes NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%

原文发表于 kubernetes中文社区 ，为作者原创翻译 ， 原文地址 更多kubernetes文章，请多关注 kubernetes中文社区 目录 Service Mesh简介 Istio 架构(Architecture) 组件(Components) 核心功能 Linkerd Architecture ​控制平面(Control Plane) 数据平面(Data Plane)： Service Mesh对比：Istio与Linkerd 结论 参考文献 根据 CNCF 的 最新年度调查 ，很多组织对Service Mesh表现出很高的兴趣，并且有一部分已经在生产环境中使用它们。你可能不知道Linkerd是市场上第一个Service Mesh，但是Istio使Service Mesh更受欢迎。这两个项目都是最前沿的项目，而且竞争非常激烈，因此很难选择一个项目。 在本篇文章中，我们将和你一起了解Istio和Linkerd架构，组件，并比较它们的产品以帮助你做出明智的决定。 Service Mesh简介 在过去的几年中，微服务架构已成为软件设计中流行的样式。在这种架构中，我们将应用程序分解为可独立部署的服务。这些服务通常是轻量级的，多语言的，并且通常由各种职能团队进行开发部署。 当某些服务数量增加，难以管理且越来越复杂时，微服务架构将一直有效。但这也在管理安全性