A stack resource is the specification for a cloud native buildpacks stack used during build and in the resulting app image.
The stack will be referenced by a builder resource.
At this time only a Cluster scoped ClusterStack is available.
Corresponding kp cli command docs here.
apiVersion: kpack.io/v1alpha2
kind: ClusterStack
metadata:
name: base
spec:
id: "io.buildpacks.stacks.jammy"
buildImage:
image: "paketobuildpacks/build-jammy-base"
runImage:
image: "paketobuildpacks/run-jammy-base"id: The 'id' of the stackbuildImage.image: The build image of stack.runImage.image: The run image of stack.
To use stack images from a private registry, you have to add a serviceAccountRef referencing a serviceaccount with the secrets needed to pull from this registry.
spec:
serviceAccountRef:
name: private
namespace: privateserviceAccountRef: An object reference to a service account in any namespace. The object reference must containnameandnamespace.
The stack resource will not poll for updates. A CI/CD tool is needed to update the resource with new digests when new stack images are available.
The pack CLI command: pack stack suggest will display a list of recommended stacks that can be used. We recommend starting with the io.buildpacks.stacks.jammy base stack.
kpack builds on the architecture of the stack's images. To build for arm64, both the buildImage and runImage must provide a linux/arm64 variant. The io.buildpacks.stacks.jammy stack images (e.g. paketobuildpacks/build-jammy-base and paketobuildpacks/run-jammy-base) are published as multi-arch images and support arm64.
The buildpacks referenced by the builder must also support arm64. Not every buildpack publishes an arm64 variant, so confirm support for the buildpacks you depend on before building.
kpack resolves the architecture from the builder image and schedules the build pod onto a node matching that architecture (kubernetes.io/arch), so an arm64 builder requires at least one arm64 node in the cluster.