The adoption of Kubernetes and its ecosystem has continued its rapid growth, with over 5.1 million developers worldwide now using Kubernetes. Developers are adopting and utilizing Kubernetes to manage containerized workloads and services. Kubernetes has many benefits for organizations and developers including auto scaling, automated deployment and rollback, self-healing, loading balancing and application centricity.
At CloudCasa, as a cloud-native backup-as-a-service provider, we are often dealing with customer concerns about the security and privacy of their data. Sometimes the concern is almost paradoxical because the data and application they are protecting is publicly accessible and running inside the public cloud. However, there are times when organizations use public cloud infrastructure with a network architecture that resembles a private cloud.
With the release of Longhorn v1.3.0, CloudCasa by Catalogic is happy to announce that it fully supports the backup and recovery of Longhorn persistent volumes (PVs) on Kubernetes clusters. While previous versions of Longhorn supported volume snapshots and the CSI interface, Longhorn v1.3 introduced full support for the CSI snapshot interface so it can now be used to trigger volume snapshots in a cluster.
If you are considering Azure Files as the persistent storage for your Azure Kubernetes Service (AKS) applications, there are important considerations around AKS backup and recovery with implications on how you can perform Dev, Test, and Staging. This article outlines these data management considerations in detail and how to work around Azure Files limitation to achieve feature parity with using Azure Managed Disks.
Cross-cluster migration of Kubernetes workloads continues to be challenging since workloads are isolated from each other by design. There are several reasons why you may want to separate your workloads, whether it is to reduce complexity or to have the cluster closer to the user base. However, this can be complex as Kubernetes has many components.
Why settle for less! The challenge of manually dealing with self-hosting a product like Velero or Kasten on dozens of clusters and multiple clouds, and then trying to migrate data across different accounts and even different clouds is very different from dealing with a single cluster and a single cloud environment. CloudCasa provides a guided workflow for cross-account and cross-cluster Kubernetes restores in Amazon EKS from an intuitive GUI.
It was a busy week last week at KubeCon +CloudNativeCon Europe 2022 in Valencia, Spain. It seemed like the entire world related to Kubernetes came together after two years of being apart. It was fulfilling meeting up with our peers and gaining market insight- face-to-face. Catalogic’s core messaging this year has revolved around cyber-resilience for data protection.
Spring has arrived, the flowers are blooming and, for us Kubernetes fans, CNCF’s KubeCon Europe conference has just begun in Valencia! Here at Catalogic, the CloudCasa team has spent the last few months trying to top our February release by developing another set of great new features.
If you are considering Kasten today and wondering what alternatives exist for Kubernetes backup, you are at the right place where we will make our case for why CloudCasa should be your choice instead. Kasten K10 is one of the first products built to address the data protection gap in Kubernetes environments. Veeam is a market leader in data protection, and they acquired Kasten in 2021. Together, Kasten by Veeam presents a strong combination of innovation and go-to-market chops.
We are excited to have Saiyam Pathak, Director of Technical Evangelism at Civo, sign up for CloudCasa and blog the simple steps required to complete a backup and restore of a Kubernetes cluster. For those that don’t know Saiyam, he has a passion for writing and talking about Kubernetes and cloud native technologies to make them more accessible for developers. Saiyam is a CNCF ambassador and a cloud native blogger with his own Cloud Native Simplified YouTube channel.
