Skip to content

Latest commit

 

History

History
99 lines (70 loc) · 3.86 KB

tilt.md

File metadata and controls

99 lines (70 loc) · 3.86 KB
Raw

Developing Cluster API with Tilt

Overview

This document describes how to use kind and Tilt for a simplified workflow that offers easy deployments and rapid iterative builds.

Prerequisites

  1. Docker
  2. kind v0.6 or newer
  3. Tilt
  4. Clone the Cluster API repository locally
  5. Clone the provider(s) you want to deploy locally as well

Getting started

Create a kind cluster

First, make sure you have a kind cluster and that your KUBECONFIG is set up correctly:

$ kind create cluster

Create a tilt-settings.json file

Next, create a tilt-settings.json file and place it in your local copy of cluster-api. Here is an example:

{
  "allowed_contexts": ["kind-kind"],
  "default_registry": "gcr.io/your-project-name-here",
  "enable_providers": ["aws", "docker"]
}

tilt-settings.json fields

allowed_contexts: A list of kubeconfig contexts Tilt is allowed to use. See the Tilt documentation on *allow_k8s_contexts for more details.

default_registry: The image registry to use if you need to push images. See the Tilt *documentation for more details.

enable_providers: A list of the providers to enable. See available providers for more details.

Run Tilt!

To launch your development environment, run

tilt up

This will open the command-line HUD as well as a web browser interface. You can monitor Tilt's status in either location. After a brief amount of time, you should have a running development environment, and you should now be able to create a cluster. Please see the Usage section in the Quick Start for more information on creating workload clusters.

Available providers

The following providers are currently defined in the Tiltfile:

  • core: cluster-api itself (Cluster/Machine/MachineDeployment/MachineSet/KubeadmConfig/KubeadmControlPlane)
  • aws: AWS provider (AWSCluster/AWSMachine)
  • docker: Docker provider (DockerCluster/DockerMachine)

Provider map field definitions

TODO

Customizing Tilt

If you need to customize Tilt's behavior, you can create files in cluster-api's tilt.d directory. This file is ignored by git so you can be assured that any files you place here will never be checked in to source control.

These files are included after the providers map has been defined and after all the helper function definitions. This is immediately before the "real work" happens.

Under the covers, a.k.a "the real work"

At a high level, the Tiltfile performs the following actions:

  1. Read tilt-settings.json
  2. Configure the allowed Kubernetes contexts
  3. Set the default registry
  4. Define the providers map
  5. Include user-defined Tilt files
  6. Deploy cert-manager
  7. Enable providers (core + what is listed in tilt-settings.json)
    1. Build the manager binary locally as a local_resource
    2. Invoke docker_build for the provider
    3. Invoke kustomize for the provider's config/default directory

Live updates

Each provider in the providers map has a live_reload_deps list. This defines the files and/or directories that Tilt should monitor for changes. When a dependency is modified, Tilt rebuilds the provider's manager binary on your local machine, copies the binary to the running container, and executes a restart script. This is significantly faster than rebuilding the container image for each change. It also helps keep the size of each development image as small as possible (the container images do not need the entire go toolchain, source code, module dependencies, etc.).