From a4da42a712c63188817fe58d326f7f906fe099d7 Mon Sep 17 00:00:00 2001 From: Tom Kennedy Date: Tue, 16 Jan 2024 15:53:27 -0500 Subject: [PATCH] RFC to create a lifecycle crd Signed-off-by: Tom Kennedy --- rfcs/0000-lifecycle-crd.md | 125 +++++++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+) create mode 100644 rfcs/0000-lifecycle-crd.md diff --git a/rfcs/0000-lifecycle-crd.md b/rfcs/0000-lifecycle-crd.md new file mode 100644 index 000000000..5152e56c2 --- /dev/null +++ b/rfcs/0000-lifecycle-crd.md @@ -0,0 +1,125 @@ +`[Readable](https://github.com/your-name-or-org/kpack/blob//rfcs/0000-.md)` + +**Problem:** + +The CNB lifecycle is provided to kpack as in image reference in a configMap similar to how the completion and prepare +images are passed to the kpack controller. This means that every builder will always use the same exact lifecycle, with +no ability to specify an alternate one that may support different buildpack api or platform api versions. Due to kpack +support of windows, a custom lifecycle image with specific layers for the linux and windows binaries is required +(with a label specifying the layer diff id for each os). Because of this, a cve present in the lifecycle that has been +patched upstream, requires any user to build the kpack specific lifecycle image themselves if the kpack provided one +has not been bumped. + +**Outcome:** + +Users will be able to create a CR that references a lifecycle image. The file structure in the image must match +that of the [CNB Lifecycle image](https://hub.docker.com/r/buildpacksio/lifecycle/tags). + +``` +. +└── cnb/ + └── lifecycle/ + ├── analyzer + ├── builder + ├── detector + ├── exporter + ├── launcher + ├── lifecycle.toml + └── restorer +``` + +They will be able to use this lifecycle CR in any builder. A lifecycle will be shipped out of the box in kpack and +users will not be required to provide a lifecycle reference in the builder if they do not wish to override the default. +Users should see no difference in functionality compared to the existing kpack lifecycle if they do not choose to +provide their own lifecycle CR. + +Instead of creating custom multi-layer lifecycle images, users can create a lifecycle CR for their desired runtime (i.e. windows or arm64). +During builder creation, kpack will validate that the referenced lifecycle CR has the same OS and architecture as the base image. + +**Actions to take:** + +A new ClusterLifecycle CRD will be created. It will be very similar in structure to the ClusterStack Resource. +We will create a cluster scoped version of this resource. In the future, we may decide to create a namespaced version +as well, but that is not in scope for this RFC. The name ClusterLifecycle aligns with kpack's existing cluster scoped +resources. + +This is an example instance of the proposed CRD: +```yaml +apiVersion: kpack.io/v1alpha2 +kind: ClusterLifecycle +metadata: + name: sample-cluster-lifecycle +spec: + serviceAccountRef: + name: sample-sa + namespace: sample-namespace + image: buildpacksio/lifecycle@sha256:f4ce143ea6bbc6b5be5f4d151aba8214324adb93bbd7e3b1f43cd134ad450bf7 +``` + + +The existing lifecycle reconciler can be updated to reconcile this new CRD instead of ConfigMaps. + +A new field will be added to the ClusterBuilder/Builder resources allowing the user to provide a reference to a lifecycle CR. +This field will be optional and will default to the highest semantic version that is supported by the buildpacks in the builder and the platform. +This is similar to how we determine the platform api to use for a build. +```yaml +apiVersion: kpack.io/v1alpha2 +kind: Builder +metadata: + name: my-builder +spec: + tag: gcr.io/sample/builder + serviceAccountName: default + stack: + name: stack + kind: ClusterStack + lifecycle: + name: my-lifecycle + kind: ClusterLifecycle + order: + - group: + - id: paketo-buildpacks/java +``` + +```yaml +apiVersion: kpack.io/v1alpha2 +kind: ClusterBuilder +metadata: + name: my-cluster-builder +spec: + tag: gcr.io/sample/builder + stack: + name: bionic-stack + kind: ClusterStack + lifecycle: + name: my-lifecycle + kind: ClusterLifecycle + serviceAccountRef: + name: default + namespace: default + order: + - group: + - id: paketo-buildpacks/java +``` + +Creating a CRD for the lifecycle will allow us to do the following: +- Provide status resource that shows more information about the lifecycle such as supported api versions +- Allow users to specify a particular lifecycle for their builder, mimicking behavior that currently exists in the pack cli +- Offer a clean shift to using the upstream lifecycle image if done in conjunction with deprecation of windows support + +**Complexity:** + +The complexity of this is not that high due to its similarity with the other kpack resources. + +**Prior Art:** + +- The pack cli allows a lifecycle image to be specified when creating a build +- Adding new resources to the builder that get added to a layer has been done before in kpack + +**Alternatives:** + +We could keep the existing experience. + +**Risks:** +Exposing the user to the lifecycle can result in some confusion, but this can be mitigated by not making it a required +field on the builder and continuing to ship a lifecycle out of the box.