Notice: this repository is moved to github.com/kedacore/http-add-on. Do not commit here anymore
This project implements a prototype of auto-scaling containers based on HTTP requests. As requests come into the system, the container(s) that are equipped to handle that request may or may not be running and ready to accept it. If there are sufficient containers available, the request is routed to one of them. If there are not, a container is started and the request is routed to it when it's ready, courtesy of KEDA.
To install the application you'll need a Kubernetes Cluster up and running.
You need to install KEDA first. Do so with these commands:
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --n capps --create-namespace
These commands are similar to those on the official install page, but we're installing in a different namespace.
The proxy is responsible for receiving the requests, so you'll need to install it.
helm upgrade --install capps ./charts/cscaler-proxy -n capps --create-namespace
You can use the above command to upgrade your installation as well
After the install, run the following command to fetch the public IP of the proxy service:
kubectl get svc cscaler-proxy -n cscaler -o=jsonpath='{.status.loadBalancer.ingress[*].ip}'
To delete the proxy, but not KEDA, run this:
helm delete -n capps capps
### Build the app
Just simply run ```make cli``` command within the root directory. This will create a new binary file called `capps` in the `bin` directory.
You can then install it into your ```PATH``` or add the ```./bin``` to your ```PATH```, or you can just run it by typing `./bin/capps` (assuming you're on the root).
## CLI API
```shell
./bin/capps
Running with no parameters will give you the general help for the commands
Root Commands:
help
: General help, use it as./bin/capps help <cmd>
to get help on any commandrm
: Removes a created app, has its own set of flagsrun
: Creates a new app, has its own set of flagsversion
: Provides the version name and number
./bin/capps run <app-name> --image <repository>/<image>:<tag> --port <number> --server-url <url>
Runs a new application based on parameters.
Flags
-
-i
,--image
: The image to be downloaded from the repository.Since this command will create a new set of workloads, all the logged Docker repositories within the current cluster will work
-
-s
,--server-url
: (Required) The URL for the admin server. To get this, runkubectl get svc cscaler-proxy -n cscaler -o=jsonpath="{.status.loadBalancer.ingress[*].ip}"
Without the correct admin url the scaler will not work
-
-p
,--port
: Port number to be exposed, should be the port where the app listens to incoming connections. -
--use-http
: When set, the server URL will use theHTTP
protocol instead ofHTTPS
(default: false)
./bin/capps rm <app-name> --server-url <url>
Removes a previously created app
-
-s
,--server-url
: (Required) The URL for the admin server. To get this, runkubectl get svc cscaler-proxy -n cscaler -o=jsonpath="{.status.loadBalancer.ingress[*].ip}"
Without the correct admin url the scaler will not work
-
--use-http
: When set, the server URL will use theHTTP
protocol instead ofHTTPS
(default: false)
Once deployed with capps run
you'll be able to access the application through the proxy IP.
However, the proxy only understands DNS hostnames, which means that, if your service is called foo
, you'll have to access it through a DNS name like foo.domain.com
and this DNS Zone needs to have an A
record with the name foo
pointing to the proxy IP. This is an implementation of an automatic ingress rule.
You can either use your own domain or an Azure provided one.
Important: If you could not access the endpoint and it didn't work, probably you didn't have HTTPS enabled, try to use the
--use-http
flag to test again
- Go to your DNS zone settings in your domain registrar
- Add a new
A
record with the same name as your service – it should point to<service>.yourdomain.com
- Point this DNS record to the proxy IP
- Give it some minutes or check dnschecker.org for the propagation
- Access the domain
You can check the logs on kubectl logs deploy/cscaler-proxy -f -n cscaler
to check for incoming requests
- If your cluster is not created in Azure, check the "Enable HTTP Application Routing Addon" box when creating it
- If your cluster already exists, run
az aks enable-addons -n <cluster-name> -g <resource-group-name> --addons http_application_routing
- Once the execution is complete, open the Azure Portal, navigate to the resource group named
MC_<group-name>_<cluster-name>_<location>
- Find the Azure DNS zone the Addon created for you
- Follow steps 2 to 4 from the previous section
- Access the service using
<service-name>.<dns-zone-name>
You can check the logs on kubectl logs deploy/cscaler-proxy -f -n cscaler
to check for incoming requests
If you are using vscode you can open up the dev environment in container using the remote container extension the nats server will be avalible in the dev container via nats-server:4222
If you need to do any DNS work from inside a container that's running Alpine linux, use this command:
curl -L https://github.com/sequenceiq/docker-alpine-dig/releases/download/v9.10.2/dig.tgz|tar -xzv -C /usr/local/bin/
Courtesy https://github.com/sequenceiq/docker-alpine-dig
See this document for details on the components of this system.