First a couple key points:
Tags are mutable in most registries, so v1 today may be different from v1 a month ago. However clients do need to pull this tag again to see the updates.
Multiple tags may point to the same image. So stable and v1 could point to the same image.
Pointing to a digest ensures the image is immutable, however you will not receive ...
It's really up to your personal preference, but for minikube you can certainly follow the same standards that you would for production.
If your production environment will use some sort of volume mount for your application code, then follow that same workflow for local dev and just have a pod running that mounts to your local code.
If your production ...
What does 'kubectl top node' return for your node usage?
Kubernetes is pretty low overhead and can certainly handle more than 15req/s. Does your application rely on a database? If so, where is that database living? Is that single node also running any other pods?
As others noted, an APM would be a helpful tool to diagnose unexpected performance issues.
If you could let us know what helm chart you have used to install prom-operator, that might help refine the answer.
But in case of kube-prometheus-stack, in the values.yaml of the , use the additionalScrapeConfigs section to describe jobs that are external to k8s system and re-deploy.
Or use serviceMonitors as described in this article
You can use kustomization to run kubectl commands/apply files and can achieve the deployment.
However if you really want to get into the k8s ecosystem you can have look into the various tools available for a more controlled deployment workflow.
Packaging:- Manage/package your k8s objects.E.g Helm,jsonnet
Helm Repository:- Centralised helm chart repository. ...
Docker allows you to pull a cache from anywhere with a --cache-from command. See dockumentation here: https://docs.docker.com/engine/reference/commandline/build/#specifying-external-cache-sources
The easiest approach is to build your images with the --build-arg BUILDKIT_INLINE_CACHE=1 flag which stores the metadata needed to build from cache. You can store ...
The error you are getting is from your Kubernetes cluster being unable to pull container image from GitLab.
Providing a temporary credential to pull the containers as deploy time is not a great solution. For example, say your Kubernetes cluster needs to scale up by adding another node, the node will come up and try and pull the container, but the secret will ...