---------------------- The "Fetching kubectl" stage occurs because Garden uses the Kubernetes API and kubectl to interact with your Kubernetes cluster. When you run the

garden plugins kubernetes cluster-init

command, Garden needs to ensure that the correct version of kubectl is available for use. If it's not already downloaded, Garden will fetch it. This is part of the initialization process of the Kubernetes plugin in Garden. You can also run specific versions of kubectl defined by the

kubernetes

plugin using the command

garden tools kubernetes.kubectl -- <args>

. If you want to get the path of the

kubectl

binary defined by the

kubernetes

provider, you can use the command

garden tools kubectl --get-path

. For more details, you can refer to the Garden documentation (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

---------------------- If you already have the

kubectl

binary installed on your machine, you can configure Garden to use that instead of downloading it automatically. You can do this by setting the

kubectlPath

in your Garden configuration. Here's an example of how you can set it:

yaml
providers:
  - name: kubernetes
    kubectlPath: ${local.env.GARDEN_KUBECTL_PATH}?

In this example,

GARDEN_KUBECTL_PATH

is an environment variable that points to the path of your

kubectl

binary. The

?

at the end makes this field optional, so if the environment variable is not set, Garden will still download

kubectl

as needed. Please note that Garden may make some assumptions with respect to the

kubectl

version, so it is suggested to only use this when necessary. You can find more information about this in the Garden documentation (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

---------------------- The line

buildMode: "cluster-buildkit"

in a

project.garden.yaml

file configuration sets the mechanism for building container images before deploying them. When you set

buildMode

to

cluster-buildkit

, Garden will sync your files to the Kubernetes cluster and build your container images there using BuildKit (). This removes the need to run Docker locally and allows you to share layer and image caches between multiple developers, as well as between your development and CI workflows. Here's what happens when you use

cluster-buildkit

mode: 1. BuildKit is automatically deployed to the project namespace, if it hasn't already been deployed there. 2. Your code (build context) is synchronized directly to the BuildKit deployment. 3. BuildKit imports caches from the deployment registry, builds the image, and then pushes the built image and caches back to the registry. This mode requires no cluster-wide services or permissions to be managed, and thus no permissions outside of a single namespace for each user/project. For more details, you can refer to the Garden documentation (). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

@limited-crayon-56213 That's a great question, but unfortunately I am only capable of responding to a maximum of five questions per thread. Don't hesitate to create a new thread for any further questions you have though. I'm here to help!

@limited-crayon-56213 That's a great question, but unfortunately I am only capable of responding to a maximum of five questions per thread. Don't hesitate to create a new thread for any further questions you have though. I'm here to help!