A service provides an abstract way to expose an application running on a set of Pods as a network service.
For example, suppose you have a set of Pods that each listen on TCP port 9376 and carry a label app=MyApp:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
Services can be one of the following four types:
- ClusterIP
- NodePort
- LoadBalancer
- ExternalName
ClusterIP is the default and only provides access internally
NodePort is great for when static IP addresses are necessary, such as opening a specific IP through a firewall. It is a simple connection from a high-port routed to a ClusterIP using iptables or ipvs. The creation of a NodePort generates a ClusterIP by default. The traffic is routed from the NodePort to the ClusterIP.
LoadBalancer was created to pass requests to cloud provider like AWS. The address is made available to public traffic and packers are spread among the Pods in the deployment automatically.
ExternalName allows the return of an alias to an external service. It is used for services not yet brought into the Kubernetes cluster (a bit like a placeholder). Once those services are ready we can then change the type and traffic would flow to the internal objects.
kubectl proxy creates a local service to access a ClusterIP which can be useful for troubleshooting
Exposing an application with a Service
We can use kubectl expose command which exposes a resource as a new Kubernetes service.
Ingress
An ingress is an API object that manages external access to the services in a cluster, typically HTTP.
Ingress can provide:
- load balancing
- SSL termination
- name-based virtual hosting
Service Mesh
We can implement a service mesh for more complex connections or resources, such as service discovery, rate limiting, traffic management and advanced metrics.
A service mesh consists of edge and embedded proxies communicating with each other and handling traffic based on rules from the a control plane.
Top comments (0)