Kubernetes, GCE, балансировка нагрузки, SSL

Question

Я немного новичок в создании сетей, SSL и NGINX, так голый со мной, если мне не хватает чего-то очевидного. В предисловии к этому я работаю над GCE и Kuberenetes. Моя цель - просто разоблачить все микросервисы в моем кластере через SSL. В идеальном случае он будет работать так же, как и при развертывании через тип = «LoadBalancer» и получить один внешний IP-адрес. Это моя цель, но SSL не доступен с этими базовыми балансировщиками.

Из моих исследований лучшим решением было бы установить контроллер входа nginx, использовать ресурсы доступа и услуги для предоставления моих микросервисов. Ниже приведена диаграмма, в которой я понял свое понимание этого процесса.

У меня это все, чтобы успешно работать над HTTP. Я развернул контроллер nginx по умолчанию: https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx. Как и бэкэнд по умолчанию и служба для бэкэнд по умолчанию. Вход для моего собственного микросервиса имеет правила, установленные как мое доменное имя и путь: /.

Это было успешно, но были две вещи, которые меня немного смутили.

1. При экспонировании ресурса службы для моего внутреннего интерфейса (microservice) один гидом я следовал используемому типу = «NodePort», а другие просто поставить порт, чтобы достигнуть обслуживания. Оба устанавливают целевой порт на порт приложения. Я пробовал это в обоих направлениях, и оба они работали. Путеводитель один из приведенной выше ссылки. Руководство 2: http://blog.kubernetes.io/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress.html. В чем тут разница?

2. Еще одна путаница в том, что мой вход всегда получает два IP-адреса. Мой начальный процесс мышления состоял в том, что должен быть только один внешний ip, и это могло бы поразить мой вход, который затем направляется nginx для маршрутизации. Или ip напрямую связан с nginx? Во всяком случае, первый созданный IP-адрес, похоже, дал мне ожидаемые результаты, когда неудача при посещении второго IP-адреса.

Несмотря на то, что мое замешательство, похоже, отлично работает над HTTP. За HTTPS не так много. Сначала, когда я сделал веб-запрос по https, вещи просто зависали. Я открыл 443 в своих правилах брандмауэра, которые, казалось, работали, однако я бы ударил по умолчанию, а не по микросервису.

Чтение привело меня к этому из документов Kubernetes: В настоящее время ресурс Ingress поддерживает только правила http. Это может объяснить, почему я нажимаю бэкэнда по умолчанию, потому что мои правила предназначены только для HTTP. Но если да, то как я должен использовать этот подход для SSL?

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

Любая помощь или руководство будут очень признательны. Благодаря!

Answer 1

Итак, для # 2 вы, вероятно, закончили загрузку Google HTTP (S) LoadBalancer, возможно, потому что вам не хватает аннотации kubernetes.io/ingress.class: "nginx", как описано здесь: https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#running-multiple-ingress-controllers.

У GKE есть свой собственный входной контроллер, который вам необходимо переопределить, приклеивая эту аннотацию к вашему развертыванию nginx. This article имеет хорошее объяснение по этому поводу.

kubernetes docs имеет неплохое описание того, что означает. В основном служба будет выделять порт из большого диапазона на каждом узле в вашем кластере, а узлы будут перенаправлять трафик с этого порта на ваш сервис. Это один из способов настройки балансировщика нагрузки в разных средах, но для вашего подхода это необязательно. Вы можете просто опустить поле type службы вашего микросервиса, и ему будет присвоен тип по умолчанию, который равен ClusterIP.

Что касается SSL, это может быть несколько разных вещей. Я бы удостоверился, что у вас есть секретная настройка, как они описываются в nginx controller docs, например, с полем tls.cert и tls.key.

Я также проверил журналы контроллера nginx - узнал, какой из них работает, как с kubectl get pods, а затем хвост его журналов: kubectl logs nginx-pod-<some-random-hash> -f. Это будет полезно узнать, если вы неправильно сконфигурировали что-либо, например, если в службе нет настроенных конечных точек. Большую часть времени я испортил входящий контент, это было связано с довольно простой неправильной конфигурацией Services/Deployments.

Вам также необходимо настроить DNS-запись для вашего хоста указал на статическом IP в LoadBalancer, либо еще пинг вашего сервиса с загнутым уголком -Hflag as they do in the docs, в противном случае вы могли бы в конечном итоге получить маршрутизации по умолчанию заднего конца 404.

Answer 2

Чтобы ответить на ваши вопросы, так как в этом вся суть ... Отказ от ответственности: Я n00b, поэтому возьмите все это с солью.

Что касается # 2, сообщение в блоге я ссылку ниже предлагает следующую архитектуру:

• Создание развертывания, который развертывает стручки контроллер Nginx
• Создание службы с типом LoadBalancer и статический IP маршрутизации трафика в стручках контроллера
• создать ингресс ресурс, который привыкает на стручках контроллер Nginx
• Создать секрет, который привыкает от стручков контроллера Nginx для завершения SSL
• И другие вещи тоже

Из того, что я понимаю, материал http vs https происходит с контроллерами nginx. Все мои правила входа также являются http, но контроллер входа nginx обеспечивает SSL и заботится обо всем этом, заканчивая SSL на контроллере, чтобы все под ним, все входящие данные, могли быть HTTP. У меня есть все правила http, но весь мой трафик через службу LoadBalancer заставляет использовать SSL.

Опять же, я n00b. Возьмите это все с солью. Я говорю на непрофессионалах, потому что я непрофессионал, пытающийся все это понять.

Я наткнулся на ваш вопрос, ища некоторые ответы на свои вопросы. Я столкнулся с множеством тех же проблем, с которыми вы столкнулись (я принимаю прошедшее время, учитывая количество пройденного времени). Я хотел указать вам (и/или другим с похожими проблемами) на сообщение в блоге, которое я нашел полезным, узнав о контроллере nginx. До сих пор (я все еще нахожусь на ранней стадии и в середине использования сообщения), все в должности работало.

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

https://daemonza.github.io/2017/02/13/kubernetes-nginx-ingress-controller/

Это помогло мне понять, что нужно создать, как развернуть стручки контроллера, и как выставить стручки контроллер ресурсов (создать службу LoadBalancer для модулей контроллера со статическим IP-адресом), а также принудительно выполнить SSL. Это помогло мне перепрыгнуть через несколько препятствий и пройти мимо «как все движущиеся части подходят друг к другу».

Техническая документация Kubernetes полезна для того, как использовать каждую деталь, но не обязательно выкладывать все и удалять кусочки вместе, как это делает сообщение в блоге. Отказ от ответственности: модель в блоге не может быть лучшим способом сделать это, хотя (у меня недостаточно опыта для этого вызова), но это помогло мне хотя бы получить рабочий пример контроллера входа nginx, который принудительно SSL.

Надеюсь, это поможет кому-то в конце концов.

Andrew