Connecting a local application to a Kubernetes cluster (Local Mode)
Last updated
Was this helpful?
Last updated
Was this helpful?
Local app - a locally running application that can be used instead of a Deploy
action with a local mode configuration.
Target kubernetes workload - a produced from a Deploy
action with a local mode configuration that's deployed to the target kubernetes cluster.
This feature is still experimental. We're still working on some open tasks to improve the feature stability and usability. It means that:
some incompatible changes can be made until the first non-experimental release
there are some functional limitations, see the Current limitations section below
A local application can be used instead of a kubernetes workload by adding a local mode configuration to the Deploy action
Local mode feature is only supported by certain action types and providers.
Local mode uses kubectl
port-forwarding and plain SSH port forwarding under the hood.
Requirements for the local machine environment:
OpenSSH 7.6 or higher
Kubectl
There is a number of functional limitations in the current version.
The best matching use-case for local mode is to locally run an "isolated" application, i.e. an application that does not make any calls to other resources in the kubernetes cluster (i.e. databases or other applications).
If your application makes HTTP calls to some other kubernetes resources using kubernetes DNS names, then such calls will fail because the local DNS configuration is not aware about any DNS names configured in the kubernetes cluster.
A Deploy
action cannot be running in local and sync modes simultaneously. Local mode always takes precedence over sync mode if both are configured in the relevant garden.yml
configuration file and if both --local
and --sync
flags are enabled.
The local mode is not supported natively for Windows OS. It should be used with WSL in Windows environments.
The local mode leaves the proxy container deployed in the target kubernetes cluster after exit. The affected Deploy
s must be re-deployed manually by using garden deploy
.
Usually, a Garden Deploy
action declares a configuration and a deployment policy of a kubernetes workload. A typical deployment flow looks like this:
build a container image if necessary
configure a docker container for the image
prepare kubernetes workloads to be deployed
deploy the configured kubernetes workloads to the target kubernetes cluster
The local mode changes the usual deployment flow by changing the manifest configuration step (item 3 from the list above) and the deployment step (item 4).
Local mode does the following modifications in the target kubernetes workload configuration before the actual deployment:
Sets the number of replicas of the target kubernetes workload is always set to 1
.
Disables the basic health-checks (startup, readiness and liveness probes). See the section below for details.
The startup, readiness and liveness probes are disabled for all Deploy
axtions running in local mode. This has been done because of some technical reasons.
The lifecycle of a local app can be completely controlled by a user. Thus, the health checks may be unwanted and obstructing.
The kubernetes cluster readiness checks are applied to a proxy container which sends the traffic to the local app. When a readiness probe happens, the target local app and the relevant port forward are not ready yet. Thus, the readiness probe can cause the failure of the local mode startup.
The liveness checks can cause unnecessary re-deployment of the proxy container in the target cluster. Also, those checks create some extra traffic to the local app. That might be noisy and unnecessary if the local app is running in the debugger.
Once the kubernetes workloads are configured, local mode executes the deployment step in a specific way:
The local app is started by Garden if localMode.command
field is specified in the Deploy
action configuration. Otherwise, the local app should be started manually.
The SSH port forwarding from a randomly assigned local port to the proxy container SSH port is initialized by means of kubectl port-forward
command.
The reverse port forwarding (on top of the previous SSH port forwarding) between the remote proxy container's HTTP port and the local application HTTP port is established by means of ssh
command.
As a result, the original target kubernetes workload is replaced by a workload that runs a proxy container, let's call it a proxy-workload. The proxy-workload is connected with the local app via the 2-layered port-forwarding described above. This connection schema allows to route the target kubernetes workload's traffic to the local app and back. For the rest entities in the kubernetes cluster, the local app acts as an original kubernetes workload.
In order to maintain secure connections, Garden generates a new SSH key pair for each Deploy
action running in local mode on every CLI execution.
To configure a Deploy
action for local mode, add localMode
configuration entry to the spec
field of your Deploy
action configuration. See the examples below for details.
container
action typekubernetes
and helm
action typesTo run your Deploy
actions in local mode, you can use deploy
command with the special flag:
Local mode always runs in persistent mode, it means that the Garden process won't exit until it's terminated explicitly. All port-forwards established by local mode will be stopped on the process exit. The local application will be stopped if it was started via the localMode.command
configuration option. Otherwise, if the local application was started manually, it will continue running.
If you run your local application with the localMode.command
configuration option, then you can easily watch the local application's logs in real-time by running a garden
command with verbose
log level:
Otherwise, you can find the logs in .garden/deploy.debug.*.log
files.
A concrete example can be found in the .
Only one container can be run in local mode for each or Deploy
action.
Replaces target kubernetes workload's container with a special proxy container that is based on . This container exposes its SSH
port and the same HTTP
ports as the Deploy
action configured in local mode.
Note! Garden automates the SSH key acceptance with option -oStrictHostKeyChecking=accept-new
, this is the reason why you need or higher.
An example can be found in the .
A kubernetes
example can be found in the . A helm
example can be found in the .