Kubernetes的穩定性框架是什么

本文小編為大家詳細介紹“Kubernetes的穩定性框架是什么”，內容詳細，步驟清晰，細節處理妥當，希望這篇“Kubernetes的穩定性框架是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

引言

使用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的穩定性框架是什么”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。