A general principle behind Kubernetes design is; Meet the user where they are. This means that application developers should not have to make any special adjustments when running workloads on Kubernetes. Detection of Kubernetes as a CloudPlatform goes against the spirit of this.

A more concrete example of this principle from Kubernetes design documentation

Don't assume a component's decisions will not be overridden or rejected,
nor for the component to always understand why.
For example, etcd may reject writes.
Kubelet may reject pods. 
The scheduler may not be able to schedule pods. 
Retry, but back off and/or make alternative decisions.

At a technical level, it is not possible to deterministically detect if an app resides within a Kubernetes pod as Service Link environment variables can be disabled

Instead we should explore options of using default behaviour in Spring Boot that works well with both Kubernetes and existing cloud platforms.

Comment From: bclozel

In #19593, ApplicationAvailabilityProvider is auto-configured for all applications, but HTTP Probes are only configured for applications running on Kubernetes.

This issue asks the following: * should we generally remove the CloudPlatform.KUBERNETES platform detection because it's an anti-pattern? * #19593 introduced a spring.main.cloud-platform configuration property to force the cloud platform detection. We were not super happy with that in the first place. Maybe we should turn it into a feature configuration property like management.health.probes.enabled?

Comment From: wilkinsona

should we generally remove the CloudPlatform.KUBERNETES platform detection because it's an anti-pattern?

Before doing that, we should get some input from @markpollack. It was added in support of something that he was doing.

Comment From: wilkinsona

I find the technical argument quite a bit more compelling than the argument about meeting the user where they are. This design goal is intended to mean that users "should not require an application to be rewritten to run on Kubernetes". The motivation for this is the following:

By making design choices that minimize the hurdles for deploying workloads on Kubernetes, Kubernetes make it easy to run existing workloads on Kubernetes without having to rewrite or significantly alter them.

I don't think that auto-detecting that an app is running in Kubernetes and automatically enabling some functionality is at odds with this. In fact, it reduces the alterations that users may have to make when deploying an application on Kubernetes. Arguably, by auto-configuring liveness and readiness probes when running on Kubernetes, we are helping Kubernetes to meet the user where they are.

Comment From: ojhughes

Agreed @wilkinsona, we could work with sig-apps to explore options such as an environment variable that is always set in a Pod

Comment From: bclozel

In the meantime, I've updated #19593 and now HTTP Probes are activated if the Kubernetes CloudPlatform is detected, or if the management.health.probes.enabled property is set to true. See this comment for more details.

Comment From: philwebb

We've discussed this today and our general feeling is that the detection is useful and we don't want to remove the functionality. However, it would be useful if the user could tell us about the platform for the cases where our detection logic doesn't work. We'll add that in #20691.