Feedback - Lab 3¶
General pipeline¶
Take in mind past feedback and keep your pipeline clean and readable. Remove all debug statements when you have an operational pipeline. This was explicitly mentioned in the assignment and is best practice.
Also only use cache and artifacts when needed, The kubernetes deploy step does not need to use maven cache or built artifacts so downloading these only slows things down and wastes resources.
Questions¶
ReplicaSet¶
Most groups answered this question correctly. The ReplicaSet is responsible for ensuring that the number of replicas of a Pod matches the desired number of replicas. It does this by creating or deleting Pods as necessary.
However, some groups did not answer the second part of the question (correctly), that is explaining its behavior during an upgrade. During an upgrade, a new ReplicaSet will be created with the new version of the Pod. The old ReplicaSet will be scaled down to 0 replicas and this can be done in what is called a rolling upgrade. This ensures that the new version of the Pod is running before the old version is terminated.
Game request flow and diagram¶
Below we provide a diagram of the request flow inside Kubernetes, from the game server to the logic service. This is a simplified version of the actual flow, but it should give you a good idea of how services and pods are connected through endpoints.
We have not included the DNS resolution process, but you should be aware that Kubernetes uses CoreDNS to resolve DNS names. CoreDNS is deployed as a Kubernetes service itself in the kube-system namespace.
The game servers sends requests to a list of team URLS like this one:
http://logic-service.devops-team1/moves/unit
The HTTP protocol implies port 80. A Kubernetes Service is reachable on a DNS name that is the same as the name of the service within its own namespace.
Outside of its namespace, the namespace name gets appended to the DNS name. The DNS name can be specified even more explicitly by using the fully qualified domain name (FQDN) of the service. The FQDN of a service is constructed as follows:
logic-service.devops-team1.svc.cluster.local
The svc.cluster.local is implied and does not have to be specified.
The service is configured to route requests on port 80 to the target port 8080 of its pods. Note that you can also name the port of your pods and services, to denote the purpose of the port. This is especially useful when you have multiple ports in your pod or service.
When a service is created, Kubernetes automatically creates an associated Endpoint object. The Endpoint object maintains the IP addresses and port numbers of the pods that match the service’s selector criteria.
To understand how Kubernetes Endpoints work, let’s break down the process:
- Service Creation: When you create a service in Kubernetes, you define a selector that matches a set of pods. This selector determines which pods the service will route traffic to.
- Endpoint Creation: Kubernetes automatically creates an Endpoint object associated with the service. This object contains the IP addresses and ports of the pods that match the selector.
- Updating Endpoints: As pods are added or removed, or their statuses change, Kubernetes continuously updates the Endpoint object to reflect the current set of matching pods. This ensures that the service always routes traffic to the appropriate pods.
Some kubectl commands to illustrate this:
edu-devops-cluster/devops-team19 ~ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
logic-service ClusterIP 10.109.24.104 <none> 80/TCP 30d
edu-devops-cluster/devops-team19 ~ kubectl get endpoints
NAME ENDPOINTS AGE
logic-service 192.168.104.47:8080 30d
edu-devops-cluster/devops-team19 ~ kubectl get pods -owide
NAME READY STATUS RESTARTS AGE
logic-service-79f4669df7-q7ppq 1/1 Running 0 10m 192.168.104.47 node2 <none> <none>