Huawei Cloud CCE Kubernetes Ingress — 1: ELB Ingress Service with SSL
Introduction
Hi, in this article, I will explain the use of ELB in Huawei Cloud’s CCE service, which creates a Kubernetes environment. Huawei Cloud supports two Ingress directly. The first is ELB Ingress and the other is Nginx Ingress. The ELB Ingress is used in this article.
The architecture below summarizes the topic of this article.
Prerequisites
- Domain Name (You have registered a domain name example.com with a third-party registrar)
- Add a custom domain managed by Huawei Cloud DNS (For detailed information see here)
- SSL Certificate (You can follow here for Certificate steps)
- CCE Cluster Instance with Worker Node (You can follow here to create CCE Instance)
- Stored Containerized Application (Image) in Software Repository (You can follow here to What is SWR? and How are Container Images stored in SWR?)
Connecting to a Cluster Using kubectl
This section shows how to connect to a CCE cluster using kubectl. To bind a public IP (EIP) to the cluster, go to the cluster details page and click Bind next to EIP in the Connection Information pane. In a cluster with an EIP bound, kube-apiserver will be exposed to public networks.
After connecting public IP address, download kubectl configuration file from Learn More next to kubectl.
- The kubectl configuration file kubeconfig.json is used for cluster authentication.
- The Kubernetes permissions assigned by the configuration file downloaded by IAM users are the same as those assigned to the IAM users on the CCE console.
mv -f kubeconfig.json $HOME/.kube/configAfter moving the kubectl configuration file to the required directory, let’s run the following command line. By default, external will be selected. Here you will see three different contexts; external, externalTLSVerify and internal. Since we are bind public IP, we can access Cluster in Huawei Cloud with external.
kubectl config get-context
If external is not selected, run the following command line.
kubectl config use-context externalDeployment
With Deployment, you define the desired state for your application. Kubernetes constantly checks whether the desired state and the actual state match. Deployment will create ReplicaSets running the desired number of pods. If a pod crashes, ReplicaSets will adjust the actual state according to the desired state.
The following yaml file will deploy the blog image where stored in SWR in the CCE environment.
Service (NodePort)
Kubernetes service enables a group of pods (applications running one or more containers) to be served as a service. The Service creates a single IP address and DNS record for all containers belonging to a podgroup, making it accessible to any container in the podgroup. This IP address can be used by other applications running on the same Kubernetes cluster.
There are four types of Kubernetes Services:
- ClusterIP: default service type, accessible only within the cluster
- NodePort: service exposed on a static port on each Node, can be accessed from outside the cluster
- LoadBalancer: creates a cloud provider load balancer in the underlying infrastructure, enables external traffic to be load balanced
- ExternalName: maps the service to an external DNS name.
NodePort is used for this demo. We are creating a service for the pods we created with the deployment above.
Secret (SSL Certificate)
In Kubernetes, a Secret object is a Kubernetes resource that is used to store sensitive information. We create the certificate with Secret for later use. You can create test certificates using Huawei Cloud’s Cloud Certificate Manager service. Enter the ssl certificate in the <crt> field and the ssl certificate key in the <key> field. Check here for the detailed guide.
Apply
We have completed the necessary steps with the above patch files. To summarize so far:
- We have prepared the Deployment yaml file that will create 2 Replicas.
- We have prepared the yaml file that will create NodePort Service for pods.
- We have prepared the yaml file that will create the Secret for SSL Certificate.
Let’s run the following command line in the directory where the yaml files are located:
kubectl apply -f .If yaml files are deployed successfully, you can view the running resources by running the following command line.
kubectl get all,cm,secret -n default
Ingress
Ingress is a Kubernetes Object that provides a way to route inbound traffic to different services within a cluster. Layer 7 acts as a load balancer and provides HTTP and HTTPS routes from outside the cluster to services within the cluster.
With Ingress, you can define rules that specify how incoming requests should be routed to different services. This allows you to create a single entry point for your application rather than offering each service separately.
- Ingress object: a set of access rules that forward requests to specified Services based on domain names or URLs.
- Ingress Controller: an executor for request forwarding.
Ingress Controllers provided by different vendors are implemented in different ways. Based on the types of load balancers, Ingress Controllers are classified into ELB Ingress Controller and Nginx Ingress Controller. Both of them are supported in CCE. ELB Ingress Controller forwards traffic through ELB. Nginx Ingress Controller uses the templates and images maintained by the Kubernetes community to forward traffic through the Nginx component.
This article uses Huawei Cloud’s ELB Ingress. ELB Ingress is essentially different from the open source Nginx Ingress. Therefore, their supported Service types are also different. That’s why we created a NodePort service. Because ELB Ingress Controller is deployed on a master node. All policies and forwarding behaviors are configured on the ELB side. Load balancers outside the cluster can connect to nodes in the cluster only through the IP address of the VPC in non-passthrough networking scenarios.
ELB Ingress Controller
ELB Ingress Controller is deployed on the master node and bound to the load balancer in the VPC where the cluster resides. Different domain names, ports, and forwarding policies can be configured for the same load balancer (with the same IP address).
- A user creates an ingress object and configures a traffic access rule in the ingress, including the load balancer, URL, SSL, and backend service port.
- When Ingress Controller detects that the ingress object changes, it reconfigures the listener and backend server route on the ELB side according to the traffic access rule.
- When a user accesses a workload, the traffic is forwarded to the corresponding backend service port based on the forwarding policy configured on ELB, and then forwarded to each associated workload through the Service.
Creating an ELB Ingress with Load Balancer
Huawei Cloud’s Elastic Load Balancer Service is divided into two types: Dedicated and Shared. For detailed information, see here. The example below uses a dedicated load balancer.
The following yaml file creates ingress as well as automatic ELB service creation. For a clearer understanding, let’s examine the annotations under metadata in the following yaml file and the tls under spec.
The explanation of the parameters that annotations can take in the yaml file is in the table.
We stated that it supports https with the kubernetes.io/elb.port: ‘443’ parameter. We specified the TLS policy with the kubernetes.io/elb.tls-ciphers-policy: tls-1–1 parameter and finally we stated that we want to create a dedicated ELB with the kubernetes.io/elb.class: performance parameter.
The kubernetes.io/elb.autocreate parameter creates an ELB object. Therefore, we must define the parameters of the ELB service we will create. The following table describes the Data Structures of elb.autocreate field.
Let’s deploy the ingress yaml file. For this, run the following command line in the file directory where the yaml file is located.
kubectl apply -f ingress.yamlYou can get information about the status of the Ingress object by running the following command line.
kubectl get ingressLet’s run the command line that we ran before and view the resources under the default namespace. This time, let’s add the ‘ing’ parameter.
kubectl get all,cm,secret, ing -n default
The actual state of the cluster is currently the same as desired. After that, all we have to do is to create an A record in the domain using the DNS service of the Public IP created with the ELB. For this, you can take a look at the documentation here.
Let’s send an https request from our browser to https://burakovali.online:
Conclusion
The Kubernetes Ingress object is a very useful. Huawei Cloud directly supports two different Ingress. The first of these is ELB Ingress and the other is Nginx Ingress. In this article, we created ELB Ingress on Huawei Cloud.
The ELB ingress creation process, which has very easy steps, provides many important advantages. Don’t forget to take a look at the references below to discover these benefits. The next article will be about Nginx Ingress.
References
Public Domain Name Resolution
SCM and SSL Certificate Usage
Creating Clusters and Pushing Container Image to SWR
Docker Container App, Pull and Push to Huawei Cloud SWR
Create an ELB Ingress
