Description

Currently, when creating a VM with external: true, the platform automatically creates a LoadBalancer Service and assigns a public IP. This behavior works well and allows accessing the VM via its FQDN (for example vm-instance-example).

However, when a VM does not have a public IP, no Service is created. As a consequence, accessing this VM from another VM within the same tenant requires using its internal IP address, which introduces several drawbacks:

• Internal IPs are not user-friendly
• They may change over time
• They break name-based communication consistency inside the tenant

Problem

From a VM inside a tenant:

• VMs with a public IP can be accessed via their FQDN
• VMs without a public IP can only be accessed via their internal IP

This creates an inconsistency in how VMs are addressed within the same tenant.

Expected Behavior

For VMs without a public IP, the behavior should be similar to VMs with external: true, but using an internal-only Service.

Specifically, a headless ClusterIP Service should be created automatically at VM creation time, allowing:

• DNS-based access using the VM FQDN
• Stable, name-based communication between VMs within the same tenant
• No external exposure

Proposed Solution

When a VM is created without a public IP, automatically create the following Service:

apiVersion: v1
kind: Service
metadata:
  name: vm-instance-example
  namespace: tenant-example
spec:
  selector:
    app.kubernetes.io/instance: vm-instance-example
  clusterIP: None

This would:

• Enable DNS resolution (vm-instance-example.<namespace>.svc)
• Allow consistent FQDN usage for all VMs, regardless of public exposure
• Improve usability and tenant-internal networking consistency

Benefits

• Consistent VM access model (FQDN everywhere)
• No need to rely on internal IP addresses
• Better alignment with Kubernetes-native service discovery
• No impact on security (no external exposure)