v0.6.0

Notice:

cf-for-k8s does NOT support upgrades for alpha releases. We are in the process of defining the final configuration contract which will follow the semver versioning scheme once we ship 1.0 version.

• Please upgrade your kapp to v0.33.0

Notable changes since the last v0.5.0 release

New Features / Bug fixes

• Platform engineers and App developers will notice auto-patching of app workloads when the foundation is upgraded to a new stack version. App developers no longer have to re-push the app source to patch their app workload with the CVE fixes in the base image!!
• Platform engineers can now expect all traffic to/from components are denied by default and components will require explicit policies to allow ingress/egress traffic #262.
• Platform engineers can expect all sensitive information such as passwords, cert keys are stored in Kubernetes native secrets #225, #226, #227, #228, #229, #230, #330.
• Platform engineers and App developers can see available buildpacks via cf buildpacks #101.
• App developers can select a buildpack with cf push APP_NAME -b [buildpack-name] #340.
  • Note, you can currently only select known buildpacks that are available in cf-for-k8s and not custom builpacks
• Platform engineers can expect every component gets their own unique UAA client password #233.
• Platform engineers can expect simplification of the cf-for-k8s configuration interface. You can see a list of allowable properties in config/values/00-values.yml
  • All overlays in config-optional are now managed by properties defined in config/values/00-values.yml.
  • Long term, cf-for-k8s will use YTT schema to define a more strict schema with semver versioning scheme.
  • Note: Platform engineers are still expected to provide properties in config/values/20-secrets-config-values.yml until cf-for-k8s replaces it with server-side secret generation using Quarks.
• Platform engineers can expect by default all external HTTP traffic to CF API and application workloads to redirect to HTTPS unless they set gateway.https_only to false. Note, internal traffic between system components is encrypted by default by Istio.
• Platform engineers can now control the creation of load balancer in Kubernetes using the new flag enable_load_balancer. This is helpful when you want to install locally or if want to wire your foundation to a pre-existing load-balancer.
• Platform engineers can expect upgrades to wait until Postgres (stateful sets) are upgraded #206.
• Platform engineers can observe application ingress latency contributed by the platform and network (more here)

Configuration changes

• Core config properties from config/values.yml have been moved to config/values/00-values.yml.
• Certs/password related properties were moved to config/values/20-secrets-config-values.yml. Our hope is to drop this file in favor of Quarks server side password/cert generation in the future.

Release Updates

We are only tracking published releases

Release	Old Version	New Version
Eirini	v1.7.0	v1.8.0
Networking	v0.0.6	v0.2.0
CAPI	7d9acf6a8d05fcb7f186758b58ad2e803c8c7ecc	+v0.3.0
kapp	0.30.0	0.33.0

Integration updates

Showing only notable updates,

• PR checks now include upgrade with uptime check and external database validations
• The long-running environment now has a dedicated registry repository. The goal is to monitor registry usage over time.

What we are working on next

• Define a clear versioning contract between the Platform engineers, cf-for-k8s, and contributing projects. Our goal is to submit the proposal to the community in a week or so after this release.
• Incorporate CATS tests into cf-for-k8s workflows.
• Collaborate with Credhub team to integrate Quarks server-side password generation. With Quarks, Platform engineers will no longer be required to provide passwords (or run bosh-cli based script to generate passwords) and rely on Quarks to generate them in the K8s cluster. It is similar to the functionality available today in cf-deployment with Credhub integration.
• Identify and document app structural differences required by Paketo Buildpacks to detect and build the image.
• Move roadmap to github projects and use milestones to plan future releases. Our hope is that github projects/milestones will create transparency with the community and make it easier for contributors to participate and contribute to cf-for-k8s.