詞彙表
本詞彙表旨在成為 Kubernetes 術語的全面、標準化列表。它包含 Kubernetes 特有的技術術語,以及提供有用上下文的更通用術語。
根據標籤篩選術語
點擊下方 [+] 指示符號,以取得任何特定術語的更長解釋。
一段程式碼,用於在物件持久化之前攔截對 Kubernetes API 伺服器的請求。
[+]準入控制器可針對 Kubernetes API 伺服器進行配置,並且可以是「驗證 (validating)」、「變更 (mutating)」或兩者兼具。任何準入控制器都可以拒絕請求。變更控制器可以修改它們允許的物件;驗證控制器則不得修改。
在 Kubernetes 中,「親和性 (affinity)」是一組規則,為排程器提供關於 Pod 放置位置的提示。
[+]親和性有兩種
這些規則是使用 Kubernetes 標籤 (labels)和選擇器 (selectors)定義,並在pod中指定,它們可以是必要的或偏好的,具體取決於您希望排程器多嚴格地執行它們。
聚合層讓您在叢集中安裝額外的 Kubernetes 風格 API。
[+]當您設定Kubernetes API 伺服器 (Kubernetes API Server)以支援額外的 API時,您可以新增
APIService
物件以「聲明」Kubernetes API 中的 URL 路徑。用於將任意非識別中繼資料附加到物件的金鑰值組。
[+]註解中的中繼資料可以是小的或大的、結構化的或非結構化的,並且可以包含標籤 (labels)不允許的字元。用戶端(例如工具和程式庫)可以檢索此中繼資料。
Kubernetes API 中一組相關的路徑。
[+]您可以透過變更 API 伺服器的組態來啟用或停用每個 API 群組。您也可以停用或啟用特定資源的路徑。API 群組使擴充 Kubernetes API 更加容易。API 群組在 REST 路徑和序列化物件的
apiVersion
欄位中指定。- 閱讀API 群組 (API Group)以取得更多資訊。
- 亦稱為:kube-apiserver
API 伺服器是 Kubernetes 控制平面 (control plane)的元件,用於公開 Kubernetes API。API 伺服器是 Kubernetes 控制前端。
[+]Kubernetes API 伺服器的主要實作是kube-apiserver。kube-apiserver 設計為可水平擴充,也就是說,它透過部署更多實例來擴充。您可以執行多個 kube-apiserver 實例,並在這些實例之間平衡流量。
API 起始的驅逐是您使用 Eviction API 建立
[+]Eviction
物件以觸發 Pod 正常終止的程序。您可以透過直接使用 kube-apiserver 的用戶端(例如
kubectl drain
指令)呼叫 Eviction API 來請求驅逐。當Eviction
物件建立時,API 伺服器會終止 Pod。API 起始的驅逐會尊重您設定的
PodDisruptionBudgets
和terminationGracePeriodSeconds
。API 起始的驅逐與節點壓力驅逐 (node-pressure eviction)不同。
- 請參閱API 起始的驅逐 (API-initiated eviction)以取得更多資訊。
應用程式容器(或 app containers)是 容器 (containers),位於 pod 中,在任何初始化容器 (init containers)完成後啟動。
[+]初始化容器可讓您分離對整體工作負載 (workload)很重要的初始化細節,並且在應用程式容器啟動後不需要保持執行。如果 pod 沒有設定任何初始化容器,則該 pod 中的所有容器都是應用程式容器。
負責應用程式高階設計的人員。
[+]架構師確保應用程式的實作使其能夠以可擴充、可維護的方式與周圍的元件互動。周圍的元件包括資料庫、日誌基礎架構和其他微服務。
編寫在 Kubernetes 叢集中執行的應用程式的人員。
[+]應用程式開發人員專注於應用程式的一部分。他們關注的範圍大小可能差異很大。
- 各種容器化應用程式執行的層級。[+]
各種容器化應用程式執行的層級。
可以審查和核准 Kubernetes 程式碼貢獻的人員。
[+]雖然程式碼審查側重於程式碼品質和正確性,但核准側重於對貢獻的整體接受度。整體接受度包括向後/向前相容性、遵守 API 和旗標慣例、細微的效能和正確性問題、與系統其他部分的互動等等。核准者身分限定於程式碼庫的一部分。核准者以前被稱為維護者。
cAdvisor (Container Advisor) 為容器使用者提供對其執行中容器 (containers)的資源使用率和效能特性的理解。
[+]它是一個正在執行的常駐程式,用於收集、彙總、處理和匯出有關執行中容器的資訊。具體來說,對於每個容器,它都會保留資源隔離參數、歷史資源使用率、完整歷史資源使用率的直方圖和網路統計資訊。此資料由容器和機器範圍匯出。
用於驗證對 Kubernetes 叢集存取的密碼學安全檔案。
[+]憑證使 Kubernetes 叢集中的應用程式能夠安全地存取 Kubernetes API。憑證驗證用戶端是否被允許存取 API。
具有可選資源隔離、計帳和限制的 Linux 程序群組。
[+]cgroup 是一種 Linux 核心功能,用於限制、計帳和隔離一組程序的資源使用率(CPU、記憶體、磁碟 I/O、網路)。
「貢獻者 (contributor)」根據這些條款,授予開放原始碼專案對其貢獻的授權。
[+]CLA 有助於解決涉及貢獻材料和智慧財產權 (IP) 的法律糾紛。
Kubernetes 控制平面 (control plane)元件,嵌入雲端特定的控制邏輯。雲端控制器管理員可讓您將叢集連結到雲端供應商的 API,並將與該雲端平台互動的元件與僅與叢集互動的元件分開。
[+]透過將 Kubernetes 和底層雲端基礎架構之間的互通性邏輯分離,cloud-controller-manager 元件使雲端供應商能夠以與主要 Kubernetes 專案不同的步調發布功能。
- 亦稱為:雲端服務供應商 (Cloud Service Provider)
提供雲端運算平台的企業或其他組織。
[+]雲端供應商,有時稱為雲端服務供應商 (CSP),提供雲端運算平台或服務。
許多雲端供應商提供受管理的基礎架構(也稱為基礎架構即服務或 IaaS)。使用受管理的基礎架構,雲端供應商負責伺服器、儲存和網路,而您管理其上的層級,例如執行 Kubernetes 叢集。
您還可以找到作為受管理服務的 Kubernetes;有時稱為平台即服務或 PaaS。使用受管理的 Kubernetes,您的雲端供應商負責 Kubernetes 控制平面以及節點 (nodes)及其依賴的基礎架構:網路、儲存以及可能其他元素,例如負載平衡器。
一組稱為節點 (nodes)的工作機器,用於執行容器化應用程式。每個叢集至少有一個工作節點。
[+]工作節點託管作為應用程式工作負載元件的Pod。控制平面 (control plane) 管理叢集中的工作節點和 Pod。在生產環境中,控制平面通常跨多部電腦執行,而叢集通常執行多個節點,以提供容錯和高可用性。
設計涉及一個或多個 Kubernetes 叢集基礎架構的人員。
[+]叢集架構師關注分散式系統的最佳實務,例如:高可用性和安全性。
- 基礎架構層提供和維護 VM、網路、安全性群組等。[+]
基礎架構層提供和維護 VM、網路、安全性群組等。
管理 Kubernetes 叢集所涉及的工作:管理日常營運和協調升級。
[+]叢集營運工作的範例包括:部署新節點以擴充叢集;執行軟體升級;實作安全性控制;新增或移除儲存;設定叢集網路;管理叢集範圍的可觀察性;以及回應事件。
設定、控制和監控叢集的人員。
[+]他們的主要職責是保持叢集啟動並執行,這可能涉及定期維護活動或升級。
注意
叢集營運人員與擴充 Kubernetes API 的 Operator 模式 不同。開發 Kubernetes 開放原始碼程式碼庫並貢獻程式碼的人員。
[+]他們也是積極的社群成員 (community member),他們參與一個或多個特殊興趣小組 (SIGs)。
用於以金鑰值組儲存非機密資料的 API 物件。Pod 可以將 ConfigMap 作為環境變數、命令列引數或作為磁碟區 (volume)中的組態檔使用。
[+]ConfigMap 可讓您將環境特定的組態與容器映像檔 (container images)分離,以便您的應用程式易於攜帶。
輕量且可攜式的可執行映像檔,其中包含軟體及其所有相依性。
[+]容器將應用程式與底層主機基礎架構分離,以便在不同的雲端或作業系統環境中更輕鬆地部署,並更容易擴充。在容器內執行的應用程式稱為容器化應用程式。將這些應用程式及其相依性捆綁到容器映像檔中的過程稱為容器化。
容器環境變數是 name=value 配對,可為在pod中執行的容器提供有用的資訊
[+]容器環境變數提供執行中的容器化應用程式所需的資訊,以及關於容器 (containers)的重要資源的資訊。例如,檔案系統詳細資訊、關於容器本身的資訊以及其他叢集資源(例如服務端點)。
生命週期掛鉤公開容器 (Container)管理生命週期中的事件,並讓使用者在事件發生時執行程式碼。
[+]向容器公開了兩個掛鉤:PostStart,在容器建立後立即執行;以及 PreStop,它是封鎖的,並在容器終止之前立即呼叫。
容器網路介面 (CNI) 外掛程式是一種網路外掛程式,符合 appc/CNI 規範。
[+]- 有關 Kubernetes 和 CNI 的資訊,請參閱網路外掛程式 (Network Plugins)。
賦予 Kubernetes 有效執行容器能力的基本元件。它負責管理 Kubernetes 環境中容器的執行和生命週期。
[+]Kubernetes 支援容器執行期,例如containerd、CRI-O,以及 Kubernetes CRI (容器執行期介面) 的任何其他實作。
容器儲存介面 (CSI) 定義了一個標準介面,用於將儲存系統公開給容器。
[+]CSI 允許供應商為 Kubernetes 建立自訂儲存外掛程式,而無需將它們新增到 Kubernetes 儲存庫(樹狀結構外的外掛程式)。若要使用儲存供應商的 CSI 驅動程式,您必須先將其部署到您的叢集。然後您將能夠建立使用該 CSI 驅動程式的儲存類別 (Storage Class)。
強調簡潔性、穩健性和可攜性的容器執行期
[+]containerd 是一個容器 (container)執行期,作為 Linux 或 Windows 上的常駐程式執行。containerd 負責提取和儲存容器映像檔、執行容器、提供網路存取等等。
捐贈程式碼、文件或時間以協助 Kubernetes 專案或社群的人員。
[+]貢獻包括提取請求 (PR)、問題、意見反應、特殊興趣小組 (SIG)參與或組織社群活動。
容器編排層,用於公開 API 和介面,以定義、部署和管理容器的生命週期。
[+]此層由許多不同的元件組成,例如(但不限於)
這些元件可以作為傳統作業系統服務(常駐程式)或作為容器執行。執行這些元件的主機在過去稱為主節點 (masters)。
在 Kubernetes 中,控制器是控制迴圈,用於監看您的叢集 (cluster)狀態,然後在需要時進行或請求變更。每個控制器都嘗試將目前的叢集狀態更接近所需狀態。
[+]控制器透過apiserver(控制平面 (Control Plane)的一部分)監看叢集的共用狀態。
某些控制器也在控制平面內執行,提供 Kubernetes 營運核心的控制迴圈。例如:部署控制器 (deployment controller)、DaemonSet 控制器 (daemonset controller)、命名空間控制器 (namespace controller) 和持久磁碟區控制器 (persistent volume controller)(以及其他控制器)都在 kube-controller-manager 內執行。
一種工具,可讓您將 OCI 容器執行期與 Kubernetes CRI 搭配使用。
[+]CRI-O 是容器執行期介面 (Container Runtime Interface) (CRI) 的實作,旨在啟用使用與開放容器倡議 (OCI) 執行期規範相容的容器 (container) 執行期。
部署 CRI-O 允許 Kubernetes 使用任何符合 OCI 標準的執行期作為執行Pod 的容器執行期,並從遠端登錄檔提取 OCI 容器映像檔。
自訂程式碼,用於定義要新增到 Kubernetes API 伺服器的資源,而無需建置完整的自訂伺服器。
[+]如果公開支援的 API 資源無法滿足您的需求,自訂資源定義可讓您擴充 Kubernetes API 以適用於您的環境。
確保 Pod 的副本在一組叢集 (cluster)中的節點上執行。
[+]用於部署系統常駐程式,例如通常必須在每個節點 (Node)上執行的日誌收集器和監控代理程式。
- 提供容量(例如 CPU、記憶體、網路和儲存)的層級,以便容器可以執行並連線到網路。[+]
提供容量(例如 CPU、記憶體、網路和儲存)的層級,以便容器可以執行並連線到網路。
API 物件,用於管理複寫的應用程式,通常透過執行沒有本機狀態的 Pod。
[+]每個副本都由一個 Pod 表示,而 Pod 分散在叢集的節點 (nodes)之間。對於確實需要本機狀態的工作負載,請考慮使用 StatefulSet。
可能指:應用程式開發人員 (Application Developer)、程式碼貢獻者 (Code Contributor)或平台開發人員 (Platform Developer)。
[+]這個過載的術語在不同的上下文中可能有不同的含義
中斷是導致一個或多個 Pod 停止服務的事件。 中斷會對工作負載資源產生影響,例如依賴受影響 Pod 的 Deployment。
[+]如果你以叢集管理員的身分,摧毀屬於應用程式的 Pod,Kubernetes 將其稱為自願性中斷。 如果 Pod 因為節點故障或影響更廣泛故障區域的停機而離線,Kubernetes 將其稱為非自願性中斷。
請參閱 中斷 以取得更多資訊。
Dockershim 是 Kubernetes 1.23 及更早版本的元件。 它允許 kubelet 與 Docker Engine 通訊。
[+]從 1.24 版本開始,dockershim 已從 Kubernetes 中移除。 如需更多資訊,請參閱 Dockershim 常見問題。
可能指:Kubernetes 生態系統中依賴於核心 Kubernetes 程式碼庫或分支儲存庫的程式碼。
[+]- 在 Kubernetes 社群中:對話中經常使用下游來表示生態系統、程式碼或依賴於核心 Kubernetes 程式碼庫的第三方工具。 例如,Kubernetes 中的新功能可能會被下游的應用程式採用,以改進其功能。
- 在 GitHub 或 git 中:慣例是將分支儲存庫稱為下游,而來源儲存庫則被視為上游。
Kubernetes 將 Pod 和容器欄位值公開給在容器中執行的程式碼的機制。
[+]對於容器來說,擁有關於自身的資訊,而無需更改直接將其耦合到 Kubernetes 的容器程式碼,有時很有用。
Kubernetes downward API 允許容器使用關於自身或其在 Kubernetes 叢集中的上下文資訊。 容器中的應用程式可以存取該資訊,而無需應用程式充當 Kubernetes API 的用戶端。
有兩種方法可以將 Pod 和容器欄位公開給正在執行的容器
- 使用 環境變數
- 使用
downwardAPI
卷
這兩種公開 Pod 和容器欄位的方式統稱為 downward API。
表示時間量的字串值。
[+](Kubernetes) 持續時間的格式基於 Go 程式語言的
time.Duration
類型。在 Kubernetes API 中使用持續時間時,該值表示為一系列非負整數,並結合時間單位後綴。 你可以有多個時間量,持續時間是這些時間量的總和。 有效的時間單位為 "ns"、"µs"(或 "us")、"ms"、"s"、"m" 和 "h"。
例如:
5s
表示五秒的持續時間,而1m30s
表示一分三十秒的持續時間。允許使用者請求自動建立儲存 卷。
[+]動態佈建消除了叢集管理員預先佈建儲存的需求。 相反地,它會根據使用者請求自動佈建儲存。 動態卷佈建基於 API 物件 StorageClass,它參考 卷外掛程式,該外掛程式佈建 卷 以及要傳遞給卷外掛程式的參數集。
端點追蹤具有相符 選擇器 的 Pod 的 IP 位址。
[+]端點可以針對未指定選擇器的 服務 手動配置。 EndpointSlice 資源為端點提供了可擴展和可延伸的替代方案。
一種將網路端點與 Kubernetes 資源分組在一起的方式。
[+]一種可擴展和可延伸的方式,將網路端點分組在一起。 這些可以被 kube-proxy 用於在每個 節點 上建立網路路由。
Finalizers 是命名空間金鑰,它告訴 Kubernetes 在完全刪除標記為刪除的資源之前,要等到滿足特定條件。 Finalizers 提醒 控制器 清理已刪除物件擁有的資源。
[+]當你告訴 Kubernetes 刪除具有為其指定的 finalizers 的物件時,Kubernetes API 會透過填入
.metadata.deletionTimestamp
來標記該物件以進行刪除,並傳回202
狀態碼(HTTP "已接受")。 目標物件保持在終止狀態,而控制平面或其他元件則執行 finalizers 定義的動作。 在這些動作完成後,控制器會從目標物件中移除相關的 finalizers。 當metadata.finalizers
欄位為空時,Kubernetes 認為刪除已完成並刪除該物件。你可以使用 finalizers 來控制資源的 垃圾收集。 例如,你可以定義 finalizer 以在控制器刪除目標資源之前清理相關的資源或基礎架構。
垃圾收集是 Kubernetes 用於清理叢集資源的各種機制的總稱。
[+]Kubernetes 使用垃圾收集來清理資源,例如 未使用的容器和映像檔、失敗的 Pod、目標資源擁有的物件、已完成的 Job,以及已過期或失敗的資源。
用於在 Kubernetes 中建模服務網路的一系列 API 種類。
[+]Gateway API 提供了一系列可擴展、面向角色、協議感知的 API 種類,用於在 Kubernetes 中建模服務網路。
- 又稱為:GVR
表示唯一 Kubernetes API 資源的方式。
[+]Group Version Resources (GVR) 指定 API 群組、API 版本和資源(物件種類的名稱,如 URI 中所示),這些與存取 Kubernetes 中特定物件 ID 相關聯。 GVR 允許你定義和區分不同的 Kubernetes 物件,並指定一種即使在 API 變更時也能保持穩定的物件存取方式。
一個預先配置的 Kubernetes 資源套件,可以使用 Helm 工具進行管理。
[+]Chart 提供了一種可重現的方式來建立和共享 Kubernetes 應用程式。 單個 chart 可以用於部署簡單的東西,例如 memcached Pod,或複雜的東西,例如包含 HTTP 伺服器、資料庫、快取等的完整 Web 應用程式堆疊。
- 又稱為:HPA
一種 API 資源,可根據目標 CPU 使用率或自訂指標目標自動調整 Pod 副本的數量。
[+]HPA 通常與 ReplicationControllers、Deployments 或 ReplicaSets 一起使用。 它不能應用於無法擴展的物件,例如 DaemonSets。
HostAliases 是 IP 位址和主機名稱之間的對應,將被注入到 Pod 的 hosts 檔案中。
[+]HostAliases 是一個主機名稱和 IP 位址的可選列表,如果指定,將被注入到 Pod 的 hosts 檔案中。 這僅對非 hostNetwork Pod 有效。
不可變基礎架構是指一旦部署後就無法變更的電腦基礎架構(虛擬機器、容器、網路設備)。
[+]不變性可以透過自動化流程來強制執行,該流程會覆寫未經授權的變更,或者透過一個從一開始就不允許變更的系統來強制執行。 容器 是不可變基礎架構的一個很好的例子,因為對容器的持久性變更只能透過建立容器的新版本或從其映像檔重新建立現有容器來完成。
透過防止或識別未經授權的變更,不可變基礎架構使其更容易識別和減輕安全風險。 運行這樣的系統變得更加簡單,因為管理員可以對其進行假設。 畢竟,他們知道沒有人犯錯或進行了他們忘記溝通的變更。 不可變基礎架構與基礎架構即程式碼 (Infrastructure as Code) 齊頭並進,後者將建立基礎架構所需的所有自動化都儲存在版本控制(例如 Git)中。 不可變性和版本控制的這種結合意味著系統中每個授權變更都有持久的稽核日誌。
一種 API 物件,用於管理對叢集中服務的外部存取,通常是 HTTP。
[+]Ingress 可能提供負載平衡、SSL 終止和基於名稱的虛擬主機。
一個或多個初始化 容器,必須在任何應用程式容器運行之前完成運行。
[+]初始化 (init) 容器與常規應用程式容器類似,但有一個區別:init 容器必須在任何應用程式容器可以啟動之前完成運行。 Init 容器依序運行:每個 init 容器必須在下一個 init 容器開始之前完成運行。
與 sidecar 容器 不同,init 容器在 Pod 啟動後不會保持運行。
如需更多資訊,請閱讀 init 容器。
一個開放平台(非 Kubernetes 特有),提供統一的方式來整合微服務、管理流量、強制執行策略和彙總遙測資料。
[+]新增 Istio 不需要變更應用程式程式碼。 它是服務和網路之間的一層基礎架構,當與服務部署結合時,通常稱為服務網格。 Istio 的控制平面抽象化了底層叢集管理平台,該平台可能是 Kubernetes、Mesosphere 等。
一種表示在兩個參與方之間傳輸的宣告的方式。
[+]JWT 可以進行數位簽章和加密。 Kubernetes 使用 JWT 作為身份驗證權杖,以驗證想要在叢集中執行動作的實體的身份。
[+]kOps
不僅可以幫助你建立、摧毀、升級和維護生產級、高可用性的 Kubernetes 叢集,還可以佈建必要的雲端基礎架構。注意
目前正式支援 AWS(Amazon Web Services),DigitalOcean、GCE 和 OpenStack 在 beta 支援中,而 Azure 則在 alpha 中。kOps
是一個自動化佈建系統- 完全自動化安裝
- 使用 DNS 來識別叢集
- 自我修復:一切都在 Auto-Scaling Groups 中運行
- 多個作業系統支援(Amazon Linux、Debian、Flatcar、RHEL、Rocky 和 Ubuntu)
- 高可用性支援
- 可以直接佈建,或產生 terraform 清單
kube-proxy 是一個網路代理,在叢集中的每個 節點 上運行,實作 Kubernetes Service 概念的一部分。
[+]kube-proxy 維護節點上的網路規則。 這些網路規則允許從叢集內部或外部的網路會話與你的 Pod 進行網路通訊。
kube-proxy 使用作業系統封包過濾層(如果有的話且可用)。 否則,kube-proxy 會自行轉發流量。
透過 RESTful 介面提供 Kubernetes 功能並儲存叢集狀態的應用程式。
[+]Kubernetes 資源和「意圖記錄」都儲存為 API 物件,並透過對 API 的 RESTful 呼叫進行修改。 API 允許以宣告式方式管理配置。 使用者可以直接與 Kubernetes API 互動,或透過
kubectl
等工具進行互動。 核心 Kubernetes API 非常靈活,也可以擴展以支援自訂資源。由第三方供應商維護的軟體產品。
[+]託管服務的一些範例包括 AWS EC2、Azure SQL Database 和 GCP Pub/Sub,但它們可以是任何可供應用程式使用的軟體產品。
K8s 社群中持續活躍的貢獻者。
[+]成員可以被指派問題和 PR,並透過 GitHub 團隊參與特殊興趣小組 (SIG)。預先提交測試會自動為成員的 PR 執行。成員應保持社群的活躍貢獻者。
用於在本機執行 Kubernetes 的工具。
[+]Minikube 在您電腦上的 VM 內執行單節點叢集。您可以使用 Minikube 在學習環境中嘗試 Kubernetes。
用戶端提供的字串,用於參考資源 URL 中的物件,例如
[+]/api/v1/pods/some-name
。在任何時間點,給定種類的物件只能有一個給定的名稱。但是,如果您刪除物件,則可以使用相同的名稱建立一個新物件。
關於 Pod 群組之間以及與其他網路端點之間如何進行通訊的規格。
[+]網路原則可協助您宣告式地配置允許哪些 Pod 彼此連線、允許哪些命名空間進行通訊,以及更具體地說,在每個原則上強制執行哪些連接埠號碼。
NetworkPolicy
資源使用標籤來選取 Pod 並定義規則,這些規則指定允許哪些流量流向選取的 Pod。網路原則由網路供應商提供的受支援網路外掛程式實作。請注意,建立網路資源而沒有控制器來實作它將不會有任何效果。Operator 模式是一種系統設計,它將控制器 (Controller) 連接到一個或多個自訂資源。
[+]您可以透過將控制器新增至叢集來擴展 Kubernetes,超出 Kubernetes 本身附帶的內建控制器。
如果正在執行的應用程式充當控制器,並且具有 API 存取權限,可以針對控制平面中定義的自訂資源執行任務,則這就是 Operator 模式的範例。
宣告在持久卷 (PersistentVolume) 中定義的儲存資源,以便可以將其掛載為容器中的卷。
[+]指定儲存空間量、儲存空間的存取方式(唯讀、讀寫和/或獨佔)以及回收方式(保留、回收或刪除)。儲存空間本身的詳細資訊在 PersistentVolume 物件中描述。
自訂 Kubernetes 平台以符合其專案需求的人員。
[+]平台開發人員可能會使用自訂資源 (Custom Resources) 或使用聚合層擴展 Kubernetes API,以將功能新增至其 Kubernetes 執行個體,特別是針對其應用程式。一些平台開發人員也是貢獻者,並開發貢獻給 Kubernetes 社群的擴充功能。其他人則開發封閉原始碼的商業或特定網站的擴充功能。
最小且最簡單的 Kubernetes 物件。Pod 代表叢集中一組正在執行的容器。
[+]Pod 通常設定為執行單一主要容器。它也可以執行選用的 Sidecar 容器,以新增日誌記錄等補充功能。Pod 通常由Deployment (部署) 管理。
啟用Pod 建立和更新的細緻授權。
[+]叢集層級資源,用於控制 Pod 規格中對安全性敏感的方面。
PodSecurityPolicy
物件定義了一組 Pod 必須在其中執行的條件,才能被系統接受,以及相關欄位的預設值。Pod 安全策略控制作為選用的 Admission Controller 實作。PodSecurityPolicy 已在 Kubernetes v1.21 中棄用,並在 v1.25 中移除。作為替代方案,請使用Pod Security Admission 或第三方 Admission 外掛程式。
- 亦稱為:Pod 範本 (pod template)
定義用於建立Pod 的範本的 API 物件。PodTemplate API 也嵌入在工作負載管理 API 定義中,例如Deployment (部署) 或 StatefulSets (StatefulSets)。
[+]Pod 範本允許您定義常見的 metadata(例如標籤,或新 Pod 名稱的範本),以及指定 Pod 的期望狀態。工作負載管理控制器使用 Pod 範本(嵌入到另一個物件中,例如 Deployment 或 StatefulSet)來定義和管理一個或多個Pod。當可以有多個基於相同範本的 Pod 時,這些 Pod 稱為副本 (replicas)。雖然您可以直接建立 PodTemplate 物件,但您很少需要這樣做。
PriorityClass 是應指派給該類別中 Pod 的排程優先順序的具名類別。
[+]PriorityClass 是一個非命名空間物件,將名稱對應到整數優先順序,用於 Pod。名稱在
metadata.name
欄位中指定,優先順序值在value
欄位中指定。優先順序範圍從 -2147483648 到 1000000000(含)。較高的值表示較高的優先順序。kubelet 定期對 Pod 中執行的容器執行的檢查,它將定義容器的狀態和健康狀況,並通知容器的生命週期。
[+]若要了解更多資訊,請閱讀容器探針 (container probes)。
在電腦運算中,代理是充當遠端服務中介的伺服器。
[+]用戶端與代理互動;代理將用戶端的資料複製到實際的伺服器;實際的伺服器回覆代理;代理將實際伺服器的回覆傳送給用戶端。
kube-proxy 是在叢集中每個節點上執行的網路代理,實作 Kubernetes Service (服務) 概念的一部分。
您可以將 kube-proxy 作為純使用者空間代理服務執行。如果您的作業系統支援,您可以改為在混合模式下執行 kube-proxy,以使用較少的系統資源達到相同的整體效果。
QoS 類別(服務品質類別)為 Kubernetes 提供了一種將叢集內的 Pod 分類為多個類別,並針對排程和驅逐做出決策的方式。
[+]Pod 的 QoS 類別在建立時根據其運算資源請求和限制設定進行設定。QoS 類別用於制定關於 Pod 排程和驅逐的決策。Kubernetes 可以將以下 QoS 類別之一指派給 Pod:
Guaranteed
、Burstable
或BestEffort
。使用 SI 字首表示小數或大數的整數表示法。
[+]數量是使用緊湊的整數表示法和 SI 字首表示小數或大數。小數使用毫 (milli) 單位表示,而大數可以使用千 (kilo)、百萬 (mega) 或十億 (giga) 單位表示。
例如,數字
1.5
表示為1500m
,而數字1000
可以表示為1k
,1000000
表示為1M
。您也可以指定二進制表示法字尾;數字 2048 可以寫成2Ki
。接受的十進制(10 的冪)單位為
m
(毫,milli)、k
(千,kilo,有意使用小寫)、M
(百萬,mega)、G
(十億,giga)、T
(兆,tera)、P
(拍,peta)、E
(艾,exa)。接受的二進制(2 的冪)單位為
Ki
(千位元組,kibi)、Mi
(百萬位元組,mebi)、Gi
(十億位元組,gibi)、Ti
(兆位元組,tebi)、Pi
(拍位元組,pebi)、Ei
(艾位元組,exbi)。管理授權決策,允許管理員透過Kubernetes API 動態配置存取原則。
[+]RBAC 利用角色 (roles)(包含權限規則)和角色綁定 (role bindings)(將角色中定義的權限授予一組使用者)。
ReplicaSet(旨在)隨時維護一組正在執行的副本 Pod。
[+]工作負載物件(例如Deployment (部署))利用 ReplicaSet 來確保根據該 ReplicaSet 的規格,在您的叢集中執行已配置數量的Pod。
一種工作負載資源,用於管理複寫的應用程式,確保執行特定數量的Pod 執行個體。
[+]控制平面確保執行已定義數量的 Pod,即使某些 Pod 失敗、您手動刪除 Pod 或錯誤地啟動太多 Pod。
注意
ReplicationController 已棄用。請參閱Deployment (部署),它與之類似。提供約束,以限制每個命名空間 (Namespace) 的總資源消耗量。
[+]限制可以在命名空間中依類型建立的物件數量,以及該專案中資源可能消耗的運算資源總量。
負責審查專案某些部分程式碼的品質和正確性的人員。
[+]審閱者對程式碼庫和軟體工程原理都很了解。審閱者身分會限定在程式碼庫的某一部分。
儲存敏感資訊,例如密碼、OAuth 權杖和 SSH 金鑰。
[+]Secret 可讓您更好地控制敏感資訊的使用方式,並降低意外洩漏的風險。Secret 值編碼為 base64 字串,預設為未加密儲存,但可以配置為靜態加密。
Pod 可以透過多種方式參考 Secret,例如在卷掛載中或作為環境變數。Secret 專為機密資料設計,而ConfigMap (配置檔) 則專為非機密資料設計。
允許使用者根據標籤 (labels) 篩選資源列表。
[+]在查詢資源列表以依標籤篩選它們時,會套用選擇器。
一種公開網路應用程式的方法,該應用程式作為叢集中一個或多個 Pod 執行。
[+]Service 定位的 Pod 集合(通常)由選擇器 (selector) 決定。如果新增或移除更多 Pod,則符合選擇器的 Pod 集合將會變更。Service 確保網路流量可以導向到工作負載的目前 Pod 集合。
Kubernetes Service 可以使用 IP 網路(IPv4、IPv6 或兩者),或參考網域名稱系統 (DNS) 中的外部名稱。
Service 抽象化啟用了其他機制,例如 Ingress 和 Gateway。
以前的擴充 API,使在 Kubernetes 叢集中執行的應用程式可以輕鬆使用外部託管軟體產品,例如雲端供應商提供的資料儲存服務。
[+]它提供了一種列出、佈建和繫結外部託管服務 (Managed Services) 的方法,而無需詳細了解如何建立或管理這些服務。
一種將請求分配到佇列的技術,相較於對佇列數量取模雜湊,能提供更好的隔離性。
[+]我們經常關注將不同的請求流彼此隔離,以避免高強度的請求流擠壓低強度的請求流。一種將請求放入佇列的簡單方法是對請求的某些特徵進行雜湊處理,然後對佇列數量取模,以取得要使用的佇列索引。雜湊函數使用與請求流對齊的請求特徵作為輸入。例如,在網際網路中,這通常是來源和目的地位址、協定以及來源和目的地埠的五元組。
這種基於簡單雜湊的方案具有以下特性:任何高強度的請求流都會擠壓所有雜湊到相同佇列的低強度請求流。為大量請求流提供良好的隔離需要大量的佇列,這是有問題的。洗牌分片是一種更靈活的技術,可以更好地將低強度請求流與高強度請求流隔離。洗牌分片的術語使用了從一副牌中發牌的比喻;每個佇列都是一張隱喻的牌。洗牌分片技術首先對請求的流量識別特徵進行雜湊處理,以產生一個具有數十個或更多位元的雜湊值。然後,雜湊值被用作熵源來洗牌並發一手牌(佇列)。檢查所有發出的佇列,並將請求放入其中一個長度最短的已檢查佇列中。使用適度的手牌大小,檢查所有發出的牌並不會花費太多,並且給定的低強度請求流很有機會避開給定的高強度請求流的影響。使用大的手牌大小,檢查發出的佇列既昂貴,低強度請求流也更難以躲避一組高強度請求流的集體影響。因此,應明智地選擇手牌大小。
在 K8s 社群中持續活躍的社群成員,他們共同管理大型 Kubernetes 開源專案的持續性部分或面向。
[+]SIG 內的成員對推進特定領域(例如架構、API 機制或文件)具有共同的興趣。SIG 必須遵循 SIG 治理指南,但可以有自己的貢獻政策和溝通管道。
如需更多資訊,請參閱 kubernetes/community 儲存庫以及目前的 SIG 和工作組列表。
定義每個物件(如 Pod 或服務)應如何配置及其期望狀態。
[+]幾乎每個 Kubernetes 物件都包含兩個巢狀物件欄位,用於管理物件的配置:物件規格和物件狀態。對於具有規格的物件,您必須在建立物件時設定此規格,提供您希望資源擁有的特徵描述:其期望狀態。
它因不同的物件(如 Pod、StatefulSet 和服務)而異,詳細說明了諸如容器、磁碟區、副本、埠等設定,
以及每個物件類型特有的其他規格。此欄位封裝了 Kubernetes 應為已定義的狀態維護的內容
物件。管理一組 Pod 的部署和擴展,並提供關於這些 Pod 的順序和唯一性的保證。
[+]與 Deployment 類似,StatefulSet 管理基於相同容器規格的 Pod。與 Deployment 不同,StatefulSet 為其每個 Pod 維護黏性身分。這些 Pod 是從相同的規格建立的,但不可互換:每個 Pod 都有一個持久性識別符,在任何重新排程中都會維護該識別符。
如果您想使用儲存磁碟區為您的工作負載提供持久性,您可以將 StatefulSet 作為解決方案的一部分使用。儘管 StatefulSet 中的個別 Pod 容易發生故障,但持久性 Pod 識別符可以更輕鬆地將現有的磁碟區與替換任何已故障 Pod 的新 Pod 進行匹配。
StorageClass 為管理員提供了一種描述不同可用儲存類型的方法。
[+]StorageClass 可以對應到服務品質等級、備份策略或叢集管理員決定的任意策略。每個 StorageClass 都包含欄位
provisioner
、parameters
和reclaimPolicy
,當需要動態佈建屬於該類別的 Persistent Volume 時會使用這些欄位。使用者可以使用 StorageClass 物件的名稱請求特定的類別。Kubernetes 系統產生的字串,用於唯一識別物件。
[+]在 Kubernetes 叢集的整個生命週期中建立的每個物件都有一個獨特的 UID。它旨在區分相似實體的歷史事件。
一個動詞,用於以串流方式追蹤 Kubernetes 中物件的變更。它用於有效偵測變更。
[+]一個動詞,用於以串流方式追蹤 Kubernetes 中物件的變更。監看允許有效偵測變更;例如,需要知道 ConfigMap 何時變更的控制器可以使用監看而不是輪詢。
請參閱API 概念中有效偵測變更以取得更多資訊。
促進委員會、SIG 或跨 SIG 工作在短期、狹隘或解耦專案的討論和/或實作。
[+]工作組是一種組織人員以完成離散任務的方式。
如需更多資訊,請參閱 kubernetes/community 儲存庫以及目前的 SIG 和工作組列表。
工作負載是在 Kubernetes 上執行的應用程式。
[+]代表不同類型或工作負載部分的各種核心物件包括 DaemonSet、Deployment、Job、ReplicaSet 和 StatefulSet 物件。
例如,具有 Web 伺服器和資料庫的工作負載可能會在一個 StatefulSet 中執行資料庫,並在 Deployment 中執行 Web 伺服器。
意見回饋
此頁面是否對您有幫助?
感謝您的意見回饋。如果您有關於如何使用 Kubernetes 的具體、可回答的問題,請在 Stack Overflow 上提問。如果您想報告問題或建議改進,請在 GitHub 儲存庫中開啟一個 issue。