TektonのWorkspace機能

Tekton Pipelinesはk8sコンテナ上で動作するCIワークフローであるため、データは揮発します。
順序については Tekton Pipelinesの制御フローで解説していますが、コンテナ間でディレクトリ内のフラットファイルを共有するには Workspaces機能を利用します。

Workspaceはtaskで利用を宣言しpipelinerunやtaskrunから供給する、という構造になっています。
ストレージの種類はkubernetesが提供するストレージ機能を利用でき、pipelinerunのspec.workspacesに指定します。

Task内のワークスペース

単一Taskは複数のstepsを定義でき、各stepは個別のコンテナが起動します。
このsteps間で共有するWorkspaceにはemptyDirを利用できます。

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
spec:
  workspaces:
  - name: workdir
    emptyDir: {}

emptyDirはオプションが乏しいため、使い方に注意はとくにありません。
ただし、emptyDirが後続のタスクでクリアされていない事象に遭遇することがあります。

この場合、Tektonの機能ではなくkubernetes標準のvolumesでemptyDirをセットアップすると安定します。

Pipeline内の複数タスク間でもWorkspaceを利用してファイル共有できます。
ただし、この構成の場合にはemptyDirではなく、PersistentVolumeを利用する必要があります。emptyDirのワークスペースを用いると、後続タスクから参照した際に空になっています。

よって、この構成では公式のガイドに沿ってPersistentVolumeClaimのワークスペースを指定します。
PersistentVolumeはwrite可能なコンテナを1つに限定しているケースが多いため、sidecarなどでフィットしない構成もあります。

PersistentVolumeは、多くの場合、各クラウドプロバイダのディスクサービスを要求する挙動となるでしょう。サーバーノードの空き容量を利用するような挙動ではないことには注意が必要です。

また、PersistentVolumeClaimのワークスペースがクリアされていない事象に遭遇することがあります。
この場合、良い対処法はないためrmするかTask内のワークスペース構成に変更することで安定させるしかないでしょう。

ワークスペースを利用すると、単機能のコンテナを定義しやすくなりTaskの共通化に効果的ではありますが、動作安定とのトレードオフがあるため、検証にもとづいて構成を決定する必要があります。

ここまでの用途とは異なり、設定をreadonlyで供給する目的で、ConfigMapやSecretもworkspace経由で指定できます。
これらは各タスクのvolumesにも定義できますが、設定変更により異なる用途に活用できるケースではWorkspace経由の供給が意味を持ちます。