Container Network Interface

• Despite the name, actually does not perform any of the load balancing

• Sets up configuration

• CNI Spec

  

  

# /etc/cni/net.d/10-ashish.conf.  (convention of number-name, doesnt matter listes first anyways)

{
	"cniVersion" : "1.0.0",
	"name" : "fromScratch",
	"type" : "ashish" # very important- /opt/cni/bin/ashish
}

/opt/cni/bin/ashish ; ashish executable in in this place. can be written in anything, go/bash etc.

Containers do not have kernel. They utilize kernel feature known as namespaces. These namespaces allocate system resources, such as interfaces, to specific namespaces, preventing those resources from being visible in other namespaces of the same type.

Demystifying CNI

Summery of https://www.youtube.com/watch?v=WmSNPtwOb0Y -

https://github.com/f1ko/demystifying-cni

CRI : from Instantiating pod to configuring CNI

• User sends a spec to deploy container to Kube api-server
• It tells the Kubelet inside node to create a container. Kubelet calls the CRI creates a container.
• And then uses the CNI spec to call the CNI plugin to configure the networking for the container. We call CNI plugin as CNI itself for simplification.

Diagram :

CRI creates the network namespace.

It loads the first file located in /etc/cni/net.d/