Service mapping not working for alpine-based images

[pinnymz]

What happened?

I ran the following to test gefyra service mapping functionality with a busybox image:

gefyra run --rm -i busybox -N gefyra-test -n gefyra-test --env-from pod/my-pod -c "/bin/sh -c 'trap : TERM INT; sleep 9999999999d & wait'"

(in another console)
docker exec -it gefyra-test /bin/sh
# wget -O- my-service

the output was:

Connecting to my-service (XX.XX.XX.XX:80)
...

Rerunning the exact same test using an alpine image:

gefyra run --rm -i alpine:latest -N gefyra-test -n gefyra-test --env-from pod/my-pod -c "/bin/sh -c 'trap : TERM INT; sleep 9999999999d & wait'"

(in another console)
docker exec -it gefyra-test /bin/sh
# wget -O- my-service

the output was:

wget: bad address 'my-service'

What did you expect to happen?

The service mapping should be recognized regardless of which image was mounted in the container.

Please provide the output of gefyra check.

[INFO] Checking Docker client. [INFO] Docker client: Ok [INFO] Checking availability of Gefyra Cargo image... [INFO] Gefyra Cargo: Available [INFO] Docker: Ok [INFO] Checking Kubernetes connection. [INFO] Kubernetes: Ok [INFO] Gefyra client version: 1.1.2

How can we reproduce it (as minimally and precisely as possible)?

Run the following against a cluster to setup the sample service and pod:

kubectl create namespace gefyra-test

kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: gefyra-test
spec:
  type: ExternalName
  externalName: www.example.com
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: gefyra-test
spec:
  containers:
  - name: my-container
    image: busybox:latest
    command: ['/bin/sh']
    args: ['-c', 'trap : TERM INT; sleep 9999999999d & wait']
EOF

Then run the same commands above.

What Kubernetes setup are you working with?

$ kubectl version
Client Version: v1.27.4
Kustomize Version: v5.0.1
Server Version: v1.27.4

OS version

# On Mac:
$ sw_vers
ProductName:    macOS
ProductVersion: 12.3.1
BuildVersion:   21E258
$ uname -a
Darwin TD1002451.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64

Anything else we need to know?

I had the same issue with several alpine based containers, then realized this was happening with base alpine itself. I ruled out other factors like multi-stage builds, etc. No idea what is different about alpine, but this is a pretty big deal breaker for us.

[pinnymz]

Reading up more on alpine, there was a known DNS issue prior to 3.18 - unfortunately, the issue reported above is still occurring with 3.18/latest as demonstrated.

[SteinRobert]

Thank you for all your investigation! We'll surely look into it. It could be, that this issue is fixed in Gefyra v2. We're releasing it this week. We'll be getting back to you on this asap.

[pinnymz]

@SteinRobert I managed to retry this with v2, but still seeing the same issue. Busybox finds services properly, alpine does not.

[SteinRobert]

Thank you for trying again. We'll investigate. Meanwhile we have been able to reproduce some dns issues ourselves.