☰

Входящие правила AKS периодически сбрасываются.

tag-icon • tag-icon azure kubernetes
Входящие правила AKS периодически сбрасываются.

На AKS у меня есть служба типа LoadBalancer с 2 определенными портами, один для общего доступа (и двухсторонней аутентификации), а другой для эксклюзивного доступа из кластера Service Fabric также на Azure. Чтобы добиться эксклюзивного доступа, я изменил входящее правило на виртуальных машинах, чтобы разрешить доступ только кластеру SF. Проблема в том, что я часто вижу, что правило сбрасывается до значения по умолчанию, предположительно из-за развертывания, которое изменяет службу AKS из Azure DevOps (хотя объект LoadBalancer никогда не меняется)

Конфигурация LoadBalancer выглядит следующим образом:

apiVersion: v1
kind: Service
metadata:
  name: myservice-loadbalancer
spec:
  ports:
  - name: public-port
    port: 1234
    targetPort: public-port
  - name: service-fabric-port
    port: 4321
    targetPort: service-fabric-port
  selector:
    app: myservice
  type: LoadBalancer

Возможным решением является добавление разрешенного IP-адреса в объект LoadBalancer, как рекомендуется здесь:https://github.com/Azure/AKS/issues/570#issuecomment-413299212, но в моем случае это также ограничит «публичный порт».

Я не могу придумать другого выхода, кроме как создать два объекта LoadBalancer, по одному на порт. Но это не чистый обходной путь, поскольку: служба та же самая, только через два разных порта, и таким образом у меня будет два IP для одной и той же службы. Кроме того, как упоминалось по ссылке выше, изменения в правилах входящего трафика должны быть постоянными.

Есть ли другой способ решения? Заранее большое спасибо за любые идеи.

решение1

Я задал тот же вопрос на StackOverflow и там тоже ответил:https://stackoverflow.com/a/61696167/6860266

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

Например, служба LoadBalancer выше создаст одно правило для порта TCP 4321, позволяя любому интернет-источнику получать доступ к этому порту на публичном IP, предоставленном службе. Допустим, приоритет, предоставленный этому правилу, равен 500. Я могу изменить это правило, ноон будет сброшен позже.

Мне нужно добавить еще два правила с более высокими приоритетами, скажем, 400 и 401. Оба правила имеют в качестве назначения публичный IP-адрес службы и порт 4321. Правило 400 разрешит доступ к Service Tag ServiceFabric, тогда как правило 401 запретит доступ к Service Tag Internet.

Правила будут оцениваться в порядке 500, 401 и 400, поэтому в конечном итоге только Service Fabric сможет получить доступ к этому порту. Правила 400 и 401 не создаются Azure, поэтому они не изменятся.

Связанный контент