容器化環境FinOps成本最佳化實踐

容器技術的普及使得成本管理成為雲端環境的一大挑戰。精確的成本分配需要深入瞭解容器資源使用情況，並制定相應的最佳化策略。本文將探討如何計算容器比例、處理未分配容量、利用標籤和名稱空間，並結合 Kubernetes 的資源管理機制，例如資源請求與限制、QoS 類別等，來最佳化容器成本。同時，文章也將分析無伺服器容器的成本優勢和應用，並提供與工程團隊協作推動 FinOps 的實務方法，包含獎勵機制設計、成本護欄設定以及如何激勵工程師在成本約束下進行創新。透過這些方法，企業可以更有效地管理容器成本，並在雲端環境中實作 FinOps 的目標。

容器成本分配的挑戰與解決方案

在雲端運算環境中，容器技術的使用越來越普遍，如何準確分配容器成本成為了一個重要的課題。要實作有效的成本分配，需要了解容器在底層伺服器上的資源使用情況。

自定義容器比例

計算每個容器佔用底層雲伺服器例項的比例是一個複雜的過程。可以從使用vCPU和記憶體的數量開始著手。

表格範例：伺服器例項上的容器分配

程式碼範例：計算容器比例

def calculate_proportion(vcpu, mem, time, total_vcpu, total_mem, total_time):
    vcpu_proportion = vcpu / total_vcpu
    mem_proportion = mem / total_mem
    time_proportion = time / total_time
    # 使用最大比例作為最終比例
    proportion = max(vcpu_proportion, mem_proportion) * time_proportion
    return proportion

# 範例用法
total_vcpu = 4
total_mem = 8
total_time = 60

container1_vcpu = 1
container1_mem = 2
container1_time = 60

proportion = calculate_proportion(container1_vcpu, container1_mem, container1_time, total_vcpu, total_mem, total_time)
print(f"Container 1 的比例：{proportion * 100}%")

#### 內容解密：

此程式碼用於計算單個容器佔用伺服器資源的比例。calculate_proportion函式接收容器的vCPU使用量、記憶體使用量、執行時間以及伺服器的總vCPU、總記憶體和總執行時間。函式首先計算容器在vCPU和記憶體使用上的比例，然後根據這兩個比例中的最大值與執行時間比例的乘積計算最終比例。這種方法確保了當容器對某種資源的使用比例遠高於其他資源時，能夠根據該資源的使用情況進行成本分配。

未分配容量的處理

即使按照上述方法分配了容器成本，仍然可能存在未分配的容量成本。叢集不太可能始終保持100%的使用率或請求率，這樣就會留下未被分配的剩餘容量。

圖表範例：伺服器例項上的未分配容量

圖表翻譯：

此圖表示一個伺服器例項每小時的成本為$40，其中$15被分配給Team A，$11被分配給Team B，剩餘$14為未分配容量。這張圖清晰地展示了在容器成本分配過程中，如何處理未被使用的伺服器資源。

處理未分配成本的策略

對於未分配的容量成本，主要有兩種處理策略：

1. 將閒置成本分配給中央團隊（推薦方案）：將未分配的容量成本歸屬於管理叢集的團隊。這樣可以激勵叢集管理團隊最佳化容器排程，減少叢集大小，降低無謂的開支。

2. 將閒置成本分攤給使用叢集的團隊（替代方案）：根據容器使用叢集資源的比例，將未分配的容量成本分攤給各個使用容器的團隊。

容器世界的 FinOps 實踐最佳化

容器化技術的採用使得資源利用率提高，但也帶來了新的成本管理挑戰。在本章中，我們將探討如何在容器環境中應用 FinOps 實踐，以實作成本最佳化。

容器成本分配

在容器環境中，成本分配是一個複雜的問題。由於容器分享底層伺服器資源，因此需要確定每個容器所佔用的資源比例。有兩種常見的方法：

1. 自定義機器型別：在 Google Cloud 中，使用自定義機器型別時，會根據 vCPU 和記憶體分別計費。因此，可以直接根據容器分配的 vCPU 和記憶體來計算成本。
2. 預定義機器型別：在使用預定義機器型別時，需要記錄每個容器的自定義比例資料，以確定每個容器所佔用的資源比例。

標籤、標記和名稱空間

為了有效地管理容器成本，需要對容器進行標籤和標記。這可以幫助您根據不同的維度（例如團隊、服務等）對容器進行分類別和成本分配。

名稱空間的作用

名稱空間允許您在單個叢集中對資源進行分組。透過為團隊或特定服務建立名稱空間，可以實作粗粒度的成本分配。

容器的標籤和標記

容器本身也可以在啟動時進行標籤和標記，提供更細粒度的成本分配機制。但是，這需要使用雲端計費資料以外的工具來實作。

容器最佳化階段

容器最佳化階段是 FinOps 實踐的重要組成部分。雖然容器化技術可以提高資源利用率，但仍然需要對叢集進行最佳化，以實作成本文省。

叢集放置

將所有容器執行在單個叢集中可能會導致最佳化困難。相反，執行多個叢集可以提高靈活性，但也會增加管理複雜度和成本。

容器使用最佳化

最佳化容器使用是 FinOps 實踐的重要方面。這需要叢集管理團隊和容器執行團隊之間的協作，以實作成本文省。

權責分工

在最佳化容器時，需要明確權責分工：

• 集中式團隊負責叢集的規模調整，包括水平/垂直擴充套件和工作負載放置。
• 執行容器的團隊負責設定和使用適當的請求或保證容量。

叢集規模調整

叢集規模調整是最佳化容器成本的關鍵。這包括：

水平擴充套件

透過將容器封裝到伺服器例項上，可以減少所需的伺服器例項數量，從而降低成本。

垂直擴充套件

調整伺服器例項的大小可以降低成本。例如，如果伺服器例項的利用率不高，可以調整其大小以降低 vCPU 和記憶體的使用量。

工作負載匹配

確保容器工作負載與伺服器例項的 vCPU 和記憶體比例相匹配，可以避免資源浪費。

程式碼範例：叢集規模調整

import pandas as pd

# 定義叢集資源利用率資料
cluster_utilization = pd.DataFrame({
    'vCPU': [0.7, 0.3, 0.5],
    'memory': [0.8, 0.4, 0.6]
})

# 定義伺服器例項大小
server_sizes = pd.DataFrame({
    'vCPU': [2, 4, 8],
    'memory': [4, 8, 16]
})

# 調整伺服器例項大小
def adjust_server_size(cluster_utilization, server_sizes):
    # 計算平均資源利用率
    avg_utilization = cluster_utilization.mean()
    
    # 選擇合適的伺服器例項大小
    suitable_size = server_sizes[(server_sizes['vCPU'] >= avg_utilization['vCPU']) & 
                                 (server_sizes['memory'] >= avg_utilization['memory'])]
    
    return suitable_size

# 輸出結果
print(adjust_server_size(cluster_utilization, server_sizes))

內容解密：

此程式碼範例展示瞭如何根據叢集資源利用率資料調整伺服器例項大小。首先，我們定義了叢集資源利用率資料和伺服器例項大小。然後，我們計算了平均資源利用率，並選擇了合適的伺服器例項大小。最後，我們輸出了結果。

圖表示例：叢集資源利用率

圖表翻譯： 此圖表示例展示了叢集資源利用率的計算過程。首先，我們計算了 vCPU 和記憶體的利用率，然後計算了平均利用率。最後，我們根據平均利用率選擇了合適的伺服器例項大小。

容器化環境的 FinOps 實踐

在容器化環境中，實作 FinOps 的關鍵在於最佳化資源利用率和降低成本。容器化技術使得應用程式的佈署變得更加靈活和高效，但同時也帶來了新的挑戰，例如資源分配、成本管理和最佳化。

資源分配最佳化

容器化環境中的資源分配最佳化是實作 FinOps 的重要一步。為了確保資源的有效利用，需要根據容器的實際需求進行資源分配。

資源請求與限制

Kubernetes 等容器協調工具提供了資源請求（Request）和限制（Limit）的機制，可以根據容器的需求進行資源分配。

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 200m
        memory: 256Mi

內容解密：

此 YAML 組態檔案定義了一個 Pod，其中包含一個容器。該容器的資源請求為 100m CPU 和 128Mi 記憶體，資源限制為 200m CPU 和 256Mi 記憶體。這種組態確保了容器在需要時可以獲得足夠的資源，同時也防止了資源過度使用。

QoS 類別

Kubernetes 提供了 QoS（Quality of Service）類別，用於區分不同優先順序的 Pod。QoS 類別包括 Guaranteed、Burstable 和 Best-Effort 三種。

Guaranteed 資源分配

對於關鍵服務容器，可以使用 Guaranteed 資源分配，確保 Pod 在任何時候都能夠獲得所需的資源。

Burstable 資源分配

對於具有突發性工作負載的容器，可以使用 Burstable 資源分配，允許 Pod 在需要時使用更多的資源。

Best-Effort 資源分配

對於開發/測試容器，可以使用 Best-Effort 資源分配，當有剩餘資源時執行，否則停止。

伺服器例項費率最佳化

在容器化環境中，伺服器例項的費率最佳化同樣重要。可以使用 Spot 例項來降低成本，但需要注意風險。

圖表翻譯： 此圖表展示了使用 Spot 例項的優缺點。一方面，使用 Spot 例項可以降低成本；另一方面，需要注意例項可能被終止的風險。

容器操作階段

在 FinOps 的操作階段，需要考慮如何將雲端資源層級的操作應用於容器化環境。例如，安排開發容器在營業時間內開啟和關閉、查詢和刪除閒置容器、維護容器標籤/標記等。

無伺服器容器與FinOps的協同最佳化

在雲端運算的世界中，無伺服器容器（Serverless Containers）為企業的FinOps（財務營運）策略帶來了新的變化。以AWS的Fargate為例，無伺服器容器讓企業能夠更靈活地管理容器化的應用程式，同時也對成本管理提出了新的挑戰和機遇。

無伺服器容器的成本優勢

無伺服器容器讓企業無需再擔心叢集管理的成本和複雜性。雲端服務提供商接管了叢集管理階層，抽象化了計算節點，使得企業可以更專注於應用程式的開發和佈署。同時，無伺服器容器還提供了更精確的成本分配機制，因為每個容器任務都直接由雲端服務提供商收費。

程式碼範例：無伺服器容器的成本計算

# 無伺服器容器的成本計算範例
def calculate_serverless_cost(vcpu, memory, duration):
    # 假設每單位vCPU和記憶體的成本
    vcpu_cost = 0.000004445 # 每秒成本
    memory_cost = 0.000004445 # 每秒成本
    
    # 計算總成本
    total_cost = (vcpu * vcpu_cost + memory * memory_cost) * duration
    return total_cost

# 使用範例
vcpu = 1
memory = 2 # GB
duration = 3600 # 秒
cost = calculate_serverless_cost(vcpu, memory, duration)
print(f"無伺服器容器的總成本：${cost:.6f}")

內容解密：

此程式碼範例展示瞭如何計算無伺服器容器的成本。函式calculate_serverless_cost接受三個引數：vcpu、memory和duration，分別代表虛擬CPU核心數、記憶體大小（GB）和執行時間（秒）。透過將這些引數與對應的成本常數相乘，可以計算出無伺服器容器的總成本。這種精確的成本計算方式有助於企業更好地掌握其雲端資源的支出。

與工程團隊合作推動FinOps

FinOps是一項團隊運動，需要工程團隊的積極參與。在本章中，我們將探討如何建立一種FinOps文化，激勵工程團隊關注成本效率，而不是簡單地下達命令。

FinOps成熟度模型

圖表翻譯： 此圖表展示了FinOps成熟度模型的四個階段，從初始階段到卓越實踐。企業可以透過不斷提高意識、持續改進和最佳化，逐步提升其FinOps實踐的成熟度。

工程師的視角與FinOps

工程師的動機與財務團隊不同，他們更關注創新、軟體改進和多方面的效率，包括安全、效能、正常執行時間和可靠性。FinOps從業人員需要與工程師（及其長官層）合作，使成本效率成為與其他關鍵約束同等重要的考慮因素。

程式碼範例：資源利用率監控

# 資源利用率監控範例
import psutil

def monitor_resource_utilization():
    # 取得CPU利用率
    cpu_utilization = psutil.cpu_percent(interval=1)
    
    # 取得記憶體利用率
    memory_utilization = psutil.virtual_memory().percent
    
    return cpu_utilization, memory_utilization

# 使用範例
cpu_util, memory_util = monitor_resource_utilization()
print(f"CPU利用率：{cpu_util}%")
print(f"記憶體利用率：{memory_util}%")

內容解密：

此程式碼範例展示瞭如何監控系統的資源利用率，包括CPU和記憶體利用率。透過使用psutil函式庫，可以輕鬆取得這些指標。這些資料對於評估資源使用效率和最佳化雲端資源組態至關重要。

與工程師合作實作FinOps

Abuna Demoz是一位曾經在Google Cloud和Amazon Web Services長官大型工程團隊的軟體工程師，他分享了以下見解：

大多數工程師一開始都希望盡可能完成軟體生命週期中的各種任務，包括開發、檔案編寫、監控、警示、重構、擴充套件等。然而，他們很快就會碰到在工作日或新功能預定上線日期前實際能夠完成的任務的限制。對於高階工程師來說，需求尤其高。他們被迫不斷優先處理並在時間框架內做出艱難的選擇，通常不允許超出關鍵需求。

組織的獎勵結構對工程師行為的影響

組織的獎勵結構在這裡發揮了作用。大多數工程師會根據能獲得獎勵（薪水、獎金等）或被認可（讚揚、長官層關注、晉升等）的任務來優先安排工作。使用獎勵和認可來驅動行為非常有效，但我們也必須瞭解其中隱含的權衡。

例如，在大多陣列織中，工程師因推出客戶使用並理想地付費的新功能而獲得獎勵。這意味著當時間不夠時，很容易對可靠性、可維護性、可擴充套件性，尤其是成本投資不足。隨著組織轉向FinOps，將成本指標和目標與工程師獎勵掛鉤是讓每個人關注相同問題的好方法。

獎勵可以與提高標籤覆寫率、減少浪費和利用不足、和/或提高預測準確性掛鉤。長官者對團隊朝著這些目標努力的認可，有助於加強這些目標的重要性。

程式碼範例：成本最佳化標籤覆寫率計算

def calculate_tag_coverage(resources, tags):
    """
    計算資源的標籤覆寫率
    
    :param resources: 資源列表
    :param tags: 標籤列表
    :return: 標籤覆寫率
    """
    total_resources = len(resources)
    tagged_resources = sum(1 for resource in resources if all(tag in resource['tags'] for tag in tags))
    coverage = (tagged_resources / total_resources) * 100 if total_resources > 0 else 0
    return coverage

# 示例用法
resources = [
    {'id': '1', 'tags': ['env:prod', 'team:finops']},
    {'id': '2', 'tags': ['env:dev', 'team:devops']},
    {'id': '3', 'tags': ['env:prod', 'team:finops']}
]
tags = ['env:prod', 'team:finops']
coverage = calculate_tag_coverage(resources, tags)
print(f"標籤覆寫率: {coverage}%")

#### 內容解密：
此程式碼用於計算資源的標籤覆寫率。首先，它統計資源的總數，然後計算具有所有指定標籤的資源數量，最後計算覆寫率。這有助於評估資源的標籤完整性，對於成本分配和跟蹤至關重要。

FinOps 對工程師工作負擔的影響

FinOps 應該尋找方法減輕工程師的工作負擔，尤其是透過自動化。如第8章所述，將 FinOps 資料放在工程師的工作路徑中，可以實作更快的決策，並減少因上下文切換而丟失的認知負擔。我們不希望工程師花費大量時間（或腦力）來弄清楚他們的行動如何影響支出預測，這不僅使他們遠離其他優先事項，也降低了他們處理 FinOps 責任的可能性。FinOps 報告應該為工程師提供一個清晰的輪廓，說明他們需要考慮的行動以及支援這些行動的精確資料，從而減少工程師考慮成本所需的負擔和時間承諾。

約束與創新

人類不喜歡被約束，但約束是創新所必需的。要創造出偉大的東西，需要兩件事：一個計劃和不太夠的時間。——L. Bernstein

成本護欄常常會遇到這樣的觀點：“我們去雲端是為了減少約束，而現在你們又在給我們增加約束。”我們從工程團隊中聽到的進一步反饋是：“告訴我你想去哪裡，但不要告訴我怎麼去。”透過合作設定共同商定的成本護欄（以預算和預測的形式），並向管理基礎設施的團隊提供有關雲支出和使用的可信資料，FinOps 可以為工程師提供所需的約束，告訴他們在成本方面需要去哪裡，同時讓他們創新地實作成本效率。

成本護欄與創新

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 容器化環境FinOps成本最佳化實踐

package "Docker 架構" {
    actor "開發者" as dev

    package "Docker Engine" {
        component [Docker Daemon] as daemon
        component [Docker CLI] as cli
        component [REST API] as api
    }

    package "容器運行時" {
        component [containerd] as containerd
        component [runc] as runc
    }

    package "儲存" {
        database [Images] as images
        database [Volumes] as volumes
        database [Networks] as networks
    }

    cloud "Registry" as registry
}

dev --> cli : 命令操作
cli --> api : API 呼叫
api --> daemon : 處理請求
daemon --> containerd : 容器管理
containerd --> runc : 執行容器
daemon --> images : 映像檔管理
daemon --> registry : 拉取/推送
daemon --> volumes : 資料持久化
daemon --> networks : 網路配置

@enduml

圖表翻譯： 此圖表展示了透過設定成本護欄和使用可信資料來引導工程師實作成本效率的過程。成本護欄提供了必要的約束，而可信資料則支援工程師的創新和最佳化工作，從而達到成本目標並持續改進。

工程師喜歡解決難題

工程師喜歡解決難題。這從大型雲端服務提供商年度大會上的許多工程成功故事中可以看出。大多數演講都涵蓋了公司如何利用雲端擴充套件、創新、新增新功能，並為組織引入全新的商機。

那些在成本約束範圍內構建雲解決方案的工程師應該被視為創新者。為工程師提供一個平台，讓他們分享克服技術難題的創意工程解決方案，以滿足成本約束。

本章探討了不同級別的雲預算，以及一些剛接觸雲的團隊如何抵制預算的概念。具有諷刺意味的是，在大多陣列織中，IT支出一直都有預算。與工程師合作並提供適當的工具和激勵措施，可以幫助實作 FinOps 的目標，同時保持工程師的創新精神。