Сеть: от имени приложения до ответа

Практика через терминал портала

1. Подготовь сетевую неисправность

   Сначала получи зачёт Deployment и очисти его. Открой сетевое задание, нажми подготовку. Все команды этой части работают только с interview-lab.

   kubectl -n interview-lab get pods,service -o wide

   Что должно получиться. Есть portal-net и portal-client. Имена и симптомы соответствуют сетевому заданию.

   Если результат отличается

   Если видны portal-demo или portal-image, открыто другое упражнение. Не применяй к нему сетевые исправления.

2. Проверь сервер и выбранные адреса

   Сравни метки, selector и EndpointSlice. Отдельно найди port и targetPort.

   kubectl -n interview-lab get service portal-net -o yaml
   kubectl -n interview-lab get pods --show-labels
   kubectl -n interview-lab get endpointslices -l kubernetes.io/service-name=portal-net -o yaml

   Что должно получиться. Ты видишь, что сервисный порт и порт приложения отличаются. Адреса не нужно придумывать вручную.

   Если результат отличается

   Пустой список адресов требует проверки selector и Ready, а не редактирования DNS (Domain Name System — система доменных имён).

3. Увидь ошибку имени

   Посмотри настройки DNS (Domain Name System — система доменных имён) учебного клиента. Команда nslookup выполняется внутри контейнера, где возникает проблема.

   kubectl -n interview-lab get deployment portal-client -o yaml
   kubectl -n interview-lab exec deployment/portal-client -- nslookup portal-net.interview-lab.svc.cluster.local

   Что должно получиться. У клиента неправильная политика DNS (Domain Name System — система доменных имён) и адрес 127.0.0.1. Ошибка имени записана до исправления.

   Если результат отличается

   При ошибке exec проверь, что клиентский Pod уже Running. Не редактируй CoreDNS общего кластера.

4. Исправь клиента

   Верни стандартное разрешение имён кластера и убери неправильный пользовательский сервер DNS (Domain Name System — система доменных имён).

   kubectl -n interview-lab patch deployment portal-client --type=merge -p '{"spec":{"template":{"spec":{"dnsPolicy":"ClusterFirst","dnsConfig":null}}}}'
   kubectl -n interview-lab rollout status deployment/portal-client --timeout=90s
   kubectl -n interview-lab exec deployment/portal-client -- nslookup portal-net.interview-lab.svc.cluster.local

   Что должно получиться. Имя разрешается. Это промежуточный успех, ещё не доказательство работы сайта.

   Если результат отличается

   Если rollout ждёт, прочитай Events и квоту. Не добавляй внешние серверы DNS (Domain Name System — система доменных имён) вместо кластерного.

5. Исправь порт и проверь содержимое

   У сервера именованный порт http указывает на 8080. Service должен ссылаться на него. После исправления сравни ответ с маркером задания.

   kubectl -n interview-lab patch service portal-net --type=json -p '[{"op":"replace","path":"/spec/ports/0/targetPort","value":"http"}]'
   kubectl -n interview-lab exec deployment/portal-client -- wget -qO- http://portal-net

   Что должно получиться. Получена учебная страница, а не только установленное соединение. Нажми «Проверить результат».

   Если результат отличается

   Имя разрешается, но ответа нет: снова проверь targetPort, Ready и слушающий процесс.

6. Узнай возможности текущей сети

   Эти команды только читают конфигурацию. Не устанавливай новый плагин на общий кластер.

   kubectl -n kube-flannel get daemonset
   kubectl get networkpolicy -A
   kubectl get services -A

   Что должно получиться. В журнале указана фактическая реализация сети и отдельно статус «исполнение политик здесь не доказано».

   Если результат отличается

   Отсутствие политик не говорит о способности плагина их исполнять. Наличие политики тоже не является положительным тестом.

7. Проверь изоляцию на отдельном стенде

   По инструкции создай отдельный kind с отключённым стандартным плагином и установи совместимый Cilium. Затем используй network-policy.yaml. Проверь исходную связь, запрет и выборочное разрешение; не начинай с запрета на общем стенде.

   kubectl --context kind-kaas-net -n kaas-lab get pods,networkpolicy
   kubectl --context kind-kaas-net -n kaas-lab apply -f https://test.igorhome.ru/static/learning/network-policy.yaml

   Что должно получиться. Записаны результаты до и после политики для разрешённого и запрещённого клиента. Одного apply недостаточно.

   Если результат отличается

   Если нет готового сетевого плагина или клиентов, остановись и выполни подготовку из инструкции. Оставь критерии изоляции неотмеченными.

8. Нарисуй полный путь

   В заметках запиши имя, адрес, порт клиента, порт приложения и границу облака. Очисти готовое задание штатной кнопкой. Внешний Gateway исследуется отдельно, когда установлен его контроллер.

   kubectl -n interview-lab get service portal-net -o wide

   Что должно получиться. Есть объяснение двух разных неисправностей и схема публикации будущего приложения.

   Если результат отличается

   Не добавляй внешний адрес в схему как существующий без фактического запроса извне.

Открыть терминал ↗ · Скачать файлы лаборатории →

Файлы и подготовка к этой работе

• Подготовка отдельного стенда и правила работы ↗

Критерии готовности

Отмечай только то, что проверил на указанном стенде. Эти галочки сохраняются в браузере. Для готовых упражнений зачёт выдаёт отдельная серверная проверка практикума; остальные задания подтверждай журналом и доказательствами. Учебная модель не заменяет реальный облачный опыт.

Что сохранить в портфолио

• Журнал: исходное состояние → команда или действие → ожидаемый результат → фактическое наблюдение.
• Доказательства по критериям ниже: очищенный от секретов вывод, схема или ссылка на проверенный коммит.
• Отдельный список: что пока не запускалось, почему и какой стенд нужен для продолжения.

Проверь понимание

8 вопросов по этому модулю. Проходной результат — 7 из 8. После ответа — объяснения и ссылки на разделы, к которым стоит вернуться.