⚠️ DEPRECATION NOTICE ⚠️

Thank you to everyone who has used and contributed to capi-k8s-release!

As a follow-on to the 8/23/21 cf-dev CF on K8s Update, this project has been deprecated to focus efforts on Korifi. Korifi provides a Kubernetes-native app platform by reimplementing the core Cloud Foundry APIs and backing them by a set of Kubernetes custom resources and controllers. We invite you to try out Korifi and provide feedback!

capi-k8s-release

This collection of yaml, ytt, and go code packages together the bits that make the CF API run in cf-for-k8s.

Deploying

1. capi-k8s-release is best consumed as part of cf-for-k8s
2. Clone the cf-for-k8s repository: git clone https://github.com/cloudfoundry/cf-for-k8s.git
3. Follow the cf-for-k8s deploy documentation

Components & Collaborators

click here to edit the diagram, save as capi-k8s-release.png to persist changes

In this repo:

• cf-api-controllers is a collection of kubebuilder controllers that synchronize the CF API and various k8s CRDs (Images, Builds, Routes, PeriodicSyncs, etc).
• registry-buddy is sidecar service to help ruby code communicate with container registries using go-containerregistry.
• nginx is a custom-built nginx container including the nginx upload module for managing resumable multipart package uploads.
• backup-metadata-generator is a velero hook that collects metadata about resources currently stored in the CF API.

From elsewhere:

• cloud_controller_ng is a reference implementation of the the V3 CF API.
• eirini is an adapter that lets Cloudfoundry Processes and Tasks run on Kubernetes
• kpack is a collection of CRDs and Controllers for building container images from source using Cloud Native Buildpacks
• route controller & istio are used by cf-for-k8s to manage Routes to apps and the service mesh between CF components
• uaa is used to manage users and token verification
• cf is the eponymous CLI for interacting with the CF API. We support versions v7 and higher.

Rolling out development changes to capi-k8s-release

1. ./scripts/rollout.sh will take any local changes to capi-k8s-release, apply them to a local cf-for-k8s directory, and then deploy cf-for-k8s
2. ./scripts/build-and-rollout.sh will take local changes to cloud_controller_ng and the components in capi-k8s-release/src, build them with kbld, pack, and paketo's ruby and go buildpacks, and then deploy the new images to cf-for-k8s.

Environment variables can be used with either script to override default local source directories and remote image repositories.

Configuring Honeycomb

For debugging, it may be useful to emit events to Honeycomb. This can be done by passing an additional data file with a library annotation to the ytt command that builds the cf-for-k8s manifest, or to one of our rollout.sh scripts.

#@library/ref "@capi-k8s-release"
#@data/values
---
honeycomb:
  dataset: my-capi-dataset
  write_key: MY_WRITE_KEY

Configuring pushes of buildpack apps

capi-k8s-release currently uploads app source code to a blobstore, but then hands that off to kpack to build app images that are then placed in a registry. In order for this to work, you must configure the following values:

kpack:
  registry:
    hostname: # the hostname of the registry, used for authentication
    repository: # the destination of the build app images within the registry
    username: # basic auth registry username
    password: # basic auth registry password

dockerhub example:

kpack:
  registry:
    hostname: https://index.docker.io/v1/
    repository: cloudfoundry/capi
    username: <username>
    password: <password>

gcr example:

kpack:
  registry:
    hostname: gcr.io
    repository: gcr.io/cloudfoundry/capi
    username: <username>
    password: <password>