演示登录

Deployment: 声明式地升级应用

使用Deployment资源升级pod

现在我们要考虑pod升级的情况了，如v1升级到v2和回滚等操作，这个场景需要改动下我们的服务。返回值里标记版本信息。

// cat app.js
const http = require('http');
const os = require('os');

console.log("Kubia server starting...");

var handler = function(request, response) {
  console.log("Received request from " + request.connection.remoteAddress);
  response.writeHead(200);
  response.end("This is v1 running in pod " + os.hostname() + "\n");
};

var www = http.createServer(handler);
www.listen(8080);

不同的版本服务已经做好了，可以直接部署使用，我们体验一下。

# cat kubia-deployment-v1.yaml
apiVersion: apps/v1
kind: Deployment   # 我们这里引入了Deployment
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
     app: kubia
  template:
    metadata:
      name: kubia
      labels:
        app: kubia
    spec:
      containers:
      - image: luksa/kubia:v1
        name: nodejs

观察下，Deployment自动帮我们创建了rs/pod这些。

Deployment 是我们常用的发版方式，且--record记录发版历史，这样我们能够回滚很便利

好像deployment没带来什么好处，下面看看升级、回滚

执行滚动升级

为了演示v1升级v2过程，我们做一下服务监控工作。这次连通服务service一起创建出来。

服务部署好后，因为有负载均衡器地址，可以访问到服务

还记得获取LB的地址么，使用k get svc试试

如果LB申请不下来，可以使用busybox内网测试，见：

执行升级操作，这里是将deployment中的image由v1改为了v2

我们观察到curl返回结果由全部是v1，开始陆续出现了v2，直至全都是v2

这样升级就完成了，一个指令就陆续的完成了部署，是不是很简单呢！

回滚pod到上个版本

我们准备了一个有错误的版本v3，它不能正常工作，在从v2到v3升级时看看发生什么

能看到错误的版本出现了

此时我们做一下回滚操作

然后看到服务回滚到v2了，恢复正常

做到这里是不是觉得升级与回滚都特别便利了呢？我们看看它是怎么做到的

还记得--record参数么，它帮我们记录了发版历史，从replicaset能看出来已经有了三个版本，所以在回滚时，它能知道我们回滚到哪个历史版本

deployment能够控制升级速度、出错暂停升级、回滚到指定版本等等，非常强大，大家可以多做做练习

我们回滚到最初的版本v1玩一下

回到版本v1了

So！Deployment是管理发版的利器。做完这里，你已经完成了绝大部分的容器管理内容了！

最后，在做下一节前，注意清理资源

思考题

  • 记录发版历史有个重要参数，是什么？怎么从v2回滚到v1版本呢？

上一页ConfigMap和Secret：配置应用程序下一页StatefulSet：部署有状态的多副本应用

最后更新于

这有帮助吗？