Kubernetes

Disaster events are one of the biggest challenges that a software organization can face. Natural disasters like earthquakes or floods, technical failures such as power or network loss, and human actions such as unauthorized attacks can disable an entire fleet of systems, leading to complete failure for a business. To deal with disaster scenarios requires a proactive approach to prepare and recover from failure. One of the key benefits of running in the cloud is how easy it is to run workloads in multiple regions. This allows you to deploy a resilient architecture that supports disaster recovery, even in the cases where an entire region is disabled. ...

AWS provides four different storage options for your Kubernetes cluster: EBS, EFS, FSx for Lustre, and Amazon File Cache. Each of these CSI drivers has different performance characteristics, depending on your workload. This post quantifies those performance differences using the flexible I/O tester FIO. Note: For an overview of the different CSI options available on AWS, see Picking the right AWS CSI driver for your Kubernetes application. Before we start, please note that these results come with multiple caveats, and you should absolutely test performance on your own workloads before making any final decisions. For example, a workload with many random reads is typically latency sensitive and would benefit from higher IOPS, whereas a workload consisting of mostly streaming reads is typically throughput sensitive and would benefit from higher bandwidth and at large I/O sizes with relatively lower IOPS. ...

Dealing with storage is a core challenge when running complex applications on Kubernetes. While many applications operate just fine using a cloud database or blob storage, some applications have performance or design requirements requiring local storage. Note: For performance benchmarks see [Benchmarking AWS CSI Drivers](<{{ relref “/post/kubernetes/benchmarking-aws-csi-drivers” }}). When this is the case, developers and cluster operators rely on Container Storage Interface (CSI) implementations to provide local storage for Pods. When running on the AWS cloud, no less than four CSI providers are available for us to use: Elastic Block Storage, Elastic File System, FSx for Lustre, and AWS File Cache. This article compares these four different local storage options to help you choose the right option for your application. ...

eBPF is a relatively new extension of the Linux kernel that can run sandboxed programs in a privileged context. It is used to safely and efficiently extend the capabilities of the kernel at runtime without requiring changes to kernel source code or the loading of kernel modules. Because of eBPFs tight integration with the networking stack at the kernel level, it is seeing adoption in networking applications. This includes Kubernetes networking through eBPF implementations of the Kubnernetes networking stack like Cilium. ...

Shortly after deploying a new Kubernetes cluster, one of the first things you will likely want to do is collect some metrics and data about how it operates. There are two projects that are typically used for this, and since they are named similarly it can be confusing to know which one you should use and why. This post hopes to clear up any confusion between the Kubernetes Metrics Server and kube-state-metrics. ...

Still in search of a Kubernetes development environment I can run on my development machine that somewhat replicates, I was recently introduced to both the multipass and microk8s projects from Canonical. multipass is a prerequisite for microk8s, so let’s start there. With multipass, you can easily launch and run Ubuntu virtual machines with a single command. ❯ multipass launch --name foo Launched: foo With a virtual machine in hand, you can run execute arbitrary commands on the machine using the exec subcommand. ...

With so many people running microservice workloads, it is inevitable that organizations keep bumping into the same set of problems: state management, resiliency, event-handling, and more. Dapr exists to help codify the best practices for building microservice applications into building blocks that enable you to build portable applications with the language and framework of your choice. Each building block is completely independent and you can use one, some, or all of them in your application to solve common microservice problems. ...

In my last post I detailed how to setup a local Kubernetes development cluster using kind. This post shows how to leverage this new cluster when developing a system or application that relies on multiple microservices using tilt. If you haven’t setup your local environment with kind yet, refer back to my last post before continuing on. Installing Tilt You can install the tilt binary using Homebrew or through curl and an installation script: ...

kind is a tool built for running local Kubernetes clusters using Docker containers as nodes. kind was primarily designed for testing Kubernetes itself, but it is actually quite useful for creating a Kubernetes environment for local development, QA, or CI/CD. This blog post shows you how to setup a kind-based environment for local development that can mimic a production Kubernetes environment. A fully functioning environment using kind includes a few different components. For our purposes, we will install the following list of software. ...

The Kubernetes sweet-spot is running stateless microservices that can scale horizontally. By keeping state out of your application, Kubernetes can seamlessly add, remove, or restart pods to keep your service healthy and scalable. Developing a stateless application is, without question, the easiest way to ensure that your app can scale with Kubernetes. However, there are some workloads that do not run effectively in a stateless way, and for that, Kubernetes offers a few tools for developing stateful applications: leader election, StatefulSets and session affinity. ...