Project design

Design the Kubernetes structure for web and database.

Project: a multi-tier application

In this project you'll move an application made of a web front end, an API and a PostgreSQL database to Kubernetes. The plan:

Its own magaza namespace
Database: a single-replica Deployment taking its password from a Secret + a ClusterIP Service
API and web: multi-replica Deployments, settings from a ConfigMap
Only web is exposed outside (NodePort)

k8s/
  00-namespace.yaml
  10-db.yaml
  20-api.yaml
  30-web.yaml
  40-ayar.yaml
kubectl apply -f k8s/

The numbers in the file names keep the order predictable when the folder is applied.

Namespace and context

The first file creates the namespace; all later objects carry metadata.namespace: magaza. While working, the context's namespace is set to avoid writing -n on every command:

# 00-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: magaza

kubectl apply -f k8s/00-namespace.yaml
kubectl config set-context --current --namespace=magaza

Exercise Prepare the namespace

Write two commands: create the magaza namespace; set the active context's namespace to magaza.

Show example solution

kubectl create namespace magaza
kubectl config set-context --current --namespace=magaza

Test yourself

In this design, can the database be reached from outside the cluster?
- Yes, through port 5432
- Yes, via NodePort
- Only in Minikube
- No; ClusterIP is cluster-internal only
Show answer

No; ClusterIP is cluster-internal only — When needed, temporary access is given with kubectl port-forward.

Apply all files in the folder.

kubectl apply -f ____

Show answer

kubectl apply -f k8s/

Match the tiers.

web

Exposed with NodePort
api

ClusterIP, many replicas
db

ClusterIP, single replica
magaza

The project's namespace

Next lesson: Database Deployment

We Are Enhancing Your Experience

Cookie Preferences

Strictly Necessary Cookies

Analytical Cookies