“Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road.” –Stewart Brand

In part 1 of the beginner's guide we looked at what a container is. How Docker Engine supports the workflows involved in building, shipping and running the container-based environment and also how Kubernetes coordinates this environment across multiple machines, providing scalability, high availability, and most importantly predictability.

In part 2 we will focus on Kubernetes purely within the realms of open networking. We will look at how communication takes place between clusters consisting of various nodes and pods and the technologies that implement this. As promised, we will also look at the industry’s first Cloud Native Network Operating System (CN-NOS) from SnapRoute, and how being built on a containerized, microservices architecture with embedded Kubernetes enables rapid and efficient application deployment and operations.

Kubernetes Networking

Kubernetes is all about sharing machines between the applications, so understanding how they communicate is essential. The first important element to understand is that every Pod gets its own IP address. This means you do not have to create links between the Pods and also negates the need to map host ports to container ports, as is done in the Docker networking model. Pods can now be treated very similarly to VMs or physical hosts with respect to naming, port allocation, load balancing, migration and more.

So, each Pod within the Kubernetes cluster now has its own unique IP address which allows for Pod-to-Pod communication without the need for Network Address Translation (NAT). The containers within these Pods behave as if they were on the same host when it comes to networking, and they can all reach each other’s ports on the localhost. This offers simplicity, security, performance and also uncomplicates the process of moving applications from uncontainerized physical or virtual hosts.

There are a number of ways this network model can be implemented as Kubernetes does not provide a default approach. Some of the more popular ones include Flannel, Project Calico and Weave Net. I want to focus on two technologies that will implement the model required but also serve the entire Data Center, or multiples of, in the case of Big Switch.

AOS from Apstra – Apstra Operating System (AOS) is an Intent Based Network (IBN) system that creates and manages Data Center environments. With IBN you tell the network what you want it to do and AOS looks after the how part. AOS supports L3 connected hosts (Linux servers) that create BGP neighbouring relationships with the top of rack switches (TORs). It automates the routing adjacencies and then provides fine-grained control over the route health injections (RHI) which are commonplace in Kubernetes deployments.

AOS has a rich set of REST API endpoints that allow Kubernetes to rapidly change network policy based on the requirements of the applications. AOS also supports equipment from a multitude of vendors which includes whitebox switches from Edgecore and Delta running a variety of network operating systems (NOS) such as CumulusLinux, SONiC and OpenSwitch. Webinar with Apstra.

Big Cloud Fabric from Big Switch Networks – Big Cloud Fabric (BCF) leverages software-defined networking (SDN) to provide one big “logical switch” governed by a centralized controller. This solution delivers simplified network operations, visibility and telemetry of containers and their hosts, and network automation for rapid application and micro-services deployment. The scale-out architecture of BCF also accommodates future growth in east-west traffic, caused by an increase in micro services deployment, without costing an arm and a leg.

With the help of the Big Cloud Fabric’s virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat, OpenShift and Docker Swarm will be natively integrated with VM orchestration systems such as VMware, OpenStack & Nutanix. Engineers will be able to securely interconnect any number of these clusters and enable inter-tenant communication between them if needed.

Its SDN architecture works on open industry-standard switch hardware from Edgecore, Delta and Quanta, which allows vendor choice and also reduces costs.

You can watch their Kubernetes Demo here!

SnapRoute’s Cloud Native Network Operating System (CN-NOS)

The final element of today’s blog is a closer look at CN-NOS. I have written about SnapRoute in previous blogs but only in a very general way, briefly explaining the general idea of a Cloud Native NOS. It’s time for a more comprehensive analysis.

Key Features

• Leverages Kubernetes natively so it is now possible to load only what is required for your use case. With other NOS vendors the full protocol stack is downloaded even though only a fraction is used.
• CN-NOS offers Continuous Integration/Continuous Deployment (CI/CD). The key protocols and services are containerized as microservices, then orchestrated using Kubernetes. This allows network teams to synchronize with their colleagues in compute and storage.
• Upgrades to protocols and services can be done surgically for the first time. You do not need to disrupt systems and reboot entire switches. Patches and upgrades can be done in a targeted manner.
• CN-NOS provides the highest level of automation and orchestration because of the use of Kubernetes. Operators can now manage the data center from end to end, alleviating risk and complexity while adding predictability.

These are just a few of the extra benefits that CN-NOS brings to the table as SnapRoute attempts to drag networking kicking and screaming into the Cloud Native era.

As always, I would be more than happy to share additional resources with you or for more technical information on products or SDN give me a shout also you can browse our Open Networking products here.

Slán go fóill,
Barry

Glossary of Terms

• IoT – Internet of Things
• 5G – 5th generation of cellular mobile communication
• Linux – Family of free open-source operating systems
• ONF – Open Networking Foundation
• OCP – Open Compute Project
• SDN – Software Defined Networking
• Edgecore – White box ODM
• Quanta – White box OEM
• Data Plane – Deals with packet forwarding
• Control Plane – Management interface for network configuration
• ODM – Original design manufacturer
• OEM – Original equipment manufacturer
• Cumulus Linux – Open network operating system
• Pluribus – White box OS that offers a controllerless SDN fabric
• Pica8 – Open standards-based operating system
• Big Switch Networks – Cloud and data Center networking company
• IP Infusion – Whitebox network operating system
• OS – Operating system
• White Box – Bare metal device that runs off merchant silicon
• ASIC – Application-specific integrated circuit
• CAPEX – Capital expenditure
• OPEX – Operating expenditure
• MAC - Media Access Control
• Virtualization – To create a virtual version of something including hardware
• Load Balancing – Efficient distribution of incoming network traffic to backend servers
• Vendor Neutral - Standardized, non-proprietary approach along with unbiased business practices
• CORD – Central Office Rearchitected as a Data Center
• SD-WAN – Software Defined Wide Area Network
• NFV – Network Function Virtualization
• RTBrick – Web scale network OS
• Snap Route – Cloud native network OS
• MPLS – Multiprotocol label switching
• DoS – Denial of service attack
• ONOS – ONF controller platform
• LF – Linux Foundation
• MEC – Multi-access edge computing
• Distributed Cloud -
• COMAC – Converged Multi-Access and Core
• SEBA – SDN enabled broadband access
• TRELLIS – Spine and leaf switching fabric for central office
• VOLTHA – Virtual OLT hardware abstraction
• R-CORD- Residential CORD
• M-CORD – Mobile CORD
• E-CORD – Enterprise CORD
• PON – Passive optical network
• G.FAST – DSL protocol for local loops shorter than 500 metres
• DOCSIS – Data over cable service interface specification
• BGP – Border gateway patrol routing protocol
• OSPF – Open shortest path first routing protocol
• DSL – Digital subscriber line
• Container – Isolated execution environment on a Linux host
• Kubernetes – Open source container orchestration system
• Docker – Program that performs operating-system-level virtualization
• Cloud Native – Term used to describe container-based environments
• CNCF – Cloud Native Computing Foundation
• API – Application Programming Interface
• REST API – Representational State Transfer Application Programming Interface
• CLI – Command Line Interface
• VM – Virtual machine
• NAT – Network Address Translation
• IBN – Intent Based Networking
• TORs – Top of Rack Switches
• RHI – Route Health Injections
• BCF – Big Cloud Fabric
• VPC – Virtual Private Cloud
• ONIE – Open Networking Install Environment
• CI/CD - Continuous Integration/Continuous Deployment