System requirements of an Edge site

EKS requirements

Note The default Edge CLI method is an easier solution for installing your Edge site via the Edge CLI. Edge creates the cluster level objects, such as namespaces and priority classes for you. This method can be used for both dedicated and shared clusters.

You can install the Edge software on managed Kubernetes clusters.

• AWS EKS 1.27, 1.28, 1.29, 1.30, 1.31, 1.32, and 1.33 are supported for new and existing Edge sites.
• EKS cluster has IRSA enabled.
• Set up security groups to ensure that worker nodes can communicate with each other on non-privileged ports.

Software requirements

• A Linux server for x86_64 architecture where bash is available. This is the server from which you install the Edge software on EKS.

  Tip This server will also contain the Edge tools.

• You must have a kubeconfig file with plain cluster_admin kubectl access to the EKS cluster.
• The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the EKS cluster.
• Ensure your kubectl client is compatible with the relevant EKS version.

Hardware requirements

You need an operational EKS cluster with at least 1 worker node that is running a Linux-based operating system. The cluster must meet the following requirements:

• The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 4 worker nodes each with 4 core CPU and 16 GB.
• Each worker node needs at least 100 GB free disk space to store Docker images, logs, and ephemeral cluster data.
• We recommend you have at least 2 worker nodes in the EKS cluster.

Note  For more information about Linux OS for EKS clusters, go to the Amazon documentation about Amazon EKS optimized AMIs. As Edge sites are only compatible with Linux OS, disregard the Windows AMI option in this resource.

Network requirements

EKS requirements

Note The restrictive Edge CLI method allows you or your company to create the cluster level objects, such as namespaces and priority classes, for your Edge site. This method may be required if your company has security requirements or process that do not allow Edge sites to create the cluster level objects for you. This method can be used for both dedicated and shared clusters.

You can install the Edge software on managed Kubernetes clusters.

• AWS EKS 1.27, 1.28, 1.29, 1.30, 1.31, 1.32, and 1.33 are supported for new and existing Edge sites.
• EKS cluster has IRSA enabled.
• Set up security groups to ensure that worker nodes can communicate with each other on non-privileged ports.

Software requirements

• A Linux server for x86_64 architecture where bash is available. This is the server from which you install the Edge software on EKS.

  Tip This server will also contain the Edge tools.

• You must have a kubeconfig file with plain cluster_admin kubectl access to the EKS cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
  Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
• The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
  • A user/service account with a role scoped to the collibra-edge namespace.
  • The rules within the role must at minimum be set to "*".
    Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
  Show an example

  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    name: edge-namespace-role
    namespace: collibra-edge
  rules:
    - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
  ---
  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: edge-namespace-rb
    namespace: collibra-edge
  subjects:
    - kind: User
    name: username>  # The user that will perform the installation
    namespace: collibra-edge
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: edge-namespace-role

• Ensure your kubectl client is compatible with the relevant EKS version.

Hardware requirements

You need an operational EKS cluster with at least 1 worker node that is running a Linux-based operating system. The cluster must meet the following requirements:

• The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 4 worker nodes each with 4 core CPU and 16 GB.
• Each worker node needs at least 100 GB free disk space to store Docker images, logs, and ephemeral cluster data.
• We recommend you have at least 2 worker nodes in the EKS cluster.

Note  For more information about Linux OS for EKS clusters, go to the Amazon documentation about Amazon EKS optimized AMIs. As Edge sites are only compatible with Linux OS, disregard the Windows AMI option in this resource.

Network requirements

GKE requirements

Note The default Edge CLI method is an easier solution for installing your Edge site via the Edge CLI. Edge creates the cluster level objects, such as namespaces and priority classes for you. This method can be used for both dedicated and shared clusters.

You can install the Edge software on managed Kubernetes clusters.

• GKE 1.27, 1.28, 1.29, 1.30, 1.31, 1.32, and 1.33 are supported for new Edge sites.
  Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.

Software requirements

• A Linux server for x86_64 architecture where bash is available. This is the server from which you install the Edge software on GKE.

  Tip This server will also contain the Edge tools.

• You must have a kubeconfig file with plain cluster_admin kubectl access to the GKE cluster.
• The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the GKE cluster.
• Ensure your Kubectl client is compatible with the relevant GKE version.

Hardware requirements

You need an operational GKE cluster with at least 1 worker node. The cluster must meet the following requirements:

• The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 2 worker nodes each with 8 core CPU and 32 GB or 4 work nodes each with 4 core CPU and 16 GB.
• Each worker node needs at least 100 GB free disk space to store Docker images, logs, and ephemeral cluster data.
• We recommend you have at least 2 worker nodes in the GKE cluster.

Note At this time, Edge site installations on GKE clusters are only compatible with nodes running Linux-based operating systems. For more information about the currently supported Linux OS for GKE clusters, go to the Google documentation about Node images.

Network requirements

GKE requirements

Note The restrictive Edge CLI method allows you or your company to create the cluster level objects, such as namespaces and priority classes, for your Edge site. This method may be required if your company has security requirements or process that do not allow Edge sites to create the cluster level objects for you. This method can be used for both dedicated and shared clusters.

You can install the Edge software on managed Kubernetes clusters.

• GKE 1.27, 1.28, 1.29, 1.30, 1.31, 1.32, and 1.33 are supported for new Edge sites.
  Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.

Software requirements

• A Linux server for x86_64 architecture where bash is available. This is the server from which you install the Edge software on GKE.

  Tip This server will also contain the Edge tools.

• You must have a kubeconfig file with plain cluster_admin kubectl access to theGKE cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.
  Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.
• The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:
  • A user/service account with a role scoped to the collibra-edge namespace.
  • The rules within the role must at minimum be set to "*".
    Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
  Example…

  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    name: edge-namespace-role
    namespace: collibra-edge
  rules:
    - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
  ---
  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: edge-namespace-rb
    namespace: collibra-edge
  subjects:
    - kind: User
    name: username>  # The user that will perform the installation
    namespace: collibra-edge
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: Role
    name: edge-namespace-role

• Ensure your Kubectl client is compatible with the relevant GKE version.

Hardware requirements

You need an operational GKE cluster with at least 1 worker node. The cluster must meet the following requirements:

• The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 2 worker nodes each with 8 core CPU and 32 GB or 4 work nodes each with 4 core CPU and 16 GB.
• Each worker node needs at least 100 GB free disk space to store Docker images, logs, and ephemeral cluster data.
• We recommend you have at least 2 worker nodes in the GKE cluster.

Note At this time, Edge site installations on GKE clusters are only compatible with nodes running Linux-based operating systems. For more information about the currently supported Linux OS for GKE clusters, go to the Google documentation about Node images.

Network requirements

AWS Fargate using EKS requirements

Note The default Edge CLI method is an easier solution for installing your Edge site via the Edge CLI. Edge creates the cluster level objects, such as namespaces and priority classes for you. This method can be used for both dedicated and shared clusters.

You can install the Edge software on managed Kubernetes clusters.

• AWS Fargate using EKS on Kubernetes 1.27, 1.28, 1.29, 1.30, 1.31, 1.32, and 1.33 are supported for new Edge sites.
  Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.
• EKS cluster has IRSA enabled
• You must create an AWS Fargate profile for your cluster with the following namespace selectors:
  • kube-system
  • default
  • collibra-*
  • edge-kube-installer
• EKS cluster has CoreDNS enabled and running on a Fargate Node(s).

Software requirements

• A Linux server for x86_64 architecture where bash is available. This is the server from which you install the Edge software on AWS Fargate using EKS.

  Tip This server will also contain the Edge tools.

• You must have a kubeconfig file with plain cluster_admin kubectl access to the AWS Fargate using EKS cluster.
• The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the cluster.
• Ensure your Kubectl client is compatible with the relevant EKS version.

Network requirements

AWS Fargate using EKS requirements

Note The restrictive Edge CLI method allows you or your company to create the cluster level objects, such as namespaces and priority classes, for your Edge site. This method may be required if your company has security requirements or process that do not allow Edge sites to create the cluster level objects for you. This method can be used for both dedicated and shared clusters.

You can install the Edge software on managed Kubernetes clusters.

• AWS Fargate using EKS on Kubernetes 1.27, 1.28, 1.29, 1.30, 1.31, 1.32, and 1.33 are supported for new Edge sites.
  Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.
• EKS cluster has IRSA enabled
• You must create an AWS Fargate profile for your cluster with the following namespace selectors:
  • kube-system
  • default
  • collibra-*
  • edge-kube-installer
• EKS cluster has CoreDNS enabled and running on a Fargate Node(s).

Software requirements

• A Linux server for x86_64 architecture where bash is available. This is the server from which you install the Edge software on AWS Fargate using EKS.

  Tip This server will also contain the Edge tools.

You must have a kubeconfig file with plain cluster_admin kubectl access to the AWS Fargate using EKS cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.

Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.

The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:

• A user/service account with a role scoped to the collibra-edge namespace.
• The rules within the role must at minimum be set to "*".
  Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
Example…

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role

• Ensure your Kubectl client is compatible with the relevant EKS version.

Network requirements

Commercial

OpenShift requirements

Note The default Edge CLI method is an easier solution for installing your Edge site via the Edge CLI. Edge creates the cluster level objects, such as namespaces and priority classes for you. This method can be used for both dedicated and shared clusters.

You can install the Edge software on managed Kubernetes clusters.

• OpenShift 4.14, 4.15, 4.16, 4.17, 4.18, and 4.19 are supported for new Edge sites.
  Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.

Software requirements

• A Linux server for x86_64 architecture where bash is available. This is the server from which you install the Edge software on OpenShift.

  Tip This server will also contain the Edge tools

• You must have a kubeconfig file with plain cluster_admin kubectl access to the OpenShift cluster.
• The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the OpenShift cluster.
• Ensure your Kubectl client is compatible with the relevant OpenShift version.

Hardware requirements

You need an operational OpenShift cluster with at least 1 worker node. The cluster must meet the following requirements:

• The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 4 worker nodes each with 4 core CPU and 16 GB.
• Each worker node needs at least 100 GB free disk space to store Docker images, logs, and ephemeral cluster data.
• We recommend you have at least 2 worker nodes in the OpenShift cluster.

Note At this time, Edge site installations on OpenShift clusters are only compatible with nodes running Linux-based operating systems. For more information about the currently supported Linux OS for OpenShift clusters, go to the OpenShift documentation.

Network requirements

OpenShift requirements

Note The restrictive Edge CLI method allows you or your company to create the cluster level objects, such as namespaces and priority classes, for your Edge site. This method may be required if your company has security requirements or process that do not allow Edge sites to create the cluster level objects for you. This method can be used for both dedicated and shared clusters.

You can install the Edge software on managed Kubernetes clusters.

• OpenShift 4.14, 4.15, 4.16, 4.17, 4.18, and 4.19 are supported for new Edge sites.
  Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.

Software requirements

• A Linux server for x86_64 architecture where bash is available. This is the server from which you install the Edge software on OpenShift.

  Tip This server will also contain the Edge tools.

You must have a kubeconfig file with plain cluster_admin kubectl access to the OpenShift cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.

Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.

The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:

• A user/service account with a role scoped to the collibra-edge namespace.
• The rules within the role must at minimum be set to "*".
  Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
Example…

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role

• Ensure your Kubectl client is compatible with the relevant OpenShift version.

Hardware requirements

You need an operational OpenShift cluster with at least 1 worker node. The cluster must meet the following requirements:

• The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 4 worker nodes each with 4 core CPU and 16 GB.
• Each worker node needs at least 100 GB free disk space to store Docker images, logs, and ephemeral cluster data.
• We recommend you have at least 2 worker nodes in the OpenShift cluster.

Note At this time, Edge site installations on OpenShift clusters are only compatible with nodes running Linux-based operating systems. For more information about the currently supported Linux OS for OpenShift clusters, go to the OpenShift documentation.

Network requirements

AKS requirements

Note The default Edge CLI method is an easier solution for installing your Edge site via the Edge CLI. Edge creates the cluster level objects, such as namespaces and priority classes for you. This method can be used for both dedicated and shared clusters.

You can install the Edge software on managed Kubernetes clusters.

• AKS 1.27, 1.28, 1.29, 1.30, 1.31, 1.32, and 1.33 are supported for new Edge sites.
  Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.

Software requirements

• A Linux server for x86_64 architecture where bash is available. This is the server from which you install the Edge software on AKS.

  Tip This server will also contain the Edge tools.

• You must have a kubeconfig file with plain cluster_admin kubectl access to the AKS cluster.
• The kubeconfig environment variable must be set to a kubeconfig that has plain cluster_admin kubectl access to the AKS cluster.
• Ensure your Kubectl client is compatible with the relevant AKS version.

Hardware requirements

You need an operational AKS cluster with at least 1 worker node. The cluster must meet the following requirements:

• The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 2 worker nodes each with 8 core CPU and 32 GB or 4 work nodes each with 4 core CPU and 16 GB.
• Each worker node needs at least 100 GB free disk space to store Docker images, logs, and ephemeral cluster data.
• We recommend you have at least 2 worker nodes in the AKS cluster.

Note At this time, Edge site installations on AKS clusters are only compatible with nodes running Linux-based operating systems. For more information about the currently supported Linux OS for AKS clusters, go to the Azure documentation about Azure Kubernetes core concepts.

Network requirements

AKS requirements

Note The restrictive Edge CLI method allows you or your company to create the cluster level objects, such as namespaces and priority classes, for your Edge site. This method may be required if your company has security requirements or process that do not allow Edge sites to create the cluster level objects for you. This method can be used for both dedicated and shared clusters.

You can install the Edge software on managed Kubernetes clusters.

• AKS 1.27, 1.28, 1.29, 1.30, 1.31, 1.32, and 1.33 are supported for new Edge sites.
  Note You can migrate an existing k3s or EKS Edge site to a new managed Kubernetes cluster by following the Managed Kubernetes reinstallation steps using the Edge CLI method. You can't migrate from an existing Edge site to a new cluster using the Helm chart method.

Software requirements

• A Linux server for x86_64 architecture where bash is available. This is the server from which you install the Edge software on AKS.

  Tip This server will also contain the Edge tools.

You must have a kubeconfig file with plain cluster_admin kubectl access to the AKS cluster. This kubeconfig file is used to create the Custom Resource Definitions (CRDs) and namespace required for the Edge site.

Note The only thing that should be running inside of the dedicated namespace in the shared cluster is the Edge site. We do not support running third-party components, such as service mesh, inside of the Edge site's dedicated namespace.

The kubeconfig environment variable must be set to a valid kubeconfig file that contains the following:

• A user/service account with a role scoped to the collibra-edge namespace.
• The rules within the role must at minimum be set to "*".
  Note You need to set each rules’ value to “*” because the apiVersions and resources rules can change or be deprecated at any point within Kubernetes. Setting these values to “*” ensures that your Edge site remains compatible with the latest versions of Kubernetes. If the role has stricter permissions, your site may experience breaking changes that will require reinstallation.
Example…

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: edge-namespace-role
  namespace: collibra-edge
rules:
  - apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edge-namespace-rb
  namespace: collibra-edge
subjects:
  - kind: User
  name: username>  # The user that will perform the installation
  namespace: collibra-edge
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: edge-namespace-role

• Ensure your Kubectl client is compatible with the relevant AKS version.

Hardware requirements

You need an operational AKS cluster with at least 1 worker node. The cluster must meet the following requirements:

• The total cluster capacity has at least 16 core CPU and 64 GB memory, for example, 2 worker nodes each with 8 core CPU and 32 GB or 4 work nodes each with 4 core CPU and 16 GB.
• Each worker node needs at least 100 GB free disk space to store Docker images, logs, and ephemeral cluster data.
• We recommend you have at least 2 worker nodes in the AKS cluster.

Note At this time, Edge site installations on AKS clusters are only compatible with nodes running Linux-based operating systems. For more information about the currently supported Linux OS for AKS clusters, go to the Azure documentation about Azure Kubernetes core concepts.

Network requirements