Skip to content

Commit 575a89b

Browse files
committed
Update Blog “exposing-an-application-using-ingress-and-tls-termination-on-kubernetes-in-hpe-greenlake-for-private-cloud-enterprise”
1 parent 5a178eb commit 575a89b

File tree

1 file changed

+8
-8
lines changed

1 file changed

+8
-8
lines changed

content/blog/exposing-an-application-using-ingress-and-tls-termination-on-kubernetes-in-hpe-greenlake-for-private-cloud-enterprise.md

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -26,7 +26,7 @@ tags:
2626

2727
Once applications are deployed in a K8s cluster, the next step is to create services that expose these applications. By default, K8s services are created with the *ClusterIP* type, which supports internal connectivity among different components of the applications. However, these services are not directly accessible from outside the cluster. The challenge arises with a requirement to securely expose the deployed applications over HTTPS. This involves generating and managing SSL/TLS certificates for multiple applications deployed in the cluster. These certificates are crucial for secure communication between services, and their correct installation and management are essential to avoid access issues and security risks. To address exposing applications over HTTPS, K8s provides the concept of *Ingress*. An Ingress acts as an entry point for external traffic into the cluster. It can be configured with TLS termination. However, setting up K8s Ingress with TLS termination is intricate. It involves creating a K8s Secret to host the certificate and referencing the Secret in the Ingress resource. It also requires an additional load balancer configuration in the cluster.
2828

29-
This blog post outlines the comprehensive steps for exposing applications using Ingress and TLS termination on K8s in HPE GreenLake for Private Cloud Enterprise. [MetalLB](https://metallb.universe.tf/) is deployed to the cluster to set up the load balancer. It enables external access to services within the cluster. [Cert-manager](https://cert-manager.io/) is utilized for creating and managing SSL/TLS certificates. The generated certificate is stored as a K8s *Secret* object. This Secret can be mounted by application Pods or used by an Ingress controller. The [Nginx Ingress controller](https://www.nginx.com/products/nginx-ingress-controller/) is deployed and configured in the cluster. It handles SSL certificates and facilitates secure access to applications in the backend.
29+
This blog post outlines the comprehensive steps for exposing applications using Ingress and TLS termination on K8s in HPE GreenLake for Private Cloud Enterprise. [MetalLB](https://developer.hpe.com/blog/set-up-load-balancer-with-metallb-in-hpe-greenlake-for-private-cloud-enterprise/) is deployed to the cluster to set up the load balancer. It enables external access to services within the cluster. [Cert-manager](https://developer.hpe.com/blog/generating-self-signed-certificates-using-cert-manager-for-kubernetes-in-hpe-greenlake-for-private-cloud-entreprise/) is utilized for creating and managing SSL/TLS certificates. The generated certificate is stored as a K8s *Secret* object. This Secret can be mounted by application Pods or used by an Ingress controller. The [Nginx Ingress controller](https://www.nginx.com/products/nginx-ingress-controller/) is deployed and configured in the cluster. It handles SSL certificates and facilitates secure access to applications in the backend.
3030

3131
![](/img/tls-termination-s.png)
3232

@@ -85,7 +85,7 @@ cfe-l2advert ["cfe-pool"]
8585

8686
### Deploy Nginx Ingress controller
8787

88-
In order for an Ingress to work in the cluster, there must be an Ingress controller being deployed and running. It's the Ingress controller that accesses the certificate and the routing rules defined on the Ingress resource and makes them par of its configuration.
88+
In order for an Ingress to work in the cluster, there must be an Ingress controller being deployed and running. It's the Ingress controller that accesses the certificate and the routing rules defined on the Ingress resource and makes them part of its configuration.
8989

9090
A variety of Ingress controllers are available for deployment in the cluster, including [Traefik](https://doc.traefik.io/traefik/providers/kubernetes-ingress/), [HAProxy](https://github.com/haproxytech/kubernetes-ingress#readme) and [Nginx Ingress controller](https://www.nginx.com/products/nginx-ingress-controller/). Execute the command below to install the Nginx Ingress controller to the cluster using helm:
9191

@@ -391,7 +391,7 @@ metadata:
391391
name: ingress-host-based-selfsigned
392392
annotations:
393393
ingress.kubernetes.io/ssl-redirect: "true"
394-
cert-manager.io/issuer: "nginx-selfsinged-issuer"
394+
cert-manager.io/issuer: "nginx-selfsigned-issuer"
395395
spec:
396396
ingressClassName: nginx
397397
tls:
@@ -472,7 +472,7 @@ Events:
472472

473473
### Access deployed Nginx applications
474474

475-
Before start accessing the deployed Nginx applications, you need set up the domain and the subdomain name resolution. For the sample domain name *nginx.example.com*, and its subdomains, *blue.nginx.example.com* and *green.nginx.example.com*, the workstation host file has been used for DNS resolution.
475+
Before accessing the deployed Nginx applications, you need set up the domain and the subdomain name resolution. For the sample domain name *nginx.example.com*, and its subdomains, *blue.nginx.example.com* and *green.nginx.example.com*, the workstation host file has been used for DNS resolution.
476476

477477
Type the following commands to check that this is done correctly:
478478

@@ -489,7 +489,7 @@ blue.nginx.example.com has address 10.6.115.251
489489

490490
You can then validate the Ingres TLS configuration of the deployed Nginx applications using the browser.
491491

492-
Start the browser and type the URL *nginx.example.com*, it will be rediected over HTTPS with the warning message *'Your connection is not private'*:
492+
Start the browser and type the URL *nginx.example.com*, it will be redirected over HTTPS with the warning message *'Your connection is not private'*:
493493

494494
![](/img/nginx-main-warning.png)
495495

@@ -503,19 +503,19 @@ Click *Proceed to nginx.example.com (unsafe)*, you then go to the Nginx *MAIN
503503

504504
![](/img/nginx-main.png)
505505

506-
Type the URL *green.nginx.example.com* to the browser, it will be rediected over HTTPS with the same warning message *'Your connection is not private'*:
506+
Type the URL *green.nginx.example.com* to the browser, it will be redirected over HTTPS with the same warning message *'Your connection is not private'*:
507507

508508
![](/img/nginx-green-warning.png)
509509

510510
Click *Proceed to green.nginx.example.com (unsafe)*, you then go to the Nginx *GREEN* page:
511511

512512
![](/img/nginx-green.png)
513513

514-
The same thing occurs when type the URL *blue.nginx.example.com* to the browser. The access will be rediected over HTTPS with the same warning message *'Your connection is not private'*:
514+
The same thing occurs when you type the URL *blue.nginx.example.com* to the browser. The access will be redirected over HTTPS with the same warning message *'Your connection is not private'*:
515515

516516
![](/img/nginx-blue-warning.png)
517517

518-
Click *Proceed to blue.nginx.example.com (unsafe)*, you then go to the Nginx *BLEU* page:
518+
Click *Proceed to blue.nginx.example.com (unsafe)*, you then go to the Nginx *BLUE* page:
519519

520520
![](/img/nginx-blue.png)
521521

0 commit comments

Comments
 (0)