TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Flynn.io/Hyper.sh/Nanobox.io vs. Kubernetes

18 点作者 sdomino大约 8 年前
What benefits&#x2F;drawbacks might one of these &quot;pre-packaged&quot; container orchestration tools like Flynn.io, Hyper.sh, or Nanobox.io have verses just rolling your own with something like Kubernetes?<p>Edit: I didn&#x27;t make it as clear as I should have initially that I actually work with Nanobox.io. I&#x27;m legitimately trying to gain an understanding of why developers might find something like Nanobox (or a similar tool) appealing over something like Kubernetes.<p>Apologies for any misdirection initially.

7 条评论

IanCal大约 8 年前
You should be more upfront about your links to companies you talk about. This community is pretty fine with self promotion, but it really needs to be honest.
评论 #13831335 未加载
rubiquity大约 8 年前
Disclaimer: the OP appears to work for one of the companies&#x2F;tools listed, Nanobox.io.
评论 #13831344 未加载
nodesocket大约 8 年前
I am attending Google Cloud NEXT[1] right now, and there are a lot of breakout sessions on kubernetes and Container Engine. Google Cloud and Container Engine (GKE) makes creating a kube cluster super painless. It honestly just works and only takes a few minutes to spin up a kube cluster. GKE also has baked in awesomeness that is not available in the open source version such as automatic master and node version upgrades and automatic repair.<p>I&#x27;d recommend just using GKE instead of trying to run kubernetes on your own or using a lesser platform such as Flynn or Hyper. Google Cloud also has their own container registry which is nice since it is tightly integrated with GKE.<p>[1] - <a href="https:&#x2F;&#x2F;cloudnext.withgoogle.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cloudnext.withgoogle.com&#x2F;</a>
评论 #13832107 未加载
ianwalter大约 8 年前
Typically the pre-packaged tools don&#x27;t give you enough control. They are an abstraction with no lower level to fall back on when you want to do something outside of whatever use case they are trying to solve. Kubernetes is sort of the opposite case. Personally, I think Docker Swarm is the best option at this point. The API is simple in comparison to Kubernetes and works well. One thing that I&#x27;ve found that Kubernetes and Docker Swarm are missing that some pre-packaged options have is a load balancer &#x2F; reverse proxy, but Traefik has grown into a very nice solution. I think pre-packaged solutions to can still add a lot of value by doing things like autoscaling, simplifying blue-green deployments, etc, but I personally find some of the limitations frustrating.
charlieegan3大约 8 年前
I didn&#x27;t really have Flynn and Hyper.sh down as really being comparable. I&#x27;m not sure how Nanobox fits into the picture.<p>I&#x27;ve been pretty impressed with Hyper.sh&#x27;s ease of use and pricing. I didn&#x27;t find Flynn a good match for my use case.<p>I&#x27;ve also found GCE to be pretty good to work with.
评论 #13831534 未加载
danhunsaker大约 8 年前
Primarily, the orchestration tools will do a lot of the work for you, but they&#x27;ll also make a lot of the decisions on how things will work. &quot;Rolling your own&quot; gives more control at the cost of more complexity.
mrmrcoleman大约 8 年前
Hello, I&#x27;m working with Hyper. There are valid comments here about how much control you might want over your container stack. If you need total control, you should run your own k8s cluster or have someone else run it for you, like GKE.<p>Most of our users choose us because they don&#x27;t want that level of control and maintenance.<p>I&#x27;m aware of Flynn but not sure how it works and I&#x27;m hearing of Nanobox for the first time.<p>I imagine however that they will be experiencing the same thing as us, lots of people running event driven workloads.
评论 #13832455 未加载