#ai #kubernetes Удивительно, как быстро развивается мир моделек. Понадобилось, внезапно, по работе посмотреть большое количество логов. Да-да, есть под рукой VMui/OpenSearch/Grafana и так далее, но логов много и подов много, веб не поможет в моем дотошном осмотре. Немного специфичная задача была. Надо было прям в моменте глянуть чо там чо там на нескольких десятках подов, да ещё и с дебаг левелом. Думаю "блин, ну я вроде сам это относительно недавно делал через node proxy, даже заметку писал, дай повторю". https://t.me/makebreakreflect/205 Нашёл, зашёл, а там уныло - много команд, мне лень. Не, ну там десяток нод, десятка 4 подов, не буду же я на каждую ноду по SSH/SSM залезать, это тупо. В общем скормил мой же текст поста нейронке, говорю дай мне универсальный скрипт/команду, чтобы выкачать все файлы по фильтру неймспейса/пода, чтобы локально это исследовать. Та-да! Пару минут и у меня есть готовый скрипт. На самом деле их два - выбирайте под задачу. Мне нужен был первый вариант файлов с диска без ротации. Вариант 1: через файловую систему ноды Этот вариант ходит напрямую в /var/log/containers/ через Node Proxy API и выкачивает raw-файлы логов. Полезен, если нужно получить именно файлы с диска (например, для анализа ротации или когда нужен точный формат файла). NAMESPACE="kube-system" POD_PATTERN="kube-proxy" for POD in $(kubectl get pods -n $NAMESPACE | grep $POD_PATTERN | awk '{print $1}'); do NODE=$(kubectl get pod $POD -n $NAMESPACE -o jsonpath='{.spec.nodeName}') CONTAINER_ID=$(kubectl get pod $POD -n $NAMESPACE -o jsonpath='{.status.containerStatuses[0].containerID}' | sed 's|containerd://||') CONTAINER_NAME=$(kubectl get pod $POD -n $NAMESPACE -o jsonpath='{.spec.containers[0].name}') LOG_FILE="${POD}_${NAMESPACE}_${CONTAINER_NAME}-${CONTAINER_ID}.log" echo "⬇️ Downloading: $POD → $NODE" kubectl get --raw "/api/v1/nodes/${NODE}/proxy/logs/containers/${LOG_FILE}" > "./${POD}.log" echo "✓ Saved: ./${POD}.log" done Вариант 2: Через официальный API containerLogs Этот вариант использует документированный endpoint kubelet API. Работает с namespace/pod/container напрямую, не требует знания внутренней структуры файловой системы ноды. NAMESPACE="kube-system" POD_PATTERN="kube-proxy" for POD in $(kubectl get pods -n $NAMESPACE | grep $POD_PATTERN | awk '{print $1}'); do NODE=$(kubectl get pod $POD -n $NAMESPACE -o jsonpath='{.spec.nodeName}') CONTAINERS=$(kubectl get pod $POD -n $NAMESPACE -o jsonpath='{range .spec.containers[*]}{.name}{"\n"}{end}') for CONTAINER in $CONTAINERS; do OUTPUT_FILE="./${POD}_${CONTAINER}.log" echo "⬇️ Downloading: $POD/$CONTAINER from $NODE" kubectl get --raw "/api/v1/nodes/${NODE}/proxy/containerLogs/${NAMESPACE}/${POD}/${CONTAINER}" > "$OUTPUT_FILE" echo "✓ Saved: $OUTPUT_FILE" done done аутпут ⬇️ Downloading: kube-proxy-brpfm → aks-1 ✓ Saved: ./kube-proxy-brpfm.log ⬇️ Downloading: kube-proxy-bt6fp → aks-2 ✓ Saved: ./kube-proxy-bt6fp.log Ограничения обоих вариантов Это не стандартный документированный способ получения логов контейнеров (хотя второй вариант использует документированный endpoint kubelet, это всё равно обходной путь через nodes/proxy). Оба скрипта только для первого (индекс [0]) контейнера в поде, но мне ок по задаче. Не заработает, если: - у вашего пользователя нет прав nodes/proxy - кластер имеет ограничения на node proxy access - используется нестандартный путь для логов контейнеров (для варианта 1) - для варианта 1, если у вас не containerd, а cri-o, поправьте sed на нечто типа: sed -E 's/^(containerd:\/\/|cri-o:\/\/)//' У меня крио нет, так что я хз сработает ли