A Service is an abstract way to expose an application running on Pods as a network service. This allows the networking and application to be logically decoupled so state changes in either the application itself or the network connecting application components do not need to be tracked individually by all portions of an application.
Link to section 'Service resources' of 'Services' Service resources
In Kubernetes, a Service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service). The set of Pods targeted by a Service is usually determined by a Pod selector, but can also be defined other ways.
Link to section 'Publishing Services (ServiceTypes)' of 'Services' Publishing Services (ServiceTypes)
For some parts of your deployment you may need to expose an application externally from the cluster using Services
Kubernetes ServiceTypes allow you to specify what kind of Service you want. The default is ClusterIP.
ClusterIP: Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default ServiceType.
NodePort: Exposes the Service on each Node’s IP at a static port (the NodePort). A ClusterIP Service, to which the NodePort Service routes, is automatically created. You’ll be able to contact the NodePort Service, from outside the cluster, by requesting
LoadBalancer: Exposes the Service externally using a cloud provider’s load balancer. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created.
You can see an example of exposing a workload using the LoadBalancer type in the examples section.
An Ingress is an API object that manages external access to the services in a cluster, typically HTTP/HTTPS. An Ingress is not a ServiceType, but rather brings external traffic into the cluster and then passes it to an Ingress Controller to be routed to the correct location. Ingress may provide load balancing, SSL termination and name-based virtual hosting. Traffic routing is controlled by rules defined on the Ingress resource.
You can see an example of a service being exposed with an Ingress in the examples section.
Link to section 'Ingress Controller' of 'Services' Ingress Controller
In order for the Ingress resource to work, the cluster must have an ingress controller running to handle Ingress traffic.
Geddes provides the nginx ingress controller configured to facilitate SSL termination and automatic DNS name generation under the
Kubernetes provides additional information about Ingress Controllers in the official documentation.