Gdy myślimy o Kubernetesie nasuwa nam się od razu – chmura*, setki serwerów i tysiące aplikacji na nich co jest w zupełności prawidłowe. Z uwagi na swoje zainteresowanie IoT, od jakiegoś czasu obserwuje projekt KubeEdge, który do tych setek workerów dorzuca wsparcie dla urządzeń Edge.

*someone else’s computer

Dla tych nie zaznajomionych z IoT (lub IIOT), Edge – to takie urządzenie (ARM/x86), które zbiera dane z innych urządzeń (lub nawet innych Edge’y), może wykonywać jakieś operacje na tych danych lub przesłać je dalej. Inne urządzenia to nic innego jak czujniki, elektrozawory, serwa itp.

Problemów, które rozwiązuje KubeEdge jest dość dużo, a ogólnie w IoT jest ich jeszcze więcej niż dużo – bo wyobraźmy sobie, że zarządzanie i monitorowanie flotą urządzeń w liczbie kilku lub kilkudziecięciu tysięcy jest bardzo ciekawym wyzwaniem. Oprócz monitorowania samych urządzeń, potrzeba również monitorować aplikacje na nich działające, zbierać logi i przesyłać je do części cloud. Zdalna konfiguracja to kolejny ważny punkt, nikt sobie przecież nie wyobraża hipotetycznej podróży do urządzenia znajdującego się gdzieś pośrodku pustyni, tylko po to, żeby zmienić flagę „false” na „true”. Prawda?
Last but not least, security – czyli jak w bezpieczny sposób umożliwić działanie tego wszystkiego.

Ludzie którzy lubią spać w nocy nie zamartwiając o powyższe, KubeEdge wydaje się być ciekawym pomysłem.

Rozwiązanie składa się z dwóch częsci – Cloud oraz Edge.

W części Cloud, najważniejszym komponentem jest CloudCore. Jest to swego rodzaju mediator pomiędzy API serwerem Kubernetesa a urządzeniami Edge. Dzięki niemu możliwe jest dodawanie Nodów jak również komunikacja z nimi (downstream i upstream). Każdy Node dodany przez KubeEdge widoczny jest jako Node w Kubernetesie.

Komunikacja dwustronna CloudCore i EdgeCore jest kluczowa gdy chcemy wdrożyć aplikację, zaktualizować konfiguracje, czy – w drugą stronę – przeczytać logi, monitorować urządzenie i aplikację na urządzeniu Edge.

W części Edge dzieje się trochę więcej, zaczynając od najnowszej funkcjonalności dodanej w 1.3 – TLS bootstrapping, która automatyzuje konfigurację szyfrowanej komunikacji EdgeCore – CloudCore. Jest to duże usprawnienie pozwalające myśleć o tym rozwiązaniu na produkcji. Dalej występują komponenty znane już z „pełnowymiarowego” Kubernetesa – CRI (Container Runtime Interface) – czyli interfejs rozumiany przez kontenery implementowany przez Dockera, Containerd czy cri-o. Jest również CSI – i nie chodzi tutaj o znany serial kręcony w Miami, a o Container Storage Interface pozwalający na wykorzystanie „driverów” do montowania zasobów do kontenerów (oczywiście przez PersistentVolumeClaim).

Kolejny element stanowi powód dlaczego zawracam sobie głowę tym rozwiązaniem, mianowicie – odczyt lub zapis informacji z lub do urządzeń które mają bezpośredni związek ze światem rzeczywistym. Wyobraźmy sobie transformator, który posiada czujnik poziomu oleju (tak, posiada w rzeczywistości) i wysyła te informacje poprzez Modbus. Ta informacje powinna być odczytana przez Edge i wysłana dalej, lub zinterpretowana i przesłana do innego modułu który np. załączy alarm.
Dzięki Mapperom w KubeEdge jest możliwe zmapowanie wartości w protokole Modbus na wartości rozumiane przez nasz system.

KubeEdge przestawiane jest jako IoT Platform, jest dość młodym rozwiązaniem co oczywiście go nie przekreśla, ale wymaga trochę testów i weryfikacji. Zaufanie może budzić produkcyjne wdrożenie KubeEdge do systemu poboru opłat na autostradzie (niestety nie udało mi się ustalić na której ╮(╯_╰)╭). Jednym z głównych kontrybutorów jest firma Huawei wykorzystująca KubeEdge na swojej chmurze.