11–20 of 54 posts
Sadly startup interest changed and then went under (but the freedom I was given to explore there was the best experience I have ever had)
One consequence is the accidental deletion of AWS things... If a CRD is deleted the CRs described it are also deleted. So, deleting a CRD (even accidentally) could end up deleting resources in AWS (e.g., backups). So, be careful. Some things being managed by Kubernetes would be really cool. Other things being managed by k8s could break things if something goes wrong. I would plan accordingly.
Our goal is to make this project have "no surprises" and therefore no unexpected destruction of resources. The specifics of how we mark resource as safe to delete instead of retaining by default are under discussion on that Github issue.
Kelsey Hightower had a good take in https://twitter.com/kelseyhightower/status/12963119515307048... "AWS Controllers for Kubernetes is pretty dope. You can leverage Kubernetes to manage AWS resources such as API gateways and S3 buckets. Think Terraform but backed by Kubernetes style APIs and "realtime" control loops." An in the thread he mentions Crossplane as the cross-cloud way to do this https://twitter.com/kelsey…
Every Kubernetes shop I've seen uses Helm to deploy their workloads, & now you can set up all your S3 Buckets, SQS, SNS stuff in that same Helm chart as your app. This is hella ideal. I also just generally love the thought of being able to manage any cloud resources at all via standard open-protocols & systems. Compounding the investment, rather than having to invest in a bunch of specific not-interconnected areas is…
Does it have functionality like Kube DB that makes a “dormant” version of the state store?
One consequence is the accidental deletion of AWS things... If a CRD is deleted the CRs described it are also deleted. So, deleting a CRD (even accidentally) could end up deleting resources in AWS (e.g., backups). So, be careful. Some things being managed by Kubernetes would be really cool. Other things being managed by k8s could break things if something goes wrong. I would plan accordingly.
Hi I'm a developer advocate in the AWS Container organization. This question of how to handle resource destruction is an active issue on the project, and we'd welcome your comments (or those of anyone else) on this Github issue: https://github.com/aws/aws-controllers-k8s/issues/82 Our goal is to make this project have "no surprises" and therefore no unexpected destruction of resources. The specifics of how we mark re…
One consequence is the accidental deletion of AWS things... If a CRD is deleted the CRs described it are also deleted. So, deleting a CRD (even accidentally) could end up deleting resources in AWS (e.g., backups). So, be careful. Some things being managed by Kubernetes would be really cool. Other things being managed by k8s could break things if something goes wrong. I would plan accordingly.
In this case the delete will appear to succeed, but the recreation, if done with the same name, may fail.
Pass, I'll check back in a year.
One consequence is the accidental deletion of AWS things... If a CRD is deleted the CRs described it are also deleted. So, deleting a CRD (even accidentally) could end up deleting resources in AWS (e.g., backups). So, be careful. Some things being managed by Kubernetes would be really cool. Other things being managed by k8s could break things if something goes wrong. I would plan accordingly.
Exactly. Planning accordingly is the right answer. Assume anyone can destroy your infrastructure at any time (by mistake or otherwise). This could be done with cloudformation, terraform, API calls, and essentially any automation(with different levels of safeguards). Be prepared for that. Be careful with your data. Not so careful with individual servers - they should be cattle, not pets. EDIT: If this is a production…
Earlier quoted context omitted.
Every Kubernetes shop I've seen uses Helm to deploy their workloads, & now you can set up all your S3 Buckets, SQS, SNS stuff in that same Helm chart as your app. This is hella ideal. I also just generally love the thought of being able to manage any cloud resources at all via standard open-protocols & systems. Compounding the investment, rather than having to invest in a bunch of specific not-interconnected areas is…
It’s all fun and games until a deployment is acting funny and somebody destroys the chart and re-creates it and takes the bucket out with it. Does it have functionality like Kube DB that makes a “dormant” version of the state store?
I don't use AWS so I didn't look into this thoroughly, but the word "finalizer" does show up in the code frequently:
// MarkManaged places the supplied resource under the management of ACK.
// What this typically means is that the resource manager will decorate the
// underlying custom resource (CR) with a finalizer that indicates ACK is
// managing the resource and the underlying CR may not be deleted until ACK
// is finished cleaning up any backend AWS service resources associated
// with the CR.
One consequence is the accidental deletion of AWS things... If a CRD is deleted the CRs described it are also deleted. So, deleting a CRD (even accidentally) could end up deleting resources in AWS (e.g., backups). So, be careful. Some things being managed by Kubernetes would be really cool. Other things being managed by k8s could break things if something goes wrong. I would plan accordingly.
One layer of defense in all of these cases is keeping the IAM credentials that the configuration management tool uses from having any deletion permissions.