Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat: explain remote zilla config property #262

Merged
merged 2 commits into from
Oct 3, 2024
Merged

feat: explain remote zilla config property #262

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e69f098
feat: explain remote zilla config property
vordimous Oct 2, 2024
2792c87
feat: use the -c flag instead of the zilla property
vordimous Oct 3, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions src/how-tos/deploy-operate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -176,6 +176,14 @@ Errors and misconfigured parts of the `zilla.yaml` file are detected by Zilla an

This feature is demonstrated in the above Helm install command. Running a `helm update ...` with changes to the `zilla.yaml`, k8s will update the config map, which writes the new content into the running pods. Zilla will detect those file changes and load the new config.

Zilla can load the `zilla.yaml` config from a remote source using the `zilla.engine.config.url` [Zilla property](../reference/config/zilla-cli.md#p-property). The auto reconfigure feature will still work when pulling the config remotely.

The Zilla start command looks like this:

```bash:no-line-numbers
zilla start -P zilla.engine.config.url=http://example.com/zilla.yaml
```

vordimous marked this conversation as resolved.
Show resolved Hide resolved
## Auto Scaling

Zilla will start workers that default to the CPU cores it is allowed to use. This makes horizontal scaling easy with a 1:1 ratio of instances to workers. Any of the default scaling metrics based on server CPU usage will enable Zilla to handle traffic spikes. Additionally, Zilla [Telemetry](../reference/config/overview.md#telemetry) configuration provides more data when determining how to scale. The [Prometheus autoscale example](https://github.com/aklivity/zilla-examples/tree/main/kubernetes.prometheus.autoscale) demonstrates using metrics from the [Prometheus exporter](../reference/config/telemetry/exporters/prometheus.md) to horizontally scale Zilla on k8s.
Expand Down
Loading