Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft doubles down on Kubernetes for Azure

blogs.dxc.technology

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Microsoft doubles down on Kubernetes for Azure

#51

Post by manigandham »

mephitix wrote: post #23
lobster_johnson wrote: post #10

Earlier quoted context omitted.

Fortunately there's a bunch of ingress controllers you can use: Traefik, Voyager, HAProxy, and probably several others. And it's surprisingly trivial to write your own. So ingresses is not currently a weak point in relation to vendor lock-in happens. And Kubernetes already supports plenty of non-Google tech; as an open source project, Kubernetes is refreshingly non-Google-focused (there are a bunch of players, notabl…

>> As an aside, the current ingresses (including the Nginx one and Google's own GLB one) all have annoying deficiencies Agree, this is along the lines of what I meant. For example GCE ingress allows you to reference a global static IP while this is not possible with solely nginx ingress due to limitations with the TCP load balancer. There are separate ingress annotations for GKE/nginx/haproxy, etc. If I want to use t…

You can always layer these. Have a simple global ingress pointing to a service or daemon set of nginx/haproxy.

Re: Microsoft doubles down on Kubernetes for Azure

#52

Post by otterley »

discodave wrote: post #36
Saaster wrote: post #31

Earlier quoted context omitted.

I'm almost sure they will. They don't have much of a NIH problem (look at how many DBs they support, anyone remember SimpleDB?), ECS hasn't exactly taken off, and they're generally very good at giving whatever their customers want.

Fun fact: SimpleDB still exists and has customers. It's just very very very hard to find a link to it from AWS :) https://aws.amazon.com/simpledb/

I wrote about SimpleDB earlier this year - it still has some use cases that aren't readily suited to other database providers.

https://medium.com/zendesk-engineering/resurrecting-amazon-s...

Re: Microsoft doubles down on Kubernetes for Azure

#53

Post by thockingoog »

lobster_johnson wrote: post #10
mephitix wrote: post #6

This is a good thing; Microsoft will increase competition in this space by applying its expertise in dev tools to Kubernetes. I just hope that MS doesn't add in too many platform-specific pieces that would encourage vendor lock-in. For example k8s ingress right now is based on controllers and GCE controllers support/don't support a wide variety of things compared to nginx ingress... these areas of Kubernetes make me…

Fortunately there's a bunch of ingress controllers you can use: Traefik, Voyager, HAProxy, and probably several others. And it's surprisingly trivial to write your own. So ingresses is not currently a weak point in relation to vendor lock-in happens. And Kubernetes already supports plenty of non-Google tech; as an open source project, Kubernetes is refreshingly non-Google-focused (there are a bunch of players, notabl…

The problem with Ingress "lagging" is that it was designed to be a lowest-common-denominator API - it only absorbs logic that exists in the majority of realistic implementations. For better or worse, cloud LBs are vastly more limited in feature-set than Nginx or Envoy, so Ingress is too.

This is a big topic for debate, and will be on the agenda at KubeCon in O(days).

Re: Microsoft doubles down on Kubernetes for Azure

#54

Post by thockingoog »

gkop wrote: post #2

Edit: Thanks to replies explaining that in fact AKS doesn't charge for the master! I'm leaving the rest of this comment standing because it's an honest reply to the article posted - Microsoft isn't disingenuous, this article is just wrong. > Be that as it may, Microsoft is offering AKS for free. You will only pay for the virtual machines (VM) that you use for managing your Kubernetes cluster. Microsoft says, “Unlike…

Google and GKE team member here: The AKS announcement was either poorly worded or intentionally vague. I choose to grant the benefit of the doubt.

For small clusters (less than 1-5 nodes) GKE does not currently charge anything "extra" except your own node VMs. That is LITERALLY a $0 master.

Beyond 5 nodes we currently charge a flat rate that covers your zonal master(s) regardless of how many or how big they need to be.

Re: Microsoft doubles down on Kubernetes for Azure

#55

Post by yebyen »

th3iedkid wrote: post #11
mephitix wrote: post #6

This is a good thing; Microsoft will increase competition in this space by applying its expertise in dev tools to Kubernetes. I just hope that MS doesn't add in too many platform-specific pieces that would encourage vendor lock-in. For example k8s ingress right now is based on controllers and GCE controllers support/don't support a wide variety of things compared to nginx ingress... these areas of Kubernetes make me…

In fact MS acquired Deis sometime in March this year. Draft.sh , helm etc are under MS now, while they do remain OSS.

And Deis Workflow was marked EOL later on, something like July of this year, ostensibly so those devs could devote more time to Azure and other OSS offerings.

A lot of the complexity of getting serious deployments running on Kubernetes is just neatly abstracted away by Deis, so much IMHO that now I'm not sure what to do about getting my team to take up Kubernetes without encouraging them to use Deis. To be clear, we are using Deis, but in a very limited capacity in large part because of the perceived risk associated with those yellow construction triangles[1]. (We are so lightly invested in K8S that I think we don't really have another part of the plan as of yet. The plan is to spend 6 months on ECS and not explore Kubernetes until after, can't wait to hear what news comes this week from re:invent, or if this strategy will even be realistically possible to follow once the "EKS" news hits.)

Some of us really felt like MS making this move shortly after acquiring Deis team was a bit like throwing out the baby with the bathwater, but those devs have assured us they are not just taking directions from corporate, and that they actually are going where the demand is (that there's not enough demand for Deis Workflow specifically to be strategically important for Microsoft, but there is plenty of demand for Kubernetes at-large and more Kube-native tooling around K8S issues.)

Not sure how close you've been following this story, so apologies if I'm telling you about things you already know. And I'm not one to complain about the mode of delivery that my free stuff is received in, but this change really came out of nowhere for me and has thrown a massive wrench in my own Kubernetes adoption strategy. Some of us are trying to make sure that the OSS Deis Workflow tools are not lost to bit-rot, and development of the project now continues under the name "Hephy"[2].

Also, just a minor nit, I think that although Helm was originally made by Deis, Helm[3] the package manager has not been "taken" under the Microsoft umbrella, as it was adopted and considered as a part of Kubernetes-proper before the sale of Deis.

[1]: https://github.com/deis/workflow/

[2]: https://github.com/teamhephy/workflow

[3]: https://github.com/kubernetes/helm

Re: Microsoft doubles down on Kubernetes for Azure

#56

Post by lobster_johnson »

thockingoog wrote: post #53
lobster_johnson wrote: post #10

Earlier quoted context omitted.

Fortunately there's a bunch of ingress controllers you can use: Traefik, Voyager, HAProxy, and probably several others. And it's surprisingly trivial to write your own. So ingresses is not currently a weak point in relation to vendor lock-in happens. And Kubernetes already supports plenty of non-Google tech; as an open source project, Kubernetes is refreshingly non-Google-focused (there are a bunch of players, notabl…

The problem with Ingress "lagging" is that it was designed to be a lowest-common-denominator API - it only absorbs logic that exists in the majority of realistic implementations. For better or worse, cloud LBs are vastly more limited in feature-set than Nginx or Envoy, so Ingress is too. This is a big topic for debate, and will be on the agenda at KubeCon in O(days).

This is understandable, of course. In hindsight, I suspect the current concept of an abstract, one-size-fits-all ingress was, and is, going in the wrong direction.

With CRDs, we could have each ingress controller provide its own, native ingress object ("nginx-ingress") that had the exact features it supported (with schema validation). The ingress controller would then create or delete cloud-specific CRDs ("google-loadbalancer") based on what flavour of cloud you're running under, which Kubernetes could pick up and use. Or something like that.

But as you say, some of the friction exists because cloud LBs are limited in the first place. The arbitrary cert limit on GCP is particularly egregious. We run a SaaS solution with about 100 vendor domains, which means we've been forced to use the Nginx ingress controller and terminate TLS there, instead of at the GLB level where it arguably belongs. (We could run 10 GLBs, but that would require splitting our ingresses into 10 separate ingresses, with the duplication and potential for copy/paste errors that would ensue.)

But thirdly, it's also true that several of the ingress implementations are just a bit sloppy. Traefik, Voyager and haproxy-ingress all have issues with using TLS certs (all of them have open issues about serving both HTTP and HTTPS at the same time, I believe). A lot of today's ergonomics could be solved by polishing up these projects.

Re: Microsoft doubles down on Kubernetes for Azure

#57

Post by thockingoog »

lobster_johnson wrote: post #56
thockingoog wrote: post #53

Earlier quoted context omitted.

The problem with Ingress "lagging" is that it was designed to be a lowest-common-denominator API - it only absorbs logic that exists in the majority of realistic implementations. For better or worse, cloud LBs are vastly more limited in feature-set than Nginx or Envoy, so Ingress is too. This is a big topic for debate, and will be on the agenda at KubeCon in O(days).

This is understandable, of course. In hindsight, I suspect the current concept of an abstract, one-size-fits-all ingress was, and is, going in the wrong direction. With CRDs, we could have each ingress controller provide its own, native ingress object ("nginx-ingress") that had the exact features it supported (with schema validation). The ingress controller would then create or delete cloud-specific CRDs ("google-loa…

First, Ingress had a purpose to serve, and it has served that purpose - it is relatively easy to handle low-complexity apps with generic Ingress.

But low-complexity apps don't stay that way.

What you're describing is very much the way my brain has gone. In my experience, most users end up using at least one non-portable annotation on Ingress. The logical conclusion then, is that people care about features MORE than portability in this facet of the API.

This is not surprising to me, given how religious the debate tends to be...

Re: Microsoft doubles down on Kubernetes for Azure

#58

Post by org3432 »

bonesss wrote: post #50
org3432 wrote: post #38

So restaurants give you ketchup for "free" too, but turns out you're paying for it. This is stupid to say the management node is free, you're just paying for it in another way. Now if they said they were able to run the node so cost effectively that it's just included in the hourly node cost, then that's a plus.

For SMBs and smaller dev shops kicking off their forays into container development, not to mention customer deployments, the simplified cost models make it more management friendly and more understandable to non-IT actors. Whether it is absolutely cheaper than GCE or whatever, and if master management is a requirement, is a separate comparison based on the solution. Cutting out the management node costs removes a bar…

I'm sure you're right, but not understand economics to that level wow.

Re: Microsoft doubles down on Kubernetes for Azure

#59

Post by thockingoog »

thockingoog wrote: post #54
gkop wrote: post #2

Edit: Thanks to replies explaining that in fact AKS doesn't charge for the master! I'm leaving the rest of this comment standing because it's an honest reply to the article posted - Microsoft isn't disingenuous, this article is just wrong. > Be that as it may, Microsoft is offering AKS for free. You will only pay for the virtual machines (VM) that you use for managing your Kubernetes cluster. Microsoft says, “Unlike…

Google and GKE team member here: The AKS announcement was either poorly worded or intentionally vague. I choose to grant the benefit of the doubt. For small clusters (less than 1-5 nodes) GKE does not currently charge anything "extra" except your own node VMs. That is LITERALLY a $0 master. Beyond 5 nodes we currently charge a flat rate that covers your zonal master(s) regardless of how many or how big they need to b…

...and as of today there is no fee for masters on GKE.

https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster...

Re: Microsoft doubles down on Kubernetes for Azure

#60

Post by zenlikethat »

tyingq wrote: post #37
zenlikethat wrote: post #32

Earlier quoted context omitted.

I seriously doubt it’s a deliberate strategy on their part in this case, but Microsoft has been known to pull this type of maneuver in the past: Step one: “We love Kubernetes! Run it on Azure! It’s great” Step two: “Kubernetes experience on Azure is best enjoyed using Microsoft Enterprise Ingress, Microsoft Custom Resources for Business, and developing in Visual Studio. Use those!” Step three: “Oh, the CTO wants to m…

Plausible, but not as if AWS doesn't promote it's own proprietary lock in services. K8S does help a bit in this regard, but all three of the cloud big cloud players have reasons, products, policies, and strategies to lock you in.

Yup, just explaining how K8s is not a magic salve you can rub on everything to prevent vendor lock-in.
Post reply on HN