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

Kubernetes at GitHub

githubengineering.com

Post reply on HN
Print view View original

121–130 of 142 posts

Re: Kubernetes at GitHub

#121

Post by deadmik3 »

awill wrote: post #21
deadmik3 wrote: post #7

Earlier quoted context omitted.

I'd recommend looking into openshift. it's basically kubectl + cool deployment features. there's also free, paid, and dedicated online hosted options. disclaimer: I work on openshift

You had a big announcement about openshift.io. Everyone on HN signed up, but it's been months, but I'm still 'awaiting approval' Have you let anyone in? What's the value in all the marketing hype if you then don't let people in.

I can't speak much for OpenShift.io, which is a different product and as another commenter mentioned is just one way to work with OpenShift, with added team-based features on top of OpenShift.

For instant Online hosted access, our Pro tier will immediately allow you to create an account if you sign up today. On our Starter (free) tier we are working hard to provision as many new user accounts as we can (this week we were able to allow in 2,000 new users). Both of these are accessible at openshift.com

And of course, there is the possibility of hosting your own OpenShift cluster for free (the project is open source), which was more my intention of recommending a kubectl wrapper for the above poster.

Re: Kubernetes at GitHub

#122

Post by deadmik3 »

yebyen wrote: post #37
awill wrote: post #21

Earlier quoted context omitted.

You had a big announcement about openshift.io. Everyone on HN signed up, but it's been months, but I'm still 'awaiting approval' Have you let anyone in? What's the value in all the marketing hype if you then don't let people in.

Seconded. The last e-mail I got from OpenShift.io indicated they haven't let anyone in. I've already practically lost interest. It was evidently only "coming soon" but that announcement really looked like "coming tomorrow." The original OpenShift Developer Preview made you sign up, but you would be allowed into the platform within hours or days.

OpenShift.io is a different product than hosted OpenShift on its own. If you were to sign up for the Pro tier at openshift.com your account would be immediately provisioned. We are working on provisioning enqueued users for our Starter tier as well but again, these are separate from OpenShift.io

Re: Kubernetes at GitHub

#123

Post by rleigh »

sweettea wrote: post #90
rleigh wrote: post #36

Earlier quoted context omitted.

My schroot tool used for building Debian packages could panic a kernel in under five minutes reliably, when it was rapidly creating and destroying LVM snapshots in parallel (24 parallel jobs, with lifetimes ranging from seconds to hours, median a minute or so). This was due to udev races in part (it likes to open and poke around with LVs in response to a trigger on creation, which races with deletion if it's very qui…

In my work identity, we saw a similar problem in our testing, where blkid would cause undesired IO on fresh devices. Eventually, we disabled blkid scanning our device mapper devices upon state changes with a file /etc/udev/59-no-scanning-our-devices.rules containing: ENV{DM_NAME}==" ourdevice ", OPTIONS:="nowatch" Alternately, you could call 'udevadm settle' after device creation before doing anything else, which wil…

Yes, we did something similar to disable the triggers. Unfortunately, while this resolved some issues such as being unable to delete LVs which were erroneously in use, it didn't resolve the oopses and kernel freezes which were presumably locking problems or similar inside the kernel.

Re: Kubernetes at GitHub

#125

Post by smarterclayton »

EtienneK wrote: post #84
lima wrote: post #75

Earlier quoted context omitted.

Red Hat's OpenShift makes it a lot easier by providing all of the infrastructure around it (docker registry, docker build from Git, Ansible integration and so on). Best docs of all open source projects I've seen.

I second this. Have been PoCing OpenShift for a couple of months now and it's been a joy to use.

Thanks! Hearing this makes it all worthwhile. We love helping make Kube awesome.

Re: Kubernetes at GitHub

#126

Post by smarterclayton »

dguaraglia wrote: post #15
DDub wrote: post #2

We're currently looking at moving our applications to k8s, and was wondering what deployment tools people are using? This week we are evaluating spinnaker, helm and bash wrappers for kubectl. There is concern over adding too many layers of abstraction and that KISS is the best approach.

I feel you. About a month ago I was fighting with the same feeling. In the end, decided to use Kubernetes only for a single piece of infrastructure so it's all pretty manageable through scripts. Managing secrets in particular is a pain in the ass. One route I started checking but didn't commit to was using Ansible. They have a relatively good Kubernetes playbook and a facility to store secrets. That said, every damn…

Agree - we've been talking about how we can more natively tie the inventory into clusters, contexts, and apps. The host focus of Ansible doesn't always map to other domains, but I think it has a real chance with Kube.

Re: Kubernetes at GitHub

#127

Post by smarterclayton »

yebyen wrote: post #97
xkarga00 wrote: post #92

Earlier quoted context omitted.

> Maybe OpenShift, but it is not "really K8S" Can you elaborate more? What makes you think that this is true?

It has incompatible resource types. They built OpenShift to handle authorization and permissions before Kubernetes RBAC was fully baked. So there are OpenShift solutions that don't exist on K8S, and vice-versa. The BuildConfig and ImageStream for starters. It's not a substantive difference that makes OpenShift much harder to learn, but it is a difference that means "if RedHat decides to 'Deis' OpenShift," we're stuck…

> Maybe the chances of that happening are low, but there are enough differences that from my understanding, I should not ever expect Kubernetes projects to be directly portable to OpenShift without modification (or vice-versa.)

It's true that openshift goes a lot further to disabling things that are dangerous or not ready. Ie preventing root containers, or not enabling third party resources until it went to beta. But everything that runs on Kube runs on openshift that depends on a beta feature or higher.

Re: other OSes - a large part of what we do at Red Hat is making all the other stuff work - Docker, filesystems, selinux, security, NFS, volume drivers, network, etc. A lot of times it's not worth the extra effort to track five distributions of anything, but instead to focus on making something actually work. The behind the scenes work outside of Kubernetes is just as important as the Go code, and so we focus on those few operating systems and making it all work together.

Re: Kubernetes at GitHub

#129

Post by yebyen »

deadmik3 wrote: post #122
yebyen wrote: post #37

Earlier quoted context omitted.

Seconded. The last e-mail I got from OpenShift.io indicated they haven't let anyone in. I've already practically lost interest. It was evidently only "coming soon" but that announcement really looked like "coming tomorrow." The original OpenShift Developer Preview made you sign up, but you would be allowed into the platform within hours or days.

OpenShift.io is a different product than hosted OpenShift on its own. If you were to sign up for the Pro tier at openshift.com your account would be immediately provisioned. We are working on provisioning enqueued users for our Starter tier as well but again, these are separate from OpenShift.io

Yeah, OpenShift Pro is also quite expensive... starting at $10k for 5 nodes right?

I just checked out your pricing page and I'm 100% wrong about this. You have a $50/mo tier now! That's fantastic, thanks for pointing me at that.

You should definitely spam everyone on the OpenShift.io waiting list and let us know about your new pricing /s

No seriously, I would have liked to get some spam about this. Maybe you sent it and I missed it. I am a lot more interested at $50/mo than I would have been at $10k/yr!

Re: Kubernetes at GitHub

#130

Post by yebyen »

smarterclayton wrote: post #127
yebyen wrote: post #97

Earlier quoted context omitted.

It has incompatible resource types. They built OpenShift to handle authorization and permissions before Kubernetes RBAC was fully baked. So there are OpenShift solutions that don't exist on K8S, and vice-versa. The BuildConfig and ImageStream for starters. It's not a substantive difference that makes OpenShift much harder to learn, but it is a difference that means "if RedHat decides to 'Deis' OpenShift," we're stuck…

> Maybe the chances of that happening are low, but there are enough differences that from my understanding, I should not ever expect Kubernetes projects to be directly portable to OpenShift without modification (or vice-versa.) It's true that openshift goes a lot further to disabling things that are dangerous or not ready. Ie preventing root containers, or not enabling third party resources until it went to beta. But…

The fact is, most Kubernetes projects I know are installed by Helm, and (it might have been you, personally who) explained to me that Helm is incompatible with a multitenant environment. I think they've made some strides since RBAC has gotten a little more polished, ... but please correct me if I'm wrong, OpenShift permissions model and RBAC are more compatible than I think.

The last I heard, you just can't really use Helm on OpenShift unless you go to some lengths to lock it down to a single namespace.

It would be amazing if someone could publish a Helm on OpenShift guide! Hmm, it seems you maybe already did: https://github.com/kubernetes/helm/issues/2517

Post reply on HN