在上篇中，大至介紹了一下創建 k8s cluster 的各種方式。這篇則是動手來做一些簡單的操作，以此來了解一些 k8s 的基本概念。這篇的內容將會使用到許多 Kubernetes 基本介紹的內容，如果有任何專有名詞不太了解可以參照該文章。

使用 Minikube 創建本底 k8s cluster

:: 💡 有關 minikube 和 kubectl 的安裝請參照上篇 ::

首先必須在本地創建一個 k8s cluster，這裡我們使用 minikube 來創建。（有關 minikube 的安裝請參照上篇）。
➤ minikube start - 安裝好 minikube 後，創建本地 cluster。
➤ kubectl cluster-info - 創建好 k8s 後，取得 cluster 的基本信息。

這裡倒底發生了什麼事情呢？

首先 minikube 使用 environment variable KUBECONFIG 找到了我的 kubeconfig。
並且在本地創建了一個 virtual machine 作為 k8s node，並在上面運行了基本的 control plane 組件。這裡可以看到 master endpoint 是在本機上的 127.0.0.1:55008。

一般來說 kubeconfig 的預設路徑是 $HOME/.kube/config ，這是一個用於和所有 k8s 溝通的檔案。 kubeconfig包括三項主要信息 clusters、users、contexts (使用指令 kubectl config view --minify 來看 kubeconfig 的簡化內容)。

這裡介紹一下 kubeconfig 的基本，

cluster - 包含了所有 cluster 的基本信息，像是 name、kube-apiserver endpoint、certificate-authority。
user - 包含了所有的 user 的基本信息，像是 name 和 credentials (Ex. token、cert、username/password)。
context - 是使用 kubectl 時用於確認是使用哪個 user 溝通哪個 cluster ，每一個 context 是 user+cluster+namespace 的組合。
current-context - 則是目前所使用的 context。

一般來說使用者會和許多 clusters 溝通，每個 cluster 可能擁有多個不同的 user accounts 也可能共享同一個 user account。

kubectl

上圖中的 verbose log (flag -v6) 就顯示出指令 kubectl get pod 就是一個 HTTP GET Request 到 kube-apiserver (127.0.0.1) 的路徑 /api/v1/namespaces/default/pods。

在開始之前先說說 kubectl 吧！kubectl 是和 k8s 溝通的最基本工具，kubectl 會使用 kubeconfig 中的設定和資訊來和 cluster 溝通，上面說到 kubeconfig 中得 cluster 部分包含 kube-apiserver 的位置。這裡快速的介紹一下 kube-apiserver。
每個 k8s cluster 都會有一個 kube-apiserver，kube-apiserver 類似於一個開放的端口，是以個 REST Endpoint。而 kubectl 則是一個包裝好的客戶端，讓使用者能輕鬆的和 k8s cluster 互動，其實說到底也就是 HTTP Request 。

kubectl 的使用方式挺容易上手的，就是 1) kubectl 2) 動作 3) 資源 4) 名稱 [Optional]。

• 舉例來說使用者想要刪除名為 test 的 Pod 那就是 1) kubectl 2) 動作 delete 3) 資源 pod 4) 名稱 test → kubectl delete pod test 。
• 想要取得所有的 Pod 則是 1) kubeclt 2) 動作 get 3) 資源 pod => kubectl get pod。

當然並非所有指令都完全是這樣的結構，但大多數都是如此。使用 kubectl 時如果有不了解或不熟悉的指令時可以直接加上 --help 來觀看簡易的使用方式，如果有不理解的資源時也可以使用 kubectl explain 來觀看資源文檔。

Namespace

在創建好 cluster 後，首先要知道什麼是 Namespace。Namespace 是一個用於更好管理的 k8s 中資源的抽象的概念，k8s 中幾乎所有資源都有其所屬的 Naemespace。用英文來解釋可能更容易一些，簡單來說 Namespace 就是 Logical Grouping。

以上圖為例，在一個 k8s cluster 中有許多 Pod (k8s 的最小運行單位)，每個 Pod 會被 kube-scheduler 根據各種條件分配到不同的 Node 上運行，但使用者要如合使用 kubectl 來檢視這些 Pod 呢？這時 Namespace 的重要性就體現出來了，假設 Pod A、C、E 是屬於同一個組的軟體，這時使用 Namespace 將他們邏輯性的圈起來竟可以更方便的管理和檢視了。

剛創建好的 cluster 目前有四個預設的 Namespace，分別是 default、kube-node-lease、kube-public、kube-system 。

default 是 k8s 的預設 namespace，其中包含 k8s 的 kube-apiserver Endpoint。
kube-system 是 k8s 運行所有內部運行所需的資源的 namespace，其中包括幾乎所有的主組建 Master Components。
kube-public 是 k8s 中無需 authentication 的 namespace，這個 namespace 的存在只是 k8s 中的創建慣例，實際上可有可無。
kube-node-lease （可以不需要理解這個 Namespace 的用途）是用於與各個節點相關的租期（Lease）對象； 此對象的設計使得集群規模很大時節點心跳檢測性能得到提升。

下面用一段 asciinema 來簡單演示一下 Namespace 有關的 operations。

Pod

在上面的影片中我們在 Namespace 中快速的創建了幾個以水果和肉類命名的 Pod，那 Pod 是什麼呢？

簡單的說 Pod 是 k8s 中可以部署的最小單位。要細說的話 Pod 可可能會講不完，但一般使用 k8s 不需要知道所有的內容，這裡列出幾個簡單且常見的重點：

• Pod 是 k8s 中可部署的最小單位
• Pod 是一或多個 Container 的集合體
• Pod 中的 Container 共用同一個 Pod IP
• Pod 中的 Container 可以使用同樣的 Volume

可能會有人不太理解為何需要運行多的 Container ，常見的使用方式是將 Pod 分為Main Container 和 Sidecar Containers。Main Container 主要包含 Service 的主邏輯，而 Sidecar Container 則是用於輔助 Main Container。雖然被分做 Main 和 Sidecar，但實質上在 Pod 中他們並沒有區別，都是 Container。 常見的 sidecar 有 log watcher，用於將 log 發送至 centralized log service (ElasticSearch 或是 Splunk 等等)。

上面說到 k8s 中所有 resource 都是用 YAML 來定義的，這裡用最簡單的 Pod Spec內容來介紹如何創建一個 Pod。以下是一些 kubectl 常見的與 Pod 相關的指令。

總結

上面是在創建 k8s 後一些熟悉簡單操作的教程。相較於 k8s 高含量卻複雜的官方文檔，本文盡量摘取我認為一般使用者所需的內容，但可能也因此而省略了一些重要的內容，不過這對於沒影經驗的讀者來說這樣的起步相較起來會更平易近人一些。
我會在後續的文章中將 k8s 中許多重要的內容慢慢補齊。如果有任何疑問歡迎在facebook 上留言或者私訊我。