The widespread use of cloud-native applications, and therefore containers, has resulted in the development of numerous container orchestration tools, among which HashiCorp’s Nomad and Kubernetes stand out.
You’ve learned the basics of Kubernetes, including how to set up Pods and Deployments to run your applications, and you’re now ready to move your organization’s workloads into Kubernetes.
Maintaining a microservices ecosystem is challenging, without doubt. However, many companies that unravel that day-to-day mystery still struggle with cost—whether or not they fully understand their operating expenses.
If you need a policy management tool for your Kubernetes clusters, you have several options to choose from. Two popular policy tools are Open Policy Agent and jsPolicy.
Kubernetes is primarily a Linux technology, so it’s fairly straightforward to run it on different Linux distros. But what about the developers working on Windows who need to run Kubernetes locally?
Earlier this year, at my company, we hit a wall while developing a web application for a client. We had very limited finances and needed someone to support the DevOps side of things.
There is no denying the fact that Kubernetes has experienced widespread adoption in the last few years. Its automated deployment and scaling capabilities have made it easier and more convenient for developers to manage and develop advanced applications and services.
Kubernetes is the third most loved platform by developers, according to the Stack Overflow 2020 Developer Survey, but it’s still quite complex to use. That complexity can impede workflow.
In this series, we’re looking at alternatives to using Docker Compose for building apps that run in Kubernetes clusters. While Compose is a handy way to stand up apps locally, there are advantages to running your apps in a Kubernetes environment while you develop.
As more developers use Kubernetes, a variety of deployment tools are emerging to help them. Three interesting examples are Skaffold, Tilt, and DevSpace. While they all assist in building and deploying on Kubernetes clusters, their approaches are noticeably different.
Kubernetes now runs in more than 70 percent of container environments. Monitoring has become a key way to extract as much information as possible during container runtime.
When getting started with Docker, many developers quickly turn to Docker Compose to run their applications. Compose offers many advantages, such as having your configuration stored as code, making it easy to maintain and expand upon.
Kubernetes is Kubernetes—what difference does it make which cloud provider you choose? Well, quite a lot, actually. While GKE, EKS, AKS, and DOKS all conform to CNCF Kubernetes Certification standards and are each valid choices, they each have their unique advantages and disadvantages, ranging from pricing to upgrades, to node repair.
If you’re developing apps that run in Kubernetes, running them locally with Docker Compose may seem like a simple solution. But it can cause problems, as your local environment will be very different from how your apps run production.
Containerization is on an upward trajectory when it comes to enterprise adoption. This is primarily due to how containers solve the problem of application delivery and portability.
Many engineers developing apps that run in Kubernetes use Docker Compose for their local environment, but a lot of great alternatives are out there that make developing against a Kubernetes cluster fast and easy.
Nearly everyone touching cloud infrastructure in 2021 is familiar with the Kubernetes project. Put simply, Kubernetes is an incredibly powerful platform for container orchestration. But in my opinion, Kubernetes, more than anything, is a collection of best practices baked into a system that can scale from a Raspberry Pi up to the largest Fortune 500 infrastructure.
Kubernetes has left the state when it was mostly an ops technology behind and now is also very relevant for many developers. As I wrote in my blog post about the Kubernetes workflow, the first step for every developer who starts to directly work with Kubernetes is to set up/get access to a Kubernetes development environment.
If you are on a higher level of cloud-native development (level 2 or higher according to this article about the typical cloud-native journey of companies), the developers in your team need to have a direct access to Kubernetes.