skywalking Chart Values

The values the skywalking chart defines itself, plus the elasticsearch.* keys its values.yaml ships. Set them with --set key=value or a values file (-f my-values.yaml).

This is not the full accepted surface. Most keys under a subchart alias — banyandb.*, postgresql.*, eck-operator.*, and the elasticsearch.* keys not listed below — are passed straight through to that subchart, and its own values file is the reference. See BanyanDB, PostgreSQL and Elasticsearch.

The exception is the storage connection block. elasticsearch.config.*, banyandb.config.* and postgresql.config.host are this chart’s own keys — no subchart defines them; _helpers.tpl reads them to build the OAP storage env and the wait-for-storage init container. Looking for them in a subchart’s values file will not find them, so they are tabled below alongside the chart’s own values. helm show values chart/skywalking prints the whole merged default set.

Three values have no default and must be set on every install:

Two more have no default but are required only when the component that consumes them is enabled. Both fail the render rather than defaulting:

Both components are configurable three ways, and the chart’s own values follow that split:

Prefer the first two for both. The two files are not equivalent: Horizon’s image ships a complete /app/horizon.yaml in which every field is a ${HORIZON_*:default} placeholder, so nothing has to be mounted and ui.config replaces a file that already works. OAP reads real files for log4j2.xml and the OAL/MAL rules, which no environment variable can supply, so oap.config is the only route to those. See Configure Horizon and OAP configuration.

Kubernetes resolves envFrom before env, and a later env entry wins over an earlier one of the same name. So a Secret cannot override a variable the chart itself sets — oap.extraEnv / ui.extraEnv, both rendered last, can.

The following table lists the configurable parameters of the Skywalking chart and their default values.

Elasticsearch (ECK)

Elasticsearch is deployed via ECK (Elastic Cloud on Kubernetes). The chart includes the ECK operator and an eck-elasticsearch subchart, both controlled by elasticsearch.enabled. Because Elasticsearch CRDs must exist before the ES custom resource can be created, the ECK operator CRDs need to be installed separately before deploying the chart. See the main README for installation steps.

Top-level parameters

External Elasticsearch (when elasticsearch.enabled is false)

Node sets (elasticsearch.nodeSets[])

ECK node sets define the topology of the Elasticsearch cluster. Each entry in the list creates a group of Elasticsearch nodes.

Pod template (elasticsearch.nodeSets[].podTemplate)

The pod template follows standard Kubernetes Pod spec nested under podTemplate.spec. This controls scheduling, resources, init containers, etc.

BanyanDB

banyandb.enabled is false by default. The keys below are read by this chart’s templates in both modes; everything else under banyandb.* belongs to the subchart.

PostgreSQL

postgresql.enabled is false by default, and the bundled deployment is a demo — values.yaml turns persistence off on both primary and read replicas.

Specify each parameter with the --set key=value[,key=value] argument to helm install. A bare skywalking is not a chart reference — use a local path or the OCI URL. (The legacy JFrog repo that served the name skywalking/skywalking is frozen at 4.3.0.) From a clone, with the ECK CRDs already installed as their own release:

helm install myrelease chart/skywalking \
  --set oap.image.tag=11.0.0 \
  --set oap.storageType=elasticsearch \
  --set ui.image.tag=horizon-1.0.0 \
  --set eck-operator.installCRDs=false \
  --set nameOverride=my-skywalking

Resource names are built from the release name and nameOverride, so it has to be RFC 1123 lowercase: newSkywalking renders myrelease-newSkywalking-oap, which templates fine and is then rejected by the API server.

Alternatively, put the values in a YAML file:

helm install my-release chart/skywalking -f my-values.yaml

Released versions install from the OCI reference instead — oci://registry-1.docker.io/apache/skywalking-helm --version <x.y.z>. See Chart sources.

Tip: You can use the default values.yaml

RBAC Configuration

Roles and RoleBindings resources will be created automatically for OAP .

Tip: You can refer to the default oap-role.yaml file in templates to customize your own.

Ingress TLS

If your cluster allows automatic create/retrieve of TLS certificates ( e.g. kube-lego), please refer to the documentation for that mechanism.

To manually configure TLS, first create/retrieve a key & certificate pair for the address(skywalking ui) you wish to protect. Then create a TLS secret in the namespace:

kubectl create secret tls skywalking-tls --cert=path/to/tls.cert --key=path/to/tls.key

Include the secret’s name, along with the desired hostnames, in the skywalking-ui Ingress TLS section of your custom values.yaml file:

ui:
  ingress:
    ## If true, Skywalking ui server Ingress will be created
    ##
    enabled: true

    ## Skywalking ui server Ingress hostnames
    ## Must be provided if Ingress is enabled
    ##
    hosts:
      - skywalking

    ## Skywalking ui server Ingress TLS configuration
    ## Secrets must be manually created in the namespace
    ##
    tls:
      - secretName: skywalking
        hosts:
          - skywalking

Envoy ALS

Envoy ALS(access log service) provides fully logs about RPC routed, including HTTP and TCP.

If you want to open envoy ALS, you can do this by modifying values.yaml. default open.

serviceAccounts:
  oap:
    create: true

When envoy als ,will give ServiceAccount clusterrole permission. More envoy als ,please refer to https://github.com/apache/skywalking/blob/master/docs/en/setup/envoy/als_setting.md#observe-service-mesh-through-als