django 应用里面的脚本怎么在 k8s 平台启动更合适?

1

全部打到一个镜像里面去不就行了,不同 pod 用不同的启动命令运行不同的脚本

2

看下来,按我的理解第三个应该是要常驻运行的。那么可以将第一、第二个的脚本封装成一个 API 接口,按需执行。

3

@FarmerChillax 你意思是封装成一个 API 接口,再建一个常驻运行的脚本定时调用吗?

4

问 ai 都会给出 4 中答案啊,明显都可以

5

100 多个脚本, 梳理一下, 做一些技术改造.

1. 偶尔执行的. 改成 django admin 后台配置页面触发. 任务流, 改成 消息队列(生产者-消费者模型).

基于 队列(kafka, rabbitmq, nats 都可以) 解耦: 动作触发(生产者) 和 动作执行(消费者).

推荐 nats, 运维简单.

工作流改造成:

a. admin 侧, 触发动作, send task(参数包) 到消息队列, admin 结束.

b. 消息队列的 监听者 worker, 收到 task, 解析参数, 执行具体任务, 结束.

2. 定时任务, 可以试试 huey 和 django-huey, 支持 redis 监听不同的 queue 来分别监听 + 执行.

比 celery 简单. 注意如果启用了 django 时区, huey 配置也要启用时区, 否则是 UTC 时间.(小坑) 其他使用挺完美.

https://github.com/coleifer/huey

https://github.com/gaiacoop/django-huey

经过上述改造. 如果不考虑高可用, 单副本下, 你大概只需要部署 2-3 个容器实例, 就够了.

需要注意, 如果是 k8s 多副本实例, 需要 MQ 消息 幂等唯一消费, 可以引入一个分布式锁判定, 可以简单用 redis 锁.

上面的方案, 算是比较标准的做法.

不要滥用 django scripts 的一些方便用法. (后期维护一堆烂脚本, 显然是不明智的)

6

@linxuan716 脚本定时调用就没必要常驻了吧😂

7

打包一个镜像 分别用于 job cronjob daemonset (或者别的)

8

其实单独打包镜像不会很多,镜像的 layer 很多都是共用的

9

1. 打成两个镜像,一个是基础运行环境镜像,另一个是代码包镜像,busybox 装就行,最小化。
2. 使用 InitContainer 组合代码和运行环境变成一个 POD 。这样可以升级的时候,只升级代码包
3. 执行不同脚本,你可以用不同的 POD