port-forward и proxy
Тема дорожной карты · Kubernetes
kubectl port-forward туннелирует трафик с локального порта на порт Pod'а или Service, работающего внутри кластера Kubernetes, что делает его основным инструментом для тестирования и отладки нагрузок без их публичного раскрытия. Команда kubectl port-forward pod/<pod-name> 8080:80 привязывает localhost:8080 к порту 80 целевого Pod'а, тогда как kubectl port-forward svc/<service-name> 5432:5432 работает с Service Kubernetes, позволяя kube-proxy кластера определить нужный Pod. Поскольку соединение проходит через kube-apiserver и механизм Kubernetes API, не требуется ни Ingress, ни LoadBalancer, ни NodePort — это делает kubectl port-forward идеальным для безопасного доступа к базам данных вроде PostgreSQL или Redis, а также для просмотра дашбордов Prometheus и Grafana на staging. Туннель остаётся открытым до завершения процесса, а несколько правил перенаправления можно объединить в одном вызове, разделив пары портов пробелами.
Как это работает
port-forward и proxy — операция kubectl, которая общается с API-сервером Kubernetes. CLI читает ваш kubeconfig (по умолчанию ~/.kube/config), аутентифицирует (token, сертификат или OIDC), отправляет HTTPS-запрос API-серверу и печатает ответ. Для команд, изменяющих состояние (apply, patch, delete), API-сервер валидирует запрос, сохраняет в etcd и триггерит соответствующие контроллеры.
Когда применять
Используйте port-forward и proxy в ежедневных операциях кластера: инспектирование текущего состояния (kubectl get/describe), применение декларативных изменений (kubectl apply -f), отладка pods (kubectl logs/exec), валидация конфигов перед деплоем. Для повторяющихся workflow оборачивайте в shell-скрипты или Helm chart; для one-off отладки kubectl напрямую быстрее, чем писать инструменты.
Типичные ошибки
Распространённые ловушки kubectl: забыли -n <namespace> и инспектируете не тот namespace; используете kubectl edit на production-ресурсах (нет audit trail — используйте GitOps); копипаст из Stack Overflow без чтения, что удаляется. Всегда выполняйте kubectl config current-context перед деструктивными командами, чтобы убедиться, что указываете на правильный кластер.