Service și accesul la aplicație

Pod-urile sunt efemere, iar adresele lor IP se pot schimba. Un Service oferă un endpoint stabil și direcționează traficul către Pod-urile care îi corespund.

Fișierul k8s/base/30-service.yaml conține:

apiVersion: v1
kind: Service
metadata:
  name: ticketing-api
  namespace: cc-lab2
spec:
  type: ClusterIP
  selector:
    app: ticketing-api
  ports:
    - name: http
      port: 80
      targetPort: http
      protocol: TCP

Aplicați manifestul și inspectați Service-ul:

kubectl apply -f k8s/base/30-service.yaml
kubectl get services -n cc-lab2
kubectl describe service ticketing-api -n cc-lab2
kubectl get endpointslices -n cc-lab2 \
  -l kubernetes.io/service-name=ticketing-api

Service-ul este de tip ClusterIP, deci este accesibil în interiorul clusterului. Pentru laborator folosim port-forward:

kubectl port-forward service/ticketing-api -n cc-lab2 8080:80

Păstrați comanda activă și, într-un alt terminal, executați:

curl http://localhost:8080/health
curl http://localhost:8080/info
curl http://localhost:8080/tickets

Răspunsul /info are forma:

{
  "service": "ticketing-api",
  "version": "v1",
  "instance": "ticketing-api-xxxxxxxxxx-yyyyy"
}

Câmpul instance este numele Pod-ului care a tratat cererea.

Pentru un test executat din interiorul clusterului puteți folosi un Pod temporar:

kubectl run curl \
  --namespace cc-lab2 \
  --rm -it \
  --restart=Never \
  --image=curlimages/curl:latest \
  -- http://ticketing-api/info

În interiorul aceluiași namespace, numele ticketing-api este rezolvat prin DNS către Service.

De ce nu folosim NodePort

Pentru un laborator local, port-forward este suficient și nu depinde de un port fix de pe nod. Tipurile NodePort, LoadBalancer și Ingress vor fi folosite numai în contexte în care expunerea externă este necesară.