While building a Service over another, we may think of multiple layers for port forwarding. In spite of redirecting traffic from one port to another, the action of exposing a Service is actually copying the setting of one Service to another. This scenario could be utilized as updating the Service setting, without causing headaches to current clients and servers:

// create a Service by expose an existed one
// take the one we created for Deployment for example
$ kubectl expose svc another-nginx-service --port=8081 --target-port=80 --name=yet-another-nginx-service --session-affinity="ClientIP"
service "yet-another-nginx-service" exposed
// check the newly created Service
$ kubectl describe svc yet-another-nginx-service
Name:              yet-another-nginx-service
Namespace:         default
Labels:            env=dev
                   project=My-Happy-Web
                   role=frontend
Annotations:       <none>
Selector:          project=My-Happy-Web,role=frontend
Type:              ClusterIP
IP:                10.110.218.136
Port:              <unset>  8081/TCP
TargetPort:        80/TCP
Endpoints:         192.168.79.15:80,192.168.79.21:80,192.168.79.24:80
Session Affinity:  ClientIP
Events:            <none>

Here we are! We successfully exposed another Service with similar settings to the Service another-nginx-service. The commands and output can be summarized as follows:

• A new Service name is required: Although we can copy the configurations from another Service, the name of the resource type should always be unique. When exposing a Service without the tag --name, you will get the error message: Error from server (AlreadyExists): services "another-nginx-service" already exists.
• Adding or updating the configuration is workable: We are able to add a new configuration, like adding session affinity; or we can update the port of the Service, like here, where we change to open port 8081 instead of 8080.
• Avoid changing target port: Because the target port is along with the IP of the Pods, once the Service exposing changes the target port, the newly copied Service cannot forward traffic to the same endpoints. In the preceding example, since the new target port is defined, we should point out the container port again. It prevented the new Service from using the target port as the container port and turned out a misleading transaction.

With session affinity, the list of description tags session affinity as ClientIP. For the current Kubernetes version, the client IP is the only option for session affinity. It takes the action as a hash function: with the same IP address, the request will always send to the identical Pod. However, this could be a problem if there is a load balancer or ingress controller in front of the Kubernetes Service: the requests would be considered to come from the same source, and the traffic forwarded to a single Pod. Users have to handle this issue on their own, for example, by building an HA proxy server instead of using the Kubernetes Service.