Поддержка прокси-сервера HTTP в службе Azure Kubernetes (AKS)

Статья
2024-08-02

Из этой статьи вы узнаете, как настроить кластеры Служба Azure Kubernetes (AKS) для использования HTTP-прокси для исходящего доступа к Интернету.

Кластеры AKS, развернутые в управляемых или пользовательских виртуальных сетях, имеют определенные исходящие зависимости, необходимые для правильной работы, что создало проблемы в средах, требующих перенаправления доступа к Интернету через прокси-серверы HTTP. Узлы не имели возможности провести начальную загрузку конфигурации, переменных среды и сертификатов, необходимых им для доступа к службам Интернета.

Функция прокси-сервера HTTP добавляет поддержку HTTP-прокси в кластеры AKS, предоставляя простой интерфейс, который можно использовать для защиты сетевого трафика, необходимого ДЛЯ AKS, в средах, зависящих от прокси-сервера. С помощью этой функции узлы AKS и модули pod настроены для использования прокси-сервера HTTP. Эта функция также позволяет установить доверенный центр сертификации на узлах при начальной загрузке кластера. Более сложные решения могут потребовать создания цепочки доверия для обеспечения безопасного взаимодействия в сети.

Перед началом работы

Вам потребуется последняя версия Azure CLI. Запустите az --version, чтобы определить версию и запустите az upgrade для обновления версии. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
Проверьте наличие доступных обновлений кластера AKS, чтобы убедиться, что вы используете последнюю версию AKS. Если вам нужно обновить кластер AKS, ознакомьтесь с разделом "Обновление кластера AKS".
Файлы ОС, необходимые для обновлений конфигурации прокси-сервера, можно обновлять только во время процесса обновления образа узла. После настройки прокси-сервера необходимо обновить образ узла, чтобы применить изменения. Дополнительные сведения см. в статье Об обновлении образов узлов AKS.

Настройка прокси-сервера HTTP с помощью Azure CLI

Кластер AKS можно настроить с прокси-сервером HTTP во время создания кластера с помощью az aks create команды и передачи конфигурации в виде JSON-файла.

Схема файла конфигурации выглядит следующим образом:

{
  "httpProxy": "string",
  "httpsProxy": "string",
  "noProxy": [
    "string"
  ],
  "trustedCa": "string"
}

httpProxy: URL-адрес прокси-сервера, который будет использоваться для создания HTTP-соединений за пределами кластера. Схема URL-адреса должна быть http.
httpsProxy: URL-адрес прокси-сервера, который будет использоваться для создания HTTPS-соединений за пределами кластера. Если это не указано, httpProxy используется для подключений HTTP и HTTPS.
noProxy: список доменов назначения, доменов, IP-адресов или других сетевых CIDR для исключения прокси-сервера.
trustedCa: строка, содержащая альтернативное содержимое сертификата ЦС base64 encoded. В настоящее время поддерживается только PEM формат.

Внимание

Для совместимости с компонентами Go, которые входят в систему Kubernetes, сертификат должен поддерживаться Subject Alternative Names(SANs) вместо устаревших сертификатов common Name.

Существуют различия в использовании переменной окружения http_proxy, https_proxy и no_proxy в приложениях. Curl и Python не поддерживают CIDR в no_proxy, но Ruby поддерживает.

Пример входных данных:

Примечание.

Сертификат удостоверяющего центра должен быть строкой содержимого сертификата в формате PEM, закодированной в Base64.

{
  "httpProxy": "http://myproxy.server.com:8080/", 
  "httpsProxy": "https://myproxy.server.com:8080/", 
  "noProxy": [
    "localhost",
    "127.0.0.1"
  ],
  "trustedCA": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUgvVENDQmVXZ0F3SUJB...b3Rpbk15RGszaWFyCkYxMFlscWNPbWVYMXVGbUtiZGkvWG9yR2xrQ29NRjNURHg4cm1wOURCaUIvCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0="
}

Создайте файл и укажите значения для httpProxy, httpsProxyи noProxy. Если в вашей среде это необходимо, укажите значение для trustedCa. Затем можно развернуть кластер с помощью az aks create команды с параметром, --http-proxy-config заданным для созданного файла. Кластер должен инициализироваться с настроенным на узлах HTTP-прокси.

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --http-proxy-config aks-proxy-config.json \
    --generate-ssh-keys

Настройка прокси-сервера HTTP с помощью шаблона Azure Resource Manager (ARM)

Кластер AKS можно развернуть с помощью HTTP-прокси с использованием шаблона ARM. Та же схема, используемая для развертывания CLI, присутствует в Microsoft.ContainerService/managedClusters разделе определения в "properties", как показано в следующем примере:

"properties": {
    ...,
    "httpProxyConfig": {
        "httpProxy": "string",
        "httpsProxy": "string",
        "noProxy": [
            "string"
        ],
        "trustedCa": "string"
    }
}

В шаблоне укажите значения для httpProxy, httpsProxyи noProxy. При необходимости укажите значение для trustedCa. Затем можно развернуть шаблон. Кластер должен инициализироваться с настроенным на узлах прокси-сервером HTTP.

Прокси-сервер HTTP дополнения Istio для работы с внешними службами

Если вы используете надстройку на основе Istio для AKS, необходимо создать элемент службы, чтобы разрешить приложениям в сетке получать доступ к ресурсам вне кластера или внешним ресурсам через HTTP прокси-сервер. Например:

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: proxy
spec:
  hosts:
  - my-company-proxy.com # ignored
  addresses:
  - $PROXY_IP/32
  ports:
  - number: $PROXY_PORT
    name: tcp
    protocol: TCP
  location: MESH_EXTERNAL

Создайте файл и укажите значения для PROXY_IP и PROXY_PORT. Можно развернуть запись службы с помощью

kubectl apply -f service_proxy.yaml

Обновление конфигурации прокси-сервера

Примечание.

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

Конфигурацию прокси-сервера в кластере можно обновить с помощью az aks update команды с --http-proxy-config параметром, установленным на новый JSON-файл с обновленными значениями для httpProxy, httpsProxy, noProxy и trustedCa при необходимости. Обновление вводит новые переменные среды в модули pod с новыми значениями httpProxy, httpsProxy или noProxy. Pod'ы должны перезапускаться, чтобы приложения их приняли, так как значения переменных среды внедряются мутирующим веб-перехватчиком. Для компонентов в Kubernetes, таких как containerd и сам узел, это не вступает в силу до тех пор, пока не будет выполнено обновление образа узла.

Например, предположим, что вы создали новый файл с строкой в кодировке Base64 нового сертификата ЦС с именем aks-proxy-config-2.json. Конфигурацию прокси-сервера в кластере можно обновить с помощью следующей команды:

az aks update --name $clusterName --resource-group $resourceGroup --http-proxy-config aks-proxy-config-2.json

Обновление образов узлов AKS

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

Для обновления образов узлов AKS см. в разделе Обновление образов узлов в Службе Azure Kubernetes (AKS).

Мониторинг конфигурации дополнения

HTTP-прокси с надстройкой мониторинга поддерживает следующие конфигурации:

Исходящий прокси-сервер без аутентификации
Исходящий прокси-сервер с использованием имени пользователя и проверки подлинности паролей
Исходящий прокси-сервер с доверенным сертификатом для конечной точки Log Analytics

Следующие конфигурации не поддерживаются:

Пользовательские метрики и рекомендуемые функции оповещений при использовании прокси-сервера с доверенными сертификатами

Следующие шаги

Дополнительные сведения о требованиях к сети кластеров AKS см. в разделе "Управление исходящим трафиком" для узлов кластера в AKS.