Cluster prerequisites¶

ECMWF Sites runs on Kubernetes. This guide covers the services and access the platform needs on a cluster that is already running.

Kubernetes access and permissions¶

• Use a Kubernetes version supported by your organisation and the dependencies you install.
• The installer needs permission to create namespaced resources and the cluster-scoped resources in the chart, including role-based access control (RBAC), PriorityClass objects, and the Site custom resource definition (CRD).
• The Operator, Hub, and scheduled jobs use separate ServiceAccounts. The chart always creates their RBAC. The installer needs permission to create these Roles and bindings.
• Use Kubernetes 1.30 or later, so that the chart can create the ValidatingAdmissionPolicy sites-hub-volume-deletion. This policy limits the PersistentVolumes that the Hub can delete. The installer needs permission to create ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding objects. On older clusters, the chart does not create the policy. If you render the chart with helm template, add --api-versions admissionregistration.k8s.io/v1/ValidatingAdmissionPolicy.
• Label the release namespace to enforce the restricted Pod Security Standard. The chart creates no namespace, so this is an installer action:

kubectl label namespace <release-namespace> \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted --overwrite

Every platform pod and every website pod satisfies the standard: none runs as root, none allows privilege escalation, all drop every Linux capability, and all use the RuntimeDefault seccomp profile. A custom application image that needs a Linux capability does not run under the policy. - Install a metrics API if you use the Hub HorizontalPodAutoscaler. Install a Prometheus Operator if you enable the chart's ServiceMonitor resources.

Storage¶

Provide persistent storage that matches the access patterns of your installation:

• The chart's storage.data persistent volume claim (PVC) stores platform data mounted at /sites-data. The backup job exports Site custom resources here. This backup does not contain website content.
• Each website gets its own PVC. Configure the Site storage class, access mode, and expansion support under sitesConfig.kubernetes.
• The default production-style setup often needs a storage class that supports ReadWriteMany, because more than one platform pod or job can mount shared data. Confirm the actual mounts, Container Storage Interface (CSI) driver, and access mode with your storage administrator.
• Decide how you will back up platform data and website content. These are separate storage and recovery paths.

Set storage.data.storageClassName for the chart PVC. Set sitesConfig.kubernetes.storage_class_name, storage_access_mode, and storage_expansion_supported for site PVCs. An empty chart StorageClass name uses the cluster default. A null site StorageClass name also uses the cluster default.

Images and registry access¶

The Hub, Core, and Operator image repositories use images.registry, images.*.repository, and images.tag. Website images use the registry settings under sitesConfig.kubernetes. Redis has separate image settings under images.redis.

Make sure nodes can pull each image. The standard platform images use the sites-oss project in the ECMWF container registry (ECCR). Confirm whether your cluster needs a registry pull Secret. For any image repository that requires authentication, create a kubernetes.io/dockerconfigjson Secret and set serviceAccount.imagePullSecretName to its name. The Secret must be in the release namespace. Image tags must be available for the node architecture.

Public routing, DNS, and certificates¶

Choose one of the chart's routing modes:

• ingress needs an NGINX Ingress controller that supports the mergeable Ingress resources used by the chart.
• gateway needs the Gateway API HTTPRoute CRD and a Gateway controller. Use an existing Gateway that permits routes from the release namespace, or configure the chart to create a Gateway.

In either mode, you provide three things: a public DNS name with a record that resolves to the routing entry point, a TLS certificate for that name, and the routing controller itself.

Network policies and external services¶

NetworkPolicy resources require a network plugin that enforces them. The chart creates the Redis and site policies if networkPolicy.enabled is true. Set networkPolicy.enabled to false if another tool manages network traffic. Set the allowed controller and monitoring namespaces to match your cluster.

Allow the required outbound and inbound connections for the services you enable, such as:

• the OpenID Connect (OIDC) provider and its discovery endpoint
• LDAP, SMTP, Jira, Splunk, or OpenSearch
• the container registry
• the storage and backup services
• monitoring systems and the Gateway or Ingress data plane

Before install¶

• Confirm the release namespace and environment values.
• Confirm storage classes, access modes, quotas, and backup ownership.
• Confirm image tags and registry access from all nodes.
• Confirm the routing controller, and confirm how your cluster creates the public DNS records and the TLS certificate (integration or manual process).
• Confirm NetworkPolicy support and namespace selectors.
• Confirm the required OIDC client and application Secrets are ready.
• Review the ServiceAccount permissions and cluster resource policies.