KUBERNETES SERVICE AND INGRESS -Pt1.

1. INTRODUCTION

   Before we dive into ingress in Kubernetes, we will take a brief stop on services in Kubernetes. Services enable communication between objects within and outside a k8s cluster. Objects within a cluster can be pods, service accounts daemonSet etc, object outside k8s clusters can be external nodes or end users trying to access applications hosted on pods. Kubernetes gives every pod its own private IP address for networking purposes, for end users or external nodes in a different cluster to access these pods through the IP, a service is needed. Let’s take a small illustration of the use of services in Kubernetes. For example, we deployed three pods in a node, these pods work together because they are combined to make a single application. The first one serves as front-end, the second serve as back-end, and the third is the database. These three pod needs to be reached with their assigned IPs.

   When the front-end pod is destroyed or recreated, It is assigned a new IP address, the other pods will find it difficult to keep track of the fluctuating ip address made by the front-end pod, so a definite way to counter this issue is the implementation of a service. With the aid of a service, the other pods trying to reach the frontend pod will send requests to the service ip known as the "clusterIP" when we run:

   kubectl get svc -n Kube-system

We see a service known as clusterIP. This IP will be the permanent IP of the front-end pod whether is destroyed or recreated as long as it is specified with a label and during the creation of the front-end pod and the service attached . Now let me explain what I mean by the label and selector. Here is the front-end YAML pod definition file:

apiVersion:v1

kind: Pod

metadata: name:nginx

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx

When we create the pod, we need to create a service and add the app: nginx to the selector specification:

apiVersion: v1

kind: Service

metadata:

name: frontend-svc

spec:

selector:

app: nginx

ports:

- port: 80

protocol: TCP

targetPort: 8080

#This will create a service and then bind to any pod with the "app: nginx" label and open traffic to port 8080 on the pod.

Moving forward to ingress, if you want to find out more about k8s services please do ensure to check out the official documentation page.

1. INGRESS Moving forward to ingress, A simple definition of ingress is the orchestration of load-balancing HTTP and HTTPS targeting services in a cluster. As we all know that a service can be assigned to multiple pods in a cluster, if an application is controlling a large number of external end-users, trying to reach out to the pod carrying the app through its URL will result in traffic, how does Kubernetes handle this traffic, simple, it creates more pods and balances the load among the pods. The ingress is responsible for routing and load-balancing traffic, assigning external reachable URLs terminating SSL / TLS and offering name-based virtual hosting. Also, we won't like end users accessing our applications using IP addresses such as 10.1.2.3:8080 to access our application, which is not easy to remember, but with ingress, we are able to appoint URLs to the service attached to the pod.

2. HOW INGRESS WORKS.

   First, we deploy an ingress controller as a deployment. These controllers work by routing incoming traffic to the appropriate service attached to your pods, based on the rules that you define. Some examples of ingress controllers are NGINX, HAProxy, and Envoy. For example, you might have a rule that sends all traffic to a specific URL to a web application, or you might have a rule that sends traffic to a different service based on the user's location. The ingress controller will have some set of rules known as ingress resources. A YAML to deploy Nginx as an ingress controller as deployment:

   apiVersion: extensions/v1beta1

   kind: Deployment

   metadata: name: nginx-ingress-controller

3. namespace: ingress-nginx

4. labels: app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx

5. spec:

6. replicas: 1

7. selector:

8. matchLabels:

9. app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx template:

10. metadata:

    labels:

    app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx spec:

11. serviceAccountName: nginx-ingress-serviceaccount

12. containers:

13. - name: nginx-ingress-controller

14. image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.25.1

15. args:

16. - /nginx-ingress-controller - --configmap=$(POD_NAMESPACE)/nginx-configuration - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services

17. - --udp-services-configmap=$(POD_NAMESPACE)/udp-services

18. - --publish-service=$(POD_NAMESPACE)/ingress-nginx

19. - --annotations-prefix=nginx.ingress.kubernetes.io

20. env:

21. - name: POD_NAME

22. valueFrom:

23. fieldRef:

24. fieldPath: metadata.name

25. - name: POD_NAMESPACE

26. valueFrom:

27. fieldRef:

28. fieldPath: metadata.namespace

After creating the deployment of the Nginx-ingress controller, we move forward to making the nginx resources. ingress resources are used for configuring URLs for reaching the services of k8s objects, which can be pods deployment service-account etcetera.