클러스터 내 Syslog를 사용하는 Rancher 로깅 운영자

Rancher Logging Operator은 여러 백엔드를 지원하지만 매우 일반적인 것은 syslog 엔드포인트에 로깅하는 것입니다. 그러나 이것이 환경의 새로운 부분인 경우 별도의 로깅 인프라를 유지하는 대신 위 UI의 방법을 사용하거나 Helm 차트를 통해 Kubernetes 클러스터에 직접 배포할 수 있습니다.

Fleet(Fleet 또는 기타 GitOps 흐름에 대해 작성함)를 통해 차트를 배포하려는 경우 Rancher 차트 저장소에서 다음 차트를 가져옵니다.

helm repo add rancher-charts https://charts.rancher.io
helm repo update
helm fetch rancher-charts/rancher-logging-crd
helm fetch rancher-charts/rancher-logging

하지만 적용하기 전에 로깅 운영자가 로깅할 수 있도록 클러스터에 syslog 엔드포인트를 설정하려고 합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rsyslog-deployment
  labels:
    app: rsyslog
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rsyslog
  template:
    metadata:
      labels:
        app: rsyslog
    spec:
      containers:
      - name: rsyslog
        image: sudheerc1190/rsyslog:latest
        ports:
        - containerPort: 514
        resources:
          requests:
            cpu: 250m
            memory: 524Mi
      restartPolicy: Always
      terminationGracePeriodSeconds: 30

여기서는 syslogDeployment를 생성합니다. 프로덕션의 경우 PersistentVolume를 생성하고 /var/log/remote에 마운트하여 이Pod의 후속 재생성에서 이 클러스터 또는 다른 클러스터에 대한 과거 로깅 데이터를 복원할 수 있도록 하는 것이 좋습니다.

이 예제에서는 클러스터 내부에서만 사용할 수 있기를 원하기 때문에 다음Service 객체를 생성하여 이 엔드포인트에 대한 전체 클러스터 DNS를 생성합니다.

---
apiVersion: v1
kind: Service
metadata:
  name: "syslog-service-tcp"
spec:
  ports:
    - port: 514
      targetPort: 514
      protocol: TCP
  type: LoadBalancer
  selector:
    app: "rsyslog"
---
apiVersion: v1
kind: Service
metadata:
  name: "syslog-service-udp"
spec:
  ports:
    - port: 514
      targetPort: 514
      protocol: UDP
  type: LoadBalancer
  selector:
    app: "rsyslog"

따라서 로깅에 사용하려는 프로토콜에 따라 syslog-service-udp.default.svc.cluster.local 와 같은 호스트 이름을 사용할 수 있습니다.

이제 CRD 및 로깅 연산자를 만들 수 있습니다.

helm install rancher-logging-crd ./rancher-logging-crd-100.1.2+up3.17.4.tgz -n cattle-logging-system --create-namespace

helm install rancher-logging ./rancher-logging-100.1.2+up3.17.4.tgz -n cattle-logging-system

이 차트의 버전은 일치해야 하며 cattle-logging-system 네임스페이스에 배포되어야 합니다.

로깅 연산자에는 두 가지Flow(및 클러스터 전체ClusterFlow ) 리소스와 Output(및 ClusterOutput ) 리소스가 있습니다. 이 예제에서는 네임스페이스에 걸쳐 있는 클러스터 범위 예제를 사용하지만 the matching rules 및 output formatting은 두 경우 모두 유사하게 작동합니다.

우리의 ClusterOutput는 포트 514에서 host: syslog-service-udp.default.svc.cluster.local를 사용하여 Syslog 서비스에 연결하는 것입니다. 이 경우에는 transport: udp를 사용합니다.

apiVersion: v1
items:
- apiVersion: logging.banzaicloud.io/v1beta1
  kind: ClusterOutput
  metadata:
    name: testing
    namespace: cattle-logging-system
  spec:
    syslog:
      buffer:
        total_limit_size: 2GB
        flush_thread_count: 8
        timekey: 10m
        timekey_use_utc: true
        timekey_wait: 1m
      format:
        app_name_field: kubernetes.pod_name
        hostname_field: custom-cluster-name
        log_field: message
        rfc6587_message_size: false
      host: syslog-service-udp.default.svc.cluster.local
      insecure: true
      port: 514
      transport: udp
kind: List

kubectl get clusteroutput/testing -n cattle-logging-system 를 사용하여 출력 상태(배포 상태, 문제 등)를 확인할 수 있습니다. ClusterOutput는 운영자 배포가 포함된 네임스페이스여야 합니다. 위 사양의 format 아래에서 로깅 필드에 대한 다른 옵션에 대해 the RFC format을 참조할 수 있습니다.
ClusterFlow 에서는 기본 규칙만 사용하고 kube-system 네임스페이스에서 로그를 제외하도록 요청한 다음 select 네임스페이스에서 applications 모든 항목을 제외하도록 요청합니다.

apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
  name: global-ns-clusterflow
spec:
  match:
    - exclude:
        namespaces:
        - kube-system
    - select:
        namespaces:
        - applications
  globalOutputRefs:
    - testing

testing 출력을 로그 전송을 위한 글로벌 엔드포인트로 사용하는 것을 볼 수 있습니다. kubectl get clusterflow/global-ns-clusterflow 를 사용하여 흐름의 상태를 확인할 수 있습니다.

나는 일반적으로 다음과 같은 배포를 사용하여 이 시점 이후에 테스트합니다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

그런 다음 제외된 네임스페이스에 한 번 배포한 다음 포함된 네임스페이스에 배포한 다음 몇 가지 요청을 만듭니다(curl -s http://{LB_IP} . 출력 및 흐름에 문제가 보고되지 않으면 몇 분 후에 로그가 채워지기 시작하는 것을 볼 수 있습니다). 그런 다음 kubectl exec -it {rsyslog_pod} -- tail -f /var/log/remote/{date hierarchy}/{hour}.log 와 같은 형식으로 로그를 수동으로 확인할 수 있습니다(외부에서 syslog를 스크래핑하는 항목이 없는 경우).

BanzaiCloud 오퍼레이터에 대한 자세한 내용은 here, 이 오퍼레이터의 Rancher 로깅 기능에 대한 자세한 내용은 here 에서 확인할 수 있습니다.