- Mar 29
- 3 min read

"Unjustified Connection of Apps to Kubernetes Services - An Anti-Pattern" - Blog #09

Updated: Apr 12

We discussed why you should not store configuration inside a container and why a container should not know anything about the cluster it is running on in the previous section. We can take this a step further by requiring each container to be unaware that it is running within Kubernetes at all. Unless you are developing a cluster-managing application, you should not tamper with the Kubernetes API or other external services that are assumed to be inside the cluster. This is a common scenario when teams adopt Kubernetes and fail to isolate their application from the cluster. Some classic examples include applications such as:

Expect a specific volume configuration when sharing data with other pods.
Expect specific service/DNS naming to be set up by Kubernetes networking or assume the presence of specific open ports
collect data from Kubernetes labels and annotations
Inquire within their own pod for information (e.g to see what IP address they have)
In order to function properly, an init or sidecar container is required. even on personal computers
directly contact other Kubernetes services (e.g. using the vault API to get secrets from a Vault installation that is assumed to also be present on the cluster)
To read data from a local Kubernetes configuration,
use the Kubernetes API directly from within the application.

Don’t

Of course, if your application is Kubernetes-specific (for example, an autoscaler or operator), it will need to directly access Kubernetes services. However, for the other 99% of standard web applications out there, your application should be completely unaware that it is running within Kubernetes.

Do

The ability to run your application with Docker compose is the litmus test for determining whether your application is tied to Kubernetes or not. If creating a Docker compose file for your app is trivial, it means you're following the 12-factor app principles and your app can be installed on any cluster without any special settings.

It is also critical to comprehend the premise of local Kubernetes testing. There are several options for local Kubernetes deployments available today (minikube, microk8s, kind etc). When you look at these solutions, you might conclude that if you are a developer working on an application that is deployed to Kubernetes, you must also run Kubernetes.

Don’t

If your app is well-structured, you can skip using Kubernetes to perform integration tests locally. Simply run the tests on a standalone instance of the programme (via Docker or Docker-compose).

Do

Some of your dependencies may be hosted on a different Kubernetes server, and that's fine. However, Kubernetes should not be required to host the application itself during testing.If you prefer, you can use one of the many specialised tools designed specifically for local Kubernetes development, such as Okteto, garden.io, or tilt.dev.