Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Controllers for Kubernetes

github.com

Post reply on HN
Print view View original

51–54 of 54 posts

Re: AWS Controllers for Kubernetes

#51

Post by jpeeler »

digitallogic wrote: post #16
mfer wrote: post #8

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.

Also, not all AWS follow the same deletion semantics. Example: S3 buckets. The report as being deleted somewhat quickly, but their name may not be available again for hour or so. In this case the delete will appear to succeed, but the recreation, if done with the same name, may fail.

Does the create during this time window return a specific enough error? This seems like the exact case where a controller that never gives up could provide value. Though I'm kind of amazed this is on the order of an hour instead of minutes.

Re: AWS Controllers for Kubernetes

#52

Post by rektide »

etxm wrote: post #14
rektide wrote: post #5

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?

metadata: annotations: helm.sh/resource-policy: keep

works for any & all resources!

Re: AWS Controllers for Kubernetes

#53

Post by rektide »

nrmitchi wrote: post #21
etxm wrote: post #14

Earlier quoted context omitted.

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?

This is, in my opinion, the most dangerous thing about CRDs, especially for resources that are not scoped the the cluster. It is way to easy to accidently delete something you need. PV's were my first experience dealing with this (a chart upgrade recreated a PVC, the old one unbound, and was immediately cleaned up), and it's not a risk that I want to see extended to buckets, RDS instances, etc. The other side of this…

If you've used helm for more than one day you'd know about the helm.sh/resource-policy: keep,

Which makes your first big "accidentally deleted" concern pretty near moot, so long as it's your ci/CD tools with permissions & they are using helm. So long as random cluster users aren't futzing around randomly poking at & deleting things.

Yes, you have to go way further & prevent your idiot users from being dumb, if you are giving them cluster role permissions. But again, have you considered not doing that?

Abandoned resources is no less of an issue. If there are external resources that don't have state (such as your Load balancer examp, the good news is you can delete them all & let the resource controllers recreate the real ones.

In general I feel like you are letting the 1% of concerns dominate & dissuade you, & that most people can make it very far with nothing extra.

Re: AWS Controllers for Kubernetes

#54

Post by nrmitchi »

rektide wrote: post #53
nrmitchi wrote: post #21

Earlier quoted context omitted.

This is, in my opinion, the most dangerous thing about CRDs, especially for resources that are not scoped the the cluster. It is way to easy to accidently delete something you need. PV's were my first experience dealing with this (a chart upgrade recreated a PVC, the old one unbound, and was immediately cleaned up), and it's not a risk that I want to see extended to buckets, RDS instances, etc. The other side of this…

If you've used helm for more than one day you'd know about the helm.sh/resource-policy: keep, Which makes your first big "accidentally deleted" concern pretty near moot, so long as it's your ci/CD tools with permissions & they are using helm. So long as random cluster users aren't futzing around randomly poking at & deleting things. Yes, you have to go way further & prevent your idiot users from being dumb, if you ar…

> If you've used helm for more than one day

I'm not sure why you're popping in to a thread from a week ago, starting with personal insinuations against my qualifications to have an opinion, and being a generally uncivil person.

You should try to make your points without the condescending attitude.

Post reply on HN