Argo-workflow で 300Parallels を実行する
Production環境における、Argo wfのチューニングについてまとめました。
Argo wfについて、紹介はたくさんありますが、Production環境において「チューニングはどうするか」について、情報が多くありません。
そこで、本記事は、チューニングの知識を紹介します。
プロローグ
Argo wfは、「Getting Started」の設定では、多重度が大きいと
- 一部のプロセスが
pod deleted
になる - UIが固まってしまう
ことがあります。
チューニング
チューニング方法を紹介します。
argoprojのGitHubには、ひっそりと記載されていますが、見落としてしまいます。
本家のマニュアルは、下記のとおりです。
Vertically Scaling
You can scale the controller vertically:
If you have workflows with many steps, increase--pod-workers
.
If you have many workflows, increase--workflow-workers
.
Increase both--qps
and--burst
.
You will need to increase the controller's memory and CPU.
「pod deleted」を防ぐ
deployment
の workflow-controller
をチューニングします。
これらの設定は、Argo wfのHelm Chartsを参照すると、設定方法が分かります。
{{- with .Values.controller.workflowWorkers }}
- "--workflow-workers"
- {{ . | quote }}
{{- end }}
{{- if .Values.controller.podWorkers }}
- "--pod-workers"
- {{ . | quote }}
{{- end }}
kubectlでinstallする場合、editすることで、変更することができます。viの要領で。
$ kubectl edit deployment workflow-controller -n argo
spec:
progressDeadlineSeconds: 600
replicas: 3 # 1から3に変更する
revisionHistoryLimit: 10
selector:
matchLabels:
app: workflow-controller
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: workflow-controller
spec:
containers:
- args:
- --configmap
- workflow-controller-configmap
- --executor-image
- argoproj/argoexec:v2.4.3
- --workflow-workers # ここから
- "32"
- --pod-workers
- "32" # ここまで追加する
command:
- workflow-controller
image: argoproj/workflow-controller:v2.4.3
imagePullPolicy: IfNotPresent
name: workflow-controller
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: argo
serviceAccountName: argo
terminationGracePeriodSeconds: 30
UIが固まる
argo-server
をチューニングします。 deployment
のreplicasをeditします。
$ kubectl edit deployment argo-server -n argo
spec:
progressDeadlineSeconds: 600
replicas: 3 # ここを変える
revisionHistoryLimit: 10
selector:
matchLabels:
app: argo-server
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: argo-server
spec:
containers:
- args:
- server
image: argoproj/argocli:v2.9.3
imagePullPolicy: IfNotPresent
name: argo-server
ports:
- containerPort: 2746
name: web
protocol: TCP
readinessProbe:
failureThreshold: 3
httpGet:
path: /
port: 2746
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 20
successThreshold: 1
timeoutSeconds: 1
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
nodeSelector:
kubernetes.io/os: linux
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: argo-server
serviceAccountName: argo-server
terminationGracePeriodSeconds: 30
皆さんの参考になれば幸いです。
Author And Source
この問題について(Argo-workflow で 300Parallels を実行する), 我々は、より多くの情報をここで見つけました https://qiita.com/danny-yamamoto/items/e3d62c380db86334d9d2著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .