garden.yml, along with the kubectl context you use to connect to your cluster.
local-kubernetesthis happens automatically when you're deploying or testing, but for remote clusters this requires a manual step. This is so that different users don't end up "competing" with different configurations or versions.
garden-systemnamespace, as well as any installed cluster-scoped resources.
garden dev) using the local Docker mode, images are first built locally and then pushed to the configured deployment registry, where the K8s cluster will then pull the built images when deploying. This should generally be a private container registry, or at least a private project in a public registry.
kubectl create secret docker-registryhelper. You can read more about using and setting up private registries here.
garden.ymlproject config like this:
dockerCLI, so that images can be pushed to the registry. Please refer to your registry's documentation on how to do that (for Docker Hub you simply run
nginx. Alternatively, you can set up your own ingress controller, e.g. using Traefik, Ambassador or Istio. You can find an example for using Garden with Istio in our examples directory.
kubernetesprovider, specifically, it will do the following:
containerservices to 3 (unless specified by the user).
containerdeployments to try to schedule Pods in a single Deployment across many nodes.
securityContextfor Pods (runAsUser: 1000, runAsGroup: 3000, fsGroup: 2000).
RevisionHistoryLimiton workloads to 10.
garden deploy --forcewill propagate the
helm upgrade, and set the
helm installwhen deploying
helmmodules. This may be okay while developing but risky in production, so the
productionflag prevents both of those.