Kubernetes作业和部署

Question

我可以在单个配置文件/操作中运行作业和部署吗部署将在哪里等待作业完成并检查作业是否成功，以便继续部署？

Answer 1

根据您提供的信息，我相信您可以使用名为InitContainer:的Kubernetes功能来实现您的目标

Init容器与常规容器完全相同，除了：

• 初始化容器总是运行到完成
• 每个init容器都必须成功完成，然后才能启动下一个容器

如果Pod的init容器失败，Kubernetes会重复重新启动Pod，直到init容器成功。但是，如果Pod的restartPolicy为Never，则Kubernetes不会重新启动Pod。

• 我将创建一个带有busybox的initContainer来运行命令linux，以等待服务mydb运行，然后再继续部署

复制步骤：-使用initContainer创建一个部署，该部署将运行在执行部署之前需要完成的作业：

apiVersion: apps/v1
kind: Deployment
metadata:
labels:
run: my-app
name: my-app
spec:
replicas: 2
selector:
matchLabels:
run: my-app
template:
metadata:
labels:
run: my-app
spec:
restartPolicy: Always
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

该领域可以使用多种命令，您只需选择一个包含所需二进制文件(包括sequelize作业(的docker映像

• 现在让我们应用它来查看部署的状态：

$ kubectl apply -f my-app.yaml 
deployment.apps/my-app created
$ kubectl get pods
NAME                      READY   STATUS     RESTARTS   AGE
my-app-6b4fb4958f-44ds7   0/1     Init:0/1   0          4s
my-app-6b4fb4958f-s7wmr   0/1     Init:0/1   0          4s

pod保持Init:0/1状态，等待init容器的完成。-现在，让我们创建initcontainer在完成任务之前等待运行的服务：

apiVersion: v1
kind: Service
metadata:
name: mydb
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9377

• 我们将应用它并监控pod中的更改：

$ kubectl apply -f mydb-svc.yaml 
service/mydb created
$ kubectl get pods -w
NAME                      READY   STATUS     RESTARTS   AGE
my-app-6b4fb4958f-44ds7   0/1     Init:0/1   0          91s
my-app-6b4fb4958f-s7wmr   0/1     Init:0/1   0          91s
my-app-6b4fb4958f-s7wmr   0/1     PodInitializing   0          93s
my-app-6b4fb4958f-44ds7   0/1     PodInitializing   0          94s
my-app-6b4fb4958f-s7wmr   1/1     Running           0          94s
my-app-6b4fb4958f-44ds7   1/1     Running           0          95s
^C
$ kubectl get all
NAME                          READY   STATUS    RESTARTS   AGE
pod/my-app-6b4fb4958f-44ds7   1/1     Running   0          99s
pod/my-app-6b4fb4958f-s7wmr   1/1     Running   0          99s
NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/mydb         ClusterIP   10.100.106.67   <none>        80/TCP    14s
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/my-app   2/2     2            2           99s
NAME                                DESIRED   CURRENT   READY   AGE
replicaset.apps/my-app-6b4fb4958f   2         2         2       99s

如果你需要帮助将其应用到你的环境中，请告诉我。

Answer 2

尽管initContainers是该解决方案的一个可行选项，但如果您使用helm来管理和部署到集群，则还有另一个选项。

Helm具有图表挂钩，允许您在Helm图表中的其他安装发生之前运行Job。您提到，这是针对服务部署之前的数据库迁移。完成这项工作的一些示例舵配置可能是…

apiVersion: batch/v1
kind: Job
metadata:
name: api-migration-job
namespace: default
labels:
app: api-migration-job
annotations:
"helm.sh/hook": pre-install,pre-upgrade
"helm.sh/hook-weight": "-1"
"helm.sh/hook-delete-policy": before-hook-creation
spec:
template:
spec:
containers:
- name: platform-migration
...

这将运行作业直至完成，然后再进入舵图中的安装/升级阶段。你可以看到有一个"挂钩重量"变量，如果你愿意，可以订购这些挂钩。

在我看来，这是一个比init容器更优雅的解决方案，并且允许更好的控制。