蓝绿发布 | 把应用服务集群标记位两个组,蓝组和绿组,先升级蓝组,先要把蓝组从负载均衡当中移除,绿组继续提供服务,蓝组升级完毕,再把绿组从负载均衡当中移除,绿组升级,然后都加入回负载均衡当中去,完成对外服务,对硬件资源要求很高,但是有了云计算和微服务,现在的成本也大大降低了 特点: 1.一旦出现问题,问题影响范围很大 2.发布策略简单 3.基于云计算技术和微服务,用户是无感知的 4.升级和回滚都比较方便 缺点: 在发布升级的过程之中,只有一部分集群在对外服务,可能会使集群的负载能力下降,响应变慢,需要注意给集群增加负载能力(一般来说没什么特殊需求) 段时间内可能会浪费一定的资源成本 |
金丝雀发布(灰度发布) | 基于deployment控制器创建的服务,才可以使用这种发布方式,也算是一种滚动更新,实现了一个步骤叫暂停,也就是发布的过程中,暂时停止,只有一部分的pod先升级,其他的pod还是处于老的版本,只有一部分用户可以访问新的版本,绝大数用户还在老版本,确定无问题之后,再把剩下的老版本升级成新的版本,也就是把暂停取消,继续发布,如果有问题可以立即回滚,暂停不是回滚,一旦取消暂停只能全部升级完毕之后,再回滚。 特点: 自动化的要求比较高,对运维人员的要求比较高 方便发现问题,及时解决,影响范围比较小 用户无感知,可以实现平滑过渡,而且比较节约资源 发布策略比较复杂 不易回滚,必须等到全部发布成功之后才能回滚。 |
滚动发布 | deployment的默认更新方式 |
应用程序升级,面临的最大的问题是新旧业务之间的切换,从立项>定稿>需求发布>开发>测试>发布,测试之后上线,再完美也会有问题,为了不让发生的问题影响所有用户,有了上述的三种发布方式 |
声明式资源管理(yaml文件)
1 | 适合对资源的修改操作 |
2 | 声明式管理依赖于yaml文件,所有的内容都在yaml文件当中 |
3 | 编辑好的yaml文件还是要靠陈述式命令发布到k8s集群当中 |
Kubectl create | 只能创建,不能更新,从指定yaml文件中读取配置,创建服务,不能更新 |
Kubectl apply -f | 既可以创建资源对象也可以更新资源对象,如果yaml文件更改了,apply可以直接更新资源对象 |
Kubectl delete -f | 删除yaml文件中声明的资源对象,如deployment或者pod和service |
Yaml文件如何生成
1 | 手打 |
2 | 可以根据已有的资源,直接生成 1.deployment的yaml文件 2.Service的yaml文件 3.不基于控制器的pod的yaml文件 |
k8s当中支持两种声明式资源管理方式
yaml格式 | 用来配置和管理资源对象 |
Json格式 | 主要用于api接口之间消息的传递 |
[root@master01 k8s.yaml]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-test 0/3 3 0 5d
nginx-chen 0/1 1 0 40h
[root@master01 k8s.yaml]# kubectl get deployments.apps nginx-chen -o yaml
展示yaml文件
[root@master01 k8s.yaml]# kubectl get deployments.apps nginx-chen -o yaml > /opt/k8s.yaml/nginx-chen.yaml
导出修改
[root@master01 k8s.yaml]# vim nginx-chen.yaml
[root@master01 k8s.yaml]# kubectl apply -f nginx-chen.yaml
Warning: resource deployments/nginx-chen is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
deployment.apps/nginx-chen configured
第二次更新必须要导出之后才能更新
[root@master01 k8s.yaml]# kubectl get pod
?deployment
apiVersion: apps/v1
#声明API版本的标签
kind: Deployment
#定义资源的类型service/pod/deployment/jod/ingress/daemonset/statefulset
metadata:
name: nginx1
namespace: chen
labels:
wdf: nginx1
#标签名可以自定义
#定义资源的元数据信息,资源名称,资源对象部署的命名空间,标签等等信息
spec:
#定义deployment的资源需要的参数属性
replicas: 3
#定义副本数
selector:
#定义标签选择器
matchLabels:
wdf: nginx1
#选择匹配的标签
template:
#定义业务模版,如果定义了多个副本,所有的副本的属性都会按照模版的配置进行匹配
metadata:
labels:
wdf: nginx1
#定义了pod的副本都使用元数据的标签和属性来进行匹配
spec:
containers:
- name: nginx
image: nginx:1.10
posts:
- containerPort: 80
#spec声明的是容器的相关参数,虽然我指定了容器的暴露端口是80,nginx默认的镜像就是80,即使声明了其他端口,也不会改变容器的端口,除非nginx的端口已经被修改,那么这里声明端口是可以的
service?
#定义API的版本
apiVersion: v1
kind: Service
metadata:
name: nginx-service
namespace: chen
labels:
wdf: nginx1
#这里的元数据信息包括,service的名称,所属的命名空间,以及要匹配的deployment的标签,这里的标签要和之前的标签名保持一致,否则它不知道为谁服务
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
#nodepord: 30000
#这里可以指定访问端口,可以以不指定,不指定就会随机分配(范围是30000-32764)
selector:
wdf: nginx1
#匹配所有的标签都是wdf:nginx1的pod后端提供服务
pod
#定义pod的apirversion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息,主要是一些pod的名称,命名空间,标签
metadata:
name: centos1
namespace: chen
spec:
restartPolicy: Never
#restartPolicy指的是pod内的容器启动失败或者有问题的重启策略:Always Never Onfailue ##三种重启策略,只有异常退出才会重启,状态非0,如果状态是0,不重启,restartPolicy指的是容器的重启策略,资源类
型定义为deployment,容器的重启策略只能是Always
containers:
- name: centos
image: centos:7
command: ["echo"]
args: ["hello,word!"]
command
args
定义容器运行的命令参数,类型于docker的CMD和entrypoint
args可以理解docker中的cmd 给command传参
command和args都会覆盖原容器的标准输出(cmd)
#定义pod的apiversion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息,pod的名称,所属的标签
metadata:
name: centos1
spec:
restartPolicy: Always
#restartPolicy指的是pod内的容器启动失败或者有问题的重启策略:always 指的是总是重启 never 指的是挂就挂了 Onfailure(只有异常退出才会重启,状态非0,如果状
态码是0,不重启),restartPolicy指的是容器的重启策略,资源类型定义为deployment,容器的重启策略只能是Always
containers:
- name: centos
image: centos:7
args:
- /bin/bash
- -c
- while true; do sleep 3600; done
#多个命令要用分号隔开
#定义pod的apiversion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息,pod的名称,所属的标签
metadata:
name: centos1
namespace: xiaobu
spec:
restartPolicy: Always
#restartPolicy指的是pod内的容器启动失败或者有问题的重启策略:always 指的是总是重启 never 指的是挂就挂了 Onfailure(只有异常退出才会重启,状态非0,如果状
态码是0,不重启),restartPolicy指的是容器的重启策略,资源类型定义为deployment,容器的重启策略只能是Always
containers:
- name: centos
image: centos:7
command: ["/usr/bin/test", "-e", "/etc/passwd"]
command: ["/bin/bash", "-c", "touch /tmp/live ; sleep 30; rm -rf /tmp/live; slepp 3600"]
#command和args只能有一个,会把容器的标准输出覆盖,不论是args和commmand都会覆盖CMD和ENTYRPOINT
command和args不要同时出现,除非你要传参,都会容器的标准输出