Skip to content

Latest commit

 

History

History
57 lines (38 loc) · 2.42 KB

File metadata and controls

57 lines (38 loc) · 2.42 KB

Stacks

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.

Cluster Stack Configuration

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 stack
  • buildImage.image: The build image of stack.
  • runImage.image: The run image of stack.

Using a private registry

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: private
  • serviceAccountRef: An object reference to a service account in any namespace. The object reference must contain name and namespace.

Updating a stack

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.

Suggested stacks

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.

Building for arm64

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.