Files

99 lines
3.5 KiB
Markdown

# Assignment
The Nautilus DevOps team is planning to deploy some micro services on Kubernetes platform. The team has already set up a Kubernetes cluster and now they want to set up some namespaces, deployments etc. Based on the current requirements, the team has shared some details as below:
Create a namespace named dev and deploy a POD within it. Name the pod dev-nginx-pod and use the nginx image with the latest tag. Ensure to specify the tag as nginx:latest.
Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.
# Solution
# Kubernetes Namespace + Pod — `dev` / `dev-nginx-pod`
Create a `dev` namespace and run `dev-nginx-pod` (image `nginx:latest`) inside it. Both
objects are applied in one heredoc using a multi-document manifest — no file on disk.
## Apply (heredoc → kubectl)
```bash
kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Namespace
metadata:
name: dev
---
apiVersion: v1
kind: Pod
metadata:
name: dev-nginx-pod
namespace: dev
labels:
app: dev-nginx
spec:
containers:
- name: nginx-container
image: nginx:latest
EOF
```
## How it works
### The heredoc apply pattern
- **`kubectl apply -f -`** reads from **stdin**; the heredoc feeds the YAML straight in,
nothing written to disk.
- **`<<'EOF'` (delimiter quoted)** disables shell expansion, so any `$VAR`/backticks in
a manifest stay literal — the right default for Kubernetes YAML.
- **`---`** separates the two YAML documents in a single stream. `kubectl apply`
processes each in order, so the **Namespace is created before the Pod** that targets
it. Ordering matters: a pod referencing a namespace that doesn't yet exist would fail
with `namespaces "dev" not found`.
### The Namespace
- **`kind: Namespace` / `metadata.name: dev`** — a namespace is a virtual cluster
partition for isolating and grouping resources. Creating it first gives the pod
somewhere to live.
### The Pod
- **`metadata.name: dev-nginx-pod`** — the pod's name, exactly as required.
- **`metadata.namespace: dev`** — places the pod **in the `dev` namespace**. This is the
key field for the task: without it, the pod would land in `default`. (Equivalent to
passing `-n dev` on the command line, but pinning it in the manifest is explicit and
self-contained.)
- **`metadata.labels.app: dev-nginx`** — an optional label for selection/grouping. Not
required by the task, but good practice.
- **`spec.containers`** — one container:
- **`name: nginx-container`** — the container name.
- **`image: nginx:latest`** — the NGINX image at the `latest` tag, stated explicitly
as required. (Bare `nginx` defaults to `latest`, but the task asks for the tag to be
specified.)
### Namespace-scoping recap
The `namespace: dev` line in the pod's metadata is what satisfies "deploy a POD within
it." Everything else about the pod is standard; the namespace field is the one that
ties the two objects together.
## Verify
```bash
# Namespace exists
kubectl get namespace dev
# Pod is running inside the dev namespace
kubectl get pod dev-nginx-pod -n dev -o wide
# Image is correct
kubectl get pod dev-nginx-pod -n dev \
-o jsonpath='{.spec.containers[0].image}{"\n"}'
```
Expected — namespace `dev` present, `dev-nginx-pod` in `Running` status within it, and
the image printing `nginx:latest`.
> Remember to pass `-n dev` on any `kubectl` command targeting this pod — it's not in
> the `default` namespace. If the pod sits in `ImagePullBackOff`, run
> `kubectl describe pod dev-nginx-pod -n dev` to see the pull events.