DO NOT USE

• The Kubernetes network model provides simplicity and consistency across a range of networking environments and network implementations.
• Pods can be treated much like VMs or hosts since they all have unique IP addresses.
• Containers within Pods are like processes running within a VM or host--they run in the same network namespace and share an IP address.
• This model makes it easier for applications to migrate from VMs and hosts to Pods managed by Kubernetes.
• Because isolation is defined using network policies rather than the structure of the network, the network remains easy to understand.
• Kubernetes supports mapping host ports through to Pods, or running Pods directly within the host network namespace sharing the host’s IP address.
• The type of network a container uses is transparent from within the container, whether it is a bridge, an overlay, a MacvLan network, or a custom network plugin.
• From the container’s point of view, it has a network interface with an IP address, gateway, routing table, DNS services, and other networking details, assuming the container is not using a non-network driver.
• Kubernetes’ built-in network support, kubenet, provides some network connectivity.
• Cluster IP is a virtual IP, which is actually a fake IP network.
• Service can provide a unified entry address for a group of container applications with the same function and distribute the request load to each container application in the back-end.
• Cluster IP only acts on the Kubernetes Service object and is managed and assigned IP addresses by Kubernetes from the Cluster IP address pool.
• CNI is a networking library that enables containers on a host to attach to different networks.
• Multus is a CNI plugin for Kubernetes that enables attaching multiple network interfaces to Pods.
• This solution provides SR-IOV support in Kubernetes through a CNI plugin.
• CNI lacks support for physical platform resource isolation.
• The solution is to allow SR-IOV support in Kubernetes through a CNI plugin, which supports two modes of operation.
• SR-IOV VFs are allocated to pod network namespace and are bounded to DPDK drivers in user space.
• However, SR-IOV CNI has no mechanism to expose the number of VFs available in a host, and allocated network resources are not guaranteed from the same NUMA node.
• To resolve these issues, the device plugin is used as shown in this diagram.
• Container networks are a way to use multiple containers on a single machine to improve performance.
• One way to use container networks is with CNI, which is a plugin designed to implement kernel-space networking.
• Another way to use container networks is with a service mesh, which is a way to control or monitor traffic between Pods and Services.
• One way to do this is with a service mesh container injected into every Kubernetes node.
• Another way to do this is with a service mesh container injected into every Pod or sidecar.
• With service mesh, Intel technology enables crypto acceleration through Intel Advanced Vector Extensions 512 and Intel QuickAssist Technology.
• All optimizations are now natively available in Envoy. Developers using Envoy-based solutions will see benefits out of the box on Intel Xeon 3rd Gen Scalable Processor platforms and beyond.

Test your knowledge of Kubernetes networking, container network models, CNI, and other related concepts with this quiz. Explore key features such as network policies, network support, service mesh, and performance optimizations.