101–110 of 681 posts
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's not to like! 1. I work for GCP 2. https://cloud.google.com/anthos/gke
What is the cheapest way to setup a production kubernetes on a cloud provider?
For me, and many others: infrastructure as code. Kubernetes is very complex and took a long time to learn properly. And there have been fires among the way. I plan to write extensively on my blog about it. But at the end of the day: having my entire application stack as YAML files, fully reproducible [1] is invaluable. Even cron jobs. Note: I don't use micro services, service meshes, or any fancy stuff. Just a plain…
Can k8s success be explained partly due to the need for a more polyglot stack?
I'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.
For me, and many others: infrastructure as code. Kubernetes is very complex and took a long time to learn properly. And there have been fires among the way. I plan to write extensively on my blog about it. But at the end of the day: having my entire application stack as YAML files, fully reproducible [1] is invaluable. Even cron jobs. Note: I don't use micro services, service meshes, or any fancy stuff. Just a plain…
There's an offshoot of this that I see from developers, especially at old, stodgy companies. Once everything is "infrastructure as code", the app team becomes less dependent on other teams in the org. People like to own their own destiny. Of course, that also removes a lot of potential scapegoats, so you now mostly own all outages, tech debt, etc.
I worked in networking for the longest time. When I started there network guys and server guys (at least where I was). They were different people who did different things who kinda worked together.
Then there were storage area networks and similar, networks really FOR the server and storage guys.... that kind of extended the server world over some of the network.
Then comes VMware and such things and now there was a network in a box somewhere that was entirely the server guy's deal (well except when we had to help them... always).
Then we also had load balances who in their own way were a sort of code for networks ... depending on how you looked at it (open ticket #11111 of 'please stop hard coding ip addresses').
You also had a lot of software defined networking type things and so forth brewing up in dozens of different ways.
Granted these descriptions are not exact, there were ebs and flows and some tech that sort of did this (or tired) all along. It all starts to evolve slowly into one entity.
Earlier quoted context omitted.
I've only ever used cfengine and Ansible, but they are both declarative. Hell, Ansible uses yaml files too. I would be somewhat surprised to find out Puppet and Chef weren't declarative either. Because setting up a system in an imperative fashion is ripe for trouble. You may as well use bash scripts at that point. I've used Ansible for close to 10 years for hobby projects. And setting up my development environment. G…
Check out nix for actual development environments. Huge fan of that as well. I can buy a new laptop and be back to 100% in a few minutes. Though the amount of time I spent learning how to get there far exceeds any time savings. Ever.
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 "Manufactured Hype". 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/AWS/…
Earlier quoted context omitted.
Ansible is YAML, but it's definitely imperative YAML - each YAML file is a list of steps to execute. It uses YAML kind of like how Lisp uses S-expressions, as a nice data structure for people to write code in, but it's still code. Sure, the steps are things like "if X hasn't been done yet, do it." That means it's idempotent imperative code. It doesn't mean it's declarative. CFEngine is slightly less imperative, but w…
How does K8s know what order to do things in if there aren't steps? Because on a system, certain things obviously need to happen before other things.
This is basically the benefit of "containerization" - it's not the containers themselves, it's the constraints they place on the problem space.
Kubernetes gives you limited tools for doing things to container images beyond running a single command - you can run initContainers and health checks, but the model is generally that you start a container from an image, run a command, and exit the container when the command exits. If you want the service to respawn, the whole container respawns. If you want to upgrade it, you delete the container and make a new one, you don't upgrade it in place.
If you want to, say, run a three-node database cluster, an Ansible playbook is likely to go to each machine, configure some apt sources, install a package, copy some auth keys around, create some firewall rules, start up the first database in initialization mode if it's a new deployment, connect the rest of the databases, etc. You can't take this approach in Kubernetes. Your software comes in via a Docker image, which is generated from an imperative Dockerfile (or whatever tool you like), but that happens ahead of time, outside of your running infrastructure. You can't (or shouldn't, at least) download and install software when the container starts up.
You also can't control the order when the containers start up - each DB process must be capable of syncing up with whichever DB instances happen to be running when it starts up. You can have a "controller" (https://kubernetes.io/docs/concepts/architecture/controller/) if you want loops, but a controller isn't really set up to be fully imperative, either. It gets to say, I want to go from here to point B, but it doesn't get much control of the steps to get there. And it has to be able to account for things like one database server disappearing at a random time. It can tell Kubernetes how point B looks different from point A, but that's it.
And since Kubernetes only runs containers, and containers abstract over machines (physical or virtual), it gets to insist that every time it runs some command, it runs in a fresh container. You don't have to have any logic for, how do I handle running the database if a previous version of the database was installed. It's not - you build a new fresh Docker image, and you run the database command in a container from that image. If the command exits, the container goes away, and Kubernetes starts a new container with another attempt to run that command. It can do that because it's not managing systems you provide it, it's managing containers that it creates. If you need to incrementally migrate your data from DB version 1 to 1.1, you can start up some fresh containers running version 1.1, wait for the data to sync, and then shut down version 1 - no in-place upgrades like you'd be tempted to do on full machines.
And yeah, for databases, you need to keep track of persistent storage, but that's explicitly specified in your config. You don't have any problems with configuration drift (a serious problem with large-scale Ansible/CFEngine/etc.) because there's nothing that's unexpectedly stateful. Everything is fully determined by what's specified in the latest version of your manifest because there's no other input to the system beyond that.
Again, the tradeoff is this makes quite a few constraints on your system design. They're all constraints that are long-term better if you're running at a large enough scale, but it's not clear the benefits are worth it for very small projects. I prefer running three-node database clusters on stateful machines, for instance - but the stateless web applications on top can certainly live in Kubernetes, there's no sense caring about "oh we used to run a2enmod but our current playbook doesn't run a2dismod so half our machines have this module by mistake" or whatever.
Earlier quoted context omitted.
So terraform is a higher-order, meta-Kubernetes. It's very rarely used, but who provisions the cluster itself? That's terraform. So terraform creates the cluster, DNS and VPC. Then k8s runs pretty much everything.
Why would you want to provision your own k8s cluster, if you can use EKS, AKS or similar?