How to Build a Kubernetes Portfolio Project

Local cluster vs cloud cluster: which to use

You do not need to run an EKS, GKE, or AKS cluster to build an impressive Kubernetes portfolio project. Local clusters using kind (Kubernetes in Docker) or minikube are perfectly valid — and often more practical for portfolio work because:

• No cloud costs while you are actively developing and experimenting
• Faster iteration — spin up and tear down without waiting for cloud provisioning
• The Kubernetes concepts are identical regardless of where the cluster runs

However, deploying to a managed Kubernetes service (GKE, EKS, or AKS) is genuinely more impressive for roles that use those services, because it demonstrates familiarity with node pools, cluster networking, and managed control planes. If you are targeting roles that specifically use GKE or EKS, a cloud cluster adds value.

A practical approach: develop and test locally with kind, then deploy the same manifests to a GKE Autopilot or EKS cluster (which can run small clusters within free tier or very low cost). Document both environments in the README.

What to deploy

Deploy a multi-service application — at minimum two services that communicate with each other. A web frontend and an API backend work well. A three-service setup (frontend, API, and a background worker) is better. The application functionality is not the point — the Kubernetes configuration is.

For each service, write and use:

• A Deployment manifest with replica count, container image, resource requests and limits
• Readiness and liveness probes appropriate to the service
• A Service manifest to expose the service within the cluster (ClusterIP for internal, LoadBalancer or NodePort for external)
• ConfigMaps for non-sensitive configuration
• Secrets for sensitive values (even if they are only placeholder secrets in a portfolio project)

Add an Ingress resource to route external traffic to the frontend service. Even on a local cluster, an Ingress with an Ingress controller (nginx-ingress is the most common) shows you understand cluster ingress architecture.

Kubernetes concepts to demonstrate

Resource requests and limits

Every container should have resources.requests and resources.limits defined. Requests tell the scheduler how much CPU and memory to reserve. Limits prevent a runaway container from consuming all node resources. Without these, your pods can be evicted unpredictably under node pressure.

Choose realistic values and explain them in the README. “128Mi memory request, 256Mi limit” should come with an explanation: why 128Mi? Did you profile the application, or is this an estimate?

Readiness and liveness probes

A readiness probe tells Kubernetes when a pod is ready to receive traffic. A liveness probe tells Kubernetes whether to restart a pod. Without readiness probes, Kubernetes sends traffic to pods that have not finished initialising. Without liveness probes, a deadlocked application sits broken until someone notices.

For an HTTP service, readiness probes on the health endpoint (/health or /healthz) with an initial delay and a realistic failure threshold are standard. Document what the probe is checking and what happens when it fails.

Horizontal Pod Autoscaler

Add an HPA to at least one service. Configure it to scale based on CPU or a custom metric. The HPA requires resource requests defined on the container (another reason resource requests matter). Document the min and max replica counts and the threshold you chose.

Pod Disruption Budget

A PodDisruptionBudget ensures that voluntary disruptions (node drains during upgrades, for example) do not take all replicas offline simultaneously. Adding a PDB with minAvailable: 1 is simple to configure and signals that you have thought about operational disruption, not just day-one deployment.

RBAC

Create a ServiceAccount for each application component. Assign only the necessary RBAC permissions. If the frontend does not need to call the Kubernetes API, it should have no RBAC permissions at all. Document this. It is the Kubernetes equivalent of IAM least-privilege and interviewers notice it.

Using Helm

Consider packaging your Kubernetes application as a Helm chart rather than raw manifests. Helm allows parameterisation (different image tags, replica counts, and environment-specific values in separate files), templating, and easier upgrades.

The main benefit for a portfolio project is demonstrating awareness of real deployment tooling. Most companies using Kubernetes deploy with Helm. A repository that includes a well-structured Helm chart with a values.yaml and override files for staging and production is significantly more impressive than a flat directory of manifests.

If you add Helm, document what can be configured via values and why.

Common mistakes to avoid

• No resource limits defined. This is the most common beginner mistake and the one most likely to be called out in an interview.
• Using the default namespace for everything. Create and use a dedicated namespace for your application. Namespace separation is basic Kubernetes hygiene.
• Secrets stored in plaintext in Git. Kubernetes Secrets are base64-encoded but not encrypted in a default cluster. Do not commit real secrets to the repository. For a portfolio, either use placeholder values and document that real secrets would use a secret management solution, or use Sealed Secrets or External Secrets Operator to demonstrate the production pattern.
• A Deployment with one replica and no PDB. This will go offline during node maintenance. Show you know this.
• No explanation of why you chose between ClusterIP, NodePort, and LoadBalancer. This is a common interview question — put the answer in the README.

What to document in the README

The README should include:

• An architecture diagram or text description of the services and how they communicate
• A deployment guide: what prerequisites are needed and the exact commands to deploy to a kind cluster
• The resource request/limit values and why you chose them
• The readiness and liveness probe configuration and what they check
• A note on what Kubernetes features you would add in a real production cluster (for example: network policies, OPA/Gatekeeper admission control, cluster-level audit logging)

For guidance on presenting this project in job applications, see how to write a cloud portfolio case study.