雲端服務中的容器成本分配

我們都知道在雲端中計算每一個容器的費用在現行三大公有雲對雲端資源貼標籤(tags/labels)方式是行不通的。因為這一個雲端資源(例如VM instance)可能同一時間運作了好幾個容器，並且每個容器可能是運行不同的Application。這些Applications也可能分屬不同的成本中心。

這篇Whitepaper是在講述 FinOps 團隊在處理雲端中的容器化服務之前應該了解的主要問題、挑戰和注意事項。文件中也提及了容器一些術語與概念。還從 FinOps 核心實踐的角度探討和解決 Kubernetes(以下簡稱K8S) 和容器的成本問題。核心實踐如下:

Inform(告知):了解公有雲平台(以下簡稱CSP)如何對其 K8S 服務收費。 了解為什麼在使用 K8S的環境中執行chargeback和成本分配具有挑戰性。

Optimize(優化):尋找持續優化 K8S cluster和 Pod 的方法。

Operate(營運):決定容器成本分配的方法並制定管理容器支出的政策，並使用整合工具協助管理容器成本以及傳統的雲端費用支出。

從FinOps的角度來看K8S的成本

為什麼每一個容器的成本費用計算是具有挑戰的?因為容器，說白話一點它只是另一種虛擬化 — 大台VM中裡面小型VM，虛擬化的虛擬化。但我們可以用FinOps的實踐來處理這些挑戰。

K8S的相關的術語與概念

由於三大公有雲(GCP/AWS/Azure)對其K8S有著不同的產品於服務名稱(，並有各自的術語。為簡單起見 — — 除了在專門討論K8S 時 — — 我們指的是“容器 — containers”和“伺服器 — server instances”，對應 K8S則指的是“pod”和“nodes”。

容器，簡單的來說就是把我們運作Application相關所需包含環境通通打包成一個 可以佈署的 image。我們可以把它想成它是比傳統虛擬機的大小(可能是幾十GB到幾百GB都有可能)到小很多的小VM(從幾十MB到1G都有可能)。K8S 等容器編排工具(Container orchestration)可幫助工程師以可管理和可維護的方式將容器部署到伺服器。

以下是一些主要術語會在本文中不斷出現的:

Image: 一種容器的模板(template)，裡面包含需要運作的軟體與相關library(靜態的)。

Container: 一個container image的instance； 可以同時運行同一個image的多個副本(動態的)。

Server instance/ node : 虛擬機，像是AWS EC2。地端機房可能是實體機。

Pod: K8S的術語，一種邏輯上的概念。Pod 由一群containers組成，並將它們視為可以在cluster上調度和擴展的單一個resource block。

Container orchestration: 一種容器的編排器，主要是管理node(server instance)的cluster，並維護containers/pod 的生命週期。 容器編排器的一部分是調度程序與cluster內資源，它調度containers/pod 在 node 上的運作。這一類的容器編排調度平台有好幾種，K8S是目前市面上最流行的。在三大公有雲K8S的產品名稱各有不同，GCP稱GKE ,AWS稱EKS，Azure稱AKS。有關K8S的的前世今生可參考在youtube上的介紹。

Cluster : 一群虛擬機(service instance / node)，由Container orchestration來管理。

Namespace : 一樣是K8S的術語，也是一種邏輯上的概念。一種在實際cluster上的邏輯上cluster。它可以把 pods/containers用不同的namespace分隔開來。

Pod labels: 這是一個key/value pairs，可以識別對k8s使用者有意義且相關的objects屬性，但不是直接說明我們正在用的整套系統或服務。 每個objects都可以定義一組key/value labels。 對於特定的object，每個 Key 必須是唯一值。 例如，如果我們要用namesapce來分群時，就會用到Pod labels。

我們來看一下在K8S的基本單位由大到小分別是

containers →Pod →Namespace →Clusters

下圖是一個基本的 K8S cluster示意圖

告知(inform): Container/K8S的費用是怎麼發生的?

在這一階段我們要做的是產生成本報告，以確定團隊正在運作的cluster上的單一個容器的成本。 這是建立容器費用支出可見性的第一步也是最重要的一步。

容器的成本分配哪裡不一樣?

CSP是用k8s cluster中的每一個VM來跟我們收費。 這些費用是在將容器部署到cluster時產生的，因為它們消耗了cluster的一些資源容量。 cluster裡有新機器產生就開始算錢。 這類似我們在雲端平台中開起一個VM。 無論我們是否正在用它，開機就開始算錢

為了分配在cluster上運行的容器的單一成本，我們需要某種方法來決定每一個容器消耗了多少底層服務器的資源。 我們還需要知道這個cluster還啟用哪些其他的雲端資源。 其中可能包括management node、用於追蹤cluster狀態的data store、軟體授權、備份和潛在的DR cost。 這些成本都是運作cluster的一部分，我們都要考量在我們的成本分配策略中。

容器的功能帶來了成本的複雜性

Container orchestration services對工程師簡化了管理容器的作業包含:

• 根據資源使用率需求來調度啟動或移除容器
• 以各種細緻度指標管理網路的擴展和連接
• Autoscaling和自動建立和刪除node以適應不斷變化的工作負載

CSP都提供的虛擬機 (VM) 服務來運行K8S，或者使用他們的本地產品來管理 Kubernetes cluster。 例如：

• AWS — EKS(Elastic Kubernetes Service)
• GCP — GKE(Google Kubernetes Engine)
• Azure — AKS(Azure Kubernetes Service)
• IBM Cloud : IBM Cloud Kubernetes Service
• Oracle Cloud Infrastructure : Infrastructure: Oracle Container Engine for Kubernetes
• 阿里雲: ACK(Container Service for Kubernetes)

每個CSP都提供他們自己不同等級的支援和服務，包括幫我們搬到他們的雲端中。 所有這些服務都與其他雲端服務一樣：pay-as-you-go。 這樣的計費方式很方便，但一個k8s cluster可以運作自多個團隊的多個專案的能力可能讓我們的雲端財務管理和成本分配成為挑戰。

託管 的K8S 服務的計費方法是在AWS是按cluster每小時收費，加上cluster消耗的額外底層資源。而在GCP/Azure可以以每台VM使用的時間計費。 無論是哪一種，這使得容器的成本管理具有特別的挑戰性，因為我們無法以container level來看這些container正在消耗那些雲端資源。

為什麼更難對 K8S的成本進行計費和產生費用報告？

與一般的雲端環境相比，在容器環境中分配成本面臨更多挑戰。 在一般的雲端環境中，FinOps 團隊可以一對一地的標記非容器資源，允許成本報告工具很容易的將服務對映到成本中心。 因為哪個Application/services/workload用了哪些服務使用了tags/labels可以很容易辨識出來(例如下圖)。

但這種方法到了K8S內的container就行不通了。 大多數 K8S Cluster是一個共同服務，多個團隊的多個application可能運作在同一個K8s Cluster中。 這意味著特定的容器沒有直接成本； 它們是一群容器聚集在一起，以產生每組工作的成本。 沒有一個簡單的方法將雲端費用對映到特定容器的使用情況。當然，我們也可以每個Application都啟用一個Cluster，但就可能會有資源浪費的情況發生。另外還會增加管理上的困難。

容器部署在 K8S Cluster中就會消耗雲端資源（例如compute）。 挑戰在於，在每個cluster中，我們通常有多個團隊消耗部分底層資源。

更麻煩的是，容器化環境比非容器化環境更具動態性，容器的平均壽命可能只有一天甚至更短，而 VM 的使用時間通常要長得多。 有鑑於K8S Scheduler的動態特性，K8S可以跨instance type(不同大小/類型的VM)、zone甚至region重新調度workload，意思是容器可能在任何地方跑來跑去的，甚至現在可以將運作延伸到我們的地端機房。 這使得成本管理更加複雜，因為我們的計費必須跟上快速變化的步伐。

共同追踪共享式的cluster和cluster外的雲端資源成本

下圖是一個三種Application使用K8S與其他雲端資源的效率評估。灰色的部分就是我們在每一台底層的VM中沒有用到的資源，就是浪費的部分。而且三種Application在每一台VM中使用的資源大小都不一定。

那麼，我們如何解開這種複雜性並改進我們管理容器成本的方式呢？ 首先，讓我們快速回顧一下我們的團隊是如何為 K8S的使用計費的。

管理容器費用支出的成本分配實踐和政策範例

"在雲端財務管理中，可預測性就是一切。” 雲端財務管理的老手會將成本控制在預算範圍內，並儘量減少非預期性的支出。 習慣於地端機房成本的團隊知道它們的費用是固定的且容易預測。 而雲端服務改變了這種方式，容器化讓成本計算更進一步複雜化。

K8S中的container classes

K8S這種Cluster orchestration方案可以讓我們在稱為QoS(Quality of Service) classes 的schedule containers上設置不同的保證資源。意思是，我們可以對不同類別的容器設定最小資源的給予。例如，這一類型的容器最少可以用多少vCPU/memory。

另外是要處理爆大量的工作處理，當底層node(server instance)上的容量還有剩時，可以讓 pod 使用比一開始要求使用的最低資源再往上要求更多。 像這種突然爆大量的工作處理，使用On-Deamnd / RI都不具經濟效益。大多的CSP可以使用Spot/preemptible這種高CP值的node來處理。

而在非生產環境的任一環境運作K8S時也可以使用Spot/preemptible node。 當container orchestrator為每個node(server instance)分配具有不同資源需求的Pod 時(保證的最小容量)，我們的node使用率就會更高。 我們可以將基本數量的資源分配給長時間運作且資源需求是固定的 pod(這時底層的VM可以使用RI)，以及一些可能使用剩餘服務器資源的臨時增加的 pod，以及一些會使用Spot/preemptible node的 pod。 以上這些是一些K8S的基礎知識，接下來我們開始探討一些策略來開始容器成本分配。 方法如下:

• 在開發、維運和財務之間建立良好的協同作業，用以實現高度準確預測的預算。 使用工具能自動化消除人為錯誤並使用具有更高度雲端財務準確性的容器化服務
• 使用資源或應用程式定義的聚合：規定每個團隊不能亂搞，建立一堆獨立的專案，而是使用定義好和專用的cluster
• 將團隊分配到Namespace有助於提供準確的方法來向各個專案和團隊收取容器費用
• 使用container cluster labels將標記雲端資源進入到更細緻的層次

在任何雲端財務管理策略中，靈活地了解成本可以推生出"問責制"。 我們的目標是：幫助K8S的使用者透過使用的services和container workload了解他們的容器成本產生的因素。 將這兩個結合起來有助於團隊確定他們的TCO(total cost ownership)。

更深入的觀看特定的容器化成本

另一種方式，這種建議來自Google Cloud Billing Product Manager — Debo Aderibigbe將容器的成本分拆成以下四種(如下圖)

• Billing Hierarchy:在GCP就是Organizations, folders, projects，在其他CSP就是 Linked Accounts, Tags, Subscriptions等等。
• Resources: vCPU/RAM/GPU/TPU/Load Balancers/Persistent Disk/Custom Machines/Network Egress
• Namespaces:特定的標籤來隔離不同類型的containers
• Labels:團隊/成本中心/程式名稱/環境等等

我們使用的標籤越深入並仔細，用戶可以提高他們為團隊審計成本、分配成本、優化超支的成本、模擬預算或使工作負載的成本符合配額或低於預算上限的準確性。

LiveRamp的故事: 如何解決 GKE 上的容器化成本

LiveRamp 團隊將地端機房轉移到GCP，並擴大了容器服務（和成本），這引來了財務部門的注意。他們在技術上是成功的，但一個月後，預算超支。他們需要一種方法來解釋發生了什麼事。

當時，LiveRamp 錯過進行 FinOps 文化的轉變，開發人員沒有意識到他們在雲端運算中的一項新工作是雲端的財務管理。為了增加這種理解，以容器為中心的 FinOps 原則以不同的方式幫助合理化雲端成本和運營決策。他們必須克服由於每個團隊都有各自的雲端帳號和設置而出現的挑戰。

經過大量以 FinOps 為重點的工作後，新的政策建立起來，例如為大型cluster強制命名Namespace以及更好的tagging和labeling以提高分配的準確性，這都是 FinOps 的關鍵實踐。它還有助於找到適合團隊在管理雲端財務管理方面需要的工具，例如Cloudability、CloudHealth、CSP的原生工具等。

強化成本分配需要有一致性的標記與namespace策略

如果有實施了一致且強大的標籤和namespace策略，接下來就可以想如何分配cluster成本。除非我們使用 GKE，否則我們無法很容易的檢查cluster中哪些group正在燒錢。

一種常見的方法是查看每個group（label、namespace等）消耗的資源比例，並使用它來將cluster成本分配給這些group。例如，如cluster中有五個namespace，每個namespace消耗 20% 的cluster resource，就將cluster總成本的 20% 平均分配給每個nsmaspace。

不過現實世界中，任何環境都不會是這麼簡單或直接，不然就不需要寫這篇文章了。另一層複雜性是回答如何確定clutser resource利用率的問題？用CPU、memory或兩者的組合嗎？還是resource requests或Actual usage？

不論是哪種都有好有壞。如果是resource requests(計畫中要開啟的資源):

好處是: 所有成本都可以找到家(哪個部門花錢的) ，鼓勵使用團隊只開啟他們需要的資源。 這有工具可以提供協助。（例如vertical pod autoscaler）

壞處是:一些組織尚未使用resource request fields可能還會讓開出來的資源不夠用。

如果是Actual usage(因應實際使用時所開啟的資源):

好處是:每一個團隊或application只需付他們在哪一段時間用到的實際用量。

壞處是:哪誰來付其餘的費用（沒在用cluster resource時）？ 怎麼處理overprovisioning？ 可以鼓勵團隊provision更多資源以防流量來了不夠用，但不是為此來付費 。可能會設定一個不切實際的 100% 使用率目標。

超越用Core Cluster成本的計算

我們很常容易將容器的成本計算只算k8s cluster的compute node，但卻忽略運行整個K8S cluster時的周邊成本。以下是其他也要計算的成本:

1.管理/Cluster運作成本

要把CSP為了管理cluster收取的成本或運行 container orchestrator nodes所產生的成本。 WAF/Load Balancing(以下簡稱LB)等周邊服務也會影響在cluster上運行工作負載的總體成本。

2. 儲存成本

即使容器內運作的服務我們可以視為臨時性存儲，它也算消耗存儲空間。 但是，在容器之外，cluster中的每個node也掛載了Disk，以及用於操作production cluster的任何備份或產生要存儲的服務，如NFS。

3.軟體授權費

一般來說有三種。一個是node的OS費用，但絕大多數的使用者都是使用免費或是由CSP提供的(這可能就要錢)。不過也可以BYOL(bring your own license)。另一個是在node(OS內)運作的其他軟體，最後是在容器本身軟體。

4. 可觀察性(監控)

通常，CSP會提供Cluster各種指標與日誌的可視化、監控和告警。而這些監控資料我們也可能會使用第三方第的SaaS 解決方案，如（Splunk Cloud、Sumo Logic、Datadog、SignalFx 等）。或者是用open source自建這一類的服務，這比較好算，把有多少工程師每一個人每周要花多少時間維護的人力費用給算出來，當然還有架構這一套服務所有的虛擬機費用通通加起來。

5. 資安

現在的CSP在它們的雲端平台提供了一大堆的資安功能，用這些功能絕大多數都不是免費的。

常理上我們都想將來自上述所有來源的每一塊錢都包含在我們的成本分配策略中，但就像所有 FinOps 一樣，我們應該先從容易的開始進行並隨著時間的推移不斷發展我們的實踐（Crawl、Walk、Run）。 一次實施所有這些成本分配項目可能會搞死所有人，並且隨著我們開發分配成本的流程和對組織內的團隊的成本分配的認知，分而治之的方法更有可能更有效。

解決靜態與動態時的容器成本

容器化成本會分成兩種主要型態: 靜態的(static)成本與動態成本(runtime)

靜態的成本

這是指我們在成本計算時很容易算出來的，但建立這些解決方案時我們需要考慮這些方案的品質。以及部署時它們時會如何影響 CPU/Network/Storage。 靜態的容器成本可以通過stateless 和stateful container進一步定義：這些stateless example包括：

• Web servers(包含靜態資源): 例如Apache, Nginx, IIS
• Application servers, stateless applications: 例如Tomcat, NodeJS, Symphony, .NET
• 微服務: 例如Spring Boot, Play, Quarkus
• 相關工具: 例如Maven, Gradle

具有stateful application特性的Application server

這種Application會將user sessions儲存起來。處理這種情況的兩種方法是使用具有session affinity 的LB以確保user始終存取同一個container instance，或者使用所有container instance共享的 external session persistence機制(例如存放在Redis)。

還有一些組件提供native clustering，例如portals或persistence layer caches。 通常最好讓本機軟體來管理instance之間的狀態同步。 將instance放在同一個網段(例如同一個Zone)上可以讓它們以快速、安全的方式相互通訊。

資料庫

資料庫通常需要將資料保存在filesystem。 最佳實踐是只將database engine容器化，同時將其資料保存在這個容器底層的node中。 這可以使用host volume來完成，例如：$ docker run -dit -v /var/myapp/data:/var/lib/postgresql/data postgres.

K8S 也可以用作託管資料庫服務的替代方案。 例如，專用於 MongoDB 或 Elasticsearch 的cluster可以提供類似於全託管服務，而成本只是其中的一小部分。

使用共享式的file systesm的Application

CMS(Content Management Systems)使用filesystems來儲存 PDF/圖檔/office檔案等之類的文件。這也可以使用通常安裝到CMS的host volume或者使用CSP提供的NAS服務來完成，因此 CMS 的多個instance可以同時存取文件。

動態的成本

大多數人認為容器的運行時成本是靜態的。 你如何運行你的容器將影響你的成本底線。 CSP的這些成本範例包括：

• 在估計雲端費用時，網路流量經常被忽視或低估。
• 我們經常忘記對clusters內的容器做housekeeping。一旦我們將應用程式或資料放到雲端中，它們就會繼續燒錢，直到我們刪除它們為止。
• Comput的費用不是基於Usage。
• 在雲端中Polling data是一項燒錢的作法，並且會產生transaction fee。很快，成本可能會根據polling的次數而增加。
• DOS attack或spider等形式的攻擊流量可能會以意想不到的方式增加流量。處理此類沒有預期到的費用的最佳方式是審核應用程式的安全性並提供驗證碼等控制措施，如CAPTCHAs。
• 管理：定期監控應用程式的運行狀況及其計費。定期檢查雲端中的內容是否仍需要在雲端中運作。定期監控應用程式的負載量。調整部署的大小以匹配負載。

在生產環境中考量容器的省錢

與運行stateless和fault-tolerant Application的on-demand價格相比，容器化部署可以實現高達 90% 的折扣。 容器應該是stateless並且在容器內的application是能夠graceful startup / shutdown。

憑藉這些能力，serverless的部署可能變得更具吸引力，因為這些部署僅在運作時計費。 另一種思考方式是，Application在處於休眠狀態時不收取任何費用。 這樣只將內容部署到serverless API 是不夠的，因為我們的程式效能可能會變差。 cold start就成為Application的剋星。

不過，新的可能正在發生，batch serverless loads已經能在雲端平台中運作，例如 Apache Beam。 一旦啟用，IT 的許多新領域將能夠參與省錢，遵循複雜的data-parallel processing pipelines，支援各家CSP engines或runners執行。

優化階段:在K8S中建立成本效率

與Inform(告知)階段一樣，容器世界中的優化階段是針對雲端平台的原始 FinOps 實踐的直接適應，但在應用時要考慮到容器的複雜性。

會有人說，容器化解決了rightsizing的問題。 在同一node(server instance)上運行更多工作負載似乎更具成本效益。 但正如我們到目前為止所看到的，衡量哪些團隊或專案產生了這些成本，或者我們是否從cluster中有省道錢，這其實是一項複雜的任務。哪 FinOps 實踐必須如何演變才能成功呢?

一旦我們可以對我們的K8S進行chargeback，下一步就是尋找優化 K8S環境以降低成本的方法。 FinOps 成員可以通過幾個步驟與 DevOps/SRE 團隊合作，以確保 K8S成本不會加速失控。

Pod/ Container Rightsizing

確保容器要的資源數量是恰當的。由於要太少服務可能跑不起來，因此在為容器配置的requtes或limits與其真正需要的資源之間通常存在一些buffer。

當這個buffer大於必要的資源時，就有機會省錢。 VPA(Vertical Pod Autoscaler)是一個開源專案的範例，它將通過根據容器的使用量自動調整request和limits配置，從而節省資源和成本，同時減少overhead。

HPA(Horizo​​ntal Pod Autoscaler) 主要是在scale out/in，而不是針對工作負載進行scale up/down。這裡要注意的是確保 VPA 和 HPA 策略不會相互干擾。

Binning和packing 密度的設定很重要，在為我們的生產環境設計cluster時應該要被檢視，如果是以開發環境或是以省錢為最高指導原則的的cluster，哪就要盡可能的搾乾node的資源。同時，生產環境或以效能為主的cluster設置的成本將根據不同的需求和模式進行調整。能夠以Application(pod 和namespace的基礎)匹配每個node instance family的正確數量是建立參考模型的好方法，以確保適當的容量、可用性、overhead和經濟性。

另一件需要注意的事情是確保使用 Ingress controller來確保正確的traffic shaping和load management。

Node Rightsizing

接下來是cluster裡的node type。這成為除了各種平台選擇的所有複雜性之外的一種bin packing問題。

通常只是簡單地進行增量改進，例如我們看到node的memory有多出來時，切換到相同但提供的memory較少的node type可能是有意義的。然而，在實踐中，這可能更複雜。例如，如果workload經常消耗超過它們的request，並區分”需要(need)”的情況和只因為"資源可用(availability)"但不是非常需要而消耗它的情況之間的區別。

在產生適合運行的instance type/size的白名單時，使用instance weightings scores作為考量的因素。當我們在定價可能相同的spot market中依賴多樣化的成本分配策略時，instance weightings將很有用，但有助於確保根據weight values為您的代碼提供正確的數值。

Autoscaling的調整

讓 K8S變得特別強大的是很多的autosacling選項和動態的回應不同條件的能力，例如需求增加或減少。 我們的application可能須需要一些架構和迭代調整才能這麼做，並且在此過程中存在浪費的空間。 但是，horizontal pod autoscaling（當我們需要更多/更少的 pod）和cluster autoscaling（我們何時需要更多/更少的node）設定的越緊密，運行應用程式的浪費和不必要的成本就越少。

大多數CSP都提供折扣選項，只要這些條款適合我們的應用程式，就可以節省大量資金。

Spot/Preemptible/低優先的nodes
每個CSP對其node(VM)都有不同的名稱．但都會為短時間運作的工作負載提供折扣。 這可以讓CSP將剩餘的容量都用掉，同時能夠針對將支付on-demand費率的高優先權的workload進行調整。

K8S 的declarative使其更有利於利用spot dicount，因為如果某個node在cluster中消失的話，容器會在其他的node再跑起來。 儘管如此，某些應用程式可能無法容忍這樣的服務中斷方式。 可能符合這樣運作的應用程式包括資料密集型工作負載，這些工作負載可能run in batches或對時間不敏感，例如機器學習中的訓練．

承諾的折扣
每個 CSP都有不同的名稱，例如Reserved Instances, Savings Plans, Committed Use Discounts, Subscription Discounts等，但所有這些通常都會向企業提供折扣，這基本上就是向 CSP訂立一個使用長約。這些通常涵蓋計算資源，對於希望在特定的CSP上持續使用一年或三年時間的企業，這是降低cluster成本的一個選項。

我們應該按Application的平時運作的需求與大量運作的需求的比例來購買 committed / on-demand/ spot組合的採購方式．

例如：20% 的committed用在Application 的control plane，60％可以用於on-demand, 剩下的 20％可以用spot instance。

提前產成pre-built helm charts或launch plans並發布可重用性(reusability)，包括所有各種優化，確保我們能用最少的經驗將這一種智慧付諸實現。

“Kubeless”或“Serverless Containers”是一種新玩意，CSP正在提供更高階的服務，可以解決客戶在操作和管理 K8S cluster方面的技能短缺問題。其他人則在 FPGA type instance 上尋找 Kubeless 解決方案，其結果顯著更快、成本更低，並且無需OS和容器拖累log、patch、monitor和維護 OS 和 K8S cluster所需的內容.

雲端的成本視角：揭示大規模、多雲企業容器利用的複雜性

當容器化和cluster成本在一定程度上得到控制時，我們就會想著用其他家更便宜的CSP。就是再多個雲端平台運行容器．這會使公司如何進行完整的chargeback和成本分配再變得更複雜。

如果我們們有雲端成本管理平台(自己刻的或買第三方的)，都可以降低分配容器成本的複雜性和差異性。雲端成本管理平台在以下要素均有的狀況下最有效：

• 觀察 K8S構造的使用率並將其與雲端計費資料相關聯
• 在 K8S中使用label key/value來與內部成本中心保持一致
• 統一K8S label keys與傳統ket tags，深化成本分配模型

有了這些基礎知識，無論企業的Infrastructure多麼複雜，我們(FinOps 團隊)都可以以整體方式計算 K8S成本。可以用cluster或namespace、成本中心分析成本，並全面準確地正確分配這些成本。

Operate(營運):對管理K8S成本建立政策與實踐

現在我們可以準確分配 K8S 成本，並且知道優化這些成本的方法，這時可以建立一個可持續的實踐來執行以 FinOps 為重點的政策和應用了。 例如，在上班時間開啟開發環境的容器下班後就關掉、尋找和刪除在idel狀態的容器以及通過強制執行維護容器的labels/tags，這些都是教導和授權團隊使用的一些實踐。

雲端成本POV: 以堅實的基礎運行 FinOps 團隊

在進行實踐和政策到能夠追蹤容器化的成本之前，我們要確保FinOps團隊擁有強大的雲端財務管理基礎。 與我們的財務團隊和雲端成本中心合作，以達成一致並為以下問題提供強有力的答案：

• 我們是否已在整個infrastructure中建立了回報功能和 KPI？
• 我們的團隊是否始終如一地進行檢查以確保遵循雲端財務治理和政策（了解如何使用namespace、對沒有標籤的資源下標籤、使用的 tag是與專案/團隊相關聯、自動更正標籤以減少錯誤）？
• 團隊是否只提供他們需要的東西？ 他們能否解釋這些成本的依據並準確報告？
• 誰為共同的服務付費？
• 我們的團隊是否積極且頻繁地發現優化雲端資源使用率的機會？

要回答這些問題不僅需要實施主要的 FinOps 最佳實踐，而且還要能跟得上這些實踐。 我們還可以使用雲端成本管理解決方案，以幫助團隊查看相同的資源使用率和成本報告，並共同行動以提高效率。

管理容器成本的工具選項

大多數正在雲端使用FinOps的公司（包括容器成本）通常採取以下三種方式之一。 無論是自己開發，或使用CSP提供的工具，還是使用第三方的雲端財務管理平台，每種選擇都有其優點和缺點。

自行發開發來追蹤容器成本
如果公司的人夠多，錢也夠多，那麼自己開發自己的雲端財務管理系統（包括容器成本）可能是一種了解這種支出的方法。 如今，大型的公司都在這樣做，包括 Spotify，他們使用 backstage.io 來運作自己的一套雲端管理工具。

如果我們的團隊處於使用雲端運算的早期階段並產生可以通過這種方式管理的計費資料，這也可能是有意義的。

使用CSP提供的工具
這種方法通常與內部工具(可能是ERP系統)結合使用可能是 FinOps 的另一個方法。 只要有一種方法可以消化雲端成本資料以產生對我們的業務有意義的chargeback和報告，我們就可能處於良好狀態。 不幸的是，如果組織正在運行多雲的基礎架構，我們可能必須使用每個CSP提供的每個相應工具。

我們可能還需要另一種資料可視化或分析工具來將所有這些跨雲端的財務資料整合到同一個視圖(view)中。

使用第三方的雲端財務管理平台
當我們達到一定規模時，有一堆的手動作業會很慘，所以使用專用的雲端財務管理平台是一種自動化作業的方法。 這消除了手動的人為錯誤並將分配工作（假設所有內容都準確標記和命名）交給這類自動化的平台。

這可以提高對共有的 K8S cluster及其成本的可見性。 它還可以改善團隊或專案分配成本的方式。 雲端財務管理平台通常還具有支援多雲計費資料的功能。

但是，但是在這些第三方工具提供的功能集中我們可能無法運行所有的FinOps的實踐和而要運行的FinOps實踐也可能會受這些軟體授權的影響。 我們可能還需要每年重新議價，甚至是轉換其他的平台。 一個好的開始是我們可查看 FinOps 基金會的 FinOps 認證平台。

授權並鼓勵開發人員追蹤他們的K8S使用率

在infrastructure有做好 tag與label後，這應該為開發和 FinOps 團隊成員建立他們自己自定義的報告為追踪使用率資料提供基礎。無論是通過CSP工具的 API 還是雲端財務管理工具，授權團隊建立和管理自己的監控方案都可以提供很大幫助。

我們應該要有的是，開發與維運人員已經在追踪關鍵的基礎設施指標，這些指標可以幫助我們即時監控服務正常運行時間和效能。使用成本資料增強這些現有指標可以使他們能夠將這些資訊納入其決策過程，而無需重大的工作流程變更。

除了追踪成本支出和使用率的成本之外，開發人員還可以通過利用已經成為其現有工作流程一部分的工具進一步提高其 K8S 設置的效率。通常，這意味著採用以容器為中心的開源工具。 Helm — 應用程式管理工具、Prometheus — 監控解決方案、Argo — container workflow engines，Linkerd — service mesh解決方案，可以真正幫助工程師團隊近乎即時地獲得其 K8S的可見性以推動下一步的進行。

總結：用 FinOps 最佳實踐克服 K8S的成本管理挑戰

雲端服務只會變得越來越複雜，並且擁有強大的雲端財務管理實踐可以簡化我們報告和分配成本的方式。

本文概述了一些基礎步驟，以開始提高團隊回報容器成本的準確性。在本文中，我們介紹了：

告知階段

CSP如何對其 K8S服務收費。我們回顧了為什麼在 K8S環境中執行chargeback和成本分配具有挑戰性。

優化階段

如何不斷尋找優化K8S cluster和 Pod 的方法，並推薦了一些策略進行測試。

維運階段

我們概述了一些容器成本分配的方法，並制定了管理容器支出的政策，以及如何整合工具來幫助管理容器成本以及傳統的雲端成本支出。我們還回顧了不同類型的工具可以幫助團隊建立雲端財務政策、追蹤和治理。

本文內容摘錄自FinOps中的Calculating Container Costs。