Kubernetes的稳定性框架是什么

本文小编为大家详细介绍“Kubernetes的稳定性框架是什么”，内容详细，步骤清晰，细节处理妥当，希望这篇“Kubernetes的稳定性框架是什么”文章能帮助大家解决疑惑，下面跟着小编的思路慢慢深入，一起来学习新知识吧。使用Kubernetes 1.15版本，通过API（/metrics）查询Kubernetes监控指标时，在某些指标的 HELP 信息中，可以看到诸如 “[ALPHA]” 、“[STABLE]” 、“（Deprecated）”等字样，用来标明监控指标的稳定性，以便于用户跟据自身需求来放心的使用这些指标来监控集群。一个典型的指标如下所示：与其他API的标识一样，ALPHA意味着该监控指标还处理于实验阶段，可能随时会改变，而且不保证会通知用户，用户需要谨慎使用。Deprecated意味着该监控指标已被弃用，在将来的版本中会被删除，用户需要尽快停止使用或使用替代的监控指标。本文编写时间为1.16版本发布前夕，既有的监控指标还未全部迁移到该框架中，所以只有部分监控指标会有稳定性标识。本文希望从监控指标稳定性框架的开发背景讲起，接着介绍该框架的实现原理，以帮助开发者更详细的了解和使用这个特性。很多集群监控系统都使用Kubernetes提供的监控指标来监控集群运行状况，然而Kubernetes提供的指标没有任何稳定性的保证，也就是说Kubernetes随时有可能修改这些指标，用户升级新的Kubernetes版本后，有可能原有的监控指标已被修改或直接删除，这给用户带来了困扰，这种用户的困扰引起了社区关注。为了解决这个问题，社区进行了广泛的讨论，总结下来有这两种主流的思路：使用版本标记：为监控指标划分版本标识，比如 /metrics/v1beta1、/metrics/v1等；使用文档标记：提供文档标记那些稳定的监控指标；这两种思路都有相应的优缺点：使用版本标记的办法更类似于Kubernetes API的做法，这种做法优点是可以同时支持多个版本，缺点是实现起来非常笨重；使用文档标记优点是实现简单，把稳定的监控指标记录到文档中即可，缺点是后续迭代时仍然会不可避免的破坏这个规则，从工程角度讲，非常难以管理。最后，结合这两个思路的优缺点，社区使用了一个更具创新性的方案，也就是本文要介绍的稳定性框架，该框架在实现层面相对使用版本标记更简单，在工程层面比使用文档标记更易于管理。与每个公司成立时都需要一个愿景或口号一样，监控指标稳定性框架也有自己的愿景：提供一种描述监控指标稳定性的机制；提供多种监控稳定性描述；两个愿景，一个是帮助Kubernetes开发人员定义自己的监控指标，一个是如何向用户呈现稳定性保证。同时，以下内容不在框架的考虑范围：不定义某个具体的监控指标稳定级别；不负责检查具体的监控指标是否符合规范；事实上，本框架不考虑的这些内容也很重要，会在社区其他事项中去做，只是本框架不负责这些内容。我们或许都听说过Prometheus已成为Kubernetes监控的事实标准，这体现在Kubernetes的很多组件（kube-scheduler、kubelet、kube-controller-manager和kube-apiserver等）都使用Prometheus客户端来生成Prometheus格式的监控指标。使用Prometheus，对于每个监控指标一般会先初始化一个实例，再添加到全局的注册表中，最后当用户使用API访问时，http handler 负责把这些监控指标导出。初始化实例：添加到注册表：http handler 使用的也是 Prometheus提供的handler:由上可以看到，原有的监控标标严重依赖Prometheus的特性，而新的框架设计将会对监控指标的定义、初始化、注册过程进行封装，即各组件不再直接使用Prometheus，而是使用新的框架，尽管新的框架还是使用Prometheus来实现，但提供了更多个性化的设计。在监控指标定义环节，新框架提供了新的指标参数结构体，以便于增加稳定性标识。比如，曾经使用Prometheus定义一个计数器时会使用prometheus.CounterOpts结构体，如下所示：新框架则提供了一个经过扩展的参数结构体kubemetrics.CounterOpts，新增加了StabilityLevel和DeprecatedVersion等字段用于表示稳定性和弃用标示。表示一个监控指标被废弃，可以如下定义：表示一个ALPHA监控指标，可以如下定义：与Prometheus一致，新框架对4种监控指标分别做了扩展：CounterOptsGaugeOptsHistogramOptsSummaryOpts本节暂不对每种监控指标展开介绍，还是聚焦在阐述新框架的实现思路上。曾经，使用Prometheus来初始化监控指标（获取监控指标实例），将使用一系列的prometheus.NewXXX()方法，如下所示：一方面，由于新的框架扩展了指标定义结构体，无法继续使用prometheus.NewXXX()方法开发云主机域名，另一方面新框架也希望能在指标初始化时扩展自定义行为（比如处理定义环节加入的字段），所以新框架中也提供了类似的一系列方法。使用新框架的方法来初始化实例示例如下：同样与Prometheus保持一致，新框架也提供了所有的初始化方法：NewCounter() 和 NewCounterVec()NewGauge() 和 NewGaugeVec()NewHistogram() 和 NewHistogramVec()NewSummary() 和 NewSummaryVec()同样，本节暂不对每种初始化方法展开介绍，这部分内容留到后面的章节中。曾经，使用Prometheus来注册一个监控指标实例时，实际上是注册到一个全局的注册表，如下所示：新框架中对注册也进行了封装，以便增加自定义的行为，比如废弃版本检查，注册逻辑伪代码如下：使用新框架注册，如下所示：由上综述，可以看到在编程层面，既有的监控指标可以方便的迁移到新框架，如果监控指标没有个性化的需求，那么其行为与原Prometheus完全一致，如果有个性化的需求，通过简单的配置就可完成，具体的实现细节全部由新框架负责。当前版本（kubernetes 1.15 & 1.16）提供两个级别的稳定性，用来阐述每个监控指标的稳定性：AlphaStable需要额外提及的时，在当前的设计中并没有考虑 Beta 级别，新框架作者表示将来有需要时再添加，添加也会非常简单。Alpha 级别的监控指标，基本上不提供任何稳定性的保证，它们可以随时被修改，而且新框架引入后，既有的监控指标都将标记为这个级别。Stable 级别的监控指示，基本上可以保证“不再修改”，除非将来被废弃。这里所说的“不再修改”指以下三个内容不会修改：监控指标本身不会被删除或重命名；监控指标类型不会被修改；监控指标的lable列表不会增加或减少；针对Stable级别的监控指标，lable列表不会改变，但lable 值是可以改变的。比如，某个指标用于记录鉴权的次数，使用”result”作为lable进行区分，lable 值原来是”success”和”failure”，是允许增加新的lable 值的，比如增加一个”error”（不是简单的鉴权失败，而是出现某种异常）。比如，你之前得到的指标将会由：变成：一般来讲，这种变化对用户的冲击不会很大。针对Stable级别的监控指标，删除或增加 lable 是不允许的，如果必须要这么做，需要先把当前的指标废弃，再提供一个新的监控指标。对于用户来讲，新框架还提供了一个由用户显式的屏蔽某些监控指标的能力，默认情况下，所有的监控指标都会被注册并最终通过API提供给用户，但使用新框架后，用户可以通过相应组件的启动参数显式的关掉某些监控指标，比如：把一个监控指标标记为 Stable 意味着对广大用户做出了一个承诺，这跟 API 是一致的。所以将某个监控指标标记为 Stable 或者 废弃某个监控指标时，需要非常谨慎的 review。然而，跟据Kubernetes社区的组织划分，各个组件分别有不同的 group (准确叫法是SIG)来负责相应的组件开发，各group的 reviewer 可能并不完全了解新框架所引入的这个理念，所以各group很有可能将来破坏之前做出的稳定性承诺。而每个相关监控指标的修改都由负责监控的group来review，代价会非常大，而变得不可取。针对这个问题，kubernetes社区又提供了让人眼前一亮的方法，即引入新的一致性测试。 即，生成一份现有的稳定性列表，并存放到某个由监控组管理的目录中，增加新的CI工作流收集最新的稳定性监控指标，二者对比，如果不一致，CI 会失败并拒绝合入，除非显式的修改稳定性列表。CI可以保证当显式的修改稳定性列表时，必须经过监控组的批准。每个Stable的监控指标，在决定要将其废弃后，可以在监控指标定义处显式的指定将要弃用的版本（DeprecatedVersion）。某个指标标记为废弃后不会马上被删除，需要留给用户一个适配的窗口，在接下来的某些版本中才会真正被删除。被废弃的监控指标都会经历如下阶段（每个阶段代表一个kubernetes minor版本）：比如，某个监控指标在1.16版本进入 Stable 阶段，将在 1.17版本弃用，那么在各版本其状态如下：1.16（Stable metric）：可正常使用；1.17（Deprecated metric）：标记为弃用，当前版本仍然可以用，但是用户需要准备适配；1.18（Hidden metric）：默认不开启该监控指标，管理员可通过参数显式的启用该指标；1.19（Deletion）：彻底删除，无法再使用；比如，某个监控指标将在1.17版本废弃，那么1.17版本（或更早的版本）开发时可以这样设置：使用1.17之前的版本，监控指标信息如下：那么用户在使用1.17版本时，将会看到相应的指标信息中出现弃用信息：此外，当监控指标被标记为废弃后，虽然能正常使用，但是在相应的组件日志中可以看到告警日志。当监控指标被弃用的下一个版本，即DeprecatedVersion == current_kubernetes_version – 1时，该监控指标默认会被隐藏：即不会自动注册。被隐藏的指标可以通过相应组件的启动参数（–enable-hidden-metrics=really_deprecated_metric）来显式的启用。如果用户忘记在上个版本中做好适配，仍然可以在本版本中继续使用，这无疑给用户延长了适配窗口。另外，需要特别提及的几点是：被标记为弃用的监控指标仍然尊守之前的稳定性约定，除了增加弃用标记外不会修改指标内容；本弃用规则是针对Stable监控指标的，不对 Alpha 监控指标做强制要求。处于 Alpha 阶段的监控指标也可以标记废弃版本号，它可以帮助使用 Alpha 监控指标的用户准确的了解某个监控指标何时会被删除，仅用于说明，被删除前可以不遵循弃用规则；读到这里，这篇“Kubernetes的稳定性框架是什么”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注开发云行业资讯频道。

相关推荐: ERP项目管理成功要关注的控制点都有哪些

ERP项目管理成功要关注的控制点都有哪些，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。开发云主机域名 一个ERP系统的实施需要许多因素，包括软件、硬件和服务，是一个浩大的系统工程。项目的计划、…