KubeCon + CloudNativeCon Europe 2023

Are you currently storing data to PVCs? Have you found difficulty in sharing the data across Kubernetes namespace? If yes, this is the talk for you. Kubernetes supports provisioning volumes from a variety of data sources, like PVCs, VolumeSnapshots, and CRDs (beta in Kubernetes 1.24). However, data sources are restricted to exist in the same namespace. Due to this restriction, sharing data between namespaces has been difficult. As a result, use cases like copying volumes from a production namespace to a development namespace for testing and copying golden images in one namespace to other consuming namespaces can't be achieved without administrators' help. To solve this issue, provision of volumes from cross-namespace data sources (KEP-3294) is planned to be supported as alpha feature in Kubernetes 1.26. This talk will explain how users can use this feature and how it works with demos.

Gateway API and the MCS API are two pieces of your multicluster traffic management puzzle: Gateway API provides advanced routing capabilities and the MCS API provides cross cluster service discovery. These two Kubernetes native APIs are sponsored by SIG-Network and SIG-Multicluster, respectively. How can these two APIs work together? How have they evolved, separately and as part of a larger upstream initiative to make the multicluster experience feel native? Both APIs are CRD-based, and each SIG focused on standards over details, leaving implementers plenty of room; so how have users dealt with the challenges to discover, install, and maintain synergistic controllers? Finally, where do they fit with the larger ecosystem of service discovery solutions, including service meshes and vendor specific tooling? Another project, the GAMMA initiative, sits smack between all of these, seeking to unify the east-west traffic management puzzle along one coherent, standards-driven direction. Answering these questions and more, join us for a panel style discussion with representatives from the Gateway API project, MCS API project, and GAMMA initiative. Our panelists will speak from their experience both developing the upstream standard and actually implementing the APIs with different vendors.

So you’ve deployed an app to two geographically dispersed Kubernetes clusters, trying to improve performance or reliability? Great! Now you must ensure requests always reach the correct cluster(s)! Easy? Yes, if you choose a completely open source, cloud native, global load balancing solution for Kubernetes instead of traditional complex and expensive network components. Enter k8gb, CNCF sandbox project that can be deployed to any conformant Kubernetes cluster, does not have a single point of failure, and is already adopted by several financial institutions! This dual presentation is delivered by the original creator of the project and the cloud architect who runs k8gb in a real-life production environment.

Kubernetes is a scalable distributed system and networking is a central part of it. IPv6 is an important protocol for Kubernetes, because it solves the problem about IP address exhaustion. The project has been working on implementing it for a long time, supporting IPv6 single-stack clusters since its version 1.18, and dual-stack clusters since version 1.23 March 2020. Kubernetes is also an Open Source project, driven by the community, and the development doesn’t follow a strict and well documented process, with architectural decisions and implementation details not being well documented at times. However, the project is very serious abouts its APIs, with a strong commitment to not breaking compatibility. This allows the project to have a quick feedback loop delivering new features, and allows other projects to have an opportunity to add. During this talk Antonio Ojea, Kubernetes maintainer and developer, and Fernando Gont, author of multiple IETF IPv6 protocol specifications , will do an exhaustive analysis of the Kubernetes IPv6 architecture and take a look “under the hood” to explain the myths, legends and realities of IPv6 in Kubernetes.

Load balancers are a critical part of application ingress for Kubernetes clusters. One of the simplest ways of achieving this is creating a Service and specifying the type `LoadBalancer`. Kubernetes applies a simplistic interpretation of the cluster's networking state when configuring the load balancers with the set of nodes to be used as backends. This model introduces some serious failure modes for application ingress when the model becomes decorrelated and is completely orthogonal to the state of the application itself. Load balancers may not have the most up to date node set, go through unnecessary reconfigurations, and blindly route traffic without an application specific healthcheck. Moreover, the current mechanism has also proven to be computationally suboptimal and misses a lot of opportunities for more production-grade approaches such as allowing load balancers to dynamically route application related traffic without the need for reconfiguration. This talk will walk through the current implementation, the existing problems and the proposed north star. Alexander and Swetha will cover how the refactored support will better uphold application SLA.

Kubernetes has become the lingua franca for cloud native applications. It has been a revolution since its first release, in 2015, filling the gap in the IT industry for container orchestration and improving the efficiency in software development, experiencing exponential adoption and growth. Long gone are those days that Kubernetes was used only in the Cloud, and it has progressively extended to many areas like the edge and on premises data centers. However, due to rapid adoption, its implementation inside the organizations may not be planned holistically, with different teams implementing different Kubernetes clusters leading to inconsistencies that are operationally difficult to manage. This situation presents a new challenge when these ops teams have to collaborate: How can they connect their Services? How do they communicate their workloads? How do they secure these communications? Multi cloud and hybrid cloud are real problems, in this panel of architects and practitioners, we explore cross-cloud connectivity challenges and share insights on how to solve infrastructure performance, implement golden signals to monitor the disparate cloud environments.

Kubernetes promises that we can run containerized workloads in any cloud, and according to a recent article InfoWorld “2023 may [finally] be the year of multicloud Kubernetes”. For this to happen, we need seamless connectivity between workloads across clusters, regardless of the cloud they’re running on. From the perspective of a developer, shouldn’t connectivity across clouds be as simple as connectivity within a cluster? This talk explores - and demonstrates - how Cilium and its ClusterMesh feature can take care of many aspects of connectivity across multiple clusters in a cloud-agnostic way. It will show how just a few additional lines of YAML in your existing Kubernetes resources can enable: - Connectivity between services spread across clouds - Load balancing requests across backends in multiple clusters - Connectivity between Kubernetes and legacy workloads - Mutually-authenticated, encrypted connections between services - Multi-cluster network policies The talk will also discuss some of the challenges related to IP address management, scale, and observability of multi-cluster networks, and how Cilium can help.