search

telekom / das-schiff-network-operator

Configure netlink interfaces, simple eBPF filters and FRR using Kubernetes resources.
Apache License 2.0
27 stars 3 forks source link

Split network-operator into operator and agent #121

Open chdxD1 opened 1 month ago

chdxD1 commented 1 month ago

This should be based off #112 & #110.

We would like to split the network-operator into two separate components. One is the operator, which watches the node configuration object and another one being the agent which takes the node configuration through an API (like gRPC or other means) and configures FRR and netlink.

This agent API will be the first pluggable interfaces of network-operator. The API (for this specific implementation) should be very easy and just send over the intended configuration. Difference check with the config on FRR / netlink layer will be part of the agent, no GET API will be introduced for now

image

p-strusiewiczsurmacki-mobica commented 1 month ago

110 introduces new pod network-operator-configurator. With this change network-operator watches CRDs vrfrouteconfigurations, layer2networkconfigurations and routingtables and creates per node configuration NodeConfig. network-operator-configurator watches NodeConfigs and configures the networking. Do I understand correctly that we would like to add third element (a pod for now?) that will get config from the network-operator-configurator (through gRPC) and will perform networking configuration?

chdxD1 commented 1 month ago

110 introduces new pod network-operator-configurator. With this change network-operator watches CRDs vrfrouteconfigurations, layer2networkconfigurations and routingtables and creates per node configuration NodeConfig. network-operator-configurator watches NodeConfigs and configures the networking. Do I understand correctly that we would like to add third element (a pod for now?) that will get config from the network-operator-configurator (through gRPC) and will perform networking configuration?

yes exactly, this is to split the Kubernetes to "some API" (gRPC in this case, NETCONF in another) part from the agent that performs the configuration

chdxD1 commented 1 month ago

@p-strusiewiczsurmacki-mobica one small addition: The operator-configurator will run the connectivity / post checks, just the configuration part will move to the agent.

p-strusiewiczsurmacki-mobica commented 1 month ago

I've just created draft PR for this: #124 I've used the simpliest gRPC implementation, that just serializes the NodeConfig and pass those to the Agent.

I have one more question - should BPF setup (https://github.com/telekom/das-schiff-network-operator/blob/main/cmd/manager/main.go#L183) be part of agent as well?