csye7125-fall2023-group05 / k8s-operator Goto Github PK

The controller should monitor only the specific namespace where our CR is running, other namespaces should be ignored.

• Update Cron.Spec to include other parameters from the REST API httpCheck/ endpoint
• Update the controller to watch for changes and update the CronJob based on the custom resource definition.

• Create a defineSecret() function to create a Secret resource based on the CRD
• Reconcile the Secret resource in the controller logic for any changes to it
• #15

• The status & details such as last execution time & status of the CronJob should be added to the CR at each reconciliation.

After the cronjob completes, the pod it creates to run the producer is still present on the cluster, with a status of Complete.
This pod needs to be removed using JobHistoryLimits.

The .spec.successfulJobsHistoryLimit and .spec.failedJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish.

• Set successfulJobHistoryLimit to 0
• Set failedJobHistoryLimit to 0

ref: k8s docs on cronjobs

Dockerize the k8s-operator to be installed on the GKE cluster.

Currently, we are storing the operator docker image in a public dockerhub repository.

• Use quay.io to store the k8s-operator docker image.
• We need pull secrets so that the kubebuilder manager can pull this private image when using make deploy.

Build and push works after we login using quay secrets:

make docker-build docker-push IMG=quay.io/pwncorp/k8s_operator NS=webapp

But when using make deploy, the pod create by kubebuilder fails to pull the secret container image from quay:

make deploy IMG=quay.io/pwncorp/k8s_operator NS=webapp