- Some initial setup
- The practice
- STEP 1 - Create a Helm chart
- STEP 2 - Use a redis chart as dependency of our fortune-cookies chart
- STEP 3 - Set up a cronjob that reads fortune cookies from Redis and outputs it to stdout
- STEP 4 - STEP 4 - Set up a cronjob that queues up fortune cookies to Redis
- STEP 5 - Make an accessible endpoint that reads fortune cookies from Redis and returns them as response
- docker (or docker desktop)
- kubectl
- kind (or minikube or k3d if you feel brave)
- helm
Is quite possible that brew, macports or your distro package manager installs most of the requirements just by installing kind.
kind create cluster --name devel --kubeconfig ~/.kube/devel-config
kind export kubeconfig --name devel
Feel free to replace ~/.kube/devel-config
with whatever path you prefer.
The --kubeconfig
must be included to prevent kind from messing up any default k8s configuration you have.
From now on, on every kind
command you use, you'll need to include --name devel
, which is the name of the cluster.
The export
command make the devel
kubeconfig the default one in your current terminal. If not exported or if you change your terminal, then you'll need to add --kubeconfig ~/.kube/devel-config
to almost all your helm command calls.
We need to build and load our custom docker images to kind in order to avoid using a docker registry.
Kind (k3d too, I don't know if minikube does) has a mechanism to tell the local cluster to use a locally generated image instead of trying to get it from a docker registry.
docker build \
--target fortune-cookies-takeaway-customer \
--tag fortune-cookies-takeaway:latest \
-f docker/fortune-cookies/Dockerfile \
docker/fortune-cookies/
kind load docker-image --name devel fortune-cookies-takeaway:latest
docker build \
--target fortune-cookies-delivery-customer \
--tag fortune-cookies-delivery:latest \
-f docker/fortune-cookies/Dockerfile \
docker/fortune-cookies/
kind load docker-image --name devel fortune-cookies-delivery:latest
docker build \
--target fortune-cookies-chef \
--tag fortune-cookies-chef:latest \
-f docker/fortune-cookies/Dockerfile \
docker/fortune-cookies/
kind load docker-image --name devel fortune-cookies-chef:latest
helm create helm-charts/fortune-cookies
Have a look to the resulting files in helm-charts/fortune-cookies
.
Can you make any sense of the templating engine and the values?
The idea is to end up this practice step with a running redis instance in our cluster.
In order to do that, add the next YAML to the Chart.yaml
file on your recently created chart (or get the help of your Jetbrains IDE to add the dependency from bitnami's repo):
dependencies:
- name: redis
version: 17.13.2
repository: https://charts.bitnami.com/bitnami
Build the newly declared dependency and intall our chart in the k8s cluster
helm dependency build helm-charts/fortune-cookies/
helm install fortuneCookies helm-charts/fortune-cookies/
Review available config values for that redis dependency and think about what you can tweak with them: https://artifacthub.io/packages/helm/bitnami/redis
Also visit Helm documentation about chart dependencies value overrides: https://helm.sh/docs/chart_template_guide/subcharts_and_globals/#overriding-values-from-a-parent-chart
You can upgrade the helm release by executing this command:
helm upgrade fortuneCookies helm-charts/fortune-cookies/
Have a look to the k8s cluster with openlens or any similar tool, or with kubectl
.
NOTE: review Helm available commands, there are very useful ones like:
helm template --help
The cronjob has to make use of the fortune-cookies-chef:latest
image we created during the setup and shall run every minute.
The kubernetes documentation about cronjobs may probe helpful: https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
Can we declare multiple cronjobs just with one cronjob manifest? Is it possible to declare a pod with a replica set with something inside writing to redis?
Very similar to the previous step but with the fortune-cookies-takeaway
image.
Are you able to show the logs of a cronjob with kubectl
or a GUI tool.
At this point, there should be a complete workflow where feature cookies are queued up on redis and customers are taking them away. Is the redis service properly configured?
If you don't see any message or there are "Connection refused" messages in the takeaway cronjob logs, then it may be caused by redis not allowing external clients to connect. Try to check the protected-mode
Redis configuration value.
Normally, a redis server uses a configuration file in /etc/redis.conf
. How this differs in the redis dependency chart?
STEP 5 - Make an accessible endpoint that reads fortune cookies from Redis and returns them as response
Declare an ingress that exposes a 80 port outside of the cluster.
The image you should use is the fortune-cookies-delivery
one.
You'll need to declare a pod and a service for this.
I suggest you to rely on the nginx example that was created when we created our chart.
As always, k8s documentation on ingresses is super useful: https://kubernetes.io/docs/concepts/services-networking/ingress/