Microservices Docs Help

Deploy Kubernetes definitions

This document provides information about deploying and updating the microservices application on K0s, a lightweight Kubernetes distribution.

Overview

  • Namespace: A dedicated namespace microservices for all resources

  • ConfigMap: For non-sensitive configuration values

  • Secret: For sensitive configuration values (passwords, API keys, etc.)

  • PersistentVolumes and PersistentVolumeClaims: For database storage

  • Deployments and Services: For each microservice

  • Ingress: For external access to the gateway service

Prerequisites

  • TLS certificate for the domain (stored as a Kubernetes Secret)

Directory Structure

  • namespace.yaml: Defines the microservices namespace

  • configmap.yaml: Contains non-sensitive configuration

  • secrets.yaml: Contains sensitive configuration (passwords, API keys)

  • storage.yaml: Defines PersistentVolumes and PersistentVolumeClaims for databases

  • registry-service.yaml: Service registry (Eureka)

  • zipkin.yaml: Distributed tracing (Zipkin, Zipkin Storage, Zipkin Dependencies)

  • monitoring.yaml: Monitoring tools (Prometheus, Grafana)

  • traefik-middleware.yaml: Defines Traefik middleware for HTTP to HTTPS redirection

  • authentication-db.yaml: Authentication database (MariaDB)

  • usermanagement-db.yaml: User Management database (MariaDB)

  • chess-db.yaml: Chess database (MariaDB)

  • fitness-db.yaml: Fitness database (MariaDB)

  • music-db.yaml: Music database (MariaDB)

  • admin-service.yaml: Admin dashboard

  • authentication-service.yaml: Authentication service

  • usermanagement-service.yaml: User management service

  • gateway-service.yaml: API gateway with Ingress configuration

  • website-service.yaml: Website service

  • chess-service.yaml: Chess service

  • fitness-service.yaml: Fitness service

  • music-service.yaml: Music service

Deployment Instructions

  1. Prepare metallb:

kubectl apply -n metallb-system -f metallb-config.yaml

  1. Create the namespace:

    kubectl apply -f namespace.yaml

  2. Create local-storage clas

    kubectl apply -n microservices -f local-storageclass.yaml

  3. Create ConfigMap and Secret:

    kubectl apply -n microservices -f configmap.yaml kubectl apply -n microservices -f secrets.yaml

  4. Create storage resources:

    kubectl apply -n microservices -f storage.yaml

  5. Deploy infrastructure services:

    kubectl apply -n microservices -f zipkin.yaml kubectl apply -n microservices -f registry-service.yaml

  6. Deploy database services:

    kubectl apply -n microservices -f authentication-db.yaml kubectl apply -n microservices -f usermanagement-db.yaml kubectl apply -n microservices -f chess-db.yaml kubectl apply -n microservices -f fitness-db.yaml kubectl apply -n microservices -f music-db.yaml

  7. Deploy application services:

    kubectl apply -n microservices -f admin-service.yaml kubectl apply -n microservices -f authentication-service.yaml kubectl apply -n microservices -f usermanagement-service.yaml kubectl apply -n microservices -f website-service.yaml kubectl apply -n microservices -f chess-service.yaml kubectl apply -n microservices -f fitness-service.yaml kubectl apply -n microservices -f music-service.yaml
kubectl apply -n microservices -f prometheus.yaml kubectl apply -n microservices -f grafana.yaml

  1. Deploy gateway service with Ingress:

    TLS Certificate

    Before deploying the gateway service, ensure you have created a TLS Secret named michibaum-tls in the microservices namespace:

    k0s kubectl create secret tls michibaum-tls --cert=/data/ssl/fullchain.pem --key=/data/ssl/privkey.pem -n microservices
    kubectl apply -n microservices -f gateway-service.yaml

  2. Deploy DB backups

    kubectl apply -n microservices -f db-backup.yaml

Ingress Configuration

Notes

  • The configuration uses hostPath volumes for simplicity. In a production environment, you should use a more robust storage solution like a cloud provider's persistent disk.

  • Secrets contain placeholder values. Replace them with actual values before deployment.

Port Forward

kubectl port-forward -n microservices svc/authentication-db 3307:3306 kubectl port-forward -n microservices svc/chess-db 3309:3306 kubectl port-forward -n microservices svc/fitness-db 3310:3306 kubectl port-forward -n microservices svc/music-db 3311:3306 kubectl port-forward -n microservices svc/usermanagement-db 3308:3306

Updating the Kubernetes Deployment

Update Types

Updates to the microservices application can be categorized into several types:

  1. Service Image Updates: Deploying new versions of service containers

  2. Configuration Updates: Changes to ConfigMaps or Secrets

  3. Database Schema Changes: Updates that require database migrations

  4. Infrastructure Updates: Changes to the underlying Kubernetes resources

Updating Service Images

Using Specific Tags

While the current configuration uses the latest tag, it's recommended to use specific version tags for production deployments. This allows for better control over which version is deployed and makes rollbacks easier.

To update a service image:

  1. Update the image tag in the service's deployment YAML file:

containers: - name: authentication-service image: 70131370/authentication-service:1.2.3 # Use specific version instead of 'latest'

  1. Apply the updated deployment:

kubectl apply -n microservices -f authentication-service.yaml

Using kubectl set image

For quick updates without modifying YAML files, you can use the kubectl set image command:

kubectl set image deployment/authentication-service authentication-service=70131370/authentication-service:1.2.3 -n microservices

Monitoring the Update

Monitor the rollout status to ensure the update is proceeding as expected:

kubectl rollout status deployment/authentication-service -n microservices

Updating Configuration

ConfigMap Updates

To update configuration in ConfigMaps:

  1. Edit the configmap.yaml file with the new configuration values

  2. Apply the updated ConfigMap:

kubectl apply -n microservices -f kubernetes/configmap.yaml

  1. Restart the affected deployments to pick up the new configuration:

kubectl rollout restart deployment/authentication-service -n microservices

Secret Updates

To update sensitive configuration in Secrets:

  1. Edit the secrets.yaml file with the new secret values

  2. Apply the updated Secret:

kubectl apply -n microservices -f kubernetes/secrets.yaml

  1. Restart the affected deployments:

kubectl rollout restart deployment/authentication-service -n microservices

Database Schema Changes

Database schema changes require careful handling to avoid data loss or service disruptions.

  1. Ensure Backward Compatibility: Design schema changes to be backward compatible when possible

  2. Create a Migration Plan: Document the steps required for the migration

  3. Backup Data: Always backup the database before schema changes

Implementation Steps

  1. Create a database backup:

kubectl exec -it <database-pod-name> -n microservices -- mysqldump -u root -p<password> <database-name> > backup.sql

  1. Apply schema changes using a migration tool or script

  2. Update the application to use the new schema

  3. Verify the application works correctly with the new schema

  4. If issues occur, be prepared to rollback to the previous schema

Rolling Updates

Kubernetes performs rolling updates by default when you apply changes to a deployment. This ensures that there is no downtime during the update process.

Customizing Rolling Update Strategy

You can customize the rolling update strategy in the deployment YAML:

spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1

  • maxUnavailable: Maximum number of pods that can be unavailable during the update

  • maxSurge: Maximum number of pods that can be created over the desired number of pods

Canary Deployments

For critical updates, consider using a canary deployment approach:

  1. Deploy a single instance of the new version alongside the existing version

  2. Route a small percentage of traffic to the new version

  3. Monitor for any issues

  4. Gradually increase traffic to the new version

  5. Once confident, complete the rollout of the new version

Rollback Procedures

If an update causes issues, you can rollback to a previous version.

Rolling Back a Deployment

kubectl rollout undo deployment/authentication-service -n microservices

To rollback to a specific revision:

# List revisions kubectl rollout history deployment/authentication-service -n microservices # Rollback to a specific revision kubectl rollout undo deployment/authentication-service --to-revision=2 -n microservices

Rolling Back Configuration Changes

If a ConfigMap or Secret update causes issues:

  1. Reapply the previous version of the ConfigMap or Secret

  2. Restart the affected deployments:

kubectl rollout restart deployment/authentication-service -n microservices

Best Practices

  1. Use Specific Image Tags: Avoid using latest tag in production

  2. Test Updates in Staging: Always test updates in a staging environment before applying to production

  3. Implement Health Checks: Ensure all services have proper readiness and liveness probes

  4. Monitor During Updates: Closely monitor application metrics and logs during updates

  5. Automate Updates: Use CI/CD pipelines to automate the update process

  6. Document Changes: Keep a changelog of all updates applied to the cluster

  7. Regular Backups: Maintain regular backups of all databases and configuration

  8. Update Strategy: Define an update strategy for each service based on its criticality

  9. Communication: Inform all stakeholders before performing updates that might affect service availability

Last modified: 29 July 2025
k0s and k0sctlDatabase