Defining Service Types

OKD supports many service types to accommodate a variety of use cases. The following lists presents the available service types.

Cluster IP (ClusterIP)

This service type exposes the service using an IP internal to the cluster. As such, this IP is not accessible from an external network. This is the default value when you define a service; as an administrator, you can configure the CIDR for these IPs at installation time.

Node port (NodePort)

This service type instructs the OKD control plane to map to an IP address that a node in the cluster uses. This is a legacy type, and Red Hat recommends using routes instead, which expose the service as a host name. Routes are discussed in the next section.

When using this service type, each node proxies the same port number on every node to your service. Node ports are in the 30000-32767 range by default, which means that a node port is unlikely to match an intended port for a service.

Load balancer (LoadBalancer)

This service type exposes the service through a cloud provider load balancer. You access the virtual IP of the provider's load balancer, and the OKD control plane automatically creates a node port or cluster IP to route the incoming packets.

External name (ExternalName)

This service type creates a CNAME in the DNS zone that matches an external hostname. You typically use this service type to create different access points for applications that are external to the cluster. The service returns the CNAME record whose value matches the external name.

The various service types allow you to control how to access your services. Some service types may be better suited for your environment, such as the LoadBalancer type when deploying in Amazon Web Services (AWS), Microsoft Azure, or Google Compute Engine (GCE).

With this service type, OKD redirects the traffic from the external load balancer to the backend pods, however, the provider determines the load balancing mechanism and strategy. This can increase the administration overhead associated with the cluster, as you must also manage the permissions for developers to create or delete their services.

The NodePort type is an older Kubernetes-based approach, whereby the control plan exposes the service to external clients by binding to available ports on the node host. The node then proxies connections to the service IP address. Then you access your application through the node host and the port value.

When using this service type, you must manually maintain the list of ports that you use to avoid port collisions. Moreover, you must use a valid port number, that is, a port that is inside the range and that is configured for the NodePort service type.

The ExternalName service type is a recent addition. Services that use this service type do not map to selectors. Instead, they use DNS names to determine how to access the application that matches the hostname. The control plane creates a CNAME record whose value corresponds to the external name.

This is a convenient solution for migrating your legacy applications to the cluster, as you can run parts of the application outside of the cluster until their migration is complete.