4 ms·

Hey man, I get that you need something NOW and I am sorry about that, but I have to say this is a teeeeensy bit over the top. Yeah, StatefulSet is still beta.

Hey man, I get that you need something NOW and I am sorry about that, but I have to say this is a teeeeensy bit over the top. Yeah, StatefulSet is still beta. We're getting miles on it before we tell people that we 100% back it. But you know what? People ARE using it. In production. With real data. And they mostly are just fine. I run a (tiny) database against k8s. I trust it with my own data. What you say "the container engine underlying k8s will delete all changes made to the image" is true - don't write files straight to your image FS! This is containers 101. We have PersistentVolumes for this very reason. Data that has a lifetime of its own. Does this absolve you from backups? No. Does it mean you don't need to think about upgrades? Hell no, you still have to know what your apps are up to. Nobody is making people use containers for databases, but the power of systems like Kubernetes is pretty addictive, and a lot of people are pouring a lot of energy into this problem.

cookiecaper 9y ago
I'm sorry, I just don't buy it. I understand that k8s is experimental and young -- and IMO that makes it exactly the wrong kind of thing to be running production workloads, Google association notwithstanding. None of this is meant to assault or attack Kubernetes for what it is, it's meant to highlight the absurdity of how it's being used and promoted. >What you say "the container engine underlying k8s will delete all changes made to the image" is true - don't write files straight to your image FS! This is containers 101. We have PersistentVolumes for this very reason. Data that has a lifetime of its own. Yeah, I'm not disputing this. It's just the most immediate and shocking example of how Docker can be tricky for stateful apps. On most systems, if your program is writing something to the filesystem, it's expected to persist. Any potentiality for lost files/data is normally treated as opt-in (writing to a temp folder). Are you sure you got every nook and cranny where your program expected to read/write from disk, and set all of your symlinks up right, etc.? Why deal with this? >Does this absolve you from backups? No. Does it mean you don't need to think about upgrades? Hell no, you still have to know what your apps are up to. The problem with every buzzword or hyped-up piece of software is that everyone just assumes it has magical powers. They have to get some mileage on it to realize that while it may offer some improvements, we still live in the real world. I know the Kubernetes authors are aware of this, but I wish more Kubernetes users were. >Nobody is making people use containers for databases, but the power of systems like Kubernetes is pretty addictive, and a lot of people are pouring a lot of energy into this problem. But why? Kubernetes is cool but it doesn't seem any more "addictive" than what I had before, which effectively did the same thing: a script that spun up an instance from an image, connected to it with Ansible, automatically provisioned everything, and turned it on, and similar scripts that allowed me to view the state of my other instances and apply transformations on them. You can argue that they're different scripts and k8s is one program, but it's really just a difference in invocation. Obviously I know that Kubernetes operates on containers and not VM instances, but in terms of how it affects our daily lives, k8s is, more or less, just another interface into management/automation technology that we've had since virtualization went mainstream. What are the truly innovative or unique things it brings to the table? It mostly seems to consolidate these management things into one binary, which, don't get me wrong, is a totally fine thing to do. But it doesn't sound like it would give one "addictive powers". I don't understand why someone wants to take a square peg and pound it through a round hole. Database servers are designed for dedicated machines. They want all the RAM, they want all the CPU, they want kernel parameters tuned to their liking, sometimes even kernel versions (which you can't replace on a container). On production, if you have any significant amount of traffic, you want to give the database what it wants. So what practical value do I get by putting PgSQL in a container and/or in Kubernetes? It just sounds like a massive headache for no real benefit.

cookiecaper 9y ago

I'm sorry, I just don't buy it. I understand that k8s is experimental and young -- and IMO that makes it exactly the wrong kind of thing to be running production workloads, Google association notwithstanding. None of this is meant to assault or attack Kubernetes for what it is, it's meant to highlight the absurdity of how it's being used and promoted. >What you say "the container engine underlying k8s will delete all changes made to the image" is true - don't write files straight to your image FS! This is containers 101. We have PersistentVolumes for this very reason. Data that has a lifetime of its own. Yeah, I'm not disputing this. It's just the most immediate and shocking example of how Docker can be tricky for stateful apps. On most systems, if your program is writing something to the filesystem, it's expected to persist. Any potentiality for lost files/data is normally treated as opt-in (writing to a temp folder). Are you sure you got every nook and cranny where your program expected to read/write from disk, and set all of your symlinks up right, etc.? Why deal with this? >Does this absolve you from backups? No. Does it mean you don't need to think about upgrades? Hell no, you still have to know what your apps are up to. The problem with every buzzword or hyped-up piece of software is that everyone just assumes it has magical powers. They have to get some mileage on it to realize that while it may offer some improvements, we still live in the real world. I know the Kubernetes authors are aware of this, but I wish more Kubernetes users were. >Nobody is making people use containers for databases, but the power of systems like Kubernetes is pretty addictive, and a lot of people are pouring a lot of energy into this problem. But why? Kubernetes is cool but it doesn't seem any more "addictive" than what I had before, which effectively did the same thing: a script that spun up an instance from an image, connected to it with Ansible, automatically provisioned everything, and turned it on, and similar scripts that allowed me to view the state of my other instances and apply transformations on them. You can argue that they're different scripts and k8s is one program, but it's really just a difference in invocation. Obviously I know that Kubernetes operates on containers and not VM instances, but in terms of how it affects our daily lives, k8s is, more or less, just another interface into management/automation technology that we've had since virtualization went mainstream. What are the truly innovative or unique things it brings to the table? It mostly seems to consolidate these management things into one binary, which, don't get me wrong, is a totally fine thing to do. But it doesn't sound like it would give one "addictive powers". I don't understand why someone wants to take a square peg and pound it through a round hole. Database servers are designed for dedicated machines. They want all the RAM, they want all the CPU, they want kernel parameters tuned to their liking, sometimes even kernel versions (which you can't replace on a container). On production, if you have any significant amount of traffic, you want to give the database what it wants. So what practical value do I get by putting PgSQL in a container and/or in Kubernetes? It just sounds like a massive headache for no real benefit.