# Kubernetes Management Techniques

> Markdown source of <https://docs.calebsargeant.com/computing/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)