Every non-trivial application relies on configuration values that may depend on the current execution environment. Some of these values contain sensitive information that shouldn’t be shared publicly. In general, the fewer parties that have access to those secret values, the safer the application will be—in fact, in an ideal world, no one would be granted direct access to those secrets.
Managed Kubernetes offerings greatly reduce the overhead required in administering Kubernetes. However, the cluster is only one of the components under management, as app lifecycles are self-driven tasks that vary by workloads.
In Kubernetes, node groups are a useful mechanism for creating pools of resources that can enforce scheduling requirements. They also provide a utility for shifting workloads around during cluster management and updates.
In this post, we’ll see how to use Pulumi for Day 2 Kubernetes administration.
We’ll spin up a new EKS cluster with two node groups and a given workload.
Then we’ll add one more node group with an updated configuration, and migrate the workload
over to it with zero downtime using code and kubectl.
Pulumi recently added support for managing DigitalOcean resources. This article will show you how to deploy some load balanced Droplets on DigitalOcean using Pulumi.
Last Wednesday, we invited members of our local Seattle community to Pulumi HQ for the July Pulumi Up meetup. The evening began with some networking time wherein our guests met some Pulumi engineers and users they may have only ever interacted with over Pulumi’s Community Slack while enjoying free pizza and beverages. This month’s meetup featured two talks by Pulumi engineers. Application code isn’t the only code that can have APIs Unfortunately, due to travel issues, Paul Stack wasn’t able to join us in person, but graciously agreed to present remotely… from Europe… at 4:00 in the morning.
The Amazon Elastic File System Container Storage Interface (CSI) Driver implements the CSI specification for container orchestrators to manage the lifecycle of Amazon EFS filesystems. The CSI specification defines an interface along with the minimum operational and packaging recommendations for a storage provider to implement a CSI compatible plugin. The interface declares the RPCs that a plugin must expose. The CSI drivers are the right mechanism to work with, when using a cloud storage component with Kubernetes workloads.
Some parts of this blog post are out-of-date. Please refer to our Testing Guide for the updated overview and tutorials.
Testing your infrastructure using familiar tools like Node.js’s Mocha framework allows you to ensure configuration is correct before provisioning, and that the resulting infrastructure has certain desirable properties afterwards. This can enforce team standards, ensure security guidelines are being followed, and so much more. Because Pulumi uses general purpose languages, you can just embed tests alongside your infrastructure-as-code definitions themselves, using a familiar authoring style and reporting experience. In this post, we’ll explore the ins and outs of unit testing your infrastructure.
Kubernetes Ingress is an API object that allows you manage external (or) internal HTTP[s] access to Kubernetes services running in a cluster. Amazon Elastic Load Balancing Application Load Balancer (ALB) is a popular AWS service that load balances incoming traffic at the application layer across multiple targets, such as Amazon EC2 instances, in a region. ALB supports multiple features including host or path based routing, TLS (Transport layer security) termination, WebSockets, HTTP/2, AWS WAF (web application firewall) integration, integrated access logs, and health checks.
The AWS ALB Ingress controller is a Kubernetes SIG-AWS subproject - it was the second sub-project added to SIG-AWS after the aws-authenticator subproject. The ALB Ingress controller triggers the creation of an ALB and the necessary supporting AWS resources whenever a Kubernetes user declares an Ingress resource on the cluster. TargetGroups are created for each backend specified in the Ingress resource. Listeners are created for every port specified as Ingress resource annotation. When no port is specified, sensible defaults (80 or 443) are used. Rules are created for each path specified in your ingress resource. This ensures that traffic to a specific path is routed to the correct TargetGroup.
In this post, we will work through a simple example of running ALB based Kubernetes Ingresses with Pulumi EKS, AWS, and AWSX packages.
Pulumi is excellent at connecting multiple cloud components into a cohesive application. In my previous post, I introduced the way to mix JavaScript or TypeScript serverless functions directly into the cloud infrastructure programs.
Today, I will build a serverless application with both the data store and the HTTP endpoint located close to end users to ensure prompt response time. The entire application runs on top of managed Azure services and is defined as a single Pulumi program in TypeScript.
Static websites are back in the mainstream these days. Website generators like Jekyll, Hugo, or Gatsby, make it fairly easy to combine templates and markdown pages to produce static HTML files. Static assets are the simplest thing to serve and cache, so the whole setup ends up being fast and cost-efficient. Many platforms offer services to host such static websites. This post explains the steps to create the infrastructure to do so on Microsoft Azure.
Amazon offers multiple solutions for running containers in AWS, through
its managed Elastic Container Service (ECS). This includes three major
approaches: ECS managed automatically with Fargate, ECS backed by EC2
instances, and Elastic Kubernetes Service (EKS), delivering the full
power of Kubernetes. It’s not always easy to choose between these, so in
this article we provide some basic guidance on the tradeoffs you’ll
encounter when choosing.
