### Overview ![[Pasted image 20250210151400.png|k8s-networking-objects]] ### Service In Kubernetes, a Service is a method for **exposing** a network application that is running as one or more pods. - service is not a resource but a rule in iptables. - `kube-proxy` provides the services. - pods and services are connected to each other by [[Objects#Label & Selector|labels/selectors]]. Labels will be assigned to pods, while a service collects them with given selectors. - services have vIP (virtual IP). #### High-availability ![[Pasted image 20250210151827.png]] In the figure above, **all** backends are connected to **all** frontends. This is done by connecting all backend and frontend pods to backend service. So if one of them goes down, it has minimal effect of the cluster. #### Service types ![[Pasted image 20250210153157.png]] 1. `ClusterIP`: exposes the service on a cluster-internal IP that is only reachable within cluster. For exposing to the internet, an Ingress or Gateway can be used. 2. `NodePort`: ClusterIP + exposing the service on each node's IP at a static port. 3. `LoadBalancer`: NodePort + exposing to a **external** load-balancer. 4. `ExternalName`: LoadBalancer + mapping CNAME for cluster's DNS server. From 1 to 4, each of them have the above features + their own. (e.g. NodePort has all the features of ClusterIP) Normally if you don't have an external load-balancer in your cloud provider, ClusterIP + Ingress is the default solution. #### Headless Service ![[Pasted image 20250210152529.png]] Headless services don't have a cluster/virtual IPs and thus, they can't be used as a load-balancer. This can be *used for stateful services* where we always want to request the master pod. #### Endpoints When a service connects to pods by selectors, kubernetes automatically creates an *endpoint* object associated with the service. This objects contains the IP addresses and ports of the pods that match the selector. If a pod is **not** in the cluster, by changing the endpoint of the service to the IP of the pod, the service can discover the pod. There is also a more advanced version of endpoints called *endpoint-slice* where endpoints can be grouped to help with efficiency of discovery and load-balancing. ![[Pasted image 20250210155520.png]] ### Host Networking ![[Pasted image 20250210160319.png]] Instead of using cluster IPs, it will use real IPs of the physical node. This is not considered a normal usage and should be done if you know what you're doing :LiLaugh: ### Network policy By default, we have an any-to-any pod access in a Kubernetes cluster. This can be changed using a *network policy* in layer 3/4 of network. Normally, [[Objects#Namespaces|namespaces]] can be isolated for more strict approach. However, a more strict isolation within namespaces can be implemented. Make sure your [[CRI#CNI & CSI|CNI]] supports what you want to do with your network policy. ### Ingress *Ingress* is a router to to route the outbound traffic to the cluster. It can be used as a reverse-proxy for the cluster. Just like reverse proxies, the example of Ingresses are nginx and traefik. Ingresses also loadbalance between pods in layer-7 of the network. ![[Pasted image 20250210212838.png]] ### Port forwarding ![[Pasted image 20250210213258.png]] We can connect to a resource (pod/sercvice/replicaSet) in a cluster by forwarding a port on the resource to our local port. It can be done for maintenance and development purposes. ### CNI As discussed [[CRI#CNI & CSI|here]] *CNI*s are an external component to the cluster with two main responsibilities of: 1. pod-to-pod connectivity 2. IPAM (IP Address Management) e.g. pulling, assigning They should handle both two types of network: 3. *overlay*: by VXLAN 4. *underlay*: by connecting to physical layer