Output rendered k8s manifest

.github/workflows/dev_dispatch.yml

@@ -76,3 +76,11 @@ jobs:
         uses: docker://ghcr.io/yannh/kubeconform:latest
         with:
           args: "-strict -ignore-missing-schemas ops/deploy.yaml ops/service.yaml"
+
+      - name: Upload rendered manifests as build artifacts
+        uses: actions/upload-artifact@v4
+        with:
+          name: k8s-manifests-${{ github.event.inputs.name }}
+          path: |
+            ops/deploy.yaml
+            ops/service.yaml

README.md

@@ -19,16 +19,16 @@ This image uses the following on base ubuntu22.04:
 - Python 3.10
 
 ## User Story / Implementation Notes
-###Why am I using ubuntu22.04 and not a multi-stage build?
+### Why am I using ubuntu22.04 and not a multi-stage build?
 
  Still LTS and supports python2 + python3. You could definitely do a multi-stage build but for the sake of having something to talk about, I wanted to talk about how this could be improved on.
 
 
-Right now with no cache, the image builds locally in about 35s according to docker buildkit. Obviously, if I was not using shared git runners and was in enterprise Github Org - the runners may indeed be much faster using self-hosted runners. 
+Right now with no cache, the image builds locally in about 35s according to docker buildkit. Obviously, if I was not using shared git runners and was in enterprise Github Org - the runners may indeed be much faster using self-hosted runners.
 
 I generally find myself leaning on the Actions Runner controller [helm chart](https://artifacthub.io/packages/helm/actions-runner-controller/actions-runner-controller "helm chart") for increased build times on the dedicated runners in the Action itself.
 
-At some level with this challenge, there is a few limitations not having access to - 
+At some level with this challenge, there is a few limitations not having access to -
 - A real production grade k8s cluster
 - Enterprise Github Org(Github Security SARIF report posting only works in Enterprise Orgs within private repos).  It'd be nice to use Trivy to post to this.
 - Some kind of ALB, ingress route setup,etc publicly exposable endpoint for the Service that goes to the Deploy. (the challenge specifically asked for me to touch on this).
@@ -37,9 +37,10 @@ At some level with this challenge, there is a few limitations not having access
 
 
 ## Minikube setup
-**This can be run locally with minikube for testing purposes, and to verify the k8s comptability and run forever pod. Had to do it from minikube for this demo,imo**. 
+**This can be run locally with minikube for testing purposes, and to verify the k8s comptability and run forever pod. Had to do it from minikube for this demo,imo**.
 
 - Please follow the  approrpirate minikube install for your OS from [the official source](https://minikube.sigs.k8s.io/docs/start/)
+- Enable metrics-server via `minikube addons enable metrics-server`
 - Load the image with `minikube image load sadminriley/python-test`
 - Verify you've loaded the image locally if needed with the following cmds:
 ```
@@ -63,4 +64,13 @@ service/python-swish-r-deploy exposed
 Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...`
 
 
+### HPA
+HPA works alongside *metrics-server* as usual with minikube,however obviously I cannot really demo it with a real k8s workload.
+```
+kubectl get hpa                                                                      [10:56:26]
+NAME                 REFERENCE                          TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
+python-swish-r-hpa   Deployment/python-swish-r-deploy   cpu: 2%/50%   1         3         1          67m
+```
+
+
 

ops/hpa.tpl.yaml

@@ -0,0 +1,20 @@
+apiVersion: autoscaling/v2
+kind: HorizontalPodAutoscaler
+metadata:
+  name: ${HPA_NAME}
+  labels:
+    app: ${APP_NAME}
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: ${DEPLOYMENT_NAME}
+  minReplicas: ${HPA_MIN_REPLICAS}
+  maxReplicas: ${HPA_MAX_REPLICAS}
+  metrics:
+    - type: Resource
+      resource:
+        name: cpu
+        target:
+          type: Utilization
+          averageUtilization: ${HPA_CPU_TARGET}

ops/hpa.yaml

@@ -0,0 +1,18 @@
+apiVersion: autoscaling/v2
+kind: HorizontalPodAutoscaler
+metadata:
+  name: python-swish-r-hpa
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: python-swish-r-deploy
+  minReplicas: 1
+  maxReplicas: 3
+  metrics:
+  - type: Resource
+    resource:
+      name: cpu
+      target:
+        type: Utilization
+        averageUtilization: 50