Kubernetes is everywhere now, but it’s primarily been the domain of people working on the Ops side of infrastructure. What about devs, though? You benefit from knowing what Kubernetes is and how to use it, too – otherwise, we’re still putting teams in silos. In this tutorial, we’re going to define Kubernetes at a high level, talk about the anatomy of a cluster, and learn not just why you should care but how to try it for yourself. We’ll start with local deployments using YAML before getting a little help from infrastructure as code with Pulumi to stand up everything right inside our sample application in a programming language you’re already writing!
Provisioning, managing, and monitoring a Kubernetes cluster is
not easy. AWS now offers EKS to reduce that burden – but
it’s still difficult to get up and running. Pulumi’s infrastructure as
code SDKs can help! We can provision an entire EKS cluster with a
single CLI command, thanks to the
package. Let’s see how.
Delivering modern applications is complicated and requires the coordination of many moving parts. Applications are frequently updated to implement new features and improve security and performance, translating to a better user experience for your customers. To further complicate matters, infrastructure must also be deployed and maintained simultaneously with applications to avoid conflicts or dependencies.
Containerized applications deployed on Kubernetes are particularly susceptible to a misalignment between developers who frequently push changes and operators who want to maintain a stable architecture. Continuous Integration builds and tests software and delivers it as packages. Continuous Delivery or Deployment deploys applications on infrastructure. Let’s take a look at how we can accomplish CI/CD for both applications and infrastructure.
It’s a new year and it’s time to level up your cloud engineering skills. Pulumi is there to get you started on your cloud engineering journey with workshops and technical sessions.
In the first article in this series, we gave you some questions to help you and others at your company decide if Kubernetes is right for you. In this post, we’ll give you an example of where Kubernetes can be a good fit.
When you’re considering whether or not to implement Kubernetes, perhaps the first question to ask yourself is do you need it at all?
The point of any technology isn’t the technology itself. When done right, Kubernetes can reduce the barrier of entry for application developers so they can get features from their machines to your customers as quickly and easily as possible. But do you already have a solution that works well? If you do, why do you want to change it? Making such a radical change in your technology is potentially quite dangerous so what’s your motivation?
It very well might be that sticking with and improving the solution you already have offers a better cost/benefit tradeoff. It’s easy to fall into the trap of believing that simply adopting a new technology like Kubernetes will instantly solve your hard organizational or technical problems, however, we know that is seldom true.
In this blog post we’ll share some tips and tricks for evaluating your own situation to see if Kubernetes is a good fit. We’ve learned these from helping hundreds of customers adopt Kubernetes — in addition to not, when there was a better solution available. We’ll see that the question isn’t that simple to answer and there are a lot of variables to consider. In the next blog post, we’ll talk about a situation where Kubernetes can be a good fit and how to start your first Kubernetes project.
Note that these blog posts assume you already have some familiarity with Kubernetes. If you are just starting to learn, our Getting Started with Kubernetes blog series is a good place to start.
Going from a containerized application to a service running in the cloud requires a few steps beyond an application’s normal build-and-test cycle. Namely, it means building and publishing a container image in a registry and then consuming that image from your target environment, whether that’s Kubernetes, Amazon ECS, or another container orchestrator. It’s not enough to just write a
Dockerfile — you will need to pick a container registry, decide whether that registry should be public or private, authenticate against it, and ideally automate deploying subsequent updates. Infrastructure as code to the rescue! In this article, we’ll see how to build, publish, and consume a simple container image across any cloud, using just a few lines of code.
Amazon announced several Elastic Kubernetes Service feature releases and updates during the first week of AWS re:Invent 2020. If we look at all the announcements as a whole, we can see the Kubernetes ecosystem maturing to make deployments and management easier for organizations. Let’s take a look at how they can benefit your use of EKS.
As Kubernetes grows in popularity, the number of options for Kubernetes users continues to increase. Providers of managed Kubernetes offerings will often learn lessons about operating large numbers of clusters at scale; it’s increasingly common that they will contribute this knowledge back to the ecosystem, allowing those organizations who need more control and flexibility to reap the benefits.
With the announcement of the Amazon EKS Distro during AWS re:Invent, the Amazon EKS team has contributed back to the cloud-native community in a big way. In this post, we’ll take a brief look at what the Amazon EKS Distro is, explore why you might choose this over current managed service offerings and finally, explore how you can get started with the Amazon EKS Distro on day 1 using Pulumi.
In software development, an anti-pattern is defined as an apparent solution that has unintended or negative consequences. The other side of anti-patterns is that they also offer solutions. Let’s look at container and Kubernetes anti-patterns and how to avoid them with infrastructure as code.