建站
咨詢
售后
建站咨詢
新聞中心
配置聚合層
配置聚合層 可以允許 Kubernetes apiserver 使用其它 API 擴展，這些 API 不是核心 Kubernetes API 的一部分。
成都做網(wǎng)站、網(wǎng)站制作的關(guān)注點不是能為您做些什么網(wǎng)站，而是怎么做網(wǎng)站，有沒有做好網(wǎng)站，給創(chuàng)新互聯(lián)一個展示的機會來證明自己，這并不會花費您太多時間，或許會給您帶來新的靈感和驚喜。面向用戶友好，注重用戶體驗，一切以用戶為中心。
在開始之前
你必須擁有一個 Kubernetes 的集群，同時你的 Kubernetes 集群必須帶有 kubectl 命令行工具。 建議在至少有兩個節(jié)點的集群上運行本教程，且這些節(jié)點不作為控制平面主機。 如果你還沒有集群，你可以通過 Minikube 構(gòu)建一個你自己的集群，或者你可以使用下面任意一個 Kubernetes 工具構(gòu)建：
- Katacoda
- 玩轉(zhuǎn) Kubernetes
要獲知版本信息，請輸入 ?kubectl version?。
說明： 要使聚合層在你的環(huán)境中正常工作以支持代理服務(wù)器和擴展 apiserver 之間的相互 TLS 身份驗證， 需要滿足一些設(shè)置要求。Kubernetes 和 kube-apiserver 具有多個 CA， 因此請確保代理是由聚合層 CA 簽名的，而不是由 Kubernetes 通用 CA 簽名的。
注意： 對不同的客戶端類型重復(fù)使用相同的 CA 會對集群的功能產(chǎn)生負面影響。
身份認證流程
與自定義資源定義（CRD）不同，除標準的 Kubernetes apiserver 外，Aggregation API 還涉及另一個服務(wù)器：擴展 apiserver。 Kubernetes apiserver 將需要與你的擴展 apiserver 通信，并且你的擴展 apiserver 也需要與 Kubernetes apiserver 通信。 為了確保此通信的安全，Kubernetes apiserver 使用 x509 證書向擴展 apiserver 認證。
本節(jié)介紹身份認證和鑒權(quán)流程的工作方式以及如何配置它們。
大致流程如下：
- Kubernetes apiserver：對發(fā)出請求的用戶身份認證，并對請求的 API 路徑執(zhí)行鑒權(quán)。
- Kubernetes apiserver：將請求轉(zhuǎn)發(fā)到擴展 apiserver
- 擴展 apiserver：認證來自 Kubernetes apiserver 的請求
- 擴展 apiserver：對來自原始用戶的請求鑒權(quán)
- 擴展 apiserver：執(zhí)行
本節(jié)的其余部分詳細描述了這些步驟。
該流程可以在下圖中看到。
以上泳道的來源可以在本文檔的源碼中找到。
Kubernetes Apiserver 認證和授權(quán)
由擴展 apiserver 服務(wù)的對 API 路徑的請求以與所有 API 請求相同的方式開始： 與 Kubernetes apiserver 的通信。該路徑已通過擴展 apiserver 在 Kubernetes apiserver 中注冊。
用戶與 Kubernetes apiserver 通信，請求訪問路徑。 Kubernetes apiserver 使用它的標準認證和授權(quán)配置來對用戶認證，以及對特定路徑的鑒權(quán)。
到目前為止，所有內(nèi)容都是標準的 Kubernetes API 請求，認證與鑒權(quán)。
Kubernetes apiserver 現(xiàn)在準備將請求發(fā)送到擴展 apiserver。
Kubernetes Apiserver 代理請求
Kubernetes apiserver 現(xiàn)在將請求發(fā)送或代理到注冊以處理該請求的擴展 apiserver。 為此，它需要了解幾件事：
- Kubernetes apiserver 應(yīng)該如何向擴展 apiserver 認證，以通知擴展 apiserver 通過網(wǎng)絡(luò)發(fā)出的請求來自有效的 Kubernetes apiserver？
- Kubernetes apiserver 應(yīng)該如何通知擴展 apiserver 原始請求 已通過認證的用戶名和組？
為提供這兩條信息，你必須使用若干標志來配置 Kubernetes apiserver。
Kubernetes Apiserver 客戶端認證
Kubernetes apiserver 通過 TLS 連接到擴展 apiserver，并使用客戶端證書認證。 你必須在啟動時使用提供的標志向 Kubernetes apiserver 提供以下內(nèi)容：
- 通過 ?
--proxy-client-key-file? 指定私鑰文件 - 通過 ?
--proxy-client-cert-file? 簽名的客戶端證書文件 - 通過 ?
--requestheader-client-ca-file? 簽署客戶端證書文件的 CA 證書 - 通過 ?
--requestheader-allowed-names? 在簽署的客戶證書中有效的公用名（CN）
Kubernetes apiserver 將使用由 ?--proxy-client-*-file? 指示的文件來驗證擴展 apiserver。 為了使合規(guī)的擴展 apiserver 能夠?qū)⒃撜埱笠暈橛行?，必須滿足以下條件：
- 連接必須使用由 CA 簽署的客戶端證書，該證書的證書位于 ?
--requestheader-client-ca-file? 中。 - 連接必須使用客戶端證書，該客戶端證書的 CN 是 ?
--requestheader-allowed-names? 中列出的證書之一。
說明： 你可以將此選項設(shè)置為空白，即為?
--requestheader-allowed-names?。 這將向擴展 apiserver 指示任何 CN 是可接受的。
使用這些選項啟動時，Kubernetes apiserver 將：
- 使用它們向擴展 apiserver 認證。
- 在 ?
kube-system? 命名空間中 創(chuàng)建一個名為 ?extension-apiserver-authentication? 的 ConfigMap， 它將在其中放置 CA 證書和允許的 CN。 反過來，擴展 apiserver 可以檢索這些內(nèi)容以驗證請求。
請注意，Kubernetes apiserver 使用相同的客戶端證書對所有擴展 apiserver 認證。 它不會為每個擴展 apiserver 創(chuàng)建一個客戶端證書，而是創(chuàng)建一個證書作為 Kubernetes apiserver 認證。所有擴展 apiserver 請求都重復(fù)使用相同的請求。
原始請求用戶名和組
當 Kubernetes apiserver 將請求代理到擴展 apiserver 時， 它將向擴展 apiserver 通知原始請求已成功通過其驗證的用戶名和組。 它在其代理請求的 HTTP 頭部中提供這些。你必須將要使用的標頭名稱告知 Kubernetes apiserver。
- 通過?
--requestheader-username-headers? 標明用來保存用戶名的頭部 - 通過?
--requestheader-group-headers? 標明用來保存 group 的頭部 - 通過?
--requestheader-extra-headers-prefix? 標明用來保存拓展信息前綴的頭部
這些頭部名稱也放置在 ?extension-apiserver-authentication? ConfigMap 中， 因此擴展 apiserver 可以檢索和使用它們。
擴展 Apiserver 認證
擴展 apiserver 在收到來自 Kubernetes apiserver 的代理請求后， 必須驗證該請求確實確實來自有效的身份驗證代理， 該認證代理由 Kubernetes apiserver 履行。擴展 apiserver 通過以下方式對其認證：
- 如上所述，從?
kube-system?中的 configmap 中檢索以下內(nèi)容： - 客戶端 CA 證書
- 允許名稱（CN）列表
- 用戶名，組和其他信息的頭部
- 使用以下證書檢查 TLS 連接是否已通過認證：
- 由其證書與檢索到的 CA 證書匹配的 CA 簽名。
- 在允許的 CN 列表中有一個 CN，除非列表為空，在這種情況下允許所有 CN。
- 從適當?shù)念^部中提取用戶名和組
如果以上均通過，則該請求是來自合法認證代理（在本例中為 Kubernetes apiserver） 的有效代理請求。
請注意，擴展 apiserver 實現(xiàn)負責(zé)提供上述內(nèi)容。 默認情況下，許多擴展 apiserver 實現(xiàn)利用 ?K8S.io/apiserver/? 軟件包來做到這一點。 也有一些實現(xiàn)可能支持使用命令行選項來覆蓋這些配置。
為了具有檢索 configmap 的權(quán)限，擴展 apiserver 需要適當?shù)慕巧?nbsp;在 ?kube-system? 名字空間中有一個默認角色 ?extension-apiserver-authentication-reader? 可用于設(shè)置。
擴展 Apiserver 對請求鑒權(quán)
擴展 apiserver 現(xiàn)在可以驗證從標頭檢索的?user/group?是否有權(quán)執(zhí)行給定請求。 通過向 Kubernetes apiserver 發(fā)送標準 ?SubjectAccessReview ?請求來實現(xiàn)。
為了使擴展 apiserver 本身被鑒權(quán)可以向 Kubernetes apiserver 提交 SubjectAccessReview 請求， 它需要正確的權(quán)限。 Kubernetes 包含一個具有相應(yīng)權(quán)限的名為 ?system:auth-delegator? 的默認 ?ClusterRole?， 可以將其授予擴展 apiserver 的服務(wù)帳戶。
擴展 Apiserver 執(zhí)行
如果 ?SubjectAccessReview ?通過，則擴展 apiserver 執(zhí)行請求。
啟用 Kubernetes Apiserver 標志
通過以下 kube-apiserver 標志啟用聚合層。 你的服務(wù)提供商可能已經(jīng)為你完成了這些工作：
--requestheader-client-ca-file=
--requestheader-allowed-names=front-proxy-client
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=
--proxy-client-key-file= CA-重用和沖突
Kubernetes apiserver 有兩個客戶端 CA 選項：
- ?
--client-ca-file? - ?
--requestheader-client-ca-file?
這些功能中的每個功能都是獨立的；如果使用不正確，可能彼此沖突。
- ?
--client-ca-file?：當請求到達 Kubernetes apiserver 時，如果啟用了此選項， 則 Kubernetes apiserver 會檢查請求的證書。 如果它是由 ?--client-ca-file? 引用的文件中的 CA 證書之一簽名的， 并且用戶是公用名?CN=?的值，而組是組織O= 的取值，則該請求被視為合法請求。 - ?
--requestheader-client-ca-file?：當請求到達 Kubernetes apiserver 時， 如果啟用此選項，則 Kubernetes apiserver 會檢查請求的證書。 如果它是由文件引用中的 --requestheader-client-ca-file 所簽署的 CA 證書之一簽名的， 則該請求將被視為潛在的合法請求。 然后，Kubernetes apiserver 檢查通用名稱 ?CN=? 是否是 ?--requestheader-allowed-names? 提供的列表中的名稱之一。 如果名稱允許，則請求被批準；如果不是，則請求被拒絕。
如果同時提供了 ?--client-ca-file? 和 ?--requestheader-client-ca-file?， 則首先檢查 ?--requestheader-client-ca-file? CA，然后再檢查?--client-ca-file?。 通常，這些選項中的每一個都使用不同的 CA（根 CA 或中間 CA）。 常規(guī)客戶端請求與 ?--client-ca-file? 相匹配，而聚合請求要與 ?--requestheader-client-ca-file? 相匹配。 但是，如果兩者都使用同一個 CA，則通常會通過 ?--client-ca-file? 傳遞的客戶端請求將失敗，因為 CA 將與 ?--requestheader-client-ca-file? 中的 CA 匹配，但是通用名稱 ?CN=? 將不匹配 ?--requestheader-allowed-names? 中可接受的通用名稱之一。 這可能導(dǎo)致你的 kubelet 和其他控制平面組件以及最終用戶無法向 Kubernetes apiserver 認證。
因此，請對用于控制平面組件和最終用戶鑒權(quán)的 ?--client-ca-file? 選項和 用于聚合 apiserver 鑒權(quán)的 ?--requestheader-client-ca-file? 選項使用 不同的 CA 證書。
警告： 除非你了解風(fēng)險和保護 CA 用法的機制，否則 不要 重用在不同上下文中使用的 CA。
如果你未在運行 API 服務(wù)器的主機上運行 kube-proxy，則必須確保使用以下 ?kube-apiserver? 標志啟用系統(tǒng)：
--enable-aggregator-routing=true
注冊 APIService 對象
你可以動態(tài)配置將哪些客戶端請求代理到擴展 apiserver。以下是注冊示例：
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
name: <注釋對象名稱>
spec:
group: <擴展 Apiserver 的 API 組名>
version: <擴展 Apiserver 的 API 版本>
groupPriorityMinimum:
versionPriority: <版本在組中的優(yōu)先排序, 參考 API 文檔>
service:
namespace: <拓展 Apiserver 服務(wù)的名字空間>
name: <拓展 Apiserver 服務(wù)的名稱>
caBundle: APIService 對象的名稱必須是合法的 路徑片段名稱。
調(diào)用擴展 apiserver
一旦 Kubernetes apiserver 確定應(yīng)將請求發(fā)送到擴展 apiserver， 它需要知道如何調(diào)用它。
?service ?部分是對擴展 apiserver 的服務(wù)的引用。 服務(wù)的名字空間和名字是必需的。端口是可選的，默認為 443。 路徑配置是可選的，默認為 ?/?。
下面是為可在端口 ?1234 ?上調(diào)用的擴展 apiserver 的配置示例 服務(wù)位于子路徑 ?/my-path? 下，并針對 ServerName ?my-service-name.my-service-namespace.svc? 使用自定義的 CA 包來驗證 TLS 連接 使用自定義 CA 捆綁包的?my-service-name.my-service-namespace.svc?。
apiVersion: apiregistration.k8s.io/v1
kind: APIService
...
spec:
...
service:
namespace: my-service-namespace
name: my-service-name
port: 1234
caBundle: "Ci0tLS0tQk...分享文章：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes配置聚合層
鏈接地址：http://www.5511xx.com/article/coepsgs.html
