Предисловие

В качестве обратного прокси-шлюза обычно лучшим выбором является nginx, но если у нас есть какие-то бизнес-потребности и нам нужно разработать его дважды, это просто кошмар, используем ли мы c для прямого изменения исходного кода nginx или используем lua для этого. пишите скрипты, тут все по-другому. Бывают разные проблемы.

Не только с точки зрения доступа, но и с точки зрения безопасности и использования ресурсов все не очень хорошо.

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

Недавно я увидел, что Cloudflare имеет Pingora с открытым исходным кодом, и был так рад, что решил использовать Pingora в качестве шлюза для k8s.

Цель

1. Реализация основных функций обратного прокси (http1|2, grpc, websocket).
2. слушая вход,автоматический,Плавное обновлениемаршрутизация。
3. Простой и удобный в использовании дизайн среднего уровня.
4. Инженерные возможности (мониторинг,контроль потока,Безопасность）

Знакомство с пингорой

представлятьpingoraДо,Давайте сначала поговорим о его команде разработчиков.cloudflare,Он один из крупнейших интернет-торговцев в мире.,Предоставляем решения cdn и ddos ​​высочайшего качества.

В 2022 году Cloudflare начал заменять nginx.

В настоящее время Pingora повышает производительность, обрабатывая более 1 триллиона интернет-запросов в день, и предоставляет множество новых функций клиентам Cloudflare, требуя при этом лишь одну треть ресурсов ЦП и памяти предыдущей прокси-инфраструктуры.

Это похоже на это собственное достоинство:

Pingora is a Rust framework to build fast, reliable and programmable networked systems. Pingora is battle tested as it has been serving more than 40 million Internet requests per second for more than a few years.

k8s & ingress представлять

Как самая популярная система оркестрации и управления контейнерами, k8s доминирует почти во всех серверных сервисах. Я думаю, что не все об этом знают.

Ingress — это объект в k8s, который описывает, как шлюз выполняет обратный прокси-сервер для службы.

Обычно используемые nginx и istio будут осуществлять входной контроль для динамической настройки маршрутизации шлюза, отслеживая изменения на входе.

Архитектурный дизайн

image.png

• Общая идея по-прежнему остается моделью луковицы с ручками, вложенными слой за слоем.
• монитор,событие,Модули безопасности интегрированы в звено через ручку
• Отслеживайте входные данные и динамически корректируйте структуру маршрутизации.
• Предоставить инструмент управления для взаимодействия с шлюзом.

Реализация кода

Мы не реализуем все содержимое в архитектуре, а сначала делаем MVP-версию.

Ingress watcher

• С помощью механизма наблюдения отслеживайте изменения на входном и кодовом портале.

impl WatchIngress {
    //Начинаем слушать
    pub async fn start_watch(&self)-> anyhow::Result<Receiver<IngressEvent>> {
        // Отправьте входящие изменения в канал, вот гетерогенный дизайн
        let (sender,receiver) = async_channel::bounded(8);

        // Создать клиент k8s
        let client = Client::try_default().await?;
        let api:Api<Ingress> = xxx
        ...
        // Создать наблюдателя
        ...
        let mut watch = watcher(api, wc)
            .default_backoff().boxed();
        tokio::spawn(async move {
            while let Some(result) = watch.next().await{
            ... //Отправляем изменения конфигурации в цикле
            }
        });
        Ok(receiver)
    }
}

Управление маршрутизатором

• код портала

impl HttpProxyControl {
    //Получаем события из канала и обрабатываем их функцией usinging_event_to_router,
    //Основная функция — обновление маршрутизации на основе событий
    fn ing_event_to_router(ing:IngressEvent,acl:Acl<HashMap<String,Router>>){
        ...
        //Обработка входного события
        match ty {
            1 | 2=>{ //init | update
            ... //Создаем или обновляем маршрутизацию
            }
            3=>{ //delete
            ... //удалитьмаршрутизация            }
            ...
        }
        // Ручка сни
        for (host,i) in sni.sni{
            ...
        }
        //Через указатель acl маршрутизация обновления без блокировки
        acl.update(move |_|{
            map
        });
    }
}

О проектировании маршрутизации

• В настоящее время в Ingress предусмотрены три стратегии маршрутизации: Исправлена.,префикс,особенный。Сначала мы поддерживаем фиксированные ипрефикс。
• Фиксированный режим, прямая обработка карты, относительно простой.
• префикс,Использование классической древовидной структуры сжатого словаря.,код портала

начало пингоры

• Балансировку нагрузки здесь делать не нужно, просто нужно найти правильный сервис.

pub fn start_pingora(){
    ...
    let mut my_server = Server::new(Some(Opt::default())).unwrap();
    my_server.bootstrap();      
    
    let mut gateway = http_proxy_service(&my_server.configuration,hpc);
    gateway.add_tcp(format!("0.0.0.0:{}",cfg.port).as_str());
    
    my_server.add_service(gateway);
    my_server.run_forever(); }

использовать

Сначала вам необходимо развернуть кластер k8s.

Создайте еще одно проверенное пространство имен: qa

Затем создайте несколько http-сервисов и настройте соответствующие сервисы. Здесь я начал использовать эхо-сервис для тестирования.

Служба развертывания

Нужно сначала создатьServiceAccount,Служить в модуле требуется это разрешение для доступа к ресурсам k8s,Команда выглядит следующим образом:

kubectl apply -f ./deploy/role.yaml -n qa

Затем создайте развертывание для запуска службы. pingora-ingress-ctl,Я сделал здесь зеркало,Создайте его с помощью следующей команды:

• Программа автоматически прослушивает порт, установленный на http в yaml.

kubectl apply -f ./deploy/role.yaml -n qa

Создать вход,и будет/api/v1маршрутизациянашему эху Служить,Команда выглядит следующим образом:

kubectl apply -f ./deploy/ingress.yaml -n qa

Чтобы получить доступ к службе за пределами кластера, необходимо открыть порт хоста. Мы создаем службу для службы. Команда выглядит следующим образом:

kubectl apply -f ./deploy/pingora-ingress-ctl-src.yaml -n qa

опыт

Мы отправляем правильный запрос, и эхо можно увидеть ниже:

//просить
curl --location --request GET 'http://test.com:30003/api/v1/greet/hello?content=world'

//отвечать
{"response": "Get [test-server]---> request=hello query=world"}

Измените v1 в маршруте на v2, и ответ станет 404 не найден.

Пользовательская конфигурация

Мы можем добавить в pingora некоторые пользовательские конфигурации, например следующую тестовую конфигурацию:

---
version: 1
threads: 2
pid_file: /tmp/load_balancer.pid
error_log: /tmp/load_balancer_err.log
upgrade_sock: /tmp/load_balancer.sock

проходитьConfigMapВоля Конфигурация Ввести вk8sсередина。Команда выглядит следующим образом:

kubectl apply -f ./deploy/config_map.yaml -n qa

Затем нам нужно смонтировать конфигурацию в модуль. Нам нужно изменить yaml развертывания выше. Нам нужно только разархивировать часть комментариев.

Выложу и здесь:

...
spec:
    ...
    spec:
      containers:
        # Укажите путь к файлу конфигурации при запуске.
        - args:
            - '-c'
            - /config/config.yaml
        - command:
            - ./pingora-ingress
          image: wdshihaoren/pingora-ingress:14294998
          ...
          # Подвесной диск
          volumeMounts:
            - mountPath: config
              name: config
              readOnly: true
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      # Подвесная тарелка
      volumes:
        - configMap:
            defaultMode: 420
            name: pingora-ingress-ctl-cm
          name: config

После завершения модификации просто повторно разверните ее.

код

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

В настоящее время у нас есть только базовая структура. Друзья могут интегрировать любые функции, которые вы считаете ценными, и позвольте нам их реализовать.