k8s-scale-app-rs: Scale or Restart a Kubernetes Deployment from a CronJob

2026-07-06T00:00:00+00:00

restart</code></strong> — patches the pod template’s restartedAt</code> annotation, which is the same mechanism kubectl rollout restart</code> uses.</li> </ul> Designed to run as a CronJob</code>. Version 1.0.0 is published; container images and the Helm chart are on ghcr.io</code>, signed with cosign (keyless via GitHub OIDC), and shipped with an SPDX SBOM plus SLSA build provenance.</p>

Why I built it🔗</a></h2>
The classic way to “run kubectl scale</code> on a schedule in a cluster” is to put a kubectl</code> binary into a Job image. That works, but it drags in a few things I did not want:</p>

The full kubectl</code> binary (about 50 MB stripped) for one API call.</li>
A kubeconfig / ServiceAccount plumbing that is broader than the one operation actually needs.</li>
Enough YAML around the pod spec to hide the actual behavior behind a template.</li>
</ul>
A purpose-built tool is a natural fit for Rust here: a single self-contained binary — no OpenSSL, no runtime dependency beyond glibc and the CA trust store — and a ServiceAccount that only needs deployments/scale: patch</code>. That is what k8s-scale-app-rs is.</p>
KEDA and Argo Workflows solve a related but different problem — reacting to events or orchestrating multi-step pipelines — not “flip a replica count or a restart annotation on a fixed schedule.” KEDA in particular has its own well-known scale-from-zero gap: a Prometheus-metric trigger can scale 1→N but not 0→1, because a Deployment at zero replicas emits no metric to react to (see the LLM inference series</a> for the concrete failure mode). None of that machinery applies here — a CronJob calling a purpose-built binary on a fixed schedule has nothing to react to.</p>
The same binary also covers restart. kubectl rollout restart deployment/foo</code> under the hood is one patch on spec.template.metadata.annotations["kubectl.kubernetes.io/restartedAt"]</code>. Two subcommands, same binary, same image.</p>
What it does🔗</a></h2>
The CLI is two subcommands sharing common arguments:</p>
k8s-scale-app-rs scale   --deployment <NAME> --replicas <N> [--dry-run] [--extra-ca-bundle <PATH>]</span></span>
k8s-scale-app-rs restart --deployment <NAME>                [--dry-run] [--extra-ca-bundle <PATH>]</span></span></code></pre>
Configuration is via environment variables, overridable by CLI flags:</p>
Flag</th> ENV</th> Subcommands</th></tr></thead>

--deployment</code></td> K8S_SCALE_DEPLOYMENT</code></td> both</td></tr>
--namespace</code></td> K8S_SCALE_NAMESPACE</code></td> both</td></tr>
--replicas</code></td> K8S_SCALE_REPLICAS</code></td> scale</td></tr>
--dry-run</code></td> K8S_SCALE_DRY_RUN</code></td> both</td></tr>
--extra-ca-bundle</code></td> K8S_SCALE_EXTRA_CA_BUNDLE</code></td> both</td></tr>
</tbody></table>
The --namespace</code> flag exists, but the CronJob does not hardcode it. Instead, the pod reads its own namespace from the Downward API and passes it through as an environment variable. That keeps the ServiceAccount’s Role safely namespace-scoped: the tool can only ever act on Deployments in the namespace where the CronJob itself runs. Not a general-purpose “scale anything anywhere” tool.</p>
Design highlights🔗</a></h2>
Minimal RBAC via the scale</code> subresource🔗</a></h3>
Setting replicas does not need patch</code> on the full Deployment. Kubernetes exposes deployments/scale</code> as a dedicated subresource:</p>
r</span>ules</span>:</span></span>
  -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span>
    r</span>esources</span>:</span> [</span>"</span>deployments/scale</span>"</span>]</span></span>
    v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>,</span> "</span>update</span>"</span>]</span></span></code></pre>
That is all the scale mode needs. Restart mode does need patch</code> on deployments</code> itself (to update the pod template annotation), so the shipped Role covers both:</p>
  -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span>
    r</span>esources</span>:</span> [</span>"</span>deployments</span>"</span>]</span></span>
    v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>]</span></span></code></pre>
patch</code> on the full Deployment is broader than patch</code> on deployments/scale</code> — RBAC review at deploy time should factor that in when the CronJob is configured for restart mode.</p>
Extra-CA bundle merged into the trust store🔗</a></h3>
The kube client uses the in-cluster CA from the ServiceAccount token secret automatically. For clusters whose API server certificate is signed by a corporate CA that is not in the SA-mounted ca.crt</code>, --extra-ca-bundle <path></code> reads a PEM file (or a full chain of them) and appends every CERTIFICATE</code> block to kube::Config.root_cert</code>. Non-certificate blocks in the file are filtered out.</p>
Rendered in Helm as an optional ConfigMap mount; in Kustomize as an opt-in Component. Neither path forces the mount when there is no corporate CA to add.</p>
The rustls 0.23 CryptoProvider gotcha🔗</a></h3>
If you build against kube-rs</code> with the rustls-tls</code> feature on the current release, the binary compiles cleanly — and then panics at the first TLS handshake with:</p>
Could not automatically determine the process-level CryptoProvider from Rustls crate features</span></span></code></pre>
rustls</code> 0.23 no longer picks a crypto backend based on downstream feature flags. The application itself must call rustls::crypto::ring::default_provider().install_default()</code> before any TLS work happens. In k8s-scale-app-rs this runs as the first step in main()</code>.</p>
Two notes for anyone hitting the same wall: the panic never fires at compile time, and no test caught it locally because integration tests without a cluster do not open a TLS connection. It only surfaces when the CronJob actually tries to reach the API server.</p>
Two deploy paths, independent🔗</a></h3>
Helm and Kustomize both ship in the repo, and either can be used on its own:</p>

Helm chart</strong> with values-{dev,preprod,prod}.yaml</code>, a mode: scale | restart</code> toggle that swaps the subcommand argument and drops the unused replicas env, and serviceAccount.create</code> / rbac.create</code> / extraCA.enabled</code> toggles for the pieces that a given cluster may or may not need.</li>
Kustomize</strong> with a base that has only the CronJob, plus three opt-in Components (serviceaccount/</code>, rbac/</code>, extra-ca/</code>) that overlays include as needed. Overlays under overlays/{dev,preprod,prod}/</code> set namespace and image tag and a patch that touches only the fields that vary per stage.</li>
</ul>
No Helm-inside-Kustomize glue, no Kustomize-on-Helm-render. Whichever tool matches an existing pipeline is the one to use.</p>
Two container images🔗</a></h2>
The default image and a -debug</code> variant, both built in the same GitHub Actions matrix — the
production/-debug</code> split itself is a general pattern, covered in more depth in
Part 2 of the K8s/OpenShift Best Practices series</a>:</p>
File</th> Base</th> Contents</th> Approx. size</th></tr></thead>

Containerfile</code></td> registry.access.redhat.com/ubi10/ubi-micro</code></td> Binary + CA trust store + /licenses/</code>, no package manager</td> ≈35 MB</td></tr>
Containerfile.debug</code></td> registry.access.redhat.com/ubi10/ubi-minimal</code></td> Everything above + bash</code>, curl</code>, bind-utils</code> (dig</code>)</td> ≈115 MB</td></tr>
</tbody></table>
ubi10-micro</code> is not fully distroless in the Google sense — bash and coreutils are still there — but it has no package manager and no network tools, which fits the pod’s actual operational surface for a scheduled scale or restart call. The -debug</code> variant exists for the day a pod loops in ImagePullBackOff</code> or a network policy silently drops the API-server traffic and someone needs to kubectl exec</code> in with tools to check.</p>
Why UBI10🔗</a></h3>
The base itself, not just the two variants built from it, was a deliberate choice. I went with
Red Hat’s UBI over an Alpine or a generic Docker Hub base image for one reason: it gives the
image a level of maintenance stability I don’t have to police myself — CVE scanning and rebuilds
are Red Hat’s job, not something I track on my own. That comes with a tradeoff worth stating
plainly: UBI is not “digitally sovereign” in the sense the upcoming Digital Sovereignty in
Practice series covers — it is a US vendor’s supply chain, the same as pulling from Docker Hub
or almost any other public registry would be. I did not find a base that solved that concern
without giving up the maintenance guarantees I wanted, so UBI10 here is a compromise I made
deliberately, not a claim that the underlying problem is solved.</p>
Both images ship an aggregated /licenses/LICENSES.txt</code> bundled with cargo-about</code> during the container build, generated from a whitelist of accepted SPDX identifiers. A new dependency that pulls in an unfamiliar license fails the container build on purpose.</p>
Supply chain🔗</a></h2>
The build-publish workflow</a> runs three jobs on every push, plus a release job on tag pushes:</p>

test</code></strong> — cargo fmt --check</code>, cargo clippy -D warnings</code>, cargo test --release</code>. Cluster tests auto-skip in CI (no KUBECONFIG</code>, no in-cluster SA token).</li>
build-image</code></strong> — matrix over Containerfile</code> and Containerfile.debug</code>. Each variant is built with buildx, pushed to ghcr.io/git001/k8s-scale-app-rs</code>, smoke-tested (--version</code>, scale --help</code>, restart --help</code>), then:

signed with cosign keyless</strong> via the GitHub OIDC token (no key management — Fulcio issues a short-lived certificate, the signature is logged to Rekor);</li>
has an SPDX-JSON SBOM</strong> generated with syft and attached via cosign attest --type spdxjson</code>;</li>
has SLSA build provenance</strong> pushed with actions/attest-build-provenance</code>.</li>
</ul>
</li>
publish-chart</code></strong> — helm lint</code> and helm package</code> on every push; OCI push to oci://ghcr.io/git001/charts/k8s-scale-app-rs</code>, plus cosign sign and SLSA provenance only on tag events (avoids overwrite conflicts on GHCR-immutable tags).</li>
release</code></strong> (tag events only) — creates the GitHub Release with auto-generated notes from commits since the previous tag, attaches the packaged chart .tgz</code> as an asset, and prepends the release body with pull and verify snippets.</li>
</ol>
All of that runs with permissions: contents:read, packages:write, id-token:write, attestations:write</code> — the minimum needed for OIDC-based signing plus attestation upload.</p>
Verifying a published image🔗</a></h2>
A consumer that wants to check what came out of that pipeline needs cosign v2:</p>
IMG</span>=</span>g</span>h</span>c</span>r</span>.</span>i</span>o</span>/</span>g</span>i</span>t</span>0</span>0</span>1</span>/</span>k</span>8</span>s</span>-</span>s</span>c</span>a</span>l</span>e</span>-</span>a</span>p</span>p</span>-</span>r</span>s</span>:</span>v</span>1</span>.</span>0</span>.</span>0</span></span>
IDENTITY</span>=</span>'</span>^https://github.com/git001/k8s-scale-app-rs/</span>'</span></span>
ISSUER</span>=</span>h</span>t</span>t</span>p</span>s</span>:</span>/</span>/</span>t</span>o</span>k</span>e</span>n</span>.</span>a</span>c</span>t</span>i</span>o</span>n</span>s</span>.</span>g</span>i</span>t</span>h</span>u</span>b</span>u</span>s</span>e</span>r</span>c</span>o</span>n</span>t</span>e</span>n</span>t</span>.</span>c</span>o</span>m</span></span>
</span>
cosign</span> verify</span> \</span></span>
  -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span>
  -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span>
  "</span>$</span>IMG</span>"</span></span>
</span>
cosign</span> verify-attestation</span> -</span>-type</span> spdxjson</span> \</span></span>
  -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span>
  -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span>
  "</span>$</span>IMG</span>"</span></span>
</span>
cosign</span> verify-attestation</span> -</span>-type</span> slsaprovenance</span> \</span></span>
  -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span>
  -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span>
  "</span>$</span>IMG</span>"</span></span></code></pre>
For enforcement inside the cluster, a cosign-aware admission controller — Kyverno</a>, Sigstore policy-controller</a>, or Connaisseur</a> — can turn the signature into a hard gate that rejects any pod trying to pull an image that was not produced by exactly this workflow. That is a separate deployment concern; the tool repo does not ship the policy itself.</p>
Mirroring the image into another registry🔗</a></h2>
Verifying a signature only works if the signature actually travels with the image. Not every docker pull && docker push</code>-style mirroring tool preserves it — some tools do, some quietly drop it, and one (oc-mirror v2</code>) solves a related but entirely different signature problem. I wrote up a full, sourced comparison — Which Tool Mirrors a Cosign-Signed Image into a Private Registry?</a> — with regctl</code> coming out as the most complete option for this specific image.</p>
Code and repository🔗</a></h2>

Repository: k8s-scale-app-rs on GitHub</a></li>
Container images: ghcr.io/git001/k8s-scale-app-rs:v1.0.0</code> and ghcr.io/git001/k8s-scale-app-rs:v1.0.0-debug</code></li>
Helm chart: oci://ghcr.io/git001/charts/k8s-scale-app-rs:1.0.0</code></li>
</ul>
Feedback and PRs welcome.</p>

Flag</th>	ENV</th>	Subcommands</th></tr></thead>
`--deployment</code></td>`	`K8S_SCALE_DEPLOYMENT</code></td>`	both</td></tr>
`--namespace</code></td>`	`K8S_SCALE_NAMESPACE</code></td>`	both</td></tr>
`--replicas</code></td>`	`K8S_SCALE_REPLICAS</code></td>`	scale</td></tr>
`--dry-run</code></td>`	`K8S_SCALE_DRY_RUN</code></td>`	both</td></tr>
`--extra-ca-bundle</code></td>`	`K8S_SCALE_EXTRA_CA_BUNDLE</code></td>`	both</td></tr> </tbody></table> The `--namespace</code> flag exists, but the CronJob does not hardcode it. Instead, the pod reads its own namespace from the Downward API and passes it through as an environment variable. That keeps the ServiceAccount’s Role safely namespace-scoped: the tool can only ever act on Deployments in the namespace where the CronJob itself runs. Not a general-purpose “scale anything anywhere” tool.</p>` Design highlights🔗</a></h2> Minimal RBAC via the scale</code> subresource🔗</a></h3> Setting replicas does not need patch</code> on the full Deployment. Kubernetes exposes deployments/scale</code> as a dedicated subresource:</p> r</span>ules</span>:</span></span> -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span> r</span>esources</span>:</span> [</span>"</span>deployments/scale</span>"</span>]</span></span> v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>,</span> "</span>update</span>"</span>]</span></span></code></pre> That is all the scale mode needs. Restart mode does need patch</code> on deployments</code> itself (to update the pod template annotation), so the shipped Role covers both:</p> -</span> a</span>piGroups</span>:</span> [</span>"</span>apps</span>"</span>]</span></span> r</span>esources</span>:</span> [</span>"</span>deployments</span>"</span>]</span></span> v</span>erbs</span>:</span> [</span>"</span>get</span>"</span>,</span> "</span>patch</span>"</span>]</span></span></code></pre> patch</code> on the full Deployment is broader than patch</code> on deployments/scale</code> — RBAC review at deploy time should factor that in when the CronJob is configured for restart mode.</p> Extra-CA bundle merged into the trust store🔗</a></h3> The kube client uses the in-cluster CA from the ServiceAccount token secret automatically. For clusters whose API server certificate is signed by a corporate CA that is not in the SA-mounted ca.crt</code>, --extra-ca-bundle <path></code> reads a PEM file (or a full chain of them) and appends every CERTIFICATE</code> block to kube::Config.root_cert</code>. Non-certificate blocks in the file are filtered out.</p> Rendered in Helm as an optional ConfigMap mount; in Kustomize as an opt-in Component. Neither path forces the mount when there is no corporate CA to add.</p> The rustls 0.23 CryptoProvider gotcha🔗</a></h3> If you build against kube-rs</code> with the rustls-tls</code> feature on the current release, the binary compiles cleanly — and then panics at the first TLS handshake with:</p> Could not automatically determine the process-level CryptoProvider from Rustls crate features</span></span></code></pre> rustls</code> 0.23 no longer picks a crypto backend based on downstream feature flags. The application itself must call rustls::crypto::ring::default_provider().install_default()</code> before any TLS work happens. In k8s-scale-app-rs this runs as the first step in main()</code>.</p> Two notes for anyone hitting the same wall: the panic never fires at compile time, and no test caught it locally because integration tests without a cluster do not open a TLS connection. It only surfaces when the CronJob actually tries to reach the API server.</p> Two deploy paths, independent🔗</a></h3> Helm and Kustomize both ship in the repo, and either can be used on its own:</p> Helm chart</strong> with values-{dev,preprod,prod}.yaml</code>, a mode: scale \| restart</code> toggle that swaps the subcommand argument and drops the unused replicas env, and serviceAccount.create</code> / rbac.create</code> / extraCA.enabled</code> toggles for the pieces that a given cluster may or may not need.</li> Kustomize</strong> with a base that has only the CronJob, plus three opt-in Components (serviceaccount/</code>, rbac/</code>, extra-ca/</code>) that overlays include as needed. Overlays under overlays/{dev,preprod,prod}/</code> set namespace and image tag and a patch that touches only the fields that vary per stage.</li> </ul> No Helm-inside-Kustomize glue, no Kustomize-on-Helm-render. Whichever tool matches an existing pipeline is the one to use.</p> Two container images🔗</a></h2> The default image and a -debug</code> variant, both built in the same GitHub Actions matrix — the production/-debug</code> split itself is a general pattern, covered in more depth in Part 2 of the K8s/OpenShift Best Practices series</a>:</p> File</th> Base</th> Contents</th> Approx. size</th></tr></thead> Containerfile</code></td> registry.access.redhat.com/ubi10/ubi-micro</code></td> Binary + CA trust store + /licenses/</code>, no package manager</td> ≈35 MB</td></tr> Containerfile.debug</code></td> registry.access.redhat.com/ubi10/ubi-minimal</code></td> Everything above + bash</code>, curl</code>, bind-utils</code> (dig</code>)</td> ≈115 MB</td></tr> </tbody></table> ubi10-micro</code> is not fully distroless in the Google sense — bash and coreutils are still there — but it has no package manager and no network tools, which fits the pod’s actual operational surface for a scheduled scale or restart call. The -debug</code> variant exists for the day a pod loops in ImagePullBackOff</code> or a network policy silently drops the API-server traffic and someone needs to kubectl exec</code> in with tools to check.</p> Why UBI10🔗</a></h3> The base itself, not just the two variants built from it, was a deliberate choice. I went with Red Hat’s UBI over an Alpine or a generic Docker Hub base image for one reason: it gives the image a level of maintenance stability I don’t have to police myself — CVE scanning and rebuilds are Red Hat’s job, not something I track on my own. That comes with a tradeoff worth stating plainly: UBI is not “digitally sovereign” in the sense the upcoming Digital Sovereignty in Practice series covers — it is a US vendor’s supply chain, the same as pulling from Docker Hub or almost any other public registry would be. I did not find a base that solved that concern without giving up the maintenance guarantees I wanted, so UBI10 here is a compromise I made deliberately, not a claim that the underlying problem is solved.</p> Both images ship an aggregated /licenses/LICENSES.txt</code> bundled with cargo-about</code> during the container build, generated from a whitelist of accepted SPDX identifiers. A new dependency that pulls in an unfamiliar license fails the container build on purpose.</p> Supply chain🔗</a></h2> The build-publish workflow</a> runs three jobs on every push, plus a release job on tag pushes:</p> test</code></strong> — cargo fmt --check</code>, cargo clippy -D warnings</code>, cargo test --release</code>. Cluster tests auto-skip in CI (no KUBECONFIG</code>, no in-cluster SA token).</li> build-image</code></strong> — matrix over Containerfile</code> and Containerfile.debug</code>. Each variant is built with buildx, pushed to ghcr.io/git001/k8s-scale-app-rs</code>, smoke-tested (--version</code>, scale --help</code>, restart --help</code>), then: signed with cosign keyless</strong> via the GitHub OIDC token (no key management — Fulcio issues a short-lived certificate, the signature is logged to Rekor);</li> has an SPDX-JSON SBOM</strong> generated with syft and attached via cosign attest --type spdxjson</code>;</li> has SLSA build provenance</strong> pushed with actions/attest-build-provenance</code>.</li> </ul> </li> publish-chart</code></strong> — helm lint</code> and helm package</code> on every push; OCI push to oci://ghcr.io/git001/charts/k8s-scale-app-rs</code>, plus cosign sign and SLSA provenance only on tag events (avoids overwrite conflicts on GHCR-immutable tags).</li> release</code></strong> (tag events only) — creates the GitHub Release with auto-generated notes from commits since the previous tag, attaches the packaged chart .tgz</code> as an asset, and prepends the release body with pull and verify snippets.</li> </ol> All of that runs with permissions: contents:read, packages:write, id-token:write, attestations:write</code> — the minimum needed for OIDC-based signing plus attestation upload.</p> Verifying a published image🔗</a></h2> A consumer that wants to check what came out of that pipeline needs cosign v2:</p> IMG</span>=</span>g</span>h</span>c</span>r</span>.</span>i</span>o</span>/</span>g</span>i</span>t</span>0</span>0</span>1</span>/</span>k</span>8</span>s</span>-</span>s</span>c</span>a</span>l</span>e</span>-</span>a</span>p</span>p</span>-</span>r</span>s</span>:</span>v</span>1</span>.</span>0</span>.</span>0</span></span> IDENTITY</span>=</span>'</span>^https://github.com/git001/k8s-scale-app-rs/</span>'</span></span> ISSUER</span>=</span>h</span>t</span>t</span>p</span>s</span>:</span>/</span>/</span>t</span>o</span>k</span>e</span>n</span>.</span>a</span>c</span>t</span>i</span>o</span>n</span>s</span>.</span>g</span>i</span>t</span>h</span>u</span>b</span>u</span>s</span>e</span>r</span>c</span>o</span>n</span>t</span>e</span>n</span>t</span>.</span>c</span>o</span>m</span></span> </span> cosign</span> verify</span> \</span></span> -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span> -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span> "</span>$</span>IMG</span>"</span></span> </span> cosign</span> verify-attestation</span> -</span>-type</span> spdxjson</span> \</span></span> -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span> -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span> "</span>$</span>IMG</span>"</span></span> </span> cosign</span> verify-attestation</span> -</span>-type</span> slsaprovenance</span> \</span></span> -</span>-certificate-identity-regexp</span> "</span>$</span>IDENTITY</span>"</span> \</span></span> -</span>-certificate-oidc-issuer</span> "</span>$</span>ISSUER</span>"</span> \</span></span> "</span>$</span>IMG</span>"</span></span></code></pre> For enforcement inside the cluster, a cosign-aware admission controller — Kyverno</a>, Sigstore policy-controller</a>, or Connaisseur</a> — can turn the signature into a hard gate that rejects any pod trying to pull an image that was not produced by exactly this workflow. That is a separate deployment concern; the tool repo does not ship the policy itself.</p> Mirroring the image into another registry🔗</a></h2> Verifying a signature only works if the signature actually travels with the image. Not every docker pull && docker push</code>-style mirroring tool preserves it — some tools do, some quietly drop it, and one (oc-mirror v2</code>) solves a related but entirely different signature problem. I wrote up a full, sourced comparison — Which Tool Mirrors a Cosign-Signed Image into a Private Registry?</a> — with regctl</code> coming out as the most complete option for this specific image.</p> Code and repository🔗</a></h2> Repository: k8s-scale-app-rs on GitHub</a></li> Container images: ghcr.io/git001/k8s-scale-app-rs:v1.0.0</code> and ghcr.io/git001/k8s-scale-app-rs:v1.0.0-debug</code></li> Helm chart: oci://ghcr.io/git001/charts/k8s-scale-app-rs:1.0.0</code></li> </ul> Feedback and PRs welcome.</p>

Alek's Blog - sbom

k8s-scale-app-rs: Scale or Restart a Kubernetes Deployment from a CronJob