Сети — невидимый фундамент всего, чем занимается DevOps. Их редко замечают, пока всё работает, и судорожно вспоминают, когда падает. Но в отличие от модных инструментов это знание почти не устаревает: IP, DNS, маршрутизация и порты будут с вами и через десять лет, в каком бы облаке и оркестраторе вы ни работали. Поэтому вложение окупается как мало что другое. Поймите, как имя превращается в адрес, как пакет находит дорогу и как проверять это по слоям, — и в следующий раз, когда «всё сломалось», вы не будете гадать. Вы спокойно пройдёте по лестнице сверху вниз и, скорее всего, обнаружите, что это снова был DNS.

Методичный подход важнее знания флагов: идите по слоям. Сначала имя (DNS), потом доступность (ping/route), потом порт (nc/ss), потом приложение (curl). Тот, кто проверяет по порядку, находит причину за минуты. Тот, кто гадает, — за часы.

Без сетевых основ Kubernetes кажется магией. С ними он становится логичной надстройкой над тем, что вы уже знаете. Инструменты отладки, которые стоит знать наизусть Это ваш повседневный набор. Запомните не флаги, а на какой вопрос отвечает каждый инструмент: ping — машина вообще доступна? traceroute или mtr — по какому пути идёт трафик и где он застревает? dig или nslookup — как резолвится имя и что на самом деле отдаёт DNS? curl -v — что происходит на уровне HTTP и TLS, со всеми деталями? ss (или старый netstat) — какие порты сервис реально слушает? ip addr и ip route — какие адреса и маршруты у машины? nc или telnet host port — открыт ли конкретный порт, доходит ли соединение? openssl s_client — что не так с сертификатом и TLS? tcpdump — крайнее средство: посмотреть на сами пакеты, когда всё остальное молчит.

В Kubernetes модель своя, и её важно понять: Каждый под получает собственный IP, и поды могут общаться друг с другом напрямую, без трансляции адресов. Поды эфемерны, их адреса меняются, поэтому поверх них существует Service — стабильный виртуальный адрес и имя, за которыми прячется набор подов. За назначение адресов и связность отвечает плагин CNI (Calico, Cilium, Flannel и другие). За внутренние имена отвечает CoreDNS, за маршрутизацию HTTP снаружи — Ingress, за сегментацию трафика — NetworkPolicy.

Сеть в облаке и в Kubernetes Здесь сходится всё, что выше, и начинается продвинутый уровень. В облаке вы работаете с виртуальной сетью (VPC): нарезаете подсети по CIDR, разводите публичные и приватные, ставите Internet Gateway для выхода наружу и NAT для приватных подсетей, а перед сервисами вешаете балансировщики нагрузки.

Сетевая безопасность Сеть — это и есть периметр, поэтому безопасность здесь не отдельная тема, а часть базовых навыков: Файрволы и правила доступа. В облаке это группы безопасности (на уровне инстанса, stateful, только разрешения) и сетевые ACL (на уровне подсети, stateless, есть и запреты). Принцип один: открывать минимум портов минимуму источников. Шифрование в пути. HTTPS/TLS по умолчанию, а не как опция. Внутренний трафик тоже стоит шифровать. Наименьшие привилегии в сети. Сервис должен иметь сетевой доступ только туда, куда ему действительно нужно. В Kubernetes за это отвечают сетевые политики (NetworkPolicy). VPN и приватный доступ к внутренним ресурсам вместо того, чтобы выставлять их в интернет.

Путь одного запроса (всё вместе) Чтобы связать слои воедино, проследим, что происходит, когда сервис обращается к https://api.example.com: DNS превращает имя в IP-адрес. Маршрутизация ведёт пакеты через шлюз к нужной сети. TCP-рукопожатие устанавливает соединение на порт 443. TLS-рукопожатие согласует шифрование и проверяет сертификат. HTTP-запрос уходит, приходит ответ. Любая проблема живёт на одном из этих шагов. Хороший инженер не гадает, а спрашивает по порядку: имя резолвится? маршрут есть? порт открыт? TLS поднимается? ответ корректный? Это и есть та самая отладочная дисциплина.

Маршрутизация, шлюзы и NAT Что происходит, когда пакету нужно покинуть свою подсеть? Он идёт на шлюз по умолчанию (default gateway). На каждой машине есть таблица маршрутизации, которая говорит: «в эту сеть — туда, всё остальное — на шлюз». Отдельная важная штука — NAT (трансляция адресов). Машины с приватными адресами не видны в интернете, поэтому при выходе наружу их адрес подменяется на внешний. В облаке за это отвечает NAT-шлюз: он выпускает приватные подсети в интернет, не делая их доступными извне. Зачем это знать: типичная облачная схема — приватные подсети с базами и бэкендами, которые ходят в интернет через NAT, и публичные подсети для того, что должно быть доступно снаружи. Понимание маршрутов отвечает на вопрос «почему мой сервис может скачать обновление, но к нему самому не подключиться».

DNS: телефонная книга интернета Люди помнят имена, а сеть работает с адресами. DNS переводит имя вроде api.example.com в IP. Упрощённо это происходит так: ваш резолвер спрашивает корневые серверы, те направляют к серверам зоны (.com), те — к авторитетному серверу домена, который и отдаёт нужный адрес. Ответ кешируется на время, заданное в TTL, чтобы не спрашивать каждый раз заново. Базовые типы записей: A (имя на IPv4), AAAA (на IPv6), CNAME (псевдоним на другое имя), MX (почта), TXT (произвольный текст, часто для проверок), NS (серверы имён зоны). Почему «всегда DNS»: именно из-за кеша и TTL. Вы поменяли адрес, а полмира ещё несколько часов или суток ходит по старому, потому что у них закешировался прежний ответ. Добавьте сюда опечатку в записи или забытый внутренний резолвер — и получите классический сбой, который выглядит как «приложение сломалось», хотя сломалось имя. В Kubernetes за внутренние имена сервисов отвечает CoreDNS, и его сбой кладёт обнаружение сервисов по всему кластеру.