68 Red Hat OpenShift and IBM Cloud Paks on IBM Power Systems: Volume 1
      protocol: TCP
      targetPort: 8080
  selector:
    name: httpd-test03
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}
NodePorts are in the 30000-32767 range by default, which is unlikely to match a service’s 
intended port.
For service and application access, the administrator must ensure that the external IPs are 
routed to the nodes and local firewall rules on all nodes allow access to the open port. The 
DNS wildcard feature can be used to configure resolution for a subset of names to an IP 
address in the cluster. 
The service is accessed by using the <NodeIP>:30080 address, as shown in Example 4-2.
4.3  OpenShift persistent storage
Because Plain Docker storage is not shared between nodes, it is not enough for container 
service availability because pods might be stopped on one node and restarted on another 
node at any time. If a database pod is stopped and restarted on another node, any stored 
data is lost.
Kubernetes provides a framework for managing external persistent storage for containers. 
Kubernetes recognizes a PersistentVolume resource, which can be defined as local or 
network storage. A pod resource can reference a PersistentVolumeClaim resource to access 
storage of a certain size from a PersistentVolume.
Kubernetes also specifies whether a PersistentVolume resource can be shared between pods 
or if each pod needs its own PersistentVolume with exclusive access. When a pod moves to 
another node, it stays connected to the same PersistentVolumeClaim and PersistentVolume 
instances. Therefore, a pod’s persistent storage data follows it, regardless of the node where 
it is scheduled to run.
OpenShift adds several VolumeProviders to Kubernetes, which provide access to enterprise 
storage, such as iSCSI, Fibre Channel, Gluster, or a cloud block volume service, such as 
OpenStack Cinder.
OpenShift also provides dynamic provisioning of storage for applications by way of the 
StorageClass resource. By using dynamic storage, you can select different types of back-end 
storage. The back-end storage is segregated into different tiers, depending on the needs of 
your application. 
For example, a cluster administrator can define a StorageClass with the name of “fast,” which 
uses higher-quality back-end storage, and another StorageClass called “slow,” which provides 
commodity-grade storage. 
When requesting storage, a user can specify a PersistentVolumeClaim with an annotation 
that specifies the value of the StorageClass that they prefer.