Comment by corytheboyd | Hacker News Reader

Comment by corytheboyd | Hacker News Reader

Parent Full thread

A bit OT. I’ve been putting off learning how to setup and run k8s, and am unfortunately in a situation where I don’t have anyone at work to learn from.

For context I’m no stranger to what the shape of production ready systems should be and can fill in the gaps given enough time to research and educate myself, but I don’t do operational work day-to-day.

I’m bringing a project to life right now and can’t but feel like while tough to learn and manage, k8s would be a good investment to make. I don’t have anyone using it yet, so I just did the bare minimum to get my docker-compose stack up and running on a Linode box. It works great for making sure what I have now works in a remote environment too, and I had to do a decent amount of configuration rework to get it ready, which should be transferable.

Now I’m wondering, how will things like rolling deployments work? I want to decouple the monitoring stack from the application stack, how will I handle adding another physical machine to my setup? I’m sure more questions will come up like this as I run into them, but would be curious to hear initial thoughts from anyone here to help me make a decision :)

I think the easiest way to get started is to use DigitalOcean's managed Kubernetes offering. If you already know Docker then basically you'll just be learning how to setup a cluster on Kubernetes, installing your app to the cluster and other apps using kubectl and helm, and then setting up an ingress into the cluster (likely nginx-ingress although there are other options).

In regards to your specific questions... adding another physical machine to your cluster would be really simple if you are using Terraform, you would just increment your node count number and then re-apply the Terraform config. Here is an example Terraform config(main.tf) from a simple project I have:

  variable "do_token" {}

  provider "digitalocean" {
    token = var.do_token
  }

  resource "digitalocean_kubernetes_cluster" "your-cluster" {
    name    = "your-cluster"
    region  = "sfo2"
    # Grab the latest version slug from `doctl kubernetes options versions`
    version = "1.16.6-do.2"

    node_pool {
      name       = "your-pool-1"
      size       = "s-1vcpu-2gb"
      node_count = 3
    }
  }

For deployments I would honestly just keep it simple and increment your docker tag version number on your image each time you are doing a deploy. Then when you deploy your new image (e.g. kubectl apply -f deployment.yaml), the new image will be pulled down to each cluster pod and the application containers will then be restarted one by one.

If you are running this on another test/development cluster (e.g. minikube) prior to deployment, then you should have great confidence that this will succeed. In the event that you did run into an issue, just roll back the docker image version number and reapply the yaml using kubectl again.

I've been following this method for a while and have never had any downtime with deployments. Eventually if you get sophisticated you'll want to add these steps into an automated CI/CD pipeline, but kubectl apply can carry you pretty far in solo operations.

Thank you for taking the time to craft such a thorough response! I had moving all infrastructure to terraform on my backlog already so that’s validating. I might try the k8s platform offered by Linode since I am there already, but I am constantly reading about how people use DO so maybe it’s more feature rich or something, I have just been a Linode fan for many years is all hah, and the pricing isn’t bad

Reply on news.ycombinator.com