Introduction: Learning Objectives
In this section, you will be able to
- Define a Kubernetes object and its properties,
- Describe basic Kubernetes objects and their features, and
- Demonstrate how Kubernetes objects relate to each other.
- Describe the purposes, properties, and uses of a Service,
- Describe the roles and uses for the ClusterIP, NodePort, LoadBalancer, and External Name Services.
- And describe the roles and uses for Ingress, DaemonSet, StatefulSet, and a Job.
In the real world, an object is something that has an identity, a state, and a behavior. A window or a shopping cart are examples of objects.
A software object is a bundle of data that has an identity, a state, and a behavior. Examples include variables, data structures, and specific functions.
Another term is “entity,” which also has an identity and associated data. For example, in banking, a customer account is an entity.
Finally, the term “persistent” means something will last even if there is a server failure or network attack. An example is persistent storage.
- Kubernetes objects are persistent entities. Examples include: Pods, Namespaces, ReplicaSets, Deployments, and more.
- Kubernetes objects consist of two main fields – object spec and status.
- The object spec is provided by the user which dictates an object’s desired state.
- Status is provided by Kubernetes. This describes the current state of the object.
- Kubernetes works towards matching the current state to the desired state.
- To work with these objects, use the Kubernetes API directly with the client libraries, and the kubectl command-line interface, or both.
Labels are key/value pairs attached to objects. They are intended for identification of objects. However, a label does not uniquely identify a single object. Many objects can have the same labels. This helps to organize and group objects.
Label selectors are the core grouping method in Kubernetes. They allow you to identify a set of objects.
Namespaces provide a mechanism for isolating groups of resources within a single cluster. This is useful when teams share a cluster for cost-saving purposes or for maintaining multiple projects in isolation. Namespaces are ideal when the number of cluster users is large.
Examples of namespaces are kube-system, intended for system users and the default namespace used to hold users’ applications.
There are different patterns of working with namespaces. There may be only one namespace for a user who works with one team which only has one project that is deployed into a cluster.
Alternatively, there may be many teams or projects, or a lot of users with different needs, where additional namespaces may be created.
Namespaces provide a scope for the names of objects. Each object must have a unique name for that resource type within that namespace.
- A Pod is the simplest unit in Kubernetes.
- A Pod represents a process or a single instance of an application running in the cluster.
- A Pod usually wraps one or more containers.
- Creating replicas of a Pod serves to scale an application horizontally.
YAML files are often used to define the objects that you want to create. The YAML files shown defines a simple pod.
The “kind” field specifies the kind of object to be created. In this case, we create a Pod.
The “spec” field provides the appropriate fields for the object to be created, such as the containers that will run in this Pod.
A PodSpec must contain at least one container. In this example, the container is named “nginx”.
The image field dictates which image will run in the Pod. And the ports array lists the ports that the container exposes.
A ReplicaSet is a set of identical running replicas of a Pod that are horizontally scaled. The configuration files for a ReplicaSet and a Pod are different from each other.
The replicas field specifies the number of replicas that should be running at any given time. Whenever this field is updated, the ReplicaSet creates or deletes Pods to meet the desired number of replicas.
A Pod template is included in the ReplicaSet spec which defines the Pods that should be created by the ReplicaSet. Under the selector field, the labels supplied in the MatchLabels field specify the Pods that can be acquired by the ReplicaSet. Notice that the label identified in the MatchLabels field is the same as the labels field in the Pod template.
Both are the app: nginx. Creating ReplicaSets directly is not recommended.
Instead, create a Deployment, which is a higher-level concept that manages ReplicaSets and offers more features and better control.
A Deployment is a higher-level object that provides updates for both Pods and ReplicaSets.
Deployments run multiple replicas of an application using ReplicaSets and offer additional management capabilities on top of these ReplicaSets. Deployments are suitable for stateless applications.
For stateful applications, Stateful Sets are used.
Examples of Deployments include the deployment of a replicated application, Pod updates managed by a Deployment, or the scaling up of an application.
This Deployment specification example shows the kind is “Deployment,” which defines the number of replicas, a selector to identify which Pods can be acquired, and a Pod template.
One key feature provided by Deployments but not by ReplicaSets is rolling updates.
A rolling update scales up a new version to the appropriate number of replicas and scales down the old version to zero replicas.
The ReplicaSet ensures that the appropriate number of Pods exist, while the Deployment orchestrates the roll out of a new version.
A Service is a REST object, like Pods. Services are a logical abstraction for a set of Pods in a cluster. They provide policies for accessing the Pods and cluster. And act as a load balancer across the Pods.
Each Service is assigned a unique IP address for accessing applications deployed on Pods. And a Service eliminates the need for a separate service discovery process.
A Service supports multiple protocols such as TCP, which is the default protocol, UDP, and others, and supports multiple port definitions. The port number with the same name can vary in each backend Pod.
In addition, a Service can have an optional selector and can optionally map incoming ports to a targetPort.
Why is a Service needed?
A service is needed because Pods in a cluster can be destroyed, and new Pods can be created at any time. This volatility leads to discoverability issues because of changing IP addresses.
A Service keeps track of Pod changes and exposes a single IP address or a DNS name and utilizes selectors to target a set of Pods. For native Kubernetes applications, API endpoints are updated whenever changes are detected to the Pods in the Service.
For Non-native applications, Kubernetes uses a virtual-IP-based bridge or load balancer in between the applications and the backend Pods.
Types of Services
There are four types of Services:
- LoadBalancer, and
- External Name.
ClusterIP is the default and most common service type. Kubernetes assigns a cluster-internal IP address to the ClusterIP Service that makes the Service only reachable within the cluster.
A ClusterIP service cannot make requests to Service from outside the cluster. You can set the ClusterIP address in the Service definition file, and the ClusterIP Service provides Inter-service communication within the cluster.
For example, communication between the front-end and back-end components of your app.
An extension of ClusterIP Service, a NodePort Service creates and routes the incoming requests automatically to the ClusterIP Service.
A NodePort exposes the Service on each Node’s IP address at a static port. Note that for security purposes, production use is not recommended. Kubernetes exposes a single Service with no load-balancing requirements for multiple services.
External Load Balancer
An extension of the NodePort Service, an External Load Balancer, or ELB, creates NodePort and ClusterIP Services automatically. An ELB integrates and automatically directs traffic to the NodePort Service.
To expose a Service to the Internet, you need a new ELB with an IP address. You can use a cloud provider’s ELB to host your cluster.
External Name Service
The External Name Service type maps to a DNS name and not to any selector and requires a `spec.externalName` parameter.
The External Name Service maps the Service to the contents of the externalName field that returns a CNAME record and its value.
You can use an External name to create a Service that represents external storage and enable Pods from different namespaces to talk to each other.
Next, Ingress is an API object that, when combined with a controller, provides routing rules to manage external users’ access to multiple services in a Kubernetes cluster.
In production, Ingress exposes applications to the Internet via port 80 (for HTTP) or port 443 (for HTTPS)
While the cluster monitors Ingress, an external Load Balancer is expensive and is managed outside the cluster.
A DaemonSet is an object that makes sure that Nodes run a copy of a Pod. As nodes are added to a cluster, Pods are added to the nodes.
Pods are garbage collected when removed from a cluster. If you delete a DaemonSet, all Pods are removed.
DaemonSets are ideally used for storage, logs, and monitoring nodes.
A StatefulSet is an object that manages stateful applications, manages deployment and scaling of Pods, and provides guarantees about the ordering and uniqueness of Pods.
A StatefulSet maintains a sticky identity for each Pod request and provides persistent storage volumes for your workloads.
And lastly, a job creates Pods and tracks the Pod completion process. Jobs are retried until completed.
Deleting a job will remove the created Pods. Suspending a Job will delete its active Pods until the job resumes. A job can run several Pods in parallel.
And a CronJob is regularly used to create Jobs on an iterative schedule.
In this section, you learned that
- Kubernetes objects are persistent entities.
- Their main fields are “Object spec” and “Status,”
- Namespaces help in isolating groups of resources within a single cluster,
- Pods represent a process or an instance of an app running in the cluster,
- ReplicaSets create and manage horizontally-scaled running Pods,
- Deployments provide updates for Pods and ReplicaSets.
- A service in Kubernetes is a REST object that provides policies for accessing the pods and cluster.
- ClusterIP is the default and most common Service type and provides Inter-service communication within the cluster
- An extension of ClusterIP Service, a NodePort Service, creates and routes the incoming requests automatically to the ClusterIP Service.
- An extension of the NodePort Service, an External Load Balancer creates NodePort and ClusterIP Services automatically.
- And Ingress is an API object that, when combined with a controller, provides routing rules to manage external users’ access to multiple services in a Kubernetes cluster.
- You also learned using a DaemonSet ensures that there is at least one instance of the pod on all your the nodes.
- You can use an External name to create a Service that represents external storage and enables Pods from different namespaces to talk to each other.
- A StatefulSet manages stateful applications, manages Pod deployment and scaling, maintains a sticky identity for each Pod request, and provides persistent storage volumes for your workloads.
- And finally, a Job creates pods and tracks the pod completion process. Jobs are retried until completed.