上一次我们分享到，如何去升级一个 pod 的新的版本，相信在理论上，大家都知道可以如何做了，那么我们来进行实践一下，看看都会遇到哪些问题，以及操作起来是否便捷，感兴趣的可以一起来体验一波
本来是可以使用 rolling-update 的方式
使用 rolling-update 的方式，其实对于 k8s 来说已经是过时了的，但是我们还是要来了解和尝试一下rolling-update 的方式 ，在这里我们先说一下为啥他会被淘汰
因为使用 rolling-update 的方式其实是会直接修改我们创建出来的对象的，这回导致直接更新 pod 和 RS 的标签，这种做法还是不太好，而且现在最新的 k8s 也不支持了
对于先删除旧的，然后创建新的，这个方式比较简单，就是使用 RS 的扩容和缩容拉实现，之前的分享的事件案例中就有所涉及，我们可以再来温习一遍
我们可以使用这两种方式
- RS 扩缩容的方式
- deployment
RS 扩缩容的方式
创建必备基本环境
写一个应用程序，可以标识版本
app.js
const http = require('http');
const os = require('os');
console.log("xmt kubia server starting...");
var handler = function(request, response){
console.log("received request from " + request.connection.remoteAddress);
response.writeHead(200);
response.end("you've hit xmt web " + os.hostname() + "version is v1" "\n");
};
var www = http.createServer(handler);
www.listen(8080);
自己可以继续复用之前的一个小应用，简单的 http 请求，访问应用的 8080 端口后，应用会给客户端 pod 的 名字和 版本号 v1
做一个镜像
Dockerfile
FROM node:7
ADD app.js /app.js
ENTRYPOINT ["node", "app.js"]
我们将上述的小应用加入到 Dockerfile 中，直接运行即可
docker build -t xiaomotong888/newkubia:v1
docker push xiaomotong888/newkubia:v1
写 yaml ，创建 RS，Service，Pod
mynewkubia.yaml
apiVersion: v1
kind: Service
metadata:
name: newkubia-service
spec:
type: NodePort
selector:
app: newkubia
ports:
- port: 80
targetPort: 8080
---
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: newkubia-rs
spec:
replicas: 3
selector:
matchLabels:
app: newkubia
template:
metadata:
labels:
app: newkubia
spec:
containers:
- name: newkubia
image: xiaomotong888/newkubia:v1
ports:
- containerPort: 8080
创建一个 SVC 和 RS，可以放在同一个 yaml 文件中一起部署，我们只需要用 --- 隔开即可
使用 kubectl create -f mynewkubia.yaml 即可创建出 RS ，SVC 和 POD
此处的 SVC 本来是想模拟 LoadBalancer 的，但是我使用的是 minikube ，没有办法使用 LoadBalancer，不过我可以使用 NodePort 的类型
[图片上传失败...(image-b4c79d-1689816317728)]
我们可以进入任意一个 pod ，是用 curl 命令访问 服务的地址（svc），我们可以看到如下效果
[图片上传失败...(image-8e7b91-1689816317728)]
能够看到访问此时的服务打印出来的消息是 v1 版本的，没有毛病
开始创建一个新的 RS2，将流量切换到新的 Pod 中
这个时候，我们来创建另外一个 RS2，然后通过修改标签的方式，来将 Service 的流量切换到新的 pod 中
具体的 yaml 内容 和上述的 RS yaml 内容一致，我们只需要将对应的地方修改为 newkubia-rs-2 即可，不要和之前创建的 RS 冲突了，标签也要一起修改
kubectl create 对应的 yaml 文件之后 ，我们在进入到 对应的 SVC 修改 标签
[图片上传失败...(image-1f314c-1689816317728)]
这个时候我们再来查看一下流量是否真的会去切换到 pod v2 版本上
我们仍然可以使用同样的方式，找到任意一个 pod ，进入到容器，通过 curl 命令访问 svc 的地址，查看日志给我们输出的是什么效果
[图片上传失败...(image-3b83c5-1689816317728)]
通过查看效果响应的是 v2 版本的，我们可以知道，Service 的流量确实且到了新的 pod ， 对应这个请求的路径是这个样子的：
[图片上传失败...(image-6647fc-1689816317728)]
这个图，我们在分享 Service 的时候，也有体现。
今天就到这里，学习所得，若有偏差，还请斧正
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
[图片上传失败...(image-d27c15-1689816317728)]
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
网友评论