使用Minikube在本地部署单节点Kubernetes集群及操作

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/alinyua/article/details/82774357

本文使用最新版本的Minikube完成在本地部署单节点Kubernetes集群,并以nginx集群为例,展示使用kubectl完成对集群的扩展,收缩,滚动升级以及回滚操作等.

安装方法参照 最后 ,因为我本来就安装了Docker,所以没有再去安装一个Hypervisor(如VirtualBox和KVM),不过得注意启动Minikube的时候要指定 –vm-driver=none ,另外,由于国内网络环境问题,kubectl和Minikube的下载可能不是很顺利

安装完后运行如下指令启动Minikube

minikube start --vm-driver=none

一 查看初始集群信息

使用 kubectl get -h可以看到更多关于kubectl get的用法,下面列举宏观查看用得比较多的指令

  1. 查看node信息: kubectl get nodes
  2. 查看services信息: kubectl get services
  3. 查看deployment信息: kubectl get deployments
  4. 查看pod信息: kubectl get pods

示例如下
因为是本地运行minikube,所以只会有一个主节点,这个以后也不会改变,默认会有一个名为kubernetes的服务,注意其类型是 ClusterIP ,只能从集群内部访问,且其访问端口为443,而真正的部署和pod(类似于容器)现在都还是空的.
初始状态

二 使用yaml文件部署nginx集群及服务

注意,这里我是使用配置文件声明管理Kubernetes对象,特征就是创建和更新对象都是使用kubectl apply -f <directory>/风格的命令,关于 使用命令式命令管理Kubernetes对象和使用配置文件管理Kubernetes对象以及三者间的区别可以看:https://kubernetes.io/docs/concepts/overview/object-management-kubectl/overview/
yaml的配置参考Kubernetes的Api文档:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11

1 使用deployment创建nginx集群

此处参考自 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ ,
创建nginx-deployment.yaml文件如下:
该deployment目标状态是有3个由selector选择出的副本应用,如果不足3个则根据template去创建

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

使用如下指令创建deployment

kubectl apply -f nginx-deployment.yaml --record

注意: –record可以将执行对资源(此处是deployment)的创建或更新操作的命令记录下来,方便以后审查

示例如下:
可以看到名为nginx-deployment的deployment管理着3个pod,另外,用kubectl rollout history deployment指令查看可以看到revision为1的记录的change-cause是刚执行的命令
部署

另外,还可以使用kubectl rollout status deployment指令来查看deployment的上线状态,使用kubectl describe deployment指令来查看deployment的详细状态

示例如下:
通过describe可以看到deployment的完整参数,包括一些我们没有设定的也给了默认值,如StrategyType默认是RollingUpdate,RollingUpdateStrategy默认是25% max unavailable, 25% max surge
describe deployment

2 使用service创建nginx服务

此处参考自: https://kubernetes.io/docs/concepts/services-networking/service/

创建nginx-service.yaml文件如下:
该service的类型时NodePort,更值得推荐的类型是负载均衡器 LoadBalance,但是Minikube无法使用该类型,而默认类型ClusterIP不对外开放,这里不予考虑,**Ingress **较复杂,且不属于service,这里不讨论

另外需要注意一下port,targetPort和nodePort的区别

port : 表示service暴露在cluster ip 上的端口,集群内部用户可以通过<cluster ip>:port访问该service
targetPort: 目标端口,即pod上的端口,service接收到的数据会经由kube-proxy流入后端pod的targetPort端口进入容器,故该端口应与pod的containerPort对应.
nodePort: 表示service暴露在node ip上的端口,集群外部的用户可以通过<node ip>:nodePort访问该service

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30009
  externalIPs:
    - 公网IP

使用如下指令创建service

kubectl apply -f nginx-service.yaml --record

示例如下
可以看到已经多了一个名为 nginx-service 的service
service

这个时候访问 <external-ip>:nodePort 即可打开访问nginx的默认首页
nginx
再通过kubectl describe service来查看其详情
可以看到 Endpoints那里对应的分别是三个pod的集群ip+targetPort
describe service
这个时候可以进入其中一个docker容器,修改其默认index的内容,用不同的浏览器打开<external-ip>:nodePort,就可以看到显示的结果不同.(如果用同一个浏览器一直刷新好像不会换pod)

三 使用 kubectl 测试集群操作

1 pod扩展和收缩

扩展和收缩本质是都是pod数量的改变,常用命令行动态调节,需注意用命令行调节后用 kubectl rollout history查看会发现 pod数量修改不影响REVISION,但相应的命令即使没有加**–record也会更新到 REVISIONCHANGE-CAUSE下(这可能是部署REVISION=1**的时候已经用了 –record了)

其操作主要有两种类型

1. 指定数量扩展

kubectl scale deployment nginx-deployment --replicas=10

2. 水平pod自动缩放

以下实现根据CPU利用率在最小值和最大值之间选择要运行的Pod数量

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

2 部署滚动更新和回滚

  1. revision1:现在部署的nginx版本是 1.7.9
  2. revision2: 接下来将演示将利用命令行将nginx更新到1.119 (不存在这个版本的镜像故会拉取错误)
  3. revision3: 然后马上回滚到上一版本
  4. revision4: 重新使用命令行将nginx更新到1.11.9
  5. revision5: 再使用nginx-deployment.yaml文件将nginx更新回1.7.9(注意,这里仍是更新,只是因为nginx-deployment.yaml文件的内容和第一次部署一样没有改变而已)
  6. revision6: 然后再将部署回滚到第4次部署的nginx 1.11.9 的版本

1. 利用命令行更新部署

kubectl set image deploy/nginx-deployment nginx=nginx:1.119 --record

查看pods可以看到镜像拉取错误
镜像拉取错误

2. 回滚到上一版本

kubectl rollout undo deployment/nginx-deployment

查看记录,发现REVISION3那里的CHANGE-CAUSE对应的不是回滚指令而是REVISION1的命令
history

3. 重新使用命令行更新

kubectl set image deploy/nginx-deployment nginx=nginx:1.11.9 --record

4. 使用文件更新

kubectl apply -f nginx-deployment.yaml --record

可以看到REVISION1和3的记录都没有显示出来,应该是因为和REVISION5重复了,没有显示的意义
history

5. 指定版本回滚

kubectl rollout undo deployment/nginx-deployment --to-revision=4

四 其他

1 官方资料

Minikube使用指南: https://kubernetes.io/docs/setup/minikube
Minikube安装指南: https://kubernetes.io/docs/tasks/tools/install-minikube/
Deployment概念说明和简单用例: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
Services概念说明: https://kubernetes.io/docs/concepts/services-networking/service/
Kubernetes官方API文档地址: https://kubernetes.io/docs/reference/#api-reference
最新文档对service的说明: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#service-v1-core

2 国内安装kubectl

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md 选择最新版本的更新日志,找到合适的版本(如v1.11.3的 kubernetes-client-linux-amd64.tar.gz )下载
下载后解压

 tar -zxvf kubernetes-client-linux-amd64.tar.gz

然后赋予执行权限并移到执行目录

chmod +x kubernetes/client/bin/kubectl && sudo mv kubernetes/client/bin/kubectl /usr/local/bin/kubectl

然后就可以查看版本信息了

kubectl version

3 国内安装minikube

https://github.com/kubernetes/minikube/releases 的 最新版本下的Assets选择合适的版本下载,如 minikube-linux-amd64
首先要修改文件名

mv minikube-linux-amd64 minikube

然后赋予执行权限并移到执行目录(其实第一步可以简化掉)

chmod +x minikube && sudo mv minikube /usr/local/bin/minikube

最后测试输出版本信息

minikube version

猜你喜欢

转载自blog.csdn.net/alinyua/article/details/82774357