Skip to main content

Google Kubernetes Engine (GKE)

Set up Platform Cluster

If you are not using a pre-existing cluster, create your Platform Cluster by following the GKE getting started docs

Once completed, log in to your cluster using the gcloud cli and set the PLATFORM environment variable:

gcloud container clusters get-credentials <cluster-name> --zone <zone> --project <project-name>
kubectl config current-context
export PLATFORM=<platform-context-name>

Install cert-manager

Kratix requires a set of certificates in order to deploy its internal Validating and Mutating Kubernetes webhooks. By default Kratix is configured to use cert-manager to generate the certificates, therefore we need to install cert-manager. If you already have it installed, skip to the next section.

Don't want to use cert-manager? Manually provide the required certificates

Cert-manager is used to generate a CA, and a key/cert pair which is configured for the following DNS names:

  • kratix-platform-webhook-service.kratix-platform-system.svc.cluster.local
  • kratix-platform-webhook-service.kratix-platform-system.svc

To manually provide the required certificates, you need to create the webhook-server-cert secret in the kratix-platform-system namespace with the following keys:

apiVersion: v1
data:
ca.crt: # Base64 CA certificate
tls.crt: # Base64 encoded Server certificate
tls.key: # Base64 encoded Server private key
kind: Secret
metadata:
name: webhook-server-cert
namespace: kratix-platform-system
type: kubernetes.io/tls

As part of installing Kratix we create a few resources that require the CA certificate. You will have to manually add the CA certificate to the resources mentioned below, and manually remove the cert-manager Certificate and Issuer resources. The following resources need to be updated to contain the Base64 encoded CA certificate:

  • MutatingWebhookConfiguration/kratix-platform-mutating-webhook-configuration

    apiVersion: admissionregistration.k8s.io/v1
    kind: MutatingWebhookConfiguration
    metadata:
    name: kratix-platform-mutating-webhook-configuration
    webhooks:
    - admissionReviewVersions:
    - v1
    clientConfig:
    caBundle: .... # there might be multiple admissionReviewVersions, ensure you update all of them
  • ValidatingWebhookConfiguration/kratix-platform-validating-webhook-configuration

    apiVersion: admissionregistration.k8s.io/v1
    kind: ValidatingWebhookConfiguration
    metadata:
    name: kratix-platform-validating-webhook-configuration
    webhooks:
    - admissionReviewVersions:
    - v1
    clientConfig:
    caBundle: .... # there might be multiple admissionReviewVersions, ensure you update all of them
  • CustomResourceDefinition/promises.platform.kratix.io

    apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    metadata:
    name: promises.platform.kratix.io
    spec:
    conversion:
    strategy: Webhook
    webhook:
    clientConfig:
    caBundle: ....

Lastly, you need to remove the following cert-manager Issuer and Certificate from Kratix release manifest:

---
...
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: kratix-platform-serving-cert
namespace: kratix-platform-system
spec:
...
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: kratix-platform-selfsigned-issuer
namespace: kratix-platform-system
spec:
...

To install it, run:

kubectl --context $PLATFORM apply --filename https://github.com/cert-manager/cert-manager/releases/download/v1.15.0/cert-manager.yaml

Make sure that cert-manager is ready before installing Kratix:

$ kubectl --context $PLATFORM get pods --namespace cert-manager
NAME READY STATUS RESTARTS AGE
cert-manager-7476c8fcf4-r8cnd 1/1 Running 0 19s
cert-manager-cainjector-bdd866bd4-7d8zp 1/1 Running 0 19s
cert-manager-webhook-5655dcfb4b-54r49 1/1 Running 0 19s

Install Kratix

Install Kratix on the Platform Cluster.

kubectl apply --context $PLATFORM --filename https://github.com/syntasso/kratix/releases/latest/download/kratix.yaml

You can also install and configure Kratix with Helm. For more information, see the Helm Chart documentation.

Make sure that kratix is ready before proceeding:

$ kubectl --context $PLATFORM get pods --namespace kratix-platform-system
NAME READY STATUS RESTARTS AGE
kratix-platform-controller-manager-78d57569b-bn4t4 2/2 Running 0 25s

Set up State Store

Kratix uses GitOps to provision resources on the worker clusters. You can configure Kratix with multiple GitOps repositories by creating State Stores. Kratix supports Bucket State Store and Git State Store.

Using a Git State Store is recommended for production environments as it provides better security and version control. However, for development and testing purposes, you can also use the Bucket State Store.

If you have a pre-existing Git repository or S3-Compatible Bucket you can use that as your state store. If not you can either:

  • Create a new Git repository on your Git provider of choice and use it as your state store. See Git State Store for more information.
  • Create a GCP Bucket (anything that implements the S3 API will work) and then use it as your state store. See Bucket State Store for more information. You will have to create a set of S3-Compatible credentials for Kratix to use.

Register cluster as a Destination with Kratix

We need to register the cluster with Kratix so that it can be used as a destination for deploying to. Use the template below to create a Worker Destination resource:

apiVersion: platform.kratix.io/v1alpha1
kind: Destination
metadata:
name: worker
labels:
environment: dev
spec:
stateStoreRef:
name: default
kind: <BucketStateStore or GitStateStore>

Once filled in with the correct values, apply the resource to the platform cluster:

kubectl apply --context $PLATFORM --filename <path-to-worker-destination-resource>

Set up Worker Cluster

If you are not using a pre-existing cluster, create a Worker Cluster following the same steps as the Platform Cluster setup.

Once completed, log in to your cluster using the gcloud cli and set the WORKER environment variable:

gcloud container clusters get-credentials <cluster-name> --zone <zone> --project <project-name>
kubectl config current-context
export WORKER=<worker-context-name>

Install Flux

Follow the Flux installation guide to install Flux, or if you are just using this cluster for testing you can use the following manifest (NOT to be used for production). Other GitOps tools are available, such as ArgoCD.

kubectl apply --context $WORKER --filename https://raw.githubusercontent.com/syntasso/kratix/main/hack/destination/gitops-tk-install.yaml

Make sure that flux is ready before proceeding:

$ kubectl --context $WORKER get pods --namespace flux-system
NAME READY STATUS RESTARTS AGE
helm-controller-5f7457c9dd-s5qzt 1/1 Running 0 18s
kustomize-controller-5f58d55f76-hwm5w 1/1 Running 0 19s
notification-controller-685bdc466d-5xmk8 1/1 Running 0 16s
source-controller-86b8b57796-t6xgg 1/1 Running 0 20s

Configure Flux

Configure Flux to use the state store you created earlier:

  • If you are using a Git repository as your state store, follow the steps in the FluxCD docs for creating a GitRepository resource
  • If you are using a Bucket as your state store, follow the steps in the FluxCD docs for creating a Bucket resource

Then create two Kustomization resources, one for the workload resources and one for the dependencies, using the template below:

---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
name: kratix-workload-resources
namespace: <Same namespace as the Bucket/GitRepository>
spec:
interval: 3s
prune: true
dependsOn:
- name: kratix-workload-dependencies
sourceRef:
kind: <Bucket or GitRepository>
name: <Name of Bucket/GitRepository>
path: ./worker/resources
validation: client
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
name: kratix-workload-dependencies
namespace: <Same namespace as the Bucket/GitRepository>
spec:
interval: 8s
prune: true
sourceRef:
kind: <Bucket or GitRepository>
name: <Name of Bucket/GitRepository>
path: ./worker/dependencies
validation: client
Example complete set of Flux resources
---
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: Bucket
metadata:
name: kratix-bucket
namespace: flux-system
spec:
interval: 10s
provider: generic
bucketName: kratix
endpoint: 172.18.0.2:31337
insecure: true
secretRef:
name: minio-credentials
---
apiVersion: v1
kind: Secret
metadata:
name: minio-credentials
namespace: flux-system
type: Opaque
data:
accesskey: bWluaW9hZG1pbg==
secretkey: bWluaW9hZG1pbg==
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
name: kratix-workload-resources
namespace: flux-system
spec:
interval: 3s
prune: true
dependsOn:
- name: kratix-workload-dependencies
sourceRef:
kind: Bucket
name: kratix-bucket
path: ./worker/resources
validation: client
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
name: kratix-workload-dependencies
namespace: flux-system
spec:
interval: 8s
prune: true
sourceRef:
kind: Bucket
name: kratix-bucket
path: ./worker/dependencies
validation: client

Once filled in with the correct values, apply the resource to the platform cluster:

kubectl apply --context $WORKER --filename <path-to-git-or-bucket-resource>
kubectl apply --context $WORKER --filename <path-to-kustomization-resource>

Flux will eventually reconcile the cluster's state, making the worker cluster ready to receive workloads. You can verify its readiness by observing the kratix-worker-system namespace appearing in the worker cluster:

$ kubectl --context $WORKER get namespaces
NAME STATUS AGE
...
kratix-worker-system Active 1m
...

🎉 Congratulations! Kratix is now installed! Jump to Installing and using a Promise to spin up your first as-a-service offering.