KubeCon + CloudNativeCon Europe 2021 Virtual

Note: LIVE panel. The Cloud Native networking landscape is particularly frightening. With the advent of service mesh and containers being deployed in the tens of thousands, L4/L7 load balancing, plus networking implementations for each public cloud being different, it's important for application developers and devops audiences to understand the nuances of Cloud Native networking.

The panelists, all cloud native networking experts including the Kubernetes Networking SIG chair, etc. will go into some of the fundamental design challenges and address some advanced scalability issues. We will include select questions from the audience as well.

This panel, intended for application developers and devops audience will look at the Cloud Native networking ecosystem, past present and future. Attendees will walk away with a better understanding of the challenges of some of the tools for the trade and how to best implement Cloud Native networking best practices.

One of the best ways to learn about something is to understand how you can break it. In this talk, we will look at all the different ways you can break your Kubernetes cluster with networking. Learn from this before you learn in production. Misconfigured DNS, DNS, unreliable network protocols and DNS, DNS rate-limiting, network policy side effects, NodePort surprises, MTU and Kubernetes, effects of Kubernetes networking on distributed databases, network rate-limiting effects, bootstrapping race conditions, unexpected service behavior, sudden breakages at scale, and more. The list of potential ways to break your cluster is long. Half a decade of CNI development experience while working with many, many Kubernetes users as a maintainer of one of the leading open-source CNI projects have gone into this talk. It will be fun, you will laugh, and hopefully, in the end, you will avoid some of what others have already experienced.

Existing networking APIs like Ingress and Service were designed in the very early days of Kubernetes. They got many things right, but it was quite difficult or even impossible to use those APIs for more advanced use cases. This resulted in a proliferation of implementation-specific annotations and custom resources that fragmented the user experience and have proven to be difficult to evolve. The Kubernetes networking SIG has been developing a new set of APIs that aim to solve these problems. The Gateway APIs project defines Kubernetes APIs to configure advanced concepts like traffic splitting, header matching, and load balancing configuration. In this talk, Harry and Rob will provide an overview of these APIs and some insight into the design decisions that have been made along the way. They will demo some of the advanced capabilities of these APIs, showcasing the portability of the APIs across implementations. Finally, they will provide a roadmap for the future of this project.

Kubernetes project evolution and its ecosystem is demanding new and more complex network requirements: multi-cluster and multi-zone connectivity, service topology awareness, traffic engineering, quality of service, ... KIND is a tool for running local multi-node Kubernetes clusters using Linux containers, it leverages current Linux networking capablities to emulate the cluster networking in a nested environment. This flexibility can be used to emulate more complex scenarios, let's go through some of these Kubernetes networking scenarios, and demonstrate how to use KIND to emulate and test them.

Cloud Native Network Functions (CNFs) will be the cornerstone of the 5G revolution. Unlike traditional workloads, CNFs require access to high speed network interfaces. Unfortunately, Kubernetes traditional networking does not fulfil this requirement out of the box. In order to close these gaps, a new specification has been developed called the Device Information Specification, which expands the existing multi-net specification developed by the Network Plumbing Working Group (NPWG). It not only enriches the information about the network interfaces, but also allows new accelerated technologies to be added and consumed by CNFs using an API-compliant library. This session will give an overview of the Device Information Specification and provide details of how it enables new network accelerating technologies to be integrated into Kubernetes through an end-to-end example.

Users want more out of their existing clusters. As demand increases, they would like to increase the size of their clusters by adding more nodes and pods (scaling horizontally). One of the key limitations in doing this is immutability of IP addresses. Providing each additional node and pod an IP, quickly exhausts users’ initial IP allocations. They must resort to optimizing IP addresses in their existing clusters, or pre-emptively over-allocating IP addresses during cluster creation time. With Discontiguous Pod and Node CIDRs, IP addresses become a mutable resource that can be added post-cluster creation thereby helping in the growing the cluster dynamically. Adding support for disjoint CIDRs also allows fitting clusters into fragmented IP spaces, a problem commonly faced by enterprise customers. This talk will describe how GKE solves the problem for customers and the lessons learnt along the way. This talk also proposes ideas on how to solve this natively in Kubernetes.