Kubernetes学习目录
1、基础知识
1.1、简介
Deployment资源对象在内部使用Replica Set来实现Pod的自动化编排。Deployment资源对象不管是在
作用、文件定义格式、具体操作等方面都可以看做RC的一次升级,两者的相似度达90%。
相对于RC的一个最大的升级是:
我们可以随时知道当前Pod的"部署"进度,即Pod创建--调度--绑定Node--在目标Node上启动容器。
1.2、使用场景
Deployment的使用场景非常多,一句话:只要是涉及到Pod资源对象的自动化管理,都是他的场景,
创建Deployment资源对象,生成对应的Replicas Set并完成Pod的自动管理
检查Deployment对象状态,检查Pod自动管理效果
扩展Deployment资源对象,以应对应用业务的高可用
...
1.3、资源定义
Deployment的定义与Replica Set的定义类似,除了API声明与Kind类型有所区别,其他基本上都一样。

1.4、资源清单属性介绍
apiVersion: apps/v1 # API群组及版本
kind: Deployment # 资源类型特有标识
metadata:
name <string> # 资源名称,在作用域中要唯一
namespace <string> # 名称空间;Deployment隶属名称空间级别
spec:
minReadySeconds <integer> # Pod就绪后多少秒内任一容器无crash方可视为“就绪”
replicas <integer> # 期望的Pod副本数,默认为1
selector <object> # 标签选择器,必须匹配template字段中Pod模板中的标签
template <object> # Pod模板对象
revisionHistoryLimit <integer> # 滚动更新历史记录数量,默认为10
strategy <Object> # 滚动更新策略
type <string> # 滚动更新类型,可用值有Recreate和RollingUpdate;
rollingUpdate <Object> # 滚动更新参数,专用于RollingUpdate类型
maxSurge <string> # 更新期间可比期望的Pod数量多出的数量或比例;
maxUnavailable <string> # 更新期间可比期望的Pod数量缺少的数量或比例,10,
progressDeadlineSeconds <integer> # 滚动更新故障超时时长,默认为600秒
paused <boolean> # 是否暂停部署过程
1.5、部署相关的资源对象关系图

2、Deployment-简单实践
2.1、命令行创建对象
master1 ]# kubectl create deployment pod-test --image=192.168.10.33:80/k8s/pod_test:v0.1 --replicas=3
deployment.apps/pod-test created
master1 ]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
pod-test 3/3 3 3 4s
2.2、资源定义文件创建对象
cat >dp-test.yml<<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-test
spec:
replicas: 3
selector:
matchLabels:
app: rs-test
template:
metadata:
labels:
app: rs-test
spec:
containers:
- name: nginxpod-test
image: 192.168.10.33:80/k8s/pod_test:v0.1
EOF
master1 ]# kubectl apply -f dp-test.yml
deployment.apps/deployment-test created
master1 ]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
deployment-test 3/3 3 3 9s
2.3、检查关系
2.3.1、获取deployment对象信息
master1 ~]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
deployment-test 3/3 3 3 2m16s
2.3.2、获取Replica Set对象信息
# 这里说明 rs 包含 deployment
master1 ~]# kubectl get rs
NAME DESIRED CURRENT READY AGE
deployment-test-8458f7546d 3 3 3 2m44s
2.3.3、查看 deployment的详细过程
master1 ~]# kubectl describe deployments.apps deployment-test
2.4、deployment、rs、pod之间的关系
2.4.1、关系图

2.4.2、pod名字组成解析
]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
pod-test 3/3 3 3 38s
]# kubectl get rs
NAME DESIRED CURRENT READY AGE
pod-test-6f594c84b5 3 3 3 32s
]# kubectl get rs
NAME DESIRED CURRENT READY AGE
pod-test-6f594c84b5 3 3 3 42s
[root@master1 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod-test-6f594c84b5-lc7hg 1/1 Running 0 46s
pod-test-6f594c84b5-ptq5w 1/1 Running 0 46s
pod-test-6f594c84b5-tfwhm 1/1 Running 0 46s
总结:
pod的名称是使用deployment name + rs name +随机字符组成。
3、Deployment-实践
3.1、扩容缩容
3.1.1、基本语法
基于deployment调整Pod有两种方法:
基于资源对象调整:
kubectl scale <--current-replicas=3> --replicas=5
-------
deployment/deploy_name
基于资源文件调整:
kubectl scale --replicas=4 -f deploy_name.yaml
3.1.2、基于资源对象-扩容
master1 ~]# kubectl scale --current-replicas=3 --replicas=5 deployment deployment-test
master1 ~]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
deployment-test 5/5 5 5 11m
3.1.3、基于资源对象-缩容
master1 ~]# kubectl scale --replicas=3 deployment/deployment-test
master1 ~]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
deployment-test 3/3 3 3 11m
3.1.4、基于资源文件-扩容
master1 ]# kubectl scale --replicas=5 -f dp-test.yml
master1 ]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
deployment-test 5/5 5 5 13m
3.1.5、基于资源文件-缩容
master1 ]# kubectl scale --replicas=3 -f dp-test.yml
deployment.apps/deployment-test scaled
master1 ]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
deployment-test 3/3 3 3 13m
3.2、deployment动态更新
3.2.1、命令简介
更新命令1:
kubectl set SUBCOMMAND [options] 资源类型 资源名称
子命令:常用的子命令就是image
参数详解:
--record=true 更改的时候,将信息增加到历史记录中
更新命令2:
kubectl patch (-f FILENAME | TYPE NAME) -p PATCH [options]
参数详解:
--patch='' 设定对象属性内容
回滚命令: kubectl rollout SUBCOMMAND [options] 资源类型 资源名称
子命令:
history 显示 rollout 历史
pause 标记提供的 resource 为中止状态,而pause目前仅仅支持 deployment对象
resume 继续一个停止的 resource
status 显示 rollout 的状态
undo 撤销上一次的 rollout
3.2.2、动态更新实践
# 更新版本v0.1
kubectl set image deployment/deployment-test nginxpod-test='192.168.10.33:80/k8s/pod_test:v0.1'
# 更新版本v0.2
kubectl set image deployment/deployment-test nginxpod-test='192.168.10.33:80/k8s/pod_test:v0.2'
-----------------
# 查看更新版本的历史记录
master1 ~]# kubectl rollout history deployment deployment-test
deployment.apps/deployment-test
REVISION CHANGE-CAUSE
1 kubectl set image deployment/deployment-test nginxpodtest=192.168.10.33:80/k8s/pod_test:v0.1 --record=true
2 kubectl set image deployment/deployment-test nginxpodtest=192.168.10.33:80/k8s/pod_test:v0.1 --record=true
# 查看更新的状态
master1 ~]# kubectl rollout status deployment deployment-test
# 撤销更改
master1 ~]# kubectl rollout undo deployment deployment-test
# 设置更改1个后,就暂停
master1 ~]# kubectl set image deployment/deployment-test nginxpod-test='192.168.10.33:80/k8s/pod_test:v0.2' && kubectl rollout pause deployment deployment-test
master1 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
deployment-test-8458f7546d-kgs2v 1/1 Running 0 2m45s
deployment-test-8458f7546d-nh927 1/1 Running 0 2m43s
deployment-test-8458f7546d-w5tv6 1/1 Running 0 2m43s
deployment-test-dc45fccbf-4snsf 1/1 Running 0 9s
# 继续更新
master1 ~]# kubectl rollout resume deployment deployment-test
# 回到版本3
master1 ~]# kubectl rollout undo --to-revision=3 deployment deployment-test
# 修改副本数量
kubectl patch deployments.apps deployment-test -p '{"spec":{"replicas":2}}'
# 修改期望数据
master1 ~]# kubectl patch deployments.apps deployment-test -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}'
3.3、滚动更新
3.3.1、基础知识
对于应用的动态扩展来说,还有一种叫滚动更新,其实我们刚才rollout的效果就是一种特殊的滚动更新,只不过是一个一个的变动,而真正的滚动更新远远要比默认的效果灵活.
3.3.2、属性解析
# 帮忙查询
kubectl explain deployment.spec.strategy
# yaml解析
rollingUpdate <Object>
maxSurge <string> # 更新时候,容量允许扩大的值
maxUnavailable <string> # 多少个pod不能用时候,再来更新
type <string> 主要有两种类型:"Recreate"、"RollingUpdate-默认"
# 帮忙查询
kubectl explain deployment.spec.strategy
# yaml解析
rollingUpdate <Object>
maxSurge <string> # 更新时候,容量允许扩大的值
maxUnavailable <string> # 多少个pod不能用时候,再来更新
type <string> 主要有两种类型:"Recreate"、"RollingUpdate-默认"
minReadySeconds # Kubernetes在等待设置的时间后才进行升级,如果没有设置该值,Kubernetes会假设该容器启动起来后就提供服务了,如果没有设置该值,在某些极端情况下可能会造成服务不正常运行
maxSurge # 升级过程中最多可以比原先设置多出的POD数量,默认是25% 例如:maxSurage=1,replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD,整个升级过程中最多会有5+1个POD。
maxUnavaible # 升级过程中最多有多少个POD处于无法提供服务的状态,默认是25% 当maxSurge不为0时,该值也不能为0 例如:maxUnavaible=1,则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态。
3.3.3、基本样式
基本属性样式:
minReadySeconds: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
3.3.4、滚动更新-实践
cat > rolling-update.yml<<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
name: rolling-update
spec:
replicas: 3
selector:
matchLabels:
app: nginxpod-test
template:
metadata:
labels:
app: nginxpod-test
spec:
containers:
- name: pod-roll
image: 192.168.10.33:80/k8s/pod_test:v0.1
minReadySeconds: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 2
EOF
属性解析:
minReadySeconds: 5 表示我们在更新的时候,需要先等待5秒,而不是一旦发生变化就滚动更新
maxSurge: 2 表示我们在更新的时候,可以先增加两个新的,然后再删除多出来的两个旧的
maxUnavailable: 2 表示当我们的资源数量有两个故障的时候,自动进行增加
master1 ]# kubectl apply -f rolling-update.yml
master1 ]# kubectl rollout status deployment rolling-update
master1 ]# kubectl set image deployment/rolling-update pod-roll='192.168.10.33:80/k8s/pod_test:v0.2'
master1 ]# kubectl rollout status deployment rolling-update
Waiting for deployment "rolling-update" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "rolling-update" rollout to finish: 1 old replicas are pending termination...
master1 ]# kubectl get pod -w
3.3.5、问题
更新后的pod是否还是在原来的node结点上呢?
原生的kubernetes是没有这个功能,需要你根据实际的调度策略来做,或者找相关的云平台来实现。