Kubernetes 請求併發控制與數據一致性(含ResourceVersion、Update、Patch簡析)

      在大型分佈式系統中,定會存在大量併發寫入的場景。在這種場景下如何進行更好的併發控制,即在多個任務同時存取數據時保證數據的一致性,成爲分佈式系統必須解決的問題。

      悲觀併發控制和樂觀併發控制是併發控制中採用的主要技術手段,對於不同的業務場景,應該選擇不同的控制方法。

悲觀鎖

      悲觀併發控制(又名“悲觀鎖”,Pessimistic Concurrency Control,縮寫“PCC”)是一種併發控制的方法。它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作讀某行數據應用了鎖,那只有當這個事務把鎖釋放,其他事務才能夠執行與該鎖衝突的操作。

     在悲觀鎖的場景下,假設用戶A和B要修改同一個文件,A在鎖定文件並且修改的過程中,B是無法修改這個文件的,只有等到A修改完成,並且釋放鎖以後,B纔可以獲取鎖,然後修改文件。由此可以看出,悲觀鎖對併發的控制持悲觀態度,它在進行任何修改前,首先會爲其加鎖,確保整個修改過程中不會出現衝突,從而有效的保證數據一致性。但這樣的機制同時降低了系統的併發性,尤其是兩個同時修改的對象本身不存在衝突的情況。同時也可能在競爭鎖的時候出現死鎖,所以現在很多的系統例如Kubernetes採用了樂觀併發的控制方法。

樂觀鎖

     樂觀併發控制(又名“樂觀鎖”,Optimistic Concurrency Control,縮寫“OCC”)是一種併發控制的方法。它假設多用戶併發的事務在處理時不會彼此影響,各事務能夠在不請求鎖的情況下處理各自的數據。在提交數據更新之前,每個事務會先檢查在該事務讀取數據後,有沒有其他事務又修改了該數據。如果其他事務有更新的話,正在提交的事務會進行回滾。

     相對於悲觀鎖對鎖的提前控制,樂觀鎖相信請求之間出現衝突的概率是比較小的,在讀取及更改的過程中都是不加鎖的,只有在最後提交更新時纔會檢測衝突,因此在高併發量的系統中佔有絕對優勢。同樣假設用戶A和B要修改同一個文件,A和B會先將文件獲取到本地,然後進行修改。如果A已經修改好並且將數據提交,此時B再提交,服務器端會告知B文件已經被修改,返回衝突錯誤。此時衝突必須由B來解決,可以將文件重新獲取回來,再一次修改後提交。

     樂觀鎖通常通過增加一個資源版本字段,來判斷請求是否衝突。初始化時指定一個版本值,每次讀取數據時將版本號一同讀出,每次更新數據,同時也對版本號進行更新。當服務器端收到數據時,將數據中的版本號與服務器端的做對比,如果不一致,則說明數據已經被修改,返回衝突錯誤。

Kubernetes中的併發控制

     在Kubernetes集羣中,外部用戶及內部組件頻繁的數據更新操作,導致系統的數據併發讀寫量非常大。假設採用悲觀並行的控制方法,將嚴重損耗集羣性能,因此Kubernetes採用樂觀並行的控制方法。Kubernetes通過定義資源版本字段實現了樂觀併發控制,資源版本(ResourceVersion)字段包含在Kubernetes對象的元數據(Metadata)中。這個字符串格式的字段標識了對象的內部版本號,其取值來自etcd的modifiedindex,且當對象被修改時,該字段將隨之被修改。值得注意的是該字段由服務端維護,不建議在客戶端進行修改。

type ObjectMeta struct {
    ......

    // An opaque value that represents the internal version of this object that can
    // be used by clients to determine when objects have changed. May be used for optimistic
    // concurrency, change detection, and the watch operation on a resource or set of resources.
    // Clients must treat these values as opaque and passed unmodified back to the server.
    // They may only be valid for a particular resource or set of resources.
    //
    // Populated by the system.
    // Read-only.
    // Value must be treated as opaque by clients and .
    // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#concurrency-control-and-consistency
    // +optional
    ResourceVersion string
    
    ......
}

      Kube-Apiserver可以通過該字段判斷對象是否已經被修改。當包含ResourceVersion的更新請求到達Apiserver,服務器端將對比請求數據與服務器中數據的資源版本號,如果不一致,則表明在本次更新提交時,服務端對象已被修改,此時Apiserver將返回衝突錯誤(409),客戶端需重新獲取服務端數據,重新修改後再次提交到服務器端。上述並行控制方法可防止如下的data race:

Client #1: GET Foo
Client #2: GET Foo

Client #1: Set Foo.Bar = "one" 
Client #1: PUT Foo 

Client #2: Set Foo.Baz = "two"
Client #2: PUT Foo

當未採用併發控制時,假設發生如上請求序列,兩個客戶端同時從服務端獲取同一對象Foo(含有Bar、Baz兩個字段),Client#1先將Bar字段置成one,其後Client#2對Baz字段賦值的更新請求到服務端時,將覆蓋Client#1對Bar的修改。反之在對象中添加資源版本字段,同樣的請求序列將如下:

Client #1: GET Foo  //初始Foo.ResourceVersion=1
Client #2: GET Foo  //初始Foo.ResourceVersion=1

Client #1: Set Foo.Bar = "one" 
Client #1: PUT Foo  //更新Foo.ResourceVersion=2

Client #2: Set Foo.Baz = "two"
Client #2: PUT Foo  //返回409衝突

Client#1更新對象後資源版本號將改變,Client#2在更新提交時將返回衝突錯誤(409),此時Client#2必須在本地重新獲取數據,更新後再提交到服務端。

      假設更新請求的對象中未設置ResourceVersion值,Kubernetes將會根據硬改寫策略(可配置)決定是否進行硬更新。如果配置爲可硬改寫,則數據將直接更新並存入Etcd,反之則返回錯誤,提示用戶必須指定ResourceVersion。

 Kubernetes的Update和Patch

       Kubernetes實現了Update和Patch兩個對象更新的方法,兩者提供不同的更新操作方式,但衝突判斷機制是相同的。

Update

       對於Update,客戶端更新請求中包含的是整個obj對象,服務器端將對比該請求中的obj對象和服務器端最新obj對象的ResourceVersion值。如果相等,則表明未發生衝突,將成功更新整個對象。反之若不相等則返回409衝突錯誤,Kube-Apiserver中衝突判斷的代碼片段如下。

 e.Storage.GuaranteedUpdate(ctx, key...) (runtime.Object, *uint64, error) {
		// If AllowUnconditionalUpdate() is true and the object specified by
		// the user does not have a resource version, then we populate it with
		// the latest version. Else, we check that the version specified by
		// the user matches the version of latest storage object.
		resourceVersion, err := e.Storage.Versioner().ObjectResourceVersion(obj)
		if err != nil {
			return nil, nil, err
		}
                version, err := e.Storage.Versioner().ObjectResourceVersion(existing)
		doUnconditionalUpdate := resourceVersion == 0 && e.UpdateStrategy.AllowUnconditionalUpdate()
                
		if doUnconditionalUpdate {
			// Update the object's resource version to match the latest
			// storage object's resource version.
			err = e.Storage.Versioner().UpdateObject(obj, res.ResourceVersion)
			if err != nil {
				return nil, nil, err
			}
		} else {
			// Check if the object's resource version matches the latest
			// resource version.
			......
			if resourceVersion != version {
				return nil, nil, kubeerr.NewConflict(qualifiedResource, name, fmt.Errorf(OptimisticLockErrorMsg))
			}
		}
       ......
	return out, creating, nil
}

基本流程爲:

1.獲取當前更新請求中obj對象的ResourceVersion值,及服務器端最新obj對象(existing)的ResourceVersion值

2.如果當前更新請求中obj對象的ResourceVersion值等於0,即客戶端未設置該值,則判斷是否要硬改寫(AllowUnconditionalUpdate),如配置爲硬改寫策略,將直接更新obj對象。

3.如果當前更新請求中obj對象的ResourceVersion值不等於0,則判斷兩個ResourceVersion值是否一致,不一致返回衝突錯誤(OptimisticLockErrorMsg)。

Patch

       相比Update請求包含整個obj對象,Patch請求實現了更細粒度的對象更新操作,其請求中只包含需要更新的字段。例如要更新pod中container的鏡像,可使用如下命令:

kubectl patch pod my-pod -p '{"spec":{"containers":[{"name":"my-container","image":"new-image"}]}}'

服務器端只收到以上的patch信息,然後通過如下代碼將該patch更新到Etcd中。

func (p *patcher) patchResource(ctx context.Context) (runtime.Object, error) {
	p.namespace = request.NamespaceValue(ctx)
	switch p.patchType {
	case types.JSONPatchType, types.MergePatchType:
		p.mechanism = &jsonPatcher{patcher: p}
	case types.StrategicMergePatchType:
		schemaReferenceObj, err := p.unsafeConvertor.ConvertToVersion(p.restPatcher.New(), p.kind.GroupVersion())
		if err != nil {
			return nil, err
		}
		p.mechanism = &smpPatcher{patcher: p, schemaReferenceObj: schemaReferenceObj}
	default:
		return nil, fmt.Errorf("%v: unimplemented patch type", p.patchType)
	}
	p.updatedObjectInfo = rest.DefaultUpdatedObjectInfo(nil, p.applyPatch, p.applyAdmission)
	return finishRequest(p.timeout, func() (runtime.Object, error) {
		updateObject, _, updateErr := p.restPatcher.Update(ctx, p.name, p.updatedObjectInfo, p.createValidation, p.updateValidation, false, p.options)
		return updateObject, updateErr
	})
}

流程爲:

1.首先判斷patch類型,根據類型選擇相應的mechanism 

2.利用DefaultUpdatedObjectInfo方法將applyPatch(應用Patch的方法)添加到admission chain的頭部。

3.最終還是調用上述Update方法執行更新操作。

       在步驟2中將applyPatch方法掛到admission chain的頭部,與admission行爲相似,applyPatch方法會將patch應用到最新獲取的服務器端obj上,生成一個已更新的obj,再對該obj繼續執行admission chain中的Admit與Validate。最終調用的還是update方法,因此衝突檢測的機制與上述Update方法完全一致。

        相比Update,Patch的主要優勢在於客戶端不必提供全量的obj對象信息。客戶端只需以patch的方式提交要修改的字段信息,服務器端會將該patch數據應用到最新獲取的obj中。省略了Client端獲取、修改再提交全量obj的步驟,降低了數據被修改的風險,更大大減小了衝突概率。 由於Patch方法在傳輸效率及衝突概率上都佔有絕對優勢,目前Kubernetes中幾乎所有更新操作都採用了Patch方法,我們在編寫代碼時也應該注意使用Patch方法。

不同Patch類型細節的區別可參考:

https://support.huaweicloud.com/api-cci/cci_02_0070.html

附:

     ResourceVersion字段在Kubernetes中除了用在上述併發控制機制外,還用在Kubernetes的list-watch機制中。Client端的list-watch分爲兩個步驟,先list取回所有對象,再以增量的方式watch後續對象。Client端在list取回所有對象後,將會把最新對象的ResourceVersion作爲下一步watch操作的起點參數,也即Kube-Apiserver以收到的ResourceVersion爲起始點返回後續數據,保證了list-watch中數據的連續性與完整性。

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章