共计 7968 个字符，预计需要花费 20 分钟才能阅读完成。
本文丸趣 TV 小编为大家详细介绍“Kubernetes 的稳定性框架是什么”，内容详细，步骤清晰，细节处理妥当，希望这篇“Kubernetes 的稳定性框架是什么”文章能帮助大家解决疑惑，下面跟着丸趣 TV 小编的思路慢慢深入，一起来学习新知识吧。
引言
使用 Kubernetes 1.15 版本，通过 API（/metrics）查询 Kubernetes 监控指标时，在某些指标的 HELP 信息中，可以看到诸如“[ALPHA]”、“[STABLE]”、“（Deprecated）”等字样，用来标明监控指标的稳定性，以便于用户跟据自身需求来放心的使用这些指标来监控集群。
一个典型的指标如下所示：
# HELP rest_client_request_latency_seconds [ALPHA] (Deprecated) Request latency in seconds. Broken down by verb and URL.
# TYPE rest_client_request_latency_seconds histogram
rest_client_request_latency_seconds_bucket{url= https://[::1]:6443/%7Bprefix%7D ,verb= GET ,le= 0.001 } 36
rest_client_request_latency_seconds_bucket{url= https://[::1]:6443/%7Bprefix%7D ,verb= GET ,le= 0.002 } 148
rest_client_request_latency_seconds_bucket{url= https://[::1]:6443/%7Bprefix%7D ,verb= GET ,le= 0.004 } 166
rest_client_request_latency_seconds_bucket{url= https://[::1]:6443/%7Bprefix%7D ,verb= GET ,le= 0.008 } 172与其他 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 负责把这些监控指标导出。
初始化实例：
var authenticatedUserCounter = prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: authenticated_user_requests ,
Help: Counter of authenticated requests broken out by username. ,
[]string{ username},
)添加到注册表：
prometheus.MustRegister(authenticatedUserCounter)http handler 使用的也是 Prometheus 提供的 handler:
// Install adds the DefaultMetrics handler
func (m DefaultMetrics) Install(c *mux.PathRecorderMux) {register()
c.Handle(/metrics , prometheus.Handler())
}由上可以看到，原有的监控标标严重依赖 Prometheus 的特性，而新的框架设计将会对监控指标的定义、初始化、注册过程进行封装，即各组件不再直接使用 Prometheus，而是使用新的框架，尽管新的框架还是使用 Prometheus 来实现，但提供了更多个性化的设计。
新的实现：监控指示定义
在监控指标定义环节，新框架提供了新的指标参数结构体，以便于增加稳定性标识。
比如，曾经使用 Prometheus 定义一个计数器时会使用 prometheus.CounterOpts 结构体，如下所示：
var someMetricDefinition = prometheus.CounterOpts{
Name: some_metric ,
Help: some description ,
}新框架则提供了一个经过扩展的参数结构体 kubemetrics.CounterOpts，新增加了 StabilityLevel 和 DeprecatedVersion 等字段用于表示稳定性和弃用标示。
表示一个监控指标被废弃，可以如下定义：
var deprecatedMetricDefinition = kubemetrics.CounterOpts{
Name: some_deprecated_metric ,
Help: some description ,
StabilityLevel: kubemetrics.STABLE, // 自定义字段，稳定性标识
DeprecatedVersion: 1.15 , // 自定义字段，弃用标识
}表示一个 ALPHA 监控指标，可以如下定义：
var alphaMetricDefinition = kubemetrics.CounterOpts{
Name: some_alpha_metric ,
Help: some description ,
StabilityLevel: kubemetrics.ALPHA,
DeprecatedVersion: 1.15 , // 可选字段，标明将在哪个版本弃用
}与 Prometheus 一致，新框架对 4 种监控指标分别做了扩展：
CounterOpts
GaugeOpts
HistogramOpts
SummaryOpts
本节暂不对每种监控指标展开介绍，还是聚焦在阐述新框架的实现思路上。
新的实现：监控指标初始化
曾经，使用 Prometheus 来初始化监控指标（获取监控指标实例），将使用一系列的 prometheus.NewXXX() 方法，如下所示：
var someCounterVecMetric = prometheus.NewCounterVec(
someMetricDefinition, // 指标定义
[]string{ some-label , other-label}, // 指标的 label
}一方面，由于新的框架扩展了指标定义结构体，无法继续使用 prometheus.NewXXX() 方法，另一方面新框架也希望能在指标初始化时扩展自定义行为（比如处理定义环节加入的字段），所以新框架中也提供了类似的一系列方法。
使用新框架的方法来初始化实例示例如下：
var deprecatedMetric = kubemetrics.NewCounterVec(
deprecatedMetricDefinition, // 扩展的指标定义
[]string{ some-label , other-label},
}同样与 Prometheus 保持一致，新框架也提供了所有的初始化方法：
NewCounter() 和 NewCounterVec()
NewGauge() 和 NewGaugeVec()
NewHistogram() 和 NewHistogramVec()
NewSummary() 和 NewSummaryVec()
同样，本节暂不对每种初始化方法展开介绍，这部分内容留到后面的章节中。
新的实现：监控指标注册
曾经，使用 Prometheus 来注册一个监控指标实例时，实际上是注册到一个全局的注册表，如下所示：
prometheus.MustRegister(someCounterVecMetric)新框架中对注册也进行了封装，以便增加自定义的行为，比如废弃版本检查，注册逻辑伪代码如下：
import version k8s.io/apimachinery/pkg/version
type Registry struct {
promregistry *prometheus.Registry
KubeVersion version.Info
func (r *Registry) MustRegister(metric kubemetrics.Metric) { if metricutils.compare(metric.DeprecatedVersion).isLessThan(r.KubeVersion) { // 如果废弃版本比当前版本低，检查废弃规则，不满足则不再注册
// check if binary has deprecated metrics enabled otherwise
// no-op registration
return
} else if metricutils.compare(metric.DeprecatedVersion).isEqual(r.KubeVersion) { // 如果废弃版本与当前版本一致，则把弃用信息增加到指标的 HELP 信息中并记录 warning 日志
// append deprecated text to description
// emit warning in logs
// continue to actual registration
}
// 如果是 ALPHA 监控指标，增加相应的标识到 HELP 信息中
r.promregistry.MustRegister(metric.realMetric) // 最后还是使用 Prometheus 来完成注册
}使用新框架注册，如下所示：
kubemetrics.MustRegister(deprecatedMetric)
kubemetrics.MustRegister(alphaMetric)由上综述，可以看到在编程层面，既有的监控指标可以方便的迁移到新框架，如果监控指标没有个性化的需求，那么其行为与原 Prometheus 完全一致，如果有个性化的需求，通过简单的配置就可完成，具体的实现细节全部由新框架负责。
稳定性声明
当前版本（kubernetes 1.15 1.16）提供两个级别的稳定性，用来阐述每个监控指标的稳定性：
Alpha
Stable
需要额外提及的时，在当前的设计中并没有考虑 Beta 级别，新框架作者表示将来有需要时再添加，添加也会非常简单。
Alpha 级别的监控指标，基本上不提供任何稳定性的保证，它们可以随时被修改，而且新框架引入后，既有的监控指标都将标记为这个级别。
Stable 级别的监控指示，基本上可以保证“不再修改”，除非将来被废弃。这里所说的“不再修改”指以下三个内容不会修改：
监控指标本身不会被删除或重命名；
监控指标类型不会被修改；
监控指标的 lable 列表不会增加或减少；
针对 Stable 级别的监控指标，lable 列表不会改变，但 lable 值是可以改变的。比如，某个指标用于记录鉴权的次数，使用 result 作为 lable 进行区分，lable 值原来是 success 和 failure，是允许增加新的 lable 值的，比如增加一个 error（不是简单的鉴权失败，而是出现某种异常）。
比如，你之前得到的指标将会由：
authentication_attempts{result= success} 1345
authentication_attempts{result= failure} 100变成：
authentication_attempts{result= success} 1345
authentication_attempts{result= failure} 100
authentication_attempts{result= error} 1 // 增加新的 lable 值 一般来讲，这种变化对用户的冲击不会很大。
针对 Stable 级别的监控指标，删除或增加 lable 是不允许的，如果必须要这么做，需要先把当前的指标废弃，再提供一个新的监控指标。
对于用户来讲，新框架还提供了一个由用户显式的屏蔽某些监控指标的能力，默认情况下，所有的监控指标都会被注册并最终通过 API 提供给用户，但使用新框架后，用户可以通过相应组件的启动参数显式的关掉某些监控指标，比如：
--disable-metrics=somebrokenmetric,anothermetric稳定性保证
把一个监控指标标记为 Stable 意味着对广大用户做出了一个承诺，这跟 API 是一致的。所以将某个监控指标标记为 Stable 或者 废弃某个监控指标时，需要非常谨慎的 review。
然而，跟据 Kubernetes 社区的组织划分，各个组件分别有不同的 group (准确叫法是 SIG) 来负责相应的组件开发，各 group 的 reviewer 可能并不完全了解新框架所引入的这个理念，所以各 group 很有可能将来破坏之前做出的稳定性承诺。而每个相关监控指标的修改都由负责监控的 group 来 review，代价会非常大，而变得不可取。
针对这个问题，kubernetes 社区又提供了让人眼前一亮的方法，即引入新的一致性测试。即，生成一份现有的稳定性列表，并存放到某个由监控组管理的目录中，增加新的 CI 工作流收集最新的稳定性监控指标，二者对比，如果不一致，CI 会失败并拒绝合入，除非显式的修改稳定性列表。CI 可以保证当显式的修改稳定性列表时，必须经过监控组的批准。
弃用规则
每个 Stable 的监控指标，在决定要将其废弃后，可以在监控指标定义处显式的指定将要弃用的版本（DeprecatedVersion）。某个指标标记为废弃后不会马上被删除，需要留给用户一个适配的窗口，在接下来的某些版本中才会真正被删除。
被废弃的监控指标都会经历如下阶段（每个阶段代表一个 kubernetes minor 版本）：
Stable metric - Deprecated metric - Hidden metric - Deletion比如，某个监控指标在 1.16 版本进入 Stable 阶段，将在 1.17 版本弃用，那么在各版本其状态如下：
1.16（Stable metric）：可正常使用；
1.17（Deprecated metric）：标记为弃用，当前版本仍然可以用，但是用户需要准备适配；
1.18（Hidden metric）：默认不开启该监控指标，管理员可通过参数显式的启用该指标；
1.19（Deletion）：彻底删除，无法再使用；
弃用阶段
比如，某个监控指标将在 1.17 版本废弃，那么 1.17 版本（或更早的版本）开发时可以这样设置：
var someCounter = kubemetrics.CounterOpts{
Name: some_counter ,
Help: this counts things ,
StabilityLevel: kubemetrics.STABLE,
DeprecatedVersion: 1.17 , // this metric is deprecated when the Kubernetes version == 1.17
}使用 1.17 之前的版本，监控指标信息如下：
# HELP some_counter this counts things
# TYPE some_counter counter
some_counter 0那么用户在使用 1.17 版本时，将会看到相应的指标信息中出现弃用信息：
# HELP some_counter (Deprecated from 1.17) this counts things
# TYPE some_counter counter
some_counter 0此外，当监控指标被标记为废弃后，虽然能正常使用，但是在相应的组件日志中可以看到告警日志。
隐藏阶段
当监控指标被弃用的下一个版本，即 DeprecatedVersion == current_kubernetes_version – 1 时，该监控指标默认会被隐藏：即不会自动注册。
被隐藏的指标可以通过相应组件的启动参数（–enable-hidden-metrics=really_deprecated_metric）来显式的启用。
如果用户忘记在上个版本中做好适配，仍然可以在本版本中继续使用，这无疑给用户延长了适配窗口。
另外，需要特别提及的几点是：
被标记为弃用的监控指标仍然尊守之前的稳定性约定，除了增加弃用标记外不会修改指标内容；
本弃用规则是针对 Stable 监控指标的，不对 Alpha 监控指标做强制要求。
处于 Alpha 阶段的监控指标也可以标记废弃版本号，它可以帮助使用 Alpha 监控指标的用户准确的了解某个监控指标何时会被删除，仅用于说明，被删除前可以不遵循弃用规则；
读到这里，这篇“Kubernetes 的稳定性框架是什么”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注丸趣 TV 行业资讯频道。
