Tektonは2018年にGoogleがKnative Buildを発展させて発表した、KubernetesカスタムリソースでCI/CDパイプラインを記述するOSSフレームワークです。CD Foundation（Linux Foundation配下）に寄贈されており、Jenkins・JenkinsX・Spinnaker等と並ぶ業界標準パイプライン仕様の地位を確立中です。PaaS的にすべてK8sのPodとして実行されるため、CIサーバーを別途持たずクラスタ上で完結する点が特徴で、「Kubernetesネイティブな次世代CI」のリファレンス実装として、Red HatのOpenShift Pipelinesにも採用されています。
この記事の目次
- Task・Pipeline・PipelineRunの構造
- Knative Buildから始まった歩み
- 現場での主な使われ方
- Jenkins・GitHub Actionsとの違い
- まとめ
Task・Pipeline・PipelineRunの構造
Tektonのモデルは4階層です。最小単位の「Step」はDockerコンテナで実行される1つのコマンドで、それらが集まって「Task」を構成します。Taskは1つのPodとしてクラスタ上で実行され、ビルド・テスト・スキャン・デプロイなどの粒度で再利用可能な部品となります。
複数のTaskを順序付きで束ねるのが「Pipeline」で、依存関係をDAGで宣言します。実際の実行は「PipelineRun」または「TaskRun」というカスタムリソースを作成することで開始され、そのライフサイクル中にPodがspin up→実行→終了する流れになります。全てがKubernetesカスタムリソースとして宣言されるため、kubectlで状態確認・履歴参照ができ、RBACでアクセス制御を行え、Prometheusでメトリクスを収集できます。「Tekton Hub」には公式・コミュニティ製のTaskが多数登録されており、Argo CDデプロイ、Buildpacks、Trivyスキャンなどを部品として組み込めます。
Knative Buildから始まった歩み
Tektonの源流は、2018年にGoogleが発表したサーバーレスKubernetes基盤「Knative」の一部だった「Knative Build」です。サーバーレスデプロイの前段としてコンテナビルドを担うコンポーネントとして始まりました。しかしCI/CD用途の独立した発展が必要との判断から、2019年に独立プロジェクト「Tekton」として分離。Google・IBM・Red Hat・CloudBeesらが運営に参画し、ベンダーニュートラルなKubernetesネイティブパイプライン仕様を目指す体制が整いました。
2020年にはCD Foundation（Continuous Delivery Foundation）に寄贈され、Jenkins・Jenkins X・Spinnakerと共に「CDの標準化」を進める軸となります。2021年4月にv1.0としてAPIが安定化、Red HatのOpenShift Pipelinesとして商用サポート付きで提供されるほか、IBM Cloud Pak for Applications、Google Cloud Buildの内部実装の選択肢としても採用されています。Jenkins XやKratixなど後発CDツールがTektonをエンジンとして採用しており、低レイヤパイプライン仕様としての地位を固めつつあります。
現場での主な使われ方
TektonはFluxCDやArgo CDと組み合わせて「CIはTekton、CDはGitOps」という構成で使われることが多いです。GitHub・GitLabのWebhookを「Tekton Triggers」で受け取り、対応するPipelineRunを生成してビルド・テスト・イメージpushを実行します。最後にマニフェストリポジトリへPRを送り、Argo CDがその変更を検知してクラスタに反映する、というGitOps完結ワークフローが構築できます。
コンテナイメージのビルドにはKanikoやBuildpacks用のTaskが公式提供されており、Dockerデーモンを持たないクラスタ内でもセキュアにイメージを作成できます。Trivy・Cosign・SyftといったセキュリティツールのTaskも揃っており、署名・SBOM生成・スキャンをパイプラインの一部として組み込みやすいのも強みです。Red HatはこのTektonをOpenShift Pipelinesとして商用化し、エンタープライズサポート付きで提供しているため、規制業種ではOpenShift経由でのTekton利用が主流になりつつあります。
Jenkins・GitHub Actionsとの違い
Tektonの最大の特徴は「Kubernetes以外を前提にしない」設計です。Jenkinsのようにマスター・エージェント構造を持たず、CIサーバー自体を運用する必要がありません。クラスタが既にあれば、TektonをインストールするだけでCI基盤になります。一方、GitHub ActionsやGitLab CIのようなマネージドCIの楽さは無く、Kubernetesに精通した運用者がいない組織には敷居が高いという面もあります。
選定の判断軸は「既にKubernetesを運用しているか」「ベンダーロックインを避けたいか」の2点に集約されます。プラットフォームエンジニアリングを推進する大企業や、複数クラウド／オンプレ混在の環境では、Tektonの中立性とKubernetesネイティブ性が大きな魅力になります。Argo Workflowsと比較されることもありますが、Argo Workflowsが任意のジョブを並列実行する汎用ワークフローエンジンなのに対し、TektonはCI/CDパイプラインに特化した語彙（Pipeline・Task・Workspace等）を提供する点で住み分けが明確です。両方を組み合わせて使うパターンも一般的に見られます。
まとめ
Tektonは「CIをKubernetesカスタムリソースとして再設計する」という発想で生まれた、GoogleとCD Foundationが推進するベンダーニュートラルなパイプライン仕様です。GitOpsツールと組み合わせて使う次世代CI/CDの基盤として、OpenShift Pipelinesなどの形で着実に普及しています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント