apache/skywalking-swck repository overview

⁠Apache SkyWalking Cloud on Kubernetes

Docker images are not official ASF releases, but are provided for convenience. The official release is the source tarball on dist.apache.org⁠; building from source is always the recommended usage.

SkyWalking is an APM (application performance monitoring) system, designed for microservices, cloud-native and container-based architectures.

SWCK (SkyWalking Cloud on Kubernetes) is a Kubernetes operator that provisions, upgrades and maintains SkyWalking components — the OAP backend, the UI, BanyanDB, Satellite, agents — as custom resources, and injects the Java agent into application pods.

• Documentation: https://skywalking.apache.org/docs/skywalking-swck/latest/readme/⁠
• Source: https://github.com/apache/skywalking-swck⁠
• Dockerfile: build/images/Dockerfile.release⁠

⁠Installing

The operator is installed with its Helm chart, which is published to this same repository and carries a -helm suffix on the tag:

helm install skywalking-swck oci://registry-1.docker.io/apache/skywalking-swck \
  --version 0.11.0-helm \
  --namespace skywalking-swck-system --create-namespace

The suffix is not a typo. A Docker Hub repository holds one namespace for both images and OCI charts, so 0.11.0 is the image and 0.11.0-helm is the chart of the same release. It is still a valid SemVer pre-release, so helm orders it correctly. See Helm chart⁠.

The chart is also on GHCR, without the suffix, along with a snapshot of every commit on master:

helm install skywalking-swck oci://ghcr.io/apache/skywalking-swck/helm/skywalking-swck \
  --version 0.11.0 --namespace skywalking-swck-system --create-namespace

Then create an OAP cluster — see Getting started⁠.

⁠What is in the image

Two binaries, both statically linked on gcr.io/distroless/static:nonroot and running as UID 65532:

Both run inside a Kubernetes cluster, and the chart above deploys them. Running this image by hand is not a supported way to use SWCK.

⁠Platforms

From 0.11.0, linux/amd64 and linux/arm64 are both genuine: the release builds a binary per architecture, and CI extracts each one from the published manifest and checks its ELF machine type before the release completes.

Earlier tags advertised linux/arm64 but the arm64 manifest held an x86-64 binary, so an arm64 node failed with exec format error. If you are on arm64, use 0.11.0 or later.

⁠Version compatibility

Two things worth knowing before you deploy:

• Storage is mandatory. SkyWalking removed the embedded H2 in 10.2.0, so no supported OAP has one and there is no fallback. An OAPServer with no storage starts, looks for a BanyanDB on 127.0.0.1:17912 and never becomes ready — so the operator refuses one at admission. Give it a Storage, or set SW_STORAGE yourself.
• The UI is Horizon only. apache/skywalking removed the legacy Booster UI in 11.0.0 and no longer builds an image for it, so spec.kind accepts horizon alone.

⁠Tags

• 0.11.0 — the image for that release
• 0.11.0-helm — the Helm chart for that release
• latest — the newest release image

Tags up to v0.9.0 carry a v prefix; 0.10.0 onwards do not.

⁠Licence

Apache 2.0. See https://www.apache.org/licenses/LICENSE-2.0⁠.