ロギング¶

ログプロセッサおよびフォワーダーであるFluent Bitを使用して、中央ディレクトリにKubernetesログを収集できます。これはKnativeの実行には必須ではありませんが、必要に応じてポッドと関連ログを自動的に削除するKnative Servingに役立ちます。

Fluent Bitは、他の多くのログプロバイダーへのエクスポートをサポートしています。Splunk、Datadog、ElasticSearch、Stackdriverなど、既存のログプロバイダーを使用している場合は、FluentBitドキュメントに従ってログフォワーダーを設定できます。

ロギングコンポーネントの設定¶

ログ収集の設定には、2つの手順が必要です。

各ノードでログ転送DaemonSetを実行する。
クラスタ内のどこかでコレクタを実行する。

ヒント

次の例では、ログをKubernetes PersistentVolumeClaimに保存するStatefulSetを使用していますが、HostPathを使用することもできます。

コレクタの設定¶

fluent-bit-collector.yamlファイルは、StatefulSetと、クラスタ内からログへのアクセスと読み取りを許可するKubernetesサービスを定義します。提供された構成により、loggingという名前空間で監視構成が作成されます。

重要

フォワーダーの前にコレクタを設定してください。フォワーダーの設定にはコレクタのアドレスが必要であり、コレクタの準備が整うまでフォワーダーはログをキューに入れる可能性があります。

System diagram: forwarders and co-located collector and nginx

手順¶

次のコマンドを入力して構成を適用します。
```
kubectl apply -f https://github.com/knative/docs/raw/main/docs/serving/observability/logging/fluent-bit-collector.yaml
```
デフォルトの構成では、ログは次のように分類されます。
- Knativeサービス、またはapp=Knativeラベルが付いたポッド。
- Knative以外のアプリ。
注意

ログはデフォルトでポッド名を使用してログ記録されます。これは、インストールの前後に関わらず、log-collector-configConfigMapを更新することで変更できます。

警告

ConfigMapを更新した後、Fluent Bitを再起動する必要があります。これを行うには、ポッドを削除してStatefulSetによって再作成させます。
ウェブブラウザでログにアクセスするには、次のコマンドを入力します。
```
kubectl port-forward --namespace logging service/log-collector 8080:80
```
https://#:8080/に移動します。
オプション：次のコマンドを入力して、nginxポッドでシェルを開き、Unixツールを使用してログを検索できます。
```
kubectl exec --namespace logging --stdin --tty --container nginx log-collector-0
```

フォワーダーの設定¶

Fluent Bitドキュメントを参照して、デフォルトでElasticSearchにログを転送するFluent Bit DaemonSetを設定してください。

インストール手順中にConfigMapを作成する場合は、次の操作を行う必要があります。

fluent-bit-configmap.yamlでElasticSearch構成を置き換えるか、

次のブロックをConfigMapに追加し、@INCLUDE output-elasticsearch.confを@INCLUDE output-forward.confに更新します。

output-forward.conf: |
  [OUTPUT]
      Name            forward
      Host            log-collector.logging
      Port            24224
      Require_ack_response  True

ローカルコレクタの設定¶

警告

この手順は開発環境の設定について説明しており、本番環境には適していません。

開発用にローカルKubernetesクラスタを使用している場合は、デスクトップオペレーティングシステムにログを保存するhostPathPersistentVolumeを作成できます。これにより、Kubernetes固有のツールを必要とせずに、通常のデスクトップツールをファイルで使用できます。

PersistentVolumeClaimは次のようになります。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: shared-logs
  labels:
    app: logs-collector
spec:
  accessModes:
    - "ReadWriteOnce"
  storageClassName: manual
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: logs-log-collector-0
    namespace: logging
  capacity:
    storage: 5Gi
  hostPath:
    path: <see below>

注意

hostPathは、Kubernetesソフトウェアとホストオペレーティングシステムによって異なります。

次の例に示すように、shared-logsボリュームを参照するようにStatefulSet volumeClaimTemplatesを更新する必要があります。

volumeClaimTemplates:
  metadata:
    name: logs
  spec:
    accessModes: ["ReadWriteOnce"]
    volumeName: shared-logs

Kind¶

クラスタを作成する際に、kind-config.yamlを使用し、次の例に示すように各ノードのextraMountsを指定する必要があります。

apiversion: kind.x-k8s.io/v1alpha4
kind: Cluster
nodes:
  - role: control-plane
    extraMounts:
      - hostPath: ./logs
        containerPath: /shared/logs
  - role: worker
    extraMounts:
      - hostPath: ./logs
        containerPath: /shared/logs

その後、PersistentVolumeでspec.hostPath.pathとして/shared/logsを使用できます。ディレクトリパス./logsは、Kindクラスタが作成されたディレクトリに対する相対パスであることに注意してください。

Docker Desktop¶

Docker Desktopは、ホストとゲストオペレーティングシステム間でいくつかの共有マウントを自動的に作成するため、ホームディレクトリへのパスを知るだけで済みます。異なるオペレーティングシステムの例をいくつか示します。

ホストOS	`hostPath`
Mac OS	`/Users/${USER}`
Windows	`/run/desktop/mnt/host/c/Users/${USER}/`
Linux	`/home/${USER}`

Minikube¶

Minikubeでは、Kubernetesを実行している仮想マシン（VM）にディレクトリをマウントするための明示的なコマンドが必要です。

次のコマンドは、現在のディレクトリ内のlogsディレクトリをVMの/mnt/logsにマウントします。

minikube mount ./logs:/mnt/logs

PersistentVolumeでhostPath.pathとして/mnt/logsを参照する必要もあります。