Telusko Docs

Put a Pod and its LoadBalancer Service into one YAML file separated by three dashes, apply and delete them together, and learn the safe ways to remove resources.

So far every object had its own file: k8s-pod.yml for the pod, clusterIp-svc.yml, nodePort-service.yml and k8s-lbr-svc.yml for the Services. That is fine for learning, but real applications need several objects at once (a Deployment, a Service, a ConfigMap, a Secret), and they belong together. Kubernetes lets you put all of them in one manifest file.

The separator: three dashes

YAML supports several documents in one file. Each document is separated by a line containing only ---. kubectl treats each document as a separate object and applies them in order.

# document 1
apiVersion: v1
kind: Pod
...
---
# document 2
apiVersion: v1
kind: Service
...

Step 1: Write the combined file

vi k8s-webapp.yml

k8s-webapp.yml

apiVersion: v1
kind: Pod
metadata:
  name: web-app-pod
  labels:
    app: telusko-webapp
spec:
  containers:
    - name: web-app-container
      image: <your-dockerhub-username>/springboot-app:latest
      ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: web-app-svc
spec:
  type: LoadBalancer
  selector:
    app: telusko-webapp
  ports:
    - port: 80
      targetPort: 8080

Nothing here is new. It is the pod from First Pod Creation and the Service from LoadBalancer Service Explained, joined by ---. The link between them is still the label app: telusko-webapp on the pod and the same value in the Service selector.

Step 2: Apply it

Check that the namespace is clean first:

kubectl get all

Then apply the file:

kubectl apply -f k8s-webapp.yml

In the lecture the first attempt produced this:

service/web-app-svc created
Error from server (BadRequest): error when creating "k8s-webapp.yml": Pod in version "v1" cannot be
handled as a Pod: strict decoding error: unknown field "spec.conatainers"

Two lessons hide in that output:

A typo in a field name (conatainers instead of containers) gives unknown field. Fix the spelling and apply again.
kubectl applies each document on its own. The Service was created even though the Pod failed. A multi-document file is not a transaction; one bad object does not roll back the others. Because apply is idempotent, simply fixing the file and running kubectl apply -f again is safe: the Service shows unchanged and the Pod is created.

pod/web-app-pod created
service/web-app-svc unchanged

Catch errors before anything is created

Run kubectl apply -f k8s-webapp.yml --dry-run=server first. The API server validates every document and reports errors like unknown field without creating anything.

Step 3: Check and open the app

kubectl get pods
kubectl get svc
kubectl get all

Copy the EXTERNAL-IP of web-app-svc (the ...elb.amazonaws.com name), wait two to three minutes for the load balancer to become healthy, and open it in the browser. You should see the same Telusko Learning page as before.

Why one file per application is a good idea

Separate files	One file per application
Easy to read one object at a time	Everything the app needs is in one place
You must remember to apply and delete several files	One `apply`, one `delete`
Good while learning	Common in real projects, often with one folder per app

You can also point kubectl at a folder: kubectl apply -f ./webapp/ applies every YAML file in it. Later in the course, Helm charts take this further by templating many related files.

Step 4: Deleting resources the right way

There are several ways to delete what you created. From most to least precise:

# 1. One object by type and name
kubectl delete pod web-app-pod
kubectl delete svc web-app-svc

# 2. Everything defined in a file (all documents in it)
kubectl delete -f k8s-webapp.yml

# 3. Everything of the common workload types in the current namespace
kubectl delete all --all

Command	Deletes	Risk
`kubectl delete <type> <name>`	Exactly one object	Lowest
`kubectl delete -f <file>`	Every object defined in that file	Low. Objects already gone give a harmless `NotFound` error
`kubectl delete all --all`	Pods, Services, Deployments, ReplicaSets, StatefulSets, DaemonSets, Jobs, CronJobs in the current namespace	High. Never on a shared or production cluster

What delete all --all does not delete

The lecture says kubectl delete all --all deletes every namespace too. It does not. The all category covers the common workload types and Services only, in the current namespace. Namespaces, ConfigMaps, Secrets, PersistentVolumeClaims, Ingresses and many others are left in place. The command is still dangerous because of what it does delete, but do not rely on it to "clean everything".

If you run kubectl delete -f on a file whose objects were already deleted, you get messages like Error from server (NotFound): services "webapp-svc" not found. That just means there was nothing left to delete. Add --ignore-not-found to silence it.

Delete the LoadBalancer Service before the cluster

web-app-svc created an AWS load balancer that is billed per hour. kubectl delete -f k8s-webapp.yml removes it. Check EC2, Load Balancers is empty before running eksctl delete cluster --name telusko-learning --region ap-south-1 --wait.

Try It Yourself

Create k8s-webapp.yml with the Pod and the LoadBalancer Service, apply it, and open the app in the browser.
Add a third document to the file: a ClusterIP Service named web-app-internal with the same selector. Apply again and notice which objects are created and which are unchanged.
Misspell a field in the Pod, delete everything, and apply. Confirm the Services are still created while the Pod fails.
Delete everything with kubectl delete -f k8s-webapp.yml and confirm the AWS load balancer is gone.

Official references

Written By: Shramik Masti

Creating Pod and Service in One Manifest File