Creating Objects in Kubernetes

In Kubernetes (K8s), everything is an “Object.” Think of an object as a persistent record of your intent. When you create an object, you are effectively telling the Kubernetes system, “Here is what I want my application to look like.” This is called the Desired State.

Once you create this record, Kubernetes works non-stop to ensure the Live State/Actual State (what is actually happening in the cluster) matches your Desired State. You can create these objects in two main ways: by giving direct orders (Imperative) or by providing a written blueprint (Declarative).

Imagine you are ordering a Masala Dosa at a busy Bangalore restaurant.

• Imperative Approach (Direct Orders): You stand in the kitchen and tell the chef step-by-step: “Pour the batter, spread it, add oil, put the potato masala, fold it, and serve it.” You are managing the process manually. If you leave, the process stops.
• Declarative Approach (The Menu): You simply tick “Masala Dosa” on an order slip and hand it to the waiter. You don’t care how they make it, just that you get it. If the dosa burns, the chef knows to make another one automatically because the order slip (your desired state) still says “One Masala Dosa.”

1. Imperative: You give commands step-by-step (like typing in a terminal).
2. Declarative: You write down the final result in a file (YAML) and give it to Kubernetes.

you must understand the evolution of control.

Level 1: The CLI User

You start with command this is great for a quick check, but bad for history. If you delete the pod, how do you remember exactly how you ran it?

kubectl run nginx --image=nginx

We can generate Kubernetes yaml file using CLI command.

kubectl create deployment nginx-deployment --image=nginx --dry-run=client -o yaml > deployment.yaml

Level 2: The Manifest Writer

You move to writing YAML files. This is “Infrastructure as Code.” You can save these files in GitHub. This is the industry standard.

Every Kubernetes Object you create via YAML MUST have these 4 root fields. Memorize this as “Type-Meta-Spec”:

1. apiVersion: Which version of the K8s logic are we using? (e.g., v1 for Pods, apps/v1 for Deployments).
2. kind: What are we creating? (e.g., Pod, Service, ConfigMap).
3. metadata: Identity details.
   • name: Unique string to identify the object.
   • labels: Key-value tags (e.g., app: my-website) to organize resources.
   • namespace: The virtual cluster where this object lives.
4. spec: The “Specification.” This is the most important part it describes the desired state (e.g., which container image, how many replicas, which ports to open).

Level 3 (The Architect): You use tools that “generate” or “manage” these objects for you, like Helm (Package Manager) or Operators (Custom Controllers).

At the architect level, creating an object isn’t just about “running it” it’s about governance, security, and automation.

• Validation & Mutating Webhooks: Before an object is created, it goes through “Admission Controllers.”
  • Tool: Kyverno or OPA Gatekeeper.
  • Use Case: Automatically reject any object creation request that uses the “latest” image tag or tries to run as “root” user.
• GitOps Workflow: You never run kubectl apply manually. You push code to Git, and an agent pulls the changes.
  • Tool: ArgoCD or Flux.
  • Why: It creates a perfect audit trail. “Who created this object?” -> “Check the Git commit history.”
• Custom Resource Definitions (CRDs): Extending Kubernetes to create your own object types (e.g., creating a Database object instead of just a Pod).
  • When you install tools like Prometheus or Istio, they add their own API groups (e.g., monitoring.coreos.com/v1).

Flow Kubernetes follow to create object

1. User: Writes the YAML.
2. Kubectl: Converts YAML to JSON and sends it to the API.
3. API Server: Authenticates (Who are you?), Authorizes (Can you do this?), and Validates the request.
4. Etcd: Stores the valid object (Persistence).
5. Controllers/Schedulers: Notice the new object in Etcd and wake up to do the actual work (like starting a container).

Benefits

• Portability: The same YAML object definition works on your laptop (Minikube), AWS (EKS), or Google Cloud (GKE).
• Version Control: Since objects are code (YAML), you can revert changes if something breaks.

• Working with Kubernetes Objects (Start Here)
• Kubernetes API Reference (Deep Dive)
• Managing Resources (Best Practices)

Understanding Kubernetes Manifests Yaml file

A Kubernetes Manifest is essentially a “Contract” or a “Form” that you fill out to request resources from the cluster. Written in YAML (Yet Another Markup Language), it is human-readable and works on a key-value pair system.

To create anything in Kubernetes, you must provide four specific pieces of information. Think of it like sending a package: you need to know the Postal Service rules (apiVersion), the Type of Package (kind), the Address label (metadata), and finally, the Content inside (spec). Without these four, Kubernetes simply doesn’t know what to do with your request.

GKV (Group, Version, Kind) is the fundamental definition of any resource in the Kubernetes API. It provides a structured way to categorize and version the API so it can evolve without breaking backward compatibility.

apiVersion (The Language Version)

It establishes the “Rules of Engagement.” It tells the Kubernetes API server exactly which version of the logic you want to use to create your object. and Which version of the schema you are using. Kubernetes APIs are grouped.

• Core Group (v1): These are the oldest, most stable parts of K8s (e.g., Pods, Services, Nodes). They don’t need a group name prefix.
• Named Groups (apps/v1, batch/v1): As K8s grew, features were organized into named groups.
  • apps/v1: For workloads that run applications (Deployments, DaemonSets).
  • batch/v1: For temporary jobs (Jobs, CronJobs).
  • rbac.authorization.k8s.io/v1: For permission rules.

Stability Levels:

• Alpha (e.g., v1alpha1): Experimental, buggy, likely to change.
• Beta (e.g., v1beta1): Well-tested, but minor details might change.
• Stable (e.g., v1): Rock-solid, will be supported for years.

Why is it required? Because K8s evolves. A Deployment in version extensions/v1beta1 might have different fields than in apps/v1. You must declare the version so K8s knows how to read your file.

Finding the right version which apiVersion to use for a specific object, run this command in your terminal:

kubectl api-resources

This prints a list of every resource supported by your cluster and its correct APIGROUP and VERSION.

–

2. kind (The Object Type)

This specifies the REST resource you want to create. It maps directly to a “Category” in the database.

• Logic: When you define kind: Pod, Kubernetes knows to look up the “Pod” schema definition to validate your fields.
• Constraint: You cannot invent a Kind unless you install a “Custom Resource Definition” (CRD) first.

Why is it required? Without kind, Kubernetes is like a chef holding ingredients but not knowing if you want a Soup, a Salad, or a Curry.

3. metadata (The Identity)

This section contains information about the object, not the object’s behavior itself. It helps K8s identify and group the resource.

• name: Unique ID within a namespace. (Required)
• namespace: The virtual cluster it belongs to. (Default is default).
• labels: Key-value tags (e.g., env: prod, app: frontend) used for selecting and grouping objects.
• annotations: Key-value notes (e.g., developer: ramesh, last-updated: 2024-02-11) used by external tools, not by K8s itself.

Why is it required? Every object in the K8s database (etcd) needs a unique key. That key is generated from namespace + kind + name.

4. spec (The Desired State)

This is the heart of the file. It describes the Desired State you want the cluster to maintain.

• The structure of spec changes entirely depending on the kind.
  • For a Pod, spec asks for containers and images.
  • For a Service, spec asks for ports and selectors.
  • For a CronJob, spec asks for schedule.

Why is it required? This is your actual order. Without spec, you have created an empty shell with a name but no purpose.