接上一篇,上一篇的 pod 占的篇幅有点多,但是我感觉才讲了一点,pod 真要拿出来讲能讲好几节课。
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
和前一篇一样的风格,前面那块只是个开胃菜,这里才是重头戏!!!
在kubernetes中,Pod是最小的控制单元,但是kubernetes很少直接控制Pod,一般都是通过Pod控制器来完成的。Pod控制器用于pod的管理,确保pod资源符合预期的状态,当pod的资源出现故障时,会尝试进行重启或重建pod。
在kubernetes中Pod控制器的种类有很多,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的标签
kubectl set image deploy nginx nginx=nginx -n w --record
kubectl describe deploy/nginx -n w
回滚到上一个版本(一般都是回滚到上一个版本)
# 例如错误的更新到了一个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
# 暂停
[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
下篇吧。这个压轴的档次不亚于 deployment。 不信的小伙伴可以思考一个问题:我前边鼓捣了那么多,最终目的到底是什么?如果外界连不上 k8s 里面的东西,调动不了服务,那一切不都是扯淡吗?