KubeCon + CloudNativeCon Europe 2020

When building services with etcd, one of the best features of etcd is watchers. It allows developers to create applications such that when a dataset is changed, the watcher for that dataset on another system receives the notification and performs user-specified action. A simple use case is a user has a program using etcd watchers to monitor the stock market and sell (user-defined action) if their stock of interest falls below price $X.

There are error failures that are not automatically covered with an etcd cluster such as network connectivity issues, DC outage, and cloud infrastructure maintenance. The talk consists of the following:
- what watchers are
- how to build your services using heartbeat key for monitoring etcd watchers
- perform locking on watchers to prevent race conditions
- caching data locally for your service to keep running until the etcd cluster is back up.

A very simple question but with many different answers when asked. Kubernetes should provide a ground set of concepts that allows interoperability of systems and a shared knowledge in the ecosystem. In any kubernetes distribution, a Pod or a Service have the same definition, this is not the case for application. As end-users are mainly managing apps, it's time for kubernetes to get a representation and a definition of it. 
The sig-apps community came to an agreement to provide this missing piece. They created a new Application resource and its controller. This talk is bringing light to this new upstream resource, the features it provides with concrete examples, and the next steps and how to get involved. 

While there are many resources online about internationalization (i18n) in general, there are Kubernetes-specific lessons that we learned at Buoyant in the process of internationalizing Linkerd’s web dashboard that are vital for end users and CNCF project maintainers alike who are building robust, global projects.

This lightning talk will share Linkerd’s recent i18n journey, including

- Why internationalizing user-facing features affects your project's success
- What i18n has to do with accessibility (a11y)
- What we applied -- and what we didn’t! -- from the K8s community’s i18n practices
- Kubernetes-specific pitfalls when internationalizing content

Audience members will leave with an accessible, easy roadmap to go from i18n idea to execution, with minimal organizational hiccups.

What is a well-designed CLI?
How do we develop it?

Kubernetes is widely spread and people start to be interested in Day2 Operation. Along with this, the number of kubectl plugins is developed recently.

In this presentation, Aya Igarashi will talk about how to improve the design and develop a kubectl plugin based on her experience. She develops kubectl-bindrole which is a kubectl plugin that summarizes permissions for an RBAC account.
https://github.com/Ladicle/kubectl-bindrole

This session will be helpful for people who want to develop kubectl plugins, as well as for general CLI development.

As we work harder to automate our clusters, it becomes more and more difficult to guarantee the availability requirements of our applications. In large clusters, operations teams may not have the insights to ensure an applications minimum capacity requirements are maintained. Without that understanding, you may inadvertently bring down or inhibit applications through routine maintenance activities.

Enter the Pod Disruption Budget (PDB). Simply put, PDBs allows application owners to define the minimum requirement for a service to operate in a stable manner.

In this Lightning Talk, let me walk you through the benefits, usage and implementation of PDB’s. As an attendee, you will walk away with the necessary knowledge on how to use PDBs to define enforceable operating requirements of your applications.

Have you ever considered contributing to Envoy?
What stops you?
Is it C++?
Is it completely different toolset?
Just don't feel yourself productive?
Well, we've got some news for you.
Thanks to a shiny, brand-new technology (WebAssembly), Envoy is becoming a polyglot.
And putting the human factor first, it means that now You can contribute using the toolbox that works best for You.
Paraphrasing, a demo is worth a thousand words.
Let's pick a language that everybody claims to be good at (JavaScript) and, surprisingly, use it to extend Envoy.
We'll do it live, under 5 minutes and have fun along the away (instead of cursing the-never-ending C++ compilation).

Managing configuration doesn't have to be complex, this lightening talk will show a super simple pattern for having configuration live within your repo and deployed to your Kubernetes cluster as a Secret or ConfigMap using a CD pipeline.

This is done using a CLI tool from Mozilla known as SOPS, with an envelope encryption model based on a master key supplied by a cloud based KMS provider such as AWS and a CD pipeline implemented using CircleCI. This pattern keeps your configuration secure, but allows it to be controlled in version control, under code-review and released using your build pipeline.

Cloud Native Network Function (CNF) is a software implementation of a network function, traditionally performed on a physical device (e.g. IPv4/v6 router, L2 bridge/switch, VPN gateway, firewall), but built and deployed in a cloud-native way.

This talk will show a live demo on how a CNF providing cloud-native NAT (Network Address Translation) functionality can be built and deployed into a Kubernetes cluster within 5 minutes. To achieve that, several open source projects will be used: FD.io (an open source terabit software dataplane), Ligato.io (programming framework for building CNF control and management plane) and Network Service Mesh for interconnecting CNFs in a Kubernetes cluster on required network layers.