Kubernetes i niestandardowe logi. Co z nimi zrobić?

Wszyscy lubimy logi. Przydają się na przykład, gdy musimy wyśledzić jakiś błąd w naszych aplikacjach. Ale jak poradzić sobie z niestandardowymi logami, pracując z Kubernetesem? Przekonajmy się.

Logi w Kubernetesie: na początek klasycznie

Gdy uruchamiamy aplikację za pomocą Dockera i Kubernetesa, najlepiej, jeżeli nasze logi zrzucane są na standardowe wyjścia stdout i stderr. Platforma potrafi takie logi zagregować i udostępnić je nam za pomocą standardowego polecenia kubectl logs. Zobaczmy, jak to działa.

Uruchomimy sobie prostego poda, który co sekundę napisze nam coś na konsoli:

apiVersion: v1
kind: Pod
metadata:
 name: simple-logger
spec: 
 containers:
 - name: logger
 image: busybox
 args: 
 - sh 
 - -c
 - 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done'  

Możemy teraz łatwo zobaczyć, co też nasz pod ma nam do powiedzenia:

Niestandardowe logi – co z nimi począć?

Na pewno część z Was spotkała się jednak z aplikacjami, które zapisują logi i informacje o błędach w sobie tylko znanym miejscu, bez możliwości zmiany lokalizacji.

Być może na przykład ktoś zakodował kiedyś ścieżkę do pliku z logiem, a teraz my nie możemy zmienić tych ustawień. Ciężko nam będzie dostać się do danych przechowywanych w takim miejscu jak /var/log/mojaaplikacja/plik.log.

Mamy więc taką definicję poda:

apiVersion: v1
kind: Pod
metadata:
  name: dirty-logger
spec:
  containers:
  - name: logger
    image: busybox 
    args: 
    - sh 
    - -c
    - 'mkdir /var/log/ && mkdir /var/log/mojaaplikacja && i=0; while true; do echo "$i: $(date)" >> /var/log/mojaaplikacja/plik.log; i=$((i+1)); sleep 1; done'

Aby pobrać logi z takiej aplikacji, musimy dostać się do środka kontenera i je odczytać. Da się? Ano, da się:

Jak widzicie, jest to jednak mało wygodne. No i w przypadku usunięcia poda tracimy dostęp do naszych logów.

Pokażę Wam zatem, jak sobie z takim problemem poradzić.

Pomocny pod

Kubernetes to dość elastyczna platforma. A pod to niekoniecznie tylko uruchomiony kontener. W podzie możemy uruchomić także kilka kontenerów, czy dołączyć do niego jakiś wolumin jako storage. I te cechy poda pozwolą nam wybrnąć z kłopotu i „wyeksportować” logi na stdout.

Gdzie siedzą logi?

Poza kontenerem, w którym pracuje nasza krnąbrna aplikacja, do poda dodamy wolumin, na którym będą zapisywane logi. Dodatkowo dojdzie także pomocniczy kontener, który będzie nasze logi odczytywał z tego samego woluminu i wypisywał na standardowe wyjście:

Mamy więc:

1. Aplikację pracująca w głównym kontenerze.
2. Aplikację pomocniczą, pracującą w dodatkowym kontenerze, odczytującą na bieżąco logi i „wyświetlającą” je na konsoli.
3. Wolumin wewnątrz poda. Podmontowany zarówno do głównego kontenera, jak i do aplikacji pomocniczej.

Manifest dla takiego rozwiązania może wyglądać na przykład tak:

apiVersion: v1
kind: Pod
metadata:
  name: appliaction-logger
spec:
  volumes:
    - name: logsvolume
    emptyDir: {} 
  containers:
  - name: application
    image: busybox
    args: 
    - sh 
    - -c 
    - 'mkdir /var/log/ && mkdir /var/log/mojaaplikacja && i=0; while true; do echo "$i: $(date)" >> /var/log/mojaaplikacja/plik.log; i=$((i+1)); sleep 1; done'
    volumeMounts:
    - name: logsvolume
      mountPath: /var/log/mojaaplikacja/
  - name: loghelper 
  image: busybox
  args:
  - sh
  - -c 
  - 'tail -f /var/log/mojaaplikacja/plik.log'
  volumeMounts:
  - name: logsvolume
    mountPath: /var/log/mojaaplikacja/ 

Przyjrzyjmy się poszczególnym elementom naszego rozwiązania:

• 1 – to główna aplikacja
• 2 – to aplikacja pomocnicza, odczytująca logi
• 3 – fragment zaznaczony jako 3 to wolumin wewnątrz poda, czyli miejsce, w którym główna aplikacja będzie zapisywała logi
• 4 i 5 – to punkty montowania woluminu 1 do poszczególnych kontenerów wewnątrz poda

Teraz nic nie stoi już na przeszkodzie, abyśmy dostali się do logów naszej aplikacji za pomocą standardowego polecenia kubectl logs. Musimy tylko oczywiście sięgnąć do kontenera, który nasze logi udostępnia:

Gotowe!

Podsumowanie

Uruchamianie dwóch lub więcej kontenerów w jednym podzie nie jest podejściem, które powinniśmy zawsze stosować. Na przykład umieszczanie razem WordPressa i MySQL-a jest bardzo złym pomysłem.

Istnieją jednak przypadki, gdzie taki dodatkowy kontener może nas wspomóc w realizacji zadań. I wtedy warto go zastosować.