...

• There could be multiple tenants/namespaces in a Kubernetes cluster. User may deploy multiple CNFs in any one or more tenants.
• The replica of CNF deployment could be more than one for active/backup purpose. We should apply rules for all the pods under CNF deployment. (This release doesn't implement VRRP between pods)
• CNF deployment and Sdewan rule CRs can be created/updated/deleted in any order
• The Sdewan controller and CNF process could be crash/restart at anytime for some reasons. We need to handle these scenarios
• Each Sdewan rule CR has labels to identify the type it belongs to. 3 types are available at this time: basic, app-intent and k8s-service. We extend k8s user role permission so that we can set user permission at type level of Sdewan rule CR
• Sdewan rule CR dependencies are checked on creating/updating/deleting. For example, if we create a mwan3_rule CR which uses policy policy-x, but no mwan3_policy CR named policy-x exists. Then we block the request

Architecture

Image Added

SDEWAN CRD Controller internally calls SDEWAN Restful API to do CNF configuration. And a remote client (e.g. SDEWAN Overlay Controller) can manage SDEWAN CNF configuration through creating/updating/deleting SDEWAN CRs. It includes below components:

• MWAN3 Controller: monitor mwan3 related CR change then do mwan3 configuration in SDEWAN CNF
• Firewall Controller: monitor firewall related CR change then do firewall configuration in SDEWAN CNF
• IpSec Controller: monitor ipsec related CR change then do ipsec configuration in SDEWAN CNF
• Service/Application Controller: configure firewall/NAT rule for in-cluster service and application
• Runtime controller: collect runtime information of CNF include IPSec, IKE, firewall/NAT connections, DHCP leases,  DNS entries, ARP entries etc..
• BucketPerssion/LabelValidateWebhook: do sdewan CR request permission check based on CR label and user

CNF Deployment

In this section we describe what the CNF deployment should be like, as well as the pod under the deployment.

...