CloudWatch Events can already do this for you. I wish it were exposed through automation; that's still coming, but in the interim it's still a solution that minimizes your own failure surface. Do AWS tasks with AWS's tools whenever you can--it minimizes points of failure that you have to manage. Check it: http://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Ta...
I've also seen people use Lambda, which is halfway to "do AWS tasks with AWS's tools"; it's only a few lines of code and can be flexibly triggered without this much bulk. (Same code can usually be tossed in cron.)
If you want to go the persistent-daemon approach, there's something like automated-ebs-snapshots (which I used before CloudWatch Events came along), which is reasonably bulletproofed and is already used in anger: https://github.com/skymill/automated-ebs-snapshots
Writing stuff like this is decent practice to get comfortable with the AWS APIs, but these are generally solved problems. I'd be real uncomfortable with k8s's "secrets? what's that? is that something I store unencrypted?" approach to anything remotely sensitive when I'm throwing AWS credentials around; AWS already provides a better ACL method for this sort of thing in IAM. (If you have insisted on a k8s cluster and you aren't able to leverage IAM, this is a problem on your end that should be rectified sooner than soon.)
An EBS-snapshot should give a crash-consistent image. However, it's probably better to freeze if you can. If you're doing RAID across multiple volumes, you almost definitely need to freeze your volumes while all the snapshots start.
What is the benefit of assuming additional risk by inserting this into your infrastructure instead of using AWS's existing stuff?
(I will admit: am being a little hard on you because I think this is a bad idea. On the scale of bad ideas, it's only a bad idea and not a really bad idea, but it's a bad idea.)
I've also seen people use Lambda, which is halfway to "do AWS tasks with AWS's tools"; it's only a few lines of code and can be flexibly triggered without this much bulk. (Same code can usually be tossed in cron.)
If you want to go the persistent-daemon approach, there's something like automated-ebs-snapshots (which I used before CloudWatch Events came along), which is reasonably bulletproofed and is already used in anger: https://github.com/skymill/automated-ebs-snapshots
Writing stuff like this is decent practice to get comfortable with the AWS APIs, but these are generally solved problems. I'd be real uncomfortable with k8s's "secrets? what's that? is that something I store unencrypted?" approach to anything remotely sensitive when I'm throwing AWS credentials around; AWS already provides a better ACL method for this sort of thing in IAM. (If you have insisted on a k8s cluster and you aren't able to leverage IAM, this is a problem on your end that should be rectified sooner than soon.)