4 ms·

The article and some of the comments are a strange take. There is a place for docker. There is a place for Kubernetes. They dont have much overlap in my mind.

The article and some of the comments are a strange take. There is a place for docker. There is a place for Kubernetes. They dont have much overlap in my mind. If I want to run an elastic production system with many components, and scale each component independently, i'd use Kubernetes. ...But if I want to run a Jupyter+PyTorch stack easily w/o wasting half a day on CUDA library dependency issues, I would use Docker without Kubernetes -- because I dont want to go down the rabbithole of 1. Installing kubernetes on my laptop 2. Ingress Controller hell 2b. Ingress Controller route/path/url annotation hell to make something like Jupyter work in Kubernetes ...when I can do that in 5 minutes with docker.

joana035 6y ago
> 2. Ingress Controller hell > 2b. Ingress Controller route/path/url annotation hell... Sorry, but that is no hard at all and I can't imagine why you compare it to "hell". It is literally less than 20 lines to define an ingress object.
- matsemann 6y ago
  Sometimes I've spent hours on a single config line, so having to write 20 of some unknown thing sounds scary. And it's irrelevant for what he is trying to do, which is to run something locally. With docker that's one command, vs having to set up all the other stuff as well. I've been very fan of using docker for all our dev stuff. To run something locally before it meant having correct version of lots of stuff, and possible having installed some database, configure it correctly etc. Onboarding could be days of configuring this stuff and having something fail. Now it's just download docker, run our ./setup.sh that spins up the various docker images, and one's almost good to go.
  - joana035 6y ago
    Well, looks like some fundamental knowledge is missing here, that why everything looks like "hell" or is "scary". I wonder how many lines from this "./setup.sh" could have been avoided by trying a bit harder to understand how the ingress object works. I no longer see lazyness as a good trait in programing.
    - matsemann 6y ago
      You are missing the point. In this hypothetical case I'm not interested in knowing how Kubernetes works or is deployed, I'm only interested in running my tools. It's not laziness, it's pragmatism so I can solve what I'm actually trying to solve.
  - TuringNYC 6y ago
    The challenge especially once you get to requiring Ingress Controllers is they are not a core part of Kubernetes, but third party. So you have NGINX, Kong, Traefik -- over a half dozen in total. Not all are fully featured in their open source form, so in some cases you need to purchase the tool to do something like url-rewrite. In some cases, the solution exists, but is something contributed via community (better than none, great in theory, but brittle given the pace of platform change.) Further, once you actually try to spend time on it, you find there is little to no documentation on topics such as url-rewrite. It is all interesting, but then you realize you actually have deadlines -- and now you've spent half the day on futzing around with annotation permutations (since there are few/no docs) and you have not actually started working on the actual task of tuning a model on PyTorch...that is when you drop down to just 'docker run...' It is all worth learning, and doing, but only if you need to. If I need to make something -- in this story Jupyter+PyTorch -- work for many people and be elastic and scalable, then sure, i'll go thru the effort. But if I need a throw-away instance for the day, then it is not worth doing.
- yjftsjthsd-h 6y ago
  > It is literally less than 20 lines to define an ingress object. ...and this is your idea of easy? For something that should be as simple as "this path goes to this group" + "this group is these containers"?
  - atombender 6y ago
    Not sure what you think isn't easy about it: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myingress spec: rules: - http: paths: - host: example.com path: / pathType: Prefix backend: service: name: test port: number: 80 Since everything except "spec" is common to all Kubernetes resources, this arguably isn't much different than an Nginx configuration file: upstream backend { server some-backend:80; } server { listen :80; server_name example.com; location / { proxy_pass http://backend; } }
    - TuringNYC 6y ago
      This is great, until I need to run two Jupyter+Pytorch instances (say I want to test two library versions side by side, a very common task). ...on docker, I can do this in 20sec: "docker run .... -p 8888:8888" "docker run .... -p 8888:8889" Enter k8s. Jupyter does not appear to allow path prefix-based url schemes, so the above wont work. That means, you can use "/" and the default-host, and you're good for your first instance. But what about the next instance? Now you need two different domains somehow supported. Unclear how this works, because unclear whose "problem" it is. It isnt clearly an NGINX problem, or a Jupyter problem, or a k8s problem, but a problem nonetheless. NGINX docs on multiple distinct host based ingress is thinner than that for base usage cases. I do appreciate your post, but I think my point is that solving 80% of the cases isn't sufficient to make the case for adhoc k8s-usage-by-default on desktop. I'm sure I can make the above work (e.g. for group or Prod usage), but to make that effort worth it, there has to be a reason to do it. When I have an alternative of running two "docker run" commands for adhoc usage, i'm not sure if it is.
stingraycharles 6y ago
Of course but you’re forgetting that Docker is a commercial organization as well. If not for large scale container orchestration in the cloud, how can they add value that’s worth paying considerable $ for?
- TuringNYC 6y ago
  I think whether Docker adds value (1) and how to capture the value (2) are separate questions. This response was the value it adds. I think it adds a tremendous amount of value, and widespread academic and corporate usage speaks to that. To your point, they also need to capture that value, because it would be a pity to lose Docker. I cover that in the thread of how they profit with one idea: https://news.ycombinator.com/item?id=25326062 https://news.ycombinator.com/item?id=25326062 There are other potential ideas -- marketplaces, indemnification services, security services. I hope they figure something out.
enos_feedler 6y ago
The overlap is in compatibility and consistency of the "units of programming" they can both run natively. I think of docker as the REPL for cloud computing.

joana035 6y ago

> 2. Ingress Controller hell > 2b. Ingress Controller route/path/url annotation hell... Sorry, but that is no hard at all and I can't imagine why you compare it to "hell". It is literally less than 20 lines to define an ingress object.

matsemann 6y ago
Sometimes I've spent hours on a single config line, so having to write 20 of some unknown thing sounds scary. And it's irrelevant for what he is trying to do, which is to run something locally. With docker that's one command, vs having to set up all the other stuff as well. I've been very fan of using docker for all our dev stuff. To run something locally before it meant having correct version of lots of stuff, and possible having installed some database, configure it correctly etc. Onboarding could be days of configuring this stuff and having something fail. Now it's just download docker, run our ./setup.sh that spins up the various docker images, and one's almost good to go.
- joana035 6y ago
  Well, looks like some fundamental knowledge is missing here, that why everything looks like "hell" or is "scary". I wonder how many lines from this "./setup.sh" could have been avoided by trying a bit harder to understand how the ingress object works. I no longer see lazyness as a good trait in programing.
  - matsemann 6y ago
    You are missing the point. In this hypothetical case I'm not interested in knowing how Kubernetes works or is deployed, I'm only interested in running my tools. It's not laziness, it's pragmatism so I can solve what I'm actually trying to solve.
- TuringNYC 6y ago
  The challenge especially once you get to requiring Ingress Controllers is they are not a core part of Kubernetes, but third party. So you have NGINX, Kong, Traefik -- over a half dozen in total. Not all are fully featured in their open source form, so in some cases you need to purchase the tool to do something like url-rewrite. In some cases, the solution exists, but is something contributed via community (better than none, great in theory, but brittle given the pace of platform change.) Further, once you actually try to spend time on it, you find there is little to no documentation on topics such as url-rewrite. It is all interesting, but then you realize you actually have deadlines -- and now you've spent half the day on futzing around with annotation permutations (since there are few/no docs) and you have not actually started working on the actual task of tuning a model on PyTorch...that is when you drop down to just 'docker run...' It is all worth learning, and doing, but only if you need to. If I need to make something -- in this story Jupyter+PyTorch -- work for many people and be elastic and scalable, then sure, i'll go thru the effort. But if I need a throw-away instance for the day, then it is not worth doing.
yjftsjthsd-h 6y ago
> It is literally less than 20 lines to define an ingress object. ...and this is your idea of easy? For something that should be as simple as "this path goes to this group" + "this group is these containers"?
- atombender 6y ago
  Not sure what you think isn't easy about it: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myingress spec: rules: - http: paths: - host: example.com path: / pathType: Prefix backend: service: name: test port: number: 80 Since everything except "spec" is common to all Kubernetes resources, this arguably isn't much different than an Nginx configuration file: upstream backend { server some-backend:80; } server { listen :80; server_name example.com; location / { proxy_pass http://backend; } }
  - TuringNYC 6y ago
    This is great, until I need to run two Jupyter+Pytorch instances (say I want to test two library versions side by side, a very common task). ...on docker, I can do this in 20sec: "docker run .... -p 8888:8888" "docker run .... -p 8888:8889" Enter k8s. Jupyter does not appear to allow path prefix-based url schemes, so the above wont work. That means, you can use "/" and the default-host, and you're good for your first instance. But what about the next instance? Now you need two different domains somehow supported. Unclear how this works, because unclear whose "problem" it is. It isnt clearly an NGINX problem, or a Jupyter problem, or a k8s problem, but a problem nonetheless. NGINX docs on multiple distinct host based ingress is thinner than that for base usage cases. I do appreciate your post, but I think my point is that solving 80% of the cases isn't sufficient to make the case for adhoc k8s-usage-by-default on desktop. I'm sure I can make the above work (e.g. for group or Prod usage), but to make that effort worth it, there has to be a reason to do it. When I have an alternative of running two "docker run" commands for adhoc usage, i'm not sure if it is.

stingraycharles 6y ago

Of course but you’re forgetting that Docker is a commercial organization as well. If not for large scale container orchestration in the cloud, how can they add value that’s worth paying considerable $ for?

TuringNYC 6y ago
I think whether Docker adds value (1) and how to capture the value (2) are separate questions. This response was the value it adds. I think it adds a tremendous amount of value, and widespread academic and corporate usage speaks to that. To your point, they also need to capture that value, because it would be a pity to lose Docker. I cover that in the thread of how they profit with one idea: https://news.ycombinator.com/item?id=25326062 https://news.ycombinator.com/item?id=25326062 There are other potential ideas -- marketplaces, indemnification services, security services. I hope they figure something out.

enos_feedler 6y ago

The overlap is in compatibility and consistency of the "units of programming" they can both run natively. I think of docker as the REPL for cloud computing.