kube-exam/helm/README.md

Leer en español

Design decisions of the chart

This README explains some of the design decisions made during the development of the helm chart.

Usage of Namespace

The namespace exam is used to isolate the resources (with all the benefits that brings) and avoid using the default namespace.

Usage of Default Values

All variables that are repeated and that, initially, wouldn't make sense to change for this chart are marked with default values.

For example, look for the defaults in service.yaml. You'll see that type defaults to "ClusterIP" and targetPort defaults to $port.

This has two benefits:

1. Reduces redundancy in values.yaml.
2. Provides freedom to easily modify it in the future in values.yaml. For example, suppose we want to change the type to "NodePort" in the api service, it's sufficient to make the following change:

services:
  - api:
    name: "api"
    tier: "backend"
    port: 5000
    type: "NodePort"

Flexibility with Domain

In ingress, the host is repeated to facilitate the API being on another domain. For example:

ingress:
  ssl: true
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  hosts:
    - host: kube.slc.ar
      paths:
        - path: /
          name: "client"
          port: 8080
          pathType: "Prefix"
    - host: api.kube.slc.ar
        - path: /
          name: "api"
          port: 5000
          pathType: "Prefix"
  tls:
   - secretName: exam-crt
     hosts:
       - kube.slc.ar
       - api.kube.slc.ar

Certificates for Ingress

Autogenerated certificates can be passed in ingress.ssl.*, BUT note the security restrictions of helm: only files relative to the chart path can be used. Therefore, if you want to use a file from "outside," you can create a symbolic link. For example: cd helm && ln -sf /usr/local/etc/ssl/certs/ca.crt ca.crt && ln -sf /usr/local/etc/ssl/private/ca.key ca.key. Then, pass those files to ingress.ssl.*.

Note that for these secrets to be used:

1. If secret-crt already existed, it must be deleted and a helm upgrade performed.
2. If it didn't exist, a helm install is sufficient (or even a helm upgrade if it was already running).

Therefore, suppose you want to update the certificates with ones autogenerated by you (and to update them once the ones autogenerated by you expire). The steps are as follows:

1. Delete exam-crt.
2. Update certificates.
3. Put them in the values.yaml if the path has been modified or if a helm-autogenerated one was used before.
4. Perform helm upgrade.

If you want to update the ones autogenerated by helm, the steps are:

1. Delete exam-crt.
2. Perform helm upgrade.

Note that if you only perform an upgrade, the exam-crt will not be regenerated. This is expected because otherwise, every time we modify something, a new certificate would be autogenerated!

Stateful for Postgres

Choosing to implement a stateful.yaml file as we need PostgreSQL to be an application with "stable, persistent storage" (see documentation). Additionally, in the future, if we wanted to have READ replicas, it could be done very easily by adding containers and necessary logic. For that case, a stateful set must be used to always keep the master identified. I left it as more of a future-proofing measure.

Note that if we were using a deployment, we would have many problems with the application's stop because they are sharing the same data volume at the same time (until the new pod is successfully up, the old one will remain active and then stop). This could lead to corruption of the database. This problem is easily fixed with a StatefulSet.

On the other hand, if we were using a cluster, RollingUpdate would save us from an image that does not exist, for example, as it starts with the pods with the highest cardinal and if one fails, it doesn't continue updating.

Connection Tests

They can be run with helm test exam -n exam.