Beginner with a few questions before even starting

So, one of my clients I have been working for for a great number of years is looking to expand their business. Their current project is running on one Windows server running Apache, PHP, MySQL. In the next version we’re looking to move to a Linux based platform and I thought Docker could work and I was able to quickly set up a basic set of Docker containers with PHP and MySQL. My next thought was using Kubernetes as means of load balancing instead of running everything on just 1 server or 1 set of containers. I have watched Network Chuck’s explanation on the topic and I’m confident I’ll be able to get this to work. I have looked into a couple of cloud providers like TransIP, Linode and Vultr and based on my experience with the latter, I think I might go with them, but before I set anything up just yet, I have a few questions:

  • Cronjobs: The application is a web application and contains a couple of cronjobs. I first installed crontab on my PHP container, but that would mean the job will run on all containers, right? Is there a way of of just running it on 1 container?

  • Store data: I have created a number of volumes that host the PHP files as well as the MySQL databases, so far so good. But how does this work within a Kubernetes cluster? Do all pods get their data from the same centralized volume? And I’m able to access this data via (for example) FTP or SSH?

  • Vultr specific: Could ask this directly with them of course, but I’d rather have a non biased opinion. Vultr states on their website they have a “Free Controle Plane”. Is this Kubectl?

  • Let’s Encrypt: is it possible to add LE to the mix?

Just a few things. When I go ahead and set this up I’ll probably run into a few things, but these are things I’d like to know before “inserting the boot disk”. Thanks for taking the time reading this.

I would strongly advise not jumping right into Kubernetes, especially self-managed on a platform like Vultr. Kubernetes is incredibly powerful with an extreme amount of flexibility, but that flexibility comes with a high level of complexity and a lot of potential landmines.

If you’d still like to explore K8s as an option, I’d suggest pursuing the CKA which should prepare you for self-managing K8s.

Vultr has a complete solution, so it’s not completely self-managed: Vultr Kubernetes Engine, Deploy & Scale Containerized Apps with a Fully Managed Service -

What exactly do you mean with “CKA”?

Certified Kubernetes Administrator. Even if you do not pursue getting the cert itself, doing the research and such you’d need to take the test will teach you everything you need to know to be successful with getting started.

Kubernetes seems like a good fit for what you want I THINK, but as Bob points out, there’s a lot going on under the hood, and some paradigm shifting you may need to consider.

To answer the specific questions:

If you run something inside the container, then yes - all instances will run that thing (unless you specifically arrange otherwise, e.g. check a lockserver.

k8s has its own idea of CronJob, but it may not be what you need. Hard to say without knowing more.

You should read up on kube volumes - there’s not one answer.

You could use an NFS share as a volume, in which case one change to the PHP files would be available to all pods ~immediately. That’s a good thing and a bad thing - one mistake and kaboom.

You could use something like a ConfigMap as a volume, which can be version controlled, but is pretty size-limited (~1MB total).

You could use something like git-sync to have each pod periodically pull the files from a git repo (or follow the same pattern for a cloud storage bucket or something). This can be very flexible.

There is no FTP or SSH built in - that’s something you have to do yourself, but I think you are thinking about volumes in a very legacy way. :slight_smile:

I presume their control-plane is a kube API server and standard controllers, same as GKE, EKS, AKS, etc.

Look into the cert-manager project - it can auto-provision certs for you.

Thank you.