Continued from the previous blog, we see Kubernetes more in technical terms. We see each components of Kubernetes, in considerable how they set in the bigger picture of things.
As mentioned above, pods won’t be rescheduled if the node it runs on goes down. Replica sets overcome this issue in Kube by ensuring that a specified number of pod instances (or replica sets) are running together at any given time. Therefore, to keep your pod alive, make sure that there is at least one replica set assigned to it. As well as managing single pods, replica sets can manage—and scale to major numbers—groups of pods categorized by a common label. As much of this is automated within deployment, you will never need to actively manage this scaling capability, but it’s worth understanding how the system functions to better manage your applications.
Within Kube, networking is all about connecting the network endpoints (pods). Containers in different pods must communicate via an alternative method to IPC due to their distinct IP addresses. Kubernetes networking solves this cross-node pod-to-pod connectivity as well as achieving service discovery and pod-to-pod load balancing. Pods are secured by limiting access through network segmentation. Network policies define how subsets of pods are allowed to interact with each other and other network endpoints. Configuration is on a per-namespace basis.
A Kubernetes service is an abstraction which outlines a logical subset of pods according to labels (see above). Kube’s services identify and leverage the label selectors for groups of pods in accordance with the service they are assigned. Such management ease of endpoints through services is all down to the labels. As well as service discovery capabilities, this abstraction of services further provides internal load balancing for pods within a cluster. Kubernetes provides two primary methods of finding a service. As a pod is run on a node, the kubelet (node agent) adds environment variables for each active service according to predefined conventions. The other method is to use the built-in DNS service (a cluster add-in). The DNS server monitors the Kubernetes API for all new services and assigns a set of DNS records for each. When DNS is enabled throughout the cluster, then all pods should be able to do a name resolution of services automatically.
Urolime is one of the leading DevOps consulting company with a handful of experience in supporting customers around the globe in adopting DevOps practices. As an AWS and Cloud consulting partner, Urolime not only has experience in Cloud Migrations but also support the vast customer base to enable scalable and highly available architecture on AWS, Azure, and GCP. The customers benefit from our expert involvement in Deployment Automation (CI/CD), Infrastructure Automation, Dockerization, Security, Disaster Recovery Planning & Implementation and 24/7 Managed Services with 10 Minutes SLA. Urolime is one of the companies which deals with a bunch of Kubernetes solution build for the customer on AWS, Azure, and GCP.