Juniper Contrail Networking Architecture

0:09 hi everybody my name is prasad i'm going

0:11 to walk through the control networking

0:13 architecture control

0:15 supports

0:16 both

0:17 kubernetes orchestrator as well as

0:20 openstack orchestrators

0:22 and

0:23 when we have the kubernetes orchestrator

0:26 we support containers

0:27 as well as

0:29 virtual machines

0:30 via kubot as my

0:33 as nick mentioned earlier

0:35 and also for container workloads if we

0:38 need additional security

0:40 we support through the kata containers

0:41 are equivalent

0:43 so and for openstack uh workloads like

0:47 you know primarily virtual machines

0:49 that also we support

0:52 and the control networking when it is

0:54 supporting

0:55 we have multiple options

0:57 to

0:58 do the data forwarding using the kernel

1:01 loadable modules or dpdk sriov

1:05 and smartnix

1:07 in whole we support both orchestrators

1:10 kubernetes as well as openstack and

1:13 contrail is an sdn platform

1:16 consists of three planes

1:18 config plane control plane as well as

1:20 the data plane

1:22 conflict plane consists of multiple

1:24 config nodes

1:26 and they are highly available

1:29 by two n plus one uh

1:32 you know config nodes and the similarly

1:34 control nodes are also highly available

1:38 and config plane config nodes takes the

1:41 rest configuration from the

1:44 orchestrators or ui and

1:47 stores this configuration at the hcd

1:51 data data store

1:53 key value data store

1:55 and

1:56 it forms a graph and all this

1:59 configuration is for uh forms a graph at

2:02 the control node

2:04 and it is replicated at all the other

2:06 control nodes and

2:09 as needed

2:10 only the relevant partial graphs will be

2:12 sent towards to the compute nodes

2:14 instead of sending the whole graph to

2:16 the compute nodes

2:18 so it becomes like you know highly

2:19 efficient if you have thousands of

2:23 network policies or thousands of virtual

2:25 networks only the relevant

2:27 configuration will be propagated down

2:29 for the routing so we use the bzp

2:32 to communicate the routes

2:34 across the north and as all these

2:37 componentry is uh is going to generate

2:40 the telemetry

2:41 towards to the telemetry node

2:43 and contrail supports multi-tenancy

2:46 multi-cluster support and with iam and

2:49 rollbacks

2:50 are sorry our backs

2:52 and intent-based networking and security

2:55 and also we support insights for uh

2:58 country networking as well as the

3:01 security for our security policies i

3:04 have a question uh it's enrique here

3:07 um

3:08 in the previous slide you mentioned that

3:10 you need

3:12 you can work in smart nics and you use

3:14 the pdk

3:15 but does it mean that you need a smart

3:17 link so a piece of advert to make your

3:20 solution

3:21 work or can you work also on kubernetes

3:24 in the public cloud yeah so we can work

3:27 in the uh kubernetes public cloud also

3:30 so

3:31 when we have the data plane

3:33 um you know we can have the kernel

3:35 loadable module or dpdk or smartnix

3:38 so public load uh you know we can

3:41 we can work as a cni

3:43 uh so so that is also one option

3:46 or we could have the

3:49 ec2 instances running as a compute nodes

3:52 that would be another option

3:53 does it create any limitation or

3:56 performance issue so yeah that's a good

3:58 question see when uh based on the use

4:00 cases we would be using the convertable

4:03 modules or dpdk

4:05 so let's take the cases like if we have

4:07 a fic use cases where we are running

4:10 like you know cudu that kind of

4:11 workloads

4:13 and which requires a lot of uh

4:15 throughput and performance then we use

4:17 the vpdk

4:19 so so that like you know the cores are

4:22 reserved and you know it is doing the

4:23 processing

4:24 but certain cases like you know

4:27 uh user wanted to reserve all these

4:29 codes towards to the

4:31 workloads and in those cases like you

4:33 know we wanted to support through the

4:35 smart nics

4:36 but this when we do this moniks you know

4:39 it comes with the cost

4:40 you know hence like you know we have the

4:42 varied options so so let me go to the uh

4:44 a little bit uh deep dive into the uh

4:47 control config

4:48 so control conf config is uh based on

4:52 the

4:53 kubernetes

4:55 uh you know api aggregation api server

4:58 so which basically we are extending the

5:00 existing api server uh with our custom

5:03 api server

5:05 in a way whatever the configuration

5:07 intents which we are configuring

5:10 will be

5:11 will will be called as a custom

5:13 resources

5:14 through the aggregation api server

5:16 technique so those will be handled over

5:18 to the custom api server

5:20 so these custom api servers is nothing

5:22 but another instance of the kubernetes

5:24 api server

5:26 and this custom api servers uh you know

5:29 custom resources will be managed or

5:32 through the control loops using the

5:34 custom controllers

5:36 which is similar to like you know how

5:38 the kubernetes uh does its uh you know

5:41 native resources like you know

5:43 parts or like you know nodes

5:45 or deployments and replica sets

5:48 similarly like you know all our uh

5:50 custom resources will be managed through

5:52 custom api server and custom controller

5:56 and this configuration will be watched

5:58 by the control node and forms the graph

6:01 and sends it towards to the data plane

6:05 and all this component 3 will be

6:07 generating the telemetry uh you know as

6:09 i mentioned earlier

6:10 so this is the configuration

6:14 now the next step is like you know we

6:16 have a

6:17 data path as well as the

6:19 control node

6:21 so

6:22 so here the data path evaluation is like

6:24 you know as uh

6:26 you know as you ask like no there are

6:28 multiple options controllable module

6:30 dpdk smartnix

6:32 in a given kubernetes cluster we can

6:34 have a mixed variation of things based

6:36 on the uh locality are based on the need

6:39 and the control is run through the uh

6:43 same channel through

6:45 via the control load and these routes

6:48 are exchanged using the bgp so at high

6:51 level you know we have a

6:53 controller which is the config ng and

6:55 control load

6:57 and

6:58 config ng is

7:00 for the configuration control is for the

7:03 routing

7:04 and whereas the compute nodes like you

7:05 know that's where all the uh data path

7:08 the forwarding happens using the agent

7:09 envy router and we have a web ui to

7:12 visualize these

7:14 constructs and also we send this data

7:16 towards to the telemetry enchant which

7:18 has the api server

7:20 and a collector

7:22 and send this information towards to the

7:25 syncs telemetry syncs

7:27 from ets elastic and you know sdb so far

7:30 what we covered is like you know uh how

7:32 the control sdn consists of like you

7:34 know three different planes

7:36 config control and data plane

7:39 and uh the componentry of each of them

7:43 so now i would like to walk through

7:45 a few operational models control uh

7:47 works on

7:50 so one mode is like you know is it's a

7:52 single cluster

7:54 and which is integrated with the

7:55 kubernetes cluster

7:58 and the second mode is like you know

8:00 this account trial cluster is going to

8:03 manage

8:04 few

8:06 kubernetes clusters

8:08 so that's another mode

8:11 and the third mode which we are going to

8:12 support is uh

8:14 multiple contact clusters are managed

8:17 through the uh

8:18 fed

8:19 or

8:20 another

8:22 control controller

8:24 cube here is used for the config

8:26 federation

8:28 so quiffed also like you know which is

8:29 one of the

8:31 kubernetes ecosystem provided uh

8:34 kubernetes config federation

8:37 and also we support the networking

8:40 federation my colleague is going to walk

8:42 through how that network federation

8:43 happens

8:44 and

8:45 so the other area is we support im and

8:48 rollback and multi-tenancy so in a

8:51 nutshell like you know we can

8:52 support a single unified cluster

8:56 or multiple kubernetes clusters

8:58 or if we have like you know different uh

9:01 use cases where we have to have multiple

9:04 ca2 clusters and they can be federated

9:06 using the q fed

9:08 i want to get down to a more fundamental

9:11 or maybe high level question which is

9:14 what is this replacing in my existing

9:15 kubernetes deployments am i using this

9:17 as a replacement for my container

9:19 networking like flannel or calico am i

9:22 using this to replace my

9:24 application gateways and ingress

9:26 gateways is this going to function as a

9:28 load balancer i'm just curious

9:30 what are the use cases and what am i

9:31 replacing

9:33 in my kubernetes cluster so the the

9:35 fundamental purpose of contrail is to

9:38 provide a cni so it's going to give you

9:41 the ability to deliver pod and service

9:43 networking like a flannel or calico

9:48 contrail

9:49 goes a little bit further

9:51 in

9:52 we also support the the set of load

9:54 balancer and service objects required to

9:57 expose the the applications themselves

10:00 so contrail will natively implement load

10:02 balancer objects and advertise the

10:04 external ip addresses out of the cluster

10:06 for reachability

10:08 um we're not replacing the ingress

10:10 controllers or any of the l7 load

10:12 balancers those still run on top of

10:14 control and they use the the load

10:16 balancer infrastructure to expose

10:19 uh the front end of the the

10:21 service mesh or the the load balancer um

10:25 to the external network

10:26 okay so we're really focused at a lower

10:28 layer here we're not we're not worried

10:30 about l7 at this point

10:32 l3 l4 yeah so that's basically what what

10:34 contra is going to give you is

10:36 everything around layer 3 a4 is provided

10:38 by

10:40 okay thank you

10:42 kind of building off what you just said

10:43 so if i'm doing this on on-prem i can

10:46 get rid of things like metal lb and

10:47 things like that contrail will take care

10:49 of that that load balancing

10:51 is that what i heard yeah exactly and

10:53 very very similarly we we advertise the

10:56 external ips out of the nodes using bgp

10:59 so whatever whatever router switch

11:01 you've got in the data center they'll

11:03 learn those external ips from the nodes

11:05 themselves you get

11:07 optimal routing to the endpoints

11:09 baseline here is that you don't need

11:11 necessarily an external load balancer

11:12 anymore

11:14 and also we support the application

11:16 based firewalling which is the l3 and l4

11:28 you