Prior to initializing the Kubernetes cluster, the network must be considered and IP conflicts avoided. There are several Pod networking choices, in varying levels of development and feature set.

Many of the projects will mention the Container Network Interface (CNI), which is a CNCF project. Several container runtimes currently use CNI. As a standard to handle deployment management and cleanup of network resources, CNI will become more popular

Calico

A flat Layer 3 network which communicates without IP encapsulation, used in production with software such as Kubernetes, OpenShift, Docker, Mesos and OpenStack. Viewed as a simple and flexible networking model, it scales well for large environments. Another network option, Canal, also part of this project, allows for integration with Flannel. Allows for implementation of network policies. https://www.tigera.io/

Flannel

A Layer 3 IPv4 network between the nodes of a cluster. Developed by CoreOS, it has a long history with Kubernetes. Focused on traffic between hosts, not how containers configure local networking, it can use one of several backend mechanisms, such as VXLAN. A flanneld agent on each node allocates subnet leases for the host. While it can be configured after deployment, it is much easier prior to any Pods being added. https://github.com/flannel-io/flannel

Kube-Router

Feature-filled single binary which claims to "do it all". The project is in the alpha stage, but promises to offer a distributed load balancer, firewall, and router purposely built for Kubernetes. https://www.kube-router.io/

Romana

This is another project aimed at network and security automation for cloud native applications. Aimed at large clusters, IPAM-aware topology and integration with kops clusters. https://github.com/romana/romana

Weave Net

It is typically used as an add-on for a CNI-enabled Kubernetes cluster. https://www.weave.works/oss/net/

More Installation Tools

Since Kubernetes is, after all, like any other applications that you install on a server (whether physical or virtual), all of the configuration management systems (e.g., Chef, Puppet, Ansible, Terraform) can be used. Various recipes are available on the Internet.

Additional Installation Tools

kubespray

kubespray is now in the Kubernetes incubator. It is an advanced Ansible playbook which allows you to set up a Kubernetes cluster on various operating systems and use different network providers. It was once known as kargo. https://github.com/kubernetes-sigs/kubespray

kops

kops (Kubernetes Operations) lets you create a Kubernetes cluster on AWS via a single command line. Also in beta for GKE and alpha for VMware https://github.com/kubernetes/kops

kube-aws

kube-aws is a command line tool that makes use of the AWS Cloud Formation to provision a Kubernetes cluster on AWS. (no page found)

kind

Kind is one of a few methods to run Kubernetes locally. It is currently written to work with Docker.

Main Deployment Configurations

At a high level, there are four main deployment configurations:

Single node

All the components run on the same server on a single-node deployment. This is well suited for testing, learning, and developing around Kubernetes.

Single head node, multiple workers

The topology is a single head node and multiple workers. This typically will consist of a single node etcd instance running on the head node with the API, the scheduler, and the controller-manager.

Multiple head nodes with High Availability (HA) and multiple workers

Multiple head nodes in an HA configuration and multiple workers add more durability to the cluster. The load balancer sits as the frontend of an API server and the scheduler and the controller-manager will elect a leader (which is configured via flags). The etcd setup can still be single node.

HA etcd, HA head nodes, multiple workers

The most advanced and resilient setup would be an HA etcd cluster, with HA head nodes and multiple workers. Also, etcd would run as a true cluster, which would provide HA and would run on nodes separate from the Kubernetes head nodes.

The use of Kubernetes Federation also offers high availability. Multiple clusters are joined together with a common control plane allowing movement of resources from one cluster to another administratively or after failure. While Federation has some issues, there is hope v2 will be a stronger product.