commvault.com commvault.com
Solved

Kubernetes backup with kubectl

  • 25 January 2022
  • 11 replies
  • 358 views
Frank Grimes
Rank
Badge +4

Our PaaS team is interested in running backups with kubectl and I couldn’t give them a straight answer on this. Is this something that could be built or is in the works?

icon

Best answer by Mathew Ericson 27 January 2022, 00:30

View original
If you have a question or comment, please create a topic

11 replies

dude
Rank
Badge +15

You will need a service account that has cluster admin access on the namespace. I tested some kubernetes before but had issues with the storage side of things.

Refer to: https://documentation.commvault.com/11.24/essential/129223_create_service_account_for_kubernetes.html

Supported Config: https://documentation.commvault.com/11.24/essential/123637_supported_configurations_for_kubernetes.html

 

Frank Grimes
Rank
Badge +4

@dude Our service account is setup and has admin rights across the cluster so we’re good there. I can backup/restore from the Command Center with no issues. As soon as I opened up the UI they made some remark about doing self-service backup with the CLI and I wasn’t sure if that was even possible or available.

dude
Rank
Badge +15

I believe you can do that but could not tell you exactly how. I`m sure someone will pitch in here with the details for you but meanwhile, if you havent yet, take a look on these articles.

 

 

 

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

@Mathew Ericson would be a good resource on this :nerd:

https://www.linkedin.com/in/michael-struening
Onno van den Berg
Rank
Userlevel 7
Badge +19

I guess the question from @Frank Grimes is basically if we can expect Commvault to come up with a kubectl operator extension that allows for people who administer Kubernetes to perform configuration tasks en backup and restore actions all from the CLI without the need to go out to an external interface like Command Center. 

Frank Grimes
Rank
Badge +4

@Onno van den Berg Correct. Our DevOps/PaaS team is a little resistant when it comes to using an external tool like Command Center. They’re in the CLI all day and would prefer to stay there when managing/monitoring our k8s clusters. We had similar struggles with our DBA’s when managing SQL backups/restores. They preferred to leverage SSMS so we pushed out the plug-in for them.

Onno van den Berg
Rank
Userlevel 7
Badge +19

Yeah I totally understand where you are coming from and I can adhere to it. Sometimes change can be very beneficial and offer many advantages but in the cases you refer to we indeed often have the same discussions and request. I b.t.w. was hoping they already released an operator e.g. I told development in the early beginnings that they should take it into account. Having an operator makes sure Kubernetes will embrace the solution more quickly and if all works out well can even result in them becoming fans. One example that comes with an extensive CLI for Kubernetes is Velero. Would be great if this is also coming for Commvault. 

Mathew Ericson
Rank
Userlevel 4
Badge +6

@Mathew Ericson would be a good resource on this :nerd:

Thanks @Mike Struening 

Very interesting discussion and while I can’t comment on anything that may or may not be in development - my advice to @Frank Grimes , @Onno van den Berg  would be to reach out to their Commvault Sales team who can brief them under NDA on what we have running in Commvault Labs.

At a high-level we see a number of approaches today - the more common scenario we see today is
- onboard a kubernetes cluster
- create a app group matching the label selectors + plan (based on value of the data)
- let commvault and the ‘backup operator’ manage and monitor backups and recovery readiness

We don’t see alot of DevOps engineers that want to actively run a kubectl based backup - using Commvault’s label selector auto-discovery & protection gives DevOs engineers the ability to integrate Commvault in GitsOps managed apps - without requiring the developer to be running backups or restores via kubectl command line.

Hit me up at twitter.com/mericsonAU
MFasulo
Rank
Userlevel 6
Badge +12

I guess the question from @Frank Grimes is basically if we can expect Commvault to come up with a kubectl operator extension that allows for people who administer Kubernetes to perform configuration tasks en backup and restore actions all from the CLI without the need to go out to an external interface like Command Center. 

 

 

this is the way

Onno van den Berg
Rank
Userlevel 7
Badge +19

@Mathew Ericson would be a good resource on this :nerd:

Thanks @Mike Struening 

Very interesting discussion and while I can’t comment on anything that may or may not be in development - my advice to @Frank Grimes , @Onno van den Berg  would be to reach out to their Commvault Sales team who can brief them under NDA on what we have running in Commvault Labs.

At a high-level we see a number of approaches today - the more common scenario we see today is
- onboard a kubernetes cluster
- create a app group matching the label selectors + plan (based on value of the data)
- let commvault and the ‘backup operator’ manage and monitor backups and recovery readiness

We don’t see alot of DevOps engineers that want to actively run a kubectl based backup - using Commvault’s label selector auto-discovery & protection gives DevOs engineers the ability to integrate Commvault in GitsOps managed apps - without requiring the developer to be running backups or restores via kubectl command line.

@Mathew Ericson you are making a separation between a user and a backup administrator who monitors the backup and the readiness. And that is exactly the difference between organizations in where you have different roles and responsibilities and organizations who are working according to DevOps in where the backup administrator is more often a platform administrator who makes sure the environment is ready to serve the business needs. I agree that the label selectors + plan help to onboard Kubernetes workloads to be onboarded automatically from code, but it does not allow the Kubernetes engineers to perform on-demand backups (think of upgrades) and recoveries from the CLI and this what you want to improve the usability from a Kubernetes engineering perspective. It would definitely help in making sure that the solution is actually embraced by the Kubernetes admins as the tool to be used to satisfy their data protection needs for their stateful applications. 

MFasulo
Rank
Userlevel 6
Badge +12

@Mathew Ericson would be a good resource on this :nerd:

Thanks @Mike Struening 

Very interesting discussion and while I can’t comment on anything that may or may not be in development - my advice to @Frank Grimes , @Onno van den Berg  would be to reach out to their Commvault Sales team who can brief them under NDA on what we have running in Commvault Labs.

At a high-level we see a number of approaches today - the more common scenario we see today is
- onboard a kubernetes cluster
- create a app group matching the label selectors + plan (based on value of the data)
- let commvault and the ‘backup operator’ manage and monitor backups and recovery readiness

We don’t see alot of DevOps engineers that want to actively run a kubectl based backup - using Commvault’s label selector auto-discovery & protection gives DevOs engineers the ability to integrate Commvault in GitsOps managed apps - without requiring the developer to be running backups or restores via kubectl command line.

@Mathew Ericson you are making a separation between a user and a backup administrator who monitors the backup and the readiness. And that is exactly the difference between organizations in where you have different roles and responsibilities and organizations who are working according to DevOps in where the backup administrator is more often a platform administrator who makes sure the environment is ready to serve the business needs. I agree that the label selectors + plan help to onboard Kubernetes workloads to be onboarded automatically from code, but it does not allow the Kubernetes engineers to perform on-demand backups (think of upgrades) and recoveries from the CLI and this what you want to improve the usability from a Kubernetes engineering perspective. It would definitely help in making sure that the solution is actually embraced by the Kubernetes admins as the tool to be used to satisfy their data protection needs for their stateful applications. 

 

this is a good convo, its balancing “what we hear”.  

Terms & ConditionsCookie settings