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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

The future of Kubernetes is virtual machines

220 点作者 MordodeMaru超过 6 年前

20 条评论

amscanne超过 6 年前
An important element of Kubernetes is that it standardizes the infrastructure control plane, and allows different pieces to be plugged in (for networking, storage, etc.).<p>The &quot;virtual kubelet&quot; essentially throws that all that away and keeps Kubernetes &quot;in API only&quot;. For example, with virtual kubelets, scheduling is meaningless and networking and storage are restricted to whatever the virtual kubelet target supports (if useable at all).<p>Personally, I think the value proposition is tenuous -- you can create VMs today, doing so via the Kubernetes API isn&#x27;t suddenly revolutionary. Just like throwing something in a &quot;hardware virtualized&quot; instance doesn&#x27;t suddenly make the whole system secure.<p>Containers and Kubernetes are compelling for a variety of reasons, improving them to handle multi-tenancy is a broad challenge but I don&#x27;t think the answer is to reduce the standard to what we have today (a bunch of disparate VMs).
评论 #18766374 未加载
评论 #18766993 未加载
评论 #18766280 未加载
评论 #18770298 未加载
mcguire超过 6 年前
As someone who has been a sysadmin and system programmer for 25 years and a crusty rat bastard for almost that long, I have to wonder how long it is going to be until someone realizes that a piece of hardware doing a task is more efficient than 27 layers of virtual machines and a long pair of tongs.
评论 #18768346 未加载
评论 #18767231 未加载
评论 #18767203 未加载
评论 #18769764 未加载
评论 #18769436 未加载
评论 #18768057 未加载
评论 #18767748 未加载
评论 #18767072 未加载
评论 #18767347 未加载
评论 #18767126 未加载
trjordan超过 6 年前
This is, like all good HN articles, technically correct and practically incorrect.<p>It is correct that containers leak, and people know this. Multi-cluster strategies are real, and they shouldn&#x27;t be. It should be OK to have one big cluster[1]. Until Kubernetes fixes this, there will be some friction to adopt it, based on real use cases like untrusted code and noisy neighbors.<p>It is incorrect because users (e.g. non-infrastructure engineers) don&#x27;t know or care about the precise definition of containers and VMs are. The point of &quot;containers&quot; is that I can define something that acts like an operating system from the ground up, and it builds quickly and runs quickly in production.<p>Kubernetes doesn&#x27;t win by forcing users to think about VMs. Kubernetes wins by adopting a VM standard that can be built by Dockerfiles. Infra engineers will love it.<p>But besides them? Nobody will care, because Docker for Mac will look the same.<p>[1] Maybe 1 cluster per region? There&#x27;s a whole fascinating topic that starts with the question &quot;when building a PaaS, do you expose region placement to devs?&quot; The answer implies a ton of stuff about what exactly it&#x27;s reasonable to expect from a PaaS and how much infrastructure your average dev has to know.
评论 #18767719 未加载
评论 #18766807 未加载
评论 #18766825 未加载
评论 #18766746 未加载
jchw超过 6 年前
&quot;virtual machines&quot; may be the wrong word. Containers is probably still the right word. What we probably want, is actually isolated containers.<p>And hell, you can nearly get that today. Combining Docker with gVisor is a potential solution to the soft tenancy problem as far as I can tell, and Kubernetes supports using it.<p>(And gVisor is by no stretch of the imagination a &#x27;VM&#x27; - it is, at best, a tiny hypervisor, and maybe less than that.)
mattbillenstein超过 6 年前
Dammit, most of you reading this do not need any of this shit! Build simple things!
评论 #18768994 未加载
013a超过 6 年前
I really worry about cost in this future of leaning on something like ACI&#x2F;Fargate to actually run the containers.<p>An m5.large instance (2vcpu&#x2F;8gb) costs $70&#x2F;mo on-demand ($44&#x2F;mo with a 1 year reservation). A similar Fargate runtime costs $146&#x2F;mo.<p>A b2ms Azure instance (2vcpu&#x2F;8gb) costs $60&#x2F;mo on-demand ($39&#x2F;mo 1 year reservation). Azure Container Instances at a similar provisioning level costs $176&#x2F;mo by my calculations.<p>That&#x27;s not a small difference. That&#x27;s, like, 3x.<p>Point being, I love virtual-kublet from the perspective of a scale-up just trying to get a product out the door. But for established companies, I still think the core idea of a container on a VM you control is going to rule. Fortunately Kubernetes allows amazingly easy flexibility to switch, and that&#x27;s a reason why it might be the most important technology created in recent history.
评论 #18774046 未加载
orliesaurus超过 6 年前
This feels like an infinite russian doll problem, putting k8s inside a bunch of vms I mean.. but I am glad that while everyone is still trying to learn how to properly do k8s these folks are thinking of the next thing
评论 #18766887 未加载
old-gregg超过 6 年前
Kubernetes has a real chance to succeed where OpenStack failed. Good people at AWS have good reasons to be worried and will push us to a proprietary form of &quot;serverless&quot;.
评论 #18766481 未加载
评论 #18766288 未加载
stevenacreman超过 6 年前
It&#x27;s still containers. On a cloud provider the Kubernetes workers are VM&#x27;s which orchestrate containers. With Kata Containers you&#x27;re just spawning containers inside micro-vm&#x27;s.
评论 #18766444 未加载
评论 #18766103 未加载
state_less超过 6 年前
While the use of namespaces seemed a bit discounted in the article, I think part of the problem is that it&#x27;s an underutilized and poorly conveyed feature, but maybe that&#x27;s just me? I&#x27;d like to see a better out-of-the-box vanilla K8S user management interface in the dashboard. Maybe the default UX on cluster creation is a user&#x2F;service account that isn&#x27;t cluster admin that is limited to 1 or more namespaces. There should be a better dashboard to configure and create users that is front and center when you first create a cluster. You have to work a bit to get something you can use to authenticate as cluster admin like role. This should help direct people towards creating more users and isolated namespaces.
评论 #18768395 未加载
评论 #18767568 未加载
评论 #18767360 未加载
评论 #18767125 未加载
markbnj超过 6 年前
I get the multi-tenancy argument, for certain use cases. I&#x27;m not sure I understand the point about greater resource utilization. Presumably they mean workloads can be scheduled more densely given a set of hardware resources, vs. containers... but I&#x27;d think that containers would score better on that metric than VMs. Can someone expound?<p>The best part of the piece for me was &quot;kubesprawl,&quot; my new favorite word for the week. We&#x27;ve seen it ourselves to some extent, but we are at least aware of it and try to exert some pressure in the other direction. Beyond that I am not particularly bothered by the idea of running lots of clusters for different purposes.
emmelaich超过 6 年前
I&#x27;m picking the eyes out the article here but I had to twitch at this ...<p>&gt; <i>Linux containers were not built to be secure isolated sandboxes (like Solaris Zones or FreeBSD Jails). Instead they’re built upon a shared kernel model ...</i><p>Solaris Zones and BSD Jails both use a shared kernel.<p>And I&#x27;d bet you they were far from perfect in security isolation.<p>Now it may be true that security wasn&#x27;t Linux containers prime reason for being but we have an existence proof that they can be made secure enough -- anyone can get a trial Openshift container for the price of a login.
tybit超过 6 年前
<i>As 2018 comes to a close its time to drag out the hubris and make a bold prediction. The future of Kubernetes is Virtual Machines, not Containers.</i><p>I’d say that’s less of a prediction than a matter of fact since it’s already happened in 2018 for AWS and GCP.<p>This post is kind of irrelevant for consumers imo, in that the future of Kubernetes is still the container interface, regardless of whether your vendor decides to run it in a container or a VM.
评论 #18766042 未加载
elsonrodriguez超过 6 年前
The future of Kubernetes (for some interesting use cases), is virtual machines. For the rest of us the virtual kubelet project represents a bridge between Kubernetes and Serverless.<p>I&#x27;d much rather pay my cloud provider to run my k8s workloads (billed by pod requests&#x2F;limits) than pay for a control plane and three nodes just to run my workloads.
ec109685超过 6 年前
The nested kubernetes idea is interesting (linked to from the post). However, amazon and google aren’t using nested control planes for their infrastructure. Why is a single control plane good for them, but not for a Kubernetes deployment?
Annatar超过 6 年前
And people still wrangle with this... how can it be easier to struggle like this than learn how to use SmartOS and Triton? Kubernetes is a solution to severe OS virtualization deficiency in Linux, most notably orchestration. You, know, the problem which is non-existant in SmartOS with Triton and large scale configuration management with operating system packages. Every so often this hits &quot;Hacker News&quot; and people will rather struggle than master something new. But one cannot polish a turd.
评论 #18775306 未加载
xaduha超过 6 年前
I&#x27;d be fine with that if they were using LKVM (from kvmtool) or that new Firecracker. But as far as I can tell most projects in this area use QEMU still, which is an outstanding piece of software, but doesn&#x27;t scream micro-vm to me.
k__超过 6 年前
I had the impression DevOps ppl would cling to containers as the final form of VMs?<p>But I&#x27;m mostly a high level front-end guy doing back-ends with serverless tech only.
peterwwillis超过 6 年前
I&#x27;m convinced that Kubernetes is very good for job security, and not much else. Unless you&#x27;re a managed services host, you should probably not be running it.<p>Please, for the love of all that is holy, use a cloud services provider if you need K8s-style service features. If you don&#x27;t, then just cobble together your infrastructure in the simplest way possible that uses DevOps principles, methods and practices.
评论 #18768816 未加载
CyanLite4超过 6 年前
TLDR: Kubernetes is an anti-pattern.