k8s之deployment

之前service以及rc已经可以做到滚动升级并且服务发现、负载均衡等功能，为什么还需要deployment这个组件呢？

前面使用rc和service是通过selector进行关联的，但是在rc的滚动升级过程中selector是可能发生改变的，所以升级之后service与rc可能失去关联关系导致无法访问。

定义一个deployment：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: 192.168.56.201:5000/nginx:1.13
        ports:
        - containerPort: 80

 

 此时，deployment会创建一个rs，rs具有大部分rc的功能，但是还没有暴露端口出来还无法访问，可以通过以下指令暴露端口：

 

 可以看到通过创建svc暴露端口，即宿主机的55107端口，

 

 可以看到此时使用的镜像是NGINX1.13版本，如果要升级镜像版本，可以通过直接编辑deployment即可。

 

 再次访问就已经升级到了新的版本

 

 

---

通过观察我们可以发现他是通过rs来进行滚动升级，先创建了一个新的rs，rs创建了三个新的pod，但是对service没有任何影响

此时如果想要回滚，操作也很简单：

 

 可以看到NGINX又回到了之前的1.13版本

---

同时也可以使用history命令查看该deployment的升级历史信息，但是这里无法看到CAHNGE-CAUSE，这也是通过edit升级造成的弊端，所以也是不推荐的方式。

 

 想要保留历史版本的变更信息可以通过以下方式创建deployment。（其中关键就在最后的--record参数）

 

 这样就创建了一个以NGINX：1,13为镜像、副本数为3、名为NGINX的deployment。

 

这里就可以看到他的历史变更信息。同样的，进行升级后也可以查看到相应的变更记录。

 回滚也是一样：