Pods, Deployments, Helm, autoscaling, AKS, EKS, GKE: Master the fundamental concepts of Kubernetes and deploy to production. Complete guide by Smile.
According to the CNCF's 2025 annual survey, 82% of container-using organizations run Kubernetes in production, compared to 66% in 2023 — and 98% of respondents report having adopted cloud-native practices. In just a few years, Kubernetes has gone from being a Google project to a global standard for cloud-native infrastructure.
This Kubernetes guide explains the fundamental concepts, production deployment mechanisms, and architectural choices that make the difference between a stable cluster and an unmanageable one.
What is Kubernetes?
Kubernetes (or K8s for short) is the leading open-source containerization and orchestration platform, created by Google and donated to the Cloud Native Computing Foundation (CNCF) in 2014. It automates the deployment, scaling, high availability, and management of containerized applications in production.
Its role is to answer a simple question: how to operate dozens, hundreds or thousands of containers in production, reliably and automatically?
Kubernetes vs Docker: the essential distinction
Docker and Kubernetes are complementary, not competitors.
Docker packages an application and its dependencies into a portable and reproducible image, independent of the underlying operating systems.
Kubernetes orchestrates containers at scale. It decides where and how to deploy them, restarts them in case of failure, scales them according to the load, and manages their network and storage.
Docker Swarm is Docker's native orchestration solution, but Kubernetes has become the industry standard for large-scale production deployments. In short: Docker builds and runs a container. Kubernetes manages fleets of containers in production.
Kubernetes and DevOps
Kubernetes is the native infrastructure of modern DevOps . It enables continuous deployment at scale by integrating with CI/CD pipelines and automating rolling updates, rollbacks, and resource management. Without orchestration, deploying microservices at scale remains a manual and risky process.
The fundamental concepts of Kubernetes
Understanding Kubernetes begins with mastering its basic building blocks.
Kubernetes Pod: the atomic unit
A Kubernetes Pod is the smallest deployable unit in the platform. It contains one or more containers that share the same network and local storage. In practice, a Pod typically contains a single application container.
Pods are ephemeral by nature. Kubernetes automatically creates, destroys, and recreates them as needed. Pods are never managed directly in production.
Node and Cluster: the infrastructure
A Node is a physical or virtual machine that runs Pods. A Cluster is the set of Nodes managed by Kubernetes. Each cluster includes a Control Plane (which makes orchestration decisions) and Worker Nodes (which execute workloads).
Deployment: Lifecycle Management
A deployment is the Kubernetes resource that describes the desired state of an application: which Docker image to use, how many replicas to maintain, and which update strategy to apply. Kubernetes continuously manages to match the actual state to the described deployment.
If a Pod fails, the Deployment automatically recreates it. If the Deployment is modified, Kubernetes applies the update according to the defined strategy.
Service: exhibition and discovery
A service exposes a set of pods under a stable IP address and DNS name. Pods are ephemeral and change their IP address each time they are recreated. The service abstracts this instability and provides a stable access point for applications.
There are several types of Services depending on the need: ClusterIP (internal to the cluster), NodePort (exposure on each Node) and LoadBalancer (exposure via cloud load balancers).
Namespace: isolation and organization
A namespace is a virtual namespace that isolates Kubernetes resources within a single cluster. It allows you to separate environments (development, staging, production), teams, or applications within a shared cluster, with distinct security policies and resource quotas.
ConfigMap and Secret: configuration management
ConfigMaps store non-sensitive configurations (URLs, application settings) decoupled from the code. Secrets store sensitive data (passwords, tokens, certificates) with encryption at rest. These two resources allow you to externalize the configuration and modify it without rebuilding the Docker image.
Deploy to production with Kubernetes
Autoscaling: adapting resources to the load
Kubernetes offers two autoscaling mechanisms.
The Horizontal Pod Autoscaler ( HPA ) automatically increases or decreases the number of replicas in a deployment based on load metrics (CPU, memory, custom metrics). This is the most common mechanism for absorbing traffic spikes.
The VPA (Vertical Pod Autoscaler) optimizes the allocation of resources (CPU and memory) for each Pod based on its actual consumption. It is useful for optimizing costs without having to manually size each deployment.
Rolling updates and rollbacks
Rolling updates allow you to deploy a new version of an application gradually, Pod by Pod, without service interruption. If the new version has problems, a rollback with a single kubectl command allows you to instantly revert to the previous version.
This is one of the most valuable mechanisms of Kubernetes in production: it eliminates maintenance windows and drastically reduces the risk of each deployment.
Ingress: routing of external traffic
Ingress is the Kubernetes resource that manages the routing of incoming HTTP/HTTPS traffic to internal services. It allows you to define routing rules based on the domain name or URL path, centralize TLS termination, and implement authentication policies.
kubectl: the Kubernetes command line
kubectl is the command-line interface for interacting with a Kubernetes cluster. The `kubectl get` command lists resources (Pods, Services, Deployments). The `kubectl logs` command provides access to a Pod's logs in real time. It's an essential tool for any engineer who operates a Kubernetes cluster on a daily basis.
Helm: the Kubernetes package manager
Helm is the package manager for Kubernetes. It allows you to package, distribute, and deploy complex Kubernetes applications using "charts," which are sets of configurable YAML templates. Rather than manually maintaining dozens of YAML files, Helm allows you to deploy a complete application with a single command and manage its versions.
Managed vs. Self-Hosted Kubernetes
Managed services
The three major cloud providers offer fully managed Kubernetes clusters.
AKS (Azure Kubernetes Service) is Microsoft's solution, particularly well integrated into the Azure ecosystem (Active Directory, Azure Monitor, Azure Container Registry). It is the natural choice for organizations already using Microsoft Azure.
EKS (Elastic Kubernetes Service) is the AWS solution. Its deep integration within the AWS ecosystem (IAM, CloudWatch, ECR) makes it the preferred choice for AWS-first organizations.
GKE (Google Kubernetes Engine) is historically considered the most technically mature managed service, which makes sense since Google is the creator of Kubernetes. Its Autopilot mode completely automates node management.
Comparative table
Criteria AKSEKSGKE Cloud Integration Azure AWSGCPM Kubernetes Maturity Very Good Very Good Excellent Node Management Semi-Managed Semi-Managed Autopilot Available Sovereignty France Via Bleu Not Available Via S3NS Administration Complexity Low Medium Low Cost Comparable Comparable Slightly Lower
Self-hosted Kubernetes
Deploying and managing a Kubernetes cluster in-house (using kubeadm, k3s, or Rancher) offers complete control but imposes a significant operational burden. This is the choice of organizations with strict sovereignty requirements or those that do not want to depend on a cloud provider. It requires a team with in-depth Kubernetes expertise.
Complementary ecosystem and tools
Service Mesh: Istio and Linkerd
The service mesh manages communication between services within the cluster: mTLS encryption, circuit breaking, automatic retries, and traffic observability. Istio is the most comprehensive but also the most complex to operate. Linkerd is lighter and easier for startup teams to adopt.
Observability: Prometheus and Grafana
Prometheus collects and stores metrics from all cluster components and applications. Grafana visualizes these metrics in customizable dashboards. Together, they form the benchmark observability stack for the Kubernetes ecosystem, complemented by Jaeger or Tempo for distributed tracing.
GitOps: ArgoCD and Flux
ArgoCD and Flux implement GitOps on Kubernetes: the desired state of the cluster is described in Git, and an operator continuously synchronizes the actual state of the cluster with what is described in versioned YAML files or Helm charts. This is the de facto standard for configuration management in production.
Smile and Kubernetes: our cloud-native expertise
At Smile, we have been deploying and operating Kubernetes clusters in production since the platform's first stable versions. Our expertise covers the entire stack: cluster architecture design, deployment on AKS, EKS, or GKE, observability setup, GitOps implementation with ArgoCD, and securing production clusters.
Our approach is pragmatic. We help our clients choose between managed and self-hosted Kubernetes based on their actual constraints in terms of sovereignty, cost, and operational maturity. We also train DevOps teams and engineers new to Kubernetes, with courses tailored to all levels, from junior DevOps engineers to senior cloud architects.
Looking to deploy Kubernetes in production? Discover our expertise in Kubernetes orchestration .
Frequently Asked Questions about Kubernetes
Is it mandatory to use Docker with Kubernetes?
No. Kubernetes supports several container runtimes via the Container Runtime Interface (CRI): containerd, CRI-O, and Docker (via dockershim, now deprecated). In practice, containerd is the most widely used runtime in modern Kubernetes clusters. Docker remains the standard tool for building container images locally, but it is no longer required in production on Kubernetes nodes.
What is the difference between a Deployment and a StatefulSet?
A Deployment manages stateless applications where each replica is identical and interchangeable. A StatefulSet manages stateful applications (databases, distributed file systems) where each Pod has a stable identity, its own persistent storage, and a defined start and stop order. A Deployment is used for a REST API, while a StatefulSet is used for PostgreSQL or Elasticsearch.
How to secure a Kubernetes cluster in production?
Five fundamental practices: enable RBAC (Role-Based Access Control) to limit the permissions of each component, use Network Policies to control traffic between Pods, scan container images before deployment, enable encryption of Secrets at rest in etcd, and implement Pod Security Admission to prevent containers from running with excessive privileges.
When is Kubernetes not the right solution?
Kubernetes introduces significant operational complexity. For a small team with few services, a low-traffic application, or an early-stage startup, simpler alternatives (Docker Compose, AWS Fargate, Fly.io, Railway) offer a better value-to-complexity ratio. Kubernetes becomes relevant when the need for scalability, high availability, and the deployment of numerous microservices justifies the investment in learning and operating it.