Airflow: Kubernetes Executor - invalid hostname in the database

[Labbs]

Summary:
Airflow cannot retrieve logs from kubernetes pods because the pod name is invalid.

Apache Airflow version: 1.10.11

Kubernetes version (if you are using kubernetes) (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.1", GitCommit:"7879fc12a63337efff607952a323df90cdc7a335", GitTreeState:"clean", BuildDate:"2020-04-10T21:53:51Z", GoVersion:"go1.14.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.6-eks-4e7f64", GitCommit:"4e7f642f9f4cbb3c39a4fc6ee84fe341a8ade94c", GitTreeState:"clean", BuildDate:"2020-06-11T13:55:35Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

Environment:

• Cloud provider or hardware configuration: AWS

What happened:
When I want to retrieve the logs from the GUI, Airflow indicates that it has not found the pod

HTTP response body: b'{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods \\"examplekubernetesexecutorstarttask-7409bf0f1ed644cfba6c423be769\\" not found","reason":"NotFound","details":{"name":"examplekubernetesexecutorstarttask-7409bf0f1ed644cfba6c423be769","kind":"pods"},"code":404}\n'

After checking in the kubernetes and the database, the hostname is in the database is not complete.

kubectl get po -n airflow-testing | grep examplekubernetesexecutorstarttask-7409bf0f1ed644cfba6c423be769
examplekubernetesexecutorstarttask-7409bf0f1ed644cfba6c423be769a8c4         0/1     Completed   0          107m

It's missing 4 characters in the hostname.
If I update the database with the complete hostname, airflow retrieve the log without issue

What you expected to happen:
The hostname must be complete in the database so that airflow can retrieve the logs in kubernetes with the correct pod name.

How to reproduce it:
1- configure airflow for use KubernetesExecutor

AIRFLOW__KUBERNETES__DELETE_WORKER_PODS=False
AIRFLOW__CORE__EXECUTOR=KubernetesExecutor

2- add dag

from airflow import DAG
from airflow.operators.python_operator import PythonOperator
from airflow.utils.dates import days_ago

args = {
    "owner": "airflow",
}


def print_stuff():
    print("ok")


dag = DAG(
    dag_id="example_kubernetes_executor",
    default_args=args,
    schedule_interval=None,
    start_date=days_ago(2),
    tags=["example"],
)

start_task = PythonOperator(
    dag=dag,
    task_id="start_task",
    python_callable=print_stuff)

one_task = PythonOperator(
    dag=dag,
    task_id="one_task",
    python_callable=print_stuff,
    executor_config={"KubernetesExecutor": {"image": "apache/airflow:latest"}},
)

start_task >> one_task

3- trigger execution
4- get logs from UI

Result:

*** Trying to get logs (last 100 lines) from worker pod examplekubernetesexecutorstarttask-7409bf0f1ed644cfba6c423be769 ***

*** Unable to fetch logs from worker pod examplekubernetesexecutorstarttask-7409bf0f1ed644cfba6c423be769 ***
(404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Audit-Id': '28495ca5-86f3-4935-9cef-f825b79cdff6', 'Cache-Control': 'no-cache, private', 'Content-Type': 'application/json', 'Date': 'Tue, 11 Aug 2020 16:27:43 GMT', 'Content-Length': '294'})
HTTP response body: b'{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods \\"examplekubernetesexecutorstarttask-7409bf0f1ed644cfba6c423be769\\" not found","reason":"NotFound","details":{"name":"examplekubernetesexecutorstarttask-7409bf0f1ed644cfba6c423be769","kind":"pods"},"code":404}\n'

Anything else we need to know:
The problem is permanent regardless of the dag used.

[boring-cyborg[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template!

[jonstacks]

I'm also seeing this in our EKS clusters(version 1.15.11) with airflow 1.10.11 and 1.10.12 using the Kubernetes Executor. Everything else seems to be working as expected with the exception of logs.

I think I've traced it back to how the hostname gets set in the DB. I think this call to get_hostname is the issue:

https://github.com/apache/airflow/blob/4e3799fec4c23d0f43603a0489c5a6158aeba035/airflow/utils/net.py#L31-L36

If you exec into a pod with a long pod name(> 63 chars) and and run echo -n $(hostname) | wc -c you should get the truncated name you are seeing in the database(length 63 characters). At least that is happening for me. I think it has to do with the maximum length of a label in a fqdn being 63 characters.

It looks like airflow has an environment variable for this callable and we could do something like this: https://stackoverflow.com/a/62905570. If there is an easy way to expose the log port on the executor pods, I think we could easily override this with the environment variable to set it to the IP. I didn't see anything in the documentation for it, except maybe a pod template file, but I think that overrides the whole POD.

It looks like it shouldn't be a problem from the side that looks at the logs:

https://github.com/apache/airflow/blob/4e3799fec4c23d0f43603a0489c5a6158aeba035/airflow/utils/log/file_task_handler.py#L109-L123

I am new to managing airflow for our company, but I'm wondering if it would make sense to, by default, inject a POD_NAME environment variable using the downward API by default into the container and if that environment variable is set, return that for the hostname, so it gets set in the DB. Hopefully it would make the default configuration handle this case where the pod name is really long.

Something like:

- name: MY_POD_NAME
  valueFrom:
    fieldRef:
      fieldPath: metadata.name

We are currently trying to get this working so that we can use the KubernetesExecutor in production instead of the CeleryExecutor. If anyone knows a good way around this, I would be great full to learn the best way to handle this.

[jonstacks]

I did some messing around and was able to get get the logs working by adding this: https://github.com/apache/airflow/commit/58eb534f1902a561c151d0bb796692a3df6e241f

It looks up the correct pod name based on the partial so it can grab the logs. It seems to be working for us, but I feel like there might be a better way.

[Labbs]

@jonstacks I tested your fix. That works well.