Support chaining of VLAN plugin

[nvetel]

Introduction

This feature adds the ability to create multiple vlan interfaces out of a container namespace interface created by another CNI. It is greatly inspired from PR #903 proposing a similar feature on macvlan.

Problem

I need to have an interface in a pod, and create as many vlan interfaces as I want on that master interface, with a different IPAM configuration on each one.

Proposal

The idea is to relay on the vlan plugin to create such configuration, since creating a vlan interface and using IPAM on is exactly what it is for.

An obvious solution is to chain vlan plugin after the plugin creating master interface, and to use the linkInContainer option to target a master interface in the container namespace. But the limitation is that it's hard to know the master interface in advance to reuse it in the chained vlan plugin.

The proposal is then use an empty master in the vlan plugin netconf combined with the linkInContainer parameter to ask the plugin to use the CNI_IF_NAME argument as master interface, and to name the new interface as the master with a dot vlanID notation at the end.

Here is a netconf example with a master interface created by the "my-main-plugin", and then the VLAN interfaces 3 and 4 created out of it :

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: vlan-chaining-example
spec:
  config: '{
        "cniVersion": "0.3.1",
        "name": "vlan-chaining-example",
        "plugins": [{
            "type": "my-main-plugin",
        },{
            "type": "vlan",
            "linkInContainer": true,
            "vlanId": 3,
            "ipam": {
                    "type": "static",
                    "addresses": [{
                          "address": "192.168.3.10",
                          "gateway": "192.168.3.1"
                    }]
            }
        },{
            "type": "vlan",
            "linkInContainer": true,
            "vlanId": 4,
            "ipam": {
                    "type": "static",
                    "addresses": [{
                          "address": "192.168.4.10",
                          "gateway": "192.168.4.1"
                    }]
            }
        }]
    }'

[s1061123]

First, thank you for the PR. I agree with you that your requirement is valid but I suppose we need to think more about its desgin.

Currently your design assumes that vlan plugin is similar to ipvlan as well as macvlan, however it is not correct actually because VLAN (i.e. 802.1Q) could be nested as Q-in-Q. ipvlan and macvlan does not allow nested structure. Hence if we have following configuration, another user may want to create nested Q-in-Q config (one interface with two VLAN ID: 3 for outer tag and 4 for inner tag) as well as your expectation (two interfaces: vlan interface with VLAN ID: 3 and another vlan interface with VLAN ID:4 in one CNI config).

{
  "cniVersion": "1.0.0",
  "name": "vlan-chaining-example",
  "plugins": [
    {
      "type": "my-main-plugin",
      (snip)
    },
    {
      "type": "vlan",
      "vlanId": 3,
      (snip)
    },
    {
      "type": "vlan",
      "vlanId": 4,
      (snip)
    },
    {
     "type": "tuning",
     "promisc": true
    }
  ]
}

Above CNI config is slightly not clear that which interface 'tuning' apply the configuration because actually CNI specification does not specify such multiple container interfaces in one CNI result. Hence, to apply such CNI config, we also need to elaborate CNI specification to define the semantics for CNI chaining with multiple container interface case, as well as runtimeConfig and cni-arg beause currently runtimeConfig and cni-args is also desgined one interface in one results cases, mainly.

In addition, from multus point of view, above CNI config is not feasible because multus expects (not strictly, but roughtly) that one net-attach-def creates one interface to the Pod. For example, multi-networkpolicy does not support two interface in one net-attach-def officially.

But as I told previously, your requirement is valid. I roughly come up an idea to split into two CNI config as following:

{
  "cniVersion": "1.0.0",
  "name": "vlan-chaining-example1",
  "plugins": [
    {
      "type": "my-main-plugin",
      (snip)
    },
    {
      "type": "vlan",
      "vlanId": 3,
      (snip)
    }
  ]
}

{
  "cniVersion": "1.0.0",
  "name": "vlan-chaining-example2",
  "plugins": [
    {
      "type": "host-local", (or container-local, newly added)
      "device": "net1" (specify interface name, created by above example1)
    },
    {
      "type": "vlan",
      "vlanId": 4,
      (snip)
    },
    {
     "type": "tuning",
     "promisc": true
    }
  ]
}

This will solve your requirement as well as previous concerns. So how about to close this PR and file another issue(or PR)?

[nvetel]

Hello @s1061123 ,

Your remarks make sense, and point out use cases I did not anticipated (q-in-q, multi-networkpolicies).

My main intent was to be able to create vlan interfaces out of another net-attach-def without knowing in advance its CNI_IFNAME. If I want to create multiple VLAN interfaces, I then need one net-attach-def for each one of them, and then I NEED to know the master. And if I know the master, I think that the current features of the vlan plugin would actually fit my need.

Anyway, Thanks for you're help. I will close the PR and re-think of a solution to my use cases regarding your suggestions.