接下来结合我们的k8s进行对我们的微服务项目进行演示
启动副本本身是无状态的应用,无需考虑服务是否带来的影响
扩容根据副本本身的模版再去创建新的副本
replicas是整个副本的数量,而不是在原基础的副本增加3
[root@k8s-master k8s]# kubectl scale --replicas=3 deployment stock -n ms
deployment.extensions/stock scaled
[root@k8s-master k8s]# kubectl get pod -n ms
NAME READY STATUS RESTARTS AGE
eureka-0 1/1 Running 0 21m
eureka-1 1/1 Running 0 19m
eureka-2 1/1 Running 0 18m
gateway 1/1 Running 0 16m
gateway 1/1 Running 0 16m
order 1/1 Running 0 11m
portal 1/1 Running 0 9m31s
product 1/1 Running 0 11m
stock 1/1 Running 0 6s
stock 1/1 Running 0 11m
stock 1/1 Running 0 6s
新功能上线模拟
在product这个模块下,这里-dev.yml是本地的一个测试环境,修改某个功能比如,那么我们就需要重新构建一下jar包,比如修复bug或者添加代码,我们就得重新构建镜像,但是在k8s中我们只需要对某个模块进行构建就可以了,无需再全部构建,进入分支选择改动的模块,k8s用新的镜像
[root@k8s-master simple-microservice-dev3]# vim product-service/product-service-biz/src/main/resources/application-dev.yml
开发把代码更新完之后,提交到git、gitlab仓库,我们就需要git clone 拉取目标项目代码到本地
然后构建
[root@k8s-master simple-microservice-dev3]# cd product-service/
[root@k8s-master product-service]# ls
pom.xml product-service-api product-service-biz
[root@k8s-master product-service]# mvn clean package -D maven.test.skip=true
为什么可以在这个目录下也可以执行?
[root@k8s-master product-service]# ls
pom.xml product-service-api product-service-biz
因为这里有这个pom.xml,描述了所需的依赖包,都在这里面定义的
然后推送到我们的k8s中,执行这个脚本,将会替换我们新的模块,把新功能推送上去
微服务的新功能发布也不会影响前端等其他模块的使用
[root@k8s-master k8s]# ./docker_build.sh product-service
[root@k8s-master k8s]# kubectl get pod -n ms
NAME READY STATUS RESTARTS AGE
eureka-0 1/1 Running 0 70m
eureka-1 1/1 Running 3 69m
eureka-2 1/1 Running 3 68m
gateway 1/1 Running 0 65m
gateway 1/1 Running 0 65m
order 1/1 Running 0 60m
portal 1/1 Running 0 58m
product 1/1 Running 0 115s
stock 1/1 Running 0 61m
原文:https://blog.51cto.com/14143894/2430372