Avoid pod environment variables' conflicts with Docker-style links

Solution 1:

Is there a way to configure cluster to not add those automatic variables for each visible service?

Yes and no: not cluster-wide, AFAIK, but the enableServiceLinks: false field in spec: is designed to allow you to switch them off

Alternatively, would using other runtimes like containerd solve this problem?

No, those names were adding in the spirit of compatibility with docker, but are not related to docker at all -- they're injected by kubelet

How in general do I use environment without running into such naming conflicts? Or service names are considered a part of contract with containers and I should not change them freely?

Another option is rather than wholesale banning them, you also can just masking off the specific ones that bother your app; the ones that end in _HTTP are especially problematic with Spring Boot where there is a Service whose metadata: { name: is some super generic name like service or server

You can do that per Deployment:

env:
- name: SERVICENAME_PORT_HTTP
  # omitting the value: just sets it to the empty string in the container
# and the rest

or you can declare a ConfigMap containing the offensive ones and wholesale overwrite them with envFrom: (in order to not have to patch each affected Deployment