Hello folks, today we are going to get a wide understanding about services in Kubernetes and also the Ingress. So, from part one and two I gave you some background knowledge about Kubernetes and their workloads. Now we can expand our knowledge with services and Ingress. So, let's go then.
Services:
A way to expose a network application that is operating as one or more Pods in your cluster is called a service in Kubernetes. The fact that using a new service discovery mechanism doesn't need changing your current application is one of the main goals of Services in Kubernetes. Code that was created for a cloud-native environment or an older app that you containerized can both be executed in Pods. To enable clients to interact with that collection of Pods, you utilize a Service to make them accessible via the network. Here I attached some sample code for your YAML file to create your first service.
And there is three main service types. Those are ClusterIP, Nodeport and loadebalancer. Now we can explore them one by one.
ClusterIP:
An IP address is assigned by this default service type from a pool of IP addresses that your cluster has set aside specifically for that use. The ClusterIP type serves as the basis for a number of other Service types. Kubernetes does not allocate an IP address to a service that you specify with the.spec.clusterIP set to "None". Refer to headless Services for additional details.
When submitting a request for the development of a service, you can include your own cluster IP address. Set the.spec.clusterIP field to accomplish this. For instance, if you want to reuse an existing DNS entry or if you have legacy systems that are hard to reconfigure and are set up for a specific IP address.
The IP address you select needs to be a working IPv4 or IPv6 address that falls under the CIDR range service-cluster-ip-range that is set up for the API server. An error 422 HTTP status code will be returned by the API server if you attempt to create a Service with an invalid clusterIP address value.
NodePort:
The Kubernetes control plane assigns a port from the range indicated by the --service-node-port-range flag (default: 30000-32767) if the type field is set to NodePort. Every node proxies that port into your service (which is the same port number on every node). The assigned port is reported by Your Service in the field called.spec.ports[*].nodePort.
You can setup environments that Kubernetes does not completely support, create your own load balancing solution, or even expose the IP addresses of one or more nodes directly by using a NodePort.
You can enter a value in the nodePort field to indicate a specific port number. Either that port will be assigned to you by the control plane, or it will report that the API transaction failed. This implies that you are responsible for handling any potential port clashes. Additionally, the port you use must be inside the range set up for NodePort use.
This is a sample manifest that defines a NodePort value (30007 in this case) for a Service of type:
Load-Balancer:
You can enter a value in the nodePort field to indicate a specific port number. Either that port will be assigned to you by the control plane, or it will report that the API transaction failed. This implies that you are responsible for handling any potential port clashes. Additionally, the port you use must be inside the range set up for NodePort use.
This is a sample manifest that defines a NodePort value (30007 in this case) for a Service of type:
The backend Pods receive traffic that is directed from the external load balancer. The load balancing mechanism is chosen by the cloud provider.
Kubernetes usually begins by making the necessary modifications to match your request for a Service of type: NodePort in order to create a Service of type: LoadBalancer. The external load balancer is then set up by the cloud-controller-manager component to send traffic to the designated node port.
When configuring a load-balanced service, you can choose not to assign a node port as long as the cloud provider implementation permits it.
You may be able to define the loadBalancerIP with certain cloud providers. In some situations, the loadBalancerIP that the user specifies is used to create the load-balancer. The load balancer is configured with an ephemeral IP address if the loadBalancerIP field is left empty. The loadbalancerIP field you set is disregarded if you supply one but your cloud provider does not support the capability.
So this is my description about Kubernetes services and then, I'm going to tell share some knowledge about ingress in Kubernates.
Ingress:
This is an API object that manages external access to the services in a cluster, typically HTTP. Ingress may provide load balancing, SSL termination and name-based virtual hosting. Services within the cluster can access HTTP and HTTPS routes from outside the cluster through ingress. Rules that are defined on the Ingress resource govern traffic routing. And here I added some sample image for your understanding.
And there is two basic routing methods called, path based routing and name based routing.
So, this is the content that I hope to cover in this article and hope you guys got some background idea about Kubernetes services & ingress. stay tuned for next...
Top comments (0)