Expose it to the world with Ingress and TLS
Continues from the last build: It is now packaged as a Helm chart you can install per environment, but it is only reachable in-cluster via port-forward, no real hostname, no HTTPS.
The Storefront installs cleanly from its Helm chart, but the only way anyone reaches it is `kubectl port-forward`, which dies when your terminal closes and means nothing to a teammate or a browser.
What you'll build
The Storefront reachable at a real hostname over HTTPS: an NGINX ingress controller fronting the cluster, an Ingress that path-routes the frontend and the API to their Services, a cert-manager ClusterIssuer issuing a Let’s Encrypt certificate into a TLS Secret, and an automatic HTTP-to-HTTPS redirect, all proven with a browser and curl.
See how we teach, before you sign up
You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: storefront
spec:
ingressClassName: nginx
rules:
- host: shop.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: storefront-api
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: storefront-web
port:
number: 80
# tls + cert-manager annotation added in milestones 3-4Reading this file
kind: IngressAn Ingress is the rule set that an ingress controller reads to route outside HTTP traffic to in-cluster Services by host and path.ingressClassName: nginxTells Kubernetes which installed controller owns this Ingress, without it the NGINX controller may ignore the rule entirely.host: shop.example.comThe real hostname callers will use, the controller matches the request Host header against this to pick these rules.name: storefront-webRoutes the matched path to the frontend Service from the Storefront chart, swap in your real Service name if it differs.name: storefront-apiRoutes the /api path to the API Service, this is the path-based split that puts both behind one host.
A skeleton Ingress, you add the TLS block and the cert-manager annotation milestone by milestone.
That's 1 of 8 explained code blocks in this single project.
The build, milestone by milestone
- 1
Install an ingress controller and reach the cluster from outside
5 guided stepsAn Ingress object is just data, nothing happens until a controller is watching it. The controller is the actual load balancer at the edge, so it has to exist and be reachable before any rule can route traffic.
- 2
Route the frontend and API through the Ingress over HTTP
5 guided stepsGet routing correct over HTTP before adding TLS, otherwise a failure could be the certificate or the rule and you cannot tell which. Path-based routing is what lets one hostname serve both the site and its API.
- 3
Point a real hostname at the controller
5 guided stepsA certificate is issued for a hostname, and the ACME HTTP-01 challenge needs that hostname to actually resolve to your controller. Real DNS is the prerequisite for the TLS step, not an optional polish.
- 4
Terminate TLS with a cert-manager certificate
5 guided stepsHTTPS is table stakes for a real product, and hand-managed certificates expire and cause outages. cert-manager automates issuance and renewal so the padlock stays green without anyone remembering to rotate a cert.
- 5
Force HTTPS and verify end to end
5 guided stepsServing HTTPS but still accepting plain HTTP leaves a downgrade gap and a confusing mixed experience. A clean 301 to HTTPS plus an end-to-end check is what makes this a finished, demoable front door.
What's inside when you start
You'll walk away with
This is portfolio-grade. Build it free.
Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.
Start building