- 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: v1
kind: Pod
metadata:
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 是最常用的那种。
为了不被前面的演示干扰，这里我将命名空间直接删掉，一整个空间删掉上面的东西自然也就没了。
创建 deploymentkubectl create deployment nginx --image=nginx:1.15.2
可以自行添加参数。
然后稍作等待，让子d飞一会儿。
使用配置文件创建，要怎么写呢？
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-CAUSE
1 <none>
2 kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true
3 kubectl set image deploy nginx nginx=nginx:xxx --record=true
# 回滚到上一个版本
[root@k8s-master01 ~]# kubectl rollout undo deploy nginx
deployment.apps/nginx rolled back
# 多次更新错误版本
[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:aa --record
deployment.apps/nginx image updated
[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:bb --record
deployment.apps/nginx image updated
[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:cc --record
deployment.apps/nginx image updated
# 查看kubectl更新的历史命令
[root@k8s-master01 ~]# kubectl rollout history deploy nginx
deployment.apps/nginx
REVISION CHANGE-CAUSE
1 <none>
3 kubectl set image deploy nginx nginx=nginx:xxx --record=true
4 kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true
5 kubectl set image deploy nginx nginx=nginx:aa --record=true
6 kubectl set image deploy nginx nginx=nginx:bb --record=true
7 kubectl set image deploy nginx nginx=nginx:cc --record=true
# 查看指定版本的详细信息 ---看revision对应的数字即可
[root@k8s-master01 ~]# kubectl rollout history deploy nginx --revision=4
deployment.apps/nginx with revision #4
Pod 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: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
# 回滚到指定版本
[root@k8s-master01 ~]# kubectl rollout undo deploy nginx --to-revision=4
deployment.apps/nginx rolled back
# Deployment的扩容与缩容，不会生成新的rs
[root@k8s-master01 ~]# kubectl scale --replicas=4 deploy nginx -n w
deployment.apps/nginx scaled
# --replicas # 指定副本数
# nginx # pod的名字
# 查看rs
[root@k8s-master01 ~]# kubectl get rs -n w
# Deployment的扩容与缩容，不会生成新的rs
[root@k8s-master01 ~]# kubectl scale --replicas=1 deploy nginx -n w
deployment.apps/nginx scaled
# --replicas # 指定副本数
# nginx # pod的名字
# 查看rs
[root@k8s-master01 ~]# kubectl get rs
- deployment可以在线edit更改（可以一次性更改多个）
- 也可以用kubectl set image更改（也可以一次性更改多个，但是需要使用到Deployment的暂停和恢复功能）
# 暂停
[root@k8s-master01 ~]# kubectl rollout pause deployment nginx -n w
deployment.apps/nginx paused
# 第一次更新
[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:1.15.4 --record
deployment.apps/nginx image updated
# 第二次更新、添加内存、CPU
[root@k8s-master01 ~]# kubectl set resources deploy nginx -c nginx --limits=cpu=200m,memory=128Mi --requests=cpu=10m,memory=16Mi
deployment.apps/nginx resource requirements updated
# 查看被更改以后的nginx镜像的deployment
[root@k8s-master01 ~]# kubectl get deploy nginx -o yaml
# 更新完想更新的内容后，然后恢复镜像
[root@k8s-master01 ~]# kubectl rollout resume deploy nginx -n w
deployment.apps/nginx resumed
# 查看rs，看到有新的
[root@k8s-master01 ~]# kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-5b6bc78b67 1 1 0 41s
.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:端口：
http://虚拟机IP + 映射本机端口
删除service就是那个命令嘛，不说了。
思考题
以配置文件形式部署 nginx svc。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）