The software described in this documentation is either no longer supported or is in extended support.
Oracle recommends that you upgrade to a current supported release.
You can use services to expose access to one or more mutually interchangeable pods. Since pods can be replicated for rolling updates and for scalability, clients accessing an application must be directed to a pod running the correct application. Pods may also need access to applications outside of Kubernetes. In either case, you can define a service to make access to these facilities transparent, even if the actual backend changes.
Typically, services consist of port and IP mappings. How services function in network space is defined by the service type when it is created.
The default service type is the ClusterIP,
and you can use this to expose the service on the internal IP of
the cluster. This option makes the service only reachable from
within the cluster. Therefore, you should use this option to
expose services for applications that need to be able to access
each other from within the cluster.
Frequently, clients outside of the Kubernetes cluster may need access
to services within the cluster. You can achieve this by creating
a NodePort service type. This service type
enables you to take advantage of the Kube
Proxy service that runs on every worker node and
reroute traffic to a ClusterIP, which is
created automatically along with the NodePort
service. The service is exposed on each node IP at a static
port, called the NodePort. The Kube Proxy
routes traffic destined to the NodePort into
the cluster to be serviced by a pod running inside the cluster.
This means that if a NodePort service is
running in the cluster, it can be accessed via any node in the
cluster, regardless of where the pod is running.
Building on top of these service types, the
LoadBalancer service type makes it possible
for you to expose the service externally by using a cloud
provider's load balancer. This allows an external load balancer
to handle redirecting traffic to pods directly in the cluster
via the Kube Proxy. A NodePort service and a
ClusterIP service are automatically created
when you set up the LoadBalancer service.
As you add services for different pods, you must ensure that
your network is properly configured to allow traffic to flow
for each service declaration. If you create a
NodePort or LoadBalancer
service, any of the ports exposed must also be accessible
through any firewalls that are in place.
If you are using Oracle Cloud Infrastructure, you must add ingress rules to the security lists for the Virtual Cloud Network (VCN) for your compute instances connections. Each rule should allow access to the port that you have exposed for a service.
Equally, if you are running firewalld on any of your nodes, you must ensure that you add rules to allow traffic for the external facing ports of the services that you create.
For more information on services, see the upstream documentation at:
https://kubernetes.io/docs/concepts/services-networking/service/