Note: lists.cloudfoundry.org will be down for maintenance on Wednesday, October 5th, starting at 9AM Pacific Time (4PM Wednesday October 5, 2022 UTC), for approximately one hour.
- Cloud Foundry for Kubernetes (cf-for-k8s) v0.6.0 release is out
Cloud Foundry for Kubernetes (cf-for-k8s) v0.6.0 release is out
Hello CF community,
We shipped a new alpha release v0.6.0 of cf-for-k8s. Some key highlights are below.
- 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
- 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
- App developers can select a buildpack with
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
- All overlays in config-optional are now managed by properties defined in
- 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
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
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
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)