111–120 of 178 posts
Reading few blogs and forums about it today - people talking about switching to Gateway API (from "legacy" Ingress). And I do not understand it: 1. Ingress still works, it's not deprecated. 2. There a lot of controllers, which supports both: Gateway API and Ingress (for example Traefik) So, how Ingress Nginx retiring related / affects switch to Gateway API?
How do you people even keep up with this? I'm going back to cybersecurity after trying DevOps for a year, it's not for me. I miss my sysadmin days, things were simple back then and worked. Maybe I'm just getting old and my cognitive abilities are declining. It seems to me that the current tech scene doesn't reward simple.
It's exactly why taking a trip through the ops/infra side is so important for people - you learn why LTS-style engineering is so important. You learn to pick technologies that are stable, reliable, well-supported by a large-enough people who are conservative in their approach, for anything foundational, because the alternative is migration pain again and again.
Though now AI slop is upon us so we'll probably be even worse off for a while.
How do you people even keep up with this? I'm going back to cybersecurity after trying DevOps for a year, it's not for me. I miss my sysadmin days, things were simple back then and worked. Maybe I'm just getting old and my cognitive abilities are declining. It seems to me that the current tech scene doesn't reward simple.
Kubernetes is promoting Gateway API for a while now. It's in GA for 2 years already (while Ingress was in GA quite late, 2020/K8s 1.19?).
Sun-setting ingress-nginx was not exactly a secret.
The whole Ingress in k8s is marked in docs as "frozen" for a while as well. There are no radical steps yet, but it's clear that Gateway API is something to get interested in.
Meanwhile Nginx Gateway Fabric [1] (which implements gateway API) is there, still uses nginx under the hood and remains opensource. They even have a "migration tool" to convert objects [3].
There are still a few months of support and time to move on to a different controller. Kubernetes still continues support for ingress so if you want to switch and keep using Ingress, there are other controllers [2].
[1] https://gateway-api.sigs.k8s.io/implementations/#nginx-gatew...
[2] https://gateway-api.sigs.k8s.io/implementations/#gateway-con...
[3] https://docs.nginx.com/nginx-gateway-fabric/install/ingress-...
Earlier quoted context omitted.
> things were simple back then If you were working in the orgs targeted by k8s, I think it was generally more of a mess. Think about managing a park of 100~200 servers with home made bash scripts and crappy monitoring tools and a modicum of dashboards. Now, k8s has engulfed a lot more than the primary target, but smaller shops go for it because they'r also hoping to hit it big someday I guess. Otherwise, there will b…
You can manage and reason about ~2000+ servers without Kubernetes, even with a relatively small team, say about 100 - 150, depending on what kind of business you're in. I'd recommend either Puppet, Ansible (with AWX) and/or Ubuntu Landscape (assuming that your in the Ubuntu ecosystem). Kubernetes is for rather special case environments. I am coming around to the idea of using Kubernetes more, but I still think that i…
Because 100-150 for the devops would be crazy for a mid-sized system like that.
Unless you're managing Windows servers or something.
How do you people even keep up with this? I'm going back to cybersecurity after trying DevOps for a year, it's not for me. I miss my sysadmin days, things were simple back then and worked. Maybe I'm just getting old and my cognitive abilities are declining. It seems to me that the current tech scene doesn't reward simple.
One thing that I push for nowadays, after a few scars is managed platforms.
Earlier quoted context omitted.
Just out of curiosity, what's wrong with either of those two?
Docker is not for production. Nomad at scale in practice needs a lot of load-bearing Bash scripts around it: for managing certs, for external DNS, you need Consul for service discovery, Vault for secrets. At that point, is Nomad still simple? If you're going to take on all of the essential complexity of deploying software at scale, just do it right and use Kubernetes. Source: running thousands of containers in produc…
Kubernetes uses etcd for service discovery. It isn't that Nomad does things differently or less simply, it is just that they are more explicit about it.
The real difference is that Kubernetes has a wide array of cloud hosts that hide the complexity from users, whereas Nomad can realistically be self hosted
How do you people even keep up with this? I'm going back to cybersecurity after trying DevOps for a year, it's not for me. I miss my sysadmin days, things were simple back then and worked. Maybe I'm just getting old and my cognitive abilities are declining. It seems to me that the current tech scene doesn't reward simple.
> things were simple back then If you were working in the orgs targeted by k8s, I think it was generally more of a mess. Think about managing a park of 100~200 servers with home made bash scripts and crappy monitoring tools and a modicum of dashboards. Now, k8s has engulfed a lot more than the primary target, but smaller shops go for it because they'r also hoping to hit it big someday I guess. Otherwise, there will b…
We have Configuration Management systems like Puppet in mature enough state for over a decade now.
I haven't installed server manually or "with handmade scripts" in good 12 years by now.
We have park of around 100-200 servers and actually managing hardware is tiny part of it
> Now, k8s has engulfed a lot more than the primary target, but smaller shops go for it because they'r also hoping to hit it big someday I guess. Otherwise, there will be far easier solutions at lower scale.
K8S is popular because it gives developers a lot of power to deploy stuff, without caring much at underlying systems, without bothering ops people too much. Cloud-wise there is a bunch of native ways to just run a few containers that don't involve it but onprem it is nice way to get a bit faster iteration cycle on infrastructure, even if complexity cost is high.
It is overkill for I'd imagine most stuff deployed in K8S and half of deployments are probably motivated by resume padding rather than actual need.
Kubernetes is never maturing. It keeps moving. An installation just a year ago would have things that would require significant planning to upgrade. What is missing is an open source orchestrator that has a feature freeze and isn't Nomad or docker swarm.
But I'd love LTS release chain that keeps config same for at least 2-3 years.
How do you people even keep up with this? I'm going back to cybersecurity after trying DevOps for a year, it's not for me. I miss my sysadmin days, things were simple back then and worked. Maybe I'm just getting old and my cognitive abilities are declining. It seems to me that the current tech scene doesn't reward simple.
> things were simple back then If you were working in the orgs targeted by k8s, I think it was generally more of a mess. Think about managing a park of 100~200 servers with home made bash scripts and crappy monitoring tools and a modicum of dashboards. Now, k8s has engulfed a lot more than the primary target, but smaller shops go for it because they'r also hoping to hit it big someday I guess. Otherwise, there will b…
Not even that. One repository I checked this week had some commits which messages were like "synchronize code with what is on production server". Awesome. And that's not counting the number of hidden adhoc cronjobs on multiple servers.
Also as a dev I like having a pool of "compute" where I can decide to start a new project whenever instead of having to ask some OPS team for servers, routing, DNS config.
Kubernetes is never maturing. It keeps moving. An installation just a year ago would have things that would require significant planning to upgrade. What is missing is an open source orchestrator that has a feature freeze and isn't Nomad or docker swarm.
I think services take me literally half an hour a month or so to deal with unless something major has changed, and a major K8s version upgrade where I roll all nodes is a few hours.
If people are deploying clusters and not touching them for a year+ then like any system you're going to end up with endless tech debt that takes "significant planning" to upgrade. I wouldn't do a distro upgrade between Ubuntu LTS releases without expecting a lot of work, in fact I'd probably just rebuild the server(s) using tool of choice.