Services, Networking and Load Balancing

There are a number of components that help run the app from within. These parts help things operate smoothly and balance the load put on the backend or frontend pods.

Services

Pods have to be contained and controlled to create an efficient app. The service is typically determined by a selector to help organize the pods and establish access.

Within Kubernetes, the service is a piece available through an internal IP address that balances loads and acts as an ambassador for pods. A service can be deployed to perform a service to a logical collection of pods, treating them as a single entity. With this component, you can track and control the backend containers of a specific type.

Consumers only see the stable endpoint, but the service allows you to scale out or adjust backend workload units as needed. You can configure a service whenever you need to allow access to one or more pods from another app or external consumer. Clients don’t even need to know these services exist, since they operate in the backend and present the same frontend result.

Connecting Containers

Once you create the running and replicated application, you can put it on a network. Docker offers one way to create containers with host-private networking so containers are only communicating with containers on the same machine. If you want to take your app off the machine’s IP address, you need to coordinate the ports or dynamically allocate them. It is very hard to coordinate those ports as the app scales, so Kubernetes provides every pod with an IP address assigned explicitly to a cluster.

Containers within a pod will be able to reach the ports of other pods on localhost and see each other. This allows for reliable services that reach beyond the original machine with a simple networking model. Each set of pods will also get a single DNS name and Kubernetes is then able to load-balance with them.

The IP assigned to the resource is only good until the end of the life cycle for that resource or object. You will run into errors if there are duplicate IPs found on the same Network. And, it won’t change until the resource is gone and the object depleted or the IP is deleted explicitly. You can create static public IP addresses if you are running into issues with the ones that are defaulted by Kubernetes. Most of the time, people will outgrow this default and need a service to provide more agile IP addresses that can be seen on other networks.

EndpointSlices

Kubernetes will track network endpoints within every cluster. As the clusters and services grow, the API limits are more notable. There are challenges that come with scaling to more networks with more endpoints. This can increase network traffic and cause issues within Endpoints because of the large size of the resources. With EndpointSlices, the network endpoint references are stored as a smaller EndpointSlice that refers to the pods matching that Service selector. This groups network endpoints into one place by organizing the service and port combinations.

The EndpointSlices can act as the foundation for kube-proxy to reply on when coordinating internal traffic. Establishing EndpointSlices should help improve the performance of services, especially if you have a lot of endpoints. There are three address types that are supported by EndpointSlices:

• IPv4
• IPv6
• Fully Qualified Domain Name (FQDN)

To create EndpointSlices you will use an EndpointSlice controller that will make and manage the slices. Labels will be used to indicate which entity is managing a given EndpointSlice in order to avoid interference between multiple controllers managing your slices. Most of the time, the ownership of the EndpointSlice is going to go to the service that it logged endpoints for.

Storage

Temporary and long-term storage is needed to keep pods rotating correctly. Within a given cluster, various types of storage can be used.

Volumes: The volumes abstraction is used by Kubernetes to support reliable data sharing and availability. Within the container framework, access to data storage can lack flexibility and accessibility. Volumes help share data between containers until the termination of the pod. Coupled pods can share information easily without complicated external projects or components forcing the share. When containers fail, the pod does not suffer a data loss because the files have already been shared.

Persistent volumes: Are mechanisms that can be used if you want to create more robust storage that isn’t tied to the life cycle of the pod. The persistent volumes abstraction allows the app admin to determine storage resources that users can request and select for the pods they want to run. When the pod is finished, the volume’s policy determines how long the data is kept or when it is deleted. This provides a safeguard against failures stemming from nodes.

Volume snapshots: This kind of picture allows users and developers to see volume within a storage system. This examines a cluster to provide a picture of the resources and could work from specified attributes to show different aspects of the same value within the storage system.

CSI volume cloning: When certain groups of storage volumes need to be duplicated, you can create a clone of a persistent volume that is not currently in use. This is only available for CSI drivers and dynamic provisioners. It will only work within the same storage class and both volumes must use the same volume mode setting. It can specify an existing persistent volume to establish a new one.

Storage classes: This allows the developer to determine the kind of storage offered, including quality-of-service levels, app policies or backup settings. Kubernetes allows the creator to determine how the classes are set, establishing profiles that define how users are assigned storage class objects. Once these storage class resource objects are established, they cannot be updated. Volume plugins are used to set the persistent volumes for each storage class.

Dynamic volume provisioning: When volumes need to be created for storage, dynamic volume provisioning can be used to automate these processes by demand. Instead of requiring creators or administrators to make manual adjustments to their cloud or storage provider to establish new storage volumes and persistent volume objects, they can pre-set the storage scaling. This allows storage to be created as soon as it is requested by users. This allows the user to select from multiple storage classes without having to worry about the complexity of where storage is created.

Node-specific volume limits: There are sometimes limits placed by cloud providers on how many volumes can be attached to a nodes. Those settings have to be respected or nodes would end up stuck in limbo with conflicting commands and restrictions. Kubernetes will automatically default the volumes that are allowed per node, based on the specific requirements of the cloud provider. You can adjust these limits, but may run into issues with nodes that refuse to perform on certain platforms.a

Ingress

Your application will need a way to connect to the external services that publish your app to other IP addresses and networks. You will want an API (application programming interface) to manage that access. Normally you are connecting to the HTTP and Ingress is the kind of tool that will help manage that connection.

Traffic is sent through the Ingress resource, which will help with load balancing the traffic and provide services to the external URLs that the app can reach. It can terminate SSL/TLS and the Ingress controller will be responsible for fulfilling the loads and even configuring the edge router. It will not expose arbitrary ports or services aside from the HTTP and HTTPS that are within the controller specifications. There are different Ingress controllers that can be chosen to fit different reference specs and they all operate a little bit differently.