Does garden implement autoscaling for container se...
# 🌱|help-and-getting-started
c
It looks like garden's container module only includes reference to a static number of replicas for services. Are there plans to include some basic horizontal scaling in the template? It would be nice if I didn't have to BYO helm charts.
q
For that you'd need to use either the kubernetes or helm modules. What's annoying about that workflow? Is it just that making K8s manifests are annoying (I understand and sympathize)?
I don't believe there's plans to implement horizontal autoscaling but @curved-intern-91221 or @calm-family-29323 would know better
m
you can and should do this by including your own hpa manifest for the deployment
eg
garden.yaml
Copy code
kind: Module
type: kubernetes
name: one-server
disabled: ${!var.one.enabled}

include:
  - "*"
files: 
  - deployment.yaml
  - service.yaml
  - hpa.yaml
  - ingress.yaml
  - pdb.yaml

variables: 
  tls-suffix: "${var.acme.production ? 'prod' : 'staging'}"
  issuer: "${var.acme.production ? 'letsencrypt-issuer-prod' : 'letsencrypt-issuer-staging'}"
  external-image: "${var.one.server.container.image}:${var.one.server.container.tag}"

serviceResource:
  kind: Deployment
  name: one-server
hpa.yaml
Copy code
${if var.one.server.autoscaling.enabled}
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: one-server
  labels: 
    app.kubernetes.io/name: one-server
    app.kubernetes.io/instance: ${environment.fullName}
    app.kubernetes.io/service: server
    app.kubernetes.io/version: ${var.one.server.container.tag}
    app.kubernetes.io/managed-by: Garden
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: one-server
  minReplicas: ${var.one.server.autoscaling.min}
  maxReplicas: ${var.one.server.autoscaling.max}
  metrics:
    ${if var.one.server.autoscaling.cpu}
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: ${var.one.server.autoscaling.cpu}
    ${endif}
    ${if var.one.server.autoscaling.memory}
    - type: Resource
      resource:
        name: memory
        targetAverageUtilization: ${var.one.server.autoscaling.memory}
    ${endif}
${endif}
c
Thanks for the input and examples, I guess I will go that route. I think it does diminish the value-add of using garden where you get some nice defaults (e.g. the
container
module) over the k8s primitives. For instance, I'm using
tlsCertificates
with my own cert-manager installation. It's nice that the built in container module is probably templating in the correct hostnames and everything for ingress based on the environment. So to add some autoscaling, I now have a lot of surface area to replicate and make sure it's working correctly. I will likely be scanning the garden source to copy/paste the existing templates to the best of my ability. Are the existing templates for
container
easily accessible in the garden repo? Or are they built more programmatically in the JS?
m
if you are using kubernetes you'll want to use the kube module not the container one
q
@chilly-waitress-62592 it's tempting to stick with
container
modules because they are so simple to reason through. As your needs grow we generally advise relegating use of the container module to the role of image-builder then leaning on the
kubernetes
or
helm
modules for the heavy-lifting. After all, Kubernetes is the underlying substrate.
c
Fair enough.
m
HPA also has a lot of parameters to the point that its better to use a manifest to define it rather than feature creeping it into container module
3 Views