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

91–100 of 142 posts

Re: Kubernetes at GitHub

#91

Post by colemickens »

sandGorgon wrote: post #81
brown9-2 wrote: post #60

Earlier quoted context omitted.

What does Swarm do differently here?

swarm is a batteries-included system. you can use it in the way that kubernetes is used... or (if you dont have all these sophisticated load balancers), you can allow it to load balance for you. https://docs.docker.com/engine/swarm/ingress/#publish-a-port... What it means is that when you create a docker swarm - it starts working.

I don't really know much about Swarm. Can you describe how that is different than NodePort with Kubernetes (which is the default for Services)?

Re: Kubernetes at GitHub

#92

Post by xkarga00 »

yebyen wrote: post #32
gtirloni wrote: post #16

Earlier quoted context omitted.

Unfortunately, neither it being open source nor its technical prowess is reason sufficient for some people. That's a simplistic analysis. Most people using Linux don't know it the kernel code "well enough" to maintain it in face of hardware changes and other external requirements. I don't mean anything by "strong suspicions", you do: "I have a strong suspicion that Deis will live on after March under stewardship of n…

OK, fair. It's still worth a look! That was my point. If you compare it to other alternatives and find it to be the best thing, it would be a shame to put it on the shelf instead when there are no alternatives that are as technically strong. If you don't look at it, you have no basis to compare it to the alternatives that you're evaluating. I would rather pick a really good solution than a supported one. If I have to…

> Maybe OpenShift, but it is not "really K8S"

Can you elaborate more? What makes you think that this is true?

Re: Kubernetes at GitHub

#93

Post by pdelgallego »

dookahku wrote: post #66

Any favorted training for learning Kubernetes? I found this one so far: https://classroom.udacity.com/courses/ud615 But any extra courses/trainings is always appreciated

Udemy: https://www.udemy.com/learn-devops-the-complete-kubernetes-c...

Pluralsight: https://www.pluralsight.com/courses/getting-started-kubernet...

Re: Kubernetes at GitHub

#94

Post by atemerev »

iagooar wrote: post #46

Love to see more Kubernetes success stories. I work for an ISP and we are trying to write another success story ;) As an ISP, we have tons of constraints in terms of infrastructure. We're not allowed to use any public cloud services. At the same time, the in-house infrastructure is either too limited, or managed via spreadsheets by a bunch of dysfunctional teams. For my team, Kubernetes has been truly a life saver wh…

From the ops side, I would also suggest to take a look at Mesos, DC/OS and Marathon. Kubernetes, like Docker, is more developer-friendly; DC/OS is more ops-friendly. DC/OS can use Kubernetes natively.

Re: Kubernetes at GitHub

#95

Post by tachion »

philips wrote: post #59
robotmay wrote: post #54

Earlier quoted context omitted.

I'm still utterly perplexed as to what Tectonic actually -is-. I kinda get that it's a kubernetes setup, but is it a GUI over the top of it? The website is pretty confusing and I think I gave up really quickly when trying to set it up.

Tectonic is Enterprise Kubernetes. We start with pure upstream Kubernetes at the core and install it in a production ready setup with the Tectonic Installer[1] across clouds or bare metal. On top of those basics Tectonic provides things most organizations need: - Authentication backed by LDAP/SAML/etc - One-click automated updates of the entire cluster - Pre-configured cluster monitoring/alerting There is a bunch mor…

I'm currently deploying Tectonic flavoured Kubernetes at a large organisation and I can vouch for how great you guys are at supporting users (who are not yet customers) at any stage of the process - love that, and can't recommend you guys for that more. However, as the comment above says, Tectonic (and Quay for that matter) documentation is... just horrible and if not the engineers support, I'd be pretty much stuck on quite few things. Why don't you push your docs to a public repo, so I could do some writing and send some PR's? ;)

Re: Kubernetes at GitHub

#96

Post by gu4x »

skewart wrote: post #53

> Several qualities of Kubernetes stood out from the other platforms we evaluated: the vibrant open source community supporting the project, the first run experience (which allowed us to deploy a small cluster and an application in the first few hours of our initial experiment), and a wealth of information available about the experience that motivated its design. It's interesting that the reasons they cite for choosi…

I believe developer experience on being introduced to a tool is paramount to its success. It gives a lot of confidence in what you're doing and keeps things moving forward. To me appear that the application is built on a solid simple concept instead of a convoluted complex architecture. Some tools sin on the opposite though, very simple to setup but very complicated to understand how to scale.

Re: Kubernetes at GitHub

#97

Post by yebyen »

xkarga00 wrote: post #92
yebyen wrote: post #32

Earlier quoted context omitted.

OK, fair. It's still worth a look! That was my point. If you compare it to other alternatives and find it to be the best thing, it would be a shame to put it on the shelf instead when there are no alternatives that are as technically strong. If you don't look at it, you have no basis to compare it to the alternatives that you're evaluating. I would rather pick a really good solution than a supported one. If I have to…

> 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 rebuilding everything for the better-supported K8S-proper mainline tree, and large parts of our tooling are going to need to be replaced because Kubernetes does not do ImageStream, and OpenShift does not do Helm.

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 also very expensive for an open-source project. Granted you are paying for support and cloud hardware, but I can take Kubernetes and spin it up anywhere. Try installing RedHat OpenShift onto arbitrary releases of CoreOS, Debian, and Amazon Linux like you might be able to do with kubeadm or kops.

That was one of the core promises of Kubernetes, to run anywhere that you can run Docker. My experiences with OpenShift were anything but that. (If I want to run OpenShift Origin, I'll be setting up a latest release of Fedora or RHEL to do it on, I guess.)

I will take Deis for my dev environments at least, because I think the chances that Kubernetes core devs are going to break the APIs in a way that makes it impossible for Deis to be kept alive by a ragtag bunch that figured out how the CI scripts work, pretty much nil. I can take Deis to any cloud provider on any operating system that can do Kubernetes, or onto my own metal (or on Minikube, or on Localkube, or ...)

You get the point by now... Kubernetes brings an ecosystem of options, and OpenShift narrows the scope and range of that ecosystem substantially.

When Deis v1 was EOL'ed, I got into a bit of an argument on HN with Bacongobbler about whether Deis v2 was a different product or not. I argued that it was, because it runs on a different platform now (K8S) and does not support running on the old platform anymore (Fleet).

Technically not true because you can run K8S on Fleet, and Deis v2 on that. But for a sysadmin, it was different, because I knew the rules about making Deis v1 with Fleet "High-Availability" and the rules were all different for Kubernetes, so I argued that it was different.

But for a user, the APIs are all compatible, and they may even bring API integrations such as deisdash.com with them to the "new" platform. (Deisdash is the only API integration for Deis that I am aware of, but when Deis v1 was EOL and Deis v2 was production-ready, you could use Deisdash with either.)

I've now fully eschewed Deis v1 (my old place of employment still has one standing, but it runs such a small amount of infrastructure that I could replace it with a severely less sophisticated setup and nobody would notice until it failed.) I'm on Workflow now, and I have approximately no regrets about it. I can take it anywhere that I can take helm and K8s.

I'll be looking forward to see what the Deis/Azure team bring out in the future that's going to obviate the need for me to be on unsupported EOL Workflow. Because according to Deis team lead @gabrtv, they are still just getting warmed up:

https://twitter.com/gabrtv/status/891096179089342464

Re: Kubernetes at GitHub

#98

Post by dkh99 »

ninkendo wrote: post #64
spmurrayzzz wrote: post #57

Earlier quoted context omitted.

They could easily still use standalone puppet to handle the config management for individual container images. I currently do this with salt-minion. It reduces the burden on the Dockerfile itself, and lets you embrace a declarative configuration state at build time.

It definitely seems like the wrong approach to me to have puppet manage your base images. They're not VM's, they shouldn't have multiple services, they shouldn't require any complex configuration management, they should just be the minimum requirements to support your application's local runtime dependencies, and that's it. From previous experience migrating from a puppet setup to one that used containers, puppet's v…

There's nothing inherently about Puppet that means it has to manage multi-service "whole OS"-like installations. It can just as easily be put to the task of a Dockerfile: install dependencies and deployables for a single application. Its robust ability to manage things like user accounts, packages, scheduled jobs (e.g. for alerting, though you would have to install at least a second service for this: _crond) and the like makes it vastly superior to Dockerfile shell scripts for complex tasks.

Think of puppet more like a way of simplifying your Dockerfiles to have fewer crazy shell commands in total, rather than hiding the craziness in layers and hoping it all composes properly. If you do use lots of layers, Puppet can make your life much easier, since it can be better at detecting previous layers' changes and working around them (think redundant package install commands. Even the no-op "already installed!" command takes time; if you're installing hundreds of packages--many people are, for better or worse--that can eat up build time).

Puppet isn't a VM provisioner; it can also be used as a replacement for large parts of your Dockerfile, or a better autoconf to set up the environment/deps for your application to run in.

Edit: syntax.

Re: Kubernetes at GitHub

#99

Post by yebyen »

yebyen wrote: post #11
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.

You should take a look at Deis Workflow. I say this in spite of the fact that it was announced last week[1], the next release of Deis Workflow will be the last (under the current stewardship, and probably under that name.) It's just such a solid system, I would even more strongly recommend the (already EOL'ed early last year)[2] Deis v1 PaaS, except that you've already indicated you're moving to K8S, and Deis v2 is d…

I'm still waiting for anyone who downvoted to tell me what better alternatives to Deis Workflow exist. I would rather have a better solution than a supported one.

Re: Kubernetes at GitHub

#100

Post by brown9-2 »

sandGorgon wrote: post #81
brown9-2 wrote: post #60

Earlier quoted context omitted.

What does Swarm do differently here?

swarm is a batteries-included system. you can use it in the way that kubernetes is used... or (if you dont have all these sophisticated load balancers), you can allow it to load balance for you. https://docs.docker.com/engine/swarm/ingress/#publish-a-port... What it means is that when you create a docker swarm - it starts working.

Thanks for the link, but this sounds the same as Kubernetes' Service NodePort.
Post reply on HN