Rancher Logging Operator с внутрикластерным Syslog

Rancher Logging Operator поддерживает ряд бэкендов, но очень распространенным является ведение журнала на конечную точку syslog. Однако вместо того, чтобы поддерживать отдельную инфраструктуру протоколирования, если это новая часть вашей среды, вы можете развернуть ее на кластерах Kubernetes напрямую, либо используя метод в UI выше, либо с помощью диаграммы Helm.

Если вы планируете развертывать диаграммы через 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
Войти в полноэкранный режим Выход из полноэкранного режима

Здесь мы просто создаем syslog Deployment; для производства я бы рекомендовал создать 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) ресурсы и OutputClusterOutput) ресурсы. В этом примере будут использоваться только кластерно-копируемые примеры, которые охватывают пространства имен, но правила сопоставления и форматирование вывода будут работать одинаково в обоих случаях.

Наш ClusterOutput будет тем, что соединяется с нашей службой Syslog, используя host: syslog-service-udp.default.svc.cluster.local на порту 514, в данном случае используя 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, вы можете обратиться к формату RFC для других вариантов полей протоколирования.

В нашем 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 в качестве глобальной конечной точки для отправки журналов. Вы можете проверить состояние Flow, используя 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}, если вывод и поток не сообщают о проблемах, вы увидите, что журналы начнут заполняться через несколько минут). Затем вы можете проверить журналы вручную (если ничто не скребет syslog извне) с помощью команды kubectl exec -it {rsyslog_pod} -- tail -f /var/log/remote/{date hierarchy}/{hour}.log.

Подробнее об операторе BanzaiCloud можно прочитать здесь, а подробнее о возможностях ведения журнала в Rancher с помощью этого оператора можно прочитать здесь.

Оцените статью
Procodings.ru
Добавить комментарий