# Kubernetes Services Services are "grouping" Pods to track changes on the networking level. The This is needed as Pods are ephemeral by design (Deployments may create and destroy Pod dynamically) and thus information related to connectivity are constantly changing. Other resources on a cluster are typically pointed to services instead of individual Pods. The service takes the requests and distributes the workload to the Pods in its "group".*Labels* are used as *Selectors* to target the Pods within a service. In short a Service can be viewed as the "frontend" for a group of pods, which serve as the "backend" to run a application. The service can be one of the different types — for example: - `NodePort` — exposes a port on the external IP of the node (e.g. for testing) - `LoadBalancer` — exposes a service **externally** via an external loadbalancer (e.g. within cloudproviders) - `ClusterIP` — exposes service **interanally** within a cluster > [!INFO] > If a Service is exposing Pods with multiple replicas but without proper underlying (shared) storage, changes made to the Pod's local filesystem are only saved in one replica of the Pod! > > For example: > > Two replicas of the Pod "uptimekuma" are exposed via the service "uptimekuma" > > ```bash > $ kubectl get pods > NAME READY STATUS RESTARTS AGE > uptimekuma-6d99b9cffd-jr9sh 1/1 Running 0 23m > uptimekuma-6d99b9cffd-wcllg 1/1 Running 0 23m > ``` > > ```bash > $ kubectl get svc > NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE > uptimekuma LoadBalancer 10.43.121.86 192.168.5.15 3001:31951/TCP 8s > ``` > > The application is then accessed via then local browser on `https://localhost:3001` and initialized (account setup). > > This is only saved to the Pod `uptimekuma-6d99b9cffd-jr9sh` — the other Pod `..-wcllg` remains unconfigured (or better: "the application's state in the Pod remains unconfigured), which results in an inconsistent state of the Deployment. A direct `port-forward` bypasses this issue, since it connects to one Pod specifically rather than going through the Service. ## Common kubectl commands - `kubectl expose deployment <DEPLOYMENT> --port <PORT>` exposes a resource as a new Kubernetes service (could technically also be used for Pods using `expose pod`). Labels in the definition will be used as the selector for the exposed service, so Kubernetes how which resources (Pods) to target - `kubectl apply -f <FILE>` to apply a definition - `kubectl get service` to liste active services on the cluster (this can also be used to create a defintion file using `-o yaml`) - `kubectl config set-context --current --namespace=default` to set the default namespace for the current context - `kubectl port-forward services/<SERVICE> <PORT>` to port-forward to a service - `kubectl get service <SERVICE> -o yaml > <FILE>.yaml` to create a definition from a created deployment - `kubectl delete service <SERVICE>` to delete a service ## Tips - `svc` is a shorthand for `service` - In [[Rancher Desktop]] a service of the type `Loadbalancer` can be used to expose applications on the host. --- ## Related - **previous** [[Kubernetes]] - **see** [[kubectl]] for details on how to interact with the Kubernetes API - **see** [[Kubernetes Pods]] for more information about the concept of Pods - **see** [[Kubernetes Storage]] for more information about storage concepts in Kubernetes - **see** [[Rancher Desktop]] for more information on the application ## Sources - **references** [[03.04.04.02 Services in Kubernetes]] as the reference of the course module teaching the fundamentals of Kubernetes - **references** [Kubernetes Docs](https://kubernetes.io/docs/concepts/services-networking/service/) for the official documentation of services ## Usage - **used in** [[A typical note from my vault]]