KubeCon + CloudNativeCon North America 2019

Accounting is very important in Kubernetes. Better accounting leads to improved node stability, density, and more accurate charging users based on their actual resource utilization. Unfortunately, there are gaps in resource accounting in Kubernetes today, mostly based on the fact that running a pod is not actually free.

In Kubernetes 1.16, the PodOverhead feature is introduced to fix these issues.

We’ll dive into the details of a pod’s journey from client CLI to running on a node, touching on kubectl, API server, admission controllers, etcd, scheduler, kubelet, containerd/cri-o, and runtimes like Kata Containers and gVisor. Through this we will highlight the current gaps and how the PodOverhead feature addresses them.

Attend to get a basic understanding of the Pod creation process, and learn what the new PodOverhead feature is and how it can be used to improve cluster stability.

The Windows Operating System does not support privileged operations from inside a container today. Daemon-sets on Windows nodes in Kubernetes clusters that need to perform configuration actions on the node are significantly impacted by the absence of privileged mode support on Windows. In this talk we:
1. Explore the pros and cons of the options the SIG Windows community brainstormed to provide containers running on Windows the ability to perform privileged operations while being managed by Kubernetes.
2. Delve into the specific characteristics of the privileged proxy approach we decided to adopt.
3. Demonstrate how the privileged proxy approach is used to support privileged operations that need to be executed by daemon-sets associated with CSI plugins running on Windows nodes in a Kubernetes cluster.

containerd, a graduated CNCF project, is a widely used container runtime that provides core functionality for Docker. containerd was designed to be small and simple, but also very modular and extensible. This talk covers the architecture of containerd, explains the responsibilities of each component, and dives deep into containerd’s facility for extension. We’ll cover the individual gRPC services that make up containerd and show how they can be extended with proxy plugins, Go plugins, process interfaces (OCI runtimes and process-based logging), thick client implementations, and build-your-own containerd for compiled-in extension. These extension mechanisms can be shown with simple examples and real-world use in the firecracker-containerd project.

In large clusters, some applications attempt to consume a majority of shared resources. These "noisy neighbours" cause performance degradation for other workloads in the cluster. At this time, Kubernetes has mechanisms to mitigate this behaviour for CPU and memory only. This talk discusses methods for extending fine-grained resource control on other shared resources, such as block and PCIe I/O, shared CPU caches, and others. It demonstrates how to utilize extensibility points of CRI-O and containerd runtimes to achieve fine-grained resource control. The talk also presents an approach for evolving this method into an extensive and fully dynamic resource management solution for Kubernetes.

Agenda
- Problem Statement: different types of "noisy neighbours"
- Resource management on kernel, OCI, and Kubernetes levels
- Stitching the pieces together: dynamic container resource management

In Barcelona, we raced through seven different container runtime setups from Docker to cri-o to containerd--including interesting projects like AWS's Firecracker, Kata containers and gVisor. For each we demonstrated how to allow Kubernetes to use each one of them using either RuntimeClass or standard kubelet CRI configuration parameters and then gave a quick highlight of their feature set, maturity, and usage in the ecosystem.

While we successfully demo'd each runtime, we didn't have time to assess each of them with regards to the "why?" question: why would an operator or user choose one of these runtimes? In this "Part 2" talk we will take the time to walk back through each runtime, cover updates to the project since May, look at performance and security characteristics, and answer the why question for each one!

Weave Ignite is a new open source tool that combines Firecracker microVMs with OCI images, containerd and CNI to unify containers and VMs. It integrates with Kubernetes and GitOps operators so it can be managed declaratively like Kubernetes itself and Terraform.

Ignite is fast and secure because of Firecracker, AWS’ oss KVM implementation that is optimised for speed, low resource consumption, high security, and isolation. With Ignite, users can:
*Launch and manage entire “app ready” stacks from Git
*Run legacy or special apps in lightweight VMs (eg for multi-tenancy)
*Run a cloud of VMs ‘anywhere’ using Kubernetes for orchestration, Ignite for virtualization, GitOps for management, and supporting cloud native tools and APIs.

Ignite contributor Mark Emeis will share why Kubernetes SIG Lead and Weaveworks DX Engineer, Lucas Käldström, created Ignite, how it works, and how to get started.