Skip to content

Create EgressPolicy

Egresspolicy is used to define which pods' outbound traffic needs to be forwarded through the EgressGateway node, and to define other configuration details. When a matching pod accesses any address outside the cluster (any address that is not a Node IP, CNI Pod CIDR, or ClusterIP), it will be forwarded by the EgressGateway Node. Currently, EgressPolicy is divided into two categories: namespace-level and cluster-level.

  • Namespace-level : The scope of the created policy is at the namespace level.
  • Cluster-level : The scope of the created policy is at the cluster level.

Create Namespace EgressPolicy

  1. Click Gateway Policy -> Create Namespace Policy , and fill in the following parameters:

    Basic Information:

    • Policy Name : Enter the name of the policy to be created.
    • Description : Define the description of the policy to be created.
    • Namespace : The namespace where the policy will take effect, in this example, select default .
    • Gateway Selection : Specify which already created Egress Gateway instance to use.

    Outbound Address:

    • Outbound IP Address : Use a separate VIP as the outbound IP. Since EgressGateway operates on the basis of ARP, it is suitable for traditional networks where the source IP is always fixed. If not set, the default VIP will be used, and the IP value must be within the IPPool range of the EgressGateway. You can choose the IP in two ways:

      • Specify Outbound IP Address : Specify a specific IP address as the outbound IP by selecting Gateway from a proper Egress IP range.
      • Specify Allocation Policy : Use the default outbound IP or select an IP from the pool as the outbound IP through round-robin allocation.
    • Node IP Address : Use the node's IP address as the outbound IP. This is suitable for public cloud and traditional network environments, but the disadvantage is that the outbound source IP may change with node failures. The corresponding field information is spec.egressIP.useNodeIP=true .

    Source Address Pods :

    Select Pods : Support selecting source address pods through Label Selectors or Source Address , specifying the range of Pods where this policy will take effect. When a matching Pod accesses any address outside the cluster (any address that is not a Node IP, CNI Pod CIDR, or ClusterIP), it will be forwarded by the EgressGateway Node.

    • Label Selectors : Specify the source address pods using labels.
    • Source Address : By adding source address CIDR blocks to the whitelist, the locked pods will enforce this policy.

    Advanced Settings :

    Destination Address : Specify a whitelist of destination addresses. When specified, this policy will only apply to the defined destination addresses. Supports input in various formats such as single IP address, IP range, CIDR, etc. Default is to apply to all destination addresses.

  2. Click OK after inputting the details to complete the creation.

Create Cluster EgressPolicy

  1. Click Gateway Policy -> Create Cluster Policy , and refer to the parameters for Basic Information, Outbound Address, and Pod Selection as described in Create Namespace EgressPolicy.

    Advanced Settings :

    • Namespace Selector : Select namespaces using labels, and the policy will apply to the selected namespaces.
    • Destination Address : Similar to creating namespace Egress Gateway policies.
  2. Click OK after inputting the details to complete the creation.

Create EgressPolicy Using YAML

  1. Create the EgressPolicy YAML

    cat <<EOF | kubectl apply -f -
    apiVersion: egressgateway.spidernet.io/v1beta1
    kind: EgressPolicy
    metadata:
      name: test
      namespace: default
    spec:
      egressGatewayName: default
      appliedTo:
        podSelector:
          matchLabels:
            app: "visitor"
    EOF
    

    In the above creation command:

    • spec.egressGatewayName specifies which EgressGateway group to use.
    • spec.appliedTo.podSelector specifies which pods within the cluster this policy will apply to.
    • There are two options for the source IP address of egress traffic:
      • You can use the IP of the gateway node. This is suitable for public cloud and traditional network environments, but the drawback is that the outbound source IP may change with node failures. You can set spec.egressIP.useNodeIP=true to make it effective.
      • You can use a separate VIP. Since EgressGateway operates on the basis of ARP, it is suitable for traditional networks, but not suitable for public cloud environments. The advantage is that the outbound source IP is always fixed. If no settings are made in EgressPolicy, the default VIP of egressGatewayName will be used, or you can manually specify spec.egressIP.ipv4, and the IP value must be within the IP pool of the EgressGateway.
  2. Check the status of the EgressPolicy

    $ kubectl get EgressPolicy -A
    NAMESPACE   NAME   GATEWAY   IPV4           IPV6   EGRESSTUNNEL
    default     test   default   172.22.0.110          egressgateway-worker2
    
    $ kubectl get EgressPolicy test -o yaml
    apiVersion: egressgateway.spidernet.io/v1beta1
    kind: EgressPolicy
    metadata:
      name: test
      namespace: default
    spec:
      appliedTo:
        podSelector:
          matchLabels:
            app: visitor
      egressIP:
        allocatorPolicy: default
        useNodeIP: false
    status:
      eip:
        ipv4: 172.22.0.110
      node: egressgateway-worker2
    

    In the above output:

    • status.eip shows the outbound IP address used when the Pods in this group exit the cluster.
    • status.node shows which EgressGateway node is currently responsible for forwarding outbound traffic.

    Note

    EgressGateway nodes support high availability. When there are multiple EgressGateway nodes, all EgressPolicies will be evenly distributed among different EgressGateway nodes.

  3. Check the status of EgressEndpointSlices

    Each EgressPolicy object has a corresponding EgressEndpointSlices object, which stores the set of IP addresses of Pods selected by the EgressPolicy. If an application cannot access the outside, you can check if the IP addresses in this object are correct.

    $ kubectl get egressendpointslices -A
    NAMESPACE   NAME         AGE
    default     test-kvlp6   18s
    
    $ kubectl get egressendpointslices test-kvlp6 -o yaml
    apiVersion: egressgateway.spidernet.io/v1beta1
    endpoints:
    - ipv4:
      - 172.40.14.195
      node: egressgateway-worker
      ns: default
      pod: visitor-6764bb48cc-29vq9
    kind: EgressEndpointSlice
    metadata:
      name: test-kvlp6
      namespace: default
    

Egress Gateway Test

  1. Deploy the nettools application outside the cluster to simulate an external service. nettools will return the requester's source IP address in the HTTP response.

    docker run -d --net=host ghcr.io/spidernet-io/egressgateway-nettools:latest /usr/bin/nettools-server -protocol web -webPort 8080
    
  2. In the visitor Pod within the cluster, verify the effect of outbound traffic. When the visitor accesses the external service, the source IP returned by nettools should match the effect of EgressPolicy .status.eip.status.eip`.

    $ kubectl get pod
    NAME                       READY   STATUS    RESTARTS   AGE
    visitor-6764bb48cc-29vq9   1/1     Running   0          15m
    
    $ kubectl exec -it visitor-6764bb48cc-29vq9 bash
    $ curl 10.6.1.92:8080
    Remote IP: 172.22.0.110
    

Comments