小说阅读网免费小说,好看的电视剧,《完美世界》txt全集

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案

創(chuàng)新互聯(lián)kubernetes教程：Kubernetes配置聚合層

配置聚合層

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

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

在開(kāi)始之前

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

Katacoda
玩轉(zhuǎn) Kubernetes

要獲知版本信息，請(qǐng)輸入 ?kubectl version?。

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

注意：對(duì)不同的客戶端類型重復(fù)使用相同的 CA 會(huì)對(duì)集群的功能產(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 證書(shū)向擴(kuò)展 apiserver 認(rèn)證。

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

大致流程如下：

Kubernetes apiserver：對(duì)發(fā)出請(qǐng)求的用戶身份認(rèn)證，并對(duì)請(qǐng)求的 API 路徑執(zhí)行鑒權(quán)。
Kubernetes apiserver：將請(qǐng)求轉(zhuǎn)發(fā)到擴(kuò)展 apiserver
擴(kuò)展 apiserver：認(rèn)證來(lái)自 Kubernetes apiserver 的請(qǐng)求
擴(kuò)展 apiserver：對(duì)來(lái)自原始用戶的請(qǐng)求鑒權(quán)
擴(kuò)展 apiserver：執(zhí)行

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

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

以上泳道的來(lái)源可以在本文檔的源碼中找到。

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

由擴(kuò)展 apiserver 服務(wù)的對(duì) API 路徑的請(qǐng)求以與所有 API 請(qǐng)求相同的方式開(kāi)始：與 Kubernetes apiserver 的通信。該路徑已通過(guò)擴(kuò)展 apiserver 在 Kubernetes apiserver 中注冊(cè)。

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

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

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

Kubernetes Apiserver 代理請(qǐng)求

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

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

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

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

Kubernetes apiserver 通過(guò) TLS 連接到擴(kuò)展 apiserver，并使用客戶端證書(shū)認(rèn)證。你必須在啟動(dòng)時(shí)使用提供的標(biāo)志向 Kubernetes apiserver 提供以下內(nèi)容：

通過(guò) ?--proxy-client-key-file? 指定私鑰文件
通過(guò) ?--proxy-client-cert-file? 簽名的客戶端證書(shū)文件
通過(guò) ?--requestheader-client-ca-file? 簽署客戶端證書(shū)文件的 CA 證書(shū)
通過(guò) ?--requestheader-allowed-names? 在簽署的客戶證書(shū)中有效的公用名（CN）

Kubernetes apiserver 將使用由 ?--proxy-client-*-file? 指示的文件來(lái)驗(yàn)證擴(kuò)展 apiserver。為了使合規(guī)的擴(kuò)展 apiserver 能夠?qū)⒃撜?qǐng)求視為有效，必須滿足以下條件：

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

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

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

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

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

原始請(qǐng)求用戶名和組

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

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

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

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

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

如上所述，從?kube-system?中的 configmap 中檢索以下內(nèi)容：

客戶端 CA 證書(shū)
允許名稱（CN）列表
用戶名，組和其他信息的頭部

使用以下證書(shū)檢查 TLS 連接是否已通過(guò)認(rèn)證：

由其證書(shū)與檢索到的 CA 證書(shū)匹配的 CA 簽名。
在允許的 CN 列表中有一個(gè) CN，除非列表為空，在這種情況下允許所有 CN。
從適當(dāng)?shù)念^部中提取用戶名和組

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

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

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

擴(kuò)展 Apiserver 對(duì)請(qǐng)求鑒權(quán)

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

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

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

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

啟用 Kubernetes Apiserver 標(biāo)志

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

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

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

警告：除非你了解風(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

注冊(cè) APIService 對(duì)象

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

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

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

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

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

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

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

當(dāng)前題目：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes配置聚合層
文章轉(zhuǎn)載：http://fisionsoft.com.cn/article/coepsgs.html