K8S三种发布方式和声明式资源管理

2024-01-02 18:05:40
蓝绿发布

把应用服务集群标记位两个组,蓝组和绿组,先升级蓝组,先要把蓝组从负载均衡当中移除,绿组继续提供服务,蓝组升级完毕,再把绿组从负载均衡当中移除,绿组升级,然后都加入回负载均衡当中去,完成对外服务,对硬件资源要求很高,但是有了云计算和微服务,现在的成本也大大降低了

特点:

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不要同时出现,除非你要传参,都会容器的标准输出

文章来源:https://blog.csdn.net/2301_79410672/article/details/135338871
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。