3 ms·

Surely you recognize that we had services that could talk to each other before k8s existed? And therefore all of the things you point to are solved problems and

Surely you recognize that we had services that could talk to each other before k8s existed? And therefore all of the things you point to are solved problems and don't require k8s in any way, shape, or form? Like, if I'm configuring the foo service and it needs to know how to contact the bar service... that's not a problem? I just put bar-service-lb.mycompany.net in a config file and I'm done. I don't understand why people think they need complex "service discovery". Just give things names! My cloud provider (or heaven forbid, wires in a data center! gasp!) already gives me perfectly good networking. Why layer anything on top of that? No one really needs "ingress". Your server program can listen on a port! Like we've been doing for 50 years! This is a completely self-inflicted problem. It's so depressing seeing the k8s generation completely forget the highly effective ways that we used to do things. All those things are still possible! You can choose to design, build, and run a simple system if you want to!

KronisLV 4y ago
> Like, if I'm configuring the foo service and it needs to know how to contact the bar service... that's not a problem? I just put bar-service-lb.mycompany.net in a config file and I'm done. I don't understand why people think they need complex "service discovery". Just give things names! What about when you're given a few servers for your dev/test environment, but don't have control over the DNS server and adding records to it has an annoying amount of red tape? Would this be a good option: - FOO_URL=http://300.0.0.1:3000 - BAR_URL=http://300.0.0.1:8080 - BAZ_URL=http://300.0.0.2:80 - X_URL=http://300.0.0.2:5601 - Y_URL=http://300.0.0.3:5602 Or would this be better: - FOO_URL=http://foo.dev.svc.cluster.local - BAR_URL=http://bar.dev.svc.cluster.local - BAZ_URL=http://baz.dev.svc.cluster.local - X_URL=http://x.dev.svc.cluster.local - Y_URL=http://y.dev.svc.cluster.local Sure, you can achieve the same with just modifying a hosts file, but what about when you need to propagate some changes to every computer and other server that needs to talk to these apps, while you are still not in control of the DNS server? I guess you can just run your own DNS server at that point as well, but that might raise some eyebrows in some places, vs just using whatever the orchestrator provides you with out of the box (and Kubernetes also has built in proxy functionality so people can connect to the cluster pretty easily and forward whichever services they want, which can take a bit of work otherwise, though i guess you'd get used to the proper order of arguments in the SSH tunnel commands too). > No one really needs "ingress". Your server program can listen on a port! Like we've been doing for 50 years! This is a completely self-inflicted problem. What if you want all of your services to have SSL/TLS certificates provisioned for them? What if you want to ensure that all of the inter-service communication is also encrypted? What about you wanting to add circuit breaking or rate limiting logic in there? Or maybe doing a MitM on yourself so you can debug the network traffic between the services better? Also, do you really want to configure the firewall rules for each of your internal services to be able to talk to others, or wouldn't it also be good to have it piggyback its traffic on some other overlay networking port that's open on all of them for cluster communications? Oh, also to avoid weirdness with CORS or other technologies, it might be nice to route requests based on domains and paths, instead of ports (e.g. my-app.com/analytics might be better than my-app.com:9000 in some contexts), though of course that is easily achievable with any reverse proxy, just saying that ports aren't always the best option. Personally, I think that there's a lot of benefit to using an ingress and a service mesh of some sort, as long as those don't add too much undue complexity. I mean, using our own Nginx/Apache/Caddy/Traefik instance instead of the Ingress abstraction was also perfectly passable, but there are certainly benefits to exploring new technologies and what they offer. In my experience, all of these container technologies providing you with their own DNS implementation out of the box is very useful, especially because recognizing that "300.0.0.1:3000" is the wrong URL is harder than looking at "foo.dev.svc.cluster.local" and seeing that your service probably doesn't intend to connect to foo. > It's so depressing seeing the k8s generation completely forget the highly effective ways that we used to do things. All those things are still possible! You can choose to design, build, and run a simple system if you want to! I do agree with this, though! There should be more resources out there to show off how to do basic and useful networking without getting too deeply into some of the fancier technologies.
- icod 4y ago
  Running your own DNS isn't as hard as you think
  - KronisLV 4y ago
    I'm not saying that it's too hard at all (even though servers like BIND could probably use some UX improvements), just that not everyone would approve of you running your own server for any given project. And sometimes adding/changing records on the org-wide server must be "thrown over the wall", which will be slow. Furthermore, if you have 5 different projects that you need to work on and each of those would have their own separate DNS servers, you might find yourself in a slightly uncomfortable situation. Most container orchestration solutions don't have that problem, because they embed their own server and provide the necessary proxying solutions so that you may connect to the cluster from outside as well.
- ptman 4y ago
  Making something work with a IPv4 octet of 300 (decimal) is a trick I'd like to see... (and I'm not talking about https://ma.ttias.be/theres-more-than-one-way-to-write-an-ip-address/ https://ma.ttias.be/theres-more-than-one-way-to-write-an-ip-... )
  - KronisLV 4y ago
    That's intentional, just so i don't give someone's actual IP address in my silly example. Or, you know, make people misunderstand the example by providing a local address when I intend to give an example where a set of remote boxes are being discussed. :) Might as well have dug up https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4 https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4 but the arbitrary nature of it all hurts my head.
qbasic_forever 4y ago
K8s doesn't reinvent anything. It uses DNS for service discovery, just like you describe. It happily opens ports for ingress if you'd like (or it talks to your cloud provider load balancer to do the same). K8s is literally just a few go-based API endpoints that orchestrate all kinds of existing things like DNS, container scheduling, etc. What K8s does is provide a simple and idiomatic rest API on top of all this architecture. No longer do you have to read a ton of disparate man pages, figure out what the sysadmin 10 years ago did for DNS, etc.. you just use kubectl or the API. It's the same interface to spin up more replicas of a frontend service as it is to open a port for ingress or even collect and review logs.

KronisLV 4y ago

> Like, if I'm configuring the foo service and it needs to know how to contact the bar service... that's not a problem? I just put bar-service-lb.mycompany.net in a config file and I'm done. I don't understand why people think they need complex "service discovery". Just give things names! What about when you're given a few servers for your dev/test environment, but don't have control over the DNS server and adding records to it has an annoying amount of red tape? Would this be a good option: - FOO_URL=http://300.0.0.1:3000 - BAR_URL=http://300.0.0.1:8080 - BAZ_URL=http://300.0.0.2:80 - X_URL=http://300.0.0.2:5601 - Y_URL=http://300.0.0.3:5602 Or would this be better: - FOO_URL=http://foo.dev.svc.cluster.local - BAR_URL=http://bar.dev.svc.cluster.local - BAZ_URL=http://baz.dev.svc.cluster.local - X_URL=http://x.dev.svc.cluster.local - Y_URL=http://y.dev.svc.cluster.local Sure, you can achieve the same with just modifying a hosts file, but what about when you need to propagate some changes to every computer and other server that needs to talk to these apps, while you are still not in control of the DNS server? I guess you can just run your own DNS server at that point as well, but that might raise some eyebrows in some places, vs just using whatever the orchestrator provides you with out of the box (and Kubernetes also has built in proxy functionality so people can connect to the cluster pretty easily and forward whichever services they want, which can take a bit of work otherwise, though i guess you'd get used to the proper order of arguments in the SSH tunnel commands too). > No one really needs "ingress". Your server program can listen on a port! Like we've been doing for 50 years! This is a completely self-inflicted problem. What if you want all of your services to have SSL/TLS certificates provisioned for them? What if you want to ensure that all of the inter-service communication is also encrypted? What about you wanting to add circuit breaking or rate limiting logic in there? Or maybe doing a MitM on yourself so you can debug the network traffic between the services better? Also, do you really want to configure the firewall rules for each of your internal services to be able to talk to others, or wouldn't it also be good to have it piggyback its traffic on some other overlay networking port that's open on all of them for cluster communications? Oh, also to avoid weirdness with CORS or other technologies, it might be nice to route requests based on domains and paths, instead of ports (e.g. my-app.com/analytics might be better than my-app.com:9000 in some contexts), though of course that is easily achievable with any reverse proxy, just saying that ports aren't always the best option. Personally, I think that there's a lot of benefit to using an ingress and a service mesh of some sort, as long as those don't add too much undue complexity. I mean, using our own Nginx/Apache/Caddy/Traefik instance instead of the Ingress abstraction was also perfectly passable, but there are certainly benefits to exploring new technologies and what they offer. In my experience, all of these container technologies providing you with their own DNS implementation out of the box is very useful, especially because recognizing that "300.0.0.1:3000" is the wrong URL is harder than looking at "foo.dev.svc.cluster.local" and seeing that your service probably doesn't intend to connect to foo. > It's so depressing seeing the k8s generation completely forget the highly effective ways that we used to do things. All those things are still possible! You can choose to design, build, and run a simple system if you want to! I do agree with this, though! There should be more resources out there to show off how to do basic and useful networking without getting too deeply into some of the fancier technologies.

icod 4y ago
Running your own DNS isn't as hard as you think
- KronisLV 4y ago
  I'm not saying that it's too hard at all (even though servers like BIND could probably use some UX improvements), just that not everyone would approve of you running your own server for any given project. And sometimes adding/changing records on the org-wide server must be "thrown over the wall", which will be slow. Furthermore, if you have 5 different projects that you need to work on and each of those would have their own separate DNS servers, you might find yourself in a slightly uncomfortable situation. Most container orchestration solutions don't have that problem, because they embed their own server and provide the necessary proxying solutions so that you may connect to the cluster from outside as well.
ptman 4y ago
Making something work with a IPv4 octet of 300 (decimal) is a trick I'd like to see... (and I'm not talking about https://ma.ttias.be/theres-more-than-one-way-to-write-an-ip-address/ https://ma.ttias.be/theres-more-than-one-way-to-write-an-ip-... )
- KronisLV 4y ago
  That's intentional, just so i don't give someone's actual IP address in my silly example. Or, you know, make people misunderstand the example by providing a local address when I intend to give an example where a set of remote boxes are being discussed. :) Might as well have dug up https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4 https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4 but the arbitrary nature of it all hurts my head.

qbasic_forever 4y ago

K8s doesn't reinvent anything. It uses DNS for service discovery, just like you describe. It happily opens ports for ingress if you'd like (or it talks to your cloud provider load balancer to do the same). K8s is literally just a few go-based API endpoints that orchestrate all kinds of existing things like DNS, container scheduling, etc. What K8s does is provide a simple and idiomatic rest API on top of all this architecture. No longer do you have to read a ton of disparate man pages, figure out what the sysadmin 10 years ago did for DNS, etc.. you just use kubectl or the API. It's the same interface to spin up more replicas of a frontend service as it is to open a port for ingress or even collect and review logs.