DNAT

Scenario

A destination network address translation (DNAT) gateway is situated between cluster nodes and public networks and assigned an EIP. After receiving inbound requests from public networks, the NAT gateway translates the EIP (destination address in the inbound requests) into a cluster-internal address. It appears to workload users as if all nodes running the workload share the same EIP.

DNAT provides higher reliability than EIP-based NodePort in which the EIP is bound to a single node and once the node is down, all inbound requests to the workload will not be distributed. The access address is in the format of <EIP>:<access port>, for example, 10.117.117.117:80.

Figure 1 DNAT

Constraints

Observe the following constraints when using the NAT Gateway service:

DNAT rules do not support enterprise project authorization.

Containers in the cluster cannot access the DNAT Service whose externalTrafficPolicy is Local.
Multiple rules for one NAT gateway can use the same EIP, but the rules for different NAT gateways must use different EIPs.
Each VPC can have only one NAT gateway.
Users cannot manually add the default route in a VPC.
Only one SNAT rule can be added to a subnet in a VPC.
SNAT and DNAT rules are designed for different functions. If SNAT and DNAT rules use the same EIP, resource preemption will occur. An SNAT rule cannot share an EIP with a DNAT rule with Port Type set to All ports.
DNAT rules do not support binding an EIP to a virtual IP address.
When both the EIP and NAT Gateway services are configured for a server, data will be forwarded through the EIP.
The custom CIDR block must be a subset of the VPC subnet CIDR blocks.
The custom CIDR block must be a CIDR block of Direct Connect and cannot conflicts with VPC's existing subnet CIDR blocks.
When you perform operations on underlying resources of an ECS, for example, changing its specifications, the configured NAT gateway rules become invalid. Delete the rules and reconfigure them.
After a Service is created, if the affinity setting is switched from the cluster level to the node level, the connection tracing table will not be cleared. Do not modify the Service affinity setting after the Service is created. To modify it, create a Service again.
If the node subnet is associated with a custom route table, add the NAT route to the custom route table when using the DNAT Service.

Creating a NAT Gateway and an Elastic IP Address

You have created a NAT gateway and an elastic IP address. The specific procedure is as follows:

Log in to the management console, choose Networking > NAT Gateway from the service list, and click Buy Public NAT Gateway in the upper right corner. Configure parameters based on site requirements.

When buying a NAT gateway, ensure that the NAT gateway belongs to the same VPC and subnet as the CCE cluster where the workload is running.
Log in to the management console, choose Networking > Elastic IP from the service list, and click Buy EIP in the upper right corner. Configure parameters based on site requirements.

Creating a DNAT Gateway Service

Log in to the CCE console and click the cluster name to access the cluster console.
In the navigation pane, choose Services & Ingresses. In the upper right corner, click Create Service.
Configure intra-cluster access parameters.
- Service Name: Specify a Service name, which can be the same as the workload name.
- Service Type: Select DNAT.
- Namespace: Namespace to which the workload belongs.
- Service Affinity: For details, see externalTrafficPolicy (Service Affinity).
  - Cluster level: The IP addresses and access ports of all nodes in a cluster can access the workload associated with the Service. Service access will cause performance loss due to route redirection, and the source IP address of the client cannot be obtained.
  - Node level: Only the IP address and access port of the node where the workload is located can access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
- Selector: Add a label and click Confirm. The Service will use this label to select pods. You can also click Reference Workload Label to use the label of an existing workload. In the dialog box that is displayed, select a workload and click OK.
- IPv6: This function is disabled by default. After this function is enabled, the cluster IP address of the Service changes to an IPv6 address. For details, see Creating an IPv4/IPv6 Dual-Stack Cluster in CCE. This parameter is available only in clusters of v1.15 or later with IPv6 enabled (set during cluster creation).
- DNAT: Select the DNAT gateway and EIP created in Creating a NAT Gateway and an Elastic IP Address.
- Ports
  - Protocol: protocol used by the Service.
  - Container Port: listener port of the workload. The Nginx workload listens on port 80.
  - Service Port: a port mapped to the container port at the cluster-internal IP address. The workload can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
Click OK.

Setting the Access Type Using kubectl

You can configure Service access when creating a workload using kubectl. This section uses an Nginx workload as an example to describe how to implement intra-cluster access using kubectl.

Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.

Create and edit the nginx-deployment.yaml and nginx-nat-svc.yaml files.

The file names are user-defined. nginx-deployment.yaml and nginx-nat-svc.yaml are merely example file names.

vi nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:latest
        name: nginx
      imagePullSecrets:
      - name: default-secret

For descriptions of the preceding fields, see Table 1.

vi nginx-nat-svc.yaml

apiVersion: v1 
kind: Service 
metadata: 
  name: nginx 
  annotations:
    kubernetes.io/elb.class: dnat
    kubernetes.io/natgateway.id: e4a1cfcf-29df-4ab8-a4ea-c05dc860f554
spec: 
  loadBalancerIP: 10.78.42.242
  ports: 
  - name: service0 
    port: 80 
    protocol: TCP 
    targetPort: 80 
  selector: 
    app: nginx 
  type: LoadBalancer

**Table 1** Key parameters
Parameter	Mandatory	Type	Description
kubernetes.io/elb.class	Yes	String	This parameter is set to dnat so CCE can work with a NAT gateway and DNAT rules can be added.
kubernetes.io/natgateway.id	Yes	String	ID of a NAT gateway.
loadBalancerIP	Yes	String	EIP ID.
port	Yes	Integer	Access port set on the console. The value ranges from 1 to 65535.
targetPort	Yes	String	Container port set on the console. The value ranges from 1 to 65535.
type	Yes	String	NAT gateway service type must be set to LoadBalancer.

Create a workload.
kubectl create -f nginx-deployment.yaml

If information similar to the following is displayed, the workload is being created.
```
deployment "nginx" created
```
kubectl get po

If information similar to the following is displayed, the workload is running.
```
NAME                     READY     STATUS             RESTARTS   AGE
nginx-2601814895-sf71t   1/1       Running            0          8s
```
Create a Service.
kubectl create -f nginx-nat-svc.yaml

If information similar to the following is displayed, the Service has been created.
```
service "nginx-eip" created
```
kubectl get svc

If the following information is displayed, the Service has been set successfully, and the workload is accessible.
```
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE 
kubernetes   ClusterIP   10.247.0.1       <none>        443/TCP        3d 
nginx-nat    LoadBalancer 10.247.226.2  10.154.74.98   80:30589/TCP  5s
```
In the address bar of your browser, enter 10.154.74.98:80 and press Enter.
In this example, 10.154.74.98 is the elastic IP address and 80 is the port number obtained in the previous step.