【本文目標(biāo)】

1. minikube睹簇、kubectl介紹

在上一篇文章【k8s學(xué)習(xí)】Kubernetes學(xué)習(xí)——核心組件和架構(gòu)中，介紹了兩個(gè)節(jié)點(diǎn)類型：Master節(jié)點(diǎn)和Worker節(jié)點(diǎn)寥闪。

而在現(xiàn)實(shí)中太惠，我們很難在本地機(jī)器上裝一個(gè)Kubernetes集群（比如CPU或是內(nèi)存的限制）。為此疲憋，誕生了開源項(xiàng)目：minikube凿渊。

minikube上安裝了Master的4個(gè)組件（Api Server，Scheduler缚柳，Controller manager埃脏，etcd）以及Worker的3個(gè)組件（（container runtime，kubelet秋忙，kebe-proxy））彩掐，相當(dāng)于把Master和Worker合并到一個(gè)Node上了，所以minikube只有一個(gè)節(jié)點(diǎn)灰追。我們可以很好的利用minikube在本地做一些測試堵幽。

我們想要操作minikube狗超，比如在節(jié)點(diǎn)上創(chuàng)建Pod、Service等朴下，這時(shí)候就需要用到kubectl了努咐。它是一個(gè)Kubernetes集群的命令行工具。

在上一篇文章中有講到Master Node上的組件Api Server是Kubernetes集群的唯一入口殴胧，那么想要和Api Server進(jìn)行交互的工具有很多渗稍，比如通過UI（Kubenetes Dashboard），或是API团滥， 或是命令行工具竿屹，而這里的命令行工具就是kubectl。在這三個(gè)客戶端工具中惫撰，kubectl是最強(qiáng)大的羔沙。

kubectl并不只是在minikube中使用，它也能管理Kubernetes集群厨钻。

2. minikube安裝

minikube官網(wǎng)：https://minikube.sigs.k8s.io/docs/
minikube github地址：https://github.com/kubernetes/minikube

可以參考官網(wǎng)教程或是網(wǎng)上其它教程來安裝minikube扼雏。

需要注意的是，minikube需要你的電腦支持virtualization技術(shù)夯膀。因?yàn)閙inikube是運(yùn)行在virtual box（虛擬機(jī)）中的诗充。這也是為什么在官網(wǎng)中會(huì)與：

Container or virtual machine manager, such as: Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox, or VMware Fusion/Workstation

另外，minikube的安裝依賴kubectl诱建，也就是說會(huì)把kubectl一并安裝蝴蜓。

3. minikube運(yùn)行

3.1 vm driver

啟動(dòng)minikube，這里的參數(shù)是告訴minikube我們需要哪個(gè)虛擬的driver俺猿，比如我們可以不用Docker茎匠，而是上述列表中的第二個(gè)Hyperkit（如果是MacOS，先用brew install hyperkit安裝之）押袍，那么在啟動(dòng)的時(shí)候就可以告訴minikube诵冒，使用的是hyperkit的vm driver：

minikube start --vm-driver=hyperkit

minikube里面是預(yù)先安裝了Container容器的runtime環(huán)境，所以并不需要預(yù)先安裝Docker也可以谊惭。當(dāng)然也可以安裝Docker作為上述的vm driver用汽馋，這時(shí)候啟動(dòng)的時(shí)候就需要用minikube start --vm-driver=docker

更多關(guān)于不同系統(tǒng)（linux/macos/windows）的vm driver的選擇：https://minikube.sigs.k8s.io/docs/drivers/

3.2 啟動(dòng)好后可以通過kubectl進(jìn)行交互

比如查看節(jié)點(diǎn)的信息圈盔，可以看到minikube有什么Role：

kubectl get node

image.png

如果想要更詳細(xì)的查看Node豹芯，可以使用kubectl describe命令，可以看到在namespace=kube-system下驱敲，有很多我們熟悉的組件：

kubectl describe node minikube

image.png

4. kubectl铁蹈，一些常用的命令

4.1 查看資源：kubectl get <組件>

官網(wǎng)：https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get

我們在上述使用kubectl get node來查看node的信息≈谡＃基本上木缝，kubectl get能加任何的資源（比如pod便锨、service围辙、deployment等等）我碟。

可以通過kubectl get -h來查看幫助文檔，或者看官網(wǎng)文檔姚建。

4.2 創(chuàng)建組件：kubectl create <組件>

官網(wǎng)：https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#create

kubectl create命令矫俺，也是非常強(qiáng)大的，我們通過kubectl create -h查看幫助文檔掸冤，可以看到通過這個(gè)命令可以創(chuàng)建以下組件：

kubectl create

但在這個(gè)list中沒有Pod厘托，原因是在實(shí)踐中我們通常會(huì)使用Deployment去創(chuàng)建Pod，原因在上一篇博文講的很清楚了稿湿。即開頭第1章節(jié)引用的文章铅匹。

示例：
創(chuàng)建Deployment的命令格式，可以看到名稱和鏡像是必填的：

kubectl create deployment NAME --image=image -- [COMMAND] [args...]

比如創(chuàng)建nginx的Pod饺藤，Kubernetes會(huì)去docker hub中根據(jù)輸入的image找到相應(yīng)的鏡像：

kubectl create deployment nginx-depl --image=nginx

kubectl create deployment

可以通過#4.1的kubectl get的命令查看deployment包斑，可以看到READY了：

kubectl get deployment

我們都知道Deployment是用來更好的生成Pod和ReplicaSet用的，所以我們在Kubernetes創(chuàng)建了Deployment涕俗，相應(yīng)的Pod和ReplicaSet也會(huì)創(chuàng)建（這是最終目的）：

• 會(huì)跟據(jù)name和image創(chuàng)建Pod罗丰，別的屬性都默認(rèn)，查看Pod的命令：kubectl get pod再姑，默認(rèn)的Pod Name是剛剛輸入的Deployment Name作為前綴 + ReplicaSet ID + 再加上一串隨機(jī)數(shù)（即自己的ID)萌抵。
• 會(huì)創(chuàng)建ReplicaSet，查看命令也差不多：kubectl get replicaset元镀，默認(rèn)會(huì)創(chuàng)建1個(gè)绍填。一般情況下我們不會(huì)自己去創(chuàng)建、修改栖疑、刪除ReplicaSet讨永，都是通過Deployment進(jìn)行操作，和Pod一樣蔽挠。

kubectl get pod

kubectl get replicaset

4.3 kubectl edit

kubectl edit deployment nginx-delp

通過這個(gè)命令住闯，可以看到剛剛我們通過kubectl create出來的創(chuàng)建，這個(gè)yaml是Kubernetes自動(dòng)生成出來的澳淑，除了必填項(xiàng)name和image之外比原，其它的都是默認(rèn)值：

在實(shí)現(xiàn)生產(chǎn)中，我們更多的是自己編寫yaml進(jìn)行部署杠巡，而不是直接使用kubectl create這樣的命令量窘。

下面的kind就是定義這個(gè)資源文件的類型，可以是Pod氢拥，Deployment蚌铜，Service等等锨侯。可以看下面的image中看到定義的nginx鏡像冬殃。

另外可以看到屬性replicas的個(gè)數(shù)是1囚痴。

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2022-06-16T13:09:34Z"
  generation: 1
  labels:
    app: nginx-depl
  name: nginx-depl
  namespace: default
  resourceVersion: "4726"
  uid: 968f297e-e7ef-4b23-bc7e-5298d84dae3a
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx-depl
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-depl
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 1
  conditions:
  - lastTransitionTime: "2022-06-16T13:10:01Z"
    lastUpdateTime: "2022-06-16T13:10:01Z"

如果我們修改了上述的image版本，從latest改到具體的某一個(gè)版本审葬，保存后深滚，就會(huì)立馬基于修改后的image生成新的ReplicaSet和Pod，老的Pod會(huì)Ternimated（終止）然后從列表中移除掉涣觉。

4.4 debug

4.4.1 查看組件的log痴荐，比如想要查看上述nginx Pod的log：kubectl logs -f <PodName>。

kubectl logs -f nginx-depl-5ddc44dd46-xbq4b

image.png

4.4.2 kubectl describe <資源> <資源名稱>官册，查看某個(gè)資源的詳細(xì)信息生兆，比如上述這個(gè)Pod：

kubectl describe pod nginx-depl-5ddc44dd46-xbq4b

部份截圖：

image.png

4.4.3 進(jìn)入到Pod容器內(nèi)
exec = execute
-it = interact terminal

kubectl exec -it nginx-depl-5ddc44dd46-xbq4b -- /bin/bash

image.png

4.5 kubectl delete <資源> <資源名稱>

比如我們可以通過命令kubectl delete deployment nginx-depl來刪除上面建的Deployment，相應(yīng)的Pod會(huì)自動(dòng)跟著Terminate（終止）并刪除膝宁，ReplicaSet也會(huì)跟著刪除鸦难。

4.6 kubectl apply -f <fileName>

如同上述說的，我們一般不會(huì)直接使用kubectl create來創(chuàng)建組件昆汹，因?yàn)榭赡軙?huì)有很多參數(shù)明刷，以及重復(fù)利用原則，所以這里的fileName就是Kubernetes的配置yaml文件满粗”材可以用kubectl apply來run我們寫的這個(gè)配置。

5. Kubernetes yaml配置文件

5.1 每個(gè)Kuberneted yaml配置文件一般包含三個(gè)部分：

metadata上面的兩行是必須有的聲明映皆，apiVersion是這個(gè)yaml的版本聲明挤聘，可能每個(gè)不同的kind種類，version會(huì)不一樣捅彻。
kind就是想要定義的組件（或者叫資源）组去。

• metadata：
  
  image.png
• specification：每個(gè)不同的kind的spec可能都會(huì)不太一樣。
  
  image.png
• status：這塊是Kubernetes自動(dòng)加上的步淹。對于status从隆，可能會(huì)有兩塊，1塊是期望的狀態(tài)（Desired status）缭裆，另一塊是現(xiàn)在的真實(shí)狀態(tài)（Actual status）键闺，如果兩者出現(xiàn)了不一致，Kubernetes集群就會(huì)嘗試去fix它澈驼。
  比如kind=Deployment辛燥，定義的spec.replicas = 2，然后用kubectl apply這個(gè)配置，當(dāng)status中的replicas = 1的時(shí)候挎塌，Kubernetes就會(huì)發(fā)現(xiàn)不一致了徘六，于是就會(huì)嘗試再啟動(dòng)一個(gè)Pod，以達(dá)到replica = 2的效果榴都。
  那么Kubernetes的配置中的當(dāng)前的status信息從哪里來呢待锈？在上一篇文章介紹過的，它是從Master節(jié)點(diǎn)的其中一個(gè)組件etcd中來的缭贡。

5.2 一些注意的點(diǎn)：

• 關(guān)于yaml文件炉擅，如果有一些格式上的錯(cuò)誤，那么將會(huì)導(dǎo)致組件無法啟動(dòng)阳惹，所以我們可以預(yù)先使用一些validator online的網(wǎng)址，去驗(yàn)證yaml的格式眶俩，如：https://codebeautify.org/yaml-validator
• yaml文件存放位置：從實(shí)踐上來說莹汤，可以和源代碼放在一起或是單獨(dú)放git repository。

5.3 Template：

示例是Deployment yaml配置：

image.png

5.4 Component間的相互聯(lián)系

Deployment yaml中定義了Deployment的metadata，也定義了Pod的metadata钞楼，那么組件間相互聯(lián)系的部分喇闸，靠的是：Labels，Selectors和Ports询件。

5.4.1 metadata中一般包含labels燃乍，spec中一般包含selector。
比如定義一個(gè)kind為Deployment的yaml配置宛琅，在metadata的labels中刻蟹，一般就是key-value的形式『俦伲可以看到有l(wèi)abels為：app = nginx舆瘪。

image.png

用matchLabels來匹配：
以下是Service的yaml配置，那么怎么把Deployment中的labels在Service中聯(lián)系起來呢红伦？用的是selector標(biāo)簽英古，可以看到selector下也是app = nginx。

image.png

5.4.2 Port
Service的spec中有ports的定義色建。
Development的template中定義的是Pod的信息哺呜，Pod的spec中定義了containers（因?yàn)閏ontainer是在pod里面運(yùn)行的，且理論上一個(gè)Pod可以運(yùn)行多個(gè)container容器，所以這里的containers屬性是放在Pod下面且是復(fù)數(shù)）某残，可以看到container中也定義了ports国撵。

Service中定義的port，是提供給外部應(yīng)用來訪問它的玻墅，targetPort則是尋找需要轉(zhuǎn)發(fā)給哪個(gè)Pod（這里定義的是8080）介牙，container中定義了自己的port是8080，這樣就match上了澳厢。即外部程序訪問80到這個(gè)Service环础，Service再轉(zhuǎn)發(fā)給端口為8080的Pod容器。

5.4.3 示例
我們把上述5.4.1中的兩個(gè)yaml運(yùn)行下：

image.png

image.png

image.png

查看Pod更多的信息，可以看到上述Service中的兩個(gè)Endpoint指向的IP就是我們創(chuàng)建的兩個(gè)Pod：

image.png

5.4.4 通過配置文件刪除剛剛創(chuàng)建的組件：

image.png

參考：
https://www.youtube.com/watch?v=X48VuDVv0do