이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 2. Verifying cluster prerequisites for logging


Before you install the Loki Operator or Red Hat OpenShift Logging Operator, verify that your cluster meets both storage requirements for LokiStack. Missing either storage prerequisite is a common cause of silent deployment failures.

Important

LokiStack requires TWO separate types of storage:

  1. Block storage (via StorageClass): For internal PVCs that store the write-ahead log (WAL), index cache, and compactor working space
  2. Object storage (S3-compatible): For the actual log data chunks and indices

This section covers the first requirement (block storage). Object storage is configured separately in Configuring object storage for LokiStack.

Both storage types are mandatory. Missing either causes deployment failure.

2.1. Why verify prerequisites first

Without a working StorageClass:

  • Operators install successfully.
  • The LokiStack shows Ready.
  • Pods remain Pending and no logs are collected or stored.

Without object storage or a proper CA bundle:

  • Operators install successfully.
  • The LokiStack shows Ready.
  • Logs are silently dropped with no user-facing error.

Complete these checks now to prevent troubleshooting issues later. See KCS-7062821 for examples of support cases caused by unclear storage requirements.

2.2. Object storage permissions requirements

The credentials used to access S3-compatible object storage must have specific permissions to allow LokiStack to read, write, and manage log data.

2.2.1. Required S3 API permissions

The following S3 API permissions are required for LokiStack to function correctly:

Expand
PermissionPurpose

s3:ListBucket

List objects in the bucket. Required for LokiStack to query and retrieve stored log chunks.

s3:PutObject

Write log chunks and index files to the bucket. Required for log ingestion.

s3:GetObject

Read log chunks and index files from the bucket. Required for log queries and compaction.

s3:DeleteObject

Delete expired log chunks based on retention policies. Required for the compactor component.

s3:GetObjectTagging

Read object tags. Required for retention and lifecycle management.

s3:PutObjectTagging

Write object tags. Required for retention and lifecycle management.

Important

Without s3:DeleteObject permission, the LokiStack compactor cannot remove expired logs. This causes the bucket to grow indefinitely, even when retention policies are configured. The LokiStack shows Ready but old logs are never deleted.

2.2.2. Example IAM policy for AWS S3

If using Amazon S3, create an IAM policy with the following permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::<bucket_name>"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:GetObjectTagging",
        "s3:PutObjectTagging"
      ],
      "Resource": "arn:aws:s3:::<bucket_name>/*"
    }
  ]
}

Replace <bucket_name> with your actual S3 bucket name.

2.2.3. Permissions for S3 Compatible storage

For S3 Compatible storage providers (NetApp StorageGRID, Cloudian HyperStore, and others), ensure the access credentials have equivalent permissions to the S3 API operations listed above. The exact configuration method varies by storage provider.

Consult your storage provider’s documentation for:

  • How to create users or service accounts
  • How to grant S3 API permissions to those accounts
  • Whether additional permissions are required for your specific storage implementation
Note

Some S3 Compatible storage providers use different permission models or naming conventions. Verify that your credentials can perform all six S3 operations listed above.

2.3. Verifying StorageClass availability

LokiStack requires a StorageClass that supports dynamic provisioning of block storage (ReadWriteOnce). The StorageClass does not need to be the default, but it must have sufficient available capacity for your chosen LokiStack size.

Prerequisites

  • You have cluster administrator permissions.
  • You are logged in to the cluster with oc.

Procedure

  1. List available StorageClass resources:

    $ oc get storageclass
  2. Identify the StorageClass you will use for LokiStack. It can be the default StorageClass (marked with (default)) or any other available StorageClass:

    $ oc get storageclass -o=jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubernetes\.io/is-default-class=="true")].metadata.name}'
  3. Verify the StorageClass supports block storage (strongly recommended for Loki performance):

    Look for a provisioner such as ebs.csi.aws.com, csi.vsphere.vmware.com, openshift-storage.ceph.rbd, or similar.

    Important

    Loki supports both block and filesystem storage, but filesystem storage introduces significant performance issues and is not recommended for production deployments. Always use block storage (volumeMode: Block) when available.

  4. Verify the StorageClass has sufficient available capacity:

    Check the disk space requirements from the Loki sizing table. For example, 1x.medium with ruler requires 910 GiB of total disk capacity across all PVCs.

Note

If no suitable StorageClass exists, LokiStack PVCs remain Pending and pods never start. You must configure a StorageClass before installing the operators. If you do not want to use the default StorageClass, you can specify storageClassName explicitly in the LokiStack CR.

Next step

If you are on single-node OpenShift or an edge deployment without dynamic storage, configure local storage for single-node and edge deployments.

2.4. Configuring local storage for single-node and edge deployments

Single-node OpenShift and many edge deployments do not include a StorageClass. Use the Local Storage Operator or Logical Volume Manager Storage to create one from local disks.

Prerequisites

  • You have cluster administrator permissions.
  • Raw, unformatted block devices are available on the node(s).
  • The cluster is not using OpenShift Data Foundation (consider OpenShift Data Foundation for larger environments).

Procedure

  1. Create the project, if it does not exist, by running the following command:

    $ oc adm new-project openshift-local-storage
  2. Install the Local Storage Operator from OperatorHub (Web Console) or via Subscription YAML. Use the stable channel.
  3. Create a LocalVolume CR for block devices (recommended for Loki):

    Example: localvolume-block.yaml

    apiVersion: local.storage.openshift.io/v1
    kind: LocalVolume
    metadata:
      name: local-block
      namespace: openshift-local-storage
    spec:
      nodeSelector:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - <your_node_name>
      storageClassDevices:
      - storageClassName: local-block
        volumeMode: Block
        devicePaths:
        - /dev/disk/by-id/<device_id>
        fsType: ""

    <your_node_name>
    Replace with your node name or use node labels for selection.
    storageClassName: local-block
    This value becomes your new StorageClass name.
    <device_id>
    Use stable by-id paths for device identification.
  4. Apply it by running the following command:

    $ oc apply -f localvolume-block.yaml
  5. Verify the new StorageClass by running the following command:

    $ oc get storageclass local-block
  6. Optional: Make it the default StorageClass.

Verification

After the LokiStack is created, check that PVCs bind by running the following command:

$ oc get pvc -n openshift-logging
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동