virtual-kubelet has different DNS resolution behaviour to standard kubelet

[grahamhayes]

---

Environment summary

Provider (e.g. ACI, AWS Fargate)
ACI
Version (e.g. 0.1, 0.2-beta)
0.9.0
K8s Master Info (e.g. AKS, ACS, Bare Metal, EKS)
AKS
Install Method (e.g. Helm Chart, )
All

Issue Details

When creating a pod, I expect /etc/resolv.conf to be populated like a standard AKS kubelet (or plain upstream kubernetes).

By default, the search domain is left blank, and while it can be overridden by a dnsConfig section on the pod spec, it means that off the shelf software that generates its own pod specs cannot use the DNS based service discovery it relies on.

Repo Steps

apiVersion: v1
kind: Pod
metadata:
  name: helloworld-3
spec:
  containers:
  - image: microsoft/aci-helloworld
    imagePullPolicy: Always
    name: helloworld
    resources:
      requests:
        memory: 1G
        cpu: 1
    ports:
    - containerPort: 80
      name: http
      protocol: TCP
    - containerPort: 443
      name: https
  nodeSelector:
    kubernetes.io/role: agent
    beta.kubernetes.io/os: linux
    type: virtual-kubelet
  tolerations:
  - key: virtual-kubelet.io/provider
    operator: Exists
  - key: azure.com/aci
    effect: NoSchedule

Then (using the ACI interface on the portal)

cat /etc/resolv.conf or try to connect to a service via the cluster dns name with no dns suffixes.

[Romiko]

Any update on this being resolved? Excuse the pun.

[dkkapur]

Redirecting this to @macolso @mikkelhegn for latest updates!

[gossion]

duplicated with #46