【03】Kubernets：K8S 操做入門

寫在前面的話

 

通過上一節，咱們順利將 K8S 集羣搭建了起來，在其中我也簡單的談了一下關於 K8S 的網絡。那麼這一節咱們主要談談如何來簡單的使用 K8S 的命令。固然這些命令有不少，咱們只是經過一個小例子來操做講解。是不全面的。

可是其實更多的目的是爲了介紹一種方法。在後期的應用中，咱們也會和 docker 同樣，慢慢的摒棄掉這種純手敲命令的形式，並且換成更爲直觀的資源清單（yaml 文件）的形式。

並且本章節咱們會好好談談在 K8S 中很是重要的幾個概念中的一部分，主要包括：Pod 和 Service 部分。

至於控制器 Controller 這些內容，咱們會在更後邊的時候詳講。

 

 

關於 Pod

 

咱們一直都在說，Pod 是 K8S 可以調度的最小單元。那啥是 Pod？

Pod 實際上是一個容器集，由 1 個甚至多個容器組成，它們的關係屬於緊密到不宜分割。一個 Pod 內的全部容器都運行在同一個節點上。

咱們能夠作個比喻，把一個學校比做 K8S，咱們每一個人就像一個容器，那麼一個班就是一個 Pod，同專業多個班一塊兒組成 Service，學校通常調度都是調度的專業，固然他也能夠調度某個班。但咱們能夠假設他不會有事沒事專門去調度某個學生。

同一組的 Pod 共享 networks / uts / storage / volumes，經過 IPC 機制進行通信。跨 Pod 的容器須要外部網絡插件實現通訊，每個 Pod 有一個屬於本身的 IP，此時容器就再也不有本身的 IP 了。

對於 K8S 而言，最初和最終的目的都是爲了運行 Pod，至於其餘一些組件，其目的仍是爲了服務運行 Pod。

Pod 能夠分爲兩類：自主式 Pod 和控制器管理的 Pod。

此時咱們再回頭來看用戶訪問 K8S 的服務就能夠這樣理解：

用戶訪問的實際上是某個提供服務的 Pod，請求先是到達宿主機（Node IP）的對應端口，而後將其轉發給指定的 Service（Cluster IP），而後經過 kube-proxy 的 ipvs 規則再度將其轉發到指定的 Pod（Pod IP）。固然到達 Pod 仍然會有相應的規則訪問到 Pod 內的指定容器。

在咱們使用集羣的時候，仍是建議在 K8S 集羣外部再度加一層做爲 Load Balance，同時輔以 Keepalive 實現高可用。

至於若是咱們想隔離 Pod，只須要採用不一樣的名稱空間（Namespace）就行。

 

 

關於 Service

 

當請求到達宿主機（Node IP）的時候，請求是沒法直接到達 Pod 的，並且還多是多個 Pod 的狀況。

因此咱們須要在這一個或者多個 Pod 前面再給它加一層，用來提供一個固定的訪問端點（Cluster IP）。

經過標籤選擇器（Label selector）讓 Pod 和這個訪問端點（Service）進行綁定，就能實現 Service 網絡和 Pod 網絡的通訊。

但咱們最終目的仍是實現宿主機 Node 網絡和 Service 網絡通訊，這就須要 K8S 一個附件（DNS）來實現。具體細節就很少講，咱們大體知道這些原理就行。

你可能會有學習 docker 容器時同樣的疑問，後端 Pod 說不定就重構了，IP 變了，豈不意味這咱們須要關注 Service 的配置？

這是徹底沒有必要的，咱們提到了 Service 網絡到 Pod 網絡是經過 Label selector 標籤選擇器綁定，這意味着，只要你標籤不變，不管怎麼更新，Service 上面的解析地址永遠是對的。

同理，咱們在 Node 上訪問 Service 網絡也不須要有這些擔憂，由於這裏也不是直接經過 IP 訪問，並且經過特定的名稱。

最後須要記住，每組 Pod 應用都該擁有本身單獨的 Service 進行調度。

 

 

關於 Controller

 

咱們這裏只是簡單的先讓你們知道有控制器這個東西，至於更加詳細的關於各類控制器的功能，會在以後特定的資源清單的時候詳解。

那麼，啥是控制器（Controller）？

咱們以前在第一節講 Master 組成的時候說過，Master 由 Controller-manager / Scheduler / APIServer 組成，那時候說過，Controller-manager 是集羣中進行統一資源管理的東西。那麼 Controller 的做用就是管理 Pod 的運行規則。

在 K8S 中常見的 Controller 有如下幾種：

1. ReplicationController

2. RelicaSet

3. Deployment（咱們當前用的最多的，也是默認的）

4. StatefulSet

5. DeamonSet

6. Job,Cronjob

 

 

K8S 命令提示不全 

 

這裏單獨提一下，當咱們手敲 K8S 命令的時候，不少時候須要去 --help 看參數命令，這顯然不方便，咱們這裏提供一個可以讓咱們 tab 鍵提示命令的配置。注意，第一配置後須要登出再次登陸讓環境生效。

yum install -y bash-completion
source /usr/share/bash-completion/bash_completion
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

 

 

K8S 命令 

 

咱們能夠經過 kubectl -h 查看到 K8S 支持的命令，這裏我作個簡單的整理說明：

參數	說明
create	從文件或者輸入建立
run	在集羣中運行一個指定的鏡像（幾乎沒用了）
expose	建立 Service
set	給對象設置一個指定的特徵
explain	查看資源的文檔（重要，幫助查參數）
get	獲取資源信息（用的最多）
edit	直接編輯資源運行狀態
delete	經過文件或者其餘刪除資源
rollout	主要用於版本升級和版本回滾（重要）
scale	直接更新資源的副本數量
autoscale	自動調整資源的副本數量
certificate	修改 certificate 資源
cluster-info	顯示集羣信息
top	顯示系統資源使用狀況
cordon	標記 node 爲 unschedulable
uncordon	標記 node 爲 schedulable
taint	更新 node 的 taints
describe	顯示指定資源的詳情（實用）
logs	輸出容器在 pod 中的日誌（重要，用於排錯）
attach	進入到一個運行中的 container
exec	在一個 container 中執行一個命令
port-forward	端口轉發
proxy	運行一個 proxy 到 Kubernetes API server
cp	複製
auth	Inspect authorization
diff	Diff live version against would-be applied version
apply	經過文件名或輸入對資源進行配置（很是重要）
patch	更新資源的 field(s)
replace	經過文件或者輸入換一個資源
wait	Experimental: Wait for a specific condition on one or many resources
convert	在不一樣的 API versions 轉換配置文件
kustomize	Build a kustomization target from a directory or a remote url
label	更新在這個資源上的標籤
annotate	更新一個資源的註解
completion	Output shell completion code for the specified shell (bash or zsh)
api-resources	Print the supported API resources on the server
api-versions	Print the supported API versions on the server, in the form of "group/version"
config	修改 kubeconfig 文件
plugin	Provides utilities for interacting with plugins
version	輸出 client 和 server 的版本信息

有些沒有翻譯或者標記的，要麼用的比較少，要麼現階段意義不大。

 

 

示例：增刪查改一個 Nginx Pod

 

咱們經過一個示例，看看整個過程當中咱們用到了那些命令。

【1】建立一個 Nginx Pod：

kubectl run nginx-demo --image=nginx:1.14-alpine --port=80 --replicas=1

結果如圖：

這裏簡單的對命令進行一個說明：

咱們經過 run 運行一個 deployment 控制器取名爲 nginx-demo，並經過 --image 指定了鏡像版本，--port 說明了服務端口，只是說明，並不能暴露端口，--replicas 指明瞭副本運行數量。

在命令執行過程當中會有一個提示，不用在乎，咱們只須要看到下面 created，代表這個服務是建立成功的。

 

【2】查看 deployment 信息：

# 獲取存在的 deployment
kubectl get deployment

# 查看指定 deployment 信息
kubectl get deployment nginx-demo -o wide

# 查看指定 deployment 詳細的信息
kubectl describe deployment nginx-demo

結果如圖：

這裏有兩個點須要知道，一是 -o wide，這個是顯示更多信息，除此以外還有 -w，這個是動態顯示，有點像 linux 的 top 命令。

另一個就是 describe 命令的做用，該命令可以幫我排查啓動過程當中的錯誤，很是實用。

 

【3】查看 Pod 信息同理：

# 查看有哪些  pod
kubectl get pods

# 查看指定 pod
kubectl get pods nginx-demo-549b77b6c5-5nwhz -o wide

# 查看指定 pod 詳細信息
kubectl describe pods nginx-demo-549b77b6c5-5nwhz

結果如圖：

咱們可以看到該 Pod 運行的節點與分配到的 IP 地址。

 

【4】集羣內訪問測試 Pod：

curl 10.1.2.2

結果如圖：

能夠看到集羣內部是能夠直接訪問到 Pod 網段並訪問到 Pod 的服務的。可是集羣外部不行。

 

【5】讓外部網絡也能訪問到 Nginx：

以前咱們說過，想讓外部訪問，咱們必須把在 Pod 外面再套一層 Service，讓 Service 和宿主機之間作 DNS 解析。

因此咱們來建立一個 Service：

kubectl expose deployment nginx-demo --name=nginx-svc --port=80 --target-port=80 --type=NodePort

這個命令能夠當作，咱們將名爲 nginx-demo 的 deployment 的 80 端口暴露出去，並給這個 service 取名爲 nginx-svc。

至於 type 的意義，後面咱們會詳細的講解。

 

【6】查看建立的 Service：

# 查看有哪些 Service
kubectl get svc

# 查看指定 Service
kubectl get svc nginx-svc -o wide

咱們這裏把 services 簡寫成 svc，方便使用。這種事情在 K8S 中很常見。結果如圖：

能夠看到，咱們的服務被映射成爲 32118 端口，這個端口是一個大於 30000 的隨機端口。

可使用集羣中任意節點 IP + 32118 端口訪問到 Nginx：

 

【7】查看日誌：

kubectl logs nginx-demo-549b77b6c5-5nwhz

結果如圖：

 

【8】集羣管理（擴容和縮減）

# 擴容成3個
kubectl scale deployment nginx-demo --replicas=3

# 查看
kubectl get deployment nginx-demo -o wide

結果如圖：

同理，若是要減小節點數，只須要將 replicas 減少就行。

 

【9】版本升級與回滾：

首先來看下版本升級，其實際就是將鏡像的版本作變動：

kubectl set image deployment nginx-demo nginx-demo=nginx:1.15-alpine --record

查看更新後結果：

kubectl describe deployment nginx-demo

結果如圖：

此時，咱們能夠查看咱們升級過的版本：

kubectl rollout history deployment nginx-demo

結果如圖：

由於有了這個東西，咱們回滾版本就有了兩種選擇，一是回滾上個版本，一是回滾指定版本：

# 回滾上個版本
kubectl rollout undo deployment nginx-demo

# 回滾指定版本
kubectl rollout undo deployment nginx-demo --to-revision=2

--to-reversion 指定的數字就是經過 history 看到的編號。 

 

【10】最後就是刪除操做：

刪除 Pod：

kubectl delete pod nginx-demo-76844fcc4d-49hf2

結果如圖：

能夠看到刪除成功了，可是並無意義，由於 K8S 會再給我啓動一個新的，這就是 K8S 的自愈能力。

 

刪除 deployment：

kubectl delete deployment nginx-demo

結果如圖：

獲得的結論是，deployment 刪除，pod 也就跟着刪除。

 

刪除 Service：

kubectl delete svc nginx-svc

結果如圖：

 

 

小結

 

咱們這裏提到的其實就是一小部分命令和參數，後續還會有不少，這得再以後用到的時候才方便詳細講解，後面也不會再以命令爲主。

但這並不意味着這些基礎的命令咱們能夠不知道，這些屬於咱們學習 K8S 的基礎。