Default backend 404 как исправить

I started to use Kubernetes few month ago and I actually migrate my microServices to my rancher cluster (RKE). Everything works good, my deployments are good and services too. I would like use ingress.

Everything looks good, services are find by ingress and pods are find by services. However when I try to go to the website, I have a 404 error page from ingress controller.

You can see my configuration for juste two paths : one nginx and on grafana.
Someone knows how can i fix it and use ingress to do my reverse proxy ?

Thank you so much for your help.

I trie to use rewrite-target without result and add-base-url is deprecated.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    field.cattle.io/creatorId: user-cg5r7
    field.cattle.io/ingressState: '{"bXktaW5ncmVzcy9kZWZhdWx0L3d3dy5zY29sLWVhLm92aC8vbmdpbngvNDI=":""}'
    field.cattle.io/publicEndpoints: '[{"addresses":["51.68.226.21"],"port":80,"protocol":"HTTP","serviceName":"default:nginx-services","ingressName":"default:my-ingress","hostname":"www.scol-ea.ovh","path":"/nginx","allNodes":true}]'
  creationTimestamp: "2019-08-31T10:54:25Z"
  generation: 2
  labels:
    cattle.io/creator: or antoine
  name: my-ingress
  namespace: default
  resourceVersion: "106239"
  selfLink: /apis/extensions/v1beta1/namespaces/default/ingresses/my-ingress
  uid: b27b7b20-cbdd-11e9-b16b-fa163ea73397
spec:
  rules:
  - host: www.scol-ea.ovh
    http:
      paths:
      - backend:
          serviceName: nginx-sample
          servicePort: 80
        path: /nginx
      - backend:
          serviceName: prometheus-grafana
          servicePort: http
        path : /grafana

------------------------
apiVersion: v1
kind: Service
metadata:
  annotations:
    field.cattle.io/targetWorkloadIds: '["deployment:default:nginx-sample"]'
    workload.cattle.io/targetWorkloadIdNoop: "true"
    workload.cattle.io/workloadPortBased: "true"
  creationTimestamp: "2019-08-31T10:03:47Z"
  labels:
    cattle.io/creator: norman
  name: nginx-sample
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1beta2
    controller: true
    kind: deployment
    name: nginx-sample
    uid: 57af9603-cb2a-11e9-b16b-fa163ea73397
  resourceVersion: "102071"
  selfLink: /api/v1/namespaces/default/services/nginx-sample
  uid: 9fffe98c-cbd6-11e9-b16b-fa163ea73397
spec:
  clusterIP: 10.43.183.187
  ports:
  - name: 80tcp02
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    workload.user.cattle.io/workloadselector: deployment-default-nginx-sample
  sessionAffinity: None
  type: ClusterIP

----------------------------
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2019-08-30T13:44:00Z"
  labels:
    app: prometheus-grafana
    chart: grafana-0.0.31
    heritage: Tiller
    io.cattle.field/appId: prometheus
    release: prometheus
  name: prometheus-grafana
  namespace: default
  resourceVersion: "2536"
  selfLink: /api/v1/namespaces/default/services/prometheus-grafana
  uid: 38ebd878-cb2c-11e9-b16b-fa163ea73397
spec:
  clusterIP: 10.43.142.143
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 3000
  selector:
    app: prometheus-grafana
  sessionAffinity: None
  type: ClusterIP

NGINX Ingress controller version: Latest

What happened:
When deploying the docker-registry using the example provided on this repository and using a non-root path docker is unable to push images.

What you expected to happen:
Be able to push images to non-root paths

How to reproduce it (as minimally and precisely as possible):

I just followed the docker-registry example and added a non-root path using REGISTRY_HTTP_PREFIX in the deployment.

Anything else we need to know:

Deployment.yml

apiVersion: v1
kind: Namespace
metadata:
  name: docker-registry

---

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: docker-registry
  namespace: docker-registry
spec:
  replicas: 1
  selector:
    matchLabels:
      app: docker-registry
  template:
    metadata:
      labels:
        app: docker-registry
    spec:
      containers:
        - name: docker-registry
          image: registry:2.6.2
          env:
            - name: REGISTRY_HTTP_ADDR
              value: ":5000"
            - name: REGISTRY_HTTP_PREFIX
              value: "/registry/"
            - name: REGISTRY_HTTP_HOST
              value: "<mydomain>"
            - name: REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY
              value: "/var/lib/registry"
          ports:
          - name: http
            containerPort: 5000
          volumeMounts:
          - name: image-store
            mountPath: "/var/lib/registry"
      volumes:
        - name: image-store
          emptyDir: {}

---

kind: Service
apiVersion: v1
metadata:
  name: docker-registry
  namespace: docker-registry
  labels:
    app: docker-registry
spec:
  selector:
    app: docker-registry
  ports:
  - name: http
    port: 5000
    targetPort: 5000

Ingress Rule

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/rewrite-target: "/registry/"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
    kubernetes.io/tls-acme: 'true'
  name: docker-registry
  namespace: docker-registry
spec:
  tls:
  - hosts:
    - <mydomain>
    secretName: registry-tls
  rules:
  - host: <mydomain>
    http:
      paths:
      - backend:
          serviceName: docker-registry
          servicePort: 5000
        path: /registry/ 

Note:

Visiting https://mydomain.com/registry/v2/_catalog from a browser works fine and I get a respond back from the registry.

Ex.

docker pull alpine:latest
docker tag alpine:latest mydomain.com/registry/alpine:latest
docker push mydomain.com/registry/alpine:latest

When doing a push I get default backend 404.

I’m not sure if this is an issue with Docker, Registry, NGINX Ingress, or what.

При загрузке любимого сайта вы можете внезапно увидеть сообщение об ошибке 404, гласящем, что «требуемая страница, ресурс или документ не найден». Обычно данная проблема появляется в той ситуации, когда сервер не смог найти у себя запрашиваемую вами страницу, и выдал ответ в форме четыреста четвёртой ошибки. В этом посте я расскажу, в чём суть ошибки 404, каковы причины её возникновения, и как избежать её появления на экране вашего ПК.

Что значит ошибка 404?

Код ошибки 404 – это код статуса ответа HTTP, означающий, что «ресурс в запрашиваемой локации не найден».

Когда вы встречаете ошибку с таким номером, то это обычно означает, что между клиентом (вашим компьютером) и отдалённым сервером установлено стабильное соединение, но указанный сервер не смог найти у себя запрашиваемую вами страницу (документ).

Сообщение с данной ошибкой выглядит по-разному, в частности вот так:

Каждое число из данной ошибки имеет своё значение:

• Первая цифра «4» – означает, что это ошибка клиента (не сервера);
• Следующие цифры (04) – определяют спецификацию данной ошибки.

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

Или так:

Или так:

Надеюсь вы поняли, что это 404 ошибка, а теперь перейдём к причинам и устранению проблем с кодом 404.

Читайте также: Как отключить https (в браузере Яндекс, Google Chrome, Вконтакте).

Причины дисфункции 404

Обычно подобная ошибка возникает по следующим причинам:

• Запрашиваемый пользователем URL набран некорректно (достаточно лишь одного неверно набранного в ссылке символа, чтобы возникла 404 ошибка);
• Запрашиваемая пользователем страница была удалена (перенесена) веб-мастером сайта, обычно без редиректа, который бы автоматически переводил пользователя на новую страницу;
• Сервер, ответственный за работу этого сайта не работает, или соединение прервано;
• В появлении данной ошибки виноват действующий в вашей системе зловред (для веб-мастеров);
• Запрашиваемый домен заблокирован вашим провайдером (ISP);
• Запрашиваемый домен не существует.

  

  Примеры спецификаций ошибки у серверов Майкрософт IIS

При этом сервера Майкрософт IIS часто добавляют специальную информацию по причинам, вызывающим ошибку 404, в частности, HTTP Error 404.1 – «Сайт не найден» и другие.

Как исправить 404 ошибку

Чтобы исправить данную проблему необходимо выполнить следующее:

• Перезагрузите страницу (в частности, путём нажатия на F5), или запросите её вновь путём ввода её адреса в адресную строку вашего браузера и нажатия на «Enter»;
• Убедитесь, что запрашиваемая вами ссылка набрана верно. Внимательно проверьте каждую букву (символ) в ссылке на предмет наличия ошибки, ведь достаточно лишь одного некорректно введённого символа чтобы воочию встретиться с ошибкой четыреста четыре;
• Пройдите на один уровень выше в запрашиваемой вами ссылке. Если вы, к примеру, используете ссылку:

www.mail.ru/example

то наберите просто:

www.mail.ru

дабы убедиться, что ресурс (домен) работает корректно, а проблема возникает лишь с запрашиваемой вами страницей. Если это так, стоит уведомить веб-мастера данного ресурса о возникшей дисфункции.

• Очистите кэш и куки вашего браузера, особенно в ситуации, когда вы уже сталкивались с данной ошибкой ранее;
• Поищите вашу страницу через поисковые системы Гугл, Яндекс, Бинг и др. (если помните название страницы или её тематику). Если данная страница не будет найдена, значит, существует вероятность, что она полностью удалена из сети;
• Измените адрес используемого вами по умолчанию ДНС-сервера. Ошибка четыреста четыре может появляться в ситуации, когда ваше государство (провайдер) блокирует (фильтрует) определённые веб-сайты. Для смены ДНС нажмите Win+R, в появившейся строке введите ncpa.cpl и нажмите ввод. В перечне подключений найдите ваше интернет-подключение, наведите на него курсор, нажмите правую клавишу мыши, выберите «Свойства». В списке компонентов найдите «IPv4», дважды кликните на нём, активируйте опцию «Использовать следующие адреса ДНС-серверов», и впишите там следующие значения от ГУГЛ:

8.8.8.8

8.8.4.4

Нажмите на «Ок», и перезагрузите ваш ПК;

• Осуществите проверку на наличие вирусов в вашей системе, некоторые из них могут вызывать данную ошибку на вашем сайте (для веб-мастеров);
• Убедитесь, что SSL-сертификат установлен корректно в ситуации, когда ошибка четыреста четыре возникла после установки SSL-сертификата;
• Проверьте, не достигли ли вы лимитов памяти. Если да – увеличьте указанный лимит (актуально для веб-мастеров);
• Если ваш веб-сайт базируется на «Wordpress», необходимо вновь сгенерировать файл .htaccess. В панели администрирования перейдите в «Настройки» (Settings) – «Пермалинки» (Permalinks), а затем нажмите на кнопку «Сохранить изменения» (Save Changes).

Заключение

Что такое ошибка под номером 404? Обычно ошибка возникает в ситуации, когда пользователь неверно набрал нужный линк, или запрашиваемая пользователем страница ранее была удалена (перемещена) веб-мастером ресурса. Для исправления проблемы рекомендую воспользоваться приведёнными выше советами, они помогут вам избежать появления ошибки четыреста четыре на вашем ПК.

I’m trying to set up a very simple Kubernetes cluster with frontend, backend and db services. Here is part of the Frontend service definition file:

apiVersion: v1
kind: Service
metadata:
  name: frontend
  labels:
    tier: frontend
spec:
  selector:
    tier: frontend
  ports:
  - port: 80
    nodePort: 30080
  type: LoadBalancer

When I access the cluster’s IP at port 30080 everything is working properly.

Now I’m trying to set up an Ingress that will work at port 80 (in preparation for deploying the cluster to Azure). I want to direct all HTTP traffic to the frontend, as this is the only HTTP service in my cluster. So the ingress definition file is as follows:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: zippori
  annotations:
    kubernetes.io/ingress.class: addon-http-application-routing
spec:
  backend:
    serviceName: frontend
    servicePort: 80

However, when I access http://minikube-ip I get the following very simple error:

default backend — 404

It is as if Ingress doesn’t forward anything to my frontend, and just tries its own default backend.

How can I fix this?

Ошибка 404, либо Error 404 Not Found — ошибка, которая появляется, если браузеру не удалось обнаружить на сервере указанный URL.

Что означает ответ 404

Error 404 Not Found отображается по-разному: «HTTP 404 не найден», «Ошибка 404 Not Found», «404 Страница не найдена». Смысл надписи всегда остаётся тем же: страница отсутствует либо просто не работает. Not Found в переводе означает «не найдено».

Ошибка 404 — классический код ответа по протоколу HTTP. Он свидетельствует, что связь с сервером установлена, но данных по заданному запросу на сервере нет.

Однако если просто ввести в поисковую строку произвольный набор символов, то браузер не покажет ошибку 404 Not Found — появится сообщение, что установить соединение с конкретным сервером невозможно.

Разберёмся в техническом формировании ответа Error 404 Not Found.

Техническая сторона вопроса. При связи по HTTP браузер запрашивает указанный URL и ждёт цифрового ответа. То есть любой запрос пользователя направляется на сервер размещения искомого сайта. Когда браузеру удаётся связаться с сервером, он получает кодированный ответ. Если запрос корректный и страница найдена, отправляется ответ с кодом 200 OK, что соответствует благополучной загрузке. При отсутствии страницы отправляется ответ об ошибке.

Что значит код «404». В ответе 404 первая четвёрка указывает на то, что запрос был чрезмерно длительным или в самом адресе была ошибка. Ноль предполагает синтаксическую неточность. Завершающая цифра кода отображает конкретную причину ошибки — «4» означает отсутствие данной ссылки.

Какие ещё ошибки бывают. Ошибку 404 не нужно путать с другими ответами, которые указывают на невозможность связи с сервером. Например, ошибка 403 сообщает, что доступ к URL ограничен, а ответ «Сервер не найден» свидетельствует, что браузер не смог обнаружить место размещения сайта.

Причины ошибки

Причины, по которым HTTP возвращает ответ 404 Not Found:

• Неверный адрес. К примеру, при ручном наборе пользователь допустил опечатку в адресе либо ссылка ведёт на несуществующую страницу. При этом домен должен быть написан верно. Если пользователь ошибется в названии домена, страница вообще не загрузится (без показа ошибки).
• Битая ссылка. Это нерабочий URL, который никуда не ведёт. Данный вариант иногда возникает при внутренней перелинковке. К примеру, раньше страница существовала, а потом её удалили и забыли убрать ссылку.
• Удалённая страница. Когда пользователь попытается перейти на удалённую с сервера страницу, он также увидит ошибку 404. Ссылка для перехода может сохраниться в браузерных закладках или на сторонних ресурсах.
• Неправильный редирект на страницу с изменённым адресом. Допустим, в процессе редизайна URL изменили, но оставили без внимания связанные ссылки.
• Неполадки на сервере. Это самый редкий вариант.

В большинстве ситуаций ошибка 404 отображается, когда не удаётся обнаружить нужную страницу на доступном сервере.

Возможные последствия для сайта

Нужно ли считать 404 ошибку опасной для сайтов? Кажется, что нет ничего плохого в том, что пользователь не смог открыть одну веб-страницу. Однако если такая ситуация будет повторяться регулярно, это чревато оттоком аудитории. Одни пользователи решат, что сайт вовсе не существует. Другие подумают, что лучше не заходить на сайт, который работает с ошибками. Третьи будут игнорировать ресурс, на котором не смогли получить обещанную информацию.

Поисковые системы относятся к Not Found более лояльно. Например, Google отмечает, что 404 страницы не влияют на рейтинг. Но если при индексации роботы будут находить все больше ошибочных страниц, вряд ли это приведёт к более высокому ранжированию.

Если вы хотите улучшить взаимодействие с посетителями, важно найти и исправить все ошибки 404 на сайте.

Как выявить ошибку

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

Search Console Google

Консоль поиска Google позволяет находить страницы с ошибкой 404 за несколько кликов:

1. Войдите в учётную запись Google и перейдите в Search Console.
2. Откройте раздел «Ошибки сканирования» → «Диагностика».
3. Кликните на «Not Found».

Чтобы получить список страниц с ошибками, подтвердите права на ресурс — добавьте проверочную запись TXT в записи DNS регистратора домена. Такая запись не повлияет на работу сайта. Подробнее о процедуре подтверждения, читайте в справке Google.

Яндекс Вебмастер

Сервис для вебмастеров от Яндекса поможет быстро найти все ошибки 404:

1. Откройте Вебмастер после авторизации в Яндекс-аккаунте.
2. Выберите «Индексирование» → «Доступные для поиска страницы» → «Исключённые страницы».
3. В выданном списке выберите фильтр «Ошибка HTTP: 404».

Чтобы использовать Яндекс.Вебмастер, также нужно подтвердить право владения сайтом — добавить метатег в HTML-код главной страницы.

Screaming Frog

Для начала загрузите и установите программу на компьютер. После запуска добавьте URL проверяемого сайта и начните поиск проблем. Неработающие ссылки можно искать даже в бесплатной версии.

SiteAnalyzer

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

Как исправить ошибку Not Found

Выбор конкретного решения зависит от причины ошибки:

1. Ссылка ведёт в никуда из-за неверного URL. Для решения проблемы замените ошибочную ссылку на правильный адрес, чтобы сервер отдавал код 200 OK.
2. Битая ссылка. Подобная ситуация не редкость при внутренней перелинковке страниц. К примеру, ссылка есть, а саму страницу давно удалили. Решений два: удалить ссылку или заменить её на другую.

Удалять и менять ссылки вручную удобно только на небольших сайтах. Исправление ошибок на крупных порталах лучше автоматизировать. Например, с помощью специальных плагинов для внутренней перелинковки (Terms Description, Dagon Design Sitemap Generator) и для автоматического формирования адресов страниц (Cyr-To-Lat).

Чтобы ошибки 404 появлялись как можно реже, достаточно соблюдать простые рекомендации:

• Не присваивайте сложные адреса основным разделам сайта. Это снизит число ошибок, связанных с опечатками в URL.
• Не меняйте адреса страниц слишком часто. Это неудобно для пользователей и вводит в заблуждение поисковых роботов.
• Размещайте сайт на надёжном сервере. Это предотвратит ошибки, возникающие из-за неработоспособности сервера.

Мы разобрались, как найти и исправить ошибки Not Found внутри сайта. Но неработающая ссылка может быть расположена и на стороннем ресурсе. Допустим, когда-то на другом сайте разместили рекламную публикацию со ссылкой на определённую страницу. Спустя какое-то время страницу удалили. В этом случае появится ошибка 404. Устранить её можно, связавшись с администрацией ссылающегося сайта. Если же удалить/исправить ссылку нельзя, постарайтесь использовать ошибку с выгодой.

Как сделать страницу 404 полезной

Грамотно оформленная страница с ошибкой Error 404 Not Found — действенный инструмент конвертации посетителей. Ограничений по использованию страницы с ошибкой 404 нет. При этом практически все CMS позволяют настраивать дизайн этой страницы.

Что публиковать на странице 404:

• меню с кликабельными ссылками;
• ссылку на главную страницу;
• анонс последних публикаций;
• контакты для обратной связи.

При оформлении страницы-ошибки желательно опираться на рекомендации поисковиков:

• Яндекс настоятельно рекомендует, чтобы страница контрастировала с основным содержанием сайта — иные цвета, другие графические приёмы либо их отсутствие. Необходимо чётко и понятно объяснить пользователю, что запрошенной страницы не существует и предложить другое решение.
• Google советует придерживаться единого стиля оформления. Но также рекомендует понятно рассказать об ошибке и предложить полезные материалы.

Главное — по возможности отказаться от стандартной страницы 404. Подумайте, как привлечь внимание пользователя. Расскажите ему об отсутствии искомой страницы и предложите взамен что-то полезное или интересное.

Примеры оформления страниц 404

Designzillas

Мультяшная страница креативной студии привлекает внимание и её хочется досмотреть до конца. Если прокрутить страницу, можно увидеть, как из яйца вылупится дракон. При этом на странице есть ссылки на все основные разделы сайта.

Domenart Studio

Веб-студия «Домен АРТ» использует красочную страницу 404, оформленную в единой стилистике ресурса. Заблудившимся пользователям предлагают попробовать ещё раз ввести адрес или перейти в нужный раздел.

E-co

«Эко Пауэр», дистрибьютор производителя источников питания, демонстрирует короткое замыкание как символ ошибки. Посетителям предлагают перейти на главную.

Дом со всем

Компания «Дом со всем», занимающаяся бурением скважин, разместила на странице 404 свои контакты и перечень услуг. Со страницы можно перейти в любой раздел сайта или заказать обратный звонок. С таким наполнением посетителю не нужно искать дополнительную информацию где-то ещё.

Kualo

Страница 404 на веб-хостинге Kualo может заставить пользователя забыть, зачем он сюда пришёл. Увлекательная игра притягивает внимание. В конце игры посетителю предлагают посмотреть сайт хостинга.

Рано или поздно с ошибкой 404 сталкивается большинство сайтов. При регулярной проверке можно своевременно исправить неработающие ссылки, чтобы в ответ пользователи получали код 200 OK. Но для крупного ресурса лучше настроить оригинальную страницу, которая будет отображаться при появлении ошибки Not Found и подскажет посетителям, что делать дальше.

Главные мысли

I am currently running a small K3S cluster in order to get familiar with K8S.

I am able to set up pods with ordinary LoadBalancers and get it to work without any problem.
However, when I try to get it to work with Ingresses (HAProxy in my case) — I only end up with «default backend -404».

This is the deployment of the pods, based on the default NGINX container:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: notesncrap
  labels:
    app: notesncrap
spec:
  replicas: 2
  selector:
    matchLabels:
      app: notesncrap
  template:
    metadata:
      labels:
        app: notesncrap
    spec:
      containers:
      - name: notesncrap
        image: jselea/notesncrap 
        ports:
        - containerPort: 80

I have also created a Service:

apiVersion: v1
kind: Service
metadata:
  name: notesncrap
  labels:
    app: notesncrap
spec:
  ports:
    - port: 80
  selector:
    app: notesncrap
    tier: frontend

And now the Ingress:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: notesncrap
spec:
  rules:
  - host: k8scrap.selea.se
    http:
      paths:
      - path: /
        backend:
          serviceName: notesncrap
          servicePort: 80

I have the understanding that the name and label should be consistent over the .yaml files, and I personally can’t see anything really wrong with what I have written.

Thankful for any pointers

EDIT:

As pointed out by the comments — the Ingress is behind a Apache Reverseproxy:

ProxyPass "/" "http://x.x.x.x:80"
ProxyPassReverse "/" "http://x.x.x.x:80"
ProxyRequests On
ProxyPreserveHost On

When I try curl directly against the ingress:

╭─root@sshgateway ~
╰─➤  curl -H "Host:k8scrap.selea.se" http://x.x.x.x                                                                                                                                   
default backend - 404#

All,

We installed Kubernetes with RKE in our AWS environment as per the link — https://rancher.com/docs/rancher/v2.x/en/installation/ha/

All the steps worked mostly fine and the nodes are healthy in the AWS NLB. I do not see any issue with any pods. But when we hit the NLB url —> https://nlburl.amazonaws.com it gives an error/message as «default backend — 404». Same error comes up when I type within each of the nodes when i type localhost. Version and other cmd outputs shown below.

Thoughts or inputs on how to debug and fix the issue?

ubuntu@xxx:/tmp$ ./rke -v
rke version v0.1.14

ubuntu@xxx:/tmp$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}

ubuntu@xxx:/tmp$ kubectl --kubeconfig /tmp/kube_config_cluster.yml get ingress -n cattle-system -o wide
NAME      HOSTS                     ADDRESS                                    PORTS     AGE
rancher   rancher.mydomain.com   1.2.3.4,5.6.7.8,9.0.1.2   80, 443   19h

ubuntu@xxx:/tmp$ kubectl --kubeconfig /tmp/kube_config_cluster.yml get nodes
NAME      STATUS   ROLES                      AGE   VERSION
1.2.3.4   Ready    controlplane,etcd,worker   21h   v1.11.5
5.6.7.8   Ready    controlplane,etcd,worker   21h   v1.11.5
9.0.1.2   Ready    controlplane,etcd,worker   21h   v1.11.5


ubuntu@xxx:/tmp$ kubectl --kubeconfig /tmp/kube_config_cluster.yml describe ingress -n cattle-system
Name:             rancher
Namespace:        cattle-system
Address:          1.2.3.4,5.6.7.8,9.0.1.2
Default backend:  default-http-backend:80 (<none>)
TLS:
  tls-rancher-ingress terminates rancher.mydomain.com
Rules:
  Host                     Path  Backends
  ----                     ----  --------
  rancher.mydomain.com
                              rancher:80 (<none>)
Annotations:
  certmanager.k8s.io/issuer:                          rancher
  field.cattle.io/publicEndpoints:                    [{"addresses":["1.2.3.4","5.6.7.8","9.0.1.2"],"port":443,"protocol":"HTTPS","serviceName":"cattle-system:rancher","ingressName":"cattle-system:rancher","hostname":"rancher.mydomain.com","allNodes":false}]
  nginx.ingress.kubernetes.io/proxy-connect-timeout:  30
  nginx.ingress.kubernetes.io/proxy-read-timeout:     1800
  nginx.ingress.kubernetes.io/proxy-send-timeout:     1800
Events:                                               <none>

ubuntu@1.2.3.4:/tmp$ curl localhost
default backend - 404

All,

We installed Kubernetes with RKE in our AWS environment as per the link — https://rancher.com/docs/rancher/v2.x/en/installation/ha/

All the steps worked mostly fine and the nodes are healthy in the AWS NLB. I do not see any issue with any pods. But when we hit the NLB url —> https://nlburl.amazonaws.com it gives an error/message as «default backend — 404». Same error comes up when I type within each of the nodes when i type localhost. Version and other cmd outputs shown below.

Thoughts or inputs on how to debug and fix the issue?

ubuntu@xxx:/tmp$ ./rke -v
rke version v0.1.14

ubuntu@xxx:/tmp$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}

ubuntu@xxx:/tmp$ kubectl --kubeconfig /tmp/kube_config_cluster.yml get ingress -n cattle-system -o wide
NAME      HOSTS                     ADDRESS                                    PORTS     AGE
rancher   rancher.mydomain.com   1.2.3.4,5.6.7.8,9.0.1.2   80, 443   19h

ubuntu@xxx:/tmp$ kubectl --kubeconfig /tmp/kube_config_cluster.yml get nodes
NAME      STATUS   ROLES                      AGE   VERSION
1.2.3.4   Ready    controlplane,etcd,worker   21h   v1.11.5
5.6.7.8   Ready    controlplane,etcd,worker   21h   v1.11.5
9.0.1.2   Ready    controlplane,etcd,worker   21h   v1.11.5


ubuntu@xxx:/tmp$ kubectl --kubeconfig /tmp/kube_config_cluster.yml describe ingress -n cattle-system
Name:             rancher
Namespace:        cattle-system
Address:          1.2.3.4,5.6.7.8,9.0.1.2
Default backend:  default-http-backend:80 (<none>)
TLS:
  tls-rancher-ingress terminates rancher.mydomain.com
Rules:
  Host                     Path  Backends
  ----                     ----  --------
  rancher.mydomain.com
                              rancher:80 (<none>)
Annotations:
  certmanager.k8s.io/issuer:                          rancher
  field.cattle.io/publicEndpoints:                    [{"addresses":["1.2.3.4","5.6.7.8","9.0.1.2"],"port":443,"protocol":"HTTPS","serviceName":"cattle-system:rancher","ingressName":"cattle-system:rancher","hostname":"rancher.mydomain.com","allNodes":false}]
  nginx.ingress.kubernetes.io/proxy-connect-timeout:  30
  nginx.ingress.kubernetes.io/proxy-read-timeout:     1800
  nginx.ingress.kubernetes.io/proxy-send-timeout:     1800
Events:                                               <none>

ubuntu@1.2.3.4:/tmp$ curl localhost
default backend - 404