Kubernetes autogenerated environment variables set wrong?

During pod startup Kubernetes is creating some environment variables based on services i created (via downward API?). Problem is that one of them, MY_APPLICATION_PORT, seems to be initialized incorrectly, it looks like:

MY_APPLICATION_PORT=tcp://192.168.0.5:7777

whereas i expect it to hold only 7777 value. The problem is that i have a Spring Boot application that has this property in application.properties:

my.application.port=7777

So when spring resolves it's properties, it prefers value from environment variable over one from .properties file, thus overwriting it with incorrect value.

My question is - do you guys know how to control creation of kubernetes env variables? I can overwrite it in my deployment.yaml, but I wonder if there's another way.

EDIT:

I've found this as a closest description of my issue I've seen online:
https://github.com/kubernetes/kubernetes/issues/65130

This environment variable comes from compatibility with a very old Docker feature. You can disable it in Kubernetes by setting enableServiceLinks: false on a Container object in a Pod spec, anywhere that may appear. For example:

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: ...
          enableServiceLinks: false
          env: [...]

In particular the syntax is intended to be compatible with the environment variables generated by container links in first-generation Docker networking. Since then Docker has also introduced a DNS system into its core, and in pure Docker using links at all is now considered obsolete. It should be safe to always set this Kubernetes property, especially if it causes conflicts like what you describe here.

Just to mention that it is working,

but in my case for a StatefulSet I had to move the enableServiceLinks flag at the spec level:

apiVersion: apps/v1
kind: StatefulSet
spec:
  template:
    spec:
      enableServiceLinks: false
      containers:
        - name: ...