Kubernetes API Aggregator是什么

本篇文章給大家分享的是有關(guān)Kubernetes API Aggregator是什么，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

一、什么是 Aggregated API Server

1.1、概述

Aggregated（聚合的）API server 是為了將原來的 API server 這個(gè)巨石（monolithic）應(yīng)用給拆分開，為了方便用戶開發(fā)自己的 API server 集成進(jìn)來，而不用直接修改 Kubernetes 官方倉庫的代碼，這樣一來也能將 API server 解耦，方便用戶使用實(shí)驗(yàn)特性。這些 API server 可以跟 core API server 無縫銜接，使用 kubectl 也可以管理它們。

在 1.7+ 版本中，聚合層和 kube-apiserver 一起運(yùn)行。在擴(kuò)展資源被注冊(cè)前，聚合層不執(zhí)行任何操，要注冊(cè)其 API，用戶必需添加一個(gè) APIService 對(duì)象，該對(duì)象需在 Kubernetes API 中聲明 URL 路徑，聚合層將發(fā)送到該 API 路徑(e.g. /apis/myextension.mycompany.io/v1/…)的所有對(duì)象代理到注冊(cè)的 APIService。

通常，通過在集群中的一個(gè) Pod 中運(yùn)行一個(gè) extension-apiserver 來實(shí)現(xiàn) APIService。如果已添加的資源需要主動(dòng)管理，這個(gè) extension-apiserver 通常需要和一個(gè)或多個(gè)控制器配對(duì)。

1.2、設(shè)計(jì)理念

• api的擴(kuò)展性：這樣k8s的開發(fā)人員就可以編寫自己的API服務(wù)器來公開他們想要的API。集群管理員應(yīng)該能夠使用這些服務(wù)，而不需要對(duì)核心庫存儲(chǔ)庫進(jìn)行任何更改。

• 豐富了APIs：核心kubernetes團(tuán)隊(duì)阻止了很多新的API提案。通過允許開發(fā)人員將他們的API作為單獨(dú)的服務(wù)器公開，并使集群管理員能夠在不對(duì)核心庫存儲(chǔ)庫進(jìn)行任何更改的情況下使用它們，這樣就無須社區(qū)繁雜的審查了

• 開發(fā)分階段實(shí)驗(yàn)性API的地方：新的API可以在單獨(dú)的聚集服務(wù)器中開發(fā)，當(dāng)它穩(wěn)定之后，那么把它們封裝起來安裝到其他集群就很容易了。

• 確保新API遵循kubernetes約定：如果沒有這里提出的機(jī)制，社區(qū)成員可能會(huì)被迫推出自己的東西，這可能會(huì)或可能不遵循kubernetes約定。

Aggregator for Kubernetes-style API servers: dynamic registration, discovery summarization, secure proxy

二、認(rèn)證流程

2.1、工作方式

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

1. Kubernetes apiserver：對(duì)發(fā)出請(qǐng)求的用戶身份認(rèn)證，并對(duì)請(qǐng)求的 API 路徑執(zhí)行鑒權(quán)

2. Kubernetes apiserver (aggregator)：將請(qǐng)求轉(zhuǎn)發(fā)到 Extension apiserver (aggregated apiserver)

3. Extension apiserver：認(rèn)證來自 Kubernetes apiserver 的請(qǐng)求

4. Extension apiserver：對(duì)來自原始用戶的請(qǐng)求鑒權(quán)

5. Extension apiserver：執(zhí)行

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

假設(shè)我們已經(jīng)在 Kubernetes apiserver 注冊(cè)了 Extension apiserver。

當(dāng)用戶請(qǐng)求訪問 path ，Kubernetes apiserver 使用它的標(biāo)準(zhǔn)認(rèn)證和授權(quán)配置來對(duì)用戶認(rèn)證，以及對(duì)特定 path 的鑒權(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ā)送到 Extension apiserver。

2.3、Kubernetes Apiserver 代理請(qǐng)求

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

1. Kubernetes apiserver 應(yīng)該如何向 Extension apiserver 認(rèn)證，以通知 Extension apiserver 通過網(wǎng)絡(luò)發(fā)出的請(qǐng)求來自有效的 Kubernetes apiserver？

2. Kubernetes apiserver 應(yīng)該如何通知 Extension apiserver 原始請(qǐng)求已通過認(rèn)證的用戶名和組？

簡而言之，就是 Kubernetes apiserver 已經(jīng)認(rèn)證和鑒權(quán)用戶的請(qǐng)求，怎么這這些信息傳遞給 Extension apiserver，為提供這兩條信息，我們必須使用若干標(biāo)志來配置 Kubernetes apiserver。

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

Kubernetes apiserver 通過 TLS 連接到 Extension apiserver，并使用客戶端證書認(rèn)證，這里 Kubernetes apiserver (aggregator or proxy) 是 Extension apiserver 的客戶端。必須在啟動(dòng)時(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 指示的文件來通過 Extension apiserver 驗(yàn)證。為了使合規(guī)的 Extension apiserver 能夠?qū)⒃撜?qǐng)求視為有效，必須滿足以下條件：

1. 連接必須使用由 CA 簽署的客戶端證書，該證書的證書位于 --requestheader-client-ca-file 中。

2. 連接必須使用客戶端證書，該客戶端證書的 CN 是 --requestheader-allowed-names 中列出的證書之一。 注意：您可以將此選項(xiàng)設(shè)置為空白，即為--requestheader-allowed-names=""。這將向擴(kuò)展 apiserver 指示任何 CN 是可接受的。

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

1. 使用它們來通過 Extension apiserver 的認(rèn)證。

2. 在名為 kube-system 命名空間中創(chuàng)建一個(gè) configmap  extension-apiserver-authentication ，它將在其中放置 CA 證書和允許的 CN。反過來，Extension apiserver 可以檢索這些內(nèi)容以驗(yàn)證請(qǐng)求。

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

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

• 通過--requestheader-username-headers 標(biāo)明用來保存用戶名的頭部

• 通過--requestheader-group-headers 標(biāo)明用來保存 group 的頭部

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

這些標(biāo)頭名稱也放置在extension-apiserver-authentication 的 configmap 中，因此 Extension apiserver 可以檢索和使用它們。

2.4、Extension apiserver 認(rèn)證

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

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

• 客戶端 CA 證書 --requestheader-client-ca-file。

• 允許名稱（CN）列表 --requestheader-allowed-names。

• 用戶名，組和其他信息的頭部。

2. 使用以下證書檢查 TLS 連接是否已通過認(rèn)證：

• 由其證書與檢索到的 CA 證書匹配的 CA 簽名。

• 在允許的 CN 列表中有一個(gè) CN，除非列表為空，在這種情況下允許所有 CN。

• 從適當(dāng)?shù)念^部中提取用戶名和組。

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

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

2.5、Extension apiserver 對(duì)請(qǐng)求鑒權(quán)

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

SubjectAcce***eview 是 authorization.k8s.io API 組的一部分資源，它將 API 服務(wù)器授權(quán)公開給外部服務(wù)。該 API 組中的其他資源可以通過如下命令查看：

kubectl get --raw /apis/authorization.k8s.io/v1/

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

2.6、Extension apiserver 執(zhí)行

如果SubjectAcce***eview通過，則擴(kuò)展 apiserver 執(zhí)行請(qǐng)求。

三、部署過程

3.1、安裝 cfssl

wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -O /usr/local/bin/cfssl
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -O /usr/local/bin/cfssljson
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -O /usr/local/bin/cfssl-certinfo
cd /usr/local/bin/
chmod +x cfssl cfssljson cfssl-certinfo

3.2、創(chuàng)建 CA

3.2.3、CA 配置文件

$ cat > aggregator-ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "aggregator": {
        "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ],
        "expiry": "87600h"
      }
    }
  }
}
EOF

• profiles : 可以定義多個(gè) profiles，分別指定不同的過期時(shí)間、使用場(chǎng)景等參數(shù)；后續(xù)在簽名證書時(shí)使用某個(gè) profile。

• signing ：表示該證書可用于簽名其它證書；生成的 aggregator-ca.pem 證書中 CA=TRUE。

• server auth ：表示 Client 可以用該 CA 對(duì) Server 提供的證書進(jìn)行驗(yàn)證。

• client auth ：表示 Server 可以用該 CA 對(duì) Client 提供的證書進(jìn)行驗(yàn)證。

3.2.3、創(chuàng)建 CA 證書簽名請(qǐng)求

$ cat > aggregator-ca-csr.json <<EOF
{
  "CN": "aggregator",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "Shanghai",
      "L": "Shanghai",
      "O": "k8s",
      "OU": "wzlinux"
    }
  ],
    "ca": {
       "expiry": "87600h"
    }
}

• “CN” ：Common Name，kube-apiserver 從證書中提取該字段作為請(qǐng)求的用戶名 (User Name)；瀏覽器使用該字段驗(yàn)證網(wǎng)站是否合法。

• “O” ：Organization，kube-apiserver 從證書中提取該字段作為請(qǐng)求用戶所屬的組 (Group)；

3.2.4、生成 CA 證書和私鑰

cfssl gencert -initca aggregator-ca-csr.json | cfssljson -bare aggregator-ca

3.3、創(chuàng)建 kubernetes 證書

3.3.1、創(chuàng)建 aggregator 證書簽名請(qǐng)求

$ cat > aggregator-csr.json <<EOF
{
    "CN": "aggregator",
    "hosts": [
      "127.0.0.1",
      "172.18.0.101",
      "172.18.0.102",
      "172.18.0.103",
      "10.96.0.1",
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "Shanghai",
            "L": "Shanghai",
            "O": "k8s",
            "OU": "wzlinux"
        }
    ]
}

如果 hosts 字段不為空則需要指定授權(quán)使用該證書的 IP 或域名列表，由于該證書后續(xù)kubernetes master 集群使用，所以上面指定kubernetes master 集群的主機(jī) IP 和 kubernetes 服務(wù)的服務(wù) IP（一般是 kube-apiserver 指定的 service-cluster-ip-range 網(wǎng)段的第一個(gè) IP，如 10.96.0.1）。

3.3.2、生成 aggreagtor 證書和私鑰

cfssl gencert -ca=aggregator-ca.pem -ca-key=aggregator-ca-key.pem -config=aggregator-ca-config.json -profile=aggregator aggregator-csr.json | cfssljson -bare aggregator

3.3.3、分發(fā)證書

將生成的證書和秘鑰文件（后綴名為.pem）拷貝到 Master 節(jié)點(diǎn)的 /etc/kubernetes/pki 目錄下備用。

3.4、開啟聚合層 API

kube-apiserver 增加以下配置：

--requestheader-client-ca-file=/etc/kubernetes/pki/aggregator-ca.pem
--requestheader-allowed-names=aggregator
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=/etc/kubernetes/pki/aggregator.pem
--proxy-client-key-file=/etc/kubernetes/pki/aggregator-key.pem

前面創(chuàng)建的證書的 CN 字段的值必須和參數(shù) –requestheader-allowed-names 指定的值 aggregator 相同。

重啟 kube-apiserver：

$ systemctl daemon-reload
$ systemctl restart kube-apiserver

如果 kube-proxy 沒有在 Master 上面運(yùn)行，kube-proxy 還需要添加配置：

--enable-aggregator-routing=true

以上就是Kubernetes API Aggregator是什么，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。