Kubernetes

Why aren’t you migrating your workloads to kubernetes, Jow Forums?

Attached: 2D39F614-9302-4B7B-863E-7661EACD1E09.png (209x203, 12K)

Because I'm not working at a shitty company looking to automate out my job and let me go.

What parts does it automate out?

Automation is good user, it escalates the organizations level of thinking and lets you work on higher-level concerns.

My team is trying to do that currently, I think. We use Artifactory and deploy it via Docker, and they’ve been exploring Kubernetes for something related to that (Not sure exactly, i’m currently working on something else). All I’ve heard from them was that they ran into network issues due to the retarded way our corp network is set up.

Quick question.
I'm learning about Kubernetes on a little microservices project at home but it's twisting my mind because its entire philosophy is the opposite of everything I do at work.
At work, we have ~10 applications, each with its own database and therefore we have as many VMs. Basically for each app there's one VM which hosts the database and another VM which hosts the application.
Working with Kubernetes, you'd essentially have only one big VM on whatever cloud platform, and then organize all your services in pods and deployments?
I don't get it, please explain to a brainlet how to work with this.

So in this example you have 20ish VMs?

You have it basically right, yes. You would create deployments for each application, and the pods would be scheduled on the cluster.

I’ll point out that it need not be one VM, you could cluster all of those 20 vms together and make them nodes in the cluster.

You have it right so far, keep reading and playing :) caveat that it is generally not advisable to run databases in containers, even with persistent storage, so those can stay on bare metal or dedicated VMs

Aight that makes a little more sense. The difficulty in working with this on personal projects is that as far as I could find there's no free hosting service for it to test deployments and whatnot so I'm stuck with running shit on my own computer.

Also
>it is generally not advisable to run databases in containers
Why is that? You'd just set up your databases the old fashioned way and leave them out of your CI/CD flow?

Forgot to answer
>So in this example you have 20ish VMs?
Yep, it's kind of a mess sometimes but it works well enough.

I wish i can but our office network is fucked

Without paying for cloud hosting, no. Minikibe is great though. Maybe you can convince your manager to give you aws credits or something.

I haven’t played around too much with containerizing databases, just listened to smarter people. I think for an ACID compliant database you can run into issues with the pods not knowing that a transaction has occurred, and what happens if your pod crashes, or the persistentvolume fails or other nastiness.

Aight thanks for the info!
One last question before I go to the wage cage. What I'm understanding from your previous answer is that you set up 1 or more VMs as a cluster, and then you deploy all your pods/deployment on that cluster and they'll get stretched appropriately over that cluster but it's NOT doing 1 VM=1 service.

Also re CI/CD for the database, we used feature toggles on our code that looked at rows with old/new versions of the schema, and ran the updates/creates/drops as patches. It worked pretty nicely but wasn’t without its warts. For example, removing a column was a pain in the ass. You could only easily add columns, and have the new code stop inserting data into the old column, until the column could be removed with the new patch, and new code looking at the old (previously new) and NEW new schemes

It’s not one VMs per service, no. You set up a deployment object, which describes the desired number of pods for a particular application. If you want 4, kubernetes knows to try and schedule 4 of those pods. Then kubernetes has an object called a Service that knows the IPs of those pods, and will route traffic to one of the appropriate pods

Right, I get it a little more. Thanks my man, time to go wage it up.

redpill me on the value of this for the indie developer (team of 4)

>What parts does it automate
It automates the transfer of large amounts of money from my employer in to my bank account

How many services do you have?

Kube is cool as hell but I don’t think you’ll need it unless you plan on having a large number of services at cloud-scale, that will still be managed by a relatively small team.

You need a team of operations people to manage Kubernetes unless you're using GKE.

I tried, but have yet to find a clean automated way to bootstrap the database setup in a staging/development environment

There is no database component to vanilla kubernetes. Or are you talking about etcd? Just use ansible or something similar, if kubeadm/kubespray doesn’t already do it

>ansible
That's what I was thinking. Right now I have a quick and dirty python script which creates the db and imports the .sql file, but it seems dirty. Maybe ansible + initcontainer is the solution