Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support chaining of VLAN plugin #989

Closed

Conversation

nvetel
Copy link

@nvetel nvetel commented Dec 8, 2023

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.

image

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"
                    }]
            }
        }]
    }'

@nvetel nvetel force-pushed the feature/vlan-chainning-support branch 2 times, most recently from e4dde28 to 9af2c5f Compare December 8, 2023 16:43
This commit updates the VLAN plugin to be used on a master interface
created from a main plugin in a chain.

If used as a channed plugin, with no master provided, and
linkInContainer at true, then the CNI_IF_NAME interface will be used as
a master interface, and the VLAN interfaces will be named as
<CNI_IF_NAME>.<VLANID>.

Signed-off-by: Nicolas VETEL <nicolas.vetel@orange.com>
@nvetel nvetel force-pushed the feature/vlan-chainning-support branch from 9af2c5f to 1854da3 Compare December 8, 2023 16:48
@nvetel nvetel marked this pull request as draft December 15, 2023 11:11
@nvetel nvetel closed this Dec 19, 2023
@nvetel
Copy link
Author

nvetel commented Dec 19, 2023

PR duplicated with #993

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant