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

本文探讨了在云计算和微服务背景下,蓝绿发布、滚动更新(如金丝雀发布)以及声明式资源管理(如yaml文件)在应用服务集群升级中的应用。这些方法强调自动化、资源优化和减少用户感知的发布策略,但也涉及可能的资源浪费和性能影响。
摘要由CSDN通过智能技术生成
蓝绿发布

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

特点:

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

  • 23
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在Kubernetes中,您可以使用以下三种方来部署Nginx: 1. 使用Deployment和Service:这是最常见的部署方,它使用Deployment控制器来管理Pod的创建和伸缩,并使用Service将流量路由到Pod。以下是一个示例配置: Deployment配置(nginx-deployment.yaml): ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 ``` Service配置(nginx-service.yaml): ```yaml apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer ``` 使用命令部署: ``` kubectl apply -f nginx-deployment.yaml kubectl apply -f nginx-service.yaml ``` 2. 使用Helm Chart:Helm是Kubernetes的包管理工具,可以简化应用程序的部署和管理。您可以使用Helm Chart来部署Nginx。以下是一个示例配置: 创建Helm Chart: ``` helm create nginx-chart ``` 编辑Chart配置文件(values.yaml): ```yaml replicaCount: 3 image: repository: nginx tag: latest pullPolicy: IfNotPresent service: name: nginx-service type: LoadBalancer port: 80 ``` 安装Helm Chart: ``` helm install nginx nginx-chart ``` 3. 使用Kubernetes Ingress:Ingress是Kubernetes集群中的一个API对象,它充当流量入口,并将流量路由到不同的服务。您可以使用Ingress来部署Nginx,并通过Ingress规则配置路由。以下是一个示例配置: 创建Ingress资源(nginx-ingress.yaml): ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nginx-ingress spec: rules: - host: example.com http: paths: - pathType: Prefix path: / backend: service: name: nginx-service port: number: 80 ``` 使用命令部署: ``` kubectl apply -f nginx-deployment.yaml kubectl apply -f nginx-ingress.yaml ``` 请注意,这些示例仅提供了基本的部署配置。根据您的需求,您可能需要进行其他配置,例如使用持久卷声明(Persistent Volume Claim)来存储Nginx日志文件或自定义Nginx配置等。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值