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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Why is Kubernetes getting so popular?

755 点作者 a7b3fa将近 5 年前

88 条评论

zelly将近 5 年前
Main benefits of Kubernetes:<p>• Lets companies brag about having # many production services at any given time<p>• Company saves money by not having to hire Linux sysadmins<p>• Company saves money by not having to pay for managed cloud products if they don&#x27;t want to<p>• Declarative, version controlled, git-blameable deployments<p>• Treating cloud providers like cattle not pets<p>It&#x27;s going to eat the world (already has?).<p>I was skeptical about Kubernetes but I now understand why it&#x27;s popular. The alternatives are all based on kludgy shell&#x2F;Python scripts or proprietary cloud products.<p>It&#x27;s easy to get frustrated with it because it&#x27;s ridiculously complex and introduces a whole glossary of jargon and a whole new mental model. This isn&#x27;t Linux anymore. This is, for all intents and purposes, a new operating system. But the interface to this OS is a bunch of &lt;strike&gt;punchcards&lt;&#x2F;strike&gt; YAML files that you send off to a black box and hope it works.<p>You&#x27;re using a text editor but it&#x27;s not programming. It&#x27;s only YAML because it&#x27;s not cool to use GUIs for system administration anymore (e.g. Windows Server, cPanel). It feels like configuring a build system or filling out taxes--absolute drudgery that hopefully gets automated one day.<p>The alternative to K8s isn&#x27;t your personal collection of fragile shell scripts. The real alternative is not doing the whole microservices thing and just deploying a single statically linked, optimized C++ server that can serve 10k requests per second from a toaster--but we&#x27;re not ready to have that discussion.
评论 #23359363 未加载
评论 #23359768 未加载
评论 #23362052 未加载
评论 #23359443 未加载
评论 #23359710 未加载
评论 #23360477 未加载
评论 #23360680 未加载
评论 #23363243 未加载
评论 #23359810 未加载
评论 #23360201 未加载
评论 #23363035 未加载
评论 #23360433 未加载
评论 #23359548 未加载
评论 #23359116 未加载
评论 #23359770 未加载
评论 #23360987 未加载
评论 #23359316 未加载
评论 #23362284 未加载
评论 #23359309 未加载
评论 #23362810 未加载
评论 #23359340 未加载
评论 #23359649 未加载
评论 #23360903 未加载
评论 #23361341 未加载
bradgessler将近 5 年前
I’ll take a shot.<p>k8s is popular because Docker solved a real problem and Compose didn’t move fast enough to solve orchestration problem. It’s a second order effect; the important thing is Docker’s popularity.<p>Before Docker there were a lot of different solutions for software developers to package up their web applications to run on a server. Docker kind of solved that problem: ops teams could theoretically take anything and run it on a sever if it was packaged up inside of a Docker image.<p>When you give a mouse a cookie, it asks for a glass of milk.<p>Fast forward a bit and the people using Docker wanted a way to orchestrate several containers across a bunch of different machines. The big appeal of Docker is that everything could be described in a simple text file. k8s tried to continue that trend with a yml file, but it turns out managing dependencies, software defined networking, and how a cluster should behave at various states isn’t true greatest fit for that format.<p>Fast forward even more into a world where everybody thinks they need k8s and simply cargo cult it for a simple Wordpress blog and you’ve got the perfect storm for resenting the complexity of k8s.<p>I do miss the days of ‘cap deploy’ for Rails apps.
评论 #23357969 未加载
评论 #23358173 未加载
评论 #23359651 未加载
评论 #23358292 未加载
评论 #23360720 未加载
评论 #23361771 未加载
评论 #23360885 未加载
评论 #23358526 未加载
silviogutierrez将近 5 年前
For me, and many others: infrastructure as code.<p>Kubernetes is <i>very</i> complex and took a <i>long</i> time to learn properly. And there have been fires among the way. I plan to write extensively on my blog about it.<p>But at the end of the day: having my entire application stack as YAML files, fully reproducible [1] is invaluable. Even cron jobs.<p>Note: I don&#x27;t use micro services, service meshes, or any fancy stuff. Just a plain ol&#x27; Django monolith.<p>Maybe there&#x27;s room for a simpler IAC solution out there. Swarm looked promising then fizzled. But right now the leader is k8s[2] and for that alone it&#x27;s worth it.<p>[1] Combined with Terraform<p>[2] There are other proprietary solutions. But k8s is vendor agnostic. I can and <i>have</i> repointed my entire infrastructure with minimal fuss.
评论 #23355998 未加载
评论 #23355630 未加载
评论 #23355800 未加载
评论 #23355660 未加载
评论 #23357307 未加载
评论 #23354887 未加载
评论 #23354854 未加载
评论 #23355453 未加载
评论 #23354779 未加载
评论 #23356275 未加载
评论 #23356352 未加载
评论 #23354830 未加载
评论 #23355485 未加载
评论 #23355209 未加载
评论 #23355135 未加载
评论 #23364277 未加载
评论 #23354837 未加载
评论 #23355718 未加载
tristor将近 5 年前
The simple answer is that Kubernetes isn&#x27;t really any of the things it&#x27;s been described as. What it &#x2F;is&#x2F;, though, is an operating system for the Cloud. It&#x27;s a set of universal abstraction layers that can sit on top of and work with any IaaS provider and allows you to build and deploy applications using infrastructure-as-code concepts through a standardized and approachable API.<p>Most companies who were late on the Cloud hype cycle (which is quite a lot of F100s) got to see second-hand how using all the nice SaaS&#x2F;PaaS offerings from major cloud providers puts you over a barrel and don&#x27;t have any interest in being the next victim, and it&#x27;s coming at the same time that these very same companies are looking to eliminate expensive commercially licensed proprietary software and revamp their ancient monolithic applications into modern microservices. The culimination of these factors is a major facet of the growth of Kubernetes in the Enterprise.<p>It&#x27;s not just hype, it has a very specific purpose which it serves in these organizations with easily demonstrated ROI, and it works. There &#x2F;are&#x2F; a lot of organizations jumping on the bandwagon and cargo-culting because they don&#x27;t know any better, but there are definitely use cases where Kubernetes shines.
评论 #23356197 未加载
评论 #23357371 未加载
评论 #23356099 未加载
评论 #23355838 未加载
评论 #23358327 未加载
评论 #23355982 未加载
评论 #23357776 未加载
评论 #23357277 未加载
clutchdude将近 5 年前
It&#x27;s not because of the networking stack.<p>I&#x27;ve yet to meet anyone who can easily explain how the CNI, services, ingresses and pod network spaces all work together.<p>Everything is so interlinked and complicated that you need to understand vast swathes of kubernetes before you can attach any sort of complexity to the networking side.<p>I contrast that to it&#x27;s scheduling and resourcing components which are relatively easy to explain and obvious.<p>Even storage is starting to move to overcomplication with CSI.<p>I half jokingly think K8s adoption is driven by consultants and cloud providers hoping to ensure a lock-in with the mechanics of actually deploying workloads on K8s.
评论 #23355645 未加载
评论 #23355232 未加载
评论 #23355093 未加载
评论 #23359404 未加载
评论 #23355267 未加载
评论 #23355870 未加载
评论 #23355288 未加载
acd将近 5 年前
Devops&#x2F;arch here, I think Kubernetes solves deployment in a standardized way and we get fresh clean state with every app deploy. Plus it restarts applications&#x2F;pods that crashes.<p>That said I think Kubernetes may be at its Productivity journey on the tech Hype cycle. Networking in Kubernetes is complicated. This complication and abstraction has a point if you are a company at Google scale. Most shops are not Google scale and do not need that level of scalability. The network abstraction has its price in complexity when doing diagnostics.<p>You could solve networking differently than in Kubernetes with IPv6. There is not a need for complicated IPv4 nat schemes. You could use native ipv6 addresses that are reachable directly from the internet. Since you have so many ipv6 addresses you do not need Routers&#x2F;Nats.<p>Anyhow in a few years time some might be using something simpler like an open source like Heroku. If you could bin pack the services &#x2F; intercommunication on the same nodes there would be speed gains from not having todo network hops going straight to local memory. Or something like a standardized server less open source function runner.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;KISS_principle" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;KISS_principle</a> <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Hype_cycle" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Hype_cycle</a>
评论 #23356486 未加载
评论 #23359640 未加载
Bob_LaBLahh将近 5 年前
Kubernetes is getting more popular because:<p>1) It solves <i>many</i> different universal, infrastructure-level problems. 2) More people are using containers. K8s helps you to manage containers. 3) It&#x27;s vendor agnostic. It&#x27;s easy to relocate a k8s application to a different cluster 5) People see that it&#x27;s growing in popularity. 6) It&#x27;s Open source. 7) It helps famous companies run large-scale systems. 8) People think that it looks good on a resume and they want to work at a well known company. 9) Once you&#x27;ve mastered K8s, it&#x27;s easy to use on problems big and small. (Note, I&#x27;m not talking about installing and administrating the cluster. I&#x27;m talking about being a cluster user.) 10) It&#x27;s controversial which means that people keep talking about it. This gives K8s mind share.<p>I&#x27;m not saying K8s doesn&#x27;t have issues or downsides.<p>1) It&#x27;s a pain to install and manage on your own. 2) It&#x27;s a lot to learn--especially if you don&#x27;t think you&#x27;re gonna use most of it&#x27;s features. 3) While the documentation has improved a lot, it&#x27;s still weak and directionless in places.<p>I think K8s is growing more popular because it&#x27;s pros strongly outweigh it&#x27;s cons.<p>(Note I tried to be unbiased on the subject, but I am a K8s fan--so much so that I wrote a video course on the subject: <a href="https:&#x2F;&#x2F;www.true-kubernetes.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.true-kubernetes.com&#x2F;</a>. So, take my opinions with a grain of salt.)
heipei将近 5 年前
My question is: Why is only k8s so popular when there are better alternatives for a large swath of users? I believe the answer is &quot;Manufactured Hype&quot;. k8s is from a purely architectural standpoint the way to go, even for smaller setups, but the concrete project is still complex enough that it requires dozens of different setup tools and will keep hordes of consultants as well as many hosted solutions from Google&#x2F;AWS&#x2F;etc in business for some time to come, so there&#x27;s a vested interest in continuing to push it. Everyone wins, users get a solid tool (even if it&#x27;s not the best for the job) and cloud providers retain their unique selling point over people setting up their own servers.<p>I still believe 90% of users would be better served by Nomad. And if someone says &quot;developers want to use the most widely used tech&quot;, then I&#x27;m here to call bullshit, because the concepts between workload schedulers and orchestrators like k8s and nomad are easy enough to carry over from one side to the other. Learning either even if you end up using the other one is not a waste of time. Heck, I started out using CoreOS with fleetctl and even that taught me many valuable lessons.
评论 #23355303 未加载
评论 #23355863 未加载
评论 #23357255 未加载
评论 #23355756 未加载
评论 #23356692 未加载
评论 #23355638 未加载
sp332将近 5 年前
I&#x27;d say it&#x27;s down to two things. First is the sheer amount of work they&#x27;re putting into standardization. They just ripped out some pretty deep internal dependencies to create a new storage interface. They have an actual standards body overseen by the Linux Foundation. So I agree with the blog post there.<p>The second reason is also about standards, but using them more assertively. Docker had way more attention and activity until 2016 when Kubernetes published the Container Runtime Interface. By limiting the Docker features they would use, they leveled the playing field between Docker and other runtimes, making Docker much less exciting. Now, new isolation features are implemented down at the runc level and new management features tend to target Kubernetes because it works just as well with any CRI-compliant runtime. Developing for Docker feels like being locked in.
评论 #23355614 未加载
ridruejo将近 5 年前
It makes a bit more sense if you see Kubernetes as the new Linux: a common foundation that the industry agrees on, and that you can build other abstractions on top of. In particular Kubernetes is the Linux Kernel, while we are in the early days of discovering what the &quot;Linux distro&quot; equivalent is, which will make it much more friendly &#x2F; usable to a wider audience
评论 #23356610 未加载
评论 #23355214 未加载
aprdm将近 5 年前
In my humble opinion because there is so much money and marketing behind it. If you go attend the OSS summit all the cloud players are sending evangelizers and having the whole conference to be about Kbuernetes.<p>Then a lot of people drink the koolaid and apply it everywhere &#x2F; feel they&#x27;re behind if they aren&#x27;t in Kubernetes.<p>We <i>are not</i> in Kubernetes and have multiple datacenters with thousands of VMs&#x2F;containers. We are doing just fine with the boring consul&#x2F;systemd&#x2F;ansible set up we have. We also have somethings running in Containers but not much.<p>Funnily enough at the OSS summit I had a couple of chats with people in the big companies (AWS, Netflix, etc.) and they themselves have the majority of their workflows in boring VMs. Just like us.
评论 #23357259 未加载
holografix将近 5 年前
Kubernetes is an almost necessary tech when you operate your own cloud and that’s where it came from: Google.<p>The smart people at Google knew that by quickly packaging their own internal tech and releasing it on open source they’d help people move from the incumbent AWS.<p>Helping customers switch IaaS hurts the both, lock in is better, but it hurts AWS way more. Proof? They made it free to run the necessary compute behind K8s control plane, until recently that was.<p>Are there benefits on running your biz’ web app using constructs made for a “cloud”? Sure there is, that’s why people are moving to K8s. There is real business benefits, given a certain amount of necessary moving parts. LinkedIn had such a headache with this they created Kafka.<p>I suspect most organisations’ Architects and IT peeps push for K8s as a moat for their skills and to beef up their resumé. They know full well that the value is not there for the biz’ but there’s something in it for them.
cutler将近 5 年前
I remember when Docker and K8 emerged and YAGNI kept everything in perspective. Unless you had a fleet of hundreds of servers to manage and spin-up at a moment&#x27;s notice you just used Chef, Puppet or Ansible. Now nothing&#x27;s too small for this ridiculously over-engineered technology. Got a WordPress blog? You&#x27;re doing it wrong if you don&#x27;t put it in a Docker container and launch it with K8. Same with a lot of Rails projects for which Capistrano was more than aadequate. Just gotta scratch that itch until you&#x27;ve no more skin left.
yllus将近 5 年前
To draw anecdotally from my own experiences, its for two reasons:<p>1. It&#x27;s simple to get started with, but complex enough to tweak to your needs in respect to simplicity of deployment, scaling and resource definition.<p>2. It&#x27;s appealingly cloud-agnostic just at the time where multiple cloud providers are all becoming viable and competitive.<p>I think it&#x27;s more #2 and #1; as always, timing is everything.
评论 #23356652 未加载
nasmorn将近 5 年前
I host about a dozen rails apps of different vintage and started switching from Dokku to Digital Ocean Kubernetes. I had a basic app deployed with load balancer and hosted DB in about 6 hours. Services like the nginx ingress are very powerful and it all feels really solid. I never understood Dokku internals either so them being vastly simpler is no help for me. I figured for better or worse kubernetes is here to stay and on DO it is easier than doing anything on AWS really. I have used AWS for about 5 years and have inherited things like terraformed ECS clusters and Beanstalk apps. I know way more about AWS but I feel you need to know so much that unless you only do ops you cannot really keep up.
评论 #23356103 未加载
dustym将近 5 年前
I like to say (lovingly) that Kubernetes takes complex things and simplifies them in complex ways.
评论 #23355858 未加载
评论 #23354859 未加载
closeparen将近 5 年前
What does the Kubernetes configuration format offer over configuration management systems like Ansible, Salt, Puppet, Chef, etc?
评论 #23355225 未加载
评论 #23355389 未加载
评论 #23355083 未加载
评论 #23355294 未加载
评论 #23355350 未加载
评论 #23355860 未加载
评论 #23359701 未加载
评论 #23355066 未加载
评论 #23355155 未加载
评论 #23355603 未加载
nelsonenzo将近 5 年前
as a sys-admin, I like k8s because it solves sys-admin problems in a standardized way. Things like, safe rolling deploys, consolidated logging, liveness and readiness probes, etc. And yes, also because it&#x27;s repeatable. It takes all the boring tasks of my job and let&#x27;s me focus on more meaningful work, like dashboards and monitoring.
评论 #23355416 未加载
mancini0将近 5 年前
Lets use Bazel, and Bazel&#x27;s rules_k8s to build\containerize\test\deploy only the microservices of my monorepo that changed.<p>Lets use Istio&#x27;s &quot;istioctl manifest apply&quot; to deploy a service mesh to my cluster that allows me to pull auth logic &#x2F; service discovery &#x2F; load balancing &#x2F; tracing out of my code and let Istio handle this.<p>Lets configure my app&#x27;s infrastructure (Kafka (Strimzi), Yugabyte&#x2F;Cockroach, etc) as yaml files. Being able to describe my kafka config (foo topic has 3 partitions, etc) in yaml is priceless.<p>Lets move my entire application and its infrastructure to another cloud provider by running a single bazel command.<p>k8s is the common denominator that makes all this possible.
评论 #23355655 未加载
gatvol将近 5 年前
K8s is great - if you are solving infrastructure at a certain scale. That scale being a Bank, Insurance Company or mature digital company. If you&#x27;re not in that class then it&#x27;s largely overkill&#x2F;overcomplex IMO when you can simply use Terraform plus managed Docker host like ECS and attach cloud-native managed services.<p>Again the cross cloud portability is a non starter, unless you&#x27;re really at scale.
评论 #23355343 未加载
评论 #23355528 未加载
评论 #23355257 未加载
hyperbovine将近 5 年前
Because Google made it. Same thing with Tensorflow. And, fun fact, both are massively overhyped and a real PITA to learn and use. But Google uses it, so hey.
评论 #23362452 未加载
jfrankamp将近 5 年前
I&#x27;ll add my use case: we use hosted kubernetes to deploy all of our branches of all of our projects as fully functional application _stacks_, extremely similarly to how they will eventually run in production. Want to try something and show it to someone in the product owner level? Ok there will be a kube nginx-ingress backed environment up in build-time + a few minutes.<p>The environments advertise themselves via that same modified ingress&#x27;s default backend. We stick a tiny bit of deploy yaml in our projects, the deployments kube tagging gives us all the details we need to provide diffs, last build time, links to git repos, web sites etc for the particular environment. The yaml demonstrates conclusively how an app could or should be run, regardless of os or software choice, so when we hand it to ops folks there is a basis for them to run from.
namelosw将近 5 年前
There&#x27;s nothing too novel about Kubernetes, similar patterns could be seen in Erlang many years ago, though in different abstraction levels.<p>However, because enterprise ops prior to Kubernetes are both costly and brittle, Kubernetes just works for enterprises.<p>We had a huge PowerShell codebase and it was a nightmare to maintain. in the meantime, it&#x27;s no way as robust as Kubernetes.<p>It&#x27;s just as simple as that: sure, Kubernetes seems to be complex, but most enterprise stuff are even worse. At the same time, despite they are costly, the quality is usually pretty crappy because those scripts are written under delivery pressure.
cbushko将近 5 年前
You can tell by the volume of comments how interested in the topic the community is.<p>I&#x27;ve noticed that there are a lot of replies such as &quot;it is overhyped&quot; and &quot;I can just run a VM&quot;.<p>Kubernetes is not for you as your use case may not match what it does and solves. Kubernetes provides a standard way of running your applications. It is complex but logical. Yaml sucks but it is simple and logical. I prefer to use terraform for kubernetes but it is the same thing, simple and logical. You cannot say the same with puppet, chef, ansible etc. All of those configuration tools are a big mess of different setups and scripts. I can go to any company and understand how their system works quite quickly. It makes searching for answers easy too because it is standard.<p>When you are running several services and there is an outage, it is a godsend. You can instantly view the status of things, how they are configured and when they changed. That is POWERFUL.<p>It takes a while to understand how all of the resources fit together but that is the same case with any type of deployment system and&#x2F;or operating system.<p>p.s. I am not running that huge of a system, maybe about 5k containers total between dev, staging and prod. Maybe 500k requests a day. Running a couple kubernetes clusters is significantly nicer than running things in ECS.
Fiahil将近 5 年前
TIL about kudo, The Kubernetes Universal Declarative Operator. We&#x27;ve been doing the exact same things in a custom go CLI for 2 years.<p>The kubernetes ecosystem is really amazing and full of invaluable resources. It&#x27;s vast, complex, but well-thought. Getting to know all ins and outs of the project is time consuming. So much things to learn and so little time to practice...
评论 #23356357 未加载
评论 #23355842 未加载
eyberg将近 5 年前
There&#x27;s a silent majority of people that don&#x27;t use k8s (or containers) - hell there is a significant portion of servers that don&#x27;t even use linux. I find the majority of engineers my age (mid 30s) think it is nothing more than straight marketing - between said marketing fueled vc dollars and &quot;every company is a software company&quot; there&#x27;s a very good reason why k8s has taken off but I&#x27;d ask the following:<p>Why should it have?<p>Many people I talk with will complain about security, performance and complexity of k8s (and containers in general). Non-practicing engineers (read: directors&#x2F;vps-eng) will complain about the associated cost with administering their k8s clusters both in terms of cloud cost and devops personnel cost.<p>Someone earlier mentioned it was the new wordpress - I don&#x27;t think that&#x27;s an unfair comparison, although I would challenge the complexity&#x2F;cost of it.
评论 #23361176 未加载
pyrophane将近 5 年前
Honestly, at least with GKE, hosting applications on managed k8s is not that complicated, to the point that I don&#x27;t think it is a poor choice even for small teams who might not need all the bells and whistles of k8s. That is, so long as that small team is already on board with CI and containers.
biggestlou将近 5 年前
Kubernetes got popular because it was the first system that came along that provided a CRUD API for resources of all kinds, including custom resources (CRDs), and was immediately compatible with public artifact hubs like DockerHub and Google Container Registry. The second one is the real kicker here, and I think is why Kubernetes &quot;won&quot; and Mesos et al did not. With Mesos et al you had to set up your own artifact storage. As powerful as Mesos was, there was no MesosHub.<p>Longer term, I think the contribution of Kubernetes will be getting us used to a resource&#x2F;API-driven approach to infrastructure that abstracts away cloud providers, hardware, etc. But it will probably be superseded in the coming years by something that honors similar API &quot;contracts.&quot; Probably written in Rust <i>troll</i>
bvandewalle将近 5 年前
I&#x27;m using Kubernetes extensively in my day to day work and once you get it up and running and learn the different abstraction, it becomes a single API to manage your containers, storage and network ingress needs. Making it easy to take a container and getting it up and running in the cloud with an IP address and a DNS configured in a couple API calls (or defined as YAMLs).<p>That being said, I will also be the first one to recognize that PLENTY of workloads are not made to run on Kubernetes. Sometimes it is way more efficient to spawn an EC2&#x2F;GCE instance and run a single docker container on it. It really depends on your use-case.<p>If I had to run a relatively simple app in prod I would never use Kubernetes to start with. Kubernetes starts to pay itself off once you have a critical mass of services on it.
评论 #23361214 未加载
hinkley将近 5 年前
Kubernetes, I think, exists in the &#x27;hedgehog&#x27; at the middle of the diagram of various drives and fears.<p>There is some tech so simple that you just learn it and start using it, others that you know you can pick up when the time is right.<p>And software you would be happy to invest time in... as long as someone is paying you to do it, software you fear might keep you from getting a job if you don&#x27;t invest in it.<p>There is software so simple it might be right (it isn&#x27;t) and software so complicated that it must be important if people are using it&#x2F;working on it.<p>So it&#x27;s not that Kubernetes is good, it&#x27;s just that it makes people neurotic enough to jump on the bandwagon. Been a few of those in my career. A few have stuck, most have not.
suchitpuri将近 5 年前
Kubernetes is insurance for companies against getting locked in proprietary technologies.<p>It also promotes immutable infrastructure and hence increases the portability. While some of the things like load balancers and ingress are controlled by cloud provider almost everything else can be seamlessly migrated to another cloud provider or on prem.<p>It makes dev, test, staging, prod environments consistent and also solves a lot of pain points of managing infrastructre at scale with autoscaling, auto healing and more. Istio adds a lot more kubernetes and makes the supporting microservices even easier.<p>Its going to be an important piece in Hybrid world as it brings a lot of standardization and consistency in two disparate environments.
justicezyx将近 5 年前
I mean, k8s draws experience from 12+ years of thousands of high caliber engineers. It&#x27;s like deliver modern cars to Chinese market in 1970s time. Of course it will be popular...
INTPenis将近 5 年前
I can only speak for myself as a relatively late adopter, right around early 2020 this year.<p>I only consider that late because I&#x27;ve been reading the hype around k8s for many years already.<p>Became a late adopter of containers just before k8s actually. Now I&#x27;ve migrated most of my setups both privately and professionally to containers. And setup my first k8s clusters both at work and in my homelab.<p>So my perspective is that containers are first and foremost an amazing way of deploying software because all that complexity I did in ansible to deploy the software has been moved to the container image.<p>The project itself now, be it Mastodon, Jitsi, Synapse to name a few, package most of their product for me in automatic build pipelines. All I need to do is run and configure it.<p>And therefore, moving on to k8s, it would stand to reason that some of those services are able to be clustered. Where better to do such clustering than k8s?<p>That&#x27;s just an ops perspective. We also have devs where I work and with k8s they&#x27;re able to deploy anything from routes down to their services using manifests in CD pipelines. What&#x27;s not to like?<p>Only reason one might get disenchanted with k8s is if you expect it to be a one-stop solution for your aging .net application. Not saying you can&#x27;t deploy that in k8s, I&#x27;m just using it as an example of something that might not be microservice ready.
joana035将近 5 年前
Kubernetes is getting popular because it is a no-brainer api to existing things like firewall, virtual ip, process placement, etc.<p>It&#x27;s basically running a big computer without even trying.
seph-reed将近 5 年前
It&#x27;s a developer tool made originally by google. Of course it&#x27;s popular. Which isn&#x27;t to say it&#x27;s bad, it&#x27;s just not much of a question as to why it&#x27;s popular.<p>-------<p>Kubernetes - kubernetes.io<p>Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management. It was originally designed by Google, and is now maintained by the Cloud Native Computing Foundation.<p>Original author(s): Google
dblooman将近 5 年前
If the question was, Why is kube getting so popular with developers, it might get a different response. I wonder how many software developers come to kubernetes through the templated&#x2F;helm chart&#x2F;canned approach made by there DevOps team, not that this isn&#x27;t a fine approach, but I find it a different conversation to say, Serverless, where anyone can just jump in.<p>After spending 18 months working on bringing kubernetes(EKS) to production, with dozens of services on it, the time was right to hand over migrating old services to the software engineers who maintain them. Due to product demands, but also some lack of advocacy, this didn&#x27;t happen, with the DevOps folks ultimately doing the migration and retaining all the kubernetes knowledge.<p>An unpopular opinion might be that Kubernetes is popular because it gives DevOps teams new tech to play with, with long lead times for delivery given its complexity. Kubernetes usually is a gateway to tracing, service meshes and CRDs, which while you don&#x27;t need at all to run Kubernetes, they will probably end up in your cluster.
peterwwillis将近 5 年前
Every person I know who wants to use k8s has never had to maintain it.<p><i>&quot;Developers love it!&quot;</i> Yeah, I&#x27;d love someone to drive my car for me, too. Doesn&#x27;t mean it&#x27;s a great idea to use technology so complex you have to hire a driver (really several drivers) to use it.<p>If you already have 3 people working for you that (for example) understand etcd&#x27;s protocols or how to troubleshoot ingress issues or how to prevent (and later fix) crash loops, maybe they can volunteer to babysit your cluster for you, do all the custom integration into the custom APIs, keep it secure, etc. But eventually they may get tired of it and you&#x27;ll have to hire SMEs.<p>If you&#x27;re self-hosting a &quot;small&quot; k8s cluster and didn&#x27;t budget at least $500k for it, you&#x27;re making a mistake. There are far simpler solutions to just <i>running a microservice</i> that don&#x27;t require lots of training and constant maintenance.<p>Complexity isn&#x27;t always bad, but unnecessary complexity always is.
kureikain将近 5 年前
Before K8S, to run a service you need:<p>- Setup VM: and their dependencies, tool chain. If you use thing like package that has native component such as image processing you event need to setup some compiler on the VM - Deployment process - Load balancer - Systemd unit to auto restart it. Set memory limit etc.<p>All of that is done in K8S. As long as you ship a Dockerfile, you&#x27;re done.
评论 #23356933 未加载
评论 #23357795 未加载
jariel将近 5 年前
How big does your company get before you need to step away from a tiny handful of very large EC2s?<p>If you have 16CPU EC2 for your business logic, one for your DB, and you&#x27;re smartly hosting your static content elsewhere or via Cloudflare ... I mean you need to have a &#x27;big company&#x27; before going too far beyond that.<p>What gives? What are all these startups doing?<p>This is not a story about K8&#x27;s, this is entirely something else, it&#x27;s about psychology, complexity, our love of it, or rather our &#x27;belief&#x27; that complexity = productivity that solving &#x27;the hard infra problem&#x27; must inherently, be somehow be &#x27;good for the company&#x27; because it &#x27;feels difficult&#x27; and therefore must be doing something powerful or at least gaining some kind of competitive advantage?<p>(Aside from the &#x27;Docker is Useful and K8&#x27;s follows&#x27; point which actually makes sense a little bit ...)
lkrubner将近 5 年前
I&#x27;ve tried to make the argument that Kubernetes introduces a level of complexity that should make everyone think twice before diving into that eco-system. I&#x27;ve tried to make this argument using both detailed, factual arguments, and also by using humor and parody. I am confused why Kubernetes has so much momentum, especially when you consider that most of the things we want (isolation, security, dependency management, flexible network topologies) can be gained much more simply with Terraform and Packer. With a mix of humor and detailed factual analysis, my most recent attempt to make this argument is here:<p><a href="http:&#x2F;&#x2F;www.smashcompany.com&#x2F;technology&#x2F;my-final-post-regarding-the-flaws-of-docker-kubernetes-and-their-eco-system" rel="nofollow">http:&#x2F;&#x2F;www.smashcompany.com&#x2F;technology&#x2F;my-final-post-regardi...</a>
gofreddygo将近 5 年前
- Its free<p>- Most code running on k8s hasn&#x27;t hit full production load yet.<p>- Where it has worked well, its been managed by devs that know what they are doing.<p>- It something worth putting on a backed dev resume<p>- Apparent cost saving (&#x27;we just need 1 vm instead of 5&#x27;, &#x27;we can auto scale to infinity&#x27;,&#x27;we don&#x27;t have yo pay for aws, we get it all on our own vms&#x27;).<p>Wait a few months and we will see a slurry of posts that read &#x27;why we moved away from kubernetes&#x27;, &#x27;top 5 reasons to not use kubernetes&#x27;, &#x27;How using kubernetes fucked us, in the ass&#x27;, &#x27;You dont need kubernetes&#x27;, &#x27;Why I will never work on a project that uses kubernetes&#x27;, &#x27;Hidden costs of kubernetes&#x27; and so on.<p>C&#x27;mmon, you know how this works. Just take the time and read the docs. They are well written (They just don&#x27;t mention where k8s does not work well)
评论 #23474403 未加载
StreamBright将近 5 年前
Because developers are lazy.<p>I dont want do memory management-&gt; gc<p>I dont want to do packaging -&gt; Docker<p>I dont want to do autoscaling -&gt; Kubernetes
mmcnl将近 5 年前
Kubernetes is great, but also very complex and almost an entire new paradigma to learn and understand. I feel like there&#x27;s a huge void between no Kubernetes and Kubernetes that isn&#x27;t being filled yet. Dealing with and&#x2F;or managing Kubernetes is a task on its own, I have the feeling that container orchestration doesn&#x27;t have to be that complex.<p>Something like an easy to use (and operate!) multi-tenant docker-compose on steroids with user management&#x2F;RBAC and a built-in Docker image repository that gets out of your way would be amazing for small teams &#x2F; startups that don&#x27;t want to deal with the complexity of Kubernetes.
bg24将近 5 年前
- There are big names behind it. - It will replace VM orchestration platforms. - Fear of missing out.<p>Jokes aside, when you&#x27;ve lots of teams, all working on small pieces of a large product and shipping on their own, iterating fast... you need a platform and ecosystem on top to meet their requirements. As you reach planet-scale, you need to NOT let your cost grow exponentially. Hence it is popular.<p>What if you&#x27;re not planet-scale? Well, it will still help (attract talent, design for scale, better ecosystem etc.). Hence it is popular.<p>If you&#x27;re building a business however, focus on business and time-to-market, definitely not the infra, i.e. kubernetes.
wadkar将近 5 年前
I think kubernetes is to Infra what RoR was to Web. Not necessarily in terms of architectural style of MVC, but more towards standardization of similar enough problems that can be put into a mutually agreed convention.
评论 #23361224 未加载
znpy将近 5 年前
in my opinion it kinda sets a common lingo between development people and operations people.<p>operations details are hidden from developers and development details (the details of the workload) are hidden from the operations engineers.
iudqnolq将近 5 年前
I&#x27;ve been completely perplexed by how I might repeatably and reliably setup a single DigitalOcean (or similar) server.<p>I can&#x27;t just blow away the instance, make a new one with their API, and run a bash script to set it up because I need to persist some sqlite databases between deploys.<p>Nix looks promising, but also seems to be a lot to learn. I think I&#x27;d rather focus on my app than learn a whole new language and ecosystem and way of thinking about dependencies.<p>I don&#x27;t think my needs are insane here, I&#x27;m surprised there seems to be no infrastructure as code project for tiny infrastructures.
评论 #23365249 未加载
javajosh将近 5 年前
Easy: the perception of infinite overhead. The cloud itself (e.g. EC2) gives you capacity-on-demand, but the glue to make all the nodes work together is missing. And its a really hard problem, in general, because its distributed systems. K8s fills that demand, or seeks to. The alternative is to roll-your-own, which is possible but expensive, error-prone, and difficult to hire for. (My last company discovered this to their detriment after sinking a LOT of time into building out a really complex Salt+Vagrant+AWS solution, and then decided to migrate to k8s).
hootbootscoot将近 5 年前
Beats me. It doesn&#x27;t correspond to either virtual server nor hypervisors. It certainly doesn&#x27;t correspond to real hardware. Cloud OS my butt... &quot;Hey, let&#x27;s take a zillion commodity cloud provider instances running on hypervisors, then install Ubuntu, then run Kubernetes on them, then run docker containers on them and fiddle about all day with yaml trying to make internal networking do insecure things to imitate real world infrastructure&quot;<p>Just use Ansible if you miss YAML, and you can actually deploy to real hardware.
arein2将近 5 年前
It has most of the features needed.<p>Everyone was trying to make a system simple and adopted, but if you want it to be adopted, it&#x27;s going to need a lot of features. Also Google worked some real magic in getting Kubernetes being supported by all the cloud providers.<p>It&#x27;s a framework that will enable you to do what you want, while being the standard.<p>You could write your script to do that in a simpler way, but most people already know the standard and it&#x27;s easier for everybody to understand Kubernetes rather than your clever solution.
devin将近 5 年前
I&#x27;ve seen people extolling the many benefits of Kubernetes. For those who are all in, how does something like CDK compare?
gabordemooij将近 5 年前
I served millions of users with single low end server. Kubernetes is just a sign that people can&#x27;t code anymore.
CuriousSkeptic将近 5 年前
As a follow up question. I’ve been running on Azure Service Fabric for a little over three years now and been quite happy with it so far.<p>But it doesn’t seem like it generates quite the same buzz as kunernetes. Not even within the azure&#x2F;win&#x2F;.net part of the world.<p>So have anyone here worked with both and could share some experience?
shp0ngle将近 5 年前
I learned to like kubes, but... <i>why on earth is it YAML</i> :(<p>yaml is such a horrible format that I would even prefer JSON...
clvx将近 5 年前
In a side note if you were to invest your time in writing operators, would you use kubebuilder or operator-sdk?
评论 #23355144 未加载
评论 #23361241 未加载
lyjackal将近 5 年前
I think kubernetes is great conceptually if you&#x27;re running on the cloud, but it&#x27;s a very complicated domain, and has a lot ecosystem churn. Things break a lot if you&#x27;re not careful. Upgrading dependencies is a constant pain. Certainly a time such
andbot将近 5 年前
This article adds nothing to common knowledge everyone with a bachelors degree in computer science is completely aware of. Can anyone tell me what I missed? Or where is the reason why this post is trending among people whose background I cannot grasp?
pea将近 5 年前
Do you guys think k8s is doing a job which previously the jvm did in enterprise? i.e. if everything is on the jvm, building distributed systems doesn&#x27;t require a network of containers.<p>Can k8s success be explained partly due to the need for a more polyglot stack?
评论 #23356222 未加载
评论 #23356672 未加载
alexbanks将近 5 年前
I thought it was pretty insane yesterday when I read a YC-backed recruiting company was using Kubernetes. Absolutely insane. It&#x27;s become the new, hottest, techiest thing that every company has to have even when they don&#x27;t need it.
评论 #23356567 未加载
评论 #23356184 未加载
LoSboccacc将近 5 年前
the main thing I like about them: configuration. it&#x27;s trivial to split integration configuration from applicative configuration from deployment configuration, it&#x27;s trivial to version configurations,<p>it&#x27;s not unique in what it does, but even with puppet and the likes you always had this or that exception because networking, provider images varying selinux defaults etc.<p>kuberent on it&#x27;s own already covered most ground, but configmap and endpoints really tie it together in a super convenient package<p>it&#x27;s not without pitfalls, like ms aks steal 2gb from each node so you have to be aware of that and plan accordingly, but still.
评论 #23359590 未加载
kgraves将近 5 年前
As a manager i&#x27;ve heard in all my meetings about &#x27;kubernetes&#x27;, had a look at it and have always been questioning the cost to manage this.<p>What is the cheapest way to setup a production kubernetes on a cloud provider?
评论 #23356177 未加载
评论 #23356337 未加载
评论 #23355802 未加载
Jestar342将近 5 年前
One thing I&#x27;ve discovered when hiring people is if I&#x27;m not using things like kubernetes, I don&#x27;t get (as many) candidates apply. I also don&#x27;t get as good quality candidates, either.
ashtonkem将近 5 年前
My opinion is that Kubernetes is the common integration point. Tons of stuff works with Kubernetes without having to know about each other, making deployments much much easier.
holidayacct将近 5 年前
Because Google is an advertising company, their search engine controls what people believe in and they also have some good engineers but they are probably not well known. There is very little they couldn&#x27;t advertise into popularity. Whenever you see overcomplicated software or infrastructure its always a way to waste executive function, create frustration and create unnecessary mental overhead. If the technology you&#x27;re using isn&#x27;t making it easier for you to run your infrastructure from memory, reduce the use of executive function and decrease frustration then you should ignore it. Don&#x27;t fall for the fashion trends.
评论 #23356176 未加载
nova22033将近 5 年前
This is the wrong question. The question should be why are containers so popular? If you&#x27;re going to use containers, kubernetes makes it easier to do so.
kerng将近 5 年前
Not a microservices guru, but why are big companies (most famously Uber, who was sort of spearheading it famously) starting to abandon this architecture?
pjmlp将近 5 年前
Somehow k8s capabilities look like a description of WebSphere feature list, just done with cooler technology for younger generations.
tamrix将近 5 年前
Some developers just refuse to admit they&#x27;re are trends in development.<p>Kubernetes is popular because it&#x27;s the new &#x27;cool&#x27;.
semasad将近 5 年前
I love to read when some tech we are using @ Nursoft.co about 1+ year is &quot;getting&quot; popular, it&#x27;s feels good.
gabordemooij将近 5 年前
Kubernetes is popular because developers want names on their CVS. A couple of shell scripts will get you anywhere.
hinkley将近 5 年前
Am I the only one who noticed that &#x27;Innovation&#x27; was by far the shortest section of that article?
shakil将近 5 年前
Call me biased [1] but K8s will take over the world! Yes you get containers and micro-services and all that good stuff, but now with Anthos [2] its also the best way to achieve multi-cloud and hybrid architectures. What&#x27;s not to like!<p>1. I work for GCP 2. <a href="https:&#x2F;&#x2F;cloud.google.com&#x2F;anthos&#x2F;gke" rel="nofollow">https:&#x2F;&#x2F;cloud.google.com&#x2F;anthos&#x2F;gke</a>
评论 #23355704 未加载
yalogin将近 5 年前
Google created it but did they get any benefit from it? Did it help in getting any business for GCP?
评论 #23357374 未加载
AzzieElbab将近 5 年前
Because the demos are awesome and there is a lot of money to be made in getting it beyond demos
JackRabbitSlim将近 5 年前
I get the feeling K8 is the modern PHP. Software that&#x27;s easy to pick up and use without complete understanding and get something usable. Even if its not efficient and results in lots of technical debt.<p>And like PHP, it will be criticised with the power of hind sight but will continue to be used and power vast swaths of the internet.
评论 #23355871 未加载
评论 #23355868 未加载
claytongulick将近 5 年前
I completely understand the use case for Kubernetes when you&#x27;re dealing with languages that require a lot of environment config, like Python.<p>I&#x27;ve never really thought it was that useful for (for example) nodejs, where you can just npm install your whole environment and deps, and off you go.
评论 #23356258 未加载
thisisnotmy将近 5 年前
Because it’s basically turning things off and on. At scale.
kakoni将近 5 年前
So anybody doing k8s onprem? How is it going&#x2F;working?
maxdo将近 5 年前
if you&#x27;re on microservices, it&#x27;s no brainer. You&#x27;ll need an army of DevOps with semi-custom scripts to maintain the same. It&#x27;s really automating a lot of stuff. Helm + Kubernetes let our company&#x27;s ability to launch microservices with no DevOps involved. You just provide the name of the project, push to git and GitLab CI will pick it up and do the stuff by the template. Even junior developers in our team are doing that from day one. Isn&#x27;t that a future we dream about? If you have too much load it will autoscale pod, if node is overloaded it will autoscale node pool, if you have a memory leak it will restart the app so you can sleep at night. I can provide a million examples that make our 100+ microservices management so much simpler. No Linux kungfu, 0 bash scrips, no SSH, and interaction with OS, not a single devops role for 15+ developers team.<p>Our management of cluster is just a simple &quot;add more CPU or memory to this nodepool&quot;, sometimes change a nodepool name for deployment for certain service. All done simple cloud management UI. For those who call microservices fancy stuff. No, we are a startup with fast delivery, deploy cycle. We have tons of subproject , integrations, and our main languages are nodejs, golang and python. Some of these are not good at multi-thread so no way to run it as a monolith. The other one is used only when it&#x27;s needed for high performance. So All together Microservices + Kubernetes + Helm + good CI + proper pubsub gives our backend extremely simple fast cycle of development, delivery, and what&#x27;s important flexibility in terms of language&#x2F;framework&#x2F;version.<p>What is also good is the installation of services. With helm I can install high availability redis setup for free in 5 minutes. The same level of setup will cost you several thousand dollars for devops work and further maintenance and update. With k8s it&#x27;s simple helm install stable&#x2F;redis-ha<p>So yeah, I can totally understand some simple projects don&#x27;t need k8s. I can understand you can build something is Scala and Java slowly but with high quality as a monolith. You don&#x27;t need k8s for 3 services. I can understand some old DevOps don&#x27;t want to learn new things and they complain about a tool that reduces the need of these guys. Otherwise, you really need k8s.
评论 #23355370 未加载
fmakunbound将近 5 年前
It gets more popular mostly because it&#x27;s popular.
alec_kendall将近 5 年前
This seems appropriate... <a href="https:&#x2F;&#x2F;microservices.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;microservices.io&#x2F;</a>
jonahbenton将近 5 年前
Obligatory- the best introduction to Kubernetes, from conceptual perspective, is Google&#x27;s incredible Borg paper:<p><a href="https:&#x2F;&#x2F;static.googleusercontent.com&#x2F;media&#x2F;research.google.com&#x2F;en&#x2F;&#x2F;pubs&#x2F;archive&#x2F;43438.pdf" rel="nofollow">https:&#x2F;&#x2F;static.googleusercontent.com&#x2F;media&#x2F;research.google.c...</a>
PanosJee将近 5 年前
Religion
zelphirkalt将近 5 年前
In this post it might only be an example, but I don&#x27;t see anything, that necessitates the use of YAML. All of that could be put in a JSON file, which is far less complex.<p>YAML should not even be needed for Kubernetes. Configuration should be representable in a purely declarative way, instead of making the YAML mess, with all kinds of references and stuff. Perhaps the configuration specification needs to be re-worked. Many projects using YAML feel to me like a configuration trash can, where you just add more and more stuff, which you haven&#x27;t thought about.<p>I once tried moving an already containerized system to Kubernetes for testing, how that would work. It was a nightmare. It was a few years ago, maybe 3 years ago. Documentation was plenty but really sucked. I could not find _any_ documentation of what can be put into that YAML configuration file, what the structure really is. I read tens of pages of documentation, none of it helped me to find, what I needed. Then even to set everything up, to get the Kubernetes running at all also took way too much time and 3 people to figure out and was badly documented. It took multiple hours on at least 2 days. Necessary steps, I still remember, not being listed on one single page in any kind of overview, but somewhere a required step was hidden on another documentation page, that was not even mentioned in the list of steps to take.<p>Finally having set things up, I had a web interface in front of me, where I was supposed to be able to configure pods or something. Only, that I could not configure everything I had in my already containerized system, via that web interface. It seems that this web interface was only meant for the most basic use cases, where one does not need to provide containers with much configuration. My only remaining option was to upload a YAML file, which was undocumented, as far as I could see back then. That&#x27;s were I stopped. A horrible experience and I wish not to have it again.<p>There were also naming issues. There was something called &quot;Helm&quot;. To me that sounds like an Emacs package. But OK I guess we have these naming issues everywhere in software development. Still bugs me though, as it feels like Google pushes down its naming of things into many people&#x27;s minds and sooner or later, most people will associate Google things with names, which have previously meant different things.<p>There were 1 or 2 layers of abstraction in Kubernetes, which I found completely useless for my use-case and wished they were not there, but of course I had to deal with them, as the system is not flexible to allow me to only have layers I need. I just wanted to run my containers on multiple machines, balancing the load and automatically restarting on crashes, you know, all the nice things Erlang offers already for ages.<p>I feel like Kubernetes is the Erlang ecosystem for the poor or uneducated, who&#x27;ve never heard of other ways, with features poorly copied.<p>If I really needed to bring a system to multiple servers and scale and load balance, I&#x27;d rather look into something like Nomad. Seems much simpler and also offers load balancing over multiple machines and can run docker containers and normal applications as well, plus I was able to set it up in less than an hour or so, having to servers in the system.
评论 #23357114 未加载
courtf将近 5 年前
I honestly couldn&#x27;t tell you.<p>What I can tell you, is that the unbelievable bloat in the complexity of our systems is going to bite us in the ass. I&#x27;ll never forget when I joined a hip fintech company, and the director of eng told us in orientation that we should think of their cloud of services as a thousand points of light, out in space. I knew my days were numbered at exactly that moment. This company had 200k unique users, and they were spending a million dollars a month on CRUD. Granted, banking is its own beast, but I had just come from a company of 10 people serving 3 million <i>daily</i> users 10k requests a second for images drawn on the fly by GPUs. Our hosting costs never exceeded 20k per month, and the vast majority of that was cloudflare.<p>Deploying meant compiling a static binary and copying it to the 4-6 hardware servers we ran in a couple racks, one rack on each side of the continent. We were drunk by 11am most of the time.<p>Today, it&#x27;s apparently much more impressive if you need to have a team of earnest, bright-eyed Stanford grads constantly tweaking and fiddling with 100 knobs in order to keep systems running. Enter kubernetes.
评论 #23357705 未加载
评论 #23357526 未加载
评论 #23358470 未加载
评论 #23358134 未加载
评论 #23357965 未加载
评论 #23358384 未加载
评论 #23357624 未加载
评论 #23357472 未加载
评论 #23357711 未加载
评论 #23358274 未加载
评论 #23357871 未加载
评论 #23357509 未加载
hardwaresofton将近 5 年前
tl;dr - Kubernetes is a good tool, but it has been marketed and evangelized to where it is today, it&#x27;s meteoric rise is not organic.<p>I am a huge Kubernetes fan, and think that it is a good and necessary tool with little accidental complexity (most concepts are there because you will likely need them and&#x2F;or that they are a valid concern), but my position is that the growth of Kubernetes has <i>not</i> been organic -- it&#x27;s been heavily promoted and marketed and pushed to where it is today.<p>Let&#x27;s compare a project like Ansible first release in 2012[0], and the first AnsibleFest is in 2016[0]. Ansible is a very useful abstraction&#x2F;force multiplier for doing ops. If a dedicated conference is a measure of community&#x2F;enthusiasm reaching a fever pitch, it took 4 years for Ansible to reach critical mass. Kubernetes had it&#x27;s first Kubecon in 2015[1] ONE year after it&#x27;s initial release in 2014[2]. Did it reach critical mass 4x quicker than ansible? Maybe, but I think the simpler explanation is that the people who want Kubernetes to succeed know that creating buzz and the <i>appearance</i> of widespread adoption and community is more important than it actually being there, as it becomes a self-fulfilling prophecy. Once you have enough onlookers, people motivated to work on open source (i.e. give away labor, time and energy for free) will come improve your project with you, serve as an initial user base, your biggest promoters, all the while strengthening your ecosystem.<p>Another interesting side to this is how thoroughly Kubernetes <i>seems</i> to be crushing it&#x27;s competition -- DC&#x2F;OS (Mesos), Nomad and other competition are not fighting a functionality war, they&#x27;re fighting a marketing war. DC&#x2F;OS and Nomad are not obviously worse in function, but certainly don&#x27;t compare when you consider ecosystem size (perceived, if not actual) and brand. It&#x27;s a winner-take-most scenario and tech companies are particularly good at seizing this kind of opportunity. Of course, if you compare the resources of the entities backing these projects, it&#x27;s clear who was going to win the marketing war.<p>In a world of free tiers as a good way to get people locked in, developer evangelists who build essentially propaganda projects (no matter how cool they are), and shrinking attention spans, Kubernetes is a good tool which has marketed itself to greatness. In it&#x27;s wake there are efforts like the CNCF which I struggle to characterize because it&#x27;s hard to differentiate their efforts to standardize from an effort to bureaucratize. I&#x27;m almost certainly blinded by my own cynicism but most of this just doesn&#x27;t feel organic. Big, useful open source software gets world-renowned after years&#x2F;decades of being convenient&#x2F;useful&#x2F;correct&#x2F;etc but Kubernetes (and other projects given the CNCF gold star) seem to be trying to skip this process or at least bootstrap a reputation out of the gate.<p>DevOps traditionally moved much slower -- I can remember what seemed like an age of &quot;salt vs ansible vs chef&quot;, with all three technologies having had lots of times to prove themselves useful. Even the switch to containers instead of VM&#x2F;user based process isolation took more time than Kubernetes has taken to dominate the zeitgeist.<p>[0]: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ansible_(software)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ansible_(software)</a><p>[1]: <a href="http:&#x2F;&#x2F;www.voxuspr.com&#x2F;2019&#x2F;03&#x2F;what-is-kubecon-its-past-present-and-future" rel="nofollow">http:&#x2F;&#x2F;www.voxuspr.com&#x2F;2019&#x2F;03&#x2F;what-is-kubecon-its-past-pres...</a><p>[2]: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Kubernetes" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Kubernetes</a>
foobar_将近 5 年前
The arguments used to consistently market software<p>1. It&#x27;s portable<p>2. It&#x27;s fast<p>3. It&#x27;s declarative<p>4. It&#x27;s fun &#x2F; productive &#x2F; easy<p>5. It&#x27;s safe &#x2F; automatic<p>6. It&#x27;s an integrated framework<p>The opposites are also used to detract competitors.<p>The idea of k8 is that it will be portable to all hosting providers and linux distributions as opposed to developing shell scripts for Red Hat, especially multiple versions. I don&#x27;t think it&#x27;s easy or fun or fast.
battery_cowboy将近 5 年前
Because everyone chases the newest, shiniest thing in tech, and it&#x27;s not cool nor fun to make boring old stuff in C then copy one binary and maybe a config to the server.
评论 #23355064 未加载
评论 #23355382 未加载