This article is the third part of a series focused on Kubernetes multi-cluster technology. For an introduction to this topic, the goals and responsibilities of multi-cluster setups, and how to manage the cluster lifecycle, please see parts one and two of this series.
This article is the second part of a series focused on Kubernetes multi-cluster. For an introduction and more about the goals and responsibilities of multi-cluster setups, please see part one.
Developers who work in fast-paced environments face the risk of infrastructure sprawl in their VMs or servers. Even with the rise in containerized deployments on Kubernetes and other platforms, admins still must determine how to efficiently manage hundreds and thousands of clusters for various projects.
Kubernetes has taken the software development world by storm. It gives you an excellent framework to deploy your application with and abstracts away the low-level details of the underlying infrastructure.
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.
With Kubernetes becoming the gold standard for advanced container orchestration, it’s also become necessary to use extensions that work alongside Kubernetes to provide security and modularity.
I was recently on a YouTube stream explaining jsPolicy, an open source project for managing policies in Kubernetes clusters that we maintain at Loft Labs. CEO Lukas Gentele joined me, and our host was Saiyam Pathak.
Providing security for our infrastructure and applications is a never-ending continuous process. This article will talk about security in Kubernetes clusters, traffic incoming and outgoing to/from the cluster, and the traffic within the cluster.
It can be challenging to manage costs if your developers use Kubernetes clusters running in the cloud, whether they use shared clusters or have their own dedicated clusters.
Recently, you might have heard about “internal Kubernetes platforms” from many different sources: KubeCon talks, blog articles, or just colleagues and friends. Even if such platforms are not always called internal Kubernetes platforms, solutions that allow engineers to get a standardized and easy Kubernetes access in a cloud environment seem to become more common now.
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.
The container orchestration technology Kubernetes has become the dominant solution for cloud infrastructure and as such it is maturing at an unrivaled pace. Many companies have already adopted Kubernetes or are in the process of it.