I’ve just migrated this blog site itself into the kubernetes cluster I built with Raspberry Pi 4s, and this post is about the steps and approach I used to achieve this goal. Yes, what you have been reading is served by 1 of the Raspberry Pi boards.

First of all, a bit introduction on kustomize: It’s a bit late to the game but better late than never. Since kubectl v1.14, kustomize has been merged as a switch like kubectl apply -k test.yaml ...

I guess the reason behind something like kustomize is when a guy like me deploying apps into k8s clusters, it’s actually a lot of “YAML engineering”, ie. writing YAML files for the Namespace, Deployment, Service, etc. It’s OK to do it for the first time, but very soon I felt repeating myself with all those metadata or annotation tags.

helm is the other tool to manage kubernetes schema files and it started quite earlier than kustomize. I never liked it though. A sample helm chart template looks like this. The main reason I don’t like it is that it brings placeholders like {{ .Values.stuff }} into yaml and they are everywhere, just like good old asp/jsp templates, this makes the template no longer a valid YAML any more. Also I’m not a fan to put a lot of logic into configuration files.

Here’s a very good blog on how to kustomize. With kustomize I can put values associated with some conditions, eg. git branch, or ops environments, etc. into YAML files without any efforts to template the original schema, which enabling me to check-in the base schema into a public repository without the need to worry if I put any database password there.

Here’s the github repository where I store the YAML files which I used to deploy wordpress into my cluster, including following implementations:

• Namespace for each installation
• typical WordPress on PHP7.2-FPM and nginx containers running as non-root user
• K8s PersistedVolume on NFS shared partition for files, eg. photos, plug-ins, etc.
• Redis cache for PHP session
• Istio Gateway and VirtualService samples
• Ingress routing for nginx-ingress-controller(I’m not using this though)

The base directory has almost all the schema and with some dummy values. And the wordress-site directory has kustomize patch files which should hold your domain name, NFS server address for storage, etc.

To reuse my schema, you can simply duplicate the wordpress-site directory along side with the base directory and put in real configuration as fit. Such as:

kustomize/
  base/
  wordpress-site1/
  wordpress-site2/

Then assuming you’ve configured kubectl, database and NFS already, you can preview the wordpress deployment with:

# in kustomize/wordpress-site1/
kubectl apply -k . --dry-run -o yaml |less
# or using kustomize standalone command
kustomize build . |less

And do the real thing without the --dry-run switch.

But the secret referenced in deploy.yaml is not checked in obviously. You need to create it manually with:

# prepare and create the secret
kubectl create secret --namespace wordpress-mysite generic wordpress-secret --from-literal=dbuser=mysqluser --from-literal=dbhost=x.x.x.x --from-literal=dbname=mysite --from-literal=dbpass=mysqlpass

# optionally this can be encrypted as a sealed secret
kubectl create secret --namespace wordpress-mysite generic wordpress-secret --from-literal=dbuser=mysqluser --from-literal=dbhost=x.x.x.x --from-literal=dbname=mysite --from-literal=dbpass=mysqlpass --dry-run -o yaml |kubeseal -o yaml

🙂