4 ms·

Someone like Chick-fil-A has tens of thousands of cash registers that are really just little Linux computers. They want to make sure all of those registers are

Someone like Chick-fil-A has tens of thousands of cash registers that are really just little Linux computers. They want to make sure all of those registers are running their most up to date cash register code, has access to their internal Chick-fil-A data, (inventory, finances, menu, etc) and do it in a fault tolerant way so one store losing internet access will eventually recover when it gets online again. Kubernetes is perfect for this kind of scenario--Chick-fil-A HQ runs a k8s control plane that all of the stores and registers connect to as nodes and receive explicit code and other state to run. From a central command they can instantly update everything, monitor it, add/remove nodes, etc. They can do it all with just k8s and kubectl, they aren't bodging together piles of shell scripts, ansible scripts, custom tools, etc.

remram 4y ago
Kubernetes is not perfect for this scenario at all? Kubernetes is meant for clusters of interchangeable computers, to make sure a networked app stays available when losing some nodes. It provides unified networking (all pods in same network, even if on different nodes), service discovery, scaling, zero-downtime upgrades. None of that works or even makes sense if you have end-user devices. Nodes are not interchangeable, you can't route around breakage (if one point of sale goes down, that's one physical device with a dark screen, adding one pod somewhere else won't help), the networking is mostly useless, zero-downtime impossible (you have only one physical screen to use, can't have two containers grab it during a rolling upgrade), service discovery is irrelevant unless you are running your database on those cash registers for some reason. Use Ansible/Salt/... instead. Kubernetes is hype, and it's what people know, and it can technically do some of those things, but it's a terrible tool for this job.
- cassianoleal 4y ago
  Your entire second paragraph seems to wholly ignore the existence of StatefulSets.
  - remram 4y ago
    You mean DaemonSets, maybe? I don't know what you're trying to say.
    - cassianoleal 4y ago
      lol you're right, I do. Sorry, was just waking up when I wrote that! What I'm trying to say, is: > Nodes are not interchangeable They don't have to be. You just need to make sure that certain pods run on all nodes that match certain criteria. That can be easily achieved with DaemonSets, taints and tolerations. > you can't route around breakage (if one point of sale goes down, that's one physical device with a dark screen, Sure, that's the same regardless of how you deploy software to the POS. > adding one pod somewhere else won't help) DaemonSets won't do that, so it's not a problem. > the networking is mostly useless, zero-downtime impossible (you have only one physical screen to use, can't have two containers grab it during a rolling upgrade) I believe your argument here is that k8s provides more features than what you need. That can be said about anything, all the way down to the hardware. Surely there's a lot of things the CPU on the POS can do that's mostly useless in this context. > service discovery is irrelevant unless you are running your database on those cash registers for some reason. Same as above, I guess...?
      - remram 4y ago
        As I said, it "can technically do some of those things, but it's a terrible tool for this job". You can also use Kubernetes as a key-value database, wrapping values in ConfigMaps. You can do that, it will work. It is a terrible tool for that job too.
        cassianoleal 4y ago
        It's definitely not meant to be used as a key-value database and I agree it's a terrible tool for that - although that capability can be useful in certain situations. That said, it's actually meant to deploy software to computers. It's actually not bad at all at that. I see nothing in your arguments that show why it's a terrible tool for this job. That said, this is mostly personal opinion anyway. You say using ansible/salt/etc is better for this job. It might be, depending on many factors. It's not great either though. I imagine Kubernetes is solving real problems for those who are using it in this kind of context. Note that I'm not defending it, I just don't see why it would be so bad.
locustous 4y ago
Can track inventory and sales via couchdb, it's built for accommodating limited connectivity and maintaining versioning and updating a remote sync. Have the clients update themselves when new releases are done. Have a backup access method, say, ssh if there are issues. Corporate can pull all relevant data from couch to know the exact state of the distributed network.

remram 4y ago

Kubernetes is not perfect for this scenario at all? Kubernetes is meant for clusters of interchangeable computers, to make sure a networked app stays available when losing some nodes. It provides unified networking (all pods in same network, even if on different nodes), service discovery, scaling, zero-downtime upgrades. None of that works or even makes sense if you have end-user devices. Nodes are not interchangeable, you can't route around breakage (if one point of sale goes down, that's one physical device with a dark screen, adding one pod somewhere else won't help), the networking is mostly useless, zero-downtime impossible (you have only one physical screen to use, can't have two containers grab it during a rolling upgrade), service discovery is irrelevant unless you are running your database on those cash registers for some reason. Use Ansible/Salt/... instead. Kubernetes is hype, and it's what people know, and it can technically do some of those things, but it's a terrible tool for this job.

cassianoleal 4y ago
Your entire second paragraph seems to wholly ignore the existence of StatefulSets.
- remram 4y ago
  You mean DaemonSets, maybe? I don't know what you're trying to say.
  - cassianoleal 4y ago
    lol you're right, I do. Sorry, was just waking up when I wrote that! What I'm trying to say, is: > Nodes are not interchangeable They don't have to be. You just need to make sure that certain pods run on all nodes that match certain criteria. That can be easily achieved with DaemonSets, taints and tolerations. > you can't route around breakage (if one point of sale goes down, that's one physical device with a dark screen, Sure, that's the same regardless of how you deploy software to the POS. > adding one pod somewhere else won't help) DaemonSets won't do that, so it's not a problem. > the networking is mostly useless, zero-downtime impossible (you have only one physical screen to use, can't have two containers grab it during a rolling upgrade) I believe your argument here is that k8s provides more features than what you need. That can be said about anything, all the way down to the hardware. Surely there's a lot of things the CPU on the POS can do that's mostly useless in this context. > service discovery is irrelevant unless you are running your database on those cash registers for some reason. Same as above, I guess...?
    - remram 4y ago
      As I said, it "can technically do some of those things, but it's a terrible tool for this job". You can also use Kubernetes as a key-value database, wrapping values in ConfigMaps. You can do that, it will work. It is a terrible tool for that job too.
      - cassianoleal 4y ago
        It's definitely not meant to be used as a key-value database and I agree it's a terrible tool for that - although that capability can be useful in certain situations. That said, it's actually meant to deploy software to computers. It's actually not bad at all at that. I see nothing in your arguments that show why it's a terrible tool for this job. That said, this is mostly personal opinion anyway. You say using ansible/salt/etc is better for this job. It might be, depending on many factors. It's not great either though. I imagine Kubernetes is solving real problems for those who are using it in this kind of context. Note that I'm not defending it, I just don't see why it would be so bad.

locustous 4y ago

Can track inventory and sales via couchdb, it's built for accommodating limited connectivity and maintaining versioning and updating a remote sync. Have the clients update themselves when new releases are done. Have a backup access method, say, ssh if there are issues. Corporate can pull all relevant data from couch to know the exact state of the distributed network.