Now a days, it's very difficult remember the vm passwords while connecting in the office network. So, Connect easily using sshpass.
For installation for mac/Linux:
Mac:
brew install hudochenkov/sshpass/sshpass
Linux:
yum install sshpass
Example of usage:
Ex:
sshpass -p test123 ssh root@192.168.1.1
Reafference:
https://stackoverflow.com/questions/32255660/how-to-install-sshpass-on-mac
The Single Root I/O Virtualization (SR-IOV) specification is a standard for a type of PCI device assignment that can share a single device with multiple pods.
SR-IOV enables you to segment a compliant network device, recognized on the host node as a physical function (PF), into multiple virtual functions (VFs), and make them available for direct IO to the POD.
Network Interface Cards (NICs) with SR-IOV capabilities are managed through physical functions (PFs) and virtual functions (VFs). A PF is used by the host and usually represents a single NIC port. VF configurations are applied through the PF. With SR-IOV CNI each VF can be treated as a separate network interface, assigned to a container, and configured with it's own MAC, VLAN, IP and more.
SR-IOV CNI plugin works with SR-IOV device plugin for VF allocation in Kubernetes. A metaplugin such as Multus gets the allocated VF's deviceID(PCI address) and is responsible for invoking the SR-IOV CNI plugin with that deviceID.
The end result will be similar to the in the picture except for the SRIOV-CNI and the DPDK userspace.
Reference:
https://github.com/ramanujadasu/sriov-cni
https://dramasamy.medium.com/high-performance-containerized-applications-in-kubernetes-f494cef3f8e8
Kubernetes is an open-source orchestration engine for automating deployments, scaling, managing, and providing the infrastructure to host containerized applications. At the infrastructure level, a Kubernetes cluster is comprised of a set of physical or virtual machines, each acting in a specific role.
Master components are responsible for managing the Kubernetes cluster. They manage the life cycle of pods, the base unit of a deployment within a Kubernetes cluster. Master servers run the following components:
kube-apiserver – the main component, exposing APIs for the other master components.
etcd – distributed key/value store which Kubernetes uses for persistent storage of all cluster information.
kube-scheduler – uses information in the pod spec to decide on which node to run a pod.
kube-controller-manager – responsible for node management (detecting if a node fails), pod replication, and endpoint creation.
cloud-controller-manager – daemon acting like an abstraction layer between the APIs and the different cloud providers’ tools (storage volumes, load balancers etc.)
Node components are worker machines in Kubernetes and are managed by the Master. A node may be a virtual machine (VM) or physical machine, and Kubernetes runs equally well on both types of systems. Each node contains the necessary components to run pods:
kubelet – watches the API server for pods on that node and makes sure they are running
cAdvisor – collects metrics about pods running on that particular node
kube-proxy – watches the API server for pods/services changes in order to maintain the network up to date
container runtime – responsible for managing container images and running containers on that node
Reference:
https://www.suse.com/c/rancher_blog/understanding-the-kubernetes-node/#:~:text=kubelet%20%E2%80%93%20watches%20the%20API%20server,the%20network%20up%20to%20date
