0.4 cloud-native-rejekts-eu-2019 2019-05-18 2019-05-19 2 00:05 https://cfp.cloud-native.rejekts.io https://cfp.cloud-native.rejekts.io/media/cloud-native-rejekts-eu-2019/img/EU_Rejekts_White_X_Transparency.png UTC Main Hall Opening 2019-05-18T09:00:00+00:00 09:00 00:45 Doors and registration desk open to receive attendees. cloud-native-rejekts-eu-2019-51-day-1-registration-reception Break TBA en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/DTLE89/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/DTLE89/feedback/ Main Hall Opening 2019-05-18T09:45:00+00:00 09:45 00:10 We look to welcome and provide information to all attendees. cloud-native-rejekts-eu-2019-49-cloud-native-rejekts-opening Cloud Native Chris Kuehl en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/CPJPCG/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/CPJPCG/feedback/ Main Hall Talk 2019-05-18T10:00:00+00:00 10:00 00:30 I will demo how to use different BPF tools in the Kubernetes developer workflow. Then, I will explain how it works and what support it requires from the Kubernetes installation. cloud-native-rejekts-eu-2019-25-using-bpf-to-debug-your-kubernetes-application Cloud Native Alban Crequy en BPF tools for tracing your Linux system is an area with a lot of developments. This has happened in the bcc project and in bpftrace project. Until recently, bcc and bpftrace were designed to trace one Linux system. This is changing with kubectl-trace, a tool adapting bpftrace for the Kubernetes workflow. I’ll present how to use kubectl-trace to trace a Kubernetes pod. I will also present new tools based on bcc to trace syscalls or files opened by a specific pod. Finally, I will explain how it works and what support it requires from the Kubernetes installation. Slides: https://tinyurl.com/rejekts-bpf-kubernetes false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/VBYM33/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/VBYM33/feedback/ Main Hall Talk 2019-05-18T10:40:00+00:00 10:40 00:30 Have you ever been asked the question - “How do we make sure Kubernetes resources conform to our internal policies and procedures?”. In this session we introduce, how you can audit, validate and mutate Kubernetes resources based custom semantic rules during create, update, and delete operations without recompiling or reconfiguring the Kubernetes API server using Gatekeeper - a policy controller for Kubernetes. cloud-native-rejekts-eu-2019-48-building-flexible-policy-with-opa-and-kubernetes Cloud Native Rita ZhangMax Smythe en Every organization has rules, whether it be that each resource needs to be labelled a specific way or to only use images from specific container repositories. Some of these rules or policies are essential to meet governance or legal requirements and may be based on learning from past experiences. In this session we introduce, how you can audit, validate and mutate Kubernetes resources based custom semantic rules during create, update, and delete operations without recompiling or reconfiguring the Kubernetes API server. These policies are all backed by the Open Policy Agent (OPA), which is a lightweight, general-purpose policy engine for cloud-native environments. We will also demonstrate the work that is being done in the upstream community and provide working samples to start your journey building scalable policy on Kubernetes. Open Source Repository - https://github.com/open-policy-agent/gatekeeper false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/MKZDRL/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/MKZDRL/feedback/ Main Hall Talk 2019-05-18T11:35:00+00:00 11:35 00:30 I will explain the overview of the architecture around Firecracker and container runtimes. Then I will show demos for a proof-of-concept implementation. cloud-native-rejekts-eu-2019-39-evaluating-firecracker-as-a-container-runtime-engine Cloud Native Dongsu Park en Firecracker, an open-source project published by Amazon, opens up a lot of interesting perspective to the container ecosystem. It opens up use cases between containers and VMs, making use of KVM without relying on heavyweight Qemu instances. Its integration with the Kubernetes ecosystem has only started its first step with containerd. Obviously it’s a good starting point. However, it's also time to think about how we should get the new shape of containers integrated with all other high-level container runtimes. In this talk, I would like to talk about alternative ways of integration for getting Firecracker integrated with multiple container runtimes. A proof-of-concept implementation will be also presented during the talk. From the side of Firecracker, its integration with the Kubernetes ecosystem has only started its first steps, only with containerd & Kata containers. For the diversity of Kubernetes ecosystem, however, we should also think about how we should get Firecracker integrated with all other high-level container runtimes in the cloud-native ecosystem. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/XT9PEB/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/XT9PEB/feedback/ Main Hall Talk 2019-05-18T12:15:00+00:00 12:15 00:30 Because the kernel knows more than your programs. cloud-native-rejekts-eu-2019-13-prometheus-as-exposition-format-for-ebpf-programs Cloud Native /media/cloud-native-rejekts-eu-2019/images/GRK7DW/Screenshot_2019-05-18_at_03.03.26.png Leonardo Di Donato en Nowadays every application exposes their metrics via an HTTP endpoint readable by using Prometheus. Recently the exposition format got included into the OpenMetrics standard of the CNCF. Nevertheless, this very common pattern by definition only expose metrics regarding the specific applications being observed. This talk wants to expose the idea, and a reference implementation, of a slightly different use case that uses **eBPF** programs as a source of information to allow the exposition and collection of kernel and application probes via a **Prometheus** endpoint. After having showed the architecture of the proposed reference implementation - a Kubernetes operator with a custom resource for BPF programs - we'll demo the entire solution to grab and present some metrics without having touched any application running on the demo cluster. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/GRK7DW/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/GRK7DW/feedback/ Main Hall Break 2019-05-18T12:50:00+00:00 12:50 01:30 Lunch time! cloud-native-rejekts-eu-2019-53-lunch Break TBA en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/BTN3CX/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/BTN3CX/feedback/ Main Hall Talk 2019-05-18T14:20:00+00:00 14:20 00:30 I will describe a GitOps based deployment workflow that makes your Kubernetes deployments secure, auditable, and simpler and the process the process and tools you need to put it in place on any cloud. cloud-native-rejekts-eu-2019-15-highly-effective-kubernetes-deployments-with-gitops Cloud Native Edaena Salinas en Over the last year, I’ve had the privilege of working with a number of development teams as they modernize workloads, make them cloud native, and move them to Kubernetes. In this talk, I’ll talk about how many are converging on a GitOps workflow to make their Kubernetes deployments secure, auditable, and simpler and describe the end to end process and tooling you can use to achieve this. This is a practical cloud neutral talk and you’ll walk away with tools and techniques you can apply to your own Kubernetes deployments. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/LH3PPX/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/LH3PPX/feedback/ Main Hall Talk 2019-05-18T15:00:00+00:00 15:00 00:30 Setting up a CI pipeline for Kubernetes distribution environment can be a daunting - and possibly costly - task, especially when you need to run tests for every change in a distribution focused on high-availability. In this talk, I will explain how we built a CI system at Kinvolk based on Concourse CI, where we spin up multiple, parallel multi-node Kubernetes clusters in isolation on a single bare metal machine, in order to automatically run tests for bare-metal Kubernetes deployments. I will discuss the architectural and design choices, the tools that were used, the challenges we faced, and how we addressed them. cloud-native-rejekts-eu-2019-34-building-a-ci-pipeline-for-kubernetes-distributions-on-the-cheap Cloud Native Kosy Anyanwu en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/VNXFFH/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/VNXFFH/feedback/ Main Hall Talk 2019-05-18T15:40:00+00:00 15:40 00:30 Observing Kubernetes clusters at scale can be challenging. While most companies operate a small number of Kubernetes clusters, Giant Swarm is responsible for hundreds. This scale makes maintaining a responsible level of observability harder. We aim to present our observability journey, particularly with Prometheus. This will cover our architectural choices in the past, such as building tooling for managing Prometheus for on-demand Kubernetes clusters, our current usage and drawbacks we’d like to address, and our plans for the future, such as horizontal scaling and Cortex. We will also cover our continuous improvement process using post mortems and continuous delivery, which allows us to evolve our metrics, new exporters, and alerting as we discover blind spots. This talk presents our learnings of handling observability at scale, with in-depth examples from our infrastructure. cloud-native-rejekts-eu-2019-24-observing-enterprise-kubernetes-clusters-at-scale Cloud Native Joe Salisbury en Giant Swarm operates Kubernetes clusters for enterprise, offering a control plane for Kubernetes as a product, and 24/7 support for any managed Kubernetes clusters. As part of this offering, a high degree of observability and monitoring is necessary to respond to and debug operational issues. In this talk, we will present the learnings from our observability journey to the community, with a focus on how we’ve progressed with Prometheus. This will detail our path to our current usage of Prometheus, our current architecture and drawbacks, and our plans for the future. As part of this discussion, we’ll cover our architectural choices for monitoring our Kubernetes management platform, before moving onto our current setup and areas we’d like to improve. Towards how we’d like to improve, we’ll go into our plans to horizontally scale our Prometheus setup, as well as integrate with Cortex. We will also dive into our use of post mortems and continuous delivery to provide continuous improvement. This will touch on some related aspects, such as how our alerting has evolved over time, and how we have implemented new Prometheus exporters to improve the observability of Kubernetes, such as through exposing network and DNS metrics. Our main aim with this talk is to present how we’re managing observability in a holistic sense. We also believe that the community would be enriched by our learnings, as they can see which decisions we made have had positive outcomes (and which ones haven’t!). false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/HVZJJ7/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/HVZJJ7/feedback/ Main Hall Talk 2019-05-18T16:35:00+00:00 16:35 00:30 Container Registries store the images we build, secure, sign, geo-replicate and deploy. They support production workloads we configure authentication for each service and user that must access them. Joins as we share the work to extend OCI distribution and image specs to support new artifact types such as Helm and CNAB. We'll demonstrate how you can author and store new artifacts, leveraging the investments of OCI compliant registries enabling you to focus on the apps and artifacts, without having to manage the infrastructure. cloud-native-rejekts-eu-2019-45-artifact-registries-extending-oci-image-and-distribution Cloud Native Steve Lasker en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/VNVWCU/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/VNVWCU/feedback/ Main Hall Talk 2019-05-18T17:15:00+00:00 17:15 00:30 Relative to cloud infrastructure, bare metal environments are more varied and do not expose a unified API. The Cluster API unifies infrastructure management with Kubernetes-native resources, but our previous attempts to use it in bare metal environments show that actuators alone have significant limitations. Kubernetes webhooks offer an alternative that separates the provisioning of Infrastructure from the deployment of Kubernetes, while keeping the declarative model and common tooling provided by the Cluster API. cloud-native-rejekts-eu-2019-20-deep-dive-deploying-kubernetes-on-bare-metal-using-the-cluster-api Cloud Native David Watson & Jason DeTiberus en Today, the Cluster API project has provider implementations for a variety of cloud environments. Users are interested in using the Cluster API to operate clusters in heterogeneous bare metal environments. While machine provisioning varies widely across these environments, software provisioning remains largely the same. Because of this commonality, the cost of maintaining a separate provider for each environment outweighs the benefits. Attendees will learn how a single Cluster API provider can be used to operate clusters across different bare metal environments. We will show how to implement a webhook to provision machines in a bare metal environment, and how to integrate it with the Cluster API provider. We will also explain in depth the challenges of deploying Kubernetes in a uniform way across different environments using existing tooling (e.g. kubeadm). false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/C7HJP8/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/C7HJP8/feedback/ Main Hall Talk 2019-05-18T17:55:00+00:00 17:55 00:30 In this talk, we will explore our journey scaling from a couple of hundred nodes to several thousand Kubernetes nodes. Tales will be told on how to scale etcd itself and what a health check every 30 seconds does to the apiserver when running at several thousand nodes. cloud-native-rejekts-eu-2019-30-lessons-learned-while-scaling-kubernetes-to-5k-nodes Cloud Native Thomas Graf en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/88DYSP/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/88DYSP/feedback/ Main Hall Opening 2019-05-19T09:00:00+00:00 09:00 01:00 Doors and registration desk open to receive attendees. cloud-native-rejekts-eu-2019-52-day-2-registration-and-reception Break TBA en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/VTTMJ9/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/VTTMJ9/feedback/ Main Hall Talk 2019-05-19T10:00:00+00:00 10:00 00:30 Why should I use it?! Introducing new solutions, new technologies or new processes can meet resistance among your developers. Especially when it is a hyped technology such as Kubernetes. Listen to what Jessica and her team learned while building Kubernetes as a Service for developers at Meltwater. How human challenges become technical choices, and how communication and education can achieve high adoption rate. cloud-native-rejekts-eu-2019-6-getting-developers-to-adopt-your-service Cloud Native Jessica Andersson en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/QGAV7J/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/QGAV7J/feedback/ Main Hall Talk 2019-05-19T10:40:00+00:00 10:40 00:30 If you're developing applications on top of Kubernetes, you may be feeling overwhelmed with the vast number of developer tooling in the ecosystem at your disposal. Kubernetes is moving at a rapid pace, and it's becoming impossible to keep up with the latest and greatest development environments, debuggers, and build, test and deployment tools. In this talk, we'll share from our experience building applications on top of Kubernetes at Bitnami. We'll take a look at the landscape and answer questions like "should my team be using minikube or a shared Kubernetes environment?", "what's the difference between Skaffold, Draft and Telepresence?" and "should I be building an operator or a Helm chart?". We'll try to discern which tools best fit a scenario or workflow by looking at real-world examples of Kubernetes applications. cloud-native-rejekts-eu-2019-38-the-app-developer-s-kubernetes-toolbox Cloud Native Adnan Abdulhussein en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/NUPMTF/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/NUPMTF/feedback/ Main Hall Talk 2019-05-19T11:35:00+00:00 11:35 00:30 While running Kubernetes in production, how do you know what the cluster is doing? In this talk Federico will show you how he and his team are using kube-state-metrics in combination with other exporters and logs to get insights into the multi-tenant Kubernetes cluster they run for 40+ development teams at Meltwater. He will focus on metrics for the higher level Kubernetes objects as well as the cloud environment they run the cluster in. cloud-native-rejekts-eu-2019-3-knowing-what-your-kubernetes-cluster-is-doing Cloud Native Federico Hernandez en This talk builds on and extends two other talks from previous KubeCon events: - Reveal Your Deepest Kubernetes Metrics (KubeCon 2018 Europe) - Monitor The World Meaningful Metrics for Kubernetes Applications and Clusters (KubeCon 2018 NA) It will start where the other talks end and show real world examples of using metrics from kube-state-metrics for the higher abstraction level Kubernetes objects in combination with other exporters such as aws-limits and log files to get insights into the Kubernetes cluster we are running internally for other development teams at Meltwater. By running Kubernetes in production for over a year we have learnt (sometimes the hard way) to focus on the overall state of the cluster without loosing the possibility to dig into specific details as well as knowing about the state of the cloud environment the cluster runs in. The hard way gave us learnings on which metrics we were lacking and which ones were not needed. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/KMUEGQ/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/KMUEGQ/feedback/ Main Hall Talk 2019-05-19T12:15:00+00:00 12:15 00:30 In late 2017 and throughout 2018 we witnessed the advent of a new class of CPU-level information disclosure vulnerabilities, commonly known as “Spectre”, “Meltdown”, and (later in 2018) “Level 1 Terminal Fault” (l1tf in short, also known as “Foreshadow”). This talk will give a brief introduction of related CPU design concepts and their concrete exploitation by the above-mentioned vulnerabilities, and discuss available mitigations. After we’ve established (or refreshed) our knowledge of the problem field, the main part of the talk will focus on keeping your Kubernetes clusters secured from those vulnerabilities: we will take a full-stack approach and look at common OS and container abstraction layers in cloud-native scenarios individually - bare metal kernel space, user space, (optional) virtualization, and container runtime - to discuss weaknesses and mitigations at each of the layers. cloud-native-rejekts-eu-2019-36-hardware-vulnerabilities-in-cloud-native-environments Cloud Native Thilo Fromm en The talk aims to raise awareness as well as spread in-depth understanding of the impact CPU information disclosure flaws have on Kubernetes and its workloads. Our motivation is to educate our audience to empower folks to be able able to judge by themselves whether their workloads are secure, and to provide options and mitigations should workloads be at risk. Knowledge from this session will help the community to better understand this new vulnerability class, and to maintain security in Kubernetes deployments. The talk will roughly follow the path of our blog post on the impact of hardware security vulnerabilities in cloud-native environments: https://kinvolk.io/blog/2019/03/hardware-vulnerabilities-in-cloud-native-environments/ . false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/7YSFAF/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/7YSFAF/feedback/ Main Hall Break 2019-05-19T12:50:00+00:00 12:50 01:30 Lunch time! cloud-native-rejekts-eu-2019-54-lunch Break TBA en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/PTN7FW/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/PTN7FW/feedback/ Main Hall Talk 2019-05-19T14:20:00+00:00 14:20 00:30 What even are Kubernetes Operators? Kernel modules for extending Kubernetes. cloud-native-rejekts-eu-2019-47-kubernetes-operators Cloud Native Josh Wood en The Operator pattern for custom Kubernetes controllers extends the platform to automate the management of stateful, complex applications -- think databases, file stores, and other critical components that often have their own notions of clustering. Operators provide a philosophy and a toolkit for extending Kubernetes orchestration to this class of application, as well as, recursively, mechanisms for managing the lifecycle of the Kubernetes platform itself. This talk, a freestyle rap based on a rejected Kubecon proposal, will examine and demo Kubernetes Operators and make you want to use Operators and write one for your own application. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/ZW8MXF/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/ZW8MXF/feedback/ Main Hall Talk 2019-05-19T15:00:00+00:00 15:00 00:30 Istio is one of the most important things to happen to continuous delivery/deployment since Kubernetes. In this talk, you'll learn how to leverage Helm and Istio to create reliable automated deployment. To help us visualize the rollout we've built an interactive, open-source app and will ask audiences to help decide if a rollout continues or not. cloud-native-rejekts-eu-2019-42-visualizing-canary-rollouts-with-istio-and-helm Cloud Native Dan Garfield en The secret sauce uses a little-known feature of Helm to create arrays of Kubernetes stacks and Codefresh to manage custom health-checks and keeping the rollouts synchronized. You don't want to miss this very visual and interactive talk. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/RNVGKN/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/RNVGKN/feedback/ Main Hall Talk 2019-05-19T15:40:00+00:00 15:40 00:30 Cerebral is an open source, provider agnostic, preemptive Kubernetes cluster autoscaler with pluggable metrics backends and scaling engines. In this talk, we'll do a deep dive into Cerebral and contrast its methodology with that of the Kubernetes Cluster Autoscaler, which scales only after seeing that pods cannot be scheduled. cloud-native-rejekts-eu-2019-32-preemptive-autoscaling-on-any-cloud Cloud Native Matt KellyAshley Schuett en Cluster autoscalers automatically adjust the number of nodes in your cluster without operator intervention. Scaling up is important to meet resource demand while scaling down is useful for cost savings when nodes are underutilized. Within the Kubernetes ecosystem, there are various methods for achieving autoscaling. We’ll do a deep dive into Cerebral, an open source, provider agnostic, preemptive autoscaler with pluggable metrics backends and autoscaling engines. We’ll demo how to use it with a standard backend such as Prometheus, as well as explore use cases for custom backends: scaling based on a growing application queue, for example. This methodology will be contrasted with others such as the Kubernetes Cluster Autoscaler. The audience will also leave with an understanding of different scaling strategies: random, least waste, cost-optimized, and so on. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/9LP3TL/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/9LP3TL/feedback/ Main Hall Talk 2019-05-19T16:35:00+00:00 16:35 00:30 The Cloud Native community pushes updates very frequently, sometimes for security reasons other times to deliver new features. This means we need to continuously upgrade Kubernetes and the related Cloud Native Stack. Kubernetes has created a nice way to roll out new application versions, but what about the upgrade of the orchestrator itself, the core addons running on the cluster, or even the infrastructure holding it. Thanks to running clusters for multiple customers all over the world Giant Swarm has created a system to roll out any piece of the infrastructure stack without impact to the customer’s workloads. Our approach is relying on a set of operators to gracefully control the entire process making it reliable and reproducible. The audience will see the different decisions that have been taken and which problems have been faced over time. cloud-native-rejekts-eu-2019-21-always-up-to-date-dissecting-a-kubernetes-upgrade Cloud Native Fernando RIpoll en Giant Swarm manages cloud infrastructure for enterprises. It means we are in charge of providing Kubernetes clusters to our customers, as well as managing them so they are always running and up to date. Since Cloud Native environments are composed of a mixture of different components, people usually struggle to have everything up to date. In order to make it safe and robust, we have created a versioned system where all components of the platform are tracked under a bundle. It brings some benefits like immutability and testability. A bundle is made of a list of components like the VM, underlying operative system, the Kubernetes release, container runtime, load balancers, VPC peerings, DNS server, etc. Every component defines the version and the changelog since the last occurrence. Behind the curtain, a control plane in the form of a Kubernetes cluster holds a system of interconnected operators in charge of ensuring the desired state of the tenant clusters. A custom resource holds the entire configuration of the clusters including the version bundle. Every time there is a component(s) released we create a new bundle. After it is tested, it is promoted to the end user who can trigger the upgrade in her existing clusters. As this approach is similar to upstream cluster API efforts, we believe that the community can benefit from our learnings after two years of building and running this architecture. The audience will see which decisions we made, and why using Kubernetes to manage Kubernetes clusters is a great approach in order to keep the clusters up to date in such a dynamic environment. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/GMZRW7/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/GMZRW7/feedback/ Main Hall Lightning talk 2019-05-19T17:15:00+00:00 17:15 00:05 The State of the Art of **OpenMetrics** and some fundamentals about it. cloud-native-rejekts-eu-2019-12-openmetrics-prometheus-unbound Cloud Native Leonardo Di Donato en Nowadays every application exposes their **metrics** via an HTTP endpoint readable by using **Prometheus**. Recently the **exposition format** got included into the **OpenMetrics standard** of the **CNCF**. But why a standardization process was needed and is good? And what are the **novelties** and **differences** OpenMetrics introduces? This lightning talk will answer those questions while presenting the upcoming OpenMetrics official standard. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/ZJKBJX/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/ZJKBJX/feedback/ Main Hall Lightning talk 2019-05-19T17:30:00+00:00 17:30 00:05 Not sure which service mesh is right for you? In the emerging landscape of service meshes, which should you choose? In this lightning talk, we will demo, Meshery, an open source, multi-mesh playground that deploys different types of service meshes on-demand. cloud-native-rejekts-eu-2019-55-which-service-mesh-should-i-use- Cloud Native Lee Calcote en false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/M3QJJY/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/M3QJJY/feedback/ Main Hall Lightning talk 2019-05-19T17:40:00+00:00 17:40 00:05 The Kubernetes project releases a new version every 3 month as well as several bug fix releases in between. You need and want to upgrade your clusters. How do you do that with zero-downtime and no impact on your production workloads? In this lightning talk I will show how my team has come up with a procedure to upgrade a cluster and monitor the upgrade itself. In particular to avoid impact due to nodes becoming "Not Ready". cloud-native-rejekts-eu-2019-19-zero-downtime-upgrades-of-kubernetes Cloud Native Simone Sciarrati en The team at Meltwater develops and provides Kubernetes as a Service in a multi-tenant setup internally for 40+ development teams. The base cluster is deployed with Kops and then enhanced with add-ons by the team. During our first "kops rolling-update" runs we have experienced nodes going into "Not ready". Mainly do to bug #48638/#41916 and the way nodes reach the masters through DNS round-robin. Though our way of doing the upgrade was "triggered" by kops, we think the process and its steps, in particular the way we monitor the upgrade itself and the API functionality during the upgrade, could be interesting and applied to any Kubernetes instance. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/SFTA7W/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/SFTA7W/feedback/ Main Hall Talk 2019-05-19T17:55:00+00:00 17:55 00:30 Learn how to use Porter to create and deploy Cloud Native Application Bundles without knowing the CNAB spec. cloud-native-rejekts-eu-2019-26-build-cloud-native-application-bundles-with-porter Cloud Native /media/cloud-native-rejekts-eu-2019/images/ZKNBXH/porter-notext.png Carolyn Van SlyckJeremy Rickard en When we deploy to the cloud, most of us aren't dealing with just a single cloud provider or even deployment tool. It seems like even the simplest of applications today need a load balancer, SSL certificates, persistent file storage, DNS, and somewhere in there is your application. That is a lot to figure out! The Cloud Native Application Bundles specification was created to help address that problem, helping you manage everything in a single package and focus on what you know best: your application. [Porter](https://porter.sh) is a tool that delivers an easy to use, declarative approach to building these bundles. Porter helps you build bundles without needing to be a CNAB expert. Come learn how Porter makes it easier to manage cloud native applications in the messy imperfect hybrid cloud world that we live in. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/ZKNBXH/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/ZKNBXH/feedback/ Sidebar Talk 2019-05-19T11:35:00+00:00 11:35 00:30 In a world where stateless applications are optimized to run blazing fast, message exchanging cannot be allowed to affect their performance. Having the ability to publish more than 7 million of messages per second, NATS is the sprinter of the messaging queues. Whereas benchmarks are good indicators for choosing a tool there is no way to confirm its value without monitoring its performance in production. In our team, we use EFK stack to monitor a bunch of microservices running on top of Kubernetes, since EFK tends to be the de facto way to monitor containerized microservices. Everything started with a task: Ship NATS monitoring data to Elasticsearch. What we achieved: Extending Beats, the Elastic data shipper, with a NATS dedicated module. Join us in this session to learn more about the journey, how to add value to a CNCF project and give back to the community. PS. There will be a demo! cloud-native-rejekts-eu-2019-23-monitoring-the-nats-messaging-system-at-scale-with-elastic-beats Cloud Native MICHAEL KATSOULISStamatis Katsaounis en In this session we plan to cover the whole process of turning an internal requirement into a very meaningful integration between a CNCF incubating project (NATS) and a CNCF silver member’s project (Elastic Beats). First part of the session is going to be about the problem we had to solve. As a team working on Kubernetes microservices, we are using NATS as a messaging queue to ensure the resiliency of the critical paths. Furthermore, we rely on EFK to monitor our stack. Consequently, monitoring of NATS had to be achieved through EFK stack as well. In the second part of the session we will describe how we came up with the solution, trying to motivate the audience to follow the same successful path when facing similar situations. After investigating our available options, we noticed that Beats project, the Elastic data shipper, could fit in our case if NATS monitoring was supported. And here comes the motivational part. Those days, during an organized hackathon we grabbed the opportunity to work into creating our own NATS Beat which was later added to the official list of community Beats. Today, after Beats maintainers’ request, NATS has its own module in the core of Beats project. Final part of the session will be dedicated on how to actually use Beats for shipping monitoring data of a running NATS server to an Elasticsearch instance. The audience will have the opportunity to realize the value of NATS module and the benefit of putting effort in community projects. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/LEQHTE/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/LEQHTE/feedback/ Sidebar Talk 2019-05-19T12:15:00+00:00 12:15 00:30 Test Driven Development and Code Coverage as a concept and practice is approaching 20 years and we've moved on. Sufficiently advanced monitoring is indistinguishable from testing and in this talk I'll prove it. cloud-native-rejekts-eu-2019-22-test-driven-development-is-dead Cloud Native /media/cloud-native-rejekts-eu-2019/images/MWPDUY/tdd-is-dead.png Kevin Crawley en In this session we'll uncover why both Unit Testing and Integration Testing as a practice doesn't actually help engineers or operations understand how their applications run in production nor does it help them sleep at night when PagerDuty goes off at 3am. We'll discuss how modern software delivery organizations are leveraging advances in monitoring and logging systems to analyze the behavior of their production systems in near real time and uncover the mysticism surrounding observability. We'll smash the ban hammer on those bits of code which should never be tested and show real world examples of tooling such as Opentracing and Prometheus that enable organizations to focus on what matters: is my production application working like it should. Ultimately, sufficiently advanced monitoring is indistinguishable from testing and in this talk I'll prove it. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/MWPDUY/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/MWPDUY/feedback/ Sidebar Talk 2019-05-19T14:20:00+00:00 14:20 00:30 In this presentation we will explain why and how container networking is moving from the kernel into user space through projects such as the Contiv-VPP CNI plug-in (which leverages the Linux Foundation's fd.io project). cloud-native-rejekts-eu-2019-40-moving-the-cni-to-user-space Cloud Native Giles Heron en Existing container networking solutions rely on Linux Kernel networking (using iptables, eBPF, Open vSwitch etc.) . This constrains both performance and flexibility. User-Space networking offers better performance (especially when combined with technologies such as vector-based forwarding such as d.io VPP) and enables new features to be developed and deployed without requiring changes to the Linux kernel. Contiv-VPP is a CNI plugin for Kubernetes that leverages fd.io VPP and which provides a full implementation of Kubernetes network policy and of Kubernetes services (usually implemented by kube-proxy, which programs Linux kernel netfilter rules). We will provide a detailed description, and live demos of Contiv-VPP, and will discuss the challenges we encountered in our implementation. Finally we will show how user space networking enables Cloud-native Network Functions such as firewalls and VPN gateways. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/W3VULB/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/W3VULB/feedback/ Sidebar Talk 2019-05-19T15:00:00+00:00 15:00 00:30 As hosted Kubernetes solutions mature, it becomes ever more compelling to operate clusters across multiple cloud providers. A general point of friction can often be the differences in how you are able to authenticate to those clusters. Cloud providers tend to integrate their own proprietary solutions and hosted control planes lack the flexibility to use authentication providers and audit sinks. cloud-native-rejekts-eu-2019-14-consistent-user-authentication-in-multi-cloud-hosted-kubernetes-clusters Cloud Native Christian Simon en During this talk I will show how a reverse proxy in front of the Kubernetes API can implement uniform OIDC authentication across hosted Kubernetes solutions. false https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/XFNRUH/ https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-2019/talk/XFNRUH/feedback/