Problem with static manifest files

• whenever the code is commited, we build a new docker image with a new tag and that has to be deployed in certain environments.
• so far, according to what we know manifest files are static i.e. whenever the a new tag is generated change yaml files commit them to git and redeploy using kubectl apply -f
• the other option is patch deployment. refer patching deployment below
• To solve this in a way our manifest can handle dynamic value passing we have two solutions
  • helm
  • kustomize

Patching deployment

The Kubernetes command to patch a Deployment is kubectl patch deployment, followed by flags to specify the patch details. You can update fields of the deployment resource using a strategic merge patch, JSON merge patch, or JSON patch. The patch can be provided inline with -p or through a patch file with --patch-file.

Examples of common patch usage:

• To scale replicas via the Deployment’s scale subresource (merge patch):
  kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":3}}'
• To update the image of a container in the Deployment (strategic merge patch):
  kubectl patch deployment my-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"container-name","image":"new-image:tag"}]}}}}'
• Using JSON patch to replace a container image by array index:
  kubectl patch deployment my-deployment --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value": "new-image:tag"}]'
• To add or update metadata labels:
  kubectl patch deployment my-deployment --patch '{"metadata": {"labels": {"new-label": "value"}}}'

Key points:
– The patch format can be JSON or YAML.
– The patch string must accurately reflect the object’s structure to update the correct fields.
– Strategic merge patch is the default and preferred type for Deployments.
– The --subresource flag can patch specific subresources like scale (e.g., changing replicas).
– If the subresource does not exist, the API returns a 404 error.
– You can also patch using a patch file instead of inline string.

References:
This usage is detailed in the Kubernetes official documentation [1][2], and various tutorials on patching deployments in place [3][4]. Common patch operations include scaling, image updates, and label modifications through the kubectl patch command.

If you want, I can provide an example patch command tailored to your specific Deployment update needs.

[1] https://kubernetes.io/docs/reference/kubectl/generated/kubectl_patch/
[2] https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/
[3] https://spacelift.io/blog/kubectl-patch-command
[4] https://komodor.com/learn/kubectl-patch-changing-kubernetes-objects-in-place/
[5] https://www.unixarena.com/2024/01/how-to-patch-kubernetes-existing-deployment-how-to-roll-back.html/
[6] https://www.loft.sh/blog/kubectl-patch-what-you-can-use-it-for-and-how-to-do-it
[7] https://developer.harness.io/docs/continuous-delivery/deploy-srv-diff-platforms/kubernetes/cd-k8s-ref/kubernetes-patch-step/
[8] https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
[9] https://stackoverflow.com/questions/71221533/kubectl-patch-existing-container-command

Helm

• This is package manager of k8s.
• Helm connectivity
  
• consider the following file

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-container
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

• Now i want to reuse the same yaml with
  • a new image tag
  • service type node port
• Installing helm Refer Here
• We have create a helm and we had static template Refer Here
• Refer Here for helm chart file structure
• Helm uses go templating syntax to read the values

---

🧭 Helm Templating Syntax Cheat Sheet

📌 Variables

{{ $var := "value" }}
{{ $replicas := 3 }}

📌 Accessing Values from values.yaml

{{ .Values.image.repository }}
{{ .Values.service.name }}

📌 Conditionals

{{ if .Values.enabled }}
  # Do something
{{ end }}

If-Else

{{ if .Values.debug }}
  Debug Mode
{{ else }}
  Release Mode
{{ end }}

📌 With Block

{{ with .Values.resources }}
  CPU: {{ .cpu }}
  Memory: {{ .memory }}
{{ end }}

📌 Range Loop

{{ range .Values.hosts }}
- host: {{ . }}
{{ end }}

📌 Define and Include Templates

Define

{{ define "mychart.labels" }}
app: myapp
version: v1
{{ end }}

Include

metadata:
  labels:
    {{ include "mychart.labels" . | indent 4 }}

📌 Required Values

{{ required "Image is required!" .Values.image.repository }}

📌 Default Values

env: {{ .Values.env | default "production" }}

📌 Indentation

{{ .Values.resources | toYaml | indent 4 }}

📌 Quoting Strings

env: {{ quote .Values.environment }}

📌 Convert Map to YAML

resources:
{{ .Values.resources | toYaml | indent 2 }}

📌 Sprig Functions

{{ .Values.ips | join ", " }}
{{ "hello" | upper }}
{{ "   my text  " | trim }}

📌 Comments

{{/* This is a Helm comment */}}

📌 Lookup Values from the Cluster

{{ lookup "v1" "Service" "default" "my-service" }}

• Lets use helm playground
• Refer Here for the changes
• Helm chart maintains versions for every upgrade and we can perform rollback
• Exercise: Create a helm chart for the aks-store

aks-store

• Lets deploy aks-store into aks
  
• Refer Here for aks-store application for which we want to build helm chart

lens

• This is a visual kubectl
• Watch classroom recording for usage.