> ## Documentation Index > Fetch the complete documentation index at: https://docs.open-metadata.org/llms.txt > Use this file to discover all available pages before exploring further. # Kubernetes GKE Deployment | Official Documentation > Run your deployment on Google Kubernetes Engine (GKE) for a reliable, managed Kubernetes experience with secure configurations. # GKE on Google Cloud Platform Deployment OpenMetadata supports the Installation and Running of Application on Google Kubernetes Engine through Helm Charts. However, there are some additional configurations which needs to be done as prerequisites for the same. Google Kubernetes Engine (GKE) Auto Pilot Mode is not compatible with one of OpenMetadata Dependencies - ElasticSearch. The reason being that ElasticSearch Pods require Elevated permissions to run initContainers for changing configurations which is not allowed by GKE AutoPilot PodSecurityPolicy. All the code snippets in this section assume the `default` namespace for kubernetes. ## Prerequisites ### Cloud Database with CloudSQL and ElasticCloud for GCP as Search Engine It is recommended to use GCP [Cloud SQL](https://cloud.google.com/sql/) services for Database and [Elastic Cloud GCP](https://www.elastic.co/partners/google-cloud) for Search Engine for Production. We support - * Cloud SQL (MySQL) engine version 8 or higher * Cloud SQL (postgreSQL) engine version 12 or higher * ElasticSearch version 9.x (minimum 9.0.0, recommended 9.3.0) We recommend - * CloudSQL to be Multi Zone Available * Elastic Cloud Environment with multiple zones and minimum 2 nodes Make sure to increase `sort_buffer_size` ([for MySQL](https://cloud.google.com/sql/docs/mysql/flags)) or `work_mem` ([for PostgreSQL](https://cloud.google.com/sql/docs/postgres/flags)) to the recommended value of **20MB** or more using flags. This is especially important when running migrations to prevent **Out of Sort Memory Error**. You can revert the setting once the migrations are complete. ## Kubernetes Orchestrator Configuration (Recommended) Starting with OpenMetadata 1.12, we recommend using the **Kubernetes native orchestrator** for running ingestion pipelines. This eliminates the need for Apache Airflow and simplifies your deployment. The Kubernetes orchestrator runs ingestion pipelines as native K8s Jobs and CronJobs. For full documentation on features, configuration options, and troubleshooting, see the [Kubernetes Orchestrator Guide](/v1.12.x/deployment/ingestion/kubernetes). The recommended OMJob Operator approach requires installing Custom Resource Definitions (CRDs), which needs elevated cluster permissions. If your cluster policies don't allow CRDs, you can disable the operator by setting `useOMJobOperator: false` and `omjobOperator.enabled: false` in your values file to use native K8s Jobs instead. ### OpenMetadata Values Configuration Create your `openmetadata-values.yaml` with the following configuration: ```yaml theme={null} # openmetadata-values.yaml openmetadata: config: # Database configuration elasticsearch: host: searchType: elasticsearch port: 443 scheme: https connectionTimeoutSecs: 5 socketTimeoutSecs: 60 keepAliveTimeoutSecs: 600 batchSize: 10 auth: enabled: true username: password: secretRef: elasticsearch-secrets secretKey: openmetadata-elasticsearch-password database: host: port: 3306 driverClass: com.mysql.cj.jdbc.Driver dbScheme: mysql dbUseSSL: true databaseName: auth: username: password: secretRef: mysql-secrets secretKey: openmetadata-mysql-password # Kubernetes Orchestrator configuration pipelineServiceClientConfig: enabled: true type: "k8s" metadataApiEndpoint: http://openmetadata:8585/api k8s: useOMJobOperator: true # Enable the OMJob Operator (recommended for production) omjobOperator: enabled: true ``` For advanced configuration options such as resource limits, job lifecycle settings, failure diagnostics, RBAC, and security contexts, see the [Kubernetes Orchestrator Guide](/v1.12.x/deployment/ingestion/kubernetes). For Database as PostgreSQL, use the below config for database values: ```yaml theme={null} database: host: port: 5432 driverClass: org.postgresql.Driver dbScheme: postgresql dbUseSSL: true databaseName: auth: username: password: secretRef: sql-secrets secretKey: openmetadata-sql-password ``` ### Create Kubernetes Secrets Create the required secrets for CloudSQL and ElasticSearch: ```bash theme={null} # Database secret kubectl create secret generic mysql-secrets \ --from-literal=openmetadata-mysql-password= # ElasticSearch secret kubectl create secret generic elasticsearch-secrets \ --from-literal=openmetadata-elasticsearch-password= ``` ### Deploy OpenMetadata ```bash theme={null} # Add the OpenMetadata Helm repository helm repo add open-metadata https://helm.open-metadata.org/ helm repo update # Install OpenMetadata (no dependencies chart needed with K8s orchestrator) helm install openmetadata open-metadata/openmetadata \ --values openmetadata-values.yaml ``` With the Kubernetes orchestrator, you don't need to deploy the `openmetadata-dependencies` chart that includes Airflow. This significantly simplifies your deployment. ### Verify the Deployment ```bash theme={null} # Check pods are running kubectl get pods # Check the K8s orchestrator health in OpenMetadata UI # Navigate to Settings → Preferences → Health ``` *** ## Using Airflow Orchestrator (Alternative) If you prefer to use Apache Airflow as the orchestrator (e.g., for existing Airflow investments or complex DAG requirements), follow the configuration below. Using Airflow requires additional infrastructure: persistent volumes with ReadWriteMany access, the openmetadata-dependencies Helm chart, and more complex configuration. ### Persistent Volumes with ReadWriteMany Access Modes OpenMetadata helm chart depends on Airflow and Airflow expects a persistent disk that support ReadWriteMany (the volume can be mounted as read-write by many nodes). The workaround is to create nfs-server disk on Google Kubernetes Engine and use that as the persistent claim and deploy OpenMetadata by implementing the following steps in order. ### Create NFS Share #### Provision GCP Persistent Disk for Google Kubernetes Engine Run the below command to create a gcloud compute zonal disk. For more information on Google Cloud Disk Options, please visit [here](https://cloud.google.com/compute/docs/disks). ```commandline theme={null} gcloud compute disks create --size=100GB --zone= nfs-disk ``` #### Deploy NFS Server in GKE ```yaml theme={null} # nfs-server-deployment.yml apiVersion: apps/v1 kind: Deployment metadata: name: nfs-server spec: replicas: 1 selector: matchLabels: role: nfs-server template: metadata: labels: role: nfs-server spec: initContainers: - name: init-airflow-directories image: busybox command: ['sh', '-c', 'mkdir -p /exports/airflow-dags /exports/airflow-logs'] volumeMounts: - mountPath: /exports name: nfs-pvc containers: - name: nfs-server image: itsthenetwork/nfs-server-alpine env: - name: SHARED_DIRECTORY value: /exports ports: - name: nfs containerPort: 2049 securityContext: privileged: true volumeMounts: - mountPath: /exports name: nfs-pvc volumes: - name: nfs-pvc gcePersistentDisk: pdName: nfs-disk fsType: ext4 --- # nfs-cluster-ip-service.yml apiVersion: v1 kind: Service metadata: name: nfs-server spec: ports: - name: nfs port: 2049 selector: role: nfs-server ``` Run the commands below and ensure the pods are running. ```commandline theme={null} kubectl create -f nfs-server-deployment.yml kubectl create -f nfs-cluster-ip-service.yml ``` We create a ClusterIP Service for pods to access NFS within the cluster at a fixed IP/DNS. #### Provision NFS backed PV and PVC for Airflow DAGs and Airflow Logs Update `` with the NFS Service Cluster IP Address for below code snippets. You can get the clusterIP using the following command ```commandline theme={null} kubectl get service nfs-server -o jsonpath='{.spec.clusterIP}' ``` #### Code Samples for PV and PVC for Airflow DAGs ```yaml theme={null} # dags_pv_pvc.yml apiVersion: v1 kind: PersistentVolume metadata: name: openmetadata-dependencies-dags-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteMany nfs: server: path: "/airflow-dags" --- apiVersion: v1 kind: PersistentVolumeClaim metadata: labels: app: airflow release: openmetadata-dependencies name: openmetadata-dependencies-dags namespace: default spec: accessModes: - ReadWriteMany resources: requests: storage: 10Gi storageClassName: "" ``` Create Persistent Volumes and Persistent Volume claims with the below command. ```commandline theme={null} kubectl create -f dags_pv_pvc.yml ``` #### Code Samples for PV and PVC for Airflow Logs ```yaml theme={null} # logs_pv_pvc.yml apiVersion: v1 kind: PersistentVolume metadata: name: openmetadata-dependencies-logs-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteMany nfs: server: path: "/airflow-logs" --- apiVersion: v1 kind: PersistentVolumeClaim metadata: labels: app: airflow name: openmetadata-dependencies-logs namespace: default spec: accessModes: - ReadWriteMany resources: requests: storage: 10Gi storageClassName: "" ``` Create Persistent Volumes and Persistent Volume claims with the below command. ```commandline theme={null} kubectl create -f logs_pv_pvc.yml ``` ### Change owner and permission manually on disks Since airflow pods run as non root users, they would not have write access on the nfs server volumes. In order to fix the permission here, spin up a pod with persistent volumes attached and run it once. ```yaml theme={null} # permissions_pod.yml apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: my-permission-pod name: my-permission-pod spec: containers: - image: nginx name: my-permission-pod volumeMounts: - name: airflow-dags mountPath: /airflow-dags - name: airflow-logs mountPath: /airflow-logs volumes: - name: airflow-logs persistentVolumeClaim: claimName: openmetadata-dependencies-logs - name: airflow-dags persistentVolumeClaim: claimName: openmetadata-dependencies-dags dnsPolicy: ClusterFirst restartPolicy: Always ``` Airflow runs the pods with linux user name as airflow and linux user id as 50000. Run the below command to create the pod and fix the permissions ```commandline theme={null} kubectl create -f permissions_pod.yml ``` Once the permissions pod is up and running, execute the below commands within the container. ```commandline theme={null} kubectl exec --tty my-permission-pod --container my-permission-pod -- chown -R 50000 /airflow-dags /airflow-logs # If needed kubectl exec --tty my-permission-pod --container my-permission-pod -- chmod -R a+rwx /airflow-dags ``` ### Create OpenMetadata dependencies Values Override openmetadata dependencies airflow helm values to bind the nfs persistent volumes for DAGs and logs. ```yaml theme={null} # values-dependencies.yml airflow: airflow: extraVolumeMounts: - mountPath: /airflow-logs name: nfs-airflow-logs - mountPath: /airflow-dags/dags name: nfs-airflow-dags extraVolumes: - name: nfs-airflow-logs persistentVolumeClaim: claimName: openmetadata-dependencies-logs - name: nfs-airflow-dags persistentVolumeClaim: claimName: openmetadata-dependencies-dags config: AIRFLOW__OPENMETADATA_AIRFLOW_APIS__DAG_GENERATED_CONFIGS: "/airflow-dags/dags" dags: path: /airflow-dags/dags persistence: enabled: false logs: path: /airflow-logs persistence: enabled: false ``` For more information on airflow helm chart values, please refer to [airflow-helm](https://artifacthub.io/packages/helm/airflow-helm/airflow/8.8.0). When deploying openmeteadata dependencies helm chart, use the below command - ```commandline theme={null} helm install openmetadata-dependencies open-metadata/openmetadata-dependencies --values values-dependencies.yaml ``` The above command uses configurations defined [here](https://raw.githubusercontent.com/open-metadata/openmetadata-helm-charts/main/charts/deps/values.yaml). You can modify any configuration and deploy by passing your own `values.yaml` ```commandline theme={null} helm install openmetadata-dependencies open-metadata/openmetadata-dependencies --values ``` Once the openmetadata dependencies helm chart deployed, you can then run the below command to install the openmetadata helm chart - ```commandline theme={null} helm install openmetadata open-metadata/openmetadata --values ``` Make sure to create CloudSQL and ElasticSearch credentials as Kubernetes Secrets mentioned [here](/v1.12.x/quick-start/local-kubernetes-deployment#2.-create-kubernetes-secrets-required-for-helm-charts). Also, disable MySQL and ElasticSearch from OpenMetadata Dependencies Helm Charts as mentioned in the FAQs [here](#how-to-disable-mysql-and-elasticsearch-from-openmetadata-dependencies-helm-charts). ## Troubleshooting ### Pods are stuck in Pending State due to Persistent Volume Creation Failure If you came across `invalid access type while creating the pvc`, and the permission pod is stuck in "pending" state. The above error might have occurred due to the pvc volumes not setup or pvc volumes are not mounted properly. dag-log permission-pod-events Please validate: * all the prerequisites mentioned in this [section](#prerequisites) * the configuration of `dags_pv_pvc.yml` file * `storageClassName` field in YAML file ## FAQs ## Java Memory Heap Issue If your openmetadata pods are not in ready state at any point in time and the openmetadata pod logs speaks about the below issue - ``` Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "AsyncAppender-Worker-async-file-appender" Exception in thread "pool-5-thread-1" java.lang.OutOfMemoryError: Java heap space Exception in thread "AsyncAppender-Worker-async-file-appender" java.lang.OutOfMemoryError: Java heap space Exception in thread "dw-46" java.lang.OutOfMemoryError: Java heap space Exception in thread "AsyncAppender-Worker-async-console-appender" java.lang.OutOfMemoryError: Java heap space ``` This is due to the default JVM Heap Space configuration (1 GiB) being not enough for your workloads. In order to resolve this issue, head over to your custom openmetadata helm values and append the below environment variable ```yaml theme={null} extraEnvs: - name: OPENMETADATA_HEAP_OPTS value: "-Xmx2G -Xms2G" ``` The flag `Xmx` specifies the maximum memory allocation pool for a Java virtual machine (JVM), while `Xms` specifies the initial memory allocation pool. Upgrade the helm charts with the above changes using the following command `helm upgrade --install openmetadata open-metadata/openmetadata --values --namespace `. Update this command your `values.yml` filename and `namespaceName` where you have deployed OpenMetadata in Kubernetes. ## PostgreSQL Issue permission denied to create extension "pgcrypto" If you are facing the below issue with PostgreSQL as Database Backend for OpenMetadata Application, ``` Message: ERROR: permission denied to create extension "pgcrypto" Hint: Must be superuser to create this extension. ``` It seems the Database User does not have sufficient privileges. In order to resolve the above issue, grant usage permissions to the PSQL User. ```sql theme={null} GRANT USAGE ON SCHEMA schema_name TO ; GRANT CREATE ON EXTENSION pgcrypto TO ; ``` In the above command, replace `` with the sql user used by OpenMetadata Application to connect to PostgreSQL Database. ## How to extend and use custom docker images with OpenMetadata Helm Charts ? ## Extending OpenMetadata Server Docker Image ### 1. Create a `Dockerfile` based on `docker.open-metadata.org/openmetadata/server` OpenMetadata helm charts uses official published docker images from [DockerHub](https://hub.docker.com/u/openmetadata). A typical scenario will be to install organization certificates for connecting with inhouse systems. For Example - ``` FROM docker.open-metadata.org/openmetadata/server:x.y.z WORKDIR /home/ COPY . RUN update-ca-certificates ``` where `docker.open-metadata.org/openmetadata/server:x.y.z` needs to point to the same version of the OpenMetadata server, for example `docker.open-metadata.org/openmetadata/server:1.3.1`. This image needs to be built and published to the container registry of your choice. ### 2. Update your openmetadata helm values yaml The OpenMetadata Application gets installed as part of `openmetadata` helm chart. In this step, update the custom helm values using YAML file to point the image created in the previous step. For example, create a helm values file named `values.yaml` with the following contents - ```yaml theme={null} ... image: repository: # Overrides the image tag whose default is the chart appVersion. tag: ... ``` ### 3. Install / Upgrade your helm release Upgrade/Install your openmetadata helm charts with the below single command: ```bash theme={null} helm upgrade --install openmetadata open-metadata/openmetadata--values values.yaml ``` ## Extending OpenMetadata Ingestion Docker Image One possible use case where you would need to use a custom image for the ingestion is because you have developed your own custom connectors. You can find a complete working example of this [here](https://github.com/open-metadata/openmetadata-demo/tree/main/custom-connector). After you have your code ready, the steps would be the following: ### 1. Create a `Dockerfile` based on `docker.open-metadata.org/openmetadata/ingestion`: For example - ``` FROM docker.open-metadata.org/openmetadata/ingestion:x.y.z USER airflow # Let's use the home directory of airflow user WORKDIR /home/airflow # Install our custom connector COPY COPY setup.py . RUN pip install --no-deps . ``` where `docker.open-metadata.org/openmetadata/ingestion:x.y.z` needs to point to the same version of the OpenMetadata server, for example `docker.open-metadata.org/openmetadata/ingestion:1.3.1`. This image needs to be built and published to the container registry of your choice. ### 2. Update the airflow in openmetadata dependencies values YAML The ingestion containers (which is the one shipping Airflow) gets installed in the `openmetadata-dependencies` helm chart. In this step, we use our own custom values YAML file to point to the image we just created on the previous step. You can create a file named `values.deps.yaml` with the following contents: ```yaml theme={null} airflow: airflow: image: repository: # by default, openmetadata/ingestion tag: # by default, the version you are deploying, e.g., 1.1.0 pullPolicy: "IfNotPresent" ``` ### 3. Install / Upgrade helm release Upgrade/Install your openmetadata-dependencies helm charts with the below single command: ```bash theme={null} helm upgrade --install openmetadata-dependencies open-metadata/openmetadata-dependencies --values values.deps.yaml ``` ## How to disable MySQL and ElasticSearch from OpenMetadata Dependencies Helm Charts ? If you are using MySQL and ElasticSearch externally, you would want to disable the local installation of mysql and elasticsearch while installing OpenMetadata Dependencies Helm Chart. You can disable the MySQL and ElasticSearch Helm Dependencies by setting `enabled: false` value for each dependency. Below is the command to set helm values from Helm CLI - ```commandline theme={null} helm upgrade --install openmetadata-dependencies open-metadata/openmetadata-dependencies --set mysql.enabled=false --set elasticsearch.enabled=false ``` Alternatively, you can create a custom YAML file named `values.deps.yaml` to disable installation of MySQL and Elasticsearch . ```yaml theme={null} mysql: enabled: false ... elasticsearch: enabled: false ... ... ``` ## How to configure external database like PostgreSQL with OpenMetadata Helm Charts ? OpenMetadata Supports PostgreSQL as one of the Database Dependencies. OpenMetadata Helm Charts by default does not include PostgreSQL as Database Dependencies. In order to configure Helm Charts with External Database like PostgreSQL, follow the below guide to make the helm values change and upgrade / install OpenMetadata helm charts with the same. ## Upgrade Airflow Helm Dependencies Helm Charts to connect to External Database like PostgreSQL We ship [airflow-helm](https://github.com/airflow-helm/charts/tree/main/charts/airflow) as one of OpenMetadata Dependencies with default values to connect to MySQL Database as part of `externalDatabase` configurations. You can find more information on setting the `externalDatabase` as part of helm values [here](https://github.com/airflow-helm/charts/blob/main/charts/airflow/docs/faq/database/external-database.md). With OpenMetadata Dependencies Helm Charts, your helm values would look something like below - ```yaml theme={null} ... airflow: externalDatabase: type: postgresql host: port: 5432 database: user: passwordSecret: airflow-postgresql-secrets passwordSecretKey: airflow-postgresql-password ... ``` For the above code, it is assumed you are creating a kubernetes secret for storing Airflow Database login Credentials. A sample command to create the secret will be `kubectl create secret generic airflow-postgresql-secrets --from-literal=airflow-postgresql-password=`. ## Upgrade OpenMetadata Helm Charts to connect to External Database like PostgreSQL Update the `openmetadata.config.database.*` helm values for OpenMetadata Application to connect to External Database like PostgreSQL. With OpenMetadata Helm Charts, your helm values would look something like below - ```yaml theme={null} openmetadata: config: ... database: host: port: 5432 driverClass: org.postgresql.Driver dbScheme: postgresql dbUseSSL: true databaseName: auth: username: password: secretRef: openmetadata-postgresql-secrets secretKey: openmetadata-postgresql-password ``` For the above code, it is assumed you are creating a kubernetes secret for storing OpenMetadata Database login Credentials. A sample command to create the secret will be `kubectl create secret generic openmetadata-postgresql-secrets --from-literal=openmetadata-postgresql-password=`. Once you make the above changes to your helm values, run the below command to install/upgrade helm charts - ```commandline theme={null} helm upgrade --install openmetadata-dependencies open-metadata/openmetadata-dependencies --values <> --namespace helm upgrade --install openmetadata open-metadata/openmetadata --values <> --namespace ``` ## How to customize OpenMetadata Dependencies Helm Chart with custom helm values Our OpenMetadata Dependencies Helm Charts are internally depends on three sub-charts - * [Bitnami MySQL](https://artifacthub.io/packages/helm/bitnami/mysql/9.7.2) (helm chart version 9.7.2) * [OpenSearch](https://artifacthub.io/packages/helm/opensearch-project-helm-charts/opensearch/2.12.2) (helm chart version 2.12.2) * [Airflow](https://artifacthub.io/packages/helm/airflow-helm/airflow/8.8.0) (helm chart version 8.8.0) If you are looking to customize the deployments of any of the above dependencies, please refer to the above links for customizations of helm values for further references. By default, OpenMetadata Dependencies helm chart provides initial generic customization of these helm values in order to get you started quickly. You can refer to the openmetadata-dependencies helm charts default values [here](https://github.com/open-metadata/openmetadata-helm-charts/blob/main/charts/deps/values.yaml).