4 ms·

> 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

> 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.

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.