Why the Ingress Cannot Be Accessed Outside the Cluster?

Troubleshooting Process

This section provides an overview of troubleshooting ingress external access exceptions, as shown in Figure 1.

Figure 1 Overview of troubleshooting ingress external access exceptions

1. Checking Whether the Exception Is Caused by the Ingress.

   Check whether the problem is caused by the ingress. Ensure that the external domain name resolution is normal, the security group rules are correct, and the service and workload corresponding to the ingress are working properly.

2. Checking the Ingress Status.

   When the service and workload are normal, ensure that the load balancer on which the ingress depends is normal. If the ingress is of the Nginx type, ensure that the nginx-ingress add-on is normal.

3. Checking Whether the Ingress Is Configured Correctly.
   If the preceding check results are normal, the ingress configuration may be incorrect.

   • Check whether the parameters for interconnecting with the load balancer are correct.
   • Check whether the Service configuration is correct.
   • Check whether the forwarding configuration is correct.
4. Checking Certificate.

   If HTTPS access is enabled on the ingress, you also need to check whether the fault is caused by incorrect certificate configuration. You can use the same load balancer to create an HTTP ingress. If the access is normal, the HTTPS certificate may be faulty.

5. If the fault persists, capture packets for analysis or submit a service ticket for help.

Checking Whether the Exception Is Caused by the Ingress

Check whether the access exception is caused by the ingress. If the domain name resolution exception, security group rule error, service exception, or workload exception occurs, the ingress access may fail.

The following check sequence complies with the rules from outside to inside:

1. Check whether the domain name resolution or security group rules are normal.
   1. Run the following command to check whether record sets of the domain name take effect on the authoritative DNS server:

      nslookup -qt= Type Domain name Authoritative DNS address

   2. Check the security group rules of the cluster nodes and ensure that the service ports in the 30000–32767 range are accessible to all network segments for inbound traffic. For details about how to harden the security group, see How Can I Configure a Security Group Rule in a Cluster?.

      

2. Check whether the Service can access services in the container.
   You can create a pod in the cluster and use the cluster IP address to access the Service. If the Service type is NodePort, you can also use EIP:Port to access the service over the Internet.

   1. Use kubectl to connect to the cluster and query the Service in the cluster.

      # kubectl get svc
      NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
      kubernetes   ClusterIP   10.247.0.1       <none>        443/TCP        34m
      nginx        ClusterIP   10.247.138.227   <none>        80/TCP         30m

   2. Create a pod and log in to the container.

      kubectl run -i --tty --image nginx:alpine test --rm /bin/sh

   3. Run the curl command to access ClusterIP address:Port of the Service to check whether the Service in the cluster is accessible.

      curl 10.247.138.227:80

      If the Service can be accessed, the backend workload status is normal. It can be preliminarily determined that the exception is caused by the ingress. For details, see Checking the Ingress Status.

      If the Service access is abnormal, check the workload status to determine the cause.

3. Check whether the workload status is normal.

   If the workload is normal but the Service cannot be accessed, the exception may be caused by the Service. Check the Service configuration. For example, check whether the container port is correctly configured to an open service port of the container.

   If the workload is normal but the access result is not as expected, check the service code running in the container.

Checking the Ingress Status

CCE supports two types of ingresses. The Ngnix Ingress Controller is provided by the open source community and needs to be maintained by installing the add-on in the cluster. The ELB Ingress Controller runs on the master node and is maintained by a dedicated Huawei Cloud team.

1. If you use an Nginx ingress, you need to install the NGINX Ingress Controller add-on in the cluster. If you use a LoadBalancer ingress, skip this step.

   Go to Add-ons and check whether the NGINX Ingress Controller add-on runs properly. Ensure that there are enough node resources in the cluster. If not, the add-on pods cannot be scheduled to nodes.

2. Go to the ELB console to check the ELB status.
   • ELB ingress

     The access port can be customized. Check whether the listener and backend server group created on the ELB are not deleted or modified.

     When creating an ELB ingress, you can choose Auto Create on the console to automatically create a load balancer. Do not modify the load balancer. Otherwise, ingress exceptions may be caused.

   • Nginx ingress

     The access ports are fixed to 80 and 443. Custom ports are not supported. Installing the nginx-ingress add-on occupies both ports 80 and 443. Do not delete them. Otherwise, you need to reinstall the add-on.

   You can also determine whether the fault is caused by the load balancer based on the error code. If the following error code is displayed, there is a high probability that the fault is caused by the load balancer. In this case, you need to pay special attention to the load balancer.

   

Checking Whether the Ingress Is Configured Correctly

If the preceding check items are normal, check whether the exception is caused by parameter settings. When using kubectl to create an ingress, a large number of parameters need to be set, which is prone to errors. You are advised to use the console to create ingresses and set parameters as required to automatically filter out load balancers and Services that do not meet requirements. This effectively prevents incorrect formats or missing of key parameters.

Checking Certificate

The ingress secret certificate type of CCE is IngressTLS or kubernetes.io/tls. If the certificate type is incorrect, the ingress cannot create a listener on the load balancer. As a result, the ingress access becomes abnormal.

1. Remove HTTPS parameters from YAML and create an HTTP ingress to check whether the ingress can be accessed.

   If the HTTP access is normal, check whether the HTTPS secret certificate is correct.

2. Check whether the secret type is correct. Check whether the secret type is IngressTLS or kubernetes.io/tls.

   # kubectl get secret
   NAME                  TYPE                                  DATA   AGE
   ingress               IngressTLS                            2      36m

3. Create test certificates to rectify the certificate fault.

   # openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN={YOUR_HOST}/O={YOUR_HOST}"

4. Use the test certificates tls.key and tls.crt to create a secret and check whether the secret can be accessed normally. The following example shows how to create an IngressTLS secret.

   Specifically, the IngressTLS secret is created using kubectl:

   kind: Secret
   apiVersion: v1
   type: IngressTLS
   metadata:
     name: ingress
     namespace: default
   data:
     tls.crt: LS0tLS1CRU*****FURS0tLS0t
     tls.key: LS0tLS1CRU*****VZLS0tLS0=

   

   In the preceding information, tls.crt and tls.key are only examples. Replace them with the actual files. The values of tls.crt and tls.key are the content encrypted using Base64.