【K8S 资源管理】声明式资源管理

目录

一、常用的发布方式

1、蓝绿发布：

2、金丝雀发布（灰度发布）：

3、滚动更新（deployment的默认更新方式）：

二、声明式管理方法（yaml文件）

1、三种发布命令：

2、三种常用的yaml文件：

2.1、deployment的yaml文件：

2.2、service的yaml文件：

2.3、port的yaml文件：

---

一、常用的发布方式

三种常见的项目发布方式：

蓝绿发布、金丝雀发布（灰度发布）、滚动发布

应用程序升级，面临的最大的问题是新旧业务之间的切换。

立项—定稿—需求发布—开发—测试—发布

测试之后上线，在完美也会有问题。为了不让发生的问题影响所有用户，产生了上述的三种发布方式

1、蓝绿发布：

工作方式：

1、把应用服务集群标记为两个组，蓝组和绿组。先升级蓝组，要把蓝组从负载均衡当中移除，绿组继续提供服务

2、蓝组升级完毕，再把绿组从负载均衡中移除，绿组升级，然后都加入回负载均衡中去，完成对外服务

蓝绿发布对硬件资源要求很高，但是有了云计算和微服务，现在的成本也大大降低了

蓝绿发布的特点：

1. 一旦出现问题，问题的影响范围很大
2. 发布策略简单
3. 基于现在的云计算和微服务，用户是无感知的
4. 升级和回滚都比较方便

缺点：

在发布升级的过程中，只有一部分集群在对外提供服务，可能会使集群的负载能力下降，响应变慢，需要注意给这个集群增加负载能力（一般来说没什么特殊需要，一般都是半夜访问最小的之后升级）。在短时间内可能会浪费一定的资源成本

2、金丝雀发布（灰度发布）：

必须是基于deployment控制器创建的服务，才可以使用这种发布方式。相当于测试服

工作方式：

实际上也是一种滚动更新，发布的过程中，暂时停止，只有一部分的pod先升级，其他的pod还是处于老的版本。只有一部分用户可以访问新的版本，绝大多数用户还是老版本。确定无问题之后，再把剩下的老版本升级成新版本，把暂停取消，继续发布。如果有问题，可以立即回滚。暂停不是回滚，一旦取消暂停，只能全部升级完毕之后再回滚

#K8S的金丝雀暂停发布，只会更新一个

kubectl set image deployment nginx nginx=nginx:1.24 --record && kubectl rollout pause deployment nginx

#统一更新

kubectl rollout resume deployment nginx

#全部升级完毕后才能回滚

kubectl rollout history deployment nginx

kubectl rollout undo deployment nginx --to-revision=1

若想回滚，只能全部升级完毕之后，才能回滚

灰度发布特点：

1. 自动化的要求比较高，对运维人员的要求比较高
2. 方便发现问题，及时解决，影响范围比较小
3. 用户无感知，可以实现一个平滑的过度。节约资源
4. 发布策略比较复杂
5. 不易回滚，必须等到全部发布成功之后，才能回滚

3、滚动更新（deployment的默认更新方式）：

deployment的默认更新方式

一般灰度和滚动发布即可

一般用滚动，特殊场景用灰度（要准备场景）

二、声明式管理方法（yaml文件）

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

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

3、编辑好的yml文件还是要靠陈述式命令发布到K8S集群中

K8S中支持两种声明式的资源管理方式：

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

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

1、三种发布命令：

kubectl create

#create只能创建，不能更新。从指定的yml文件中读取配置，创建服务。不能更新

kubectl apply -f

#既可以创建资源对象，也可以更新资源对象。如果yml文件更改了，apply可以直接更新资源对象（用的最多的方式）

kubectl delete -f

#删除yml文件中声明的资源对象

yaml文件如何生成：

两种方式：
1、手打

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

kubectl get deployments.apps nginx -o yaml

kubectl get deployments.apps nginx -o yaml > /opt/test.yaml

调用yaml文件

kubectl apply -f test.yaml

改过一次的yaml文件再次调用会报错，重新导出yaml文件才行

若修改之后，想再调用加--force 强制调用

kubectl apply -f test.yaml --force

2、三种常用的yaml文件：

1. deployment的yaml文件（daemonset、statefulset）
2. service的yaml文件
3. 不基于控制器的pod的yaml文件

2.1、deployment的yaml文件：

?

#deployment的yaml文件模版
kubectl explain deployment


vim deployment

apiVersion: apps/v1
#声明api版本的标签
kind: Deployment
#定义资源的类型（Service/Pod/Deployment/Job/Ingress/Daemonset/Statefulset）
metadata:
  name: nginx1 
  namespace: test1
  labels: 
    test: nginx1
#定义资源的元数据信息，比如资源名称、资源对象、部署的命名空间、标签等信息
spec:
#定义deployment的资源需要的参数属性
  replicas: 3
#定义副本数
  selector: 
#定义标签选择器
    matchLabels: 
      test: nginx1
#选择匹配的标签
  template:
#定义业务模版，如果定义了多个副本，所有的副本属性都会按照模版的配置进行匹配
    metadata: 
      labels: 
        test: nginx1
#定义了pod的副本都使用元数据的标签和属性来进行匹配
    spec:
      containers: 
      - name: nginx
        image: nginx:1.10
        #ports: 
        #- containerPort: 80
#spec声明的是容器的相关参数，虽然指定了容器的暴露端口是80，如果镜像默认的端口不是80，80也访问不了，端口这里可以忽略，默认的不用加，即使指定了其他端口，也不会改变容器的端口，要改只能进容器改.

2.2、service的yaml文件：

vim service.yaml


#定义api版本
apiVersion: v1
kind: Service
metadata:
  name: nginx1-service
  namespace: test1
  labels:
    test: nginx1
#元数据信息包括，service的名称（不能重复），所属的命名空间，以及要匹配的deployment的标签（要和之前的deployment标签一致，否则会重新生成新的service）

spec:
  type: NodePort
  ports: 
  - port: 80
    targetPort: 80
    nodePort: 30000
  selector: 
    test: nginx1
#匹配所有的标签都是test:nginx1的pod后端提供服务

2.3、port的yaml文件：

vim pod.yaml


#pod的yaml模版
kubectl explain pod

#定义pod的apiversion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息,pod的名称，所属的命名空间，标签等
metadata:
  name: centos1
  namespace: test1

spec:
  restartPolicy: Always
#restartPolicy指的是pod内的容器启动失败或者有问题的重启策略：Always、Never、Onfailure（只有异常>
退出才会重启，状态码非0重启，为0不重启），restartPolicy指的是容器的重启策略，资源类型定义为deplo
yment，容器的重启策略只能是Always，可以不加。
  containers:
  - name: centos
    image: centos:7

运行一次之后，centos会直接退出

想要持续运行要添加两个参数：

command、args

定义容器运行的命令参数，类型与docker的CMD和ENTRYPOINT

args可以理解为CMD，可以给command传参

CMD可以给ENTRYPOINT传参

command和args都会覆盖原容器的标准输出（CMD和ENTRYPOINT都会覆盖）

持续运行：

#定义pod的apiversion
apiVersion: v1
#定义资源的类型
kind: Pod
#定义元数据信息,pod的名称，所属的命名空间，标签等
metadata:
  name: centos1
  namespace: test1

spec:
  restartPolicy: Never
#restartPolicy指的是pod内的容器启动失败或者有问题的重启策略：Always、Never、Onfailure（只有异常>
退出才会重启，状态码非0重启，为0不重启），restartPolicy指的是容器的重启策略，资源类型定义为deplo
yment，容器的重启策略只能是Always，可以不加。
  containers:
  - name: centos
    image: centos:7
    args: 
    - /bin/bash
    - -c
    - while true; do sleep 3600; done
#多个命令用;分号隔开

3600秒后自动退出

也可以在一行定义多个命令：用,逗号和空格隔开

command的多条命令一起执行必须是 /bin/bash -c 开头

格式：

command和args只能有一个。会把容器的标准输出覆盖。不论是args和command都会覆盖CMD和ENTRYPOINT

command和args不要同时出现，除非传参时。都会覆盖容器的标准输出（CMD和ENTRYPOINT）