Kubernetes Management

Imperative: Focus on how a program operates (boil milk and create chai)

Declarative: Focus on what a program should fulfil (Hamza please give me chai)

• Kubernetes Imperative (no much use anymore)

  This approach is more suitable for quick prototyping, debugging, and one-off tasks. It allows you to interact with the cluster in a step-by-step manner.

  Here are a few examples of imperative commands using the kubectl command-line tool:

  1. Create a deployment:

  kubectl create deployment my-deployment --image=my-image:v1
  1. Scale a deployment:

  kubectl scale deployment my-deployment --replicas=3
  1. Expose a deployment as a service:

  kubectl expose deployment my-deployment --port=8080 --target-port=80 --type=LoadBalancer
  1. Delete a resource:

  kubectl delete deployment my-deployment

  While the imperative approach can be handy for certain scenarios, it's generally advised to use the declarative approach whenever possible for managing your Kubernetes cluster.

  imperative is easier to get started

  imperative is easier for humans at the CLI

  imperative is NOT easy to automate

• Kubernetes Declarative (best way) Kubernetes declarative approach: Describing the desired state of your application or infrastructure using YAML or JSON files, allowing Kubernetes to handle the implementation details. Example:

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: my-webapp
  spec:
    replicas: 3
    template:
      metadata:
        labels:
          app: webapp
      spec:
        containers:
          - name: webapp
            image: my-webapp:latest
            ports:
              - containerPort: 80

  In this example, a Deployment named "my-webapp" with three replicas is defined. Kubernetes ensures the specified image is deployed with the desired replica count and container port. Using kubectl apply, Kubernetes reconciles the desired state with the current state to achieve the defined configuration.

Three Management Approaches

1. Imperative commands: run, expose, scale, edit, create deployment
   1. best for dev/learning/personal projects
   2. easy to learn, hard to manage over time
2. Imperative objects: create -f file.yml, replace -f file.yml, delete...
   1. Goof for prod of small env
   2. store your changes in git-bsed yaml files
   3. Hard to automate
3. Declarative objects: apply -f file.yml or dir\ , diff | best way for DevOps style
   1. Best for prod, easier to automate
   2. Harder to understand and predict changes but most best way to do k8s.