**Apache Airflow version**: 2.0.0+

**Kubernetes version (if you are using kubernetes)** (use `kubectl version`): All versions affected

**Environment**:
It affects all possible host configurations. The issue impacts KubernetesPodOperator.
What scripts will actually be affected inside of KubernetesPodOperator container - big question. In my scenario it was locally executed **Apache Spark**.

**What happened**:

This issue is consequence of change that was introduced in this commit/line:
https://github.com/apache/airflow/commit/862443f6d3669411abfb83082c29c2fad7fcf12d#diff-01764c9ba7b2270764a59e7ff281c95809071b1f801170ee75a02481a8a730aaR475

Pod operator is generating a pod name that has period in it. Whatever pod name is picked gets inherited by container itself, as result it becomes a hostname of it. The problem of hostnames in Linux is that if it contains period, it immediately becomes assumed a valid domain that DNS should be able to resolve. md5 digest in this weird case becomes assumed as first level "domain". Obviously, some libraries have no idea what to do with DNS domain like `airflow-pod-operator.9b702530e25f40f2b1cf6220842280c`, so they throw exceptions (either Unknown host, Unable to resolve hostname or such)
In my use case the component was barking was **Apache Spark** in local mode.

Error line is referring to Spark URL:
> 21/05/21 11:20:01 ERROR SparkApp$: org.apache.spark.SparkException: Invalid Spark URL: spark://HeartbeatReceiver@airflow-pod-operator.9b702530e25e30f2b1cf1622082280c:38031 

**What you expected to happen**:
Apache Spark just works without issues and able to resolve itself by hostname without any code changes.

**How to reproduce it**:
As I'm not certain about full list of affected applications, I would for now assume anything that tries to resolve "current pod's" hostname.
In my scenario I was running Wordcount of Apache Spark in local mode in KubernetesPodOperator. Perhaps, there might be easier ways to replicate it.

**Anything else we need to know**:
Having this kind of unresolvable real domain vs hostname confusion in my opinion is very very bad, and should be discouraged.

The way for me to mitigate this issue right now was to build my own inheritance for KubernetesPodOperator that has method `create_pod_request_obj` overriden to call older method of generation of unique identifiers for pod name that used `-` (hyphen) instead of `.` (period) notation in name.
tests/kubernetes/models/test_secret.py
Secret('env', 'TARGET', 'secret_b', 'source_b'),
        ]
        k8s_client = ApiClient()
        pod = append_to_pod(pod, secrets)
        result = k8s_client.sanitize_for_serialization(pod)
        assert result == {
            'apiVersion': 'v1',
            'kind': 'Pod',
            'metadata': {
                'labels': {'app': 'myapp'},
                'name': 'myapp-pod.cf4a56d281014217b0272af6216feb48',
                'namespace': 'default',
            },
            'spec': {
                'containers': [
                    {
                        'command': ['sh', '-c', 'echo Hello Kubernetes!'],
                        'env': [
                            {'name': 'ENVIRONMENT', 'value': 'prod'},
                            {'name': 'LOG_LEVEL', 'value': 'warning'},
                            {
                                'name': 'TARGET',
                                'valueFrom': {'secretKeyRef': {'key': 'source_b', 'name': 'secret_b'}},
                            },
                        ],
                        'envFrom': [
                            {'configMapRef': {'name': 'configmap_a'}},
                            {'secretRef': {'name': 'secret_a'}},
                        ],
                        'image': 'busybox',