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

As Kubernetes grows, a startup ecosystem develops in its wake

techcrunch.com

Post reply on HN
Print view View original

71–80 of 156 posts

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#71

Post by outworlder »

anoncoward1234 wrote: post #55

Kubernetes is cool and all, but there needs to be a lot of simplification for it to be "nice to use". Essentially the problem is that it's the "opposite" of Golang - the number of ways to do the same thing is massive leading to huge numbers of headaches in trying to get things done. Recently, I spun up a simple pod-to-pod communication example but I found it pretty difficult. If you look up cluster networking in Kube…

Why don't you use something like Kops? It will create (and manage) the cluster for you.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#72

Post by outworlder »

atombender wrote: post #3

Kubernetes is one of those rare cases where the industry is rallying around a technologically sound platform that emerged from the trenches, and not something that was designed to create jobs for consultants. It's great. Right now, there's a bunch of fairly traditional players such as Red Hat, but none of them are in a position to mess it up. What I'm waiting for, though, is for a big player to do a modern, clean "Ku…

> For example, I should be able to define a persistent disk using a Kubernetes manifest, instead of having to go through some web UI or CLI ("gcloud compute disk create" or whatever).

What do you mean? You can do exactly that today, with persistent volume claims. K8s will create the storage volume for you and make it available for containers. This is "dynamic provisioning".

https://kubernetes.io/docs/concepts/storage/persistent-volum...

What is missing is being able to create other resources. For instance, define a EC2 instance as a k8s object and have K8s provision it, for legacy or anything you haven't moved to K8s yet(databases, etc). I see no technical reason why it cannot be implemented today.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#73

Post by lobster_johnson »

outworlder wrote: post #72
atombender wrote: post #3

Kubernetes is one of those rare cases where the industry is rallying around a technologically sound platform that emerged from the trenches, and not something that was designed to create jobs for consultants. It's great. Right now, there's a bunch of fairly traditional players such as Red Hat, but none of them are in a position to mess it up. What I'm waiting for, though, is for a big player to do a modern, clean "Ku…

> For example, I should be able to define a persistent disk using a Kubernetes manifest, instead of having to go through some web UI or CLI ("gcloud compute disk create" or whatever). What do you mean? You can do exactly that today, with persistent volume claims. K8s will create the storage volume for you and make it available for containers. This is "dynamic provisioning". https://kubernetes.io/docs/concepts/storage…

See my reply here: https://news.ycombinator.com/item?id=17015475.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#75

Post by StudentStuff »

jpdb wrote: post #38
StudentStuff wrote: post #27

Earlier quoted context omitted.

At least DO supports IPv6, for our application the 40ms latency penalty we encountered for half our customers when on GCP from not supporting IPv6 was not worth it. On that note, HE.net really peers with everyone over IPv6, even ISPs that won't peer with them on IPv4, its quite impressive how much better the routing can be on certain ISPs due to this!

Genuinely curious: how does the lack of IPv6 cause 40ms of latency?

Users on Centurylink Fiber can reach us in 4ms over IPv6 (despite it not being true IPv6) versus 45ms to 60ms with IPv4. DSL is similiar but not quite as notable, more like 30ms of saved latency.

The root issue is Centurylink has no peering with Hurricane Electric on IPv4, and ditto for peering with numerous other providers, versus on IPv6 they have a much more open peering policy. This seems to be common among a number of ISPs, though as time goes on this issue will hopefully ease.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#76

Post by StudentStuff »

pathseeker wrote: post #50
jpdb wrote: post #38

Earlier quoted context omitted.

Genuinely curious: how does the lack of IPv6 cause 40ms of latency?

Tunneling to a v6 provider.

More like the end user gets routed through bespoke connections hundreds of miles away due to ISPs like Centurylink not openly peering on IPv4 at Internet Exchanges, whereas on IPv6 they seem to have local routes to Hurricane Electric and many others on the West Coast, thus no need for traffic to go back east!

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#77

Post by outworlder »

spyspy wrote: post #61
k8sftl wrote: post #53

Earlier quoted context omitted.

CoreOS, PXE, bootkube, kubelet, kubectl. And you say it's not complex? I don't think you and I will ever agree on the meaning of that word.

This thread is extremely refreshing. The number of times I've heard "Kubernetes is sooo simple!!!" here and elsewhere is super frustrating. "You just take your app and put it in a container, then put that container in a pod, which is in a replica set with some other apps in their own containers, which is on a node in a cluster in a datacenter somewhere! Oh and the replica set is amongst a deployment. And if you want…

Isn't this a symptom of a lack of tooling?

Only a few people need to know all the details. We have many developers that know absolutely nothing how this stuff works. They only know that they push code, and a container falls off the other side, which can even be installed automatically.

Also, you don't need sidecars. Add a k8s ingress, or even deploy a separate nginx that will do this for you (we use the second option). Developers do not care.

I'm starting to think that minikube is an anti-pattern.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#78

Post by jacques_chester »

adamm255 wrote: post #62
atombender wrote: post #3

Kubernetes is one of those rare cases where the industry is rallying around a technologically sound platform that emerged from the trenches, and not something that was designed to create jobs for consultants. It's great. Right now, there's a bunch of fairly traditional players such as Red Hat, but none of them are in a position to mess it up. What I'm waiting for, though, is for a big player to do a modern, clean "Ku…

Pivotal and VMware are working on this. From what I’ve seen (yet to play around too deep with this yet) looks promising. You’ve got it spot on though, just needs to be simple. https://pivotal.io/containers/deploying

I work for Pivotal. PKS is our product in the Kubernetes space, co-developed with VMWare and Google. The opensource project we based PKS on is Cloud Foundry Container Runtime, CFCR.

We are basically bringing all the stuff we learned building Cloud Foundry to bear on Kubernetes. There's also an increasing amount of systems being shared. Right now Istio is seen as the long-term north-south and east-west routing solution for Cloud Foundry App Runtime (CFAR, what folks traditionally thought of as Cloud Foundry). We're looking at introducing Loggregator to the Kubernetes world as Oratos, we have factored buildpacks into standalone systems that can have a single image builder for any OCI-compliant platform, we led the formation of the Open Service Broker API effort that creates a common service catalogue approach for both CFAR and Kubernetes, we've contributed to runC and I lose track of all the rest.

When I say "we" I should say this isn't just Pivotal. IBM, SAP and SUSE are deeply involved as Cloud Foundry community members.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#79

Post by drej »

It’s always nice when there is some sort of consensus in the industry, however, there is one thing I worry about.

Now that there is a usable solution for complex orchestration, many newcomers will consider it the goto solution, regardless of scale. You need nginx and some python scripts? Kubernetes! You have 100 daily visitors? Kubernetes!

It’s not really their fault, it’s just a sad consequence of a convenient cloud solution.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#80

Post by jacques_chester »

lobster_johnson wrote: post #9
navaati wrote: post #4

Earlier quoted context omitted.

Well RedHat's OpenShift.com is kinda that, have a look at it !

Maybe. I'm skeptical of Red Hat. The openshift.com web site, which is definitely not geared toward engineers, doesn't give me any confidence that this is what I'm after. Not that Google is better here, but I already know what GCP provides; something that wants to compete with GCP/GKE really needs to explain why they're a viable competitor. (And to people who design these things: If you need to have a "Products" dropd…

I work for Pivotal, we directly compete with Red Hat.

Look: they're Red Hat, I mean c'mon now. If you don't think they have great engineers then I'd hate to hear what you think of the rest of us.

These websites are not usually intended for you or I. They're intended to get the interest of the cheque-signers. Enterprise software is a very particular world and it has its particular cadences and norms and approaches. Red Hat understands it well. So does Pivotal. That's why we see so much of each other at a number of places where folks are looking to adopt modern platforms.

Post reply on HN