5 ms·

Ingress going GA and the support cycle bumping up from 9 months to 12 are my fav two things in this one. Of course it'll probably be another few months (if not

Ingress going GA and the support cycle bumping up from 9 months to 12 are my fav two things in this one. Of course it'll probably be another few months (if not six) before we see this in gke/eks.

csunbird 6y ago
EKS is still on 1.17 AWS is really dragging their feet on supporting latest version of K8s
- mattashii 6y ago
  I don't think being 3 months behind upstream release cycle is 'dragging their feet', but more 'waiting for stabilization' and 'researching and implementing required changes'.
  - csunbird 6y ago
    They started supporting 1.17 very recently, I think, because last time I checked when 1.17 was the latest stable kubernetes version, they were supporting 1.14 only. EKS is usually behind. Edit: I stand corrected. 1.17 was officially supported on July, 1.16 on April and 1.15 on March. Those versions were released a long time ago.
    - mattashii 6y ago
      True, on 17 July EKS announced k8s 1.17 GA, 1 May was k8s 1.16 GA, and 10 March for 1.15. They've been catching up. But, being behind is expected from a SaaS offering of 3rd party software: it takes time to ensure you can deliver the quality of service your customers expect, and for 3rd party software you don't get a head start.
- wronglebowski 6y ago
  As someone new to k8s and EKS it blows my mind things are only supported for such a short period of time. I find it very difficult to build a product on a platform in such constant flux. I'm struggling to see the benefits of k8s when things are rapidly being replaced and EOLd.
  - djhaskin987 6y ago
    If it helps, it may not be k8s, but more EKS. We have had terrible luck at my company with EKS, being more painful than just an on-prem k8s cluster in my experience, getting the networking working, load balancers, etc.
    - different_sort 6y ago
      Could you indulge me with any details? Not AWS or someone who works on k8s, I'm just always interested in war stories, and cloud providers "not working" is an interest too.
      - djhaskin987 6y ago
        We got an on-prem cluster working with Rancher and MetalLB with L2 configuration (MetalLB spoke ARP). It was great. We tried to do the same on EKS. we got it iniitally working, but then we needed to get the nodes on certain subnets so that HQ would be happy or something, that was hard. It felt like any time we tried to make any changes, such as adding worker nodes or deleting old ones, the ALB configuration got all messed up and we couldn't get it fixed. Super brittle. We tried with NLB too, but eventually just got tired of fighting with a tool that was supposed to make this stuff simple. I'll tell you what was simple: MetalLB on our own on-prem network.
  - starefossen 6y ago
    Just stick to stable Kubernetes API resources[1] and they are guaranteed to continue to work through all 1.x versions. [1] https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning https://kubernetes.io/docs/concepts/overview/kubernetes-api/...
  - wstrange 6y ago
    It's not quite as bad as it seems. We have had a vanishingly small number of breakages as we upgraded from early verions of Kubernetes. Mostly just tweaking a few resources where the API got promoted from beta to stable.
  - 6y ago
TuringNYC 6y ago
Ingress going GA seems big. I just read through the release notes but didnt see as much about Ingress Controllers. I always found it strange that Ingress Controllers are external components provided by the CSPs or 3rd parties (if you are going multi-cloud support as I am). Looking at NGINX, Kong, Traefik, and the loose change of community-contributed extensions to NGINX, Kong, Traefik, I always wonder why it isn't just part of the core. Anyone know if that is the eventual plan? If so, what happens to the small companies building solutions, do their products just become 2nd class citizens?
- starefossen 6y ago
  Ingress going GA refers to the Ingress API resource in the Kubernetes API becoming stable. There are no discussion (or Kubernetes Enhancement Proposals (KEPs) regarding providing a default ingress controller. There are two areas that Kubernetes has taken a hands of approach and it is ingress traffic (and external load balancing) and storage. Those are provided by external vendors through APIs.
- candiddevmike 6y ago
  This is basically why ingress isn't seen as a sexy way to integrate with Kube. Companies like F5 etc know they don't want to be a "swappable" ingress provider, so they create stickier solutions like custom operators. Additionally, most companies graduate from ingress to service mesh, or skip ingress entirely, so service mesh is the key business to capture and where most companies are targeting their efforts.
  - cmckn 6y ago
    I've used Ingress for some personal projects, and have also felt the pull towards service mesh. I've tried to set up Istio and Linkerd a couple times each, and bailed every time. These products need to be deeply integrated into the cluster (e.g. Istio installs its own ingress controller), so I've had to tear down and re-build my cluster in order to properly set up the mesh. I wish they were more approachable. Or I wish I were smarter!
    - deleted 6y ago
sturadnidge 6y ago
The rationale for the support cycle bump is a little surprising to me. I always thought it would happen with feature stabilisation, but tne reason given is simply “people weren’t upgrading”.
- pas 6y ago
  That's a pretty valid reason. It's the community taking care of itself.
cmckn 6y ago
Ingress is still a bit of a mess, IMO. The reliance on annotations to ensure functionality with a specific ingress controller feels strange in the context of other k8s API objects. I understand why Ingress works this way, but it doesn't live up to the portability expectation. I know there is a "v2" coming for Services, and I'm hopeful that Ingress continues to get love. Networking in k8s is a big problem to solve :)
- bogomipz 6y ago
  >"The reliance on annotations to ensure functionality with a specific ingress controller feels strange in the context of other k8s API objects. I understand why Ingress works this way, but it doesn't live up to the portability expectation." I'm curious what are the reasons for the reliance on annotations for this object type?
  - cmckn 6y ago
    The core Ingress object is super minimal, basically just "listen on ABC host+path and forward requests to XYZ service". But Ingress controllers can do all types of things, and might need more context to properly route the traffic. For example, you might want HTTP requests to be automatically upgraded to HTTPS. Or your ingress controller might need specific instructions if it's handling something like a gRPC connection. You might want one Ingress object handled by Traefik and another by nginx. These types of things have been addressed by adding annotations to the Ingress object. It's honestly a pretty elegant solution to a pretty hairy problem, but it ties your YAML to a specific cluster incarnation. Of course, if you use CRD's, you're in the same situation; but the dream of k8s is portability (for me).
- markdog12 6y ago
  Didn't IngressClass change that? https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class https://kubernetes.io/docs/concepts/services-networking/ingr...
  - cmckn 6y ago
    I think the result is still mostly the same, just a bit more organized. That's definitely progress though, thanks for pointing it out!

Ingress going GA and the support cycle bumping up from 9 months to 12 are my fav two things in this one. Of course it'll probably be another few months (if not six) before we see this in gke/eks.

csunbird 6y ago

EKS is still on 1.17 AWS is really dragging their feet on supporting latest version of K8s

mattashii 6y ago
I don't think being 3 months behind upstream release cycle is 'dragging their feet', but more 'waiting for stabilization' and 'researching and implementing required changes'.
- csunbird 6y ago
  They started supporting 1.17 very recently, I think, because last time I checked when 1.17 was the latest stable kubernetes version, they were supporting 1.14 only. EKS is usually behind. Edit: I stand corrected. 1.17 was officially supported on July, 1.16 on April and 1.15 on March. Those versions were released a long time ago.
  - mattashii 6y ago
    True, on 17 July EKS announced k8s 1.17 GA, 1 May was k8s 1.16 GA, and 10 March for 1.15. They've been catching up. But, being behind is expected from a SaaS offering of 3rd party software: it takes time to ensure you can deliver the quality of service your customers expect, and for 3rd party software you don't get a head start.
wronglebowski 6y ago
As someone new to k8s and EKS it blows my mind things are only supported for such a short period of time. I find it very difficult to build a product on a platform in such constant flux. I'm struggling to see the benefits of k8s when things are rapidly being replaced and EOLd.
- djhaskin987 6y ago
  If it helps, it may not be k8s, but more EKS. We have had terrible luck at my company with EKS, being more painful than just an on-prem k8s cluster in my experience, getting the networking working, load balancers, etc.
  - different_sort 6y ago
    Could you indulge me with any details? Not AWS or someone who works on k8s, I'm just always interested in war stories, and cloud providers "not working" is an interest too.
    - djhaskin987 6y ago
      We got an on-prem cluster working with Rancher and MetalLB with L2 configuration (MetalLB spoke ARP). It was great. We tried to do the same on EKS. we got it iniitally working, but then we needed to get the nodes on certain subnets so that HQ would be happy or something, that was hard. It felt like any time we tried to make any changes, such as adding worker nodes or deleting old ones, the ALB configuration got all messed up and we couldn't get it fixed. Super brittle. We tried with NLB too, but eventually just got tired of fighting with a tool that was supposed to make this stuff simple. I'll tell you what was simple: MetalLB on our own on-prem network.
- starefossen 6y ago
  Just stick to stable Kubernetes API resources[1] and they are guaranteed to continue to work through all 1.x versions. [1] https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning https://kubernetes.io/docs/concepts/overview/kubernetes-api/...
- wstrange 6y ago
  It's not quite as bad as it seems. We have had a vanishingly small number of breakages as we upgraded from early verions of Kubernetes. Mostly just tweaking a few resources where the API got promoted from beta to stable.
- 6y ago

TuringNYC 6y ago

Ingress going GA seems big. I just read through the release notes but didnt see as much about Ingress Controllers. I always found it strange that Ingress Controllers are external components provided by the CSPs or 3rd parties (if you are going multi-cloud support as I am). Looking at NGINX, Kong, Traefik, and the loose change of community-contributed extensions to NGINX, Kong, Traefik, I always wonder why it isn't just part of the core. Anyone know if that is the eventual plan? If so, what happens to the small companies building solutions, do their products just become 2nd class citizens?

starefossen 6y ago
Ingress going GA refers to the Ingress API resource in the Kubernetes API becoming stable. There are no discussion (or Kubernetes Enhancement Proposals (KEPs) regarding providing a default ingress controller. There are two areas that Kubernetes has taken a hands of approach and it is ingress traffic (and external load balancing) and storage. Those are provided by external vendors through APIs.
candiddevmike 6y ago
This is basically why ingress isn't seen as a sexy way to integrate with Kube. Companies like F5 etc know they don't want to be a "swappable" ingress provider, so they create stickier solutions like custom operators. Additionally, most companies graduate from ingress to service mesh, or skip ingress entirely, so service mesh is the key business to capture and where most companies are targeting their efforts.
- cmckn 6y ago
  I've used Ingress for some personal projects, and have also felt the pull towards service mesh. I've tried to set up Istio and Linkerd a couple times each, and bailed every time. These products need to be deeply integrated into the cluster (e.g. Istio installs its own ingress controller), so I've had to tear down and re-build my cluster in order to properly set up the mesh. I wish they were more approachable. Or I wish I were smarter!
  - deleted 6y ago

sturadnidge 6y ago

The rationale for the support cycle bump is a little surprising to me. I always thought it would happen with feature stabilisation, but tne reason given is simply “people weren’t upgrading”.

pas 6y ago
That's a pretty valid reason. It's the community taking care of itself.

cmckn 6y ago

Ingress is still a bit of a mess, IMO. The reliance on annotations to ensure functionality with a specific ingress controller feels strange in the context of other k8s API objects. I understand why Ingress works this way, but it doesn't live up to the portability expectation. I know there is a "v2" coming for Services, and I'm hopeful that Ingress continues to get love. Networking in k8s is a big problem to solve :)

bogomipz 6y ago
>"The reliance on annotations to ensure functionality with a specific ingress controller feels strange in the context of other k8s API objects. I understand why Ingress works this way, but it doesn't live up to the portability expectation." I'm curious what are the reasons for the reliance on annotations for this object type?
- cmckn 6y ago
  The core Ingress object is super minimal, basically just "listen on ABC host+path and forward requests to XYZ service". But Ingress controllers can do all types of things, and might need more context to properly route the traffic. For example, you might want HTTP requests to be automatically upgraded to HTTPS. Or your ingress controller might need specific instructions if it's handling something like a gRPC connection. You might want one Ingress object handled by Traefik and another by nginx. These types of things have been addressed by adding annotations to the Ingress object. It's honestly a pretty elegant solution to a pretty hairy problem, but it ties your YAML to a specific cluster incarnation. Of course, if you use CRD's, you're in the same situation; but the dream of k8s is portability (for me).
markdog12 6y ago
Didn't IngressClass change that? https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class https://kubernetes.io/docs/concepts/services-networking/ingr...
- cmckn 6y ago
  I think the result is still mostly the same, just a bit more organized. That's definitely progress though, thanks for pointing it out!