当前位置:   article > 正文

k8s声明式资源管理

k8s声明式资源管理
三种常见的项目发布方式

1、蓝绿发布

2、金丝雀发布(灰度发布

3、滚动发布

应用程序升级,面临的最大的问题是新旧业务之间的切换,立项-----定稿------需求发布-----开发------测试------发布,测试之后上线,再完美也会有问题的,为了不让发生的问题影响所有用户,上述的三种发布方式

什么是蓝绿发布?

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

蓝绿发布的特点

1、一旦出现问题,问题的影响范围很大

2、发布策略简单

3、基于现在的云计算和微服务,用户无感知的

4、升级和回滚都比较方便

缺点

在发布升级的过程之中,只有一部分集群在对外提供服务,可能会是集群的负载能力下降,响应变慢,需要注意给集群增加负载能力(一般来说没有什么特殊需要),短时间内可能会浪费一定的资源成本

金丝雀发布(灰度发布)

deployment控制器创建的服务,才可以使用这种发布方式,滚动更新,暂停,发布的过程中,暂时停止,只有一部分的pod先升级,其他的pod还是处于老的版本,只有一部分用户可以访问新的版本,绝大多数用户还是在老版本,确定无问题之后,再把剩下的老版本,升级成新的版本,把暂停取消,继续发布,如果有问题,可以立刻回滚,暂停不是回滚,一旦取消只能全部升级完毕之后,在回滚

灰度发布的特点

1、自动化的要求比较,对运维人员的要求比较高

2、方便问题,及时解决,影响范围比较小

3、用户无感知,平滑过度,节约资源

4、发布策略比较复杂

5、不易回滚,必须要全部发布成功之后才能回滚

滚动更新

deployment的默认就是滚动更新

声明式

声明式管理方式(yaml)文件

1、适合对资源的修改操作

2、声明式管理依赖于yaml文件,所有的内容都在yaml文件当中

3、编辑好的yaml文件,还是要依靠陈述式的命令发布到k8s集群当中

  1. kubectl create 只能创建,不能更新,从指定yaml文件中读取配置,创建服务,不能更新
  2. kubectl apply -f 既可以创建资源对啊ing也可以更新资源对象,如果yaml文件更改了,apply可以直接更新资源对象
  3. kubectl delete -f 删除yaml文件中声明的资源对象
yaml文件如何生成

1、手打

2、可以根据已有的资源,直接生成

  1. kubectl get deployment.apps nginx -o yaml 展示yaml文件
  2. kubectl get deployment.apps nginx -o yaml >> test.yaml 导出修改
  3. kubectl apply -f test.yaml 更新
  4. 第二次更新必须导出之后才能更新
  5. 1、deployment的yaml文件 daemonset sratefulset
  6. 2、service的yaml文件
  7. 3、不基于控制器的pod的yaml文件

在k8s当中支持两种声明式的资源管理方式

1、yaml格式,用于配置和管理资源对象

2、json格式,只要用于在api接口之间消息的传递

声明式的格式
deployment
  1. kubectl explain deployment 声明deployment的语法(格式)
  2. vim nginx.yml
  3. apiVersion: apps/v1
  4. #声明API版本的标签
  5. kind: Deployment
  6. #定义资源的类型service pod deployment job ingress daemonset statefulset
  7. metadata:
  8. name: nginx1
  9. #定义资源的元数据信息,比较说资源名称,资源对象部署的命名空间,标签等等信息
  10. namespace: xiaobu
  11. labels:
  12. xb: nginx1
  13. spec:
  14. #定义deployment的资源需要的参数属性
  15. replicas: 3
  16. #定义副本数
  17. selector:
  18. #定义标签选择器
  19. matchLables:
  20. xb: nginx1
  21. #选择匹配的标签
  22. template:
  23. #定义业务模版,如果定义了多个副本,所有的副本的属性都会按照模版的配置进行匹配
  24. metadata:
  25. labels:
  26. xb: nginx1
  27. #定义了pod的副本都使用元数据的标签和属性来进行匹配
  28. spec:
  29. containers:
  30. - name: nginx
  31. image: nginx:1.10
  32. posts:
  33. - containerPort: 80
  34. #spec声明的是容器的相关参数,虽然我指定了容器的暴露端口是80,nginx默认的镜像就是80,即使指定了其他端口,也不会改变容器的端口
  35. kubectl apply -f nginx1.yml
  36. kubectl create ns xiaobu 创建命名空间
nginx-service
  1. vim nginx-service.yml
  2. #定义API的版本
  3. apiVersion: v1
  4. kind: Service
  5. metadata:
  6. name: nginx-service
  7. namespace: xiaobu
  8. labels:
  9. xb: nginx1
  10. #元数据信息包括,service的名称,所属的命名空间,以及要匹配的deployment的标签,要和之前的保持一致
  11. spec:
  12. type: NodePort
  13. ports:
  14. - port: 80
  15. targetPort: 80
  16. # nodePort: 30000
  17. #可以指定访问的端口,也可以不指定访问端口(随机分配)
  18. selector:
  19. xb: nginx1
  20. #匹配所有的标签都是xb:nginx1的pod的后端提供服务
  21. kubectl apply -f nginx-service.yml
  22. 查看指定的控制器的service
  23. kubectl get svc -n xiaobu
  24. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
  25. nginx-service NodePort 10.96.56.18 <none> 80:31195/TCP 13s
  26. curl -I 20.0.0.70:31195
  27. HTTP/1.1 200 OK
  28. Server: nginx/1.10.3
  29. Date: Tue, 02 Jan 2024 03:18:33 GMT
  30. Content-Type: text/html
  31. Content-Length: 612
  32. Last-Modified: Tue, 31 Jan 2017 15:01:11 GMT
  33. Connection: keep-alive
  34. ETag: "5890a6b7-264"
  35. Accept-Ranges: bytes
pod
  1. 定义pod的apiversion
  2. apiVersion: v1
  3. #定义资源的类型
  4. kind: Pod
  5. #定义元数据信息,pod的名称,所属的标签
  6. metadata:
  7. name: centos1
  8. spec:
  9. restartPolicy: Never
  10. #restartPolicy指的是pod内的容器启动失败或者有问题的重启策略:always 指的是总是重启 never 指的是挂就挂了 Onfailure(只有异常退出才会重启,状态非0,如果状
  11. 态码是0,不重启),restartPolicy指的是容器的重启策略,资源类型定义为deployment,容器的重启策略只能是Always
  12. containers:
  13. - name: centos
  14. image: centos:7
  15. command
  16. args
  17. 定义容器运行的命令参数,类型于docker的CMD和entrypoint
  18. args可以理解docker中的cmd 给command传参
  19. command和args都会覆盖原容器的标准输出(cmd)
  20. #定义pod的apiversion
  21. apiVersion: v1
  22. #定义资源的类型
  23. kind: Pod
  24. #定义元数据信息,pod的名称,所属的标签
  25. metadata:
  26. name: centos1
  27. spec:
  28. restartPolicy: Always
  29. #restartPolicy指的是pod内的容器启动失败或者有问题的重启策略:always 指的是总是重启 never 指的是挂就挂了 Onfailure(只有异常退出才会重启,状态非0,如果状
  30. 态码是0,不重启),restartPolicy指的是容器的重启策略,资源类型定义为deployment,容器的重启策略只能是Always
  31. containers:
  32. - name: centos
  33. image: centos:7
  34. args:
  35. - /bin/bash
  36. - -c
  37. - while true; do sleep 3600; done
  38. #多个命令要用分号隔开
  39. #定义pod的apiversion
  40. apiVersion: v1
  41. #定义资源的类型
  42. kind: Pod
  43. #定义元数据信息,pod的名称,所属的标签
  44. metadata:
  45. name: centos1
  46. namespace: xiaobu
  47. spec:
  48. restartPolicy: Always
  49. #restartPolicy指的是pod内的容器启动失败或者有问题的重启策略:always 指的是总是重启 never 指的是挂就挂了 Onfailure(只有异常退出才会重启,状态非0,如果状
  50. 态码是0,不重启),restartPolicy指的是容器的重启策略,资源类型定义为deployment,容器的重启策略只能是Always
  51. containers:
  52. - name: centos
  53. image: centos:7
  54. command: ["/usr/bin/test", "-e", "/etc/passwd"]
  55. command: ["/bin/bash", "-c", "touch /tmp/live ; sleep 30; rm -rf /tmp/live; slepp 3600"]
  56. #command和args只能有一个,会把容器的标准输出覆盖,不论是args和commmand都会覆盖CMD和ENTYRPOINT
  57. command和args不要同时出现,除非你要传参,都会容器的标准输出
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/不正经/article/detail/629175
推荐阅读
相关标签
  

闽ICP备14008679号