edx-LFS158x Kubernetes學習筆記(第七章)

Chapter 7. Accessing Minikube

Introduction and Learning Objectives

在本章中，我們將研究訪問Kubernetes集群的不同方法。有多種外部客戶機或自定義腳本提供用於管理目的的群集訪問。我們將使用kubectl作為CLI工具來訪問Minikube Kubernetes集群，將Kubernetes儀表板用作與集群交互的基於web的用戶界面，並使用curl命令，該命令具有通過api訪問集群的正確憑據。 在本章結束時，您應該能夠：

• 查看訪問任何Kubernetes集群的方法。
• 為Linux、macOS和Windows配置kubectl。
• 從儀表板訪問Minikube群集。
• 通過API訪問Minikube。

Accessing Minikube

Accessing Minikube

任何運行正常的Kubernetes集群都可以通過以下任一方法訪問：

• 命令行界面（CLI）工具和腳本
• 通過Web瀏覽器的基於Web的用戶界面（Web UI）
• 通過CLI或以編程方式的api 這些方法適用於所有的Kubernetes集群。

Accessing Minikube: Command Line Interface (CLI)

kubectl是用於管理集群資源和應用程序的Kubernetes命令行界面（CLI）客戶端。它可以單獨使用，也可以作為腳本和自動化工具的一部分使用。一旦為kubectl配置了所有必需的身份憑據和集群訪問點，就可以從任何地方遠程使用它來訪問集群。 在後面的章節中，我們將使用kubectl來部署應用程序、管理和配置Kubernetes資源。

Accessing Minikube: Web-based User Interface (Web UI)

Kubernetes儀表板提供了一個基於Web的用戶界面(Web UI)，可以與Kubernetes集群交互來管理資源和容器化的應用程序。在後面的章節中，我們將使用它來部署一個容器化的應用程序;

Accessing Minikube: APIs

我們知道，Kubernetes有API服務器，operator/用戶從外部世界連接到它，與集群交互。使用CLI和Web UI，我們可以連接到Master Node上運行的API Server來執行不同的操作。我們可以使用API端點直接連接到API服務器並向其發送命令，只要我們能夠訪問主節點並擁有正確的憑據。 下面，我們可以看到Kubernetes的HTTP API空間的一部分：

HTTP API Space of Kubernetes

Kubernetes的HTTP API空間可以分為三個獨立的組：

• 核心組（/api/v1） 該組包括諸如Pods、services、nodes、namespaces、configmaps、secrets等對象。
• 命名組 此組包括/api/NAME/NAME/NAME/VERSION格式的對象。這些不同的API版本意味著不同的穩定性和支持級別： Alpha level水平-它可以在任何時間點下降，沒有通知。例如，/apis/batch/v2alpha1。 Beta level-它經過了很好的測試，但是在隨後的Beta或穩定版本中，對象的語義可能會以不兼容的方式發生變化。例如，/apis/certificates.k8s.io/v1beta1。 Stable level-出現在許多後續版本的發佈軟件中。例如，/apis/networking.k8s.io/v1。
• 系統範圍 這個組由系統範圍的API端點組成，如/healthz、/logs、/metrics、/ui等。

我們可以通過調用相應的API端點或通過CLI/Web UI直接連接到API服務器。 接下來，我們將看到如何訪問我們在上一章中設置的Minikube環境。

kubectl

kubectl通常在安裝Minikube之前安裝，但我們也可以在安裝之後安裝。安裝後，kubectl會自動接收其配置，以便Minikube Kubernetes集群訪問。但是，在其他Kubernetes集群設置中，我們可能需要配置kubectl訪問集群所需的集群訪問點和證書。 Kubernetes文檔中提到了安裝kubectl的不同方法。為了獲得最佳效果，建議將kubectl與Minikube運行的Kubernetes保持在同一版本上——在編寫課程時，最新的穩定版本是v1.14.1。接下來，我們將看幾個步驟來在Linux、macOS和Windows系統上安裝它。

Installing kubectl on Linux

Installing kubectl on macOS

Installing kubectl on Windows

kubectl Configuration File

要訪問Kubernetes集群，kubectl客戶機需要主節點端點和適當的憑據才能與主節點上運行的API服務器交互。啟動Minikube時，默認情況下，啟動進程會在.kube目錄（通常稱為dot-kube配置文件）中創建一個配置文件config，該文件位於用戶的主目錄中。配置文件包含kubectl所需的所有連接詳細信息。默認情況下，kubectl二進制文件將分析此文件以查找主節點的連接端點以及憑據。要查看連接詳細信息，我們可以查看~/.kube/config文件的內容（在Linux上）或運行以下命令：

<code>$kubectl config view
apiVersion: v1
clusters:
- cluster:
   certificate-authority: /home/student/.minikube/ca.crt
   server: https://192.168.99.100:8443
 name: minikube
contexts:
- context:
   cluster: minikube
   user: minikube
 name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
 user:
   client-certificate: /home/student/.minikube/client.crt
   client-key: /home/student/.minikube/client.key
/<code>

安裝kubectl後，我們可以使用kubectl cluster info命令獲取有關Minikube集群的信息：

<code>$ kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443
KubeDNS is running at https://192.168.99.100:8443//api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
/<code>

您可以在這裡找到有關kubectl命令行選項的更多詳細信息。 儘管對於Minikube安裝的Kubernetes集群，會自動創建~/.kube/config文件，但對於其他工具安裝的Kubernetes集群，情況並非如此。在其他情況下，必須手動創建配置文件，有時需要修改配置以適應各種網絡和客戶機/服務器設置。

Installing kubectl CLI Client (Demo)

Kubernetes Dashboard

如前所述，Kubernetes儀表板為Kubernetes集群管理提供了一個基於web的用戶界面。要從Minikube訪問儀表板，我們可以使用Minikube dashboard命令，該命令在web瀏覽器上打開一個新選項卡，顯示Kubernetes儀表板：

<code>$ minikube dashboard
/<code>

注意：如果瀏覽器沒有打開另一個選項卡並且沒有按預期顯示儀表板，請驗證終端中的輸出，因為它可能會顯示儀表板的鏈接（以及一些錯誤消息）。將該鏈接複製並粘貼到瀏覽器的新選項卡中。根據終端的功能，您可以單擊或右鍵單擊鏈接直接在瀏覽器中打開。鏈接可能類似於： http://127.0.0.1:37751/api/v1/namespaces/kube-system/services/http:kubernetes-dashboard:/proxy/ 可能唯一的區別是端口號，上面是37751。您的端口號可能不同。 註銷/登錄或重新啟動系統後，應該就正常了（minikube dashboard命令直接在瀏覽器中打開顯示儀表板的新選項卡）。

The 'kubectl proxy' Command

發出kubectl proxy命令後，kubectl在主節點上使用API服務器進行身份驗證，並使儀表板在稍有不同的URL上可用，這次是通過代理端口8001。 首先，我們發出kubectl proxy命令：

<code>$ kubectl proxy
Starting to serve on 127.0.0.1:8001
/<code>

只要代理運行，它就會鎖定終端。運行代理後，我們可以通過新的URL訪問儀表板（只需單擊下面的它-它應該可以在您的工作站上工作）。一旦停止代理（使用CTRL+C），儀表板就不再可訪問。 http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard:/proxy/#!/overview?namespace=default

Kubernetes Dashboard over the proxy

APIs - with 'kubectl proxy'

當kubectl代理運行時，我們可以通過代理端口8001上的本地主機向API發送請求（從另一個終端，因為proxy鎖定了第一個終端）：

<code>$ curl http://localhost:8001/
{
 "paths": [
   "/api", 

   "/api/v1",
   "/apis",
   "/apis/apps",
   ......
   ......
   "/logs",
   "/metrics",
   "/openapi/v2",
   "/version"
 ]
}
/<code>

通過上面的curl請求，我們從API服務器請求了所有API端點。單擊上面的鏈接（在curl命令中），它將在瀏覽器選項卡中打開相同的列表輸出。 我們可以使用curl或在瀏覽器中探索每個路徑組合，例如： http://localhost:8001/api/v1 http://localhost:8001/apis/apps/v1 http://localhost:8001/healthz http://localhost:8001/metrics

APIs - without 'kubectl proxy'

當不使用kubectl proxy時，我們需要在發送API請求時向API服務器進行身份驗證。我們可以在發出curl時提供不記名令牌，或者提供一組密鑰和證書來進行身份驗證。 不記名令牌是由認證服務器（主節點上的API服務器）生成並返回給客戶端的訪問令牌。使用該令牌，客戶端可以連接回Kubernetes API服務器，而無需提供進一步的身份驗證詳細信息，然後訪問資源。 獲取令牌：

<code>$ TOKEN=$(kubectl describe secret -n kube-system $(kubectl get secrets -n kube-system | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\\t' | tr -d " ")
/<code>

獲取API服務器終結點：

<code>$ APISERVER=$(kubectl config view | grep https | cut -f 2- -d ":" | tr -d " ")
/<code>

APISERVER存儲的IP與Kubernetes主IP相同. 通過以下2個命令並比較它們的輸出，確認是否相同：

<code>$ echo $APISERVER
https://192.168.99.100:8443
$ kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443 ...
/<code>

使用curl命令訪問API服務器，如下所示：

<code>$ curl $APISERVER --header "Authorization: Bearer $TOKEN" --insecure
{
 "paths": [
   "/api",
   "/api/v1",
   "/apis",
   "/apis/apps",
   ......
   ......
   "/logs",
   "/metrics",
   "/openapi/v2",
   "/version"
 ]
}
/<code>

我們可以從.kube/config文件中提取客戶端證書、客戶端密鑰和證書頒發機構數據，而不是訪問令牌。提取後，對它們進行編碼，然後使用curl命令進行身份驗證。新的curl命令類似於：

<code>$ curl $APISERVER --cert encoded-cert --key encoded-key --cacert encoded-ca

/<code>

Accessing the Cluster with Dashboard and Query APIs with CLI (Demo)

視頻解說;

閱讀更多 一直溫柔 的文章

關鍵字: 軟件 Line 學習