配置聚合層

配置聚合層 可以允許 Kubernetes apiserver 使用其它 API 擴(kuò)展，這些 API 不是核心 Kubernetes API 的一部分。

成都做網(wǎng)站、網(wǎng)站制作的關(guān)注點(diǎn)不是能為您做些什么網(wǎng)站，而是怎么做網(wǎng)站，有沒有做好網(wǎng)站，給創(chuàng)新互聯(lián)一個(gè)展示的機(jī)會來證明自己，這并不會花費(fèi)您太多時(shí)間，或許會給您帶來新的靈感和驚喜。面向用戶友好，注重用戶體驗(yàn)，一切以用戶為中心。

在開始之前

你必須擁有一個(gè) Kubernetes 的集群，同時(shí)你的 Kubernetes 集群必須帶有 kubectl 命令行工具。 建議在至少有兩個(gè)節(jié)點(diǎn)的集群上運(yùn)行本教程，且這些節(jié)點(diǎn)不作為控制平面主機(jī)。 如果你還沒有集群，你可以通過 Minikube 構(gòu)建一個(gè)你自己的集群，或者你可以使用下面任意一個(gè) Kubernetes 工具構(gòu)建：

• Katacoda
• 玩轉(zhuǎn) Kubernetes

要獲知版本信息，請輸入 ?kubectl version?。

說明： 要使聚合層在你的環(huán)境中正常工作以支持代理服務(wù)器和擴(kuò)展 apiserver 之間的相互 TLS 身份驗(yàn)證， 需要滿足一些設(shè)置要求。Kubernetes 和 kube-apiserver 具有多個(gè) CA， 因此請確保代理是由聚合層 CA 簽名的，而不是由 Kubernetes 通用 CA 簽名的。

注意： 對不同的客戶端類型重復(fù)使用相同的 CA 會對集群的功能產(chǎn)生負(fù)面影響。

身份認(rèn)證流程

與自定義資源定義（CRD）不同，除標(biāo)準(zhǔn)的 Kubernetes apiserver 外，Aggregation API 還涉及另一個(gè)服務(wù)器：擴(kuò)展 apiserver。 Kubernetes apiserver 將需要與你的擴(kuò)展 apiserver 通信，并且你的擴(kuò)展 apiserver 也需要與 Kubernetes apiserver 通信。 為了確保此通信的安全，Kubernetes apiserver 使用 x509 證書向擴(kuò)展 apiserver 認(rèn)證。

本節(jié)介紹身份認(rèn)證和鑒權(quán)流程的工作方式以及如何配置它們。

大致流程如下：

1. Kubernetes apiserver：對發(fā)出請求的用戶身份認(rèn)證，并對請求的 API 路徑執(zhí)行鑒權(quán)。
2. Kubernetes apiserver：將請求轉(zhuǎn)發(fā)到擴(kuò)展 apiserver
3. 擴(kuò)展 apiserver：認(rèn)證來自 Kubernetes apiserver 的請求
4. 擴(kuò)展 apiserver：對來自原始用戶的請求鑒權(quán)
5. 擴(kuò)展 apiserver：執(zhí)行

本節(jié)的其余部分詳細(xì)描述了這些步驟。

該流程可以在下圖中看到。

以上泳道的來源可以在本文檔的源碼中找到。

Kubernetes Apiserver 認(rèn)證和授權(quán)

由擴(kuò)展 apiserver 服務(wù)的對 API 路徑的請求以與所有 API 請求相同的方式開始： 與 Kubernetes apiserver 的通信。該路徑已通過擴(kuò)展 apiserver 在 Kubernetes apiserver 中注冊。

用戶與 Kubernetes apiserver 通信，請求訪問路徑。 Kubernetes apiserver 使用它的標(biāo)準(zhǔn)認(rèn)證和授權(quán)配置來對用戶認(rèn)證，以及對特定路徑的鑒權(quán)。

到目前為止，所有內(nèi)容都是標(biāo)準(zhǔn)的 Kubernetes API 請求，認(rèn)證與鑒權(quán)。

Kubernetes apiserver 現(xiàn)在準(zhǔn)備將請求發(fā)送到擴(kuò)展 apiserver。

Kubernetes Apiserver 代理請求 

Kubernetes apiserver 現(xiàn)在將請求發(fā)送或代理到注冊以處理該請求的擴(kuò)展 apiserver。 為此，它需要了解幾件事：

1. Kubernetes apiserver 應(yīng)該如何向擴(kuò)展 apiserver 認(rèn)證，以通知擴(kuò)展 apiserver 通過網(wǎng)絡(luò)發(fā)出的請求來自有效的 Kubernetes apiserver？
2. Kubernetes apiserver 應(yīng)該如何通知擴(kuò)展 apiserver 原始請求 已通過認(rèn)證的用戶名和組？

為提供這兩條信息，你必須使用若干標(biāo)志來配置 Kubernetes apiserver。

Kubernetes Apiserver 客戶端認(rèn)證

Kubernetes apiserver 通過 TLS 連接到擴(kuò)展 apiserver，并使用客戶端證書認(rèn)證。 你必須在啟動時(shí)使用提供的標(biāo)志向 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? 指示的文件來驗(yàn)證擴(kuò)展 apiserver。 為了使合規(guī)的擴(kuò)展 apiserver 能夠?qū)⒃撜埱笠暈橛行?，必須滿足以下條件：

1. 連接必須使用由 CA 簽署的客戶端證書，該證書的證書位于 ?--requestheader-client-ca-file? 中。
2. 連接必須使用客戶端證書，該客戶端證書的 CN 是 ?--requestheader-allowed-names? 中列出的證書之一。

說明： 你可以將此選項(xiàng)設(shè)置為空白，即為?--requestheader-allowed-names?。 這將向擴(kuò)展 apiserver 指示任何 CN 是可接受的。

使用這些選項(xiàng)啟動時(shí)，Kubernetes apiserver 將：

1. 使用它們向擴(kuò)展 apiserver 認(rèn)證。
2. 在 ?kube-system? 命名空間中 創(chuàng)建一個(gè)名為 ?extension-apiserver-authentication? 的 ConfigMap， 它將在其中放置 CA 證書和允許的 CN。 反過來，擴(kuò)展 apiserver 可以檢索這些內(nèi)容以驗(yàn)證請求。

請注意，Kubernetes apiserver 使用相同的客戶端證書對所有擴(kuò)展 apiserver 認(rèn)證。 它不會為每個(gè)擴(kuò)展 apiserver 創(chuàng)建一個(gè)客戶端證書，而是創(chuàng)建一個(gè)證書作為 Kubernetes apiserver 認(rèn)證。所有擴(kuò)展 apiserver 請求都重復(fù)使用相同的請求。

原始請求用戶名和組

當(dāng) Kubernetes apiserver 將請求代理到擴(kuò)展 apiserver 時(shí)， 它將向擴(kuò)展 apiserver 通知原始請求已成功通過其驗(yàn)證的用戶名和組。 它在其代理請求的 HTTP 頭部中提供這些。你必須將要使用的標(biāo)頭名稱告知 Kubernetes apiserver。

• 通過?--requestheader-username-headers? 標(biāo)明用來保存用戶名的頭部
• 通過?--requestheader-group-headers? 標(biāo)明用來保存 group 的頭部
• 通過?--requestheader-extra-headers-prefix? 標(biāo)明用來保存拓展信息前綴的頭部

這些頭部名稱也放置在 ?extension-apiserver-authentication? ConfigMap 中， 因此擴(kuò)展 apiserver 可以檢索和使用它們。

擴(kuò)展 Apiserver 認(rèn)證

擴(kuò)展 apiserver 在收到來自 Kubernetes apiserver 的代理請求后， 必須驗(yàn)證該請求確實(shí)確實(shí)來自有效的身份驗(yàn)證代理， 該認(rèn)證代理由 Kubernetes apiserver 履行。擴(kuò)展 apiserver 通過以下方式對其認(rèn)證：

1. 如上所述，從?kube-system?中的 configmap 中檢索以下內(nèi)容：
• 客戶端 CA 證書
• 允許名稱（CN）列表
• 用戶名，組和其他信息的頭部
2. 使用以下證書檢查 TLS 連接是否已通過認(rèn)證：
• 由其證書與檢索到的 CA 證書匹配的 CA 簽名。
• 在允許的 CN 列表中有一個(gè) CN，除非列表為空，在這種情況下允許所有 CN。
• 從適當(dāng)?shù)念^部中提取用戶名和組

如果以上均通過，則該請求是來自合法認(rèn)證代理（在本例中為 Kubernetes apiserver） 的有效代理請求。

請注意，擴(kuò)展 apiserver 實(shí)現(xiàn)負(fù)責(zé)提供上述內(nèi)容。 默認(rèn)情況下，許多擴(kuò)展 apiserver 實(shí)現(xiàn)利用 ?K8S.io/apiserver/? 軟件包來做到這一點(diǎn)。 也有一些實(shí)現(xiàn)可能支持使用命令行選項(xiàng)來覆蓋這些配置。

為了具有檢索 configmap 的權(quán)限，擴(kuò)展 apiserver 需要適當(dāng)?shù)慕巧?nbsp;在 ?kube-system? 名字空間中有一個(gè)默認(rèn)角色 ?extension-apiserver-authentication-reader? 可用于設(shè)置。

擴(kuò)展 Apiserver 對請求鑒權(quán)

擴(kuò)展 apiserver 現(xiàn)在可以驗(yàn)證從標(biāo)頭檢索的?user/group?是否有權(quán)執(zhí)行給定請求。 通過向 Kubernetes apiserver 發(fā)送標(biāo)準(zhǔn) ?SubjectAccessReview ?請求來實(shí)現(xiàn)。

為了使擴(kuò)展 apiserver 本身被鑒權(quán)可以向 Kubernetes apiserver 提交 SubjectAccessReview 請求， 它需要正確的權(quán)限。 Kubernetes 包含一個(gè)具有相應(yīng)權(quán)限的名為 ?system:auth-delegator? 的默認(rèn) ?ClusterRole?， 可以將其授予擴(kuò)展 apiserver 的服務(wù)帳戶。

擴(kuò)展 Apiserver 執(zhí)行

如果 ?SubjectAccessReview ?通過，則擴(kuò)展 apiserver 執(zhí)行請求。

啟用 Kubernetes Apiserver 標(biāo)志 

通過以下 kube-apiserver 標(biāo)志啟用聚合層。 你的服務(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 有兩個(gè)客戶端 CA 選項(xiàng)：

• ?--client-ca-file ?
• ?--requestheader-client-ca-file ?

這些功能中的每個(gè)功能都是獨(dú)立的；如果使用不正確，可能彼此沖突。

• ?--client-ca-file?：當(dāng)請求到達(dá) Kubernetes apiserver 時(shí)，如果啟用了此選項(xiàng)， 則 Kubernetes apiserver 會檢查請求的證書。 如果它是由 ?--client-ca-file? 引用的文件中的 CA 證書之一簽名的， 并且用戶是公用名?CN=?的值，而組是組織O= 的取值，則該請求被視為合法請求。
• ?--requestheader-client-ca-file?：當(dāng)請求到達(dá) Kubernetes apiserver 時(shí)， 如果啟用此選項(xiàng)，則 Kubernetes apiserver 會檢查請求的證書。 如果它是由文件引用中的 --requestheader-client-ca-file 所簽署的 CA 證書之一簽名的， 則該請求將被視為潛在的合法請求。 然后，Kubernetes apiserver 檢查通用名稱 ?CN=? 是否是 ?--requestheader-allowed-names? 提供的列表中的名稱之一。 如果名稱允許，則請求被批準(zhǔn)；如果不是，則請求被拒絕。

如果同時(shí)提供了 ?--client-ca-file? 和 ?--requestheader-client-ca-file?， 則首先檢查 ?--requestheader-client-ca-file? CA，然后再檢查?--client-ca-file?。 通常，這些選項(xiàng)中的每一個(gè)都使用不同的 CA（根 CA 或中間 CA）。 常規(guī)客戶端請求與 ?--client-ca-file? 相匹配，而聚合請求要與 ?--requestheader-client-ca-file? 相匹配。 但是，如果兩者都使用同一個(gè) CA，則通常會通過 ?--client-ca-file? 傳遞的客戶端請求將失敗，因?yàn)?nbsp;CA 將與 ?--requestheader-client-ca-file? 中的 CA 匹配，但是通用名稱 ?CN=? 將不匹配 ?--requestheader-allowed-names? 中可接受的通用名稱之一。 這可能導(dǎo)致你的 kubelet 和其他控制平面組件以及最終用戶無法向 Kubernetes apiserver 認(rèn)證。

因此，請對用于控制平面組件和最終用戶鑒權(quán)的 ?--client-ca-file? 選項(xiàng)和 用于聚合 apiserver 鑒權(quán)的 ?--requestheader-client-ca-file? 選項(xiàng)使用 不同的 CA 證書。

警告： 除非你了解風(fēng)險(xiǎn)和保護(hù) CA 用法的機(jī)制，否則 不要 重用在不同上下文中使用的 CA。

如果你未在運(yùn)行 API 服務(wù)器的主機(jī)上運(yùn)行 kube-proxy，則必須確保使用以下 ?kube-apiserver? 標(biāo)志啟用系統(tǒng)：

--enable-aggregator-routing=true

注冊 APIService 對象

你可以動態(tài)配置將哪些客戶端請求代理到擴(kuò)展 apiserver。以下是注冊示例：

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: <注釋對象名稱>
spec:
  group: <擴(kuò)展 Apiserver 的 API 組名>
  version: <擴(kuò)展 Apiserver 的 API 版本>
  groupPriorityMinimum: 
  versionPriority: <版本在組中的優(yōu)先排序, 參考 API 文檔>
  service:
    namespace: <拓展 Apiserver 服務(wù)的名字空間>
    name: <拓展 Apiserver 服務(wù)的名稱>
  caBundle: 

APIService 對象的名稱必須是合法的 路徑片段名稱。

調(diào)用擴(kuò)展 apiserver

一旦 Kubernetes apiserver 確定應(yīng)將請求發(fā)送到擴(kuò)展 apiserver， 它需要知道如何調(diào)用它。

?service ?部分是對擴(kuò)展 apiserver 的服務(wù)的引用。 服務(wù)的名字空間和名字是必需的。端口是可選的，默認(rèn)為 443。 路徑配置是可選的，默認(rèn)為 ?/?。

下面是為可在端口 ?1234 ?上調(diào)用的擴(kuò)展 apiserver 的配置示例 服務(wù)位于子路徑 ?/my-path? 下，并針對 ServerName ?my-service-name.my-service-namespace.svc? 使用自定義的 CA 包來驗(yàn)證 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......tLS0K"
...

新聞名稱：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes配置聚合層
文章位置：http://uogjgqi.cn/article/coepsgs.html