欠费之后操作设计

[xiao-jay]

1、背景：

用户会出现欠费情况，要做到提前提醒用户欠费情况和欠费到一定程度自动停止用户使用，重度欠费清除用户资源的作用。

2、用户使用cloud场景

2.1、使用service和deployment部署了自己的服务，使用ingress暴露服务供前端调用。

接近欠费应提醒用户

轻度欠费应停止ingress暴露服务无法外部访问，pod，deployment等资源应该只能get不能update，（是否停止计费待商榷），持续超过7天释放资源

重度欠费清除namespace资源

2.2、使用了cloud provider起了一个集群。

接近欠费提醒用户

轻度欠费让他无法连接自己的infra，并且可以使aws的服务器关机，停止计费，持续超过7天释放资源

重度欠费清除用户的infra资源

3、具体实现逻辑

一个controller，监听Account，Account余额计算出如果轻度欠费，关闭ingress暴露服务（暂时不知道如何实现），通过webhook禁止用户create/update pod、deployment、service，不能apply yaml（不知道如何实现）。

如果出现重度欠费，删除用户ns所有资源。

4、提醒模块逻辑

controller 里面调用一个前端接口，在前端的通知栏里面显示

并且使用短信/邮件/电话等方式联系用户

5、定义欠费程度与金额的对应关系

接近欠费- 20

轻度欠费- 0

重度欠费- -100

[fanux]

3. 轻度欠费时 建议控制器改变用户的 RBAC 让用户收回用户访问所有 API 的权限，并提醒
4. 中度欠费时 清理用户 ns 里面的 ingress 对象
5. 重度欠费删除 ns

[xiao-jay]

1、轻度欠费的时候，用户的pod还在正常运行，还会正常扣费，应该是不扣用户费用了吧
2、infra那个你禁止用户访问也没用，有开发基础的用户会通过私钥直接连接aws服务器

[zzjin]

1. 欠费程度对应的阶段和操作应该是统一的,就是一个完整的有限状态机:
   1. 正常
   2. 即将欠费
   3. 轻度欠费
   4. 重度欠费
   5. 注销(?)

       stateDiagram-v2
       [*] --> 正常
       正常 --> 即将欠费: 使用资源
       note right of 即将欠费
         发送即将欠费通知
       end note
       即将欠费 --> 轻度欠费: 继续使用
       note right of 轻度欠费
         发送欠费通知
       end note
       note right of 轻度欠费
         更新RBAC(?)
       end note
       note right of 轻度欠费
         暂停Namespace
       end note
       轻度欠费 --> 重度欠费: 继续使用
       轻度欠费 --> 正常: 充值
       重度欠费 --> 正常: 充值
       重度欠费 --> [*]: 超过N天
       note right of 重度欠费
         删除所有资源
       end note
   

   Loading
2. 模块本身是可扩展的:
   1. pod/ns 对应的管理模块
   2. 第三方service的管理模块(SCP)
   3. 通知提醒模块
      模块本身如何对接? 装SCP的controller的时候如何对接?

具体实现逻辑:

把所有pod的scale全部改成0?
https://github.com/govirtuo/kube-ns-suspender
https://codeberg.org/hjacobs/kube-downscaler

[fanux]

那还有 infra 怎么办

[xiao-jay]

@zzjin @fanux 异步对一下吧
12.30号前目标，通知系统怎么让前端知道还没想好，发送短信可以接入第三方服务，先把框架搭出来只实现重度扣费直接删除ns的操作吧

    stateDiagram-v2
    [*] --> 正常
    正常 --> 即将欠费: 使用资源
    note right of 即将欠费
      发送即将欠费通知
    end note
    即将欠费 --> 重度欠费: 继续使用
    note right of 重度欠费
      发送欠费通知
    end note
    重度欠费 --> 正常: 充值
    重度欠费 --> [*]:超过N天，删除所有资源

Loading

通知系统

stateDiagram-v2
[*] --> 通知controller:欠费消息
通知controller --> 前端消息通知接口: 欠费信息和后果
通知controller --> 用户手机短信: 欠费信息和后果

Loading

之后期望做成的样子

    stateDiagram-v2
    [*] --> 正常
    正常 --> 即将欠费: 使用资源
   
    轻度欠费 --> 重度欠费: 继续使用
    轻度欠费 --> 正常: 充值
   
    重度欠费 --> 正常: 充值
    轻度欠费 --> [*]: 超过2*N天，删除所有资源
     note right of 即将欠费
      发送即将欠费通知
    end note
    即将欠费 --> 轻度欠费: 继续使用
    note right of 轻度欠费
      发送欠费通知
    end note
    note right of 轻度欠费
      更新RBAC，只能get和list
    end note
    note right of 轻度欠费
      暂停Namespace,pod,ingress的scale改为0
    end note

    重度欠费 --> [*]: 超过N天，删除所有资源
        note left of 重度欠费
      发送欠费通知
    end note

Loading

[zzjin]

前端消息通知接口 这个应该是一个通知controller维护的一个cr?然后一个用户一个cr,里面spec可能没有数据,status就是N条通知的list,每个list内部是object包含正文,时间,是否已读等,前端直接get这个crd就能列出来所有的消息通知

第二个流程里面,轻度欠费之后,所有的pod,scale都是0了,是不是用户已经没法“继续使用“cloud了?这个在什么情况下会转变状态到重度欠费呢

[xiao-jay]

1、怎么判断是否已读是我疑惑的点，又怎么做到不重复提醒两次
2、有可能轻度欠费之后继续使用infra（现在对infra的操作只有启动和删除），到达重度，也有可能是我们没考虑到的情况导致资源继续被使用，继续被扣费，比如用户使用了自定义资源啥的。

[fanux]

会有个统一的通知服务，不管欠费还是其它事件都通过这个服务来推送

[xiao-jay]

通知那个玩意不管是否已读了，每个用户有一个通知数据CR，有一个欠费controller，欠费会去监听account金额变化，如果是欠费了就把状态变为欠费然后在通知数据CR中更新通知信息，前端就去看这个通知数据CR吧，然后按时间顺序从最新的开始列出来通知，暂时没有用户确认通知的功能。

[zzjin]

我觉得可以，不过欠费controller还需要实际的操作ns的各种限制吧？）还是再来个controller

[xiao-jay]

对，现在先简单一点来