Развертывание на основе пользователей в Kubernetes

Я немного новичок в kubernetes. И мы хотим представить некоторые из наших продуктов как SaaS нашим клиентам. Поэтому мне нужны изолированные развертывания на основе пользователей. После некоторых исследований я решил создать пространство имен для каждого пользователя. Затем разверните то, что хочет пользователь из нашего шаблона, в пространство имен пользователя. Но есть проблема с сопоставлением портов. Допустим, у нас есть 6 пользователей, и все они хотят развернуть приложение django. Итак, все они хотят получить доступ к своему проекту с 80 и 443 портов. Есть ли решение для этого в kubernetes? Если это так, как мне действовать?

И как я могу разделить развертывания каждого пользователя на разные сети или вланы, чтобы изолировать их сети друг от друга?


kubernetes docker kubernetes-pod
person Zekeriya Akgül    schedule 26.03.2020    source источник
comment
Насколько вы доверяете своим клиентам? Безопасность Kubernetes — это не то, что я бы хотел использовать для этого, если есть риск, что злоумышленник станет клиентом. Разрешения и пространства имен Kubernetes и все, что не создано, чтобы быть жесткими границами безопасности.   -  person coderanger    schedule 26.03.2020
comment
почему вы не используете правила и службы входа. Таким образом, у каждого пользователя будет свое правило, указывающее на требуемую службу, а служба будет указывать на правильное развертывание. Таким образом, пользователи полностью разделены и не будут влиять друг на друга.   -  person Hany Habib    schedule 26.03.2020

Ответы (2)


arrow_upward
2
arrow_downward

Вы можете либо поместить выделенный балансировщик нагрузки для каждого из них (дорогое решение, но прямолинейное), либо заставить ваш контроллер Ingress принимать запросы только с именем хоста и указывать каждое имя хоста на его службу в его пространстве имен (дешевое решение, но усложнить).

Решение для балансировки нагрузки:

Это легко, если вы работаете с облачным провайдером, поэтому каждый раз, когда клиент предоставляет приложение, вы просто создаете службу типа LoadBalancer, указывающую на его приложение. Поскольку для каждого приложения вы получаете новый балансировщик нагрузки, у вас нет проблем с конфликтами портов. Теперь недостатки в том, что это вы можете сделать только с облачным провайдером, и это будет довольно дорого.

Решение Ingress:

Это профессиональное решение. Это дешево, но и сложнее. Итак, вы должны создать ресурс Ingress следующим образом:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
spec:
  tls:
  - secretName: tls 
  rules:
  - host: site1.domain.com
    http:
      paths:
      - path: /path1/
        backend:
          serviceName: service1
          servicePort: 80
  - host: site2.domain.com
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
    ...

Здесь у вас есть только один балансировщик нагрузки L7, и всю маршрутизацию выполняет Ingress Controller. В зависимости от контроллера Ingress вы можете получить балансировщик нагрузки L4 (например, nginx, Traefik), но все же маршрутизацию выполняет контроллер Ingres.

Сложность? Вам нужно будет найти способ обновить записи Ingress Controller без простоев для других пользователей. Кроме того, в Kubernetes Ingress Controller не может передать запрос из одного пространства имен в другое. Таким образом, служба должна работать в том же пространстве имен, в котором был создан ресурс Ingress (обратите внимание, я говорю ресурс Ingress, поскольку это правила (например, yaml выше), а не Ingress Controller). Это известное ограничение, о котором уже объявила команда Kubernetes, и оно никогда не будет изменено, поскольку создает огромную дыру в безопасности.

Вам нужно будет создать безголовые службы без селекторов в том же пространстве имен, что и Ingress объект, и отдельно создать Endpoint объектов, указывающих на службу в других пространствах имен. Это может показаться громоздким, но на самом деле это довольно профессионально.

person suren    schedule 26.03.2020

arrow_upward
1
arrow_downward

Чтобы разделить внешний доступ к приложениям, вам необходимо развернуть контроллер входящего трафика и создавать разные входы, указывающие на службы каждого приложения. Каждый вход будет содержать свой уникальный URL-адрес для каждого приложения.

Чтобы запретить внутреннюю связь между пространствами имен, вам необходимо развернуть сетевые политики. . Для этого вам потребуется развернуть аддон. Или вы можете решить эту проблему, развернув любой распространенный сервисный меш: Istio, Linkerd, Consul и т. д.

person Anton Matsiuk    schedule 26.03.2020