Help Center> Cloud Container Engine> FAQ> Networking> Network Fault> What Should I Do If an Ingress Fails to Be Added or Cannot Be Accessed
View PDF

What Should I Do If an Ingress Fails to Be Added or Cannot Be Accessed

Ingresses forward requests based on layer-7 HTTP and HTTPS protocols. As an entry of cluster traffic, ingresses use domain names and paths to achieve finer granularities. After an ingress is added to a cluster, the cluster may fail to be accessed. This section describes how to locate the fault when an ingress fails to be added or cannot be accessed.

Troubleshooting Process

As a distributor for cluster traffic, an ingress is a bridge between load balancers and Services in a container. Before rectifying ingress issues, read the following precautions and perform a self-check:
  • If an Nginx ingress is used, ensure that the nginx-ingress add-on has been installed.
  • If the host address is specified in the ingress, the IP address cannot be used for access. This is not a problem.

Most problems occurred when you use kubectl to create an ingress. This section provides several key check items to help you quickly locate the root cause.

Figure 1 Troubleshooting process

Check Item 1: Whether Mandatory Ingress Parameters of Are Correct

If an ingress is added by using a YAML file, check whether the exception is caused by parameter settings. Ingress is defined by parameters in the annotations field. Kubernetes does not verify the parameters in the annotations field when creating resources. If key parameters are incorrect or missing, an ingress can be created but cannot be accessed.

The following lists the common errors that may occur frequently:
  • Failed to interconnect with ELB load balancer
    • The interconnected ELB load balancer is not in the same VPC as the cluster.
    • Key fields kubernetes.io/elb.id, kubernetes.io/elb.ip, kubernetes.io/ingress.class, and kubernetes.io/elb.port in annotations are missing when an ELB ingress is added to connect to an existing ELB load balancer.
    • When you add an Nginx ingress, the nginx-ingress add-on is not installed. As a result, the ELB connection is unavailable.
    • When you add an Nginx ingress, key fields kubernetes.io/ingress.class and kubernetes.io/elb.port are missing in annotations.
    • When you add an Nginx ingress, the kubernetes.io/elb.port field does not support custom ports. If HTTP is used, the value is fixed to 80. If HTTPS is used, the value is fixed to 443.
  • Failed to interconnect with the backend Service
    • The type of the Service interconnected with the ingress is incorrect. For details about the Services supported by the ingress, see Table 1.
      Table 1 Service types supported by the ingress

      Ingress Type

      Access Type

      ClusterIP

      NodePort

      ELB ingress

      Load balancing routing

      Not supported

      Supported

      ENI load balancing routing

      Supported

      Not supported

      Nginx ingress

      Load balancing routing

      Supported

      Supported

      ENI load balancing routing

      Supported

      Not supported

Solution

If an ingress is added by using kubectl, check whether key parameters are correctly set according to common error items. If the fault persists, you are advised to create an ingress again. After the basic functions are available, add advanced functions.

You are advised to use the CCE console to add an ingress and set parameters as required. The CCE console automatically filters out load balancers and Services that do not meet requirements, preventing incorrect format or missing of key parameters.
Figure 2 Adding an ingress

Check Item 2: Whether the Backend Container Port of a Service Is Correct

When creating an ingress using YAML, you need to correctly enter the target Service name and access port, and ensure that the container port in the Service is correctly configured. That is, the Service can access the containers.

When you add an ingress on the CCE console, the CCE console filters target Services that meet the requirements and automatically fills in the corresponding Service access port. You only need to ensure that the Services can access the containers.

Solution

Correctly specify the port that exposes the pod to the Service. You can perform the following steps to verify the configuration:

  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. Run the curl command to access IP address:Port of the Service to check whether the Service in the cluster is accessible. 

    # kubectl run -i --tty --image nginx:alpine test --rm /bin/sh
If you don't see a command prompt, try pressing enter.
/ # curl 10.247.138.227:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

  3. If the access fails, check whether the container port in the Service is correct or whether services in the container are running properly.

Check Item 3: Whether Containers Have Corresponding Paths

Different access paths can be set for ingress forwarding. Note that the access path is the path exposed by the Service in the target container. If a container does not have the corresponding path, a 404 error is returned and the corresponding container cannot be found.

Solution 1

Ensure that the container has the corresponding path and the path has been correctly specified in the ingress.

Solution 2 (supported only when the nginx-ingress add-on is used)

Nginx Ingress Controller supports redirection. You can add the rewrite annotation to the annotations field to rewrite the path that does not exist in the container to prevent the error display.

Example YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-test
  namespace: default
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: ''
      http:
        paths:
          - path: /.*
            backend:
              serviceName: <your_service_name>  # Replace it with the name of your target service.
              servicePort: 80

In the example, /.* is a regular expression that matches any value. Any path can be rewritten to the root path /. For example, when a user accesses http://**.**.**/test, the user is automatically redirected to http://**.**.**/, the service can be accessed even if the /test path does not exist in the service running in your container.

Check Item 4: Whether the Secret Certificate Is Correct When HTTPS Is Used

The ingress secret certificate type of CCE is IngressTLS. If the certificate type is incorrect, the ingress cannot create a listener on the ELB side. As a result, the ingress access becomes abnormal.

Solution

  1. Delete the HTTPS parameters from the YAML file and create an ingress of the HTTP type to check whether the ingress can be accessed. Ensure that the annotations field of the ingress and the Service are correct.

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

  2. Check whether the secret type is IngressTLS. 

    # 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 of the IngressTLS type and check whether the secret can be accessed normally.

    The following is an example YAML file when a 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.

Parent topic: Network Fault