Architecting Workflows For Reliability
読み返す用
What About A Workflow?
デフォルトでは、ワークフローポッドが削除されると、タスクは失敗としてマークされ、ワークフローは失敗します。これは大きな問題になる可能性があります。たとえば：
タスクは非常に長い間実行されていました。 例：Sparkジョブ。
タスクはコストがかかる可能性があります。例：高価なGPUをたくさん使用している。
ワークフローを再試行することはできますが、別の中断が二度と起こらないという保証はありません。
Retry Strategy
ポッドの削除に対する最初の防御策は、再試行戦略を使用することです。ここで最も重要な詳細は、タスクが「再試行可能」である必要があることです。つまり、タスクが中断された場合でも、正常に再実行できるということです。多くの場合、これはべき等であることを意味します。つまり、再度実行しても、結果はまったく同じということです。
code:yaml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: retry-container-
spec:
entrypoint: retry-container
templates:
- name: retry-container
retryStrategy:
limit: "10"
container:
image: python:alpine3.6
# fail with a 66% probability
args: ["import random; import sys; exit_code = random.choice(0, 1, 1); sys.exit(exit_code)"] 多くのチームはactiveDeadlineSecondsを使用して、何か問題が発生した場合にタスクがすぐに失敗するようにします。 したがって、howretryStrategy、activeDeadlineSeconds、およびbackoffが相互作用することを考えてください。
これは、タスクが10m未満の短期間の場合、さらに効果的です。 大きなタスクを小さなタスクに分割すると、ポッド削除の中断による影響は小さくなります。
もう1つのベストプラクティスは、作業の回避です。つまり、タスクを再試行した場合に、より速く完了することができるようにタスクを記述します。
リソーステンプレートを使用する場合は、実際に再試行を使用できるため、リソースを作成する基になるポッドが削除された場合、が再試行されると、同じリソースを作成しようとします。
リソースに決定論的な名前が付いていることを確認してください（例：my-resource-{{workflow.name}}）。
"create"アクションの代わりに"apply"アクションを使用します。
Reducing The Chance Of Pod Deletion
最初に試すことができるツールは、PodDisruptionBudgetです。これにより、クラスターのドレインなどの自発的な中断に耐えることができます。
code:yaml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: default-pdb-support-
spec:
entrypoint: pdbcreate
serviceAccountName: default
podDisruptionBudget:
minAvailable: "9999" # Provide arbitrary big number if you don't know how many pods the workflow creates
templates:
- name: pdbcreate
container:
image: alpine:latest
ただし、これではハードウェア障害などの不本意な中断を防ぐことはできません。
ワークフローのコストを最適化して、使用するリソースを減らすこともできます。これにより、リソースが不足しているためにポッドが削除される可能性が低くなります。また、ワークフローのコストも低くなります。
間もなく、Kubecostと共同でブログ投稿を行い、これについてさらに詳しく説明します。
Summary
ワークフローは小さなKubernetesアプリのようなものであり、これを念頭に置くことで、Kubernetesアプリが受ける可能性のある種類の中断に対して堅牢になるようにワークフローを設計できます。再試行戦略、作業回避、ポッド中断バジェットを使用することで、タスク自体が失敗した場合にのみ失敗する堅牢なワークフローを作成できます。