在微服務架構下，K8S集群中往往部署了多套服務，這也意味著不同的團隊、不同的角色、不同的服務會在同一集群中，不同業務的資料需要在不同的空間進行管理和檢視。
在傳統的主機環境中，在不同主機上部署 datakit 時，通過配置不同的工作空間 token 可以很容易地實現這一點，但在使用 daemonset 部署的 k8s 環境中，同乙個 daemonset 無法靈活地配置多套 datakit，配置變更時需要重啟 datakit，datakit 達到一定規模後的影響非常大。
因此，Observation Cloud 提供的 Dataway Sinker 功能是解決上述問題的最佳方法。
從上圖可以看出，該解決方案最重要的部分是資料標籤管理。 資料解除安裝是否符合預期、準確和有用，取決於標籤的正確使用和規劃管理。 標籤的管理和使用恰好是觀測雲平台的核心能力之一。
有關如何標記的更多資訊，請參閱觀測雲中標記的最佳實踐，此處不再贅述。
除此之外，會審還支援以下屬性：
觀測雲內建了自定義鍵，例如，所有通用資料分類的類別，其值可以是對應資料分類的“名稱”列（例如，時間序列是度量，物件是物件等）。
物件標籤屬性以及 K8S 集群的開箱即用屬性，例如：namespacecontainer_name等。
下面將演示如何使用資料路沉降器功能解除安裝和管理資料。
在本文中，我們將根據通用業務屬性 namespace 將資料劃分為工作區。
作為先決條件，Observation Cloud DataKit 收集器已部署在集群中。
在測試集群中，有多個命名空間，如下圖所示
此外，我們使用觀測雲資料kit來監控K8S集群的指標，但所有的監控指標都在乙個工作空間OBS中，如下圖所示
預期效果是根據不同的命名空間將監視資料解除安裝到不同的工作區，例如：namespace=datakit所有資料都將解除安裝到 Observation Cloud 資料工具包工作區。
第 1 步：安裝 DataWay
對於 SaaS 使用者，他們可以在本地部署乙個專用於解除安裝的 DataWay（K8S 集群），然後將資料傳送到 OpenWay。
1）參考DataWay安裝文件安裝DataWay;
2） 修改dataway.yaml新增以下與沉降器相關的配置環境變數;
- 名稱：DW Secret Token 開啟資料分發功能後，用於與 DataKit 聯動，注意需要將 32 位字串值：新增到 TKN 中"tkn_yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"- 名稱：DW Cascaded 開啟資料分發功能後，SaaS使用者使用級聯來鏈結價值："on"- 名稱：DW Sinker File Path mountedJSON 檔案位址值："/usr/local/cloudcare/dataflux/dataway/sinker.json"- 名稱：DW 遠端主機 配置級聯位址值：""
這裡你使用檔案模式來配置分流規則，配置也支援etcd，具體配置請參考資料路配置。3） 部署 DataWay。
第 2 步：修改分流規則
建立檔案sinker.json，填寫以下資訊，並將檔案掛載到 DataWay 容器中。
匹配規則 ]，對應於工作區的 OpenWay 位址和令牌"url": "?token=tkn_cb1a9a53fcb04436a4adab6435327fca" }," ],"url": "?token=tkn_c6e8ae1bbfa2489aba843cc56baf3c66" }," ],"url": "?token=tkn_1618f90ef13b482d9f682f30f7118d2f" }步驟三：修改DataKit配置1）修改datakit解除安裝環境變數的配置;
- 名稱：env dataway 位址和秘密令牌值： -name： env sinker 全域性客戶金鑰 指定 offload 的鍵值： namespace - name： env dataway enable sinker 啟用 sinker 值："true"2） 重新部署資料包。
只有 DataKit 工作區中的資料具有 DataKit 的命名空間。
只有 utils 工作區中將命名空間作為 utils 的資料可用。
OBS工作空間中沒有utils和datakit資料。
在這一點上，轉移是成功的。
除了上述示例之外，您還可以利用 DataKit 內建的自定義鍵，這些鍵通常不會出現在收集的資料中，但 DataKit 可以使用這些鍵對資料進行分組。 如果需要對這些鍵維度進行分類，可以將它們新增到全域性自定義鍵列表中（預設情況下不配置這些鍵）。 我們可以使用一些內建的自定義鍵來實現資料解除安裝。 具體流量分配規則請參見內建自定義金鑰流量分配。