cp -v .env.sample .env
bash scripts/set-aws-vars.sh
kubectl apply -f prod/aws
docker run -e AZP_URL=https://dev.azure.com/<NAME> \
-e AZP_TOKEN=<YOUR_PAT_TOKEN> \
-e AZP_POOL=linux-containers-aks \
docker.io/<REPO>/az-agent:ubuntu-22.04
podman run -e AZP_URL=https://dev.azure.com/<NAME> \
-e AZP_TOKEN=<YOUR_PAT_TOKEN> \
-e AZP_POOL=linux-containers-aks \
docker.io/<REPO>/az-agent:ubuntu-22.04
Check if azure-agent working
kubectl -n keda logs pod/keda-operator-<HASH>
docker build --no-cache --tag az-agent:ubuntu-22.04 -f container/Dockerfile.amd64 container/
podman build --no-cache --tag az-agent:ubuntu-22.04 -f container/Dockerfile.amd64 container/
KEDA acts like a "Custom Metrics API" for exposing metrics to the HPA. KEDA can't do its job without the HPA.
The complexity of developing a metrics server is abstracted away by using KEDA.
Scalers are the glue that provides the metrics from various sources to the HPA.
Here's a list of some of the most widely used scalers:
For a complete list view the scalers section on the KEDA site.
A common question is when should one use a HPA and when to enlist KEDA. If the workload is memory or cpu intensive, and has a well defined metric that can be measured then using a HPA is sufficient.
When dealing with a workload that is event driven or relies upon a custom metric, then using KEDA should be the first choice.
This work is licensed under the GNU GPLv3+
Content type
Image
Digest
sha256:6ac30b719…
Size
482.2 MB
Last updated
over 2 years ago
docker pull rusian/az-agent