For Okera to work in GCP, and GKE specifically, there are a few requirements that need to be addressed at some point in time. This includes access to storage buckets as well as a transactional database instance. The following topics address these dependencies and how to acquire them in a general manner. Okera is aware that, in practice, a lot of these resources are already deployed and shared with other services. In that case, it is required to work with the owners of these services to agree to an access pattern.
Google Cloud Storage (GCS)¶
Okera requires a GCS path where it can store audit and operational logs, e.g.
We refer to this as the
Okera GCS Storage. In addition, you must have read/write access to this storage.
If you do not already have GCS storage created, please refer to the online documentation to create it.
You will need a resource project where you will create Okera resources such as your GKE cluster.
Database (Cloud SQL)¶
Okera is backed by a relational database, and we strongly recommend using Google Cloud SQL. Okera supports MySQL 5.6 and 5.7.
After the database is created, navigate to the Cloud SQL page:
- Select your database, e.g.
- In "Overview", write down the "Connect to this instance" details, this will be used later as part of your "Catalog DB URL".
- In "Connections", ensure that "Allow only SSL connections" is selected.
- In "Users", create a new admin user that can manage the Okera databases. Write down the new admin name and password, this will be used later as your "Catalog DB User".
Google Kubernetes Engine (GKE)¶
Okera runs on top of Kubernetes, and on GCP, we leverage GKE as our managed Kubernetes runtime.
You should follow official documentation for creating GKE clusters.
Once the GKE cluster is created, you will need to be able to access it using
kubectl from a machine, which we call the
To do this, install and configure the Google SDK CLI on that machine, and then execute the following command:
$ gcloud container clusters get-credentials <your gke cluster> --region=<region>
Also see the online documentation for details.
Once complete, you should be able to use
kubectl normally, e.g.:
$ kubectl get nodes -owide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME gke-cluster-1-odas-default-309f3494-chhm Ready <none> 10m v1.15.12-gke.6002 10.128.0.12 18.104.22.1681 Container-Optimized OS from Google 4.19.112+ docker://19.3.1 gke-cluster-1-odas-default-309f3494-d1vl Ready <none> 20d v1.15.12-gke.6002 10.128.0.10 34.321.321.123 Container-Optimized OS from Google 4.19.112+ docker://19.3.1 gke-cluster-1-odas-default-309f3494-t7m0 Ready <none> 10m v1.15.12-gke.6002 10.128.0.11 34.123.321.123 Container-Optimized OS from Google 4.19.112+ docker://19.3.1
You can also see all available Kubernetes contexts:
$ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE ... * gke_vivid-lane-285120_us-central1-c_cluster-1 gke_vivid-lane-285120_us-central1-c_cluster-1 gke_vivid-lane-285120_us-central1-c_cluster-1 ...