Kubernetes Apiserver和Extension apiserver的介紹

這篇文章為大家?guī)碛嘘P(guān)Kubernetes Apiserver和Extension apiserver的介紹。大部分知識點(diǎn)都是大家經(jīng)常用到的，為此分享給大家做個參考。一起跟隨小編過來看看吧。

1.1、概述

Aggregated（聚合的）API server 是為了將原來的 API server 這個巨石（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ò)展資源被注冊前，聚合層不執(zhí)行任何操，要注冊其 API，用戶必需添加一個 APIService 對象，該對象需在 Kubernetes API 中聲明 URL 路徑，聚合層將發(fā)送到該 API 路徑(e.g. /apis/myextension.mycompany.io/v1/…)的所有對象代理到注冊的 APIService。

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

1.2、設(shè)計理念

• api的擴(kuò)展性：這樣k8s的開發(fā)人員就可以編寫自己的API服務(wù)器來公開他們想要的API。集群管理員應(yīng)該能夠使用這些服務(wù)，而不需要對核心庫存儲庫進(jìn)行任何更改。
• 豐富了APIs：核心kubernetes團(tuán)隊阻止了很多新的API提案。通過允許開發(fā)人員將他們的API作為單獨(dú)的服務(wù)器公開，并使集群管理員能夠在不對核心庫存儲庫進(jìn)行任何更改的情況下使用它們，這樣就無須社區(qū)繁雜的審查了
• 開發(fā)分階段實(shí)驗(yàn)性API的地方：新的API可以在單獨(dú)的聚集服務(wù)器中開發(fā)，當(dāng)它穩(wěn)定之后，那么把它們封裝起來安裝到其他集群就很容易了。
• 確保新API遵循kubernetes約定：如果沒有這里提出的機(jī)制，社區(qū)成員可能會被迫推出自己的東西，這可能會或可能不遵循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 還涉及另一個服務(wù)器：Extension apiserver。Kubernetes apiserver 將需要與您的 Extension apiserver 通信，并且您的 Extension apiserver 也需要與 Kubernetes apiserver 通信。為了確保此通信的安全，Kubernetes apiserver 使用 x509 證書向 Extension apiserver 認(rèn)證。

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

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

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

當(dāng)用戶請求訪問 path ，Kubernetes apiserver 使用它的標(biāo)準(zhǔn)認(rèn)證和授權(quán)配置來對用戶認(rèn)證，以及對特定 path 的鑒權(quán)，到目前為止，所有內(nèi)容都是標(biāo)準(zhǔn)的 Kubernetes API 請求，認(rèn)證與鑒權(quán)，接下來 Kubernetes apiserver 現(xiàn)在準(zhǔn)備將請求發(fā)送到 Extension apiserver。

2.3、Kubernetes Apiserver 代理請求

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

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

簡而言之，就是 Kubernetes apiserver 已經(jīng)認(rèn)證和鑒權(quán)用戶的請求，怎么這這些信息傳遞給 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 的客戶端。必須在啟動時使用提供的標(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ū)⒃撜埱笠暈橛行?，必須滿足以下條件：

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

使用這些選項啟動時，Kubernetes apiserver 將：

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

2.3.2、原始請求用戶名和組

當(dāng) Kubernetes apiserver 將請求代理到 Extension apiserver 時，它將向 Extension apiserver 通知原始請求已成功通過其驗(yàn)證的用戶名和組。它在其代理請求的 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 的代理請求后，必須驗(yàn)證該請求確實(shí)確實(shí)來自有效的身份驗(yàn)證代理，該認(rèn)證代理由 Kubernetes apiserver 履行。Extension apiserver 通過以下方式對其認(rèn)證：

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

• 客戶端 CA 證書 --requestheader-client-ca-file。
• 允許名稱（CN）列表 --requestheader-allowed-names。
• 用戶名，組和其他信息的頭部。

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

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

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

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

2.5、Extension apiserver 對請求鑒權(quán)

Extension apiserver 現(xiàn)在可以驗(yàn)證從標(biāo)頭檢索的user/group是否有權(quán)執(zhí)行給定請求。通過向 Kubernetes apiserver 發(fā)送標(biāo)準(zhǔn) SubjectAcce***eview 請求來實(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 請求，它需要正確的權(quán)限。Kubernetes 包含一個具有相應(yīng)權(quán)限的名為system：auth-delegator 的默認(rèn) ClusterRole，可以將其授予 Extension apiserver 的服務(wù)帳戶。

2.6、Extension apiserver 執(zhí)行

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

三、部署過程

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 : 可以定義多個 profiles，分別指定不同的過期時間、使用場景等參數(shù)；后續(xù)在簽名證書時使用某個 profile。
• signing ：表示該證書可用于簽名其它證書；生成的 aggregator-ca.pem 證書中 CA=TRUE。
• server auth ：表示 Client 可以用該 CA 對 Server 提供的證書進(jìn)行驗(yàn)證。
• client auth ：表示 Server 可以用該 CA 對 Client 提供的證書進(jìn)行驗(yàn)證。

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

$ 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 從證書中提取該字段作為請求的用戶名 (User Name)；瀏覽器使用該字段驗(yàn)證網(wǎng)站是否合法。
• “O” ：Organization，kube-apiserver 從證書中提取該字段作為請求用戶所屬的組 (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 證書簽名請求

$ 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)段的第一個 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 Apiserver和Extension apiserver的知識匯總，內(nèi)容較為全面，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ骺赡軙姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學(xué)到更多知識。