8.2 與Kubernetes API服務(wù)器交互

我們已經(jīng)知道此再，Downward API提供了一種簡單的方式昔搂，將pod和容器的元數(shù)據(jù)傳遞給在它們內(nèi)部運行的進程。但這種方式其實僅僅可以暴露一個pod自身的元數(shù)據(jù)输拇，而且只可以暴露部分元數(shù)據(jù)摘符。某些情況下，我們的應(yīng)用需要知道其他pod的信息策吠，甚至是集群中其他資源的信息逛裤。這種情況下Downward API方式將無能為力。

正如書中提到的猴抹，可以通過服務(wù)相關(guān)的環(huán)境變量或者DNS來獲取服務(wù)和pod的信息带族，但如果應(yīng)用需要獲取其他資源的信息或者獲取最新的信息，就需要直接與API服務(wù)器進行交互（如圖8.4所示）蟀给。

在了解pod中的應(yīng)用如何與Kubernetes API服務(wù)器交互之前蝙砌，先在自己的本機上研究一下服務(wù)器的REST endpoit，這樣我們可以大致了解什么是API服務(wù)器跋理。

8.2.1 探究Kubernetes REST API

我們已經(jīng)了解了Kubernetes不同的資源類型择克。但如果打算開發(fā)一個可以與Kubernetes API交互的應(yīng)用，要首先了解API前普。

先嘗試直接訪問API服務(wù)器肚邢，可以通過運行 kubectl cluster-info 命令來得到服務(wù)器的URL。

$ kubectl cluster-info
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. 
Unable to connect to the server: dial tcp 172.17.0.2:8443: connect: no route to host 

因為服務(wù)器使用HTTPS協(xié)議并且需要授權(quán)拭卿，所以與服務(wù)器交互并不是一件簡單的事情骡湖，可以嘗試通過curl來訪問它贱纠，使用curl的 --insecure（或-k）選項來跳過服務(wù)器證書檢查環(huán)節(jié)，但這也不能讓我們走得更遠响蕴。

$ curl https://172.17.0.2:8443 -k

幸運的是并巍，我們可以執(zhí)行 kubectl proxy 命令，通過代理與服務(wù)器交互换途，而不是自行來處理驗證過程懊渡。

通過Kubectl proxy訪問API服務(wù)器

kubectl proxy 命令啟動了一個代理服務(wù)來接收來自你本機的HTTP連接并轉(zhuǎn)發(fā)至API服務(wù)器，同時處理身份認證军拟，所以不需要每次請求都上傳認證憑證剃执。它也可以確保我們直接與真實的API服務(wù)器交互，而不是一個中間人（通過每次驗證服務(wù)器證書的方式）懈息。

運行代理很簡單肾档，所要做的就是運行以下命令：

$ kubectl proxy --address='0.0.0.0' --port=8001 --accept-hosts='.*'

我們也無須傳遞其他任何參數(shù)，因為kubectl已經(jīng)知曉所需的所有參數(shù)（API服務(wù)器 URL辫继、認證憑證等）谎脯。一旦啟動纳本，代理服務(wù)器就將在本地端口8001接收連接請求艇搀，讓我們看一下它是如何工作的：

$ curl localhost:8001

看刊殉，我們發(fā)送請求給代理，代理接著發(fā)送請求給API服務(wù)器炮车，然后代理將返回從服務(wù)器返回的所有信息舵变，現(xiàn)在讓我們開始研究。

通過Kubectl proxy研究Kubernetes API

我們可以繼續(xù)使用curl瘦穆，或者打開瀏覽器并且指向 http://localhost:8001 纪隙，看一下當(dāng)我們訪問這個基礎(chǔ)的URL時，API服務(wù)器會返回什么扛或。服務(wù)器的應(yīng)答是一組路徑的清單绵咱，如下所示。

代碼清單8.7 API服務(wù)器的REST endpoint清單：http://localhost:8001

{
  "paths": [
    "/.well-known/openid-configuration", 
    "/api",
    "/api/v1",
    "/apis",
    ----------
    "/apis/batch",  # batchAPI組以及它的兩個版本
    "/apis/batch/v1",
    "/apis/batch/v1beta1", 
   ]
}

這些路徑對應(yīng)了我們創(chuàng)建Pod熙兔、Service這些資源時定義的API組和版本信息悲伶。

你或許已經(jīng)發(fā)現(xiàn)在 /apis/batch/v1 路徑下的 batch/V1 就是在第4章了解的Job資源API組和版本信息。同樣黔姜， /api/V1 對應(yīng)apiVersion：這里所說的V1指的是我們創(chuàng)建的基礎(chǔ)資源（Pod拢切、Service蒂萎、ReplicationController等）秆吵。在Kubernetes最早期版本中提到的最基礎(chǔ)的資源并不屬于任何指定的組，原因是Kubernetes初期并沒有使用API組的概念五慈，這個概念是后期引入的纳寂。

注意 這些沒有列入API組的初始資源類型現(xiàn)在一般被認為歸屬于核心的API組主穗。

研究批量API組的REST endpoint

讓我們來研究Job資源API，從路徑 /apis/batch 下的內(nèi)容開始（暫時忽略版本）毙芜，如下面的代碼清單所示忽媒。

代碼清單8.8 在 /apis/batch 目錄下的endpoint清單： curl http://localhost:8001/apis/batch 這個響應(yīng)消息展示了包括可用版本、客戶推薦使用版本在內(nèi)的批量API組信息腋粥。讓我們接著看一下 /apis/batch/V1 路徑下的內(nèi)容晦雨，如下面的代碼清單所示。

代碼清單8.9 在 batch/V1 中的資源類型： http://localhost:8001/apis/batch/v1

{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "batch/v1", #資源請單
  "resources": [  #所有的資源類型
    {
      "name": "cronjobs",  
      "singularName": "",
      "namespaced": true, #指定namesapce的job資源,
      "kind": "CronJob",
      "verbs": [
        "create",
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "update",
        "watch"
      ],
      "shortNames": [
        "cj"
      ],
      "categories": [
        "all"
      ],
      "storageVersionHash": "h/JlFAZkyyY="
    }
  ]
}

像我們看到的一樣隘冲，API服務(wù)器返回了在 batch/V1 目錄下API組中的資源類型以及 REST endpoint 清單闹瞧。除了資源的名稱和相關(guān)的類型，API服務(wù)器也包含了一些其他信息展辞，比如資源是否被指定了命名空間奥邮、名稱簡寫（如果有的話，對于Job來說沒有）罗珍、資源對應(yīng)可以使用的動詞列表等洽腺。

返回的列表描述了在API服務(wù)器中暴露的REST資源。＂name＂:＂jobs＂行的信息告訴我們API包含了 /apis/batch/V1/jobs 的endpoint,＂verbs＂數(shù)組告訴我們可以通過endpoint恢復(fù)覆旱、修改以及刪除Job資源蘸朋。對于某些特定的資源，API服務(wù)器暴露了額外的API endpoint（例如扣唱，通過 jobs/status 路徑可以修改Job的狀態(tài)）度液。

列舉集群中所有的Job實例

通過在 /apis/batch/v1/jobs 路徑運行一個GET請求，可以獲取集群中所有Job的清單画舌，如下面的代碼清單所示堕担。

代碼清單8.10 Job清單：http://localhost:8001/apis/batch/v1/jobs

$ curl http://localhost:8001/apis/batch/v1/jobs

如果在集群中沒有部署Job資源，那么items數(shù)組將是空的曲聂∨海可以嘗試在Chapter08/my-job.yaml中部署Job，然后再次訪問RESR endpoint從而得到與代碼清單8.10中相同的輸出信息朋腋。

通過名稱恢復(fù)一個指定的Job實例

前面的endpoint返回了跨命名空間的所有Job的清單齐疙，如果想要返回指定的一個Job，需要在URL中指定它的名稱和所在的命名空間旭咽。為了恢復(fù)在之前清單中的一個Job（name:my-job ; namespace:dfault ）贞奋，需要訪問路徑：/apis/batch/v1/namespaces/default/jobs/my-job ，如下面的代碼清單所示穷绵。

代碼清單8.11 通過名稱恢復(fù)一個指定命名空間下的資源

$ curl http://localhost:8001/apis/batch/v1/namespace/default/jobs/my-job

可以看到轿塔，我們得到了my-job這個Job資源的完整的JSON定義信息，和運行 $kubetcl get job my-job -o json 命令得到的信息完全一致。

$ kubectl get job my-job -o json

雖然不使用任何特定的工具勾缭，我們也可以訪問Kubernetes REST API服務(wù)器揍障，但如果要全面地研究REST API并與之交互，在本章最后會介紹更好的方式俩由。暫時來看毒嫡，像這樣使用curl進行研究，對我們理解一個應(yīng)用如何在pod中運行并與Kubernetes交互已經(jīng)足夠幻梯。

8.2.2 從pod內(nèi)部與API服務(wù)器進行交互

我們已經(jīng)知道如何從本機通過使用kubectl proxy與API服務(wù)器進行交互《祷現(xiàn)在我們來研究從一個pod內(nèi)部訪問它，這種情況下通常沒有kubectl可用碘梢。因此膳叨，想要從pod內(nèi)部與API服務(wù)器進行交互，需要關(guān)注以下三件事情：

• 確定API服務(wù)器的位置
• 確保是與API服務(wù)器進行交互痘系，而不是一個冒名者
• 通過服務(wù)器的認證菲嘴，否則將不能查看任何內(nèi)容以及進行任何操作

接下來我們看一下交互如何實現(xiàn)。

運行一個pod來嘗試與API服務(wù)器進行通信

首先需要一個pod以便從它內(nèi)部發(fā)起與API服務(wù)器的交互汰翠。運行一個什么也不做的pod（在它僅有的容器內(nèi)部運行一個sleep命令）龄坪，然后通過 kubectl exec 在容器內(nèi)部運行一個腳本，接下來在腳本中使用curl嘗試訪問API服務(wù)器复唤。

因此健田，需要使用一個包含curl二進制的容器鏡像。如果在Docker Hub中搜索佛纫，就會發(fā)現(xiàn)curlimages/curl鏡像妓局，可以使用這個鏡像（也可以使用任何包含curl二進制的已有鏡像或者自己打包的鏡像）。pod的定義如下面的代碼清單所示呈宇。

代碼清單8.12 用來嘗試與API服務(wù)器通信的pod:curl.yaml

apiVersion: v1kind: Podmetadata:  name: curlspec:  containers:  - name: main    image: curlimages/curl  #使用curl    command: ["sleep", "9999999"] #保持容器處于運行狀態(tài)

在完成pod的創(chuàng)建后好爬，在容器中運行kubectl exec來啟動一個bash shell：

$ kubectl exec curl -it -- sh

我們現(xiàn)在已經(jīng)做好了與API服務(wù)器交互的準(zhǔn)備。

發(fā)現(xiàn)API服務(wù)器地址

首先甥啄，需要找到Kubernetes API服務(wù)器的IP地址和端口存炮。這一點比較容易做到，因為一個名為kubernetes的服務(wù)在默認的命名空間被自動暴露蜈漓，并被配置為指向API服務(wù)器穆桂。也許你應(yīng)該記得，每次使用kubectl get svc命令顯示所有服務(wù)清單時融虽，都會看到這個服務(wù)享完。

$ kubectl get svc

在第5章中說過每個服務(wù)都被配置了對應(yīng)的環(huán)境變量，在容器內(nèi)通過查詢 KUBERNETES_SERVICE_HOST 和 KUBERNETES_SERVICE_PORT 這兩個環(huán)境變量就可以獲取API服務(wù)器的IP地址和端口有额。

curl:/$ env | grep KUBERNETES_SERVICEKUBERNETES_SERVICE_PORT=443KUBERNETES_SERVICE_PORT_HTTPS=443KUBERNETES_SERVICE_HOST=10.96.0.1

同樣般又，我們應(yīng)該記得每個服務(wù)都可以獲得一個DNS入口彼绷，所以甚至沒有必要去查詢環(huán)境變量，而只是簡單地將curl指向 https://kubernetes 倒源。公平地講，如果我們不知道服務(wù)在哪個端口是可用的句狼，既可以查詢環(huán)境變量笋熬，也可以查看DNS SRV記錄來得到實際的端口號。

之前展示的環(huán)境變量說明API服務(wù)器監(jiān)聽HTTPS協(xié)議默認的443端口腻菇，所以嘗試通過HTTPS協(xié)議來訪問服務(wù)器胳螟。

curl:/$ curl https://10.96.0.1

雖然最簡單的繞開這一步驟的方式是使用推薦的-k選項（這也是我們在手工操作API服務(wù)器時通常會使用的方式），但還是來看一下更長（也是正確）的途徑筹吐。我們應(yīng)該通過使用curl檢查證書的方式驗證API服務(wù)器的身份糖耸，而不是盲目地相信連接的服務(wù)是可信的。

提示 在真實的應(yīng)用中丘薛，永遠不要跳過檢查服務(wù)器證書的環(huán)節(jié)嘉竟。這樣做會導(dǎo)致你的應(yīng)用驗證憑證暴露給采用中間人攻擊方式的攻擊者。

驗證服務(wù)器身份

在之前的章節(jié)中洋侨，在討論Secret時舍扰，我們看到一個名為defalut-token-xyz的Secret被自動創(chuàng)建，并掛載到每個容器的/var/run/secrets/http://kubernetes.io/serviceaccount目錄下希坚。讓我們查看目錄下的文件边苹，再次看一下Secret的內(nèi)容。

curl:/$  ls /var/run/secrets/kubernetes.io/serviceaccountca.crt     namespace  token

Secret有三個入口（因此在Secret卷中有三個文件）〔蒙現(xiàn)在个束，我們關(guān)注一下ca.crt文件。該文件中包含了CA的證書聊疲，用來對Kubernetes API服務(wù)器證書進行簽名茬底。為了驗證正在交互的API服務(wù)器，我們需要檢查服務(wù)器的證書是否是由CA簽發(fā)获洲。curl允許使用-cacert選項來指定CA證書桩警，我們來嘗試重新訪問API服務(wù)器：

curl:/$ curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://10.96.0.1

注意 我們可能看到一個比“Unauthorized”更長的錯誤描述。

到目前為止昌妹，我們已經(jīng)取得進展捶枢，服務(wù)使用了我們信任的CA簽名的證書，所以curl驗證通過了服務(wù)器的身份飞崖，但Unauthorized這個響應(yīng)提醒我們需要關(guān)注授權(quán)的問題烂叔。同時，看一下如何通過設(shè)置 CURL_CA_BUNDLE 環(huán)境變量來簡化操作固歪，從而不必在每次運行curl時都指定 --cacert 選項：

curl:/$ export CURL_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

現(xiàn)在蒜鸡，我們可以不使用 --cacert 來訪問API服務(wù)器：

curl:/$ curl https://10.96.0.1

這樣操作相對便捷胯努，我們的客戶端（curl）現(xiàn)在信任API服務(wù)器，但API服務(wù)器并不確認訪問者的身份逢防，所以沒有授權(quán)允許訪問叶沛。

獲得API服務(wù)器授權(quán)

我們需要獲得API服務(wù)器的授權(quán)，以便可以讀取并進一步修改或刪除部署在集群中的API對象忘朝。為了獲得授權(quán)灰署，我們需要認證的憑證，幸運的是局嘁，憑證可以使用之前提到的default-token Secret來產(chǎn)生溉箕，同時憑證可以被存放在secret卷的token文件中。Secret這個名字就說明了它主要的作用悦昵。

可以使用憑證來訪問API服務(wù)器肴茄，第一步，將憑證掛載到環(huán)境變量中：

curl:/$ TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

此時但指，憑證已經(jīng)被存放在TOKEN環(huán)境變量中寡痰，如下面的代碼清單所示，可以在向API服務(wù)器發(fā)送請求時使用它棋凳。

代碼清單8.13 獲得API服務(wù)器的正確響應(yīng)

curl:/$ curl -N "Authorization: Bearer $TOKEN" https://10.96.0.1

關(guān)閉基于角色的訪問控制（RBAC）

如果我們正在使用一個帶有RBAC機制的Kubernetes集群氓癌，服務(wù)賬戶可能不會被授權(quán)訪問API服務(wù)器（或只有部分授權(quán)）。我們將在第12章詳細了解服務(wù)賬戶和RBAC機制贫橙。目前最簡單的方式就是運行下面的命令查詢API服務(wù)器贪婉，從而繞過RBAC方式。

$ kubectl create clusterrolebinding permissive-binding \  --clusterrole=cluster-admin \  -- group=system:serviceaccount

這個命令賦予了所有服務(wù)賬戶（也可以說所有的pod）的集群管理員權(quán)限卢肃，允許它們執(zhí)行任何需要的操作疲迂，很明顯這是一個危險的操作，永遠都不應(yīng)該在生產(chǎn)的集群中執(zhí)行莫湘，對于測試來說是沒有問題的尤蒿。

我們通過發(fā)送請求的HTTP頭中的Authorization字段向API服務(wù)器傳遞了憑證，API服務(wù)器識別確認憑證并返回正確的響應(yīng)幅垮，正如前面幾個章節(jié)我們所做的腰池，現(xiàn)在可以探索集群中所有的資源。

例如忙芒，可以列出集群中所有的pod示弓，但前提是我們知道運行curl的pod屬于哪個命名空間。

獲取當(dāng)前運行pod所在的命名空間

在本章的第一部分呵萨，我們了解了如何使用Downward API的方式將命名空間的屬性傳遞到pod奏属。如果你注意觀察的話，或許注意到secret卷中也包含了一個叫作命名空間的文件潮峦。這個文件包含了當(dāng)前運行pod所在的命名空間囱皿，所以我們可以讀取這個文件來獲得命名空間信息勇婴，而不是通過環(huán)境變量明確地傳遞信息到pod。文件內(nèi)容掛載到NS環(huán)境變量中嘱腥，然后列出所有的pod耕渴，如下面的代碼清單所示。

代碼清單8.14 獲取當(dāng)前pod所在命名空間中的所有pod清單

curl:/$ NS=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)curl:/$ curl -N "Authorization: Bearer $TOKEN" --cacert $CURL_BUNDLE https://10.96.0.1/api/v1/namespaces/$NS/pod

這就對了齿兔，通過使用掛載在secret卷目錄下的三個文件橱脸，可以羅列出與當(dāng)前pod運行在同一個命名空間下的所有pod的清單。使用同樣的方式不僅可以使用GET請求愧驱，還可以使用PUT或者PATCH來檢索和修改其他API對象慰技。

簡要說明pod如何與Kubernetes交互

我們來簡單說明一下在pod中運行的應(yīng)用如何正確訪問Kubernetes的API：

• 應(yīng)用應(yīng)該驗證API服務(wù)器的證書是否是證書機構(gòu)所簽發(fā)椭盏，這個證書是在ca.crt文件中组砚。
• 應(yīng)用應(yīng)該將它在token文件中持有的憑證通過Authorization標(biāo)頭來獲得API服務(wù)器的授權(quán)。

當(dāng)對pod所在命名空間的API對象進行CRUD操作時掏颊，應(yīng)該使用namespace文件來傳遞命名空間信息到API服務(wù)器糟红。

定義 CRUD代表創(chuàng)建、讀取乌叶、修改和刪除操作盆偿，與之對應(yīng)的HTTP方法分別是POST、GET准浴、PATCH/PUT以及DELETE事扭。

8.2.3 通過ambassador容器簡化與API服務(wù)器的交互

使用HTTPS、證書和授權(quán)憑證乐横，對于開發(fā)者來說看上去有點復(fù)雜求橄。碰到過開發(fā)者在許多場景下關(guān)閉了對服務(wù)器證書驗證的功能（當(dāng)然筆者有時候也會這么做）。幸運的是葡公，我們在保證安全性的前提下有辦法簡化通信的方式罐农。

還記得在8.2.1中提到過的 kubectl proxy 命令嗎？在本機上運行這個命令催什，從而可以更加方便地訪問API服務(wù)器涵亏。向代理而不是直接向API服務(wù)器發(fā)送請求，通過代理來處理授權(quán)蒲凶、加密和服務(wù)器驗證气筋。同樣，也可以在pod中這么操作旋圆。

ambassador容器模式介紹

想象一下裆悄，如果一個應(yīng)用需要查詢API服務(wù)器（此外還有其他原因）。除了像之前章節(jié)講到的直接與API服務(wù)器交互臂聋，可以在主容器運行的同時光稼，啟動一個ambassador容器或南，并在其中運行 kubecctl proxy 命令，通過它來實現(xiàn)與API服務(wù)器的交互艾君。

在這種模式下采够，運行在主容器中的應(yīng)用不是直接與API服務(wù)器進行交互，而是通過HTTP協(xié)議（不是HTTPS協(xié)議）與ambassador連接冰垄，并且由ambassador通過HTTPS協(xié)議來連接API服務(wù)器蹬癌，對應(yīng)用透明地來處理安全問題（見圖8.6）。這種方式同樣使用了默認憑證Secret卷中的文件虹茶。

因為在同一個pod中的所有連接共享同樣的回送網(wǎng)絡(luò)接口逝薪，所以我們的應(yīng)用可以使用本地的端口來訪問代理。

運行帶有附加ambassador容器的CURL pod

為了通過操作來理解ambassador容器模式蝴罪，我們像之前創(chuàng)建curl pod一樣創(chuàng)建一個新的pod董济，但這次不是僅僅在pod中運行單個容器，而是基于一個多用途的kubectl-proxy容器鏡像來運行一個額外的ambassador容器要门，這個鏡像是之前創(chuàng)建的并已提交到Docker Hub虏肾。如果你想自己來編譯它，可以在代碼存檔中找到Dockerfile鏡像（在 /Chapter08/kubectl-proxy/ 目錄下）欢搜。

pod的manifest文件如以下代碼清單所示封豪。(tutum/curl已被廢棄)

代碼清單8.15 帶有ambassador容器的 pod:curl-with-ambassador.yaml

apiVersion: v1kind: Podmetadata:  name: curl-with-ambassadorspec:  containers:  - name: main    image: curlimages/curl    command: ["sleep", "9999999"]  - name: ambassador  #ambassador 容器    image: datawire/ambassador

pod的spec與之前非常類似，但pod名稱是不同的炒瘟，同時增加了一個額外的容器吹埠。運行這個pod，并且通過以下命令進入主容器：

$ kubectl exec -it curl-with-ambassador -c main bash

現(xiàn)在pod包含兩個容器疮装，我們希望在main容器中運行bash缘琅，所以使用 -c main 選項。如果想在pod的第一個容器中運行該命令斩个，也無須明確地指定容器胯杭。但如果想在任何其他的容器中運行這個命令，就需要使用 -c 選項來說明容器的名稱受啥。

通過ambassador來與API服務(wù)器進行交互

接下來我們嘗試通過ambassador容器來連接API服務(wù)器做个。默認情況下， kubectl proxy 綁定8001端口滚局，由于pod中的兩個容器共享包括回送地址在內(nèi)的相同的網(wǎng)絡(luò)接口居暖，可以如下面的代碼清單所示，將curl指向 localhost:8001 藤肢。

代碼清單8.16 通過ambassador容器訪問API服務(wù)器

root@curl-with-ambassador:/# curl localhost:8001

成功了太闺！curl的輸出打印結(jié)果與我們之前看到的響應(yīng)相同，但這次嘁圈，并不需要處理授權(quán)的憑證和服務(wù)器證書省骂。

想要清楚地了解處理的細節(jié)蟀淮，請參考圖8.7。curl向在ambassador容器內(nèi)運行的代理發(fā)送普通的HTTP請求（不包含任何授權(quán)相關(guān)的標(biāo)頭）钞澳，然后代理向API服務(wù)器發(fā)送HTTPS請求怠惶，通過發(fā)送憑證來對客戶端授權(quán)，同時通過驗證證書來識別服務(wù)器的身份轧粟。

這是一個很好的例子策治，它說明了如何使用一個ambassador容器來屏蔽連接外部服務(wù)的復(fù)雜性，從而簡化在主容器中運行的應(yīng)用兰吟。ambassador容器可以跨多個應(yīng)用復(fù)用通惫，而且與主應(yīng)用使用的開發(fā)語言無關(guān)。負面因素是需要運行額外的進程混蔼，并且消耗資源履腋。

8.2.4 使用客戶端庫與API服務(wù)器交互

在之前的例子中，我們已經(jīng)體驗到了使用ambassador容器kubectl-proxy的好處拄丰，如果我們的應(yīng)用僅僅需要在API服務(wù)器執(zhí)行一些簡單的操作府树，往往可以使用一個標(biāo)準(zhǔn)的客戶端庫來執(zhí)行簡單的HTTP請求俐末。但對于執(zhí)行更復(fù)雜的API請求來說料按，使用某個已有的Kubernetes API客戶端庫會更好一點。

使用已有的客戶端庫

目前卓箫，存在由API Machinery special interest group（SIG）支持的兩個版本的Kuberbetes API客戶端庫载矿。

• Golang client — https://github.com/kubernetes/client-go
• Python — https://github.com/kubernetes-incubator/client-python

注意 Kubernetes社區(qū)有大量的興趣組和工作組，這些小組分別關(guān)注著Kubernetes生態(tài)系統(tǒng)中的某個特定部分烹卒∶瓶可以在https://github.com/kubernetes/community/blob/master/sig-list.md下看到它們的清單。

除了官方支持的兩個庫旅急，這里列出了一些由用戶貢獻的針對不同語言的客戶端庫：

• Fabric8維護的Java客戶端 — https://github.com/fabric8io/kubernetes-client
• Amdatu維護的Java客戶端 — https://bitbucket.org/amdatulabs/amdatu-kubernetes
• tenxcloud維護的Node.js客戶端 — https://github.com/tenxcloud/node-kubernetesclient
• GoDaddy維護的Node.js客戶端 — https://github.com/godaddy/kubernetes-client
• PHP — https://github.com/devstub/kubernetes-api-php-client 另一個PHP客戶端 — https://github.com/maclof/kubernetes-client
• Ruby — https://github.com/Ch00k/kubr
• 另一個Ruby客戶端 — https://github.com/abonas/kubeclient
• Clojure — https://github.com/yanatan16/clj-kubernetes-api
• Scala — https://github.com/doriordan/skuber
• Perl — https://metacpan.org/pod/Net::Kubernetes

這些庫通常支持HTTPS協(xié)議逢勾，并且可以處理授權(quán)操作，所以我們不需要使用ambassador容器藐吮。

一個使用Fabric8 Java庫與Kubernetes進行交互的例子

為了說明如何通過客戶端庫與API服務(wù)器進行交互溺拱，以下的代碼清單給出了一個例子說明如何使用Fabric8 Kubernetes客戶端列出一個Java應(yīng)用中的服務(wù)。

使用Swagger和OpenAPI打造你自己的庫

如果我們選擇的開發(fā)語言沒有可用的客戶端谣辞，可以使用Swagger API框架生成客戶端庫和文檔迫摔。Kubernetes API服務(wù)器在/swaggerapi下暴露Swagger API定義，在/swagger.json下暴露OpenAPI定義泥从。

想要了解更多關(guān)于Swagger框架的內(nèi)容句占，請訪問網(wǎng)站 http://swagger.io 。

使用Swagger UI研究API

在本章開頭躯嫉，已經(jīng)提到了一種更好的研究Rest API的方式纱烘，而不是使用curl直接訪問REST endpoint杨拐。正如在前面部分所提到的，Swagger不僅是描述API的工具擂啥，如果暴露了Swagger API定義戏阅，還能夠提供一個用于查看REST API的web UI。

Kubernetes不僅暴露了Swagger API啤它，同時也有與API服務(wù)器集成的Swagger UI奕筐。Swagger UI默認狀態(tài)沒有激活，可以通過使用 --enable-swagger-ui=true 選項運行API服務(wù)器對其進行激活变骡。

提示 如果使用Minikube离赫，可以在啟動集群時，使用 minikube start--extra-config=apiserver.Features.Enable-SwaggerUI=true 選項來激活Swagger UI塌碌。

在激活UI后渊胸，可以通過以下地址在瀏覽器中打開它：

http(s)://<api server>:<port>/swagger-ui

強烈建議嘗試使用Swagger UI，通過它不僅可以瀏覽Kubernetes API台妆，也可以使用它來進行交互（例如翎猛，可以 POST JSON 資源manifest、PATCH資源或者DELETE它們）接剩。