GCP에서 Loki Helm 차트 배포

원본: https://grafana.com/docs/loki/latest/setup/install/helm/deployment-guides/gcp/ (opens in a new tab)

이 가이드는 Helm 차트를 사용하여 Google Cloud Platform(GCP)에 마이크로서비스 모드로 최소한의 실행 가능한 Loki를 배포하는 방법을 보여줍니다. 이 가이드를 따르려면 다음과 같이 GCP에 리소스를 배포하는 데 필요한 도구와 권한이 있어야 합니다:

• Google Kubernetes Engine(GKE)에 대한 전체 액세스
• Google Cloud Storage(GCS)에 대한 전체 액세스
• IAM(Identity Access Management) 역할 및 정책을 생성할 수 있는 충분한 권한

Loki를 GCP GCS에 인증하고 연결하는 방법에는 두 가지가 있습니다. IAM 역할을 통해 액세스 권한을 부여하는 권장 방법인 워크로드 아이덴티티 페더레이션을 안내해 드립니다.

고려 사항

• IAM 역할: 이 가이드에서 생성된 IAM 역할은 Loki가 GCS 버킷에 읽고 쓸 수 있도록 허용하는 기본 역할입니다. 요구 사항에 따라 더 세분화된 권한을 추가할 수 있습니다.
• 인증: Grafana Loki는 기본 인증 계층과 함께 제공됩니다. 이 예에서는 Loki 게이트웨이(NGINX)가 기본 인증을 사용하여 인터넷에 노출됩니다. NGINX는 다른 오픈 소스 리버스 프록시로 대체될 수도 있습니다. 자세한 내용은 인증을 참조하십시오.
• 보존: values.yaml 파일에서 보존 기간은 28일로 설정되어 있습니다. 요구 사항에 따라 이를 조정할 수 있습니다.
• 비용: GCP에서 Loki를 실행하면 비용이 발생합니다. 예기치 않은 청구를 피하기 위해 사용량과 비용을 모니터링해야 합니다. 이 가이드에서는 3개의 노드(n2-standard-8 인스턴스)가 있는 간단한 GKE 클러스터를 사용했습니다. 워크로드에 따라 인스턴스 유형과 노드 수를 조정할 수 있습니다.

전제 조건

• Helm 3 이상. Helm 설치 (opens in a new tab)를 참조하십시오. 로컬 시스템에 설치해야 합니다.
• GCP에서 실행 중인 Kubernetes 클러스터. Google Cloud 콘솔에서 클러스터 생성 및 워크로드 배포 (opens in a new tab)를 참조하십시오.
• 로컬 시스템에 Kubectl이 설치되어 있어야 합니다. kubectl 설치 및 설정 (opens in a new tab)을 참조하십시오.
• 로컬 시스템에 gcloud CLI가 설치되어 있어야 합니다. Google Cloud CLI 설치 (opens in a new tab)를 참조하십시오. 이 가이드에서는 gcloud CLI를 사용하여 GKE 클러스터를 생성하고 로컬에서 IAM 역할 및 정책을 수정합니다.

GKE 최소 요구 사항

GKE에 Loki를 배포하기 위한 최소 요구 사항은 다음과 같습니다:

• Kubernetes 버전 1.30 이상.
• GKE 클러스터용 노드 3개.
• 인스턴스 유형은 워크로드에 따라 다릅니다. 프로덕션 클러스터의 좋은 시작점은 n2-standard-8입니다.

kubectl이 GKE를 지원하도록 하려면 gcloud kubectl 인증 플러그인을 설치하십시오:

gcloud components install gke-gcloud-auth-plugin

이 플러그인은 kubectl을 사용하여 GKE로 인증하는 데 필요합니다. 이 플러그인에 대한 자세한 내용은 여기를 클릭하십시오 (opens in a new tab).

다음은 gcloud CLI를 사용하여 새 클러스터를 생성하기 위해 실행할 수 있는 명령의 예입니다:

gcloud container clusters create loki-gcp \
  --location=europe-west4 \
  --num-nodes=1 \
  --machine-type=n2-standard-8 \
  --release-channel=regular \
  --workload-pool=<PROJECT_ID>.svc.id.goog \
  --enable-ip-alias \
  --no-enable-basic-auth \
  --no-issue-client-certificate

<PROJECT_ID>를 클러스터를 생성할 프로젝트의 ID로 바꾸십시오. 이는 my-project-123456과 같아야 합니다.

GCS 버킷 생성

Loki를 배포하기 전에 두 개의 GCS 버킷을 생성해야 합니다: 로그(청크)를 저장할 버킷과 경고 규칙(ruler)을 저장할 버킷입니다. GCP 관리 콘솔 또는 GCP CLI를 사용하여 버킷을 생성할 수 있습니다. 버킷 이름은 전역적으로 고유해야 합니다.

gcloud storage buckets create gs://<CHUNKS_BUCKET_NAME> gs://<RULER_BUCKET_NAME> \
  --location=<REGION> \
  --default-storage-class=STANDARD \
  --public-access-prevention \
  --uniform-bucket-level-access \
  --soft-delete-duration=7d

region과 bucket 이름을 원하는 값으로 바꾸십시오. 이 가이드의 뒷부분에서 버킷 정책을 다시 살펴보겠습니다.

다음은 모든 변수가 채워진 예입니다:

gcloud storage buckets create gs://loki-gcp-chunks gs://loki-gcp-ruler \
  --location=europe-west4 \
  --default-storage-class=STANDARD \
  --public-access-prevention \
  --uniform-bucket-level-access \
  --soft-delete-duration=7d

이 명령을 실행하면 다음과 같은 응답을 받게 됩니다:

Creating gs://loki-gcp-chunks/... Creating gs://loki-gcp-ruler/...

IAM 역할 및 정책 정의

IAM은 GCP에서 어떤 리소스에 누가 액세스할 수 있는지 결정하며 여러 가지 방법으로 구성할 수 있습니다. Loki가 GCS에 액세스하도록 허용하는 권장 방법은 워크로드 아이덴티티 페더레이션을 사용하는 것입니다. 이 방법은 서비스 계정 키를 생성하고 배포하는 것보다 안전합니다. 다음 단계는 gcloud CLI를 사용하여 역할과 정책을 생성하는 방법을 보여줍니다.

GKE 클러스터에 인증

클러스터에서 kubectl 명령을 실행할 수 있어야 하므로 설치되어 있는지 확인하고(설치되지 않은 경우 gcloud components install kubectl 실행) 다음 명령을 실행하십시오:

gcloud container clusters get-credentials <CLUSTER_NAME> \
  --region=<REGION>

다음은 변수가 채워진 명령의 예입니다:

gcloud container clusters get-credentials loki-gcp \
  --region=europe-west4

이렇게 하면 GCP IAM ID를 통해 인증하고 클러스터의 액세스 정보를 로컬 kubeconfig(일반적으로 ~/.kube/config)에 쓰고 kubectl 명령이 지금부터 올바른 클러스터와 통신할 수 있도록 허용합니다.

그런 다음 GKE 클러스터에 연결되어 있고 kubectl을 통해 액세스하고 있는지 확인하려면 다음을 실행하십시오:

kubectl config current-context

다음과 같은 응답을 받아야 합니다:

gke_my-project-123456_europe-west4_loki-gcp

Kubernetes 네임스페이스 생성

Loki 워크로드를 설치할 Kubernetes 네임스페이스를 생성합니다:

kubectl create namespace <NAMESPACE>

<NAMESPACE>를 Loki 워크로드가 위치할 네임스페이스로 바꾸십시오.

예시:

kubectl create namespace loki

다음과 같은 출력을 받아야 합니다:

namespace/loki created

Kubernetes 서비스 계정(KSA) 생성

KSA는 파드에 할당된 클러스터 ID(기본적으로 default라는 이름의 서비스 계정)로, 파드가 서로 상호 작용할 수 있도록 합니다.

Kubernetes 클러스터에서 KSA를 생성합니다:

kubectl create serviceaccount <KSA_NAME> \
  --namespace <NAMESPACE>

<KSA_NAME>을 위에서 생성한 KSA의 이름으로, <NAMESPACE>를 Loki 워크로드가 있는 네임스페이스로 바꾸십시오.

예시:

kubectl create serviceaccount loki-gcp-ksa \
  --namespace loki

다음과 같은 응답을 받아야 합니다:

serviceaccount/loki-gcp-ksa created

버킷에 IAM 정책 추가

이전에 생성한 KSA와 선택한 역할을 사용하여 버킷에 IAM 정책 바인딩을 생성합니다. 청크용과 눈금자용으로 각 버킷에 대해 별도의 명령을 사용하십시오.

gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
  --role=roles/storage.objectAdmin \
  --member=principal://iam.googleapis.com/projects/<PROJECT_NUMBER>/locations/global/workloadIdentityPools/<PROJECT_ID>.svc.id.goog/subject/ns/<NAMESPACE>/sa/<KSA_NAME> \
  --condition=None

<PROJECT_ID>를 GCP 프로젝트 ID(예: project-name)로, <PROJECT_NUMBER>를 프로젝트 번호(예: 1234567890)로, <NAMESPACE>를 Loki가 설치된 네임스페이스로, <KSA_NAME>을 위에서 생성한 KSA의 이름으로 바꾸십시오.

그런 다음 다른 버킷에 대해서도 동일한 작업을 수행하십시오.

예시:

gcloud storage buckets add-iam-policy-binding gs://loki-gcp-chunks \
  --role=roles/storage.objectAdmin \
  --member=principal://iam.googleapis.com/projects/12345678901/locations/global/workloadIdentityPools/my-project-123456.svc.id.goog/subject/ns/loki/sa/loki-gcp-ksa \
  --condition=None

그리고

gcloud storage buckets add-iam-policy-binding gs://loki-gcp-ruler \
  --role=roles/storage.objectAdmin \
  --member=principal://iam.googleapis.com/projects/12345678901/locations/global/workloadIdentityPools/my-project-123456.svc.id.goog/subject/ns/loki/sa/loki-gcp-ksa \
  --condition=None

다음과 같은 응답을 받아야 합니다:

bindings:
- members:
  - projectEditor:my-project-123456
  - projectOwner:my-project-123456
  role: roles/storage.legacyBucketOwner
- members:
  - projectViewer:my-project-123456
  role: roles/storage.legacyBucketReader
- members:
  - projectEditor:my-project-123456
  - projectOwner:my-project-123456
  role: roles/storage.legacyObjectOwner
- members:
  - projectViewer:my-project-123456
  role: roles/storage.legacyObjectReader
- members:
  - principal://iam.googleapis.com/projects/12345678901/locations/global/workloadIdentityPools/my-project-123456.svc.id.goog/subject/ns/loki/sa/loki-gcp-ksa
  role: roles/storage.objectViewer
etag: CAI=
kind: storage#policy
resourceId: projects/_/buckets/loki-gcp-chunks
version: 1

Helm 차트 배포

Loki Helm 차트를 배포하기 전에 Grafana 차트 저장소를 Helm에 추가해야 합니다. 이 저장소에는 Loki Helm 차트가 포함되어 있습니다.

1. Grafana 차트 저장소를 Helm에 추가합니다:

   helm repo add grafana https://grafana.github.io/helm-charts

2. 차트 저장소를 업데이트합니다:

   helm repo update

Loki 기본 인증

Loki는 기본적으로 인증 기능이 없습니다. Loki를 GCP에 배포하고 게이트웨이를 인터넷에 노출할 것이므로 최소한 기본 인증을 추가하는 것이 좋습니다. 이 가이드에서는 Loki에 사용자 이름과 암호를 부여합니다:

1. 시작하려면 사용자 이름과 암호가 포함된 .htpasswd 파일을 만들어야 합니다. htpasswd 명령을 사용하여 파일을 만들 수 있습니다:

   htpasswd 명령이 설치되어 있지 않으면 OS에 따라 brew, apt-get 또는 yum을 사용하여 설치할 수 있습니다.

   htpasswd -c .htpasswd <username>

   이렇게 하면 사용자 이름이 loki인 auth라는 파일이 생성됩니다. 암호를 입력하라는 메시지가 표시됩니다.

2. .htpasswd 파일로 Kubernetes 시크릿을 생성합니다:

   kubectl create secret generic loki-basic-auth --from-file=.htpasswd -n loki

   이렇게 하면 loki 네임스페이스에 loki-basic-auth라는 시크릿이 생성됩니다. Loki Helm 차트 구성에서 이 시크릿을 참조할 것입니다.

3. 카나리를 위한 canary-basic-auth 시크릿을 생성합니다:

   kubectl create secret generic canary-basic-auth \
     --from-literal=username=<USERNAME> \
     --from-literal=password=<PASSWORD> \
     -n loki

   Loki 카나리가 Loki 게이트웨이로 인증하기 위해 사용자 이름과 암호가 포함된 리터럴 시크릿을 생성합니다. 자리 표시자를 원하는 사용자 이름과 암호로 바꾸십시오.

Loki Helm 차트 구성

요구 사항에 가장 적합한 구성 옵션을 선택하여 values.yaml 파일을 생성합니다. 아래는 마이크로서비스 모드에서 Loki Helm 차트에 대한 values.yaml 파일의 예입니다.

loki:
  schemaConfig:
    configs:
      - from: "2024-04-01"
        store: tsdb
        object_store: gcs
        schema: v13
        index:
          prefix: loki_index_
          period: 24h
  storage_config:
    gcs:
      bucket_name: <CHUNK_BUCKET_NAME> # 실제 gcs 버킷 이름(예: loki-gcp-chunks)
  ingester:
    chunk_encoding: snappy
  pattern_ingester:
    enabled: true
  limits_config:
    allow_structured_metadata: true
  volume_enabled: true
  retention_period: 672h # 28일 보존
  compactor:
    retention_enabled: true
  delete_request_store: gcs
  ruler:
    enable_api: true
    storage_config:
      type: gcs
      gcs_storage_config:
        region: <REGION> # GCS 지역(예: europe-west4)
        bucketnames: <RULER_BUCKET_NAME> # 실제 gcs 버킷 이름(예: loki-gcp-ruler)
    alertmanager_url: http://prom:9093 # 경고를 보낼 Alertmanager의 URL(Prometheus, Mimir 등)
  querier:
    max_concurrent: 4
 
storage:
  type: gcs
  bucketNames:
    chunks: <CHUNK_BUCKET_NAME> # 실제 gcs 버킷 이름(예: loki-gcp-chunks)
    ruler: <RULER_BUCKET_NAME> # 실제 gcs 버킷 이름(예: loki-gcp-ruler)
 
serviceAccount:
  create: false
  name: <KSA_NAME>
 
deploymentMode: Distributed
 
ingester:
  replicas: 3
  zoneAwareReplication:
    enabled: false
 
querier:
  replicas: 3
  maxUnavailable: 2
 
queryFrontend:
  replicas: 2
  maxUnavailable: 1
 
queryScheduler:
  replicas: 2
 
distributor:
  replicas: 3
  maxUnavailable: 2
 
compactor:
  replicas: 1
 
indexGateway:
  replicas: 2
  maxUnavailable: 1
 
ruler:
  replicas: 1
  maxUnavailable: 1
 
# Loki 게이트웨이를 노출하여 외부에서 쓰고 쿼리할 수 있도록 함
gateway:
  service:
    type: LoadBalancer
  basicAuth:
    enabled: true
    existingSecret: loki-basic-auth
 
# 기본 인증을 사용하므로 카나리에 사용자 이름과 암호를 전달해야 함
lokiCanary:
  extraArgs:
    - -pass=$(LOKI_PASS)
    - -user=$(LOKI_USER)
  extraEnv:
    - name: LOKI_PASS
      valueFrom:
        secretKeyRef:
          name: canary-basic-auth
          key: password
    - name: LOKI_USER
      valueFrom:
        secretKeyRef:
          name: canary-basic-auth
          key: username
 
# 스토리지를 위해 minio 활성화
minio:
  enabled: false
 
backend:
  replicas: 0
read:
  replicas: 0
write:
  replicas: 0
singleBinary:
  replicas: 0

Loki 배포를 위해 유효한 values.yaml 파일을 정의하는 것이 중요합니다. 잘못된 구성의 위험을 제거하기 위해 GCP에 배포할 때 염두에 두어야 할 구성 옵션을 분석해 보겠습니다:

• Loki 구성 대 Values 구성:
  • values.yaml 파일에는 Loki 구성 파일의 직접적인 표현인 loki라는 섹션이 포함되어 있습니다.
  • 이 섹션은 스키마, 스토리지 및 쿼리어 구성을 포함한 Loki 구성을 정의합니다.
  • 청크에 대한 주요 구성은 GCS 버킷 지역과 이름을 정의하는 storage_config 섹션입니다. 이는 Loki에게 청크를 어디에 저장할지 알려줍니다.
  • ruler 섹션은 GCS 버킷 지역과 이름을 포함한 눈금자 구성을 정의합니다. 이는 Loki에게 경고 및 기록 규칙을 어디에 저장할지 알려줍니다.
  • 전체 Loki 구성은 Loki 구성 문서를 참조하십시오.
• 스토리지:
  • Helm 차트가 데이터를 어디에 저장하는지 정의합니다.
  • Amazon GCS를 사용하므로 유형을 GCS로 설정하십시오.
  • 이전에 생성한 버킷과 일치하도록 청크 및 눈금자의 버킷 이름을 구성하십시오.
  • GCS 섹션은 버킷의 지역을 지정합니다.
• 서비스 계정:
  • serviceAccount 섹션은 Loki 서비스 계정의 IAM 역할을 정의하는 데 사용됩니다.
  • 여기서 이전에 생성한 IAM 역할이 연결됩니다.
• 게이트웨이:
  • Loki 게이트웨이가 노출되는 방식을 정의합니다.
  • 이 구성에서는 LoadBalancer 서비스 유형을 사용하고 있습니다.

Loki 배포

이제 values.yaml 파일을 생성했으므로 Helm 차트를 사용하여 Loki를 배포할 수 있습니다.

1. 새로 생성한 values.yaml 파일을 사용하여 배포합니다:

   helm install --values values.yaml loki grafana/loki -n loki --create-namespace

   중요: 신뢰 정책이 IAM 역할을 loki 네임스페이스의 loki 서비스 계정에서 사용하도록 허용하도록 설정되어 있으므로 loki라는 네임스페이스를 생성하는 것이 중요합니다. 이는 구성 가능하지만 서비스 계정을 업데이트해야 합니다.

2. 배포를 확인합니다:

   kubectl get pods -n loki

   Loki 파드가 실행 중인 것을 볼 수 있습니다.

   NAME                                READY   STATUS    RESTARTS   AGE
   loki-canary-crqpg                   1/1     Running   0          10m
   loki-canary-hm26p                   1/1     Running   0          10m
   loki-canary-v9wv9                   1/1     Running   0          10m
   loki-chunks-cache-0                 2/2     Running   0          10m
   loki-compactor-0                    1/1     Running   0          10m
   loki-distributor-78ccdcc9b4-9wlhl   1/1     Running   0          10m
   loki-distributor-78ccdcc9b4-km6j2   1/1     Running   0          10m
   loki-distributor-78ccdcc9b4-ptwrb   1/1     Running   0          10m
   loki-gateway-5f97f78755-hm6mx       1/1     Running   0          10m
   loki-index-gateway-0                1/1     Running   0          10m
   loki-index-gateway-1                1/1     Running   0          10m
   loki-ingester-zone-a-0              1/1     Running   0          10m
   loki-ingester-zone-b-0              1/1     Running   0          10m
   loki-ingester-zone-c-0              1/1     Running   0          10m
   loki-querier-89d4ff448-4vr9b        1/1     Running   0          10m
   loki-querier-89d4ff448-7nvrf        1/1     Running   0          10m
   loki-querier-89d4ff448-q89kh        1/1     Running   0          10m
   loki-query-frontend-678899db5-n5wc4 1/1     Running   0          10m
   loki-query-frontend-678899db5-tf69b 1/1     Running   0          10m
   loki-query-scheduler-7d666bf759-9xqb5 1/1     Running   0          10m
   loki-query-scheduler-7d666bf759-kpb5q 1/1     Running   0          10m
   loki-results-cache-0                2/2     Running   0          10m
   loki-ruler-0                        1/1     Running   0          10m

Loki 게이트웨이 서비스 찾기

Loki 게이트웨이 서비스는 Loki 게이트웨이를 인터넷에 노출하는 LoadBalancer 서비스입니다. 여기에서 로그를 쓰고 쿼리하게 됩니다. 기본적으로 NGINX가 게이트웨이로 사용됩니다.

Loki 게이트웨이 서비스를 찾으려면 다음 명령을 실행하십시오:

kubectl get svc -n loki

외부 IP 주소를 가진 Loki 게이트웨이 서비스가 표시됩니다. 이 주소를 사용하여 Loki에 쓰고 쿼리하게 됩니다.

NAME           TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
loki-gateway   LoadBalancer   34.118.239.140   34.91.203.240   80:30566/TCP   25m

이 경우 외부 IP 주소는 34.91.203.240입니다.

축하합니다! Helm 차트를 사용하여 GCP에 Loki를 성공적으로 배포했습니다. 마치기 전에 배포를 테스트해 보겠습니다.

Loki 배포 테스트

k6는 Loki 배포를 테스트하는 가장 빠른 방법 중 하나입니다. 이를 통해 Loki에 로그를 쓰고 쿼리할 수 있습니다. k6를 시작하려면 아래 단계를 따르십시오:

1. 로컬 시스템에 Loki 확장 기능이 있는 k6를 설치합니다. k6 및 xk6-loki 확장 설치를 참조하십시오.

2. 다음 내용으로 gcp-test.js 파일을 생성합니다:

   import { sleep, check } from 'k6';
   import loki from 'k6/x/loki';
    
   /**
    * 푸시 및 쿼리 요청에 사용되는 URL
    * 경로는 클라이언트에 의해 자동으로 추가됩니다
    * @constant {string}
    */
   const username = '<USERNAME>';
   const password = '<PASSWORD>';
   const external_ip = '<EXTERNAL-IP>';
   const credentials = `${username}:${password}`;
   const BASE_URL = `http://${credentials}@${external_ip}`;
    
   /**
    * 바이트 값에 대한 도우미 상수
    * @constant {number}
    */
   const KB = 1024;
   /**
    * 바이트 값에 대한 도우미 상수
    * @constant {number}
    */
   const MB = KB * KB;
    
   /**
    * 구성 및 Loki 클라이언트 인스턴스화
    */
   const conf = new loki.Config(BASE_URL);
   const client = new loki.Client(conf);
    
   /**
    * 테스트 시나리오 정의
    */
   export const options = {
     vus: 10,
     iterations: 10,
   };
    
   export default () => {
     // 10개의 스트림과 800KB에서 2MB 사이의 압축되지 않은 로그로 요청 푸시
     var res = client.pushParameterized(10, 800 * KB, 2 * MB);
    
     // 성공적인 쓰기 확인
     check(res, {
       'successful write': (res) => res.status == 204,
     });
    
     // 레이블 풀에서 임의의 로그 형식 선택
     let format = randomChoice(conf.labels["format"]);
    
     // 제한 1로 즉시 쿼리 실행
     res = client.instantQuery(`count_over_time({format="${format}"}[1m])`, 1)
    
     // 성공적인 읽기 확인
     check(res, {
       'successful instant query': (res) => res.status == 200,
     });
    
     // 지난 5분 동안 범위 쿼리 실행 및 1000개로 제한
     res = client.rangeQuery(`{format="${format}"}`, "5m", 1000);
    
     // 성공적인 읽기 확인
     check(res, {
       'successful range query': (res) => res.status == 200,
     });
    
     // 다음 반복 전에 대기
     sleep(1);
   };
    
   /**
    * 배열에서 임의의 항목을 가져오는 도우미 함수
    */
   function randomChoice(items) {
     return items[Math.floor(Math.random() * items.length)];
   }

   <EXTERNAL-IP>를 Loki 게이트웨이 서비스의 외부 IP 주소로 바꾸십시오.

   이 스크립트는 Loki에 로그를 쓰고 Loki에서 로그를 쿼리합니다. 800KB에서 2MB 사이의 임의 형식으로 로그를 쓰고 지난 5분 동안 임의 형식으로 로그를 쿼리합니다.

3. 테스트를 실행합니다:

   ./k6 run gcp-test.js

   이렇게 하면 테스트가 실행되고 결과가 출력됩니다. 테스트가 Loki에 로그를 쓰고 Loki에서 로그를 쿼리하는 것을 볼 수 있습니다.

이제 GCP에서 마이크로서비스 모드로 Loki를 성공적으로 배포했으므로 다음을 탐색할 수 있습니다:

• Loki 클러스터 모니터링
• Loki로 데이터 보내기
• Loki 쿼리하기
• 관리