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) ресурсы и Output (и ClusterOutput) ресурсы. В этом примере будут использоваться только кластерно-копируемые примеры, которые охватывают пространства имен, но правила сопоставления и форматирование вывода будут работать одинаково в обоих случаях.
Наш 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 с помощью этого оператора можно прочитать здесь.