<Home>
DocumentationSELF-HOSTED / DEVELOPMENT RELEASEView source ↗
GUIDE 13 / Deploy

Kubernetes patches

Patch the Deployment, Service and Ingress Hakopod generates for a service, behind an installation switch and a protected-field guard.

From alpha.81 a service can carry a YAML patch for the Deployment, Service or Ingress Hakopod generates for it. Use it when no TOML field covers what you need, such as a toleration for a dedicated node pool, an extra probe, or an annotation that HAProxy or a mesh reads.

Patches use the strategic-merge format of kubectl patch. Hakopod builds the object as usual, applies the patch and compares the result. If the patch changes a protected field, the release fails before anything is applied and the error names the field.

Turn it on#

Patches are off until an installation administrator enables them in Settings → Kubernetes patches. A release that adds or changes a patch also needs the kubernetes:patch permission. Installation administrators and project admins have it; the built-in developer and viewer roles do not. A CLI session asks for it with hakopod login --allow-kubernetes-patch, and Git pushes cannot add or change a patch.

Turning the switch off blocks new and changed patches only. Services keep the patches they already have, and removing a patch never needs the switch or the permission.

Example#

[services.api.kubernetes]
deployment = '''
spec:
  template:
    spec:
      tolerations:
        - key: dedicated
          operator: Equal
          value: api
          effect: NoSchedule
'''
ingress = '''
metadata:
  annotations:
    haproxy.org/load-balance: leastconn
'''

The service container is always named app. Each patch is a YAML mapping of at most 16 KiB. A Service patch needs a service with a port, and an Ingress patch needs a public service with a port.

What stays protected#

A patch can add labels and annotations, tolerations, node selector keys, affinity where Hakopod set none, probes, lifecycle hooks, resources for cpu, memory and ephemeral storage, extra environment variables, and emptyDir volumes. It cannot change images, commands, the security context, the service account, host networking or host ports, secret-backed variables, Hakopod's own labels, the Service type, or the Ingress routes and TLS. An Ingress patch may set haproxy.org/ annotations only, and refuses snippets, authentication and certificate references, and settings that change what Hakopod Edge sees.

See the result#

hakopod manifests APP --service api prints the generated objects with the patches applied, without applying anything. Secrets are never shown. The complete rules list every patchable and protected field.