Lesson 3

YAML in Kubernetes and CI

Manifest and workflow patterns developers edit daily.

Most YAML pain in production comes from Kubernetes manifests and CI workflow files—not from toy examples.

Kubernetes manifests

A Deployment usually combines:

  • Top-level API metadata (apiVersion, kind, metadata)
  • A nested pod template under spec.template
  • Container arrays with ports, env vars, and probes

Indentation errors often appear three or four levels deep, which is why line/column parser hints matter more than generic "invalid YAML" messages.

GitHub Actions workflows

Workflow files combine mappings and sequences:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

Common issues:

  • Mis-indenting steps so a step becomes a sibling of jobs
  • Pasting multiline shell without | or > block scalars
  • Mixing JSON-style { } flow collections inside block-style files

Docker Compose

Compose emphasizes service maps and dependency graphs. Port strings such as "8080:80" must stay quoted when YAML would otherwise interpret : specially in ambiguous contexts.

Practical habits

  1. Validate before apply — catch syntax errors locally
  2. Format before PR — stable indentation reduces review noise
  3. Sort keys optionally — cleaner diffs when your team agrees on ordering
  4. Keep secrets out of share links — use placeholders in examples sent to chat

Valid YAML is necessary but not sufficient: resource names, namespaces, and RBAC still need cluster-specific review.

When you want to practice, use the related DevCove tool — optional, not part of this lesson.

Open related tool

Back to course overview