Consistent Kubernetes service object naming

[chrisjs]

Currently when a stream is created, the deployer creates the appropriate deployment object along with a service object which could be of type clusterIP (default), NodePort or LoadBalancer toggled based on deployer properties.

For example:

service/ticktock-log-v1

The version number will change on subsequent deploys of the stream. This application name with the version number concatenated is passed into the deployer. The deployer uses the application name as for example, the name of the service. Typically this would make sense - i.e: if your deploying an app called "nginx" a sensible name for the service object would the static name nginx.

Not having a consistent service name is problematic in some use-cases, for example:

• Feature request : add a support to auto create an additional clusterIP service with respect to deploymentLabel spring-cloud-deployer-kubernetes#370

  • Work around needed

• Support configuring ingress spring-cloud-deployer-kubernetes#184

  • Ingress uses serviceName: https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/networking/types.go#L463

Having a static name as expected would alleviate needs for work around as well as allow other things that depend on those names to work out of the box

[sabbyanandan]

There are also requests for the predictable service names from a monitoring perspective, too.

Example:

The name of application includes the version number of the application when apps are deployed through GUI (dashboard), which makes it hard for them to track the log.

Background: We do tracing with DataDog, and if application's service name contains dynamic strings, it makes the monitoring hard.

[chrisjs]

ideally names would be normalized, labels would be used for selectors, annotations used for metadata. probably need to consider any backwards compatibility issues for existing streams to make sure they and their corresponding objects get cleaned up properly

looks related as well: #927

[chrisjs]

as a concrete example using a deployment and service, given kubernetes already allows for tracking versions, doing rollbacks, etc, natively the following may be used for consideration in implementation.

this may also remove the need for: spring-cloud/spring-cloud-deployer-kubernetes#196 given theres no need to mess around with the LB, its just updating the deployment. there may be additional projects where changes are needed.

in the following an nginx deployment and service is created, the image version is changed, undo / undo to specific revision is performed. nginx is used in this example as it has no dependencies but can be any application..

$ kubectl create -f nginx-deployment.yaml
$ kubectl create -f nginx-svc.yaml

$ kubectl get svc -l app=nginx
NAME    TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
nginx   LoadBalancer   10.106.78.8   192.168.99.112   80:32427/TCP   5s

$ curl 192.168.99.112
...
<title>Welcome to nginx!</title>
...

$ kubectl describe pod/nginx-deployment-574b87c764-849gc | grep Image:
    Image:          nginx:1.14.2

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
..
new pod comes up, the old terminates
..

$ kubectl describe pod/nginx-deployment-5d66cc795f-pdcwp | grep Image:
    Image:          nginx:1.16.1

$ curl 192.168.99.112
...
<title>Welcome to nginx!</title>
...

$ kubectl rollout history deployment.v1.apps/nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record=true

$ kubectl rollout undo deployment.v1.apps/nginx-deployment
- OR to undo or specific a specific version: -
$ kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=1

$ kubectl describe pod/nginx-deployment-574b87c764-xfmp4 | grep Image:
    Image:          nginx:1.14.2

# revision is already stored for you as metadata if needed
$ kubectl describe deployment nginx-deployment | grep revision
Annotations:            deployment.kubernetes.io/revision: 3

...
<title>Welcome to nginx!</title>
...

$ kubectl delete deployment,service -l app=nginx

obviously simplistic example but shows the built in ability to change image versions without incrementing names, labels, etc while also maintaining the existing load balancer.

some output and other explanations omitted as full examples are available in the docs at: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment

[chrisjs]

releated PR should cover keeping the service name consistent. seems like that may be the furthest we can do with the skipper model...