У меня есть кластер Azure kubernetes, созданный с использованием следующего кода Terraform.
# Required Provider
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.0.2"
}
}
required_version = ">= 1.1.0"
}
data "azurerm_client_config" "current" {}
provider "azurerm" {
subscription_id = local.subscription_id
tenant_id = local.tenant_id
client_id = local.client_id
client_secret = local.client_secret
features {}
}
resource "random_pet" "rg-name" {
prefix = var.resource_group_name_prefix
}
resource "azurerm_resource_group" "rg" {
name = random_pet.rg-name.id
location = var.resource_group_location
}
resource "azurerm_virtual_network" "test" {
name = var.virtual_network_name
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
address_space = [var.virtual_network_address_prefix]
subnet {
name = var.aks_subnet_name
address_prefix = var.aks_subnet_address_prefix
}
tags = var.tags
}
data "azurerm_subnet" "kubesubnet" {
name = var.aks_subnet_name
virtual_network_name = azurerm_virtual_network.test.name
resource_group_name = azurerm_resource_group.rg.name
depends_on = [azurerm_virtual_network.test]
}
resource "azurerm_kubernetes_cluster" "k8s" {
name = var.aks_name
location = azurerm_resource_group.rg.location
dns_prefix = var.aks_dns_prefix
private_cluster_enabled = var.private_cluster
resource_group_name = azurerm_resource_group.rg.name
http_application_routing_enabled = false
linux_profile {
admin_username = var.vm_user_name
ssh_key {
key_data = file(var.public_ssh_key_path)
}
}
default_node_pool {
name = "agentpool"
node_count = var.aks_agent_count
vm_size = var.aks_agent_vm_size
os_disk_size_gb = var.aks_agent_os_disk_size
vnet_subnet_id = data.azurerm_subnet.kubesubnet.id
}
service_principal {
client_id = local.client_id
client_secret = local.client_secret
}
network_profile {
network_plugin = "azure"
dns_service_ip = var.aks_dns_service_ip
docker_bridge_cidr = var.aks_docker_bridge_cidr
service_cidr = var.aks_service_cidr
load_balancer_sku = "standard"
}
# Enabled the cluster configuration to the Azure kubernets with RBAC
azure_active_directory_role_based_access_control {
managed = var.azure_active_directory_role_based_access_control_managed
admin_group_object_ids = var.active_directory_role_based_access_control_admin_group_object_ids
azure_rbac_enabled = var.azure_rbac_enabled
}
timeouts {
create = "20m"
delete = "20m"
}
depends_on = [data.azurerm_subnet.kubesubnet,module.log_analytics_workspace]
tags = var.tags
}
Он создает балансировщик нагрузки с общедоступным IP-адресом, как показано ниже.
Однако я не хочу иметь общедоступный IP-адрес для балансировщика нагрузки, вместо этого он должен иметь внутренний частный IP-адрес.
Что мне делать, чтобы этот балансировщик нагрузки с внутренним частным IP-адресом и служба не были доступны через Интернет с использованием общедоступного IP-адреса?
Примечание. Согласно документации Microsoft, даже если вы аннотируете аннотациями: service.beta.kubernetes.io/azure-load-balancer-internal: «true», внешний IP-адрес все равно назначается, чего я пытаюсь избежать.
Балансировщик нагрузки, созданный с помощью кластера AKS (обычно называемый kubernetes), используется для исходящего (не входящего) трафика и является общедоступным LB, и он не может быть частным. Это часть конфигурации исходящего типа.
Для «исходящего типа» кластера AKS можно задать «LoadBalancer, UserDefinedRouting или manageNatGateway». если вы выберете любой вариант, кроме LB, вам нужно будет настроить свою сеть для маршрутизации трафика извне. проверьте этот документ для получения дополнительной информации.
Для входящего трафика вы можете использовать общедоступный или частный LB. Это настраивается в сервисном ресурсе (типа LoadBalancer) в kubernetes, где вы должны использовать упомянутую вами аннотацию для создания частного LB. Публичные правила будут использовать тот же общедоступный LB, созданный в кластере.
Вы также можете установить частный IP-адрес LB, используя аннотации:
annotations:
service.beta.kubernetes.io/azure-load-balancer-ipv4: 10.240.0.25
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
Это упоминается в том же документе, которым вы поделились.
Кластер должен иметь доступ к Интернету для загрузки и настройки узлов, а также для установления связи с сервером API, который является общедоступной конечной точкой (если не используется частный кластер). Чтобы направить весь трафик на FW, используйте исходящий тип как UDR, как упоминалось ранее. Также проверьте это: learn.microsoft.com/en-us/azure/aks/limit-egress-traffic
Насколько я понимаю, service.beta.kubernetes.io/azure-load-balancer-internal нужно использовать для создания внутреннего балансировщика нагрузки. Однако в случае сервисной сетки ISTIO виртуальная служба будет использоваться вместе со службой типа IP-кластера. Как применить внутренний балансировщик нагрузки для ISTIO?
Это другой вопрос, но в основном служба istio-ingressgateway должна иметь внутреннюю аннотацию, проверьте этот документ: istio.io/latest/docs/tasks/security/authorization/authz-ingress/… . Также этот ответ: stackoverflow.com/questions/64112107/…
Мы создаем кластеры kubernetes для внутреннего использования и не хотим раскрывать что-либо через Интернет, включая выход. Зачем на выходе нужен балансировщик нагрузки? Разве он не использует тот же входной порт для ответа на входящий запрос? Если этот выходной балансировщик нагрузки необходим, может ли он иметь частный IP-адрес? Если нет, то как не использовать это, а использовать любой другой способ, чтобы все исходящие запросы перенаправлялись на брандмауэр до выхода в Интернет?