Lab 4 - Kubernetes Workloads

Introduction¶

Welcome to the lab 4. In this session, the next topics are covered:

• Getting familiar with basic Kubernetes resources;
• Deployment of NGINX server on Kubernetes;
• Setup of Kubernetes workloads for ghostfolio application;
• Configuration of the application secrets.

Workload basics¶

In terms of Kubernetes, a manifest is a .yaml file with description of Kubernetes-managed resource. Typical resources are Pod (container group), Deployment (management for stateless Pods like web services), ConfigMap (set of configuration data), Secret (set of encrypted key-value pairs) StatefulSet (management for stateful Pods, like database services).

Pod workload¶

A Pod is a minimal unit of workload in Kubernetes, which represents a set of containers with common storage and network resources.

An example manifest file for Pod with NGINX server container looks like this:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    resources:
      requests:
        memory: "128Mi"
        cpu: "300m"
      limits:
        memory: "256Mi"
        cpu: "500m"
    ports:
    - containerPort: 80
      name: http

The major sections are:

1. apiVersion - a version of Kubernetes API to use;
2. kind - a type of Kubernetes resource, Pod in this case;
3. metadata describes Pod name and labels for filtering;
4. spec describes a specification for containers, volumes, etc.;
5. containers describes settings for containers within a Pod and includes container images, exposed ports and computing resources.

export KUBECONFIG=/etc/kubernetes/admin.conf
kubectl apply -f pod-nginx.yaml
# pod/nginx created

kubectl get pod nginx
# NAME        READY   STATUS    RESTARTS   AGE
# nginx   1/1     Running   0          2m43s

kubectl exec -it nginx -- /bin/bash
# root@nginx:/#

kubectl describe pod nginx
# Name:             nginx
# Namespace:        default
# ...
# Status:           Running
# IP:               10.0.1.244
# ...

curl 10.0.1.244
#<a href="http://nginx.com/">nginx.com</a>.</p>
#
#<p><em>Thank you for using nginx.</em></p>
#...

Deployment workload¶

One of the most powerful features of Kubernetes is Pod lifecycle management. It covers many cases, for example: Pod gets restarted when an application container crashes with error. For this, Kubernetes requires a higher-level structure Deployment to manage stateless Pods.

If the NGINX Pod is removed, Kubernetes won't recreate it automatically:

kubectl delete pod nginx
# pod "nginx" deleted
kubectl get pod nginx
# Error from server (NotFound): pods "nginx" not found

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          limits:
            memory: "256Mi"
            cpu: "500m"
        ports:
        - containerPort: 80
          name: http

kubectl apply -f deployment-nginx.yaml
# deployment.apps/nginx created

kubectl get deployment nginx
# NAME    READY   UP-TO-DATE   AVAILABLE   AGE
# nginx   1/1     1            1           35s

kubectl get pod -l app=nginx
# NAME                     READY   STATUS    RESTARTS   AGE
# nginx-74547bd6d7-smgmk   1/1     Running   0          51s

kubectl describe deployment nginx

Deployment of Ghostfolio application¶

Ghostfolio is a chosen app as a primary use case for this course.

The app's architecture consists of:

• frontend (Angular);
• backend (NetsJS);
• database (PostgreSQL);
• caching system (Redis).

A docker-compose configuration provided by the development team is in the repository: link. Application deployment consists of 3 containers: Redis, PostgreSQL and the application (frontend + backend).

The Kubernetes setup requires 1 StatefulSet for database and 2 Deployments for cache and the application.

Redis¶

Redis is an in-memory database, which has basic authentication capabilities. In this lab, we are going to use password-base auth. In Kubernetes, the proper way to store static passwords, tokens, etc. is Secret resource.

apiVersion: v1
kind: Secret
metadata:
  name: redis-secret
type: Opaque
data:
  password: cmVkaXMtcGFzc3dvcmQ= # base64 encoded "redis-password"

kubectl apply -f secret-redis.yaml
# secret/redis-secret created

kubectl get secret redis-secret
# NAME           TYPE     DATA   AGE
# redis-secret   Opaque   1      10s

The next step is Deployment of Redis. For now, we create a storage without persistence and with a single replica.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  selector:
    matchLabels:
      app: redis
  replicas: 1
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: bitnami/redis:6.2.13
        env:
          - name: REDIS_PASSWORD
            valueFrom:
              secretKeyRef:
                name: redis-secret
                key: password
        resources:
          requests:
            memory: 128Mi
            cpu: 100m
          limits:
            memory: 256Mi
            cpu: 200m
        ports:
        - containerPort: 6379
          name: redis-port

kubectl get pods -l app=redis
# NAME                     READY   STATUS    RESTARTS   AGE
# redis-7cfc5c8d5c-x775z   1/1     Running   0          3m23s

kubectl logs redis-7cfc5c8d5c-x775z
# ... Welcome to the Bitnami redis container
# ...* Ready to accept connections

Currently, the Redis instance is not properly accessible via network. If an application running in the cluster needs to request Redis, it should know the Pod's hostname or IP. This is not a reliable approach, because pods can be recreated and the hostname changes after this.

To encapsulate one or set of Pods, a Service resource is recommended. It works as a single-point access to Pods and provides load balancing. In the next lab, we are going to dive deeper into Kubernetes networking topic.

apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  selector:
    app: redis
  ports:
  - port: 6379
    targetPort: 6379

PostgreSQL¶

PostgreSQL is a free object-relational database system. Many IT companies make use of it due to openness, included features and large community. In this practice, we use this system as a primary data storage for the use-case app.

apiVersion: v1
kind: Secret
metadata:
  name: postgresql-secret
type: Opaque
data:
  username: Z2hvc3Rmb2xpbw== # base64 encoded ghostfolio
  database: Z2hvc3Rmb2xpbw== # base64 encoded ghostfolio
  postgresPassword: cG9zdGdyZXMtcGFzc3dvcmQ= # base64 encoded postgres-password

kubectl apply -f secret-postgresql.yaml
# secret/postgresql-secret created

Now, we are ready to deploy a StatefulSet for PostgreSQL. StatefulSet is a management resource as a Deployment, which controls stateful applications only. The key differences between the two:

• StatefulSet creates and removes pods in a strict order;
• Deployment Pods are identical and can be interchanged;
• Deployment assigns random name suffix for Pods, StatefulSet uses sequential numbers;
• Pods managed by a Deployment share the same persistent storage while StatefulSet creates a volume for each replica.

For now, the storage setup for Kubernetes is not covered by this lab, so instead of persistent volumes we use in-memory storage.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgresql
spec:
  selector:
    matchLabels:
      app: postgresql
  serviceName: postgresql
  replicas: 1
  template:
    metadata:
      labels:
        app: postgresql
    spec:
      containers:
      - name: postgresql
        image: bitnami/postgresql:15.4.0
        env:
          - name: POSTGRESQL_USERNAME
            valueFrom:
              secretKeyRef:
                name: postgresql-secret
                key: username
          - name: POSTGRESQL_DATABASE
            valueFrom:
              secretKeyRef:
                name: postgresql-secret
                key: database
          - name: POSTGRESQL_PASSWORD
            valueFrom:
              secretKeyRef:
                name: postgresql-secret
                key: postgresPassword
        ports:
        - containerPort: 5432
          name: postgres-port
        volumeMounts:
        - name: postgresql-data
          mountPath: /bitnami/postgresql
      volumes:
        - name: postgresql-data
          emptyDir: {}

kubectl logs postgresql-0
# ...
# ... [1] LOG: database system is ready to accept connections
# ...

kubectl exec -it postgresql-0 -- bash
# I have no name!@postgresql-0:/$

export PGPASSWORD="postgres-password"
psql -U ghostfolio
# psql (15.4)
# Type "help" for help.

# ghostfolio=>

Ghostfolio app¶

Ghostfolio uses a single container for the frontend and the backend and doesn't include any persistent data. Deployment fits these requirements and, in this section, you need to create and apply a manifest yourself.

...
- name: DATABASE_URL
  valueFrom:
    secretKeyRef:
      name: postgresql-secret
      key: url
...

kubectl apply -f secret-postgresql.yaml
# secret/postgresql-secret configured

kubectl rollout restart deployment ghostfolio
# deployment.apps/ghostfolio restarted

resources:
  requests:
    memory: 512Mi
    cpu: 1
  limits:
    memory: 1024Mi
    cpu: 2

kubectl logs -l app=ghostfolio
# ...
# Listening at http://0.0.0.0:3333

curl -I -L 10.0.1.122:3333
# HTTP/1.1 200 OK
# X-Powered-By: Express
# Access-Control-Allow-Origin: *
# Content-Type: text/html; charset=utf-8
# Content-Length: 28290
# ETag: W/"6e82-Hj3f0VuXQ7VokGpxgLIBEvLI1jk"
# Date: Thu, 21 Sep 2023 12:42:59 GMT
# Connection: keep-alive
# Keep-Alive: timeout=5