k8s 实践经验（四）：实操中学 k8s 五种资源（2）deployment

k8s 实践经验（四）：实操中学 k8s 五种资源（2）deployment

文章目录

​​Label 标签​​

​​打标签​​​​标签筛选​​​​删除标签​​​​通过配置文件配置​​

​​deployment​​

​​创建 deployment​​​​状态解析​​

​​Deployment的更新​​

​​更改deployment的镜像并记录​​​​查看更新过程​​

​​Deployment的回滚​​

​​4.2、回滚到指定版本（较少，但是得掌握）​​

​​Deployment的扩容与缩容​​

​​Deployment的扩容​​​​Deployment的缩容​​

​​Deployment的暂停和恢复​​

​​Deployment 暂停功能​​​​Deployment 恢复功能​​

​​Deployment注意事项​​​​新的风暴已经出现​​​​service 简介​​

​​创建集群内部访问 service​​​​创建集群外部访问 service​​

​​思考题​​

接上一篇，上一篇的 pod 占的篇幅有点多，但是我感觉才讲了一点，pod 真要拿出来讲能讲好几节课。

Label 标签

Label是kubernetes的一个重要概念。它的作用就是在资源上添加标识，用来对它们进行区分和选择。

● Label的特点：

○ 一个Label会以key/value键值对的形式附加到各种对象上，如Node、Pod、Service等。

○ 一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。

○ Label通常在资源对象定义时确定，当然也可以在对象创建后动态的添加或删除。

这个 key/value，公司应该会有自己的规范，我们自己玩的时候高兴取什么名字就取什么名字，只要你自己不迷糊就行。

打标签

让我们给这个 nginx pod 打上一个标签：

kubectl label pod nginx2-59c95fc67d-sbdx5 version=1.0 -n dev

再给它打一个：

kubectl label pod nginx2-59c95fc67d-sbdx5 author=wlf -n dev

如果要更新标签：

kubectl label pod nginx2-59c95fc67d-sbdx5 version=2.0 -n dev --overwrite

记得要加上覆盖标志。不加也行，系统会提示的。

查看标签：

kubectl get pod nginx2-59c95fc67d-sbdx5 -n dev --show-labels

标签筛选

通过 key/value 方式：

kubectl get pod -l key=value [-n 命名空间] --show-labels

还有其他方式，这里不多说。

删除标签

kubectl label pod xxx key- [-n 命名空间]

通过配置文件配置

apiVersion: v1kind: Podmetadata: name: nginx namespace: dev labels: version: "3.0" env: "test" spec: containers: - image: nginx:1.17.1 imagePullPolicy: IfNotPresent name: pod ports: - name: nginx-port containerPort: 80 protocol: TCP

deployment

和前一篇一样的风格，前面那块只是个开胃菜，这里才是重头戏！！！

在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Pod控制器用于pod的管理，确保pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建pod。

在kubernetes中Pod控制器的种类有很多，Deployment 是最常用的那种。

为了不被前面的演示干扰，这里我将命名空间直接删掉，一整个空间删掉上面的东西自然也就没了。

创建 deployment

kubectl create deployment nginx --image=nginx:1.15.2

可以自行添加参数。

然后稍作等待，让子弹飞一会儿。

使用配置文件创建，要怎么写呢？

kubectl get deployment nginx -n w -o yaml > nginx-deploy.yaml

拿到这个 nginx-deploy.yaml 之后，我们是不是就可以为所欲为啦！！！

（所以说我到现在还不会自己写 deploy.yaml，是有原因的。。。）

状态解析

kubectl get deploy -n w -o wide

 NAME： Deployment名称 READY：Pod的状态，已经Ready的个数 UP-TO-DATE：已经达到期望状态的被更新的副本数 AVAILABLE：已经可以用的副本数 AGE：显示应用程序运行的时间 CONTAINERS：容器名称 IMAGES：容器的镜像 SELECTOR：管理的Pod的标签

Deployment的更新

更改deployment的镜像并记录

kubectl set image deploy nginx nginx=nginx -n w --record

查看更新过程

kubectl describe deploy/nginx -n w

Deployment的回滚

回滚到上一个版本（一般都是回滚到上一个版本）

# 例如错误的更新到了一个xxx版本[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:xxx --record deployment.apps/nginx image updated# 查看kubectl更新的历史命令[root@k8s-master01 ~]# kubectl rollout history deploy nginx deployment.apps/nginx REVISION CHANGE-CAUSE1 2 kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true3 kubectl set image deploy nginx nginx=nginx:xxx --record=true# 回滚到上一个版本[root@k8s-master01 ~]# kubectl rollout undo deploy nginxdeployment.apps/nginx rolled back

4.2、回滚到指定版本（较少，但是得掌握）

# 多次更新错误版本[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:aa --recorddeployment.apps/nginx image updated[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:bb --recorddeployment.apps/nginx image updated[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:cc --recorddeployment.apps/nginx image updated# 查看kubectl更新的历史命令[root@k8s-master01 ~]# kubectl rollout history deploy nginx deployment.apps/nginx REVISION CHANGE-CAUSE1 3 kubectl set image deploy nginx nginx=nginx:xxx --record=true4 kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true5 kubectl set image deploy nginx nginx=nginx:aa --record=true6 kubectl set image deploy nginx nginx=nginx:bb --record=true7 kubectl set image deploy nginx nginx=nginx:cc --record=true# 查看指定版本的详细信息 ---看revision对应的数字即可[root@k8s-master01 ~]# kubectl rollout history deploy nginx --revision=4deployment.apps/nginx with revision #4Pod Template: Labels: app=nginx pod-template-hash=5dfc8689c6 Annotations: kubernetes.io/change-cause: kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true Containers: nginx: Image: nginx:1.15.3 Port: Host Port: Environment: Mounts: Volumes: # 回滚到指定版本[root@k8s-master01 ~]# kubectl rollout undo deploy nginx --to-revision=4deployment.apps/nginx rolled back

Deployment的扩容与缩容

Deployment的扩容

# Deployment的扩容与缩容，不会生成新的rs[root@k8s-master01 ~]# kubectl scale --replicas=4 deploy nginx -n wdeployment.apps/nginx scaled# --replicas # 指定副本数# nginx # pod的名字# 查看rs[root@k8s-master01 ~]# kubectl get rs -n w

Deployment的缩容

# Deployment的扩容与缩容，不会生成新的rs[root@k8s-master01 ~]# kubectl scale --replicas=1 deploy nginx -n wdeployment.apps/nginx scaled# --replicas # 指定副本数# nginx # pod的名字# 查看rs[root@k8s-master01 ~]# kubectl get rs

Deployment的暂停和恢复

deployment可以在线edit更改（可以一次性更改多个）也可以用kubectl set image更改（也可以一次性更改多个，但是需要使用到Deployment的暂停和恢复功能）

Deployment 暂停功能

# 暂停[root@k8s-master01 ~]# kubectl rollout pause deployment nginx -n wdeployment.apps/nginx paused# 第一次更新[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:1.15.4 --recorddeployment.apps/nginx image updated# 第二次更新、添加内存、CPU[root@k8s-master01 ~]# kubectl set resources deploy nginx -c nginx --limits=cpu=200m,memory=128Mi --requests=cpu=10m,memory=16Mideployment.apps/nginx resource requirements updated# 查看被更改以后的nginx镜像的deployment[root@k8s-master01 ~]# kubectl get deploy nginx -o yaml

Deployment 恢复功能

# 更新完想更新的内容后，然后恢复镜像[root@k8s-master01 ~]# kubectl rollout resume deploy nginx -n wdeployment.apps/nginx resumed# 查看rs，看到有新的[root@k8s-master01 ~]# kubectl get rsNAME DESIRED CURRENT READY AGEnginx-5b6bc78b67 1 1 0 41s

Deployment注意事项

.spec.revisionHistoryLimit：设置保留RS旧的revision的个数，设置为0的话，不保留历史数据.spec.minReadySeconds：可选参数，指定新创建的Pod在没有任何容器崩溃的情况下视为Ready最小的秒数，默认为0，即一旦被创建就视为可用。滚动更新的策略： .spec.strategy.type：更新deployment的方式，默认是RollingUpdate RollingUpdate：滚动更新，可以指定maxSurge和maxUnavailable maxUnavailable：指定在回滚或更新时最大不可用的Pod的数量，可选字段，默认25%，可以设置成数字或百分比，如果该值为0，那么maxSurge就不能0 maxSurge：可以超过期望值的最大Pod数，可选字段，默认为25%，可以设置成数字或百分比，如果该值为0，那么maxUnavailable不能为0 Recreate：重建，先删除旧的Pod，在创建新的Pod

新的风暴已经出现

走到这一步，我们已经能够在 k8s 上起一些服务了，虽然演示是用 nginx，对吧。

那接下来我来删掉一个 nginx-pod，理论上是删不掉的，因为我一删，deployment 就会马上启动一个新的顶上去，正所谓旧的不去新的不来。

有没有什么不对劲？IP 不一样了。这问题也就大了，不然为什么那些 HA 架构要配置 VIP 呢？

再看，我现在在集群内部访问和集群外部访问的情况是否还是一致：

是吧，本来以为第一个 IP 漂移的问题就已经挺严重的了，再看第二个问题，那根本就没给咱机会去漂移嘛。。。

service 简介

Service可以看做是一组同类的Pod对外的访问接口，借助Service，应用可以方便的实现服务发现和负载均衡。

Kubernetes Service 从逻辑上代表了一组 Pod，具体是哪些 Pod 则是由 label 来挑选。Service 有自己 IP，而且这个 IP 是不变的。客户端只需要访问 Service 的 IP，Kubernetes 则负责建立和维护 Service 与 Pod 的映射关系。无论后端 Pod 如何变化，对客户端不会有任何影响，因为 Service 没有变。

创建集群内部访问 service

kubectl expose deployment xxx --name=服务名 --type=ClusterIP --port=暴露的端口 --target-port=指向集群中的Pod的端口 [-n 命名空间]# 会产生一个CLUSTER-IP，这个就是service的IP，在Service的生命周期内，这个地址是不会变化的

expose deployment nginx --name=svc-nginx1 --type=ClusterIP --port=80 --target-port=80 -n w

可以看到这里 service 是借助于 deployment 来暴露IP:端口的，为什么这样设计呢？因为如果是借助于 Pod 来暴露 IP:端口的时候，Pod 挂了也就挂了啊。。。

其实真正转发的时候只需要用 label 就行了，用不到这个 deployment。

查看 service：

kubectl get service -n w

目前这个集群还是只能在集群内部访问的。

创建集群外部访问 service

只需要把上面命令中的 type 指定为 NodePort 即可。

访问IP:端口：

+ 映射本机端口

删除service就是那个命令嘛，不说了。

思考题

以配置文件形式部署 nginx svc。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。