AWS Elastic Kubernetes Service (EKS) provides a range of performance and control for dynamically scaling your Kubernetes clusters, including Managed Node Groups, Fargate, and Manually-Managed Node Groups in EC2. In this post, we’ll see how to use each of these compute options, and when to prefer one over the other in order to maximize productivity, flexibility, and control, based on your needs.
A big part of our vision with Pulumi is to bring application developers and infrastructure teams closer together in the cloud. That includes both providing infrastructure teams with better software engineering tools, as well as providing developers with easier access to cloud infrastructure. We are often inspired by looking at great software engineering experiences in other development stacks and applying them to the cloud infrastructure space. Whether it be general-purpose languages and rich IDEs, testing and package management, or components and rich APIs, at Pulumi, we’ve repeatedly applied successful development tools and practices to the challenges of building and scaling modern cloud infrastructure.
We had a fantastic time at KubeCon in San Diego. At the event, the Pulumi team released two technology previews: Pulumi Crosswalk for Kubernetes and Pulumi Query for Kubernetes.
Crosswalk for Kubernetes is a set of common patterns compiled in playbooks. These patterns reduce the complex Kubernetes API syntax by providing trusted defaults with idiomatic Kubernetes. Checkout a quick introduction to Crosswalk for Kubernetes in this blog post.
Sara Novotny defined observability as “the ability to ask of your system and learn from it” during her keynote with Liz Fong-Jones. Query for Kubernetes enables observability programmatically by exposing resource processes through either batch or streaming queries. Learn more about Query for Kubernetes in our blog post.
Running Kubernetes in production can be challenging. This past year, Pulumi has collected common patterns of usage informed by best practices for provisioning Kubernetes infrastructure and running containerized applications. We call this Pulumi Crosswalk for Kubernetes: a collection of playbooks and libraries to help you to successfully configure, deploy, and manage Kubernetes in a way that works for teams in production.
We often need answers to simple questions about Kubernetes resources. Questions like:
Each of these questions would normally be answered by invoking kubectl multiple times to list
resources of each type, and manually parsing the output to join it together into a single report.
Kubernetes provides a rich, standards-based API that works across cloud and on-premise infrastructure. However, many of the API fields are deeply nested and require users to specify the same values redundantly across different resources. While this explicit specification is necessary for Kubernetes to operate, this often leads users to copy-paste existing code to manage the boilerplate.
Today, as part of our Crosswalk for Kubernetes announcement, we’re introducing the Kubernetes Extensions (kx) library for Pulumi. kx is designed to simplify the declaration of Kubernetes resources, and make the API easier for everyone to use.
Today we announced Pulumi Crosswalk for Kubernetes, a collection of open source tools, libraries, and playbooks to help developers and operators work together to bring Kubernetes into their organizations. They capture the lessons we learned this past year working with organizations to go from zero to Kubernetes in production for their infrastructure and application workloads. By releasing these as open source, we hope to help everybody be more successful with their Kubernetes projects — as we have learned through experience, it isn’t easy going!
Azure Functions is a managed service for serverless applications in the Azure cloud. More broadly, Azure Functions is a runtime with multiple hosting possibilities. KEDA (Kubernetes-based Event-Driven Autoscaling) is an emerging option to host this runtime in Kubernetes.
In the first part of this post, I compare KEDA with cloud-based scaling and outline the required components. In the second part, I define infrastructure as code to deploy a sample KEDA application to an Azure Kubernetes Service (AKS) cluster.
The result is a fully working example and a high-level idea of how it works. Kubernetes expertise is not required!
We recently partnered with DigitalOcean to publish a new tutorial, How to Manage DigitalOcean and Kubernetes Infrastructure with Pulumi. This short tutorial walks you through provisioning a new DigitalOcean Kubernetes cluster, deploying an application to it, and then assigninging a stable domain name to your application’s load balancer — all in a handful of lines of infrastructure as code.
By using infrastructure as code to provision and update your infrastructure, it’s easy to create new environments, modify or scale existing ones, or automate your deployments using continuous delivery. This approach also ensures that deployments are reliable and repeatable, and can even standardize how you deploy code to different cloud providers, including DigitalOcean, AWS, Azure, GCP, and others.
Kubernetes clusters from the managed platforms of AWS Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and GCP Google Kubernetes Engine (GKE) all vary in configuration, management, and resource properties. This variance creates unnecessary complexity in cluster provisioning and application deployments, as well as for CI/CD and testing.
Additionally, if you wanted to deploy the same app across multiple clusters for specific use cases or test scenarios across providers, subtleties such as LoadBalancer outputs and cluster connection settings can be a nuisance to manage.
In this post, we’ll see how to use Pulumi to deploy the kuard app across EKS,
AKS, GKE and a local Kubernetes cluster, such as Docker Desktop or a self-managed cluster.
We’ll spin up the clusters in each provider, launch the app,
and manage both cluster and app using the TypeScript programming language.