Kubernetes objects are persistent entities in the Kubernetes system that represent the desired state of the cluster, such as which containerized applications are running, the resources they use, and the policies governing their behavior. These objects serve as building blocks for orchestrating applications and services.
A Kubernetes object is a “record of intent” — once you create the object, the Kubernetes system will constantly work to ensure that the object exists. By creating an object, you’re effectively telling the Kubernetes system what you want your cluster’s workload to look like; this is your cluster’s desired state.
To work with Kubernetes objects — whether to create, modify, or delete them — you’ll need to use the Kubernetes API. When you use the kubectl command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the Client Libraries.
There are mainly two types of objects in Kubernetes — Basic objects and High-level objects.
Basic Objects are the foundational elements that define core resources and configurations in a cluster. Basic Objects such as pod and namespace that can be deployed and managed independently.
High-level object: A high-level Kubernetes object refers to the more abstract, user-friendly resources that Kubernetes offers for managing containers, workloads, and services in a cluster. These objects allow users to define the desired state of their applications and infrastructure declaratively. Example — deployment, daemonset and statefulsets etc.
Kubernetes objects include:
- Pods: —
The smallest and simplest unit in Kubernetes. A pod is a group of one or more containers that share the same network and storage, and are executed together.
A Pod’s contents are always co-located and co-scheduled, and run in a shared context. A Pod models an application-specific “logical host”: it contains one or more application containers which are relatively tightly coupled. In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.
- Namespace :—
It provide a mechanism to isolate a set of resources/objects within a single cluster. For example, if we have 2 teams QA team and Dev team working on the same cluster then namespace can be used to isolate the objects belong to each team.
In Kubernetes, namespaces provide a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects (e.g. Deployments, Services, etc.) and not for cluster-wide objects (e.g. StorageClass, Nodes, PersistentVolumes, etc.).
- Deployments: —
A high-level abstraction for managing stateless applications. It helps automate the process of rolling updates and scaling pods.
It is a high-level object to manage pods. When we create a new deployment, it basically creates a replicaset and then replicaset creates given instances of pod. in fact, deployment is the recommended way to deploy a pod because of its advanced, built-in functions.
- Services: —
Defines how to expose a set of pods as a network service. It enables communication between different pods or between external clients and the application running inside the cluster.
- ConfigMaps: —
Stores configuration data that can be injected into containers, allowing applications to be configured without changing the container image.
A ConfigMap is an API object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume.
A ConfigMap allows you to decouple environment-specific configuration from your container images, so that your applications are easily portable.
- Secrets: —
Similar to ConfigMaps, but intended to store sensitive information like passwords, tokens, or keys.
A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in a container image. Using a Secret means that you don’t need to include confidential data in your application code.
- PersistentVolume (PV) and PersistentVolumeClaim (PVC): —
These are used to handle storage in Kubernetes. A PV is a piece of storage, and a PVC is a request for that storage by a pod.
- StatefulSets: —
A StatefulSet runs a group of Pods, and maintains a sticky identity for each of those Pods. This is useful for managing applications that need persistent storage or a stable, unique network identity.
It is Manages stateful applications that require persistent storage and stable networking. It is used for databases or other stateful services.
StatefulSet is the workload API object used to manage stateful applications.
- Ingress: —
Manages external access to services, typically using HTTP or HTTPS routes, allowing more complex routing and traffic management.
The Ingress concept lets you map traffic to different backends based on rules you define via the Kubernetes API.