1. Cf-Dev
  2. Topics

Cloud Foundry for Kubernetes (cf-for-k8s) v0.6.0 release is out

Saikiran Yerram
 

Hello CF community,

We shipped a new alpha release v0.6.0 of cf-for-k8s. Some key highlights are below. 

We love contributions, so please reach out to us in the #cf-for-k8s channel, you can also create bugs and feature requests. Also, take a look at our project roadmap in cf-for-k8s project and upcoming releases.

Key highlights

  • 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 that 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)

1 - 1 of 1