[Kubernetes] Services

A Service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service).

Through services, you can expose applications running in a pod.
Pods are created and deleted dynamically so that it is not practical to communicate with pods directly. A service expose a set of pods and provides the load-balancing of the traffic across them.


Kubernetes Services

Service | Kubernetes

  • A service provides a single point of entry for accessing one or more pods.
    • Pods are ephemeral and may only live a short time. For example, each pod gets its own IP address and you cannot rely on a pod id address staying the same.
  • A service creates endpoints between the service and pods.
  • The set of pods targeted by a service is usually determined by a selector.
  • The roles of a service
    • abstracts pod IP addresses.
    • works on TCP/UDP (OSI Layer 4). kube-proxy creates a virtual IP for services.
    • relies on labels to associate a service with a pod.
    • provides load balancing among pods.

Port Configuration

  • Port
    • the port in the service within the cluster
    • Other pods within the cluster communicate with the service using this port
  • TargetPort
    • the port of a pod
    • A service will send requests to pods using target ports.
    • Labels and selectors are used to map services and pods.
  • NodePort
    • the port that a service exposes externally
    • Any client outside of the cluster send requests to the service on this port

Service Types

  • ClusterIP
    • The ClusterIP exposes the unique IP of the service internally within a cluster (default).
    • Only pods within a cluster can access the service.
    • Pods can communicate with other pods.
    • ex) internal communications: between front-end pods and the back-end pods or between the back-end pods and the database
  • NodePort
    • The NodePort exposes the service node using a static port (30000 ~ 32767) to external clients outside of the cluster.
    • Each node proxies the allocated port.
  • LoadBalancer
    • The LoadBalancer exposes the service externally using a cloud provider’s load balancing service.
  • ExternalName
    • The ExternalName exposes an external resource inside the cluster using DNS.

Creating a service – ClusterIP

  • Create a YAML file
kubectl create service clusterip my-service \
--tcp=80:80 --dry-run=client -o=yaml > svc.yaml
  • Open the svc.yaml and update the labels.
apiVersion: v1
kind: Service
metadata:
  labels:
    app: my-app
  name: my-service
spec:
  ports:
  - name: 80-80
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: my-app
  type: ClusterIP
  • Run or apply
kubectl create -f svc.yaml
kubectl apply -f svc.yaml
  • Check the service
kubectl get svc
kubectl describe svc my-service

Creating a service – NodePort

  • Create a YAML file
kubectl create service nodeport my-port-service \
--tcp=80:80 --node-port=30085 \
--dry-run=client -o=yaml > svc-port.yaml
  • Open the svc-port.yaml and update the labels.
apiVersion: v1
kind: Service
metadata:
  labels:
    app: my-app
  name: my-port-service
spec:
  ports:
  - name: 80-80
    nodePort: 30085
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: my-app
  type: NodePort
  • Run or Apply
kubectl create -f svc-port.yaml
kubectl apply -f svc-port.yaml
  • Check the service
kubectl get svc
kubectl describe svc my-port-service


Working with services in the cluster

kubectl get services
kubectl describe svc <service-name>

kubectl get endpoints
 kubectl describe endpoint <endpoint-name>

kubectl delete service <service-name>

Checking the status of the kubelet service

sudo systemctl status kubelet

Port Forwarding

Using port forwarding, you can access a pod from outside of Kubernetes cluster.

# listen on 8080 and forward to 80 in a pod
kubectl port-forward pod/<pod-name> 8080:80

kubectl port-forward deployment/<deployment-name> 8080:80 

kubectl port-forward service/<service-name> 8080:80

Network Policies

  • Network policies specify how a pod communicated with various network entities, such as services or endpoints use over the network.
  • Network policies restrict and control the network traffic going to and from the pods.
  • By default, pods are non-isolated; they accept traffic from any source.
  • Pods can be isolated by a NetworkPolicy.
  • In NetworkPolicy, you can specify Ingress and Egress rules (based on whitelist rules).
    • spec.podSelector: determines which pods are used (matchLabels)
    • spec.policyTypes: ingress, egress, or both
    • spec.ingress: rules for incoming traffic
    • spec.egress: rules for outgoing traffic
    • spec.ingress.from: the source of network traffic
      • ipBlock, podSelector, or/and namespaceSelector
    • spec.egress.to: the destination of network traffic
      • ipBlock, podSelector, or/and namespaceSelector
    • spec.ingress(egress).ports: the protocol and the port
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
spec:
  podSelector:
    matchLabels:
      app: secure-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: client
    ports:
    - protocol: TCP
      port: 80
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 80
kubectl get networkpolicies
 
kubectl describe networkpolicy <name>

kubectl delete networkpolicy <name>

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s