Kubernetes Management Techniques

Run, Expose, and Create Generators

  • These commands use helper templates called “generators”

  • Every resource in kubernetes has a specification or “spec”

    • kubectl create deployment sample –image nginx –dry-run -o yaml

  • You can output those templates with –dry-run -o yaml

  • You can use those YAML defaults as a starting point

  • Generators are “opinionated defaults”

Generator Examples

  • Using dry-run with yaml output we can see the generators

    • kubectl create deployment test –image nginx –dry-run -o yaml

    • kubectl create job test –image nginx –dry-run -o yaml

    • kubectl expose deployment/test –port 80 –dry-run -o yaml

The Future of kubectl run

  • Right now (1.12-1.15) run is in a state of flux

  • The goal is to reduce its features to only create pods

    • Right now its defaults to creating Deployments (with the warning)

    • It has lots of generators but they are all deprecated

    • The idea is to make it easy like docker run for one-off tasks

  • It’s not recommended for production

  • Use for simple dev/test or troubleshooting pods

Old Run Confusion

  • The generators activate different Controllers based on options

  • Using dry-run we can see which generators are used

    • kubectl run test –image nginx –dry-run

    • kubectl run test –image nginx –port 80 expose –dry-run

    • kubectl run test –image nginx –restart OnFailure –dry-run

    • kubectl run test –image nginx –restart Never –dry-run

    • kubectl run test –image nginx –schedule “*/1 * * * *” –dry-run

Imperative vs Declaritive

  • Imperative: Focus on how a program operates

  • Declarative: Focus on what a program should accomplish

  • Example: “I’d like a cup of coffee”

  • Imperative: I boil water, scoop out 42 grams of medium-fine grounds, pour over 700 grams of water, etc.

  • Declarative: “Barista, I’d like a cup of coffee (barista is the engine that works through the steps, including retrying to make a cup and is only finished when I have a cup)”

Kubernetes Imperative

  • Examples: kubectl run, kubectl create deployment, kubectl update

    • We start with a state we know (no deployments exist)

    • We ask kubectl run to create a deployment

  • Different commands are required to change that deployment

  • Different commands are required per object

  • Imparitive is easier when you know the state

  • Imparitive is easier to get started

  • Imparative is easier for humans at the CLI

  • Imperative is NOT easy to automate

Kubernetes Declarative

  • Example: kubectl apple -f my-resources.yaml

    • We don’t know the current state

    • We only know what we want the end result to be (yaml contents)

  • Same command each time (tiny exception for delete)

  • Resources can be all in a file, or many files (apply a whole dir)

  • Requires understanding the YAML keys and values

  • More work than kubectl run for just starting a pod

  • The easiest way to automate

  • The eventual path to GitOps hapinness

Management Approaches

  • Imperative commands: run, expose, scale, edit, create deployment

    • Best for dev/learning/personal projects

    • Easy to learn, hardest to manage over time

  • Imperative objects: create -f file.yml, replace -f file.yml, delete…

    • Good for prod of small environments, single file per command

    • Store your changes in git-based yaml files

    • Hard to automate

  • Declarative objects: apply -f file or dir, diff

    • Best for prod, easier to automate

    • Harder to understand and predict changes

  • Most important rule

    • DOn’t mix the three approaches

    • Learn the Imperative CLI for easy control of local and test setups

    • Move to apply -f file.yml and apply -f directoryfor prod

    • Store yaml in git, git commit each change before

    • THis trains you later doing GitOPs (where git commits are automatically applied to clusters)