Credit to igekman. His summary is brief and accurate for it's brevity. I wanted to expand upon this. I understand this is two years later, but others may come here looking for the answer as well.

VRFs came to linux after network namespaces, and under the covers they leverage the same functionality that network namespaces implement, so they are nearly one in the same. As igekman pointed out its the usecase that really drives one versus the other.

A network namespace isolates the entire network stack for a given namespace. They also provide fine grained control over the network resources associated with the namespace. This includes things like interfaces, routing tables, service access, etc. This is useful when the linux host is terminating network connections and sockets for clients and services, in the traditional sense and you want to isolate visibility to the network stack for a specific or given set of services or clients running on the host. Consider this the network component for a container.

VRF stands for Virtual Routing and Forwarding and originated in custom proprietary software written by Cisco in the late 90s with the advent of MPLS (originally called Tag Switching). In the network transport world, routers, switches, proxies, and firewalls are intermediate devices between clients and services. A common need for a transport device is to be able to isolate the routes learned or advertised between these intermediate devices into separate tenants--effectively creating virtual private networks (VPNs). This allows the same routing prefixes (IP address ranges) to be distributed through the same physical device on behalf of different customers. VRFs also allows enterprises to enforce specific pathing based on the origin and destination "security zone" of a network. Note that VRFs are merely the construct on the device that provides the isolation for the routing table and associated interfaces. In order to create a VPN one generally needs a routing (control-plane) protocol to exchange prefixes (network segment destinations) and a transport (data-plane) protocol to enforce the isolation of packets within each private network.

As linux became the most common operating system to use as the base for building these intermediate devices post 2010, the implementation came with it. One would think, if VRFs are so similar to network namespaces, it begs the question... why not just use network namespaces?

VRFs have very specific rules with which they are required to operate that are not imposed on network namespaces. For instance:

• An interface can only be a member of a single VRF.
• Split horizon must be enforced, so that a packet can not hair-pin (go out and in the same interface.)
• InterVRF forwarding (route-leaking) must be explicit.

With a network namespace, all three of these rules can (and often need to) be broken. In packet forwarding, it is important that products especially from different manufacturers adhere to the same rules so as the networks scale they are predictable.

So to reiterate again on what igekman stated, if you need to isolate the network stack on your linux host:

1. You should most likely be using network namespaces if you're terminating TCP/UDP services on the device.

2. You should most likely be using VRFs if needing to isolate paths to provide transit for packets between other devices.

https://docs.kernel.org/networking/vrf.html