To start your environment you'll need to set these environment variables (we
recommend adding them to your .bashrc
):
GOPATH
: If you don't have one, simply pick a directory and addexport GOPATH=...
$GOPATH/bin
onPATH
: This is so that tooling installed viago get
will work properly.KO_DOCKER_REPO
: The docker repository to which developer images should be pushed (e.g.gcr.io/[gcloud-project]
).
ℹ️ If you are using Docker Hub to store your images, your
KO_DOCKER_REPO
variable should have the formatdocker.io/<username>
. Currently, Docker Hub doesn't let you create subdirs under your username (e.g.<username>/knative
).
.bashrc
example:
export GOPATH="$HOME/go"
export PATH="${PATH}:${GOPATH}/bin"
export KO_DOCKER_REPO='gcr.io/my-gcloud-project-id'
-
You must have
ko
installed. -
Create a Google Cloud project and install the
gcloud
CLI and rungcloud auth login
. This guide will use a mix ofgcloud
andkubectl
commands. The rest of the guide assumes that you've set thePROJECT_ID
environment variable to your Google Cloud project id, and also set your project ID as default usinggcloud config set project $PROJECT_ID
. -
Create a cluster under your Google Cloud project. If you would like to use Workload Identity to configure credential in the section Configure the Authentication Mechanism for GCP, we recommend you to enable Workload Identity when you create cluster, this could help to reduce subsequent configuration time.
-
Set up a Linux Container repository for pushing images. You can use any container image registry by adjusting the authentication methods and repository paths mentioned in the sections below.
ℹ️ You'll need to be authenticated with your
KO_DOCKER_REPO
before pushing images. Rungcloud auth configure-docker
if you are using Google Container Registry ordocker login
if you are using Docker Hub. -
Install Knative. Set up Serving and Eventing. Both are required for now to make knative-gcp work.
-
Download the
knative-gcp
source code into$GOPATH/src/github.com/google/knative-gcp
. For development follow the fork instructions.
Enter the knative-gcp
directory before running the following commands.
Option 1: Install from Main using ko
ko apply -f ./config
Option 2: Install a release.
-
Pick a knative-gcp release version:
export KGCP_VERSION=v0.19.0
-
First install the pre-install job by running the
kubectl apply
forcloud-run-events-pre-install-jobs.yaml
. Skip this step if you are installing a release before v0.18.0 or after v0.20.0 (including v0.20.0).kubectl apply --filename https://github.com/google/knative-gcp/releases/download/${KGCP_VERSION}/cloud-run-events-pre-install-jobs.yaml
-
Install the CRDs by running the
kubectl apply
forcloud-run-events.yaml
with selector. This prevents race conditions during the installation, which cause intermittent errors:kubectl apply --selector events.cloud.google.com/crd-install=true \ --filename https://github.com/google/knative-gcp/releases/download/${KGCP_VERSION}/cloud-run-events.yaml
-
To complete the installation, run the
kubectl apply
again forcloud-run-events.yaml
without selector:kubectl apply --filename https://github.com/google/knative-gcp/releases/download/${KGCP_VERSION}/cloud-run-events.yaml
Currently, we support two methods: Workload Identity and Kubernetes Secret. The configuration steps have been automated by the scripts below. If you wish to configure the auth manually, refer to Manually Configure Authentication Mechanism for the Control Plane.
Before applying initialization scripts, make sure:
- Your default zone is set to be the same as your current cluster. You may use
gcloud container clusters describe $CLUSTER_NAME
to get zone and applygcloud config set compute/zone $ZONE
to set it. - Your gcloud
CLI
are up to date. You may usegcloud components update
to update it.
Workload Identity is the recommended way to access Google Cloud services from within GKE due to its improved security properties and manageability. For more information about Workload Identity, please see here.
Note: If you install the Knative-GCP Constructs with v0.14.0 or older releases, please use option 2.
Apply init_control_plane_gke.sh:
./hack/init_control_plane_gke.sh
Note: If you didn't enable Workload Identity when you created your cluster, this step may take a long time to finish.
Optional parameters available:
CLUSTER_NAME
: an optional parameter to specify the cluster to use, default togcloud config get-value run/cluster
CLUSTER_LOCATION
: an optional parameter to specify the cluster location to use, default togcloud config get-value run/cluster_location
CLUSTER_LOCATION_TYPE
: an optional parameter to specify the cluster location type to use, default tozonal
. CLUSTER_LOCATION_TYPE must bezonal
orregional
.PROJECT_ID
: an optional parameter to specify the project to use, default togcloud config get-value project
.
Here is an example specifying the parameters instead of using the default ones:
./hack/init_control_plane_gke.sh [CLUSTER_NAME] [CLUSTER_LOCATION] [CLUSTER_LOCATION_TYPE] [PROJECT_ID]
Apply init_control_plane.sh:
./hack/init_control_plane.sh
Optional parameters available:
PROJECT_ID
: an optional parameter to specify the project to use, default togcloud config get-value project
. If you want to specify the parameterPROJECT_ID
instead of using the default one,
./hack/init_control_plane.sh [PROJECT_ID]