Kubenews #55
2021-06-17
Comparing Ceph, LINSTOR, Mayastor, and Vitastor storage performance in Kubernetes (click here to source)
各Storageプロダクトに対して、ベンチマークを行っているもの。
DRBD:9.1.4(linstor-server v1.17.0);
Ceph:16.2.7(rook v1.8.2);
Mayastor:1.0.0;
Vitastor:0.6.12(カーネル5.13.0-27-ジェネリック);
ZFS: 0.8.3;
LVM:2.03.07
ArgoCD Best Practices You Should Know (click here to source)
1. Disallow providing an empty retryStrategy
Project: Argo Workflows
retryStrategyを用いて、ワークフローで失敗またはエラーが発生したステップを再試行する方法を指定できます。
空のretryStrategy(つまり、 retryStrategy:{})を指定すると、コンテナーは完了するまで再試行し、最終的にOOMの問題が発生します。
2. Ensure that Workflow pods are not configured to use the default service account
Project: Argo Workflows
ワークフロー内のすべてのポッドは、workflow.spec.serviceAccountNameで指定したサービスアカウントで実行されます。
省略した場合、Argoはワークフローの名前空間にあるデフォルトのサービスアカウントを使用します。
単一のコンテナにアクセスできる攻撃者は、AutomountServiceAccountTokenを使用してKubernetesを悪用でき、万が一、AutomountServiceAccountTokenのオプションが無効になった場合、Argoが使用するデフォルトのサービスアカウントには権限がなく、ワークフローは失敗します。
適切な役割を持つ専用のユーザー管理サービスアカウントを作成することをお勧めします。
Ensure label part-of: argocd exists for ConfigMaps
Project: Argo CD
app.kubernetes.io/part-of:argocdというラベルを使用してConfigMapリソースに注釈を付けることが重要です。
何かしら設定を反映する場合に、app.kubernetes.io/part-of:argocdというラベルが抜けると、 ArgoCDはそれらを使用できません。
4. Disable with DAG to set FailFast=false
Project: Argo Workflows
ワークフローで一連のステップを指定する代わりに、各タスクの依存関係を指定することにより、ワークフローをDAG(有向非巡回グラフ)として定義できます。
DAGロジックには、フェイルファスト機能が組み込まれています。
これは、DAGノードの1つに障害が発生したことを検出するとすぐに、新しいステップのスケジューリングを停止すし、すべてのDAGノードが完了するまで待機してから、DAG自体に障害が発生します。
FailFastフラグのデフォルトはtrueになっており、falseに設定すると、DAG内のブランチの失敗した結果に関係なく、DAGはDAGのすべてのブランチを(成功または失敗のいずれかで)完了するまで実行できます。
5. Ensure Rollout pause step has a configured duration
Project: Argo Rollouts
Argo Rolloutsではロールアウトごとにステップのリストを定義でき、各ステップには、 setWeight(新しいRevisionに指定した割合のトラフィックを流すかを指定する)とpause(待機時間の指定)の2つのフィールドのいずれかを含めることができます 。
spec: replicas: 5 strategy: canary: steps: - setWeight: 20 - pause: {} - setWeight: 60 - pause: {duration: 10}
pauseステップに入ると、PauseCondition構造体が.status.PauseConditionsフィールドに追加されます。
pause構造体内のdurationフィールドが設定されている場合、durationフィールドの値を待機するまで、ロールアウトは次のステップに進みません。
ただし、durationフィールドが省略されている場合、追加された一時停止条件が削除されるまで、ロールアウトは無期限に待機する可能性があります。
6. Specify Rollout’s revisionHistoryLimit
Project: Argo Rollouts
.spec.revisionHistoryLimitは、ロールバックを許可するために保持する必要がある古いReplicaSetの数を示すオプションのフィールドです。
デフォルトでは、10個の古いReplicaSetが保持されます。
このフィールドをゼロに設定すると、新しいdeploymentは、そのリビジョン履歴がクリーンアップされるため、元に戻すことはできません。
7. Set scaleDownDelaySeconds to 30s to ensure IP table propagation across the nodes in a cluster
Project: Argo Rollouts
ロールアウトによってサービスのセレクターが変更されると(kubectl argo rollouts promote など)、すべてのノードがIPテーブルを更新して、古いポッドではなく新しいポッドにトラフィックを送信するようになりますが、その際に伝播遅延が発生します。
この遅延中にノードがまだ更新されていない場合、トラフィックは古いポッドに転送されます。
古いポッドを強制終了したノードにパケットが送信されないようにするために、ロールアウトはscaleDownDelaySecondsフィールドを使用してノードに十分な時間を与えることができます。
クラスタ内のノード間でIPテーブルが確実に伝播するように、scaleDownDelaySecondsを最低30秒に設定することをお勧めします。
30秒の理由としては、termination grace periodのデフォルトが30秒だからです。
8. Ensure retry on both Error and TransientError
Project: Argo Workflows
ワークフローのステップを再試行するためのコントロールを提供するrestartStrategyのフィールドの1つであるretryPolicyは、再試行されるNodePhaseステータスのポリシーを定義します。(DAGノードのノード(workflowの実行単位)のことかな?)
これに対する値としては、Always, OnError, OnTransientErrorの3つがある。
retryPolicy=Always
は過剰である。
retryPolicy=OnError
は、ノードの消失やポッドの削除など、いくつかのシステムレベルのエラーを処理します。
ただし、ポッドのgraceful termination中に、kubeletは終了したポッドにFailed
ステータスとShutdown reason
を割り当ててしまい、「エラー」ではなく「失敗」のノードステータスになるため、プリエンプションは再試行されません。
preemption failure messageとして分類されるErrorを対処するには、retryPolicy=OnTransientError
とする必要がある。
おすすめは、retryPolicy: "Always" にし、'lastRetry.status == "Error" or (lastRetry.status == "Failed" and asInt(lastRetry.exitCode) not in [0])' を設定することです。
9. Ensure progressDeadlineAbort set to true, especially if progressDeadlineSeconds has been set
Project: Argo Rollouts
ユーザーはprogressDeadlineSecondsを設定できます。
これは、更新中にロールアウトが失敗したと見なされるまでの最大時間を秒単位で示します。
ロールアウトポッドがエラー状態(イメージのプルバックなど)でスタックした場合、Progress Deadlinを超えた後、ロールアウトはdegradeになるが、エラーとなっているレプリカセット/ポッドは縮小されません。
ロールアウトを中止するには、 progressDeadlineSecondsとprogressDeadlineAbort:trueの両方を設定する必要があります。
10. Ensure custom resources match the namespace of the ArgoCD instance
Project: Argo CD
すべてのApplicationマニフェストとAppProjectマニフェストが同じmetadata.namespaceと一致する必要があります。
すべてのArgoCDリソースがArgoCDインスタンスの名前空間と一致することを確認するだけでなく、argocd名前空間を使用することをお勧めします。
Run Kubernetes Tests with SoapUI and Testkube (click here to source)
TestKubeについて。
Testkubeは、Kubernetesネイティブのテストフレームワークで、Kubernetesクラスターで直接テストを実行し、結果を一元化されたスペースに保存できます。
SoapUIを使用したKubernetesテスト
SoapUIは「方法」を簡素化し、Testkubeは「where」に対する答えを提供します。
これら2つのツールを使用して作成されたテストは、再現性があり、読みやすく、構造化されています。
SoapUIは、複数のテストタイプを持っています。
- Functional Tests
- Load Tests
- Security Tests
- Mocking