In this exercise we will use Traefik, another popular proxy server. Traefik is widely used for multiple reasons: it is easier to configure, can automatically generate and renew SSL certificates using Let’s Encrypt. We will also use most of the scripts from the prior exercise.
Create the Traefik Role Based Access Control with ClusterRoleBinding. This will allow Traefik to serve all namespaces of the cluster. To restrict the Traefik to one namespace only, use the “namespace-specific RoleBindings”.
Deploy Traefik with a deployment. This introduces a few more network hops, but follows the Kubernetes best practices guidelines and provides more flexibility.
Large organizations need to control the incoming traffic to the Kubernetes cluster. The most secure way is to use an ingress controller and create an ingress to channel all incoming traffic to the cluster.
In Learn Kubernetes part 1 – Web application in a Kubernetes cluster we have created a simple web application pod and exposed it to the outside world with a service using a load balancer. We will use the files we have created in that exercise with one change. The deployment is the same:
In this exercise we will expose the service via an NGINX ingress controller. Delete type: LoadBalancer in the app1-frontend-service.yaml file, so Kubernetes will use type: ClusterIP, the default value.
To start the kubernetes/ingress-nginx ingress controller in any operating system, execute this command to create the ‘nginx-ingress-controller’ deployment with containers
To launch the application and configure the resources to expose it outside of the Kubernetes cluster, open a terminal in the directory where you saved the files and execute
kubectl apply -f .
Verify the ingress
List the ingresses
kubectl get ingress
NAME HOSTS ADDRESS PORTS AGE
ingress * localhost 80 59s
This is the official Kubernetes dashboard, and for security reasons currently it is not recommended to use, but we can still use it in our local cluster to inspect the resources.
This is a tutorial to script a simple web application deployment in an enterprise grade Kubernetes cluster that you can follow on your Macintosh. You only need to install Docker and enable Kubernetes.
The frontend of the web application is represented by an NGINX container that listens on port 80 and returns the NGINX default page. The application is exposed outside of the cluster via a kubernetes/ingress-nginx NGINX Ingress Controller, at the address http://localhost
Save all files in the same directory. During the development process open a terminal in the directory of the files, and periodically test the configuration with kubectl apply -f . to check the code (don’t forget the period at the end of the command). This way Kubernetes will build the system step-by-step giving you continuous feedback.
I have used unique label values to demonstrate which labels make the connection between the resources using the label and selector values. Most of the time the application name is used as label for easy maintenance, but as you learn Kubernetes, it is important to understand the relationships between the resources..
Script the deployment
The deployment configures the containers running in the pods and contains the label that has to match the selector of the service.
Connect the deployment to the pods
The label in spec: selector: matchLabels: connects the deployment to the pods specified in the deployment template via the same deployment’s spec: template: metadata: labels:
The service specifies the environment variables of the pods backing the service and exposes the pods to the rest of the Kubernetes cluster or to the outside world.
Connect the service to the pods
The label in the service’s spec: selector: has to match the label in spec: template: metadata: labels: of the deployment.
We will expose the service outside of the cluster with type: LoadBalancer
To launch the application and configure the resources to expose it outside of the Kubernetes cluster, open a terminal in the directory where you saved the files and execute
kubectl apply -f .
Accessing the application
To access the application get the address of the service
kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
app1-frontend-service LoadBalancer 10.99.210.235 localhost 8080:32569/TCP 9s
Open a web browser and navigate to the address indicated by the EXTERNAL-IP and PORT: http://localhost:8080
You should see the NGINX default page
Delete the resources
If you want to delete these resources from the Kubernetes cluster, execute
Helm takes values that we pass into the Helm deployments and transforms a template (also known as a chart) to Kubernetes resources. It is a wrapper around Kubernetes resources.
It calls kubectl in the background to create the resources on the fly.
For security reasons it is not a good practice to create individual load balancers for each service.
The safer way is to create one application load balancer outside of the cluster and launch ingress controller NGINX containers to proxy the traffic to the individual services.
Ingress
“Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.”
To get the list of ingresses
kubectl get ingress
To show the details of an ingress
kubectl describe ingress
Creating an ingress
specify the URL of the application in spec: rules: – host:
if no host set, this rule handles the request to any URL
specify the path this rule applies to at spec: rules: – host: http: paths: – backend: path:
set the service name at spec: rules: … backend: serviceName: