As Kubernetes celebrates its 7th birthday this month, developers and enterprises continue to adopt containers and Kubernetes rapidly as the preferred technology and platform for creating, deploying, and operating their modern cloud-native applications and refactoring existing traditional applications. Many such applications are business critical — an outage or loss of data associated with them can result in a loss of revenue, productivity, reputation, and more. Therefore it’s more important than ever to be able to protect, recover, and move Kubernetes workloads quickly and easily within and across clusters, public cloud regions, and on-premises data centers.
With the NetApp® Astra™ Control software-defined platform, our goal is to enable you to deploy and run business-critical Kubernetes workloads with the enterprise-grade data and storage management functionality that you expect from NetApp for your traditional workloads. With Astra, your Kubernetes application is always protected, and it can be recovered and migrated or moved at any time based on your business continuity and data protection requirements, no matter where your Kubernetes clusters are running.
Astra Control has two variants:
We understand that protecting and recovering Kubernetes applications in an enterprise involves many user personas. These personas have distinct and sometimes overlapping requirements in managing the lifecycle of their applications and their associated data. We often work with the following personas:
A Kubernetes application is not a well-defined concept. With Astra, we have taken an approach based on the industry-standard best practices for how users commonly deploy Kubernetes applications. Astra allows you to protect, recover, and move entire namespaces or a distinct set of resources (ConfigMaps, Secrets, Deployment, Pod, PVC, PV, StatefulSet, etc.) within a namespace that can be grouped with a common label and designated as an application. This approach offers the flexibility to arbitrarily group resources as different applications, allowing you to protect and recover their data based on your needs.
The following sections describe the use cases that Astra addresses.
Astra provides a single pane of glass control pane for all your Kubernetes application data assets. You can view all your clusters, all you apps, in all clouds or in all data-centers using one portal. You can use the Astra APIs consistently in all environments (on-premises or public clouds) to design your data management workflows.
When you add a Kubernetes cluster to be managed by Astra, Astra automatically creates storage classes for persistent storage consumption by your applications. You specify the default storage class that you want your applications to use. This radically simplifies the job of the Kubernetes admin, who typically provisions the Kubernetes clusters and the associated storage classes for providing persistent volumes for applications in the cluster.
Astra automatically discovers applications in your Kubernetes clusters as they are added, which means that all new namespaces with resources within them are discovered dynamically. After discovery, you can choose to manage entire namespaces, or distinct applications that map to a collection of resources within the namespace, or both. This flexibility enables granular protection and recovery management for your namespaces and applications, allowing you to set distinct protection policies based on your business and application uptime needs.
For example, in a namespace n1 with two apps, app1 and app2, you could make a backup of app1 in n1 once an hour, a backup of app2 in n1 once a day, and the entire namespace n1 once a week, or not at all. Automatic application discovery gives the Kubernetes admin a single pane of glass for application protection management for multiple clusters across multiple data centers or multiple clouds. In addition, Astra delivers real-time actionable insights for protection status per application, enabling application admins and Kubernetes admins to quickly tell whether their applications are adequately protected.
As an application owner, you can take both on-demand and scheduled Snapshot copies and backups of your applications and namespaces. You can trigger on-demand Snapshot copies when you need to checkpoint the current state of your application — for example, before an update or upgrade. You can set up a Snapshot and/or backup schedule to match the RPO and RTO requirements for your application. The Snapshot copes are stored in the local storage system, while the backups are securely stored in a remote location (object storage). This approach allows you to employ a 3-2-1 backup strategy, which is the best practice for protecting applications and their associated data. As a storage or backup admin, you can back up all namespaces in all clusters so that you can recover entire clusters.
With Astra, an application admin or Kubernetes admin can recover namespaces and applications at any time, as long as they have existing Snapshot copies or backups. To match the RPO and RTO needs of your applications, you should take copies and backups at a frequency that meets your business continuity objectives and keep multiple copies, both local and remote. Adopting such a strategy can protect against a range of issues that may include accidental application data corruption, malicious deletion of one of more namespaces, or a public cloud region or data center hosting your K8s cluster suffering a service degradation or outage. Astra’s Snapshot and backup scheduler makes it easy for you to do so. Additionally, an application admin can recover from a specific issue by taking on-demand Snapshot copies and/or backups — for example, before upgrading the Kubernetes cluster or updating a particular app in the cluster. Astra enables you to recover your application in the same cluster, a different cluster in the same region, a separate cluster in another region, and even in a cluster in another public cloud. As a storage or backup admin, you can back up all namespaces in all clusters so that you can recover full clusters after a disaster.
With Astra, an application leader or owner can easily clone applications and namespaces to support various scenarios. These dev/test use cases might include testing an application with more traffic in a separate cluster, cloning a namespace with crashed applications to another namespace in the same or a different cluster, triggering a backup before upgrading an application, and more. Application cloning can also be used to enable migration use cases. For example, application migration can be triggered by data residency requirements or by the desire to move applications geographically closer to application teams to reduce access latency. Astra enables cloning from an existing Snapshot copy or a backup to reduce the time it takes to clone your application. You can clone your application in the same cluster, a different cluster in the same region, a different cluster in another region, and even in a cluster in another public cloud.
As a Kubernetes admin, you can view all the data lifecycle operations that an application and namespace have been subjected to. Astra effectively provides an audit trail of all operations that all users in an account have performed on all applications. Astra also supports various roles for users within an account, with access levels that determine, allow, or restrict what a user with a particular role can do with application data.
Astra Control already provides a rich set of advanced application data management functionality, but we’re just getting started. The Astra team at NetApp is working on more capabilities and is busy supporting Astra in more environments with a broad set of storage providers and Kubernetes platforms. So stay tuned as we accelerate the rollout for Astra Control over the next several months.
Check out Astra Control today and get started with a free plan.