【本文目标】
| mimikube、kubectl介绍 | ||
|---|---|---|
| minikube安装、运行 | ||
| 启动minikube | minikube start |
|
| 关闭minikube | minikube stop |
|
| 删除minikube | minikube delete |
|
| kubectl，一些常用的命令 | ||
| CURD命令 | ||
| 创建deployment | kubectl create deployment <name> |
|
| 编程deployment | kubectl edit deployment <name> |
|
| 编程deployment | kubectl delete deployment <name> |
|
| 查看组件的Status | ||
| 组件可以是：nodes, pod, service, replicaset, deployment | kubectl get <组件> |
|
| Debugging pods | ||
| 查看Log | kubectl logs <pod name> |
|
| 进入容器终端 | kubectl exec -it <pod name> -- bin/bash |
|
| 查看pod详细信息 | kubectl describe pod <pod name> |
|
| 使用yaml进行CURD | ||
| 让yaml配置生效，生成或修改组件 | kubectl apply -f <file name> |
|
| 利用yaml配置删除组件 | kubectl delete -f <file name> |
|
| Kubernetes yaml配置文件介绍 | ||
| 包含三个部分 |
metadata, spec(specification), status
|
|
| 组件间的联系 |
Labels, Selectors, Ports
|
1. minikube、kubectl介绍
在上一篇文章【k8s学习】Kubernetes学习——核心组件和架构中，介绍了两个节点类型：Master节点和Worker节点。
而在现实中，我们很难在本地机器上装一个Kubernetes集群（比如CPU或是内存的限制）。为此，诞生了开源项目：minikube。
minikube上安装了Master的4个组件（Api Server，Scheduler，Controller manager，etcd）以及Worker的3个组件（（container runtime，kubelet，kebe-proxy）），相当于把Master和Worker合并到一个Node上了，所以minikube只有一个节点。我们可以很好的利用minikube在本地做一些测试。
我们想要操作minikube，比如在节点上创建Pod、Service等，这时候就需要用到kubectl了。它是一个Kubernetes集群的命令行工具。
在上一篇文章中有讲到Master Node上的组件Api Server是Kubernetes集群的唯一入口，那么想要和Api Server进行交互的工具有很多，比如通过UI（Kubenetes Dashboard），或是API， 或是命令行工具，而这里的命令行工具就是kubectl。在这三个客户端工具中，kubectl是最强大的。
kubectl并不只是在minikube中使用，它也能管理Kubernetes集群。
2. minikube安装
minikube官网：https://minikube.sigs.k8s.io/docs/
minikube github地址：https://github.com/kubernetes/minikube
可以参考官网教程或是网上其它教程来安装minikube。
需要注意的是，minikube需要你的电脑支持virtualization技术。因为minikube是运行在virtual box（虚拟机）中的。这也是为什么在官网中会与：
Container or virtual machine manager, such as: Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox, or VMware Fusion/Workstation
另外，minikube的安装依赖kubectl，也就是说会把kubectl一并安装。
3. minikube运行
3.1 vm driver
启动minikube，这里的参数是告诉minikube我们需要哪个虚拟的driver，比如我们可以不用Docker，而是上述列表中的第二个Hyperkit（如果是MacOS，先用brew install hyperkit安装之），那么在启动的时候就可以告诉minikube，使用的是hyperkit的vm driver：
minikube start --vm-driver=hyperkit
minikube里面是预先安装了Container容器的runtime环境，所以并不需要预先安装Docker也可以。当然也可以安装Docker作为上述的vm driver用，这时候启动的时候就需要用minikube start --vm-driver=docker
更多关于不同系统（linux/macos/windows）的vm driver的选择：https://minikube.sigs.k8s.io/docs/drivers/
3.2 启动好后可以通过kubectl进行交互
比如查看节点的信息，可以看到minikube有什么Role：
kubectl get node
image.png
如果想要更详细的查看Node，可以使用kubectl describe命令，可以看到在namespace=kube-system下，有很多我们熟悉的组件：
kubectl describe node minikube
image.png
4. kubectl，一些常用的命令
4.1 查看资源：kubectl get <组件>
官网：https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get
我们在上述使用kubectl get node来查看node的信息。基本上，kubectl get能加任何的资源（比如pod、service、deployment等等）。
可以通过kubectl get -h来查看帮助文档，或者看官网文档。
4.2 创建组件：kubectl create <组件>
官网：https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#create
kubectl create命令，也是非常强大的，我们通过kubectl create -h查看帮助文档，可以看到通过这个命令可以创建以下组件：
kubectl create
但在这个list中没有Pod，原因是在实践中我们通常会使用Deployment去创建Pod，原因在上一篇博文讲的很清楚了。即开头第1章节引用的文章。
示例：
创建Deployment的命令格式，可以看到名称和镜像是必填的：
kubectl create deployment NAME --image=image -- [COMMAND] [args...]
比如创建nginx的Pod，Kubernetes会去docker hub中根据输入的image找到相应的镜像：
kubectl create deployment nginx-depl --image=nginx
kubectl create deployment
可以通过#4.1的kubectl get的命令查看deployment，可以看到READY了：
kubectl get deployment
我们都知道Deployment是用来更好的生成Pod和ReplicaSet用的，所以我们在Kubernetes创建了Deployment，相应的Pod和ReplicaSet也会创建（这是最终目的）：
- 会跟据name和image创建Pod，别的属性都默认，查看Pod的命令：
kubectl get pod，默认的Pod Name是刚刚输入的Deployment Name作为前缀 + ReplicaSet ID + 再加上一串随机数（即自己的ID)。 - 会创建ReplicaSet，查看命令也差不多：
kubectl get replicaset，默认会创建1个。一般情况下我们不会自己去创建、修改、删除ReplicaSet，都是通过Deployment进行操作，和Pod一样。
kubectl get pod
kubectl get replicaset
4.3 kubectl edit
kubectl edit deployment nginx-delp
通过这个命令，可以看到刚刚我们通过kubectl create出来的创建，这个yaml是Kubernetes自动生成出来的，除了必填项name和image之外，其它的都是默认值：
在实现生产中，我们更多的是自己编写yaml进行部署，而不是直接使用kubectl create这样的命令。
下面的kind就是定义这个资源文件的类型，可以是Pod，Deployment，Service等等。可以看下面的image中看到定义的nginx镜像。
另外可以看到属性replicas的个数是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改到具体的某一个版本，保存后，就会立马基于修改后的image生成新的ReplicaSet和Pod，老的Pod会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 <资源> <资源名称>，查看某个资源的详细信息，比如上述这个Pod：
kubectl describe pod nginx-depl-5ddc44dd46-xbq4b
部份截图：
image.png
4.4.3 进入到Pod容器内
exec = execute
-it = interact terminal
可以看到以root的身份进入了nginx的terminal中了：kubectl exec -it nginx-depl-5ddc44dd46-xbq4b -- /bin/bash
image.png
4.5 kubectl delete <资源> <资源名称>
比如我们可以通过命令kubectl delete deployment nginx-depl来删除上面建的Deployment，相应的Pod会自动跟着Terminate（终止）并删除，ReplicaSet也会跟着删除。
4.6 kubectl apply -f <fileName>
如同上述说的，我们一般不会直接使用kubectl create来创建组件，因为可能会有很多参数，以及重复利用原则，所以这里的fileName就是Kubernetes的配置yaml文件。可以用kubectl apply来run我们写的这个配置。
5. Kubernetes yaml配置文件
5.1 每个Kuberneted yaml配置文件一般包含三个部分：
metadata上面的两行是必须有的声明，apiVersion是这个yaml的版本声明，可能每个不同的kind种类，version会不一样。
kind就是想要定义的组件（或者叫资源）。
-
metadata：
image.png
-
specification：每个不同的kind的spec可能都会不太一样。
image.png
-
status：这块是Kubernetes自动加上的。对于status，可能会有两块，1块是期望的状态（Desired status），另一块是现在的真实状态（Actual status），如果两者出现了不一致，Kubernetes集群就会尝试去fix它。
比如kind=Deployment，定义的spec.replicas = 2，然后用kubectl apply这个配置，当status中的replicas = 1的时候，Kubernetes就会发现不一致了，于是就会尝试再启动一个Pod，以达到replica = 2的效果。
那么Kubernetes的配置中的当前的status信息从哪里来呢？在上一篇文章介绍过的，它是从Master节点的其中一个组件etcd中来的。
5.2 一些注意的点：
- 关于yaml文件，如果有一些格式上的错误，那么将会导致组件无法启动，所以我们可以预先使用一些validator online的网址，去验证yaml的格式，如：https://codebeautify.org/yaml-validator
- yaml文件存放位置：从实践上来说，可以和源代码放在一起或是单独放git repository。
5.3 Template：
示例是Deployment yaml配置：
image.png
5.4 Component间的相互联系
Deployment yaml中定义了Deployment的metadata，也定义了Pod的metadata，那么组件间相互联系的部分，靠的是：Labels，Selectors和Ports。
5.4.1 metadata中一般包含labels，spec中一般包含selector。
比如定义一个kind为Deployment的yaml配置，在metadata的labels中，一般就是key-value的形式。可以看到有labels为：app = nginx。
image.png
用matchLabels来匹配：
以下是Service的yaml配置，那么怎么把Deployment中的labels在Service中联系起来呢？用的是selector标签，可以看到selector下也是app = nginx。
image.png
5.4.2 Port
Service的spec中有ports的定义。
Development的template中定义的是Pod的信息，Pod的spec中定义了containers（因为container是在pod里面运行的，且理论上一个Pod可以运行多个container容器，所以这里的containers属性是放在Pod下面且是复数），可以看到container中也定义了ports。
Service中定义的port，是提供给外部应用来访问它的，targetPort则是寻找需要转发给哪个Pod（这里定义的是8080），container中定义了自己的port是8080，这样就match上了。即外部程序访问80到这个Service，Service再转发给端口为8080的Pod容器。
5.4.3 示例
我们把上述5.4.1中的两个yaml运行下：
image.png
可以看到Deployment, 以及它创建的ReplicaSet, Pod都正常运行了，Service也正常运行中：
image.png
查看Service的具体情况，可以看到Endpoint是两个Pod：
image.png
查看Pod更多的信息，可以看到上述Service中的两个Endpoint指向的IP就是我们创建的两个Pod：
image.png
5.4.4 通过配置文件删除刚刚创建的组件：
image.png
网友评论