RC 的一个痛点

如：

先确认，在上次示例后最后开启的端口是 3000，通过浏览器 172.16.156.128:3000 可以实现访问
使用之前创建的 rc-v2.yaml 进行滚动升级 kubectl rolling-update myweb2 -f k8s/rc/rc-v2.yaml --update-period=1s （rc-v2.yaml 中设置的是 app=myweb3 标签）
升级后再次尝试浏览器输入 172.16.156.128:3000，访问失败

这是因为我们 svc 配置文件中还是指定的标签为 app=myweb2 而升级后的服务标签不对应的缘故。我们接下来需要修改 svc 的配置文件后方可生效。（可通过 kubectl edit svc myweb 来修改）。改后再次访问，成功。

创建 Deployment 资源

# k8s/deploy/nginx-deploy.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx 
    spec:
      containers:
        - name: nginx 
          image: 172.16.156.128:5000/nginx:1.13
          ports:
            - containerPort: 80

删除之前创建的所有资源，并创建此 deployment 资源：

image.png

从截图中可以看到，启动 deployment 后，会启动一个 rs，然后有三个 pod。RS 拥有比 RC 90% 的功能且还有一些额外的功能，deployment 会先启动一个 RS 然后再启动对于的 Pod。但此时还不可以被外部访问，还需要创建 Service 资源才可以被外界访问。

创建 Service 资源除了用配置文件外，还可以用一个命令：

kubectl expose deployment nginx-deployment --port=80 --type=NodePort 
#

image.png

创建成功后，发现多了一个 svc/nginx-deployment 资源，并且对外暴露的端口是 21290 （随机的），可通过浏览器访问任意 Node 的此端口。成功。

Deployment 升级

kubectl edit deployment nginx-deployment

通过编辑 deployment 的配置文件，可以进行直接升级，如修改 nginx 版本为 1.15，保存之后马上生效。
通过 describe 命令可以看到具体 pod 中的版本信息已升级完成。
通过获取 pod 信息可以看到此时多了一个 RS 资源，并且旧的 RS 资源还保持存在，只是 DESIRED 等的数量发生了变化。他的逻辑就是吧之前的 RS 资源逐渐设置为 0，新的 RS 资源设置为 3。

image.png

Deployment 回滚

kubectl rollout undo deployment nginx-deployment

image.png

回滚之后可以发现旧的 RS 资源的个数变为 3，新的 RS 变为 0。

Deployment 更多命令

kubectl rollout history deployment nginx-deployment # 查看历史版本

image.png

kubectl run nginx --image=172.16.156.128:5000/nginx:1.15 --replicas=3 --record # 可以通过 run 直接将镜像跑起来
# 设置副本数目
# 设置记录

image.png

kubectl set image deploy nginx=172.16.156.128/nginx:1.13
# 通过命令方式改变 nginx 版本

image.png

kubectl rollout undo deployment nginx --to-revesion=1 # 按版本记录进行回滚

i

用 kubectl run nginx --image=172.16.156.128:5000/nginx:1.15 --replicas=3 --record 的方式运行起来的资源，通过查看其 label 是 run=nginx，所以需要创建一个 run=nginx 的 svc 资源，就可以对外访问。