Kubernetes 1.19

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md

by gtirloni • 6 years ago

116 39 6 years ago

github.com

cagenut• 6 years ago

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.

csunbird4• 6 years ago

EKS is still on 1.17

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

mattashii2• 6 years 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'.

wronglebowski• 6 years 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.

TuringNYC• 6 years 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?

starefossen2• 6 years 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.

candiddevmike2• 6 years 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.

csunbird4• 6 years ago

On an unrelated note, did anyone here try Skipper as their ingress controller? We are torn between Skipper and HAProxy.

Our use case is transferring large size files and NGINX is rumored to have bad performance in that regard.

jrockway2• 6 years ago

I think the problem is that HTTP reverse proxies do so much, it's hard to specify what Kubernetes should do and what you should get an external solution to do. (Personally I am appalled at how org-wide SSO works right now, and almost started my own company to sell an open-source solution to the problem. But... I don't know how to start a company and then there was a pandemic. Someone else will sell you a not-as-good solution for mega-bucks.)

In my opinion, people are always going to want their special thing; compatibility with their legacy nginx.conf, support for HTTP/3, whatever. Kubernetes can never satisfy people with those requirements. For that reason, I think people need to agree on a service discovery protocol, a route discovery protocol, and then hook those into their frontend proxy of choice. For example, I never really liked Ingress (lots of unspecified landmines, like what order rules are evaluated in when matching a request to a route), and so just run Envoy inside Kubernetes. Envoy is then fed a static route table and a valid TLS certificate, and handles all traffic in an explicit and easy to debug way. I wrote something to glue Envoy's service discovery to Kubernetes so my static config file contains less boilerplate (https://github.com/jrockway/ekglue), and it's served me well. (I need to write something to add route table entries to DNS, though. I currently do that by editing my DNS records in a web interface, which is tedious and uninteresting.)

With that in mind, what people should really be focusing on is standardizing xDS (Envoy's config language basically), and hooking it into their container orchestration framework and web server of choice. Then you can run Nginx on Openshift or Apache on ECS and everyone is using the same tools to do the very boring gruntwork of figuring out what your backends are called, and what syntax you use to say "send all requests that match example.com/foobar to a backend my container orchestration framework calls foo-bar-v2". I am sure it will sort itself out eventually -- xDS has a lot of momentum in things that aren't Envoy (notably gRPC), so this could all be a solved problem outside of Kubernetes soon enough.

harpratap2• 6 years ago

The path going forward is to split L7 layer proxies and L3/L4 layer - https://kubernetes-sigs.github.io/service-apis/spec/ "Ingress" is too broad of a term and it does too much and too little depending on your use case

sturadnidge• 6 years 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”.

pas2• 6 years ago

That's a pretty valid reason. It's the community taking care of itself.

cmckn4• 6 years 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 :)

markdog12• 6 years ago

Didn't IngressClass change that?

https://kubernetes.io/docs/concepts/services-networking/ingr...

bogomipz• 6 years 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?

different_sort2• 6 years ago

Reminder it's time to get off 1.16 now. Only 3 versions (current-2) are supported upstream.

https://kubernetes.io/docs/setup/release/version-skew-policy...

merb• 6 years ago

well, gcloud gke regular is still on 1.16.

sciurus• 6 years ago

And GKE stable is on 1.15.

Although you can't launch new clusters on it anymore, Google hasn't even forced clusters on 1.14 to update to a newer version yet.

clhodapp• 6 years ago

Tell that to Google. Their "regular" (recommended) release channel in their managed Kubernetes Engine product regularly falls off the back of the supported range, while their "rapid" channel barely stays within it.

alec_kendall• 6 years ago

I’d like to see those two teams eat lunch together

random3• 6 years ago

I was preparing to say "Tell that to GCP!" :) In their defense it's one of the services that you fire and forget. It seems to just work.

Kubernetes 1.19

Related Stories