Kubernetes Fundamentals for Cloud Professionals: Pods, Services, Deployments, and Clusters

 

Kubernetes is a platform for running containerized workloads across a cluster of machines. It is powerful because it manages desired state: you declare how an application should run, and controllers continuously work to keep reality aligned with that declaration.

For cloud professionals, the most useful starting point is not a long command list. It is a mental model of the main objects, the control loop, and how traffic and state move through the system.

A cluster is the environment Kubernetes manages

A Kubernetes cluster contains a control plane and worker nodes.

The control plane stores desired state, exposes the API, schedules work, and runs controllers. Worker nodes provide compute capacity and run application workloads.

In managed Kubernetes services, the cloud provider operates much of the control plane. The customer still owns application configuration and often significant parts of node, network, identity, and security design.

The Kubernetes control model is easier to learn provider-neutrally first, then map onto a managed service. Kubernetes on AWS provides a concrete AWS context for clusters, workloads, networking, and operations after pods, services, and deployments are understood.

The API is the center of the system

Kubernetes is API-driven. Users and automation submit resource definitions to the API server.

Controllers watch those resources and try to make the cluster match the declared state.

This design means you normally describe what should exist rather than issuing a step-by-step instruction for every operation.

Pods are the basic workload unit

A pod is the smallest schedulable unit in Kubernetes.

A pod usually contains one application container, but it can contain multiple tightly coupled containers that share networking and storage context.

Containers inside a pod can communicate over localhost. The pod receives its own network identity inside the cluster.

Pods should generally be treated as replaceable. If a pod fails, Kubernetes often creates another rather than repairing the old instance in place.

Containers and pods are not the same thing

A container is a runtime unit. A pod is a Kubernetes object that provides scheduling and shared context for one or more containers.

This distinction matters in troubleshooting. The container can be healthy while the pod fails readiness. The pod can exist while the node underneath it is unhealthy.

A cluster still runs on lower-level compute, networking, storage, and identity. virtual machines and cloud infrastructure helps explain the infrastructure layer beneath container orchestration so learners do not mistake Kubernetes for the entire platform.

Deployments manage replicated applications

You usually do not create application pods directly.

A Deployment describes a desired set of replicas and manages ReplicaSets that keep the requested number of pods running.

If a pod disappears, the controller creates a replacement. If you change the image version, the Deployment can perform a rolling update.

This is desired-state management in practice: the system continuously compares requested state with observed state.

Replica count is not the same as availability

Running three replicas improves resilience only if they are distributed sensibly and can all serve traffic.

If every pod lands on one node, a node failure can still remove the entire service. If every pod depends on one unavailable database, more replicas do not help.

Production designs consider topology, failure domains, dependencies, readiness, disruption policies, and capacity.

Services provide stable network access

Pods are ephemeral, so clients should not depend on individual pod addresses.

A Service selects a group of pods and provides a stable way to reach them. Kubernetes networking and the cluster’s data plane route traffic to eligible endpoints.

Different Service types expose applications at different scopes, from cluster-internal access to external load balancing.

Labels and selectors connect objects

Labels are key-value metadata attached to resources. Selectors use labels to identify sets of resources.

A Deployment can label its pods as belonging to an application. A Service can select pods with those labels.

This loose coupling is powerful but creates a common troubleshooting case: the pods are running, but a Service has no endpoints because its selector does not match their labels.

Readiness and liveness answer different questions

A readiness probe asks whether a container should receive traffic.

A liveness probe asks whether the container should be restarted because it is no longer making progress.

Conflating the two can create outages. An application may need time to warm up before receiving traffic but should not be restarted repeatedly during that warm-up.

Startup probes can help protect slow-starting applications from premature liveness failure.

Requests and limits influence scheduling

Resource requests tell Kubernetes how much CPU or memory a container needs for scheduling. Limits constrain how much it may use.

Requests help the scheduler decide which node has enough capacity. Poor requests can lead to inefficient packing or unexpected contention.

Memory and CPU behave differently when limits are exceeded, so teams should understand the runtime effect rather than copying arbitrary values.

Nodes are capacity, not application identity

In a healthy Kubernetes mindset, applications belong to the cluster, not to named servers.

Nodes can be replaced, upgraded, drained, or autoscaled. The scheduler can place replacement pods elsewhere.

This is a major shift for administrators accustomed to logging into one server to “fix the app.”

Scheduling considers constraints

Kubernetes can place workloads based on available resources, labels, affinity rules, taints, topology, and other constraints.

Scheduling policy should express real requirements. Over-constraining placement can leave pods pending even when the cluster has free capacity.

The right question is why the workload needs a particular placement, not how many scheduling features can be configured.

Namespaces create logical boundaries

Namespaces organize resources inside a cluster and can support access control, quotas, policy, and naming separation.

They are useful for teams, applications, and environments, but they are not automatically a hard security boundary. Strong multi-tenancy may require additional controls or separate clusters.

ConfigMaps and Secrets externalize configuration

Applications should not require a new image for every environment-specific setting.

ConfigMaps store non-sensitive configuration. Secrets store sensitive values, though teams still need proper encryption, access control, rotation, and external secret-management strategy.

The key principle is separation: application artifacts should not contain every deployment-specific value.

Persistent volumes separate data from pod lifecycle

A pod can disappear at any time. Persistent application data should live in storage whose lifecycle is independent of that pod.

PersistentVolume and PersistentVolumeClaim concepts let workloads request and consume storage through Kubernetes abstractions.

Cloud providers often integrate these abstractions with managed block, file, or other storage services.

Persistent applications force teams to think beyond container images because data durability and lifecycle are separate concerns. Azure storage and containers provides an Azure-oriented context for keeping application packaging distinct from storage architecture.

Ingress and gateways manage application entry

A Service can expose an application, but real environments often need routing by hostname or path, TLS termination, policy, and shared entry points.

Ingress resources and newer gateway patterns provide ways to express that routing while an implementation controller performs the actual data-plane work.

Do not assume the Kubernetes object itself moves packets. Controllers and underlying load balancers implement the behavior.

Deployments support controlled rollout

When a Deployment changes, Kubernetes can create new pods while removing old ones gradually.

Readiness is critical during this process. A new pod should not receive traffic until it can serve correctly.

Rollouts should also have monitoring and rollback criteria. A technically successful deployment can still introduce latency, errors, or business regressions.

Horizontal scaling adds replicas

Kubernetes can adjust replica counts automatically based on observed metrics.

Horizontal pod autoscaling is useful when more replicas increase service capacity. It is less useful when the true bottleneck is a shared database, external API, or saturated node pool.

Scaling pods may also require scaling cluster nodes so there is somewhere to schedule them.

Cluster autoscaling solves a different layer

If pods are pending because the cluster lacks capacity, node autoscaling can add worker nodes.

This creates a layered control system: workload autoscaling changes pod demand, and cluster autoscaling changes infrastructure supply.

Cloud engineers need to understand both layers to diagnose why an application failed to scale.

Observability starts with events and status

Kubernetes exposes object status, events, logs, and metrics that explain what controllers are doing.

When a workload fails, ask which layer owns the symptom. Is the pod pending? Did the container crash? Did readiness fail? Does the Service have endpoints? Is the node under pressure? Did an image pull fail?

Avoid changing random settings before reading the evidence.

Security spans image, workload, identity, and cluster

Kubernetes security includes container images, runtime privileges, service accounts, role-based access control, network policy, secrets, admission policy, node security, and the cloud permissions used by the cluster.

No single control makes a cluster secure.

Container platforms create security work at several layers: image supply chain, workload identity, secrets, network policy, runtime behavior, and cloud permissions. AWS cloud security careers shows how those responsibilities connect to broader cloud-security roles.

RBAC controls API permissions

Role-based access control determines which subjects can perform which actions on Kubernetes API resources.

Follow least privilege. A developer who needs to deploy one application does not automatically need cluster-admin permissions.

Human access and workload identity should be designed separately.

Network policy can restrict pod communication

Without suitable policy, cluster networking may permit more east-west communication than the application requires.

Network policies let teams express which pods may communicate. Their enforcement depends on the networking implementation.

Policy should be tested because a rule that exists but is not enforced provides false confidence.

Managed Kubernetes changes responsibility, not fundamentals

AWS, Azure, and Google Cloud all offer managed Kubernetes services.

The provider may manage the control plane, upgrades, integrations, or node options, but the core Kubernetes objects remain familiar.

Managed Kubernetes services can look similar while differing in identity integration, networking, node management, add-ons, and surrounding cloud services. AWS, Azure, and Google Cloud comparison helps frame those provider differences before a team compares specific offerings.

Do not use Kubernetes just because containers are involved

A small application may need only a managed container service or platform-as-a-service environment.

Kubernetes becomes valuable when teams need sophisticated scheduling, portability of orchestration patterns, extensibility, policy, or control across many workloads.

It also introduces a substantial operational surface.

Kubernetes and configuration automation often work together but solve different problems. Ansible and Kubernetes helps separate cluster orchestration from the broader task of configuring systems and enforcing desired state.

A practical learning sequence

Start with containers and images. Run a simple pod. Replace it with a Deployment. Expose it through a Service. Break labels and observe the result. Add readiness. Update the image and watch the rollout. Add persistent storage. Then explore scheduling, autoscaling, RBAC, and network policy.

Build failure into the labs. A cluster that only demonstrates successful deployment teaches less than one where you intentionally misconfigure selectors, images, resources, permissions, and health checks.

Certification relevance comes from mechanisms

Certification exams may use provider-specific managed services, but the durable value is understanding the mechanisms underneath them.

Know why pods are replaceable, why Services exist, what Deployments control, why scheduling fails, and how cluster capacity relates to application replicas.

Operating cloud-native platforms requires more than knowing Kubernetes objects; teams also need delivery, observability, automation, reliability, and incident skills. Google Cloud DevOps role places those responsibilities inside a broader DevOps career path.

What Kubernetes fundamentals should leave you able to explain

After learning the foundations, you should be able to explain the path from a deployment definition to running pods, how a Service finds endpoints, why a pod becomes unschedulable, how readiness affects traffic, how replicas improve resilience, and where persistent state lives.

That mental model is more useful than memorizing dozens of commands. Commands change. The control loop and resource relationships are the skills that transfer.