k8s——kubernetes專業術語

提筆寫春秋發表於2020-10-07

這裡寫目錄標題

一、專業術語

API Group
Kubernetes API 中的一組相關路徑。
通過更改 API server 的配置,可以啟用或禁用每個 API Group。你還可以禁用或啟用指向特定資源的路徑。API group 使擴充套件 Kubernetes API 更加的容易。API group 在 REST 路徑和序列化物件的 apiVersion 欄位中指定。
cgroup (控制組)一組具有可選資源隔離、審計和限制的 Linux 程式。[-]
Cgroup 是一個 Linux 核心特性,對一組程式的資源使用(CPU、記憶體、磁碟 I/O 和網路等)進行限制、審計和隔離。

CIDRCIDR (無類域間路由) 是一種描述 IP 地址塊的符號,被廣泛使用於各種網路配置中。[-]
在 Kubernetes 的上下文中,每個 節點 以 CIDR 形式(含起始地址和子網掩碼)獲得一個 IP 地址段,從而能夠為每個 Pod 分配一個獨一無二的 IP 地址。雖然其概念最初源自 IPv4,CIDR 已經被擴充套件為涵蓋 IPv6。

CLA (貢獻者許可協議)貢獻者 對他們在開源專案中所貢獻的程式碼的授權許可條款。[-]
CLA 對解決貢獻者在開源社群所貢獻的資料和智力資產(IP)導致的法律糾紛很有幫助。

CNI (容器網路介面)容器網路介面 (CNI) 外掛是遵循 appc/CNI 協議的一類網路外掛。[-]
想了解 Kubernetes 和 CNI 請參考 “網路外掛”。
ConfigMapConfigMap 是一種 API 物件,用來將非機密性的資料儲存到健值對中。使用時可以用作環境變數、命令列引數或者儲存卷中的配置檔案。[-]
ConfigMap 將您的環境配置資訊和 容器映象 解耦,便於應用配置的修改。當您需要儲存機密資訊時可以使用 Secret 物件。
containerd強調簡單性、健壯性和可移植性的一種容器執行時[-]
containerd 是一種 容器 執行時,能在 Linux 或者 Windows 後臺執行。 containerd 能取回、儲存容器映象,執行容器例項,提供網路訪問等。

CRI-O該工具可讓您通過 Kubernetes CRI 使用 OCI 容器執行環境。[-]
CRI-O 是 容器執行時介面 (CRI) 的實現,可啟用與開放容器倡議 Open Container Initiative(OCI)相容的 container 執行環境執行時規範。

部署 CRI-O 允許 Kubernetes 使用任何符合 OCI 執行環境,作為容器執行環境去執行 Pods,並從遠端登錄檔獲取 OCI 容器映象。

CronJob管理定期執行的 Job。[-]
Cronjob 物件類似 crontab 檔案中的一行命令,它宣告瞭一個遵循 Cron 格式的排程任務。

CustomResourceDefinition通過定製化的程式碼給您的 Kubernetes API 伺服器增加資源物件,而無需編譯完整的定製 API 伺服器。[-]
當 Kubernetes 公開支援的 API 資源不能滿足您的需要時,定製資源物件(Custom Resource Definitions)讓您可以在您的環境上擴充套件 Kubernetes API。
DaemonSet確保 Pod 的副本在叢集中的一組節點上執行。[-]
用來部署系統守護程式,例如日誌蒐集和監控代理,這些程式通常必須執行在每個節點上。

DeploymentDeployment 是管理應用副本的 API 物件。[-]
應用的每個副本就是一個 Pod,並且這些 Pod 會分散執行在叢集的節點上。

dockerDocker 是一種可以提供作業系統級別虛擬化(也稱作容器)的軟體技術[-]
Docker 使用了 Linux 核心中的資源隔離特性(如 cgroup 和核心名稱空間)以及支援聯合檔案系統(如 OverlayFS 和其他),允許多個相互獨立的“容器”一起執行在同一 Linux 例項上,從而避免啟動和維護虛擬機器(VMs)的開銷。

EndpointsEndpoints track the IP addresses of Pods with matching selectors.[-]
Endpoints can be configured manually for Services without selectors specified. The EndpointSlice resource provides a scalable and extensible alternative to Endpoints.

etcdetcd 是兼具一致性和高可用性的鍵值資料庫,可以作為儲存 Kubernetes 所有叢集資料的後臺資料庫。[-]
您的 Kubernetes 叢集的 etcd 資料庫通常需要有個備份計劃。要了解 etcd 更深層次的資訊,請參考 etcd 文件。

FlexVolumeFlexvolume 是建立 out-of-tree 卷外掛的一種介面。 容器儲存介面(CSI) 是比 Flexvolume 更新的介面,它解決了 Flexvolume 的一些問題。[-]
Flexvolume 允許使用者編寫自己的驅動程式,並在 Kubernetes 中加入對使用者自己的資料卷的支援。FlexVolume 驅動程式的二進位制檔案和依賴項必須安裝在主機上。這需要 root 許可權。如果可能的話,SIG Storage 建議實現 CSI 驅動程式,因為它解決了 Flexvolumes 的限制。

Helm ChartHelm Chart 是一組預先配置的 Kubernetes 資源所構成的包,可以使用 Helm 工具對其進行管理。[-]
Chart 提供了一種可重現的用來建立和共享 Kubernetes 應用的方法。 單個 Chart 可用來部署簡單的系統(例如一個 memcached Pod),也可以用來部署複雜的系統(例如包含 HTTP 伺服器、資料庫、快取等元件的完整 Web 應用堆疊)。

HostAliases主機別名 (HostAliases) 是一組 IP 地址和主機名的對映,用於注入到 Pod 內的 hosts 檔案。[-]
HostAliases 是一個包含主機名和 IP 地址的可選列表,配置後將被注入到 Pod 內的 hosts 檔案中。 該選項僅適用於沒有配置 hostNetwork 的 Pod.

IngressIngress 是對叢集中服務的外部訪問進行管理的 API 物件,典型的訪問方式是 HTTP。[-]
Ingress 可以提供負載均衡、SSL 終結和基於名稱的虛擬託管。

IstioIstio 是個開放平臺(非 Kubernetes 特有),提供了一種統一的方式來整合微服務、管理流量、實施策略和彙總度量資料。[-]
新增 Istio 時不需要修改應用程式碼。它是基礎設施的一層,介於服務和網路之間。當它和服務的 Deployment 相結合時,就構成了通常所謂的服務網格(Service Mesh)。Istio 的控制面抽象掉了底層的叢集管理平臺,這一叢集管理平臺可以是 Kubernetes、Mesosphere 等。
JobJob 是需要執行完成的確定性的或批量的任務。[-]
Job 建立一個或多個 Pod 物件,並確保指定數量的 Pod 成功終止。隨著各 Pod 成功結束,Job 會跟蹤記錄成功完成的個數。

Kopskops 是一個命令列工具,可以幫助您建立、銷燬、升級和維護生產級,高可用性的 Kubernetes 叢集。注意:官方僅支援 AWS,GCE 和 VMware vSphere 的支援還處於 alpha 階段。[-]
kops 為您的叢集提供了:

全自動化安裝
基於 DNS 的叢集標識
自愈功能:所有元件都在自動伸縮組(Auto-Scaling Groups)中執行
有限的作業系統支援 (推薦使用 Debian,支援 Ubuntu 16.04,試驗性支援 CentOS & RHEL)
高可用 (HA) 支援
直接提供或者生成 Terraform 清單檔案的能力
您也可以將自己的叢集作為一個構造塊,使用 Kubeadm 構造叢集。kops 是建立在 kubeadm 之上的。

kube-apiserver主節點上負責提供 Kubernetes API 服務的元件;它是 Kubernetes 控制面的前端。[-]
kube-apiserver 在設計上考慮了水平擴縮的需要。 換言之,通過部署多個例項可以實現擴縮。 參見構造高可用叢集。

kube-controller-manager在主節點上執行控制器的元件。[-]
從邏輯上講,每個控制器都是一個單獨的程式,但是為了降低複雜性,它們都被編譯到同一個可執行檔案,並在一個程式中執行。

kube-proxykube-proxy 是叢集中每個節點上執行的網路代理,實現 Kubernetes Service 概念的一部分。[-]
kube-proxy 維護節點上的網路規則。這些網路規則允許從叢集內部或外部的網路會話與 Pod 進行網路通訊。

如果作業系統提供了資料包過濾層並可用的話,kube-proxy會通過它來實現網路規則。否則,kube-proxy 僅轉發流量本身。

kube-scheduler主節點上的元件,該元件監視那些新建立的未指定執行節點的 Pod,並選擇節點讓 Pod 在上面執行。[-]
排程決策考慮的因素包括單個 Pod 和 Pod 集合的資源需求、硬體/軟體/策略約束、親和性和反親和性規範、資料位置、工作負載間的干擾和最後時限。

Kubeadm用來快速安裝 Kubernetes 並搭建安全穩定的叢集的工具。[-]
您可以使用 kubeadm 安裝控制面和工作節點元件。

Kubectlkubectl 是用來和 Kubernetes API 伺服器進行通訊的命令列工具。[-]
您可以使用 kubectl 建立、檢查、更新和刪除 Kubernetes 物件。

Kubelet一個在叢集中每個節點上執行的代理。它保證容器都執行在 Pod 中。[-]
kubelet 接收一組通過各類機制提供給它的 PodSpecs,確保這些 PodSpecs 中描述的容器處於執行狀態且健康。kubelet 不會管理不是由 Kubernetes 建立的容器。

Kubernetes APIKubernetes API 是通過 RESTful 介面提供 Kubernetes 功能服務並負責叢集狀態儲存的應用程式。[-]
Kubernetes 資源和"意向記錄"都是作為 API 物件儲存的,並可以通過對 API 的 RESTful 呼叫進行修改。 API 允許以宣告方式管理配置。 使用者可以直接和 Kubernetes API 互動,也可以通過 kubectl 這樣的工具進行互動。 核心的 Kubernetes API 是很靈活的,可以擴充套件以支援定製資源。

LimitRange提供約束來限制名稱空間中每個 容器 或 Pod 的資源消耗。[-]
LimitRange 按照型別來限制名稱空間中物件能夠建立的數量,以及單個 容器 或 Pod 可以請求/使用的計算資源量。

ManifestSpecification of a Kubernetes API object in JSON or YAML format.[-]
A manifest specifies the desired state of an object that Kubernetes will maintain when you apply the manifest. Each configuration file can contain multiple manifests.

Master遺留術語,作為執行 控制平面 的 節點 的同義詞使用。[-]
該術語仍被一些配置工具使用,如 kubeadm 以及託管的服務,為 節點 新增 kubernetes.io/role 的 標籤,以及管理控制平面 Pod 的排程。

MinikubeMinikube 是用來在本地執行 Kubernetes 的一種工具。[-]
Minikube 在使用者計算機上的一個虛擬機器內執行單節點 Kubernetes 叢集。

Operator 模式operator 模式 是一個系統設計, 將 控制器 關聯到一個或多個自定義資源。[-]
除了使用作為 Kubernetes 自身一部分的內建控制器之外,您還可以通過將控制器新增到叢集中來擴充套件 Kubernetes。

如果正在執行的應用程式能夠充當控制器並通過 API 訪問的方式來執行任務操控那些在控制平面中定義的自定義資源,這就是一個 operator 模式的示例。

PodPod 是 Kubernetes 的原子物件。Pod 表示您的叢集上一組正在執行的容器。[-]
通常建立 Pod 是為了執行單個主容器。Pod 還可以執行可選的掛斗(sidecar)容器,以新增諸如日誌記錄之類的補充特性。通常用 Deployment 來管理 Pod。

Pod Disruption Budget亦稱作:PDB
An object that limits the number of PodsPod 是 Kubernetes 的原子物件。Pod 表示您的叢集上一組正在執行的容器。 of a replicated application, that are down simultaneously from voluntary disruptions. aka: - PDB related: - pod - container tags: - operation — – Pod Disruption Budget 使應用所有者能夠為多例項應用建立一個物件,來確保一定數量的具有指定標籤的 Pod 在任何時候都不會被主動驅逐。 PDB 無法防止非主動的中斷,但是會計入預算(budget)。 [-]
Pod Disruption Budget 使應用所有者能夠為多例項應用建立一個物件,來確保一定數量的具有指定標籤的 Pod 在任何時候都不會被主動驅逐。 PDB 無法防止非主動的中斷,但是會計入預算(budget)。

Pod 優先順序Pod 優先順序表示一個 Pod 相對於其他 Pod 的重要性。[-]
Pod 優先順序 允許為一個 Pod 設定高於或低於其他 Pod 的優先順序 – 這對於生產叢集工作負載而言是一個重要的特性。

Pod 安全策略為 Pod 的建立和更新操作啟用細粒度的授權。[-]
Pod 安全策略是叢集級別的資源,它控制著 Pod 規約中的安全性敏感的內容。 PodSecurityPolicy物件定義了一組條件以及相關欄位的預設值,Pod 執行時必須滿足這些條件。Pod 安全策略控制實現上體現為一個可選的准入控制器。

Pod 水平自動擴縮器Pod 水平自動擴縮器(Horizontal Pod Autoscaler)是一種 API 資源,它根據目標 CPU 利用率或自定義度量目標擴縮 Pod 副本的數量。[-]
HPA 通常用於 Replication Controllers、Deployments 或者 Replica Sets 上。HPA 不能用於不支援擴縮的物件,例如 DaemonSets。

Pod 生命週期關於 Pod 在其生命週期中處於哪個階段的更高層次概述。[-]
Pod 生命週期 是關於 Pod 在其生命週期中處於哪個階段的更高層次概述。Pod 的status 欄位是 PodStatus 物件, 該物件的 phase 欄位包含了下面的狀態: Running、Pending、Succeeded、Failed、Unknown、Completed 或 CrashLoopBackOff。

PodPresetPodPreset 是一種 API 物件,在建立 Pod 時將諸如 Secret、卷掛載和環境變數之類的資訊注入到該 Pod 中。[-]
此 API 物件使用標準選擇器選擇 Pod 並向其中注入資訊。這允許 podspec 定義是非特定的,從而將 podspec 與環境特定的配置解耦。

QoS 類QoS Class(Quality of Service Class)為 Kubernetes 提供了一種將叢集中的 Pod 分為幾個型別並做出有關排程和驅逐決策的方法。[-]
Pod 的 QoS 類是基於 Pod 在建立時配置的計算資源請求和限制。QoS 類用於制定有關 Pod 排程和逐出的決策。 Kubernetes 可以為 Pod 分配以下 QoS 類:Guaranteed,Burstable 或者 BestEffort。

RBAC(基於角色的訪問控制)管理授權決策,允許管理員通過 Kubernetes API 動態配置訪問策略。[-]
RBAC 使用 角色 (包含許可權規則)和 角色繫結 (將角色中定義的許可權授予一組使用者)。

ReplicaSetReplicaSet 是下一代副本控制器。[-]
ReplicaSet 就像 ReplicationController 那樣,確保一次執行指定數量的 Pod 副本。ReplicaSet 支援新的基於集合的選擇器需求(在標籤的使用者指南中有相關描述),而副本控制器只支援基於等值的選擇器需求。

Replication ControllerReplication Controller 是 Kubernetes 的一種服務,用來確保給定個數的 Pod 一直處於執行狀態。[-]
Replication Controller 會基於設定值自動增刪 Pod 的例項。如果 Pod 被誤刪除或者啟動例項過多,Replication Controller 允許 Pod 的例項個數恢復到設定值。

rkt一個安全的、基於標準的容器引擎。[-]
rkt 是一個應用程式 容器 引擎,它具有原生的 {< glossary_tooltip text=“Pod” term_id=“pod” >}} 方法、可插拔的執行環境和定義良好的介面。rkt 允許使用者在 Pod 和應用程式級別應用不同的配置。每個 Pod 在一個自包含的、獨立的經典 Unix 程式模型中直接執行。

SecretSecret 用於儲存敏感資訊,如密碼、OAuth 令牌和 SSH 金鑰。[-]
Secret 允許使用者對如何使用敏感資訊進行更多的控制,並減少資訊意外暴露的風險,包括靜態加密。 Pod 通過掛載卷中的檔案的方式引用 Secret,或者通過 kubelet 為 pod 拉取映象時引用。 Secret 非常適合機密資料使用,而 ConfigMaps 適用於非機密資料。

Service將執行在一組 Pods 上的應用程式公開為網路服務的抽象方法。[-]
服務所針對的Pod集(通常)由 selector 確定。 如果新增或刪除了更多Pod,則與選擇器匹配的Pod集將發生變化。 該服務確保可以將網路流量定向到該工作負載的當前Pod集。

shuffle shardingA technique for assigning requests to queues that provides better isolation than hashing modulo the number of queues.[-]
We are often concerned with insulating different flows of requests from each other, so that a high-intensity flow does not crowd out low-intensity flows. A simple way to put requests into queues is to hash some characteristics of the request, modulo the number of queues, to get the index of the queue to use. The hash function uses as input characteristics of the request that align with flows. For example, in the Internet this is often the 5-tuple of source and destination address, protocol, and source and destination port.

That simple hash-based scheme has the property that any high-intensity flow will crowd out all the low-intensity flows that hash to the same queue. Providing good insulation for a large number of flows requires a large number of queues, which is problematic. Shuffle sharding is a more nimble technique that can do a better job of insulating the low-intensity flows from the high-intensity flows. The terminology of shuffle sharding uses the metaphor of dealing a hand from a deck of cards; each queue is a metaphorical card. The shuffle sharding technique starts with hashing the flow-identifying characteristics of the request, to produce a hash value with dozens or more of bits. Then the hash value is used as a source of entropy to shuffle the deck and deal a hand of cards (queues). All the dealt queues are examined, and the request is put into one of the examined queues with the shortest length. With a modest hand size, it does not cost much to examine all the dealt cards and a given low-intensity flow has a good chance to dodge the effects of a given high-intensity flow. With a large hand size it is expensive to examine the dealt queues and more difficult for the low-intensity flows to dodge the collective effects of a set of high-intensity flows. Thus, the hand size should be chosen judiciously.

SIG (特別興趣小組)共同管理大範疇 Kubernetes 開源專案中某元件或方面的一組社群成員。[-]
SIG 中的成員對推進某個領域(如體系結構、API 機制構件或者文件)具有相同的興趣。 SIGs 必須遵從 SIG Governance 的規定, 不過可以有自己的貢獻策略以及通訊渠道(方式)。

更多的詳細資訊可參閱 kubernetes/community 倉庫以及 SIGs 和工作組(Working Groups)的最新列表。

StatefulSetStatefulSet 用來管理 Deployment 和擴充套件一組 Pod,並且能為這些 Pod 提供序號和唯一性保證。[-]
和 Deployment 相同的是,StatefulSet 管理了基於相同容器定義的一組 Pod。但和 Deployment 不同的是,StatefulSet 為它們的每個 Pod 維護了一個固定的 ID。這些 Pod 是基於相同的宣告來建立的,但是不能相互替換:無論怎麼排程,每個 Pod 都有一個永久不變的 ID。

StatefulSet 和其他控制器使用相同的工作模式。你在 StatefulSet 物件 中定義你期望的狀態,然後 StatefulSet 的 控制器 就會通過各種更新來達到那種你想要的狀態。

UIDKubernetes 系統生成的字串,唯一標識物件。[-]
在 Kubernetes 叢集的整個生命週期中建立的每個物件都有一個不同的 uid,它旨在區分類似實體的歷史事件。

Upstream (disambiguation)[-]
可以參考:核心 Kubernetes 倉庫或作為當前倉庫派生來源的來源倉庫。

在 Kubernetes社群:對話中通常使用 upstream 來表示核心 Kubernetes 程式碼庫,也就是更廣泛的 kubernetes 生態系統、其他程式碼或第三方工具所依賴的倉庫。 例如,社群成員可能會建議將某個功能特性貢獻到 upstream,使其位於核心程式碼庫中,而不是維護於外掛或第三方工具中。
在 GitHub 或 git 中:約定是將源倉庫稱為 upstream,而派生的倉庫則被視為 downstream。
WG (工作組)工作組是為了方便討論和(或)推進執行一些短週期、窄範圍、或者從委員會和 SIG 分離出來的專案、以及跨 SIG 的活動。[-]
工作組可以將人們組織起來,一起完成一項分散的任務。它組建簡單,完成任務即可解散。

更多資訊請參考 kubernetes/community 程式碼庫和當前的 SIGs 和工作組 列表。

下游(消除歧義)可以指:Kubernetes 生態系統中依賴於核心 Kubernetes 程式碼庫或分支程式碼庫的程式碼。[-]
在 Kubernetes 社群中:下游(downstream) 在人們交流中常用來表示那些依賴核心 Kubernetes 程式碼庫的生態系統、程式碼或者第三方工具。例如,Kubernete 的一個新特性可以被下游(downstream) 應用採用,以提升它們的功能性。
在 GitHub 或 git 中:約定用下游(downstream) 表示分支程式碼庫,原始碼庫被認為是上游(upstream)。
臨時容器您可以在 Pod 中臨時執行的一種 容器 型別[-]
如果想要調查執行中有問題的 Pod,可以向該 Pod 新增一個臨時容器並進行診斷。臨時容器沒有資源或排程保證,因此不應該使用它們來執行任何部分的工作負荷本身。

雲供應商雲供應商是提供可以用來執行 Kubernetes 叢集的雲端計算平臺的公司。[-]
雲供應商也叫雲服務供應商(CSPs),他們可以為使用者提供雲端計算平臺。他們提供的服務可以是基礎設施即服務(IaaS)或者平臺即服務(PaaS)。雲供應商除了執行 Kubernetes 叢集,還提供一些叢集互動的服務,例如負載均衡(Load Balancers)、儲存類別(Storage Classes)等。

雲原生計算基金會 (CNCF)雲原生計算基金會(CNCF)建立了可持續的生態系統,並在圍繞著 專案 建立一個社群,將容器編排微服務架構的一部分。Kubernetes 是一個雲原生計算基金會專案.[-]
雲原生計算基金會(CNCF)是 Linux 基金會 的下屬基金會。它的使命是讓雲原生計算無處不在。

雲控制器管理器雲控制器管理器是 1.8 的 alpha 特性。在未來發布的版本中,這是將 Kubernetes 與任何其他雲整合的最佳方式。[-]
Kubernetes v1.6 包含一個新的可執行檔案叫做 cloud-controller-manager。cloud-controller-manager 是一個守護程式,其中嵌入了特定於某雲環境的控制環。 這些特定於雲環境的控制環最初位於 kube-controller-manager 中。 由於雲供應商的開發和釋出節奏與 Kubernetes 專案不同步,將特定於供應商的程式碼抽象到 cloud-controller-manager 可執行檔案可以允許雲供應商獨立於核心 Kubernetes 程式碼進行演進。

代理在計算機領域,代理指的是充當遠端服務中介的伺服器。[-]
客戶端與代理進行互動;代理將客戶端的資料複製到實際伺服器;實際伺服器回覆代理;代理將實際伺服器的回覆傳送給客戶端。

kube-proxy 是叢集中每個節點上執行的網路代理,實現了部分 Kubernetes Service 概念。

你可以將 kube-proxy 作為普通的使用者態代理服務執行。 如果你的作業系統支援,則可以在混合模式下執行 kube-proxy;該模式使用較少的系統資源即可達到相同的總體效果。

程式碼貢獻者為 Kubernetes 開原始碼庫開發並貢獻程式碼的人。[-]
程式碼貢獻者也是加入一個或多個 特別興趣小組 (SIGs) 的活躍的 社群成員。

准入控制器在物件持久化之前攔截 Kubernetes Api 伺服器請求的一段程式碼[-]
准入控制器可針對 Kubernetes Api 伺服器進行配置,可以執行驗證,變更或兩者都執行。任何准入控制器都可以拒絕訪問請求。 變更(mutating)控制器可以修改其允許的物件,驗證(validating)控制器則不可以。

初始化容器應用容器執行前必須先執行完成的一個或多個初始化容器。[-]
初始化(init)容器像常規應用容器一樣,只有一點不同:初始化(init)容器必須在應用容器啟動前執行完成。Init 容器的執行順序:一個初始化(init)容器必須在下一個初始化(init)容器開始前執行完成。

動態卷供應允許使用者請求自動建立儲存 卷。[-]
動態供應讓叢集管理員無需再預先供應儲存。相反,它通過使用者請求自動地供應儲存。 動態卷供應是基於 API 物件 StorageClass 的,StorageClass 可以引用 卷外掛(Volume Plugin) 提供的 卷(Volume) ,也可以引用傳遞給卷外掛(Volume Plugin)的引數集。

捲包含可被 pod 中容器訪問的資料的目錄。[-]
每個 Kubernetes 卷在所處的pod 存在期間保持存在狀態。 因此,卷的生命期會超出 pod 中執行的容器, 並且保證容器重啟之後仍保留資料。

卷(Volume)外掛卷外掛可以讓 Pod 整合儲存。[-]
卷外掛讓您能給 Pod 附加和掛載儲存卷。卷外掛既可以是 in tree 也可以是 out of tree 。in tree 外掛是 Kubernetes 程式碼庫的一部分,並遵循其釋出週期。而 Out of tree 外掛則是獨立開發的。

名稱客戶端提供的字串,引用資源 url 中的物件,如/api/v1/pods/some name。[-]
一次只能有一個給定型別的物件具有給定的名稱。但是,如果刪除物件,則可以建立同名的新物件。

名稱空間名稱空間是 Kubernetes 為了在同一物理叢集上支援多個虛擬叢集而使用的一種抽象。[-]
名稱空間用來組織叢集中物件,併為叢集資源劃分提供了一種方法。同一名稱空間內的資源名稱必須唯一,但跨名稱空間時不作要求。

儲存類別StorageClass 是管理員用來描述不同的可用儲存型別的一種方法。[-]
StorageClass 可以對映到服務質量等級(QoS)、備份策略、或者管理員隨機定義的策略。每個 StorageClass 物件包含的域有 provisioner、 parameters 和 reclaimPolicy,屬於該儲存類別的 永久卷 需要動態分配時就要用到這些域引數。通過 StorageClass 物件的名稱,使用者可以請求他們需要的特定儲存類別。

安全上下文(Security Context)securityContext 欄位定義 Pod 或容器的特權和訪問控制設定,包括執行時 UID 和 GID。[-]
Pod 或者容器中的 securityContext 欄位(應用於所有容器)用於設定容器程式使用的使用者(runAsUser)和組 (fsGroup)、權能字、特權設定和安全策略(SELinux/AppArmor/Seccomp)。

容器容器是可移植、可執行的輕量級的映象,映象中包含軟體及其相關依賴。[-]
容器使應用和底層的主機基礎設施解耦,降低了應用在不同雲環境或者作業系統上的部署難度,便於應用擴充套件。

容器儲存介面 (CSI)容器儲存介面 (CSI)定義了儲存系統暴露給容器的標準介面。[-]
CSI 允許儲存驅動提供商為 Kubernetes 建立定製化的儲存外掛,而無需將這些外掛的程式碼新增到 Kubernetes 程式碼倉庫(外部外掛)。要使用某個儲存提供商的 CSI 驅動,你首先要將它部署到你的叢集上。然後你才能建立使用該 CSI 驅動的 Storage Class 。

Kubernetes 文件中關於 CSI 的描述
可用的 CSI 驅動列表
容器環境變數容器環境變數提供了執行容器化應用所必須的一些重要資訊。[-]
容器環境變數為執行中的容器化應用提供必要的資訊,同時還提供與 容器 重要資源相關的其他資訊,例如:檔案系統資訊、容器自身的資訊以及其他像服務端點(Service endpoints)這樣的叢集資源資訊。

容器生命週期鉤子生命週期鉤子暴露容器管理生命週期中的事件,允許使用者在事件發生時執行程式碼。[-]
針對容器暴露了兩個鉤子:PostStart 在容器建立之後立即執行,PreStop 在容器停止之前立即阻塞並被呼叫。

容器執行時介面 (CRI)容器執行時介面 (CRI) 是一組與節點上 kubelet 整合的容器執行時 API[-]
更多資訊, 請參考 容器執行時介面 API 與規格。

容器執行環境(Container Runtime)容器執行環境是負責執行容器的軟體。[-]
Kubernetes 支援多個容器執行環境: Docker、 containerd、cri-o、 rktlet 以及任何實現 Kubernetes CRI (容器執行環境介面)。

容忍度一個核心物件,由三個必需的屬性組成:key、value 和 effect。 容忍度允許將 Pod 排程到具有匹配 汙點 的節點或節點組上。[-]
容忍度 和 汙點 共同作用以確保不會將 Pod 排程在不適合的節點上。在同一 pod 上可以設定一個或者多個容忍度。容忍度表示在匹配節點或節點組上的 汙點 排程 pod 是允許的(但不必要)。

工作負載工作負載是在 Kubernetes 上執行的應用程式。[-]
代表不同型別或部分工作負載的各種核心物件包括 DaemonSet, Deployment, Job, ReplicaSet, and StatefulSet。

例如,具有 Web 伺服器和資料庫的工作負載可能在一個 StatefulSet 中執行資料庫,而 Web 伺服器執行在 Deployment。

干擾干擾是指導致一個或者多個 Pod 服務停止的事件。 干擾會影響工作負載資源,比如 Deployment 這種依賴於受影響 Pod 的資源。[-]
如果您作為一個叢集操作人員,銷燬了一個從屬於某個應用的 Pod, Kubernetes 視之為 自願干擾。如果由於節點故障 或者影響更大區域故障的斷電導致 Pod 離線,Kubrenetes 視之為 非願干擾。

平臺開發者定製 Kubernetes 平臺以滿足自己的專案需求的人。[-]
例如,平臺開發人員可以使用定製資源或使用匯聚層擴充套件 Kubernetes API 來為其 Kubernetes 例項增加功能,特別是為其應用程式新增功能。一些平臺開發人員也是 Kubrenetes 貢獻者,他們會開發貢獻給 Kubernetes 社群的擴充套件;另一些則開發封閉原始碼的商業擴充套件或用於特定功能的擴充套件。

應用The layer where various containerized applications run. aka: tags: - fundamental — – 各種容器化應用執行所在的層。 [-]
各種容器化應用執行所在的層。

應用開發者編寫可以在 Kubernetes 叢集上執行的應用的人。[-]
應用開發者專注於應用的某一部分。他們工作範圍的大小有明顯的差異。

應用架構師應用架構師是負責應用高階設計的人。[-]
應用架構師確保應用的實現允許它和周邊元件進行可擴充套件的、可持續的互動。周邊元件包括資料庫、日誌基礎設施和其他微服務。

應用程式容器應用程式容器(或 app 容器)容器 在 pod 中,在 初始化容器 啟動完畢後才開始啟動。[-]
初始化容器使您可以分離對於 工作負載 整體而言很重要的初始化細節,並且一旦應用容器啟動,它不需要繼續執行。 如果 pod 沒有配置任何初始化容器,則該 pod 中的所有容器都是應用程式容器。

開發者 (釋疑)指的是: 應用開發者、 程式碼貢獻者、或 平臺開發者。[-]
根據上下文的不同,“開發者”這個被多處使用的詞條會有不同的含義。

成員K8s 社群中持續活躍的貢獻者。[-]
可以將問題單(issue)和 PR 指派給成員,成員也可以通過 GitHub 小組加入 特別興趣小組 (SIGs)。針對成員所提交的 PR,系統自動執行提交前測試。成員應該是持續活躍的社群貢獻者。

託管服務由第三方供應商負責維護的一種軟體產品。[-]
託管服務的一些例子有 AWS EC2、Azure SQL 資料庫和 GCP Pub/Sub 等, 不過它們也可以是可以被某應用使用的任何軟體交付件。 服務目錄提供了一種方法用來列舉、供應和繫結到 服務代理商所提供的託管服務。

擴充套件元件擴充套件元件是擴充套件並與 Kubernetes 深度整合以支援新型硬體的軟體元件。[-]
大多數叢集管理員會使用託管的 Kubernetes 或其某種發行包。因此,大多數 Kubernetes 使用者將需要安裝 擴充套件元件,較少使用者會需要編寫新的擴充套件元件。

批准者可以稽核並批准 Kubernetes 程式碼貢獻的人。[-]
程式碼稽核的重點是程式碼質量和正確性,而批准的重點是對貢獻的整體接受。 整體接受包括向後/向前相容性、遵守 API 和引數約定、細微的效能和正確性問題、與系統其他部分的互動等。 批准者狀態的作用域是程式碼庫的一部分。 審批者以前被稱為維護者。
搶佔Kubernetes 中的搶佔邏輯通過驅逐節點上的低優先順序 Pod 來幫助掛起的 Pod 找到合適的節點。[-]
如果一個 Pod 無法排程,排程器會嘗試搶佔較低優先順序的 Pod,以使得掛起的 Pod 可能被排程。

持久卷持久卷是代表叢集中一塊儲存空間的 API 物件。 它是通用的、可插拔的、並且不受單個 Pod 生命週期約束的持久化資源。[-]
持久卷(PersistentVolumes,PV)提供了一個 API,該 API 對儲存的供應方式細節進行抽象,令其與使用方式相分離。 在提前建立儲存(靜態供應)的場景中,PV 可以直接使用。 在按需提供儲存(動態供應)的場景中,需要使用 PersistentVolumeClaims (PVCs)。

持久卷申領申領持久卷中定義的儲存資源,以便可以將其掛載為容器中的卷。[-]
指定儲存的數量,如何訪問儲存(只讀、讀寫或獨佔)以及如何回收儲存(保留、回收或刪除)。儲存本身的詳細資訊在 PersistentVolume 規範中。

控制器控制器通過 apiserver 監控叢集的公共狀態,並致力於將當前狀態轉變為期望的狀態。[-]
Kubernetes 當前提供的部分控制器例子包括:副本控制器(replication controller)、端點控制器(endpoints controller)、名稱空間控制器(namespace controller)、服務賬號控制器(serviceaccounts controller)。

控制平面The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. aka: tags: - fundamental — – 容器編排層,它暴露 API 和介面來定義、部署容器和管理容器的生命週期。 [-]
容器編排層,它暴露 API 和介面來定義、部署容器和管理容器的生命週期。

資料平面提供諸如 CPU,記憶體,網路和儲存的能力,以便容器可以執行並連線到網路。[-]
數量[-]
數量是使用緊湊的整數表示法的小數或大數的表示,並帶有國際計量單位制(SI)字尾。 小數用 milli 單位表示,而大數用 kilo、mega 或 giga 單位表示。

例如,數字 1.5 表示為1500m, 而數字1000表示為1k,1000000表示為1M。 您還可以指定二進位制表示法字尾; 數字 2048 可以寫成2Ki。

公認的十進位制(10的冪)單位是 m(milli)、k(kilo, 有意小寫)、M(mega),G(giga)、T(terra)、P(peta)、 E(exa)。

公認的二進位制(2的冪)單位是 Ki (kibi)、 Mi (mebi)、Gi (gibi)、 Ti (tebi)、 Pi (pebi)、 Ei (exbi)。

日誌日誌是 叢集 或應用程式記錄的事件列表。[-]
應用程式和系統日誌可以幫助您瞭解叢集內部發生的情況。日誌對於除錯問題和監視叢集活動非常有用。

服務代理(Service Broker)由第三方提供並維護的一組託管服務 的訪問端點。[-]
服務代理會實現 開放服務代理 API 規範 併為應用提供使用其託管服務的標準介面。 服務目錄(Service Catalog)則提供一種方法,用來列舉、供應和繫結服務代理商所提供的託管服務。

服務目錄服務目錄(Service Catalog)是一種擴充套件 API,它能讓 Kubernetes 叢集中執行的應用易於使用外部託管的的軟體服務,例如雲供應商提供的資料倉儲服務。[-]
服務目錄可以檢索、供應、和繫結由 服務代理人(Service Brokers) 提供的外部 託管服務,而無需知道那些服務具體是怎樣建立和託管的。

服務賬戶為在 Pod 中執行的程式提供標識。[-]
當 Pod 中的程式訪問叢集時,API 伺服器將它們作為特定的服務帳戶進行身份驗證,例如 default。當您建立 Pod 時,如果您沒有指定服務帳戶,它將在相同的名稱空間 名稱空間 中自動分配 default 服務賬戶。

標籤用來為物件設定可標識的屬性標記;這些標記對使用者而言是有意義且重要的。[-]
標籤是一些關聯到 Pods 這類物件上的鍵值對。 它們通常用來組織和選擇物件子集。

汙點一個核心物件,由三個必需的屬性組成:鍵,值和效果。汙點會阻止在節點或節點組上排程 Pod。[-]
汙點和 容忍度 一起工作,以確保不會將 Pod 排程到不適合的節點上。一個或多個汙點應用於 節點。節點應該僅能排程那些帶著能與汙點相匹配容忍度的 pod。

註解註解是以鍵值對的形式給資源物件附加隨機的無法標識的後設資料。[-]
註解中的後設資料可大可小,可以是結構化的也可以是非結構化的,並且能包含標籤不允許使用的字元。像工具和軟體庫這樣的客戶端可以檢索這些後設資料。

清單JSON 或 YAML 格式的 Kubernetes API 物件規範。[-]
端點切片一種將網路端點與 Kubernetes 資源組合在一起的方法。[-]
一種將網路端點組合在一起的可擴縮、可擴充套件方式。它們將被 kube-proxy 用於在每個 節點 上建立網路路由。

網路策略網路策略是一種規範,規定了允許 Pod 組之間、Pod 與其他網路端點之間以怎樣的方式進行通訊。[-]
網路策略幫助您宣告式地配置允許哪些 Pod 之間接、哪些名稱空間之間允許進行通訊,並具體配置了哪些埠號來執行各個策略。NetworkPolicy 資源使用標籤來選擇 Pod,並定義了所選 Pod 可以接受什麼樣的流量。網路策略由網路提供商提供的並被 Kubernetes 支援的網路外掛實現。請注意,當沒有控制器實現網路資源時,建立網路資源將不會生效。

聚合層聚合層允許您在自己的叢集上安裝額外的 Kubernetes 風格的 API。[-]
當您配置了 Kubernetes API Server 來 支援額外的 API,您就可以在 Kubernetes API 中增加 APIService 物件來 “申領(Claim)” 一個 URL 路徑。

節點Kubernetes 中的工作機器稱作節點。[-]
工作機器可以是虛擬機器也可以是物理機,取決於叢集的配置。 其上部署了執行 Pods 所必需的服務, 並由主控元件來管理。 節點上的服務包括 Docker、kubelet 和 kube-proxy。

證書證書是個安全加密檔案,用來確認對 Kubernetes 叢集訪問的合法性。[-]
證書可以讓 Kubernetes 叢集中執行的應用程式安全的訪問 Kubernetes API。證書可以確認客戶端是否被允許訪問 API。

評審者評審者是負責評審專案的某部分程式碼以便提高程式碼質量和正確性的人。[-]
評審者既要了解程式碼庫又要了解軟體工程規範。評審者狀態是基於程式碼庫的組成部分來設定的。

貢獻者通過貢獻程式碼、文件或者投入時間等方式來幫助 Kubernetes 專案或社群的人。[-]
貢獻形式包括提交拉取請求(PRs)、問題報告(Issues)、反饋、參與特別興趣小組(SIG)或者組織社群活動等等。

資源配額資源配額提供了限制每個 名稱空間 的資源消耗總和的約束。[-]
限制了名稱空間中每種物件可以建立的數量,也限制了專案中可被資源物件利用的計算資源總數。

選擇算符選擇算符允許使用者通過標籤對一組資源物件進行篩選過濾。[-]
在查詢資源列表時,選擇算符可以通過 標籤 對資源進行過濾篩選。

映象映象是儲存的容器例項,它打包了應用執行所需的一組軟體。[-]
映象是軟體打包的一種方式,可以將映象儲存在容器映象倉庫、拉取到本地系統並作為應用來執行。 映象中包含的後設資料指明瞭執行什麼可執行程式、是由誰構建的以及其他資訊。
附加元件擴充套件 Kubernetes 功能的資源。[-]
安裝附加元件 闡釋了更多關於如何在叢集內使用附加元件,並列出了一些流行的附加元件。

叢集叢集由一組被稱作節點的機器組成。這些節點上執行 Kubernetes 所管理的容器化應用。叢集具有至少一個工作節點和至少一個主節點。[-]
工作節點託管作為應用程式元件的 Pod 。主節點管理叢集中的工作節點和 Pod 。多個主節點用於為叢集提供故障轉移和高可用性。

叢集操作者配置、控制、監控叢集的人。[-]
他們的主要責任是保持叢集正常執行,可能需要進行週期性的維護和升級活動。

注意: 叢集操作者不同於操作者模式(Operator Pattern),操作者模式是用來擴充套件 Kubernetes API 的。

叢集架構師叢集架構師負責設計叢集的基礎設施,可能包含一個或多個 Kubernetes 叢集。[-]
叢集架構師要具備分散式系統的最佳實踐經驗,例如:高可用性和安全性。

靜態 Pod由特定節點上的 kubelet 守護程式直接管理的 pod,[-]
API 伺服器不瞭解它的存在。

驅動外掛裝置外掛是在 Kubernetes 中執行的容器,可用於訪問供應商特定資源。[-]
驅動外掛 是執行在 Kubernetes 中的容器,它提供對供應商特定資源的訪問。驅動外掛將這些資源釋出到 Kubelet。並且可以手動部署或做為 DaemonSet,而不用編寫定製的 Kubernetes 程式碼。

相關文章