Date
Minutes
- Pragash and Yuvaraja presenting slides
- k8s to TF object mapping
- Namespace → single project or shared project
- Pod → VM
- Service, Ingress, Network Policy each have their own analogs in TF
- A single TF controller can manage multiple different types of clusters
- Non-nested, nested (cluster inside of a cluster), standalone
- Namespaces with TF & k8s
- By default in k8s, all pods can talk to all other pods in the cluster
- Can also isolate them via namespace
- Each namespace maps to a Project in k8s
- Pod gets the IP from a controller…
- For every namespace in the cluster, create a virtual network
- Start with two by default (pod network and service network)
- To isolate things with namespaces, can create isolated networks accordingly
- Example of how this looks in the TF GUI
- Syed: When associated networks to a pod with a CRD, how do you ensure that the container in the network gets the appropriate route?
- Multi interfaces in the pod
- Create the networks in the CRD
- Queue manager then uses annotations to give things to the controller, that will set up the correct interfaces for the container
- Syed: But how do you set the routing within the container?
- To steer the package inside the container, add the static routes (manual process)
- Plan to enhance this in the future
- Pod creation workflow
- When a pod is created, TF kubemanager creates a VM, interfaces, and associates with the right vrouter (on the kubemanager side)
- Same for updated pod
- Kubelet actually gets the same information
- Creates a boss container w/pod, labels, etc
- The kubelet triggers a call to the CNI
- CNI calls the vrouter, which get the information from TF controller
- Multi-interface for pod
- Kubernetes Network policy
- Which (groups of) pods are allowed to talk to each other and how they can communicate iwth other endpoints
- k8s network policy was in TF4 then had to rethink it for TF5.
- TF4: Security groups
- TF5: Firewall security policy
- Tags for labels, pods, etc
- Framework to enforce access specification across workloads
- workloads rep'd and grouped by tags
- A lot easier to do intent-based
- It's k8s native firewalling policy
- k8s network policy constructs map directly to TF firewall policy constructs
- Can customise network policies to shape the flow of traffic how you want/need
- Currently default allow, but can deny by default by creating a network policy
- Service chaining
- Live demo! (should the demo gods allow)
Action items
- Type your task here. Use "@" to assign a user and "//" to select a due date.