Use an Ingress to provide Layer-7 service access - User Guide for Serverless Kubernetes Clusters| Alibaba Cloud Documentation Center

Use an Ingress to provide Layer-7 service access

Edit in GitHub

Last Updated: Nov 01, 2019 Edit in GitHub

In Alibaba Cloud Serverless Kubernetes, you can use Server Load Balancer (SLB) to provide Layer-4 service access. You can also use an Ingress to provide Layer-7 service access. This topic describes how to provide Layer-7 service access through a domain name in a Serverless Kubernetes cluster.

Prerequisites

A Serverless Kubernetes cluster is created. You must configure a network address translation (NAT) gateway for the VPC where the cluster is located so that the cluster can download container images from the public network.
The kubectl client is connected to the Serverless Kubernetes cluster. For more information, see Connect to a Kubernetes cluster by using kubectl.

Note

If you do not specify the SLB instance, the system automatically generates a public SLB instance.
The default front-end listener ports for the SLB instance are ports 80 (HTTP) and 443 (HTTPS).
By default, the HTTPS certificate of the SLB instance is initialized to the TLS certificate configured for the first Ingress that is created. If no TLS certificate is configured for the first Ingress, the HTTPS certificate is initialized to the system default certificate. You can modify the HTTPS certificate in the SLB console as needed.
If you use an existing SLB instance, the SLB instance must be a high-performance instance that supports Elastic Network Interface (ENI). In addition, make sure that ports 80 and 443 are not currently used by other services.

Use the default SLB instance

If you do not specify the SLB instance, the system automatically generates a public SLB instance of the high-performance type when the first Ingress is created.

Deploy test services.

Create the cafe-service.yaml file, copy the following code to the file, and run the kubectl apply -f cafe-service.yaml command to deploy the coffee service and tea service:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: coffee
spec:
  replicas: 2
  selector:
    matchLabels:
      app: coffee
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: coffee
  clusterIP: None
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: tea
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tea 
  template:
    metadata:
      labels:
        app: tea 
    spec:
      containers:
      - name: tea 
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: tea-svc
  labels:
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: tea
  clusterIP: None

If the following result appears, the coffee and tea services are deployed:

deployment "coffee" created
service "coffee-svc" created
deployment "tea" created
service "tea-svc" created

Run the kubectl get svc,deploy command to view the service status.

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
svc/coffee-svc   ClusterIP   <none>       <none>        80/TCP    1m
svc/tea-svc      ClusterIP   <none>       <none>        80/TCP    1m

NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/coffee   2         2         2            2           1m
deploy/tea      1         1         1            1           1m

Configure an Ingress.

Create the cafe-ingress.yaml file, and copy the following code to the file. Then, run the kubectl apply -f cafe-ingress.yaml command to configure the external domain name and paths of the coffee service and tea service through an Ingress.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  rules:
  # Configure the Layer-7 domain name.
  - host: foo.bar.com
    http:
      paths:
      # Configure the context path.
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80
      # Configure the context path.
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80

If the following result appears, the Ingress is configured:

ingress "cafe-ingress" created

Run the kubectl get ing command to obtain the IP address of the SLB instance.

NAME           HOSTS         ADDRESS          PORTS     AGE
cafe-ingress   foo.bar.com   139. ***. **.***   80        1m

Test service access.
Note Currently, you need to manually resolve the domain name to the IP address of the SLB instance.
In this example, add the following DNS rule to the hosts file for testing service access. We recommend that you apply for an Internet Content Provider (ICP) filing for the domain name in your production environment.
```
139.***. **.***    foo.bar.com
```
- Access the coffee service in a browser.
- Access the coffee service on the command line.
```
curl -H "Host: foo.bar.com" http://139. ***. **.***/coffee
```
- Access the tea service in a browser.
- Access the tea service on the command line.
```
curl -H "Host: foo.bar.com" http://139. ***. **.***/tea
```

Use an existing SLB instance

You can use the service.beta.kubernetes.io/alicloud-loadbalancer-id annotation to specify an existing SLB instance. Note that the SLB instance must be a high-performance instance that supports ENI.

Note The system automatically initializes ports 80 and 443 for the SLB instance. Make sure that the ports are not currently used by other services.

Deploy the test service.

Create the tomcat-service.yml file, copy the following code to the file, and run the kubectl apply -f tomcat-service.yml command to deploy a Tomcat test service:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: tomcat
spec:
  replicas: 1
  selector:
    matchLabels:
      run: tomcat
  template:
    metadata:
      labels:
        run: tomcat
    spec:
      containers:
      - image: tomcat:7.0
        imagePullPolicy: Always
        name: tomcat
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: tomcat
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    run: tomcat
  clusterIP: None

If the following result appears, the Tomcat service is deployed.

deployment "tomcat" created
service "tomcat" created

Run the kubectl get svc,deploy tomcat command to view the service status.

NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
svc/tomcat   ClusterIP   <none>       <none>        8080/TCP   1m

NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/tomcat   1         1         1            1           1m

Apply for an SLB instance.
You must apply for a high-performance SLB instance (such as slb.s2.small) in the same region as the cluster. The SLB instance can be either an internal or a public instance, depending on the specific requirements. For more information, see Create an SLB instance. In this example, apply for a public SLB instance and record the ID of the SLB instance.
Configure the TLS certificate.
You must configure the TLS certificate for HTTPS access.
1. Run the following commands to generate a TLS certificate:
```
$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=bar.foo.com/O=bar.foo.com"# Create a secret for the TLS certificate.
$ kubectl create secret tls cert-example --key tls.key --cert tls.crt

secret "cert-example" created
```
2. Run the following command to view the created TLS certificate:
```
$ kubectl get secret cert-example

NAME           TYPE                DATA      AGE
cert-example   kubernetes.io/tls   2         12s
```
Note The system automatically initializes the default HTTPS certificate for the SLB instance based on the TLS certificate of the first Ingress that is created. You can modify the default HTTPS certificate in the SLB console. To configure multiple certificates, you can add extended domains for the HTTPS listener and associate them with certificates in the SLB console.

Configure an Ingress.

Create the tomcat-ingress.yml file, copy the following code to the file, and run the kubectl apply -f tomcat-ingress.yml command to configure an Ingress:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: tomcat-ingress
  annotations:
    # Specify the ID of the existing SLB instance.
    service.beta.kubernetes.io/alicloud-loadbalancer-id: lb-xxxxxxxxxx            ##Replace lb-xxxxxxxxxx with the ID of the target SLB instance.
    service.beta.kubernetes.io/alicloud-loadbalancer-force-override-listeners: "true"
spec:
  tls:
  - hosts:
    - bar.foo.com
    # Configure the TLS certificate.
    secretName: cert-example
  rules:
  # Configure the Layer-7 domain name.
  - host: bar.foo.com
    http:
      paths:
      # Configure the context path.
      - path: /
        backend:
          serviceName: tomcat
          servicePort: 8080

If the following result appears, the Ingress is configured:

ingress "tomcat-ingress" created

Run the kubectl get ing tomcat-ingress command to obtain the IP address of the SLB instance.

NAME             HOSTS         ADDRESS        PORTS     AGE
tomcat-ingress   bar.foo.com   47. ***. **.**   80, 443   1m

Test service access.
Note Currently, you need to manually resolve the domain name to the IP address of the SLB instance.
In this example, add the following DNS rule to the hosts file for testing service access. We recommend that you apply for an ICP filing for the domain name in your production environment.
```
47.***. **.**   bar.foo.com
```
- Access the Tomcat service in a browser.
- Access the Tomcat service on the command line.
```
curl -k -H "Host: bar.foo.com" https://47. ***. **. **
```