You can use it if you’re not “at scale” completely fine and reap all the benefits as if you were.
Idk it’s because people hate Google, so they hate Kubernetes, whether they’re “get off my lawn” DevOps heads who want to maintain their complicated walled garden deployments they hand-rolled to maintain job security or what but it’s frankly embarrassing.
Doing maintenance on the cluster isn't. Debugging routing issues with it isn't either, configuring a production worthy routing to begin with isn't easy either. it's only quick if you deploy weave-net and call it a day.
I would strongly discourage anyone using k8s in production unless it's hosted or you have a full team whose only responsibility is it's maintenance, provisioning and configuration
It should be also known that all "run your code on machines" platforms (like ECS) have similar issues. I remember using ECS pre-fargate and dealing with a lot of hardware issues with the instance types we were on. It was a huge time sink.
> it's only quick if you deploy weave-net and call it a day
That's exactly the benifit of kube. If something is a pain you can walk up to one of the big players and get an off-the-shelf solution that works and spend very little time integrating it into your deployment. No cloudformation stacks or other mess. Just send me some yaml and tell me some annotations to set on my existing deployments.
> I would strongly discourage anyone using k8s in production unless it's hosted or you have a full team whose only responsibility is it's maintenance, provisioning and configuration
If you have compute requirements at the scale where it makes sense for you to manage bare metal it should be pretty easy for you to find budget for 2 to 5 people to manage your fleet across all regions.
Plus disrupting all the developers.
So far every large scale implementation i have seen has cost the developers a year in productivity.
It’s not F500 scale, but it’s over 100 CPU scale. Confident I have a ton of room to scale this.
1. Off the shelf software (even from major vendors [0])
2. Hireable skill set: You can now find engineers who have used kubernetes. You can't find people who've already used your custom shell scripts.
3. Best practices for free: zero-downtime deploys can now be a real thing for you.
4. Build controllers/operators for your business concepts: rather than manually manage things make your software declaratively configured.
[0] - https://cloud.netapp.com/blog/cvo-blg-kubernetes-storage-an-...
Managing a kubernetes cluster has so many possibilities to shoot yourself in the foot without realizing it. There are dozens of tutorials online how to set up a simple linux/nignx/python/postgres cluster (including lots of results for common error google searches) while routing problems of your legacy php application that is behind an istio controlled ingress running on a specific kubernetes version will leave you for yourself.
Sure you won't be able to scale indefinitely. Switching a solid containerized project running on your self-managed machines to a kubernetes setup will be quite easy (if you heeded devops best practices).
The truth is, Kubernetes is awesome, it brings many features to the table. But it also requires ~10% additional very expensive headcount, ~20% more tasks overall, and prolongs the release cycle by ~20%. Figures are from my experience. Those drawbacks are rarely ever discussed - it's just dumped onto existing teams on top of their existing responsibilities, leading to struggle and frustration.
At my job, we went from overly complex Elasticbeanstalk deployments to pushing out new releases via Helm charts into k8s...deployment time vastly improved as did cognative load on what was actually happening.
I'd never go back.
GAE, on the other hand, is dreamy compared to K8s. I once moved some infrastructure to K8s because it was costing too much on GAE; I ended up moving it back because it was worth it. We've subsequently moved it to Digital Ocean's PaaS but that's a different story...
I think you'd find ECS or similar as easy to work with as k8s and all of them will be faster than beanstalk.
Beanstalk is ALWAYS purposefully slow, this is by design. It mimics how amazon deploys internally, slow and steady wins the race to safety. It also has some really bad issue if from from a bad deploy back to a broken app; eg you can wedge it pretty bad.
Anyway at this point I don't think Beanstalk is a fair thing to compare to. It's good you moved off.
I don't think this is some oversight on behalf of the technical writers. They don't lack the ability to explain it in simple terms, they're putting up a warning sign. If you want to join Kubernetes, it's going to mean your entire way of doing things will now be the Kubernetes way, it's not just going to be a few lines of code you add to a Make file.
A lot of people are wary of these heavyweight systems, because it's going to end up a fairly hard dependency.
Unless you are at a scale that you can employ a full-time Kubernetes team, you probably don't need Kubernetes, and if you insist on using it for production anyway, you absolutely should use one of the many managed offerings (DO is probably cheapest, I have no affiliation with them), or shrinkwrapped product like Tanzu.
Bootstrapping from scratch on bare metal remains non-trivial and an in-place upgrade is an order of magnitude harder.
Probably didn't need it, but whatever, it worked and I had to learn something new anyways.
Some corporate customers have bare-metal servers, some OpenStack, some run in AWS, some on VMWare, some on Azure, more exotic options are not rare either.
Kubernetes smooths out the differences, letting you develop an application against a standard, google-able API that is deployable anywhere.
That said, I agree about a higher level PaaS-style offering being a better fit for most companies.
There's also a lot of things they aren't tapping. Just from a security POV alone, a "dependabot for Docker" would probably do a lot for the ecosystem, but hasn't yet happened.
Just like any tool that doesn't offer more than an abstraction layer over OS features, eventually it becomes irrelevant as OS tooling improves.
You'd think. But I think what we're seeing here is the opposite side of the coin flip of that thread that smug idiots like to continually link here where people were saying Dropbox could be implemented in a day using basic Linux tools. Those people in the thread were always correct (I mean, this is "Hacker" news, so people will approach every problem with their hammer... shocking).
Dropbox just happened to get lucky. Docker, not so much. Both have serious competitors, including Google.
> This is a Virtual Vault release of HP-UX, providing enhanced security features. Virtual Vault is a compartmentalised operating system in which each file is assigned a compartment and processes only have access to files in the appropriate compartment and unlike most other UNIX systems the superuser (or root) does not have complete access to the system without following correct procedures.
It's cgroup + chroot, in the closest form.
I took it as a very technically incorrect implication with "I was already doing containers with HP-UX Vaults in version 11 back in 1999." Docker is an development product that removes OS as the core concept from application development process. This is at least a milestone as fundamental as VMware's VM tech.
The commercial failure of Docker container is unfortunate.
But if the technology community cannot appreciate its significance, and let the VM-driven mindset belittle it, that's a true tragedy that puts off the drive to innovate.
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en...
And Tru64, Solaris, BSD also had similar capabilities on the UNIX linage, and naturally IBM and Unisys also had their own versions of the theme on their platforms.
Actually, I believe one text file is the docker killer feature.
It doesn't work bare metal for the new macs, and it is extra bloat instead of making use of macOS capabilities.
Too bad apple didn't help out docker with a macos native version.
FROM macos:10.13.3
RUN xcode-build
This is underscored for me by the fact that their latest end-user (dev) tools aren't even free software any longer. They started off being unixy as hell, doing one thing and doing it well (and being hackable in the process), and now they ship closed-source spyware under the exact same brand.
As someone who loves the feature set of Docker for development but grows increasingly disillusioned with its performance on Mac, would you mind elaborating what these alternatives are?
https://github.com/VMwareFusion/vctl-docs/blob/master/docs/g...
Looks like it supports doing some kubernetes stuff using a `kind` cluster.
I've had pretty good experiences with Fusion, so, yeah, there's some real Docker alternatives up and coming. I think Docker's great, though, and I feel that we'd never have seen a `vctl` on a mac without it's existence.
Also start making pull requests for a Kubernetes killing feature in the Linux kernel - distributed cgroups and ulimits.
It if had a sustainable business model it would be deploying it now.
But they seem to have lost the production environment race to Kubernetes, at least for now. They are the biggest player in the dev-machine market, but more alternatives are popping up making it even harder to monetise. And containerd isn't a part of Docker (Inc) any more.
They do have Docker Hub, and its privileged position as the default registry of all Docker installs. But I don't really see why paying (i.e enterprise) customers would pick Docker Hub over their friendly neighbourhood cloud provider registry where they already have contracts.
Will Docker start rate limiting the public free repos even harder? Maybe making big orgs pay for the privilege of being hosted in the default docker registry? Charging to have the images "verified"?
Anyways, I hope Docker find some viable business model, it would be sad to see them fail commercially after arguably succeeding in changing the (devops) world.