Requirements

What your cluster and workstation need before helm install, and the one pre-install step the default (Elasticsearch) path requires.

Kubernetes and Helm

Requirement Version Where it comes from
Kubernetes 1.21+ eck-operator 3.3.1 and eck-elasticsearch 0.18.1 both declare a kubeVersion floor of 1.21.0-0; chart/skywalking itself declares none. Helm does not enforce a subchart’s kubeVersion, so an older cluster still installs — it just runs an unsupported ECK.
Helm 3.8+ (4.x also works) The chart is apiVersion: v2, and helm dep up pulls the BanyanDB dependency from an OCI registry (oci://docker.io/apache), which needs Helm’s non-experimental OCI support (3.8.0).
kubectl matching your cluster Used to watch the install (kubectl get pods -w) and for all troubleshooting.

CI exercises the chart on a four-node kind cluster running kindest/node:v1.28.15 (test/e2e/kind28.yaml) — every e2e cell uses it — so 1.28 is the version with the most coverage.

The chart adapts to older Ingress APIs (ui-ingress.yaml falls back from networking.k8s.io/v1 to v1beta1 to extensions/v1beta1), so ingress itself is not what sets the minimum.

Cluster permissions

Installing needs more than namespace-scoped rights:

  • CRDs are cluster-scoped. The ECK CRDs (see below) can only be installed by a user with cluster-admin-level permissions.
  • The chart creates a ClusterRole and ClusterRoleBinding for OAP (oap-clusterrole.yaml, oap-clusterrolebinding.yaml), granting get/watch/list on pods, pod logs, endpoints, services, nodes, namespaces, configmaps, extensions deployments/replicasets and Istio networking.istio.io serviceentries — this is what backs Kubernetes-based service discovery and mesh analysis. Both templates are gated on serviceAccounts.oap.create, so set serviceAccounts.oap.create=false and supply your own serviceAccounts.oap.name if you cannot create cluster-scoped RBAC.

Storage volumes

Only Elasticsearch and a BanyanDB cluster claim persistent volumes out of the box. The other paths render emptyDir — fine for a trial, data loss on every pod restart anywhere else:

Component Claims a PV by default? Note
Elasticsearch (ECK) Yes elasticsearch.nodeSets[0].count: 3, and because volumeClaimTemplates is left commented out ECK applies its own default — a 1Gi elasticsearch-data PVC per node on the default StorageClass. Uncomment elasticsearch.nodeSets[].volumeClaimTemplates in values.yaml to size it (the example asks for 30Gi). See ECK volume claim settings.
BanyanDB standalone (banyandb.standalone.enabled: true, the default) No The subchart ships storage.standalone.enabled: false. Set banyandb.storage.standalone.enabled=true to claim the 200Gi standalone-data volume.
BanyanDB cluster (banyandb.cluster.enabled=true) Yes banyandb.storage.data.enabled: true — five data PVCs (50Gi/50Gi/5Gi/50Gi/5Gi) plus 10Gi for liaison, all with storageClass: null, i.e. the cluster default StorageClass.
PostgreSQL No This chart overrides the Bitnami postgresql 12.1.2 defaults with postgresql.primary.persistence.enabled: false and postgresql.readReplicas.persistence.enabled: false; the data directory is an emptyDir. It is a demo backend, as values.yaml says.
Horizon UI No ui.persistence.enabled: false (1Gi, ReadWriteOnce once enabled). Turn it on to keep BFF audit log, setup state and alarm state across restarts.

oap.resources, ui.resources and satellite.resources are all {} by default — no requests or limits are set, so plan capacity yourself. For a laptop-sized cluster, drop the Elasticsearch node count to 1 the way test/e2e/values.yaml does.

Install the ECK CRDs first

When you need this: elasticsearch.enabled=true, which is the default. The eck-operator-crds chart ships the CRDs as ordinary templates, so without this step they would be created in the same install that also renders the Elasticsearch custom resource depending on them. Install them as their own release first — SKYWALKING_RELEASE_NAMESPACE is the namespace you install into, exported as in Quick Start:

helm dep up chart/skywalking
tar xzf chart/skywalking/charts/eck-operator-3.3.1.tgz -C /tmp eck-operator/charts/eck-operator-crds
helm install eck-crds /tmp/eck-operator/charts/eck-operator-crds \
  -n "${SKYWALKING_RELEASE_NAMESPACE}" --create-namespace

Then install the chart with eck-operator.installCRDs=false so the operator does not try to create the same cluster-scoped CRDs again:

helm install skywalking chart/skywalking -n "${SKYWALKING_RELEASE_NAMESPACE}" \
  --set oap.image.tag=11.0.0 \
  --set oap.storageType=elasticsearch \
  --set ui.image.tag=horizon-1.0.0 \
  --set eck-operator.installCRDs=false

Pass installCRDs=false for the same reason if the ECK CRDs are already present because someone else installed ECK in the cluster — they are global resources, and a second chart owning them would overwrite them on upgrade and delete them on uninstall.

The eck-crds release is independent of the SkyWalking release: helm uninstall skywalking leaves the CRDs in place, and uninstalling eck-crds deletes every ECK-managed Elasticsearch in the cluster.

When you do NOT need this: any install with elasticsearch.enabled=false — no ECK operator, no CRDs. Note that elasticsearch.enabled is the only switch: the dependency condition is elasticsearch.enabled, not oap.storageType, so --set oap.storageType=banyandb on its own still deploys ECK and an Elasticsearch cluster nobody uses. Turn it off explicitly:

elasticsearch:
  enabled: false
  # Only read when oap.storageType is elasticsearch — i.e. an external cluster.
  config:
    host: elasticsearch-es-http
    port:
      http: 9200

Required values

Three values have no default and must be set on every install (ui.image.tag only while the UI is deployed — ui.enabled defaults to true):

Value Example
oap.image.tag 11.0.0
oap.storageType elasticsearch, postgresql, banyandb
ui.image.tag horizon-1.0.0

Two more are required only when you switch a component on: banyandb.image.tag (e.g. 0.11.0) with banyandb.enabled=true, or rendering fails with banyandb.image.tag is required, and satellite.image.tag with satellite.enabled=true.

Next