共计 4108 个字符,预计需要花费 11 分钟才能阅读完成。
作者:学仁
简介
K8s Job 是 Kubernetes 中的一种资源,用来解决短周期的 Pod,相当于一次性工作,跑完就会把 Pod 销毁,不会始终占用资源,能够节省成本,进步资源利用率
阿里任务调度 SchedulerX 和云原生联合,重磅推出可视化 K8s 工作,针对脚本使用者,屏蔽了容器服务的细节,不必构建镜像就能够让不相熟容器的同学(比方运维和经营同学)玩转 K8s Job,受害容器服务带来的降本增效福利。针对容器使用者,SchedulerX 岂但齐全兼容原生的 K8s Job,还能反对历史执行记录、日志服务、重跑工作、报警监控、可视化工作编排等能力,为企业级利用保驾护航。架构图如下:
个性一:疾速开发 K8s 可视化脚本工作
Kubernetes 的 Job,常见用来做离线数据处理和运维工作(比方每天凌晨 2 点把 mysql 数据同步到大数据平台,每隔 1 小时更新一次 redis 缓存等),个别以脚本实现居多。这里以一个简略的场景举例子,来比照两种计划的差别。
Kubernetes 原生解决方案
K8s 调度的最小单位是 Pod,想跑脚本工作,须要提前把脚本打包到镜像里,而后在 YAML 文件中配置脚本命令,上面以通过 python 脚本查询数据库为例子:
- 编写 python 脚本 demo.py
#!/usr/bin/python
# -*- coding: UTF-8 -*-
import MySQLdb
# 关上数据库连贯
db = MySQLdb.connect("localhost", "testuser", "test123", "TESTDB", charset='utf8')
# 应用 cursor() 办法获取操作游标
cursor = db.cursor()
# SQL 查问语句
sql = "SELECT * FROM EMPLOYEE \
WHERE INCOME > %s" % (1000)
try:
# 执行 SQL 语句
cursor.execute(sql)
# 获取所有记录列表
results = cursor.fetchall()
for row in results:
fname = row[0]
lname = row[1]
age = row[2]
sex = row[3]
income = row[4]
# 打印后果
print "fname=%s,lname=%s,age=%s,sex=%s,income=%s" % \
(fname, lname, age, sex, income)
except:
print "Error: unable to fetch data"
# 敞开数据库连贯
db.close()
- 编写 Dockerfile
FROM python:3
WORKDIR /usr/src/app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY demo.py /root/demo.py
CMD ["python", "/root/demo.py"]
- 制作 docker 镜像,推到镜像仓库中
docker build -t registry.cn-beijing.aliyuncs.com/demo/python:1.0.0 .
docker push registry.cn-beijing.aliyuncs.com/demo/python:1.0.0
- 编写 K8s Job 的 YAML 文件,image 抉择第 3 步制作的镜像,command 的命令为执行脚本
apiVersion: batch/v1
kind: Job
metadata:
name: demo-python
spec:
template:
spec:
containers:
- name: demo-python
image: registry.cn-beijing.aliyuncs.com/demo/python:1.0.0
command: ["python", "/root/demo.py"]
restartPolicy: Never
backoffLimit: 4
咱们看到要在容器服务中跑脚本,须要这么多步骤,如果要批改脚本,还须要从新构建镜像和从新公布 K8s Job,十分麻烦。
阿里云解决方案
阿里任务调度 SchedulerX 联合云原生技术,提出了一套可视化的脚本工作解决方案,通过任务调度零碎来治理脚本,间接在线编写脚本,不须要构建镜像,就能够将脚本以 Pod 的形式在用户的 K8s 集群当中运行起来,应用十分不便,如下图:
- 在 SchedulerX 工作治理新建一个 K8s 工作,资源类型抉择 Python-Script(以后反对 shell/python/php/nodejs 四种脚本类型)
- 点击运行一次,在 Kubernetes 集群中能够看到 pod 启动,pod 名称为 schedulerx-python-{JobId}
- 在 SchedulerX 控制台也能够看到历史执行记录
- 在 SchedulerX 控制台能够看到 Pod 运行的日志
上面通过一个表格更不便的看到两个计划的差别:
个性二:齐全兼容原生 K8s Job
SchedulerX 岂但可能疾速开发 K8s 脚本工作,屏蔽容器服务的细节,给不相熟容器服务的同学带来福音,同时还能托管原生 K8s Job。
原生自带的 Job 计划
- Job
以官网提供的 Job 为例:
- 编写 YAML 文件 pi.yaml,成心写一个谬误,bpi(-1) 是非法的
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl:5.34
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(-1)"]
restartPolicy: Never
backoffLimit: 4
- 在 K8s 集群中运行该 Job,并查看 Pod 的状态和日志:
K8s 原生的 Job 不反对重跑,批改完 Job 后想要重跑,须要先删除,再从新 apply,十分麻烦。
- CronJob
以官网提供的 CronJob 为例:
- 编写 hello.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello
spec:
schedule: "* * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: perl:5.34
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(100)"]
restartPolicy: OnFailure
- 在 K8s 集群中运行该 CronJob,查看 pod 历史记录和日志
发现原生的 CronJob 只能查看最近 3 条执行记录,想要查看更久之前的记录无奈看到,这在业务呈现问题想排查的时候就变得尤为艰难。
阿里云解决方案
阿里任务调度 SchedulerX 能够托管原生 K8s 工作,不便移植,应用 SchedulerX 托管,能够享有任务调度的个性,比方工作重跑、历史记录、日志服务、报警监控等。
- 新建 K8s 工作,工作类型抉择 K8s,资源类型抉择 Job-YAML,打印 bpi(-1)
- 通过工具来生成 cron 表达式,比方每小时第 8 分钟跑
- 调度工夫还没到,也能够手动点击“运行一次”来进行测试
- 在 K8s 集群中能够看到 Job 和 Pod 启动胜利
- 在 SchedulerX 控制台也能够看到历史执行记录
- 在 SchedulerX 控制台能够看到工作运行日志
- 在线批改工作的 YAML,打印 bpi(100)
- 不须要删除 Job,通过控制台来重跑工作
- 工作重跑胜利,且能看到新的日志
上面通过一个表格来比照两个计划的差别
个性三:加强原生 Job,反对可视化工作编排
在数据处理场景下,工作之间往往有依赖关系,比方 A 工作依赖 B 工作的实现能力开始执行。
Kubernetes 原生解决方案
以后 K8s 中支流的解决方案是应用 argo 进行工作流编排,比方定义一个 DAG 如下:
# The following workflow executes a diamond workflow
#
# A
# / \
# B C
# \ /
# D
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: dag-diamond
spec:
entrypoint: diamond
templates:
- name: diamond
dag:
tasks:
- name: A
template: echo
arguments:
parameters: [{name: message, value: A}]
- name: B
depends: "A"
template: echo
arguments:
parameters: [{name: message, value: B}]
- name: C
depends: "A"
template: echo
arguments:
parameters: [{name: message, value: C}]
- name: D
depends: "B && C"
template: echo
arguments:
parameters: [{name: message, value: D}]
- name: echo
inputs:
parameters:
- name: message
container:
image: alpine:3.7
command: [echo, "{{inputs.parameters.message}}"]
咱们看到构建这么简略的一个 DAG,就须要写这么多 YAML,如果依赖关系简单,则 YAML 就变得十分难保护。
阿里云解决方案
阿里任务调度 SchedulerX 反对通过可视化的工作流进行工作编排
- 创立一个工作流,能够导入工作,也能够在以后画布新建工作,通过拖拽构建一个工作流
- 点击运行一次,能够实时看到工作流的运行状况,不便排查工作卡在哪个环节:
- 如果有工作失败了,通过控制台查看日志
- 把工作批改正确,在工作流实例图上,原地重跑失败的节点
- 失败的工作会从新依照最新的内容执行
- 当上游都执行胜利,上游就能够继续执行了
总结
通过任务调度 SchedulerX 来调度你的 K8s 工作,可能升高学习老本,放慢开发效率,让你的工作失败可报警,出问题可排查,打造云原生可观测体系下的可视化 K8s 工作。