The name Kubernetes originates from Greek, meaning helmsman or pilot. Based on Borg, Google’s internal container orchestration platform, Kubernetes was introduced to the public as an open source tool in 2014.

That same year, Google donated Kubernetes to the Cloud Native Computing Foundation (link resides outside ibm.com), the open source, vendor-neutral hub of cloud-native computing. Since then, Kubernetes has become the most widely used container orchestration tool for running container-based workloads worldwide.

Kubernetes—also referred to as k8s or kube—was explicitly designed to automate the management of containers—the standard unit of software that packages up code and all its dependencies. The orchestration tool is highly valued for running quickly and reliably in any infrastructure environment, whether on-premises, private cloud, public cloud or hybrid cloud.

Unlike virtual machines (VMs) that virtualize physical hardware, containers virtualize the operating system, such as Linux® or Windows. Each container holds just the application’s libraries and dependencies. Because containers share the same operating system kernel as the host, they are considered lightweight, fast and portable.

Kubernetes and its ecosystem of services, support and tools have become the foundation for modern cloud infrastructure and application modernization. All major cloud providers, including Amazon Web Services (AWS), Google, Microsoft, IBM® and Red Hat®, integrate Kubernetes within their cloud platforms to enhance Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) capabilities.

Basic computer networking involves connecting two or more computing devices to share data and exchange resources, either by cables (wired) or wifi.

In physical networking, physical servers are connected to physical network equipment like switches, routers and Ethernet cables to connect to the internet. 

In virtual networking, software-defined networks (SDN), components like virtual ethernet devices and virtual interfaces are installed on bare metal servers or virtual machines to connect to the internet. Kubernetes deployment relies on SDN to configure and manage network communication across clusters.

Before delving deeper into Kubernetes networking, it’s worth reviewing basic networking terms:

Network host: A network host is any computer connected to a network that provides information, applications or services to other hosts or nodes on the network.

Internet protocol (IP) address: An IP address is a unique number assigned to every device connected to a network that uses the IP for communication. It identifies the device’s host network and the device's location on the host network.

Localhost: Localhost is a default hostname that acts as a private IP address, pointing directly to the computer or device they use.

Port: A port identifies a specific connection between network devices. A number identifies each port. Computers use port numbers to determine which application, service or process should receive particular messages.

Network address translation (NAT): NAT changes internal or private addresses to public or globally routable IP addresses, allowing for safe internet access. NAT enables one, unique IP address to represent an entire group of computing devices.

Node agents: Node agents are administrative agents that monitor application servers on a host system and route administrative requests to other servers.

Network namespace: A network namespace is a collection of network interfaces and routing table instructions that provides isolation between network devices.

Proxy or proxy server: A proxy provides a gateway between users and the internet. 

Kubernetes was created to run distributed systems with a network plane spread across a cluster of machines. In addition to providing interconnectivity between components, Kubernetes cluster networking creates a seamless environment where data can move freely and efficiently through software-defined networking.

Another distinct feature of Kubernetes networking is its flat network structure, which means all components can connect without relying on other hardware. In Kubernetes, every pod in a cluster can communicate with every other pod, no matter what node it is running on. The flat network provides an efficient way to share resources and eliminates the need for dynamic port allocation.

Overall, Kubernetes networking abstracts complexity, allowing developers and operators to focus on building and maintaining applications rather than dealing with intricate network configurations.

Kubernetes network policies are an application construct that plays a vital role in Kubernetes networking. These policies allow administrators and developers to define rules specifying how pods can communicate with each other and other network endpoints.

Network policies are applied by using the Kubernetes Network Policies API and consist of the following basic components: 

Pod selector: The pod selector specifies which pods the policy applies to based on labels and selectors.

Ingress: Ingress defines rules for incoming traffic to pods

Egress: Egress defines rules for outgoing traffic from pods.

Kubernetes network policies help define and manage security policies by defining rules that control which pods can communicate with each other, thus preventing unauthorized access and preventing malicious attacks.

Network policies also ensure isolation between pods and services so that only those pods or services can communicate with an allowed set of peers. For example, isolation is critical for multi-tenancy situations when DevOps or other teams are sharing the same Kubernetes cluster yet working on different projects.

For companies with specific compliance requirements, network policies help specify and enforce network access controls. This helps meet regulatory standards and helps ensure that the cluster adheres to organization policies.

Container Network Interface (CNI) is another essential feature tied to Kubernetes networking. Created and maintained by the Cloud Native Computing Foundation and used by Kubernetes and other container runtimes, including RedHat OpenShift® and Apache Mesos, CNI is a standardized specification and set of APIs that define how network plug-ins should enable container networking.

CNI plug-ins can assign IP addresses, create network namespaces, set up network routes, and so on, to enable pod-to-pod communication, both within the same node and across nodes.

While Kubernetes provides a default CNI, numerous third-party CNI plug-ins, including Calico, Flannel and Weave, are designed to handle configuration and security in container-based networking environments.

While each might have different features and approaches to networking, such as overlay networks or direct routing, they all adhere to CNI specifications that are compatible with Kubernetes.