KubeArchive adoption discussion

[vdemeester]

Background

KubeArchive was presented at a Tekton working group meeting in December
2025. This discussion is to gather community input on whether and how
the Tekton project should adopt or integrate with KubeArchive.

What is KubeArchive?

KubeArchive is a
Kubernetes utility designed to:

• Store Kubernetes resources off of the Kubernetes cluster
• Allow users to delete cluster resources without losing their
  information
• Provide an API for retrieving and inspecting stored resources

Key Use Cases

• Tracking Job success rates over time
• Preserving build system resource information from platforms like
  Shipwright and Tekton
• Managing one-shot Kubernetes operations by archiving resources that
  would otherwise be deleted for performance or storage reasons

Relationship to Tekton

KubeArchive was inspired by Tekton Results and addresses similar use
cases around preserving pipeline run data and build artifacts after the
cluster resources are deleted.

Options for Adoption

The community could consider several approaches:

1. Official Recommendation

• Recommend KubeArchive as the archival solution for Tekton
• Add it to official documentation as a recommended component
• Maintain it as a separate project but with close collaboration

2. Native Integration

• Build KubeArchive support directly into Tekton components
• Potentially move the project under the tektoncd{.verbatim}
  organization
• Deeper integration with Pipeline, Triggers, etc.

3. Documentation & Examples

• Provide examples and documentation for using KubeArchive with Tekton
• Keep projects independent but ensure good interoperability
• Create reference implementations

4. Relationship with Tekton Results

• Clarify how KubeArchive relates to Tekton Results
• Potential migration path or coexistence strategy
• Consider if KubeArchive should complement, replace, or run alongside
  Tekton Results

5. No Action

• Keep as community-maintained option
• No official endorsement or integration
• Users can choose to use it independently

Questions for the Community

1. Do we see value in adopting KubeArchive for the Tekton
   ecosystem?
   • What specific problems would this solve?
   • What are the benefits over current solutions (e.g., Tekton
     Results)?
2. What level of integration makes sense?
   • Should this be an official Tekton project?
   • Should it remain independent with good interoperability?
   • Should it replace or complement existing solutions?
3. What are the maintenance and support implications?
   • Who would maintain it?
   • What's the support burden on the Tekton community?
   • Are there sufficient resources for this adoption?
4. Technical considerations:
   • How does it fit with existing Tekton architecture?
   • What changes would be needed in Tekton components?
   • What's the migration story for existing users?
5. User impact:
   • How does this benefit Tekton users?
   • What's the adoption/migration path?
   • Are there breaking changes or compatibility concerns?

Next Steps

Based on community feedback, we should:

1. Gather input from maintainers, contributors, and users
2. Evaluate technical feasibility and alignment with Tekton's roadmap
3. Define clear success criteria for adoption
4. Create a more detailed proposal (potentially a TEP) if there's
   consensus to move forward

References

• KubeArchive GitHub
  Repository
• Tekton Results
• Working Group Presentation (December 2025) - [link to presentation
  if available]

Call for Feedback

Please share your thoughts, concerns, and questions. This is an
important decision for the Tekton community, and we want to ensure all
perspectives are considered.

---

cc @tektoncd/core-maintainers for visibility

[enarha]

Hello. One of the Tekton Results maintainers here. And I'm definitely not a KubeArchive expert, so please excuse any inadvertent inaccuracies in the details below.

I want to touch on the comparison with Tekton Results and why one should not be a replacement solution of the other. They simply have different focus and purpose. KubeArchive is generic solution and supports any Kubernetes objects equally (more or less). It is not limited to a certain types of resources and one can use it to store any Kubernetes resource.

Tekton Results specializes in Tekton execution objects and has deeper insight of those objects, beyond the generic object properties (name, labels, annotations). That is what allows Results more flexible policies for storing and retaining objects out of the box. For example one can decide not to store “canceled” pipelines. Or have different retention policies for "successful" and "failed" PipelineRuns.

Being focused on specific types of objects and sharing code with Tekton Pipelines allows seamless version management (PipelineRun v1beta1, v1, v2, etc.) and that is done from a single place. The existing data is always transformed by the service in a compatible way, starting few the newest object version and going backwards. For a user, Pipeline execution is a Pipeline execution regardless of PipelineRun version used. It abstracts those details from the user. With a generic solution, each client should track and manage the different versions of the stored objects, by either writing transformers or managing the different versions separately.

For Tekton Results we have already planed to extend it beyond the Tekton execution objects and capture both the context and artifacts of an execution. Yet, a PipelineRun and a TaskRun will remain the primary objects and used as references to those additional objects. This will allow us to evolve and expand the project while also keeping our primary focus on Tekton.

With that said, I believe both projects have their specific use cases. If users mostly care about Tekton objects and prefer the extra flexibility of storing and retention policies and seamless transition of Tekton objects with backward compatibility, then Tekton Results is the right service for them. If they prefer flat support for any type of Kubernetes object instead, then KubeArchive is the right solution for them.

On a side note, I was not able to attend the Tekton working group call when KubeArchive was presented, but I disagree with the description "Next generation of Tekton Results". As I tried to explain my point above, those are two solutions with different focus, strengths and weaknesses.

[adambkaplan]

Chiming in as an effective "emeritus maintainer" of Tekton Results and the "parent" of KubeArchive.

When I designed KubeArchive 3+ years ago, it was a generalized form Tekton Results. Several pieces of the architecture tried to capture "lessons learned" at that time:

• Use an event-driven model instead of Kubernetes watches (ultimately KNative Eventing).
• Provide an API that is "kubectl compatible" (i.e. stick to the Kubernetes REST API forms).
• Use a data model that is Kubernetes-aware. Tekton Results provides an API and DB model that hides the Kubernetes implementation details (Result/Record).
• Separate data storage concerns from presentation concerns.
  • In KubeArchive, a dedicated Sink component is responsible for writing records to the database. Presentation is handled by a separate API server that only reads data.
  • In Tekton Results, the Watcher component sends requests to the Result API server, which is also responsible for presenting data.

Both projects have evolved, and that is a good thing! And @enarha is right - at present they do have different focus. However some of the concerns around Tekton specifics are not necessarily true, which I will address below:

That is what allows Results more flexible policies for storing and retaining objects out of the box. For example one can decide not to store “canceled” pipelines. Or have different retention policies for "successful" and "failed" PipelineRuns.

Kubearchive uses CEL expressions to set policies on when an object is archived and/or deleted (on-cluster) - such a configuration is feasible, though Tekton Results can provide a stronger developer experience in this regard.

Kubearchive currently doesn't have a mechanism for controlling long-term data retention, however I do not see a strong reason why this can't be implemented in some form. Moreover, this retention can be defined through Kubearchive CRDs, versus the ConfigMap-driven approach of the retention policy agent.

Being focused on specific types of objects and sharing code with Tekton Pipelines allows seamless version management (PipelineRun v1beta1, v1, v2, etc.) and that is done from a single place.

I agree this is a key differentiator for Tekton Results, and is something that would be exceptionally difficult for KubeArchive to provide in a generic fashion. Multi-version CRDs would need some kind of "transformer" component that can be plugged in, such as a conversion webhook. When I introduced KubeArchive to k8s apimachinery maintainers, they were very clear up front that the project should ignore CRD API conversion.

For Tekton Results we have already planed to extend it beyond the Tekton execution objects and capture both the context and artifacts of an execution.

I don't see this documented as a feature request. Is this written down somewhere? I am curious what is meant by "context" and "artifacts".

[enarha]

Apologies for the late response. I was trying to upstream those ideas I have about extending the Tekton Results functionality, but it's a busy time and I'm still talking to users to understand and define those requirements better. I'll try to summarize here.
First and foremost, we keep the PipelineRun/TaskRun/(and soon CustomRun) first class citizens of the system. I think also about keeping the same data structures results/uid/records/uid. While a bit cumbersome, it handles very well those repeating names (unique on the cluster, repeating in the DB) in an "immutable" way (IIUC KubeArchive will add to the existing records while trying to keep compatibility with the k8s API). It also represents very well the relationship between PipelineRun and TaskRuns and related data (events and logs). I'm looking into 3 vectors:

1. Objects related to triggering of a PipelineRun/TaskRun e.g. EventListener and Trigger come to mind, but there could be more.
2. PipelineRun/TaskRun execution context e.g. ConfigMap/ServiceAccount/maybe even some heavily sanitized secrets (not a fan, but if there is a demand we can provide that), related resources (if a TaskRun create resource, we treat it like a child and store it).
3. Produced artifacts - references to OCI images, SBOM, files pushed to storage etc. While not strictly k8s objects, those are kind of similar to storing logs and events in Results and are useful for debugging or providing more data to the user.

For each of the above we can have extra configuration provided by the user where we store really any type of object at the beginning, during or after execution of a pipelinerun/taskrun. This avoids adding listeners for those objects, while still provides the flexibility to target any type of object. Still, those objects will be stored under the same data structure and become records for the respective execution. The primary goal is observability and debugging with a touch of security e.g. who or what authorized the PipelineRun and the exact state of their permissions at that moment.

HTH. I'll probably use it as a basis to start a separate discussion instead of trying to cook it all myself and propose a TEP. Thanks for asking that.

[anithapriyanatarajan]

Does Kubearchive expose any API to query logs specific to an Archived PR/TR ? If so please share some references cc: @hectormartinezdev

[enarha]

The reference says:

When a Pod has multiple containers, a single container is selected in the following order of preference:
container parameter
kubectl.kubernetes.io/default-container Pod annotation
First container listed in the Pod definition

In a Tekton Pipeline, each Task creates a pod and each Step in a Task creates a separate container. If I reference a PipelineRun object, will I get the logs for each step for a task or only for a single step?

[maruiz93]

With the current implementation you would only get the logs from the last task, but we could take a look to modify the logic and provide other options.

[anithapriyanatarajan]

@maruiz93 - Could you please reconfirm this, would the API for logs return the logs for last taskrun in the given PipelineRun or for a container within the last taskRun only?.

[maruiz93]

The current API just return the logs of one container.

You can select the container by providing the container_name, if the container is not provided, one will be chosen (same as with kubectl logs

Now, if you are querying the logs from a PipelineRun. The first step is to pick a TaskRun, then pick a Pod (here there is no "pick" actually as a TaskRun translates into only one Pod) and then pick a container (if none is provided).

So if you do this:

/apis/tekton.dev/v1/namespaces/my-ns/pipelineruns/my-plr/log you will get the logs of one step in the last TaskRun from the PipelineRun my-plr in the namespace my-ns. The step (i.e. the container) will be picked by kubearchive.

if you do this:

/apis/batch/v1/namespaces/default/cronjobs/cleanup-tasks/log?container=first-step you will get the logs of the first-step container in the last TaskRun from the PipelineRun my-plr in the namespace my-ns.

Note that with kubectl logs deployment/my-deployment the logic followed is the same in the case of several pods and several containers per pod, see:

❯ kubectl logs deployment/apiserver -n openshift-apiserver --tail 3
Found 3 pods, using pod/apiserver-12345789123-vs5kp
Defaulted container "openshift-apiserver" out of: openshift-apiserver, openshift-apiserver-check-endpoints, fix-audit-permissions (init)

[AlanGreene]

a TaskRun translates into only one Pod

For simple cases yes. However, when TaskRun retries are enabled in a Pipeline for example, each attempt results in a separate Pod, these are recorded in TaskRun.status.retriesStatus.

[ggallen]

Kubearchive currently doesn't have a mechanism for controlling long-term data retention, however I do not see a strong reason why this can't be implemented in some form. Moreover, this retention can be defined through Kubearchive CRDs, versus the ConfigMap-driven approach of the retention policy agent.

I'm not sure why KubeArchive would want to implement this anyway. This is a database function, and by design KubeArchive isn't in the database business. It's database agnostic.

To me this is the job of a database admin, similar to backups.

[anithapriyanatarajan]

@vdemeester Please find below the responses based on my assessment:

Questions for the Community

Do we see value in adopting KubeArchive for the Tekton ecosystem

Yes. KubeArchive demonstrates how Tekton is a flexible CI/CD FRAMEWORK and allows integration with Kubernetes-native solutions. However, current limitation of returning logs across all taskruns of a given pipelierun must be addressed first.

What specific problems would this solve?

Predominantly PipelineRun troubleshooting and SRE teams can make use of this

What are the benefits over current solutions (e.g., TektonResults)?

In its current form, the configuration options are more intuitive and user friendly in Kubearchive. There is scope for improvement in Tekton Results.

What level of integration makes sense?
Should this be an official Tekton project?
Should it remain independent with good interoperability?
What are the maintenance and support implications?
Who would maintain it?
What's the support burden on the Tekton community?
Are there sufficient resources for this adoption?
Technical considerations:
How does it fit with existing Tekton architecture?

To all these questions - I believe, Kubearchive is not using knative/pkg for controller and reconciliation of its CRDs rather is it leveraging sigs.k8s.io/controller-runtime and hence this becomes naturally extensible to a multilcuster ecosystem with https://github.com/kubernetes-sigs/multicluster-runtime so I would recommend this to be managed as an independent k8s archival solution and propose this as wider OpenSource project to the Observability and Analysis landscape of CNCF that could benefit wider ecosystem of projects like Tekton that are based on CRDs and CRs.

While Tekton Results would offers a good log aggregation mechanism across all TaskRuns and the enhancements could closely follow the features implemented in Tekton whereas Kubearchive can address wider scope and not focus on granular needs like filter types, seraching based on Tekton reaource labels, etc.,

Should it replace or complement existing solutions?

COMPLEMENT, not replace. They serve different purposes:
Tekton Results - purpose-built for Tekton with domain-specific intelligence
Kubearchive - generic archival for any K8s resource, benefits the wider CNCF ecosystem

Users with pure Tekton can leverage Tekton Results. Users running multi-project environments (Tekton + Argo + Shipwright) benefit from Kubearchive's unified archival.

What changes would be needed in Tekton components?

I would recommend to accommodate this as an official pluggable log solution but managed independently to address wider scope but ensures interoperatbility always. This aspect should be taken care by Kubearchive. we may have to document this and look out for ways to update the Tekton Operator. (But before this we need confirmation on the open Query if Kubearchive can return the logs of all TaskRuns linked to a PipelineRun or is it just the last TaskRun

cc: @maruiz93

[enarha]

Not direct as far as I recall, but there was a separate discussion about Results handling both live and stored data and I think there we agreed it would be a nice way to integrate with Dashboard through a single interface.

[enarha]

| In its current form, the configuration options are more intuitive and user friendly in Kubearchive. There is scope for improvement in Tekton Results.
@anithapriyanatarajan can you please elaborate more on that? One thing we have already discussed in Results is unifying the way we configure the api and the watcher (e.g. switch the watcher configuration to a configmap). What else do you see as a point of improvement?

[AlanGreene]

@anithapriyanatarajan some of the previous discussions about Results / Dashboard integration: tektoncd/results#82
Unfortunately the rest is likely lost to Slack history.

[anithapriyanatarajan]

@AlanGreene @enarha - Thankyou for referring to the Issue. How shall we prioritize this? Can this be accommodated in Dashboard roadmap and should we be planning for focused working group discussions around this?

[enarha]

@anithapriyanatarajan IMO the next logical step is to submit a TEP and I'll be happy to do so once we have clarity around Results long term. Discussions could center around that TEP and at the dedicated community calls. If we identify a need for focused working group call, I'm sure we'll find a way to accommodate one.

[khrm]

I feel even after the adoption of KubeArchive, we will need a Tekton Results v2 to address some Tekton-specific APIs which leverage the KubeArchive DB. Logging can be offloaded to kubearchive, but for better results, I think we need it in v2 Tekton Results.

[enarha]

Why do we need that extra layer for handling the logs? Results handles the logs in the same or similar way, isn't it? So even if some optimization is possible, why not simply implement it in Results?

[aThorp96]

It's worth noting as well that Results has not yet released v1, so there is no need for a v2 even. I think it's reasonable, or even positive, for breaking API changes to be introduced in the v1 release, especially when they're addressing scalability and design issues identified in v0

[enarha]

@aThorp96 I think the meaning of Tekton Results v2 is "the next iteration/version" and not specifically the api version. And you are right of course, the next api verison will be v1 and that's where the breaking changes will go. We have already planned that version for later in the year, including removal of the old (direct) logging functionality and configuration options cleanup and standardization.

[vdemeester]

I want to clearly state my position as a Tekton maintainer:
KubeArchive should complement Tekton Results, not replace it.

Why Results is the right foundation for Tekton

When a user's pipeline fails at 2am, they need to quickly find that
PipelineRun, see all its TaskRun logs, and understand what happened.
Results is built for exactly that — it understands Tekton's domain:
PipelineRun↔TaskRun relationships, execution status, step/task
hierarchy. This enables status-aware retention, transparent CRD version
management (v1beta1→v1→v2), and unified log retrieval across a full
PipelineRun.

As @adambkaplan acknowledged, version management would be
"exceptionally difficult for KubeArchive to provide in a generic
fashion." And as this thread revealed, KubeArchive currently can't even
return logs across all TaskRuns of a PipelineRun — a fundamental Tekton
use case.

A generic archival tool treats a PipelineRun as just another Kubernetes
object. For Tekton users, it is much more than that.

Results has room to grow

There are clear areas where Results can evolve:

• Extension points for Tekton-related objects — storing and linking
  execution context (triggers, configmaps, produced artifacts) to their
  parent PipelineRun/TaskRun, as @enarha outlined above.
• A Kubernetes-compatible REST API — in addition to the current
  gRPC/protobuf API, providing a kubectl-friendly interface is
  something we should discuss on the Results roadmap. This addresses
  one of KubeArchive's design advantages without giving up Tekton
  domain awareness.

These are investments in purpose-built Tekton tooling, not reinventing
a generic archiver.

KubeArchive is valuable — but doesn't belong in tektoncd

KubeArchive solves a real problem: generic Kubernetes resource archival.
Users running mixed environments (Tekton + Argo + Shipwright) benefit
from a unified archival layer. But being generic is exactly why it
doesn't fit under the tektoncd org — its scope and audience are broader
than Tekton. It would be a better fit for the CNCF Observability
landscape, as @anithapriyanatarajan suggested.

The risk of replacing Results

There are existing users depending on Tekton Results today. Replacing
it with KubeArchive would mean a migration burden for those users,
maintainer bandwidth split learning a different codebase
(controller-runtime vs knative/pkg), and Tekton-specific features
having to be rebuilt on top of a generic foundation. That's a real cost
with no clear gain for Tekton users.

Recommendation

1. Keep investing in Tekton Results as Tekton's native archival and
   observability solution, with the extensions above on its roadmap.
2. Document KubeArchive as a complementary option for generic K8s
   archival needs.
3. Do not adopt KubeArchive into tektoncd — it's a generic tool
   with a broader scope that belongs in its own org.

I'd welcome other perspectives, but this is my recommendation.

[enarha]

I agree on @vdemeester 's points and second his recommendation.

[adambkaplan]

If there's one thing I'd like to ask "is this in scope for Tekton Results?" is to add support for archiving owner references of Tekton objects. Shipwright would benefit from this as its BuildRun controller currently sets owner references for generated TaskRuns (and soon PipelineRuns). cc @sayan-biswas.

Konflux would likewise benefit with its Release objects archived.

[enarha]

@adambkaplan this totally makes sense IMO. This is exactly the use cases we are looking for. @aThorp96 FYI.

[vdemeester]

Agreed @enarha @adambkaplan it makes total sense to me as well.

[adambkaplan]

It's worth pointing out that Argo Workflows has the exact same problem and implemented their own solution (which precedes Tekton Results): Workflow Archive. I think this bolsters the argument for Kubearchive to live as an independent project.

Any plan for "replacement" would likewise have substantial migration impact, as both projects have enormous end-user communities/adopters.

[enarha]

Indeed. The same argument remains though, do projects need a projects specific solution (requires extra effort, but it's specialized and supported by them) or is a generic solution good for them. But this IMO should be the direction which KubeArchive should take. Like when we used to log directly from the Tekton Results and eventually offloaded that functionality to Vector and other logging solutions.

[waveywaves]

Both Kubearchive and Results are more complementary to each other than at odds as we have already established. If both tools architecturally are going to move in the same direction and look the same, one generic and one specific, solving the same/similar problems, then it makes sense for Kubearchive to use Tekton Results packages and help improve them without reinventing the wheel, bolstering collaboration, as both tools are also used in the same context. Once Kubearchive is finally at par with Tekton Results AND can be extensible to do what Results does: we could reevaluate whether maintaining both is the right investment for the community. But from the discussion thread above the main blockers seem to be the resource relationship awareness, log retrieval and aggregation, bundling conversion logic, then query helpers, log backends per domain. It's a long serial chain, which Kubearchive will also have to implement, which can be reused from Results.

[adambkaplan]

If both tools architecturally are going to move in the same direction and look the same, one generic and one specific, solving the same/similar problems, then it makes sense for Kubearchive to use Tekton Results packages and help improve them without reinventing the wheel, bolstering collaboration, as both tools are also used in the same context.

I like this idea, but reversing the relationship direction. The spirit is the same (common libraries for common problems).

This would be a substantial evolution/pivot of the Kubearchive project from being a singular deployment to a library that is validated by a reference implementation. Projects like Tekton Results and Argo Workflows Archive would be free to pick and choose bits as they please and add their own extensions on top.

[adambkaplan]

Here's a proof of concept demonstrating Tekton Results using Kubearchive as a library: tektoncd/results#1265.

With remarkably little code, Tekton Results is able to serve the Kubernetes REST API that Kubearchive provides from the same underlying storage.