Compare languages | The cni-cilium module: examples

Egress Gateway

Egress Gateway

This feature is available in the following editions: SE+, EE.

Доступно в следующих редакциях: SE+, EE, CSE Lite (1.67), CSE Pro (1.67).

Operation principle

Принцип работы

Configuring an egress gateway requires two custom resources:

Для настройки egress-шлюза необходимы два кастомных ресурса:

  1. EgressGateway— describes the group of nodes that perform the egress gateway function in hot-standby mode:
    • Among the group of nodes match the spec.nodeSelector, the eligible nodes will be selected. One of them will be assigned as the active gateway. The active node is selected in alphabetical order.
  1. EgressGateway — описывает группу узлов, один из которых будет выбран в качестве активного egress-шлюза, а остальные останутся в резерве на случай отказа:
    • Среди группы узлов, попадающих под spec.nodeSelector, будут отобраны пригодные к использованию. Один из них будет назначен активным шлюзом. Выбор активного узла осуществляется в алфавитном порядке.

Attributes of an eligible node:

  • The node is in Ready state.
  • The node is not in the maintenance state (i.e., it is not cordoned).
  • The cilium-agent on the node is in the Ready state.
  • When using EgressGateway in VirtualIP mode, an agent is launched on the active node which emulates a “virtual” IP address using the ARP protocol. The status of this agent’s pod is also taken into account when determining the eligibility of a node.
  • Different EgressGateways can use the same nodes for operation. The active node is selected independently for each EgressGateway, which allows for load balancing between them.
    1. EgressGatewayPolicy — describes the policy for routing network requests from pods in the cluster to a specific egress gateway defined using EgressGateway.

Признаки пригодного узла:

  • Узел в состоянии Ready.
  • Узел не находится в состоянии технического обслуживания (cordon).
  • cilium-agent на узле в состоянии Ready.
  • При использовании EgressGateway в режиме VirtualIP на активном узле запускается агент, который эмулирует «виртуальный» IP-адрес с использованием протокола ARP. При определении пригодности узла также учитывается состояние пода данного агента.
  • Разные EgressGateway могут использовать одни и те же узлы. Выбор активного узла в каждом EgressGateway осуществляется независимо от других, что позволяет сбалансировать нагрузку между ними.
    1. EgressGatewayPolicy — описывает политику перенаправления сетевых запросов от подов в кластере на конкретный egress-шлюз, определённый с помощью EgressGateway.

Node maintenance

Обслуживание узла

To perform maintenance on a node that is currently the active egress gateway, follow these steps:

  1. Remove the node label to exclude it from the egress gateway candidate pool. Egress-label is the label specified in spec.nodeSelector of your EgressGateway.

Для проведения работ на узле, который в данный момент является активным egress-шлюзом, выполните следующие шаги:

  1. Снимите метку (label) с узла, чтобы исключить его из списка кандидатов для роли egress-шлюза. Egress-label — это метка, указанная в spec.nodeSelector вашего EgressGateway.

bash kubectl label node -

bash kubectl label node -

  1. Cordon the node to prevent new pods from starting:
  1. Переведите узел в режим обслуживания (cordon), чтобы предотвратить запуск новых подов:

bash kubectl cordon

bash kubectl cordon

After this, Cilium will automatically select a new active node from the remaining candidates. Traffic will continue routing through the new gateway without interruption.

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

  1. After maintenance is complete, return the node to service:
  1. Для возврата узла в работу выполните:

bash kubectl uncordon kubectl label node =

bash kubectl uncordon kubectl label node =

Note: Reapplying the label may cause the node to become active again (if it is first in alphabetical order among candidates). To avoid immediate failback, temporarily reduce the number of EgressGateway replicas or adjust priorities using additional labels.

Важно: повторное добавление метки может привести к тому, что узел снова будет выбран активным egress-шлюзом (если он первый в алфавитном порядке среди доступных кандидатов). Чтобы избежать немедленного возврата узла в активное состояние, временно уменьшите количество реплик в EgressGateway или настройте приоритет выбора через дополнительные метки.

Comparison with CiliumEgressGatewayPolicy

Сравнение с CiliumEgressGatewayPolicy

The CiliumEgressGatewayPolicy implies configuring only one node as an egress gateway. If it fails, there are no failover mechanisms and the network connection will be broken.

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

Configuration examples

Примеры настроек

EgressGateway in PrimaryIPFromEgressGatewayNodeInterface mode (basic mode)

EgressGateway в режиме PrimaryIPFromEgressGatewayNodeInterface (базовый режим)

yaml apiVersion: network.deckhouse.io/v1alpha1 kind: EgressGateway metadata: name: my-egressgw spec: nodeSelector: dedicated/egress: “” sourceIP: mode: PrimaryIPFromEgressGatewayNodeInterface primaryIPFromEgressGatewayNodeInterface: The “public” interface must have the same name on all nodes that matching the nodeSelector. If the active node fails, traffic will be redirected through the backup node and the source IP address of the network packets will change. interfaceName: eth1

yaml apiVersion: network.deckhouse.io/v1alpha1 kind: EgressGateway metadata: name: myegressgw spec: nodeSelector: dedicated/egress: “” sourceIP: mode: PrimaryIPFromEgressGatewayNodeInterface primaryIPFromEgressGatewayNodeInterface: На всех узлах, попадающих под nodeSelector, «публичный» интерфейс должен называться одинаково. При выходе из строя активного узла, трафик будет перенаправлен через резервный и IP-адрес отправителя у сетевых пакетов поменяется. interfaceName: eth1

EgressGateway in VirtualIPAddress mode (Virtual IP mode)

EgressGateway в режиме VirtualIPAddress (режим с Virtual IP)

yaml apiVersion: network.deckhouse.io/v1alpha1 kind: EgressGateway metadata: name: my-egressgw spec: nodeSelector: dedicated/egress: “” sourceIP: mode: VirtualIPAddress virtualIPAddress: Each node must have all the necessary routes configured to access all external public services, the “public” interface must be prepared for automatic configuration of the “virtual” IP as a secondary IP address. In case of failure of the active node, traffic will be redirected through the backup node and the source IP address of the network packets will not change. ip: 172.18.18.242 List of network interfaces for Virtual IP interfaces:

  • eth1

yaml apiVersion: network.deckhouse.io/v1alpha1 kind: EgressGateway metadata: name: myeg spec: nodeSelector: dedicated/egress: “” sourceIP: mode: VirtualIPAddress virtualIPAddress: На каждом узле должны быть настроены все необходимые маршруты для доступа на все внешние публичные сервисы, «публичный» интерфейс должен быть подготовлен к автоматической настройке «виртуального» IP в качестве дополнительного (secondary) IP-адреса. При выходе из строя активного узла, трафик будет перенаправлен через резервный и IP-адрес отправителя у сетевых пакетов не поменяется. ip: 172.18.18.242 Список сетевых интерфейсов для «виртуального» IP. interfaces:

  • eth1

EgressGatewayPolicy

EgressGatewayPolicy

yaml apiVersion: network.deckhouse.io/v1alpha1 kind: EgressGatewayPolicy metadata: name: my-egressgw-policy spec: destinationCIDRs:

  • 0.0.0.0/0 egressGatewayName: my-egressgw selectors:
  • podSelector: matchLabels: app: backend io.kubernetes.pod.namespace: my-ns

yaml apiVersion: network.deckhouse.io/v1alpha1 kind: EgressGatewayPolicy metadata: name: my-egressgw-policy spec: destinationCIDRs:

  • 0.0.0.0/0 egressGatewayName: my-egressgw selectors:
  • podSelector: matchLabels: app: backend io.kubernetes.pod.namespace: my-ns