Po poprzedniej części zapraszam na kolejną, pokazującą jak poradzić sobie z ograniczeniami które wprowadza Kubernetes podczas debugowania aplikacji sieciowych.
Wykonanie pojedynczego polecenia/shelll
kubectl -n my_namespace exec -it pod -- /bin/some_command
Gdzie zwykle /bin/some_command można zastąpić /bin/bash
Kontener do debugowania
kubectl debug my_pod_name -n my_namespace -it --image=ubuntu:latest /bin/bash
Powyższe spowoduje uruchomienie nowego kontenera w tym samym podzie. Dzięki temu możemy połączyć się do localhost (127.0.0.1) i sprawdzić jak działają nasze serwisy za pomocą curl/wget. W trybie debug mamy też dostęp do roota, dzięki czemu hardening właściwej aplikacji nie jest aż tak straszny i nie ogranicza nas, np. w zainstalowaniu nowych paczek. Taki kontener nie współdzieli też systemu plików z oryginalnymi kontenerami z poda, dzięki temu nie namieszamy zbyt dużo.
Lepszy kontener do debugowania
kubectl debug my_pod_name -n my_namespace -it --image=ubuntu:latest --share-processes -c container_name --copy-to=mg-debug
Jest to trochę bardziej rozbudowana wersja poprzedniego polecenia. Odpalając taki kontener do debugowania możemy wybrać jeden z istniejących kontenerów i kubectl skopiuje jego konfiguracje (zamontowane volumes, sieć i przestrzeń procesów). Zabawa w takim środowisku daje już dość duże możliwości interakcji z innymi kontenerami. Można wysłać przyjacieski sygnał -KILL do procesów, pogrzebać w podmontowanych wolumenach lub sprawdzić sieć, również bez ograniczeń hardeningu.
Shell noda
Link dla zdesperowanych: https://github.com/kvaps/kubectl-node-shell. Skrypt potrafi uruchomić shell na nodzie kubernetesa. Dzięki niemu możemy dostać się jako root na dowolnego noda z klastra jako root i wprost pogrzebać w systemie. Chyba najbardziej “wszechmocna” opcja do zabawy w szukanie dziury w całym.
Miłego debugowania!