Services

• Services groups pods to provide common access points from the external world to the containerized applications.
• kube-proxy daemon runs on each worker node to provide access to services.
• To access the application, a user/client needs to connect to the Pods.
• Pods are ephemeral in nature, resource like IP address allocated to it cannot be static.
• Pods could be terminated abruptly or be rescheduled based on existing requirements.
• Example: user/client is connected to a Pod using its IP address.
  
  Unexpecctly, the pod to which the user/client is connected is terminated, and a new Pod is created by the controller. The new Pod will have a new IP address, which will not be known automatically to the user/client of the earlier Pod.
  
  To overcome this situation, k8s provides a higher-level abstraction called Service, which logically groups Pods andd defines a policy to access them.
  Grouping is achieved via Labels Selectors.
• Example: app is the Label key, frontend and db are Label values for different Pods.
  
  Using the selectors app==frontend and app==db, we groups pods into two logical set: one with 3 Pods, and one with a single Pod.
  we assign a name to the logical grouping, referred to as a Service. In our example, we create two Services, frontend-svc, and db-svc, and they have the app==frontend and the** app==db** Selectors, respectively
  
• Services can expose:
  • single Pods
  • ReplicaSets
  • Deployments
  • DaemonSets
  • StatefulSets.

Service Object

• Example

  kind: Service
  apiVersion: v1
  metadata:
  name: frontend-svc
  spec:
  selector:
      app: frontend
  ports:
  - protocol: TCP
      port: 80
      targetPort: 5000
  

  • We create a frontend-svc Service
  • It selects all the Pods that have the Label key=app set to value=frontend
  • By default, each Service receives an IP address routable only inside the cluster, known as ClusterIP
    
  • in the example, we have 172.17.0.4 and 172.17.0.5 as ClusterIPs assigned to our frontend-svc and db-svc Servcies respectively.
  • The user/client now connects to a Servcie via its ClusterIP.
  • ClusterIP forwards traffic to one of the Pods attached to it.
  • A Service provides load balancing by default while selecting the Pods for traffic forwarding.
  • while the Service forwards traffic to Pods, we can select the targetPort on the Pod which receives the traffic.
  • in our example, the frontend-svc receives on port 80, then forwards these request to one fo the attached Pods on the targetPort 5000.
  • if the targetPort is not defined explicitly, then traffic will be forwarded to Pods on the port on which the Service receives traffic.
  • A logical set of Pod's IP address, along with the targetPort is referred as a Service endpoint
  • In our example, the frontend-svc Service has 3 endpoints:
    • 10.0.1.3:5000
    • 10.0.1.4:5000
    • 10.0.1.5:5000
      Endpoints are created and managed automatically by the Servcie, not by k8s cluster administrator.

Kube-Proxy

• All worker nodes run a daemon called kue-proxy.

• It watches the API server on the master node for the addition and removal of Services and endpoints.

• Example in iptables proxy mode:
  
  Kube-proxy, Services and Endponts (user DNS service discovery explained below.)

  • By default, kube-proxy in iptables mode chooses a backend at random.
  • for each new Service, on each node, kube-proxy configures iptables rules to capture the traffic for its ClusterIP and forwards it to one of the Service's endpoints.
  • Any node can receive the external traffic and then route it internally in the cluster based on the iptables rules.
  • When the Service is removed, kube-proxy removes the corresponding iptables rules on all nodes as well.

Service Discovery.

• Servcie are the primary mode of communication in K8s.
• We need a way to discover them at runtime.
• K8s supports two methods for discovering Services.
  • Environment Varialbes
  • DNS

Environment Variables

• As soon as the Pod starts on any worker node, the kubelet daemon running on that node adds a set of environment variable in the Pod for all active Services.
• Example:
  • if we have an active Service called redis-master, which exposes port 6379, and its ClusterIP is 172.17.0.6, then on a newly created Pod, we can see the following environment variables.

  REDIS_MASTER_SERVICE_HOST=172.17.0.6
  REDIS_MASTER_SERVICE_PORT=6379
  REDIS_MASTER_PORT=tcp://172.17.0.6:6379
  REDIS_MASTER_PORT_6379_TCP=tcp://172.17.0.6:6379
  REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
  REDIS_MASTER_PORT_6379_TCP_PORT=6379
  REDIS_MASTER_PORT_6379_TCP_ADDR=172.17.0.6
  

  • With this solution, we need to be careful while ordering our Services.
  • Pod will not have the environment variables set for Services which are created after thye Pods are created.

DNS

• K8s has an add-on for DNS
• DNS record for each Service format is my-svc.my-namespace.svc.cluster.local.
• Service within the same Namespace find other Services just by their name.
• If we add a Service redis-master in my-ns Namespace, all Pods in the same Namespace lookup the Service just by its name, redis-master.
• Pods from other Namespace lookup the same Service by adding the respective Namespce as a suffix, such as redis-master.my-ns.
• DNS is the most common and highly recommended solution.

Service Type.

• We can choose access scope for Service.
  • Is only accessible within the cluster.
  • Is accessible from within the cluster and the external world.
  • Maps to an entity which resides either inside or outside the cluster.
• Access scope is decided by ServiceType, which can be configure when creating the Service.

ClusterIP

• is the default ServiceType.
• A Service receives a VirtualIP address, known as its ClusterIP.
• This Virutal IP address is used for communicating with the Service and is accessible only within the cluster.

NodePort

• in addition to a ClusterIP, a high-port, dynamically picked form the defualt range 30000 - 32767 , is mapped to the respective Service, from all the worker nodes.
• Example: if the mapped NodePort is 32233 for the service frontend-svc, then, if we connect to any worker node on port 32233, the node would redirect all the traffic to the assigned ClusterIP - 172.17.0.4.
• if we prefer a specific high-port number instead, then we can assign that high-port number to the NodePort fro mthe default range.
  
  NodePort
• The NodePort ServiceType is useful when we want to make our Services accessible from the external world.
• The end-user connects to any worker node on the specified high-port, which proxy the request internally to the ClusterIP of the Service, then the reqeust is forwarded to the applications running inside the cluter.
• To access multiple applications from the external world, administrators can configure a reverse proxy - an ingress, and define rules that target Services within the cluster.

LoadBalancer

• NodePort and ClusterIP are automatically created, and the external load balancer will route to them.
• The Service is exposed at a static port on each worker node.
• The Service is exposed extrnally using the underlying colud provider's load balancer feature.
  
  LoadBalancer
• The LoadBalancer ServiceType will only work if the udnerlying infrastructure supports the automatic creation of Load Balancers and have the respective support in K8s, e.g Google Could Platforms and AWS.
• If infrastructure doesn't support the feature, the LoadBalancer IP address field is not populated, and the Service will work the same way as a NodePort type Service.

ExternalIP

• A Service can be mapped to na ExternalIP address if it can route to one or more of the worker nodes.
• Traffic that is ingressed into the cluster with the ExternalIP (as destination IP) on the Service port, gets routed to one of the Service endpoints.
• This type of servcie requires an external could provider such as Google Cloud Platform or AWS.
  
• ExternalIPs are not managed by K8s.
• The cluster administator has to configure the routing which maps the ExternalIP address to one of the nodes.

ExternalName

• External Name is a special ServiceType, that has no Selectors and doesn't define any endpoints.
• When accessed within the cluster, it returns a CNAME record of an externally configured Service.
• The primary use case of this ServiceType is to make externally configured Services like my-database.example.com available to applicaitons inside the cluster.
• If the externally defined Service resides within the same Namesapce, using just the name my-database would make it available to other applications as Services within that same Namespace.