This document explains kubectl, the Kubernetes command-line tool, its command structure, types of commands, and best practices for managing cluster resources.
This document introduces kubectl, the Kubernetes CLI, covering its command structure, the three main command types (imperative, imperative object configuration, declarative), their features, advantages, and practical usage for managing cluster resources and workloads.
Kubectl is the command-line interface (CLI) for Kubernetes. It enables users to deploy applications, inspect and manage cluster resources, view logs, and perform various administrative tasks. Kubectl is essential for interacting with Kubernetes clusters and managing workloads.
Kubectl commands follow a specific structure:
| Component | Description |
|---|---|
| command | Operation to perform (e.g., create, get, apply) |
| type | Resource type (e.g., pod, deployment, service) |
| name | Resource name (if applicable) |
| flags | Options or modifiers for the command |
Example:
1kubectl get pods --all-namespaces
There are three main types of kubectl commands:
| Command Type | Description | Best Use Case |
|---|---|---|
| Imperative | Directly creates, updates, or deletes live objects using command arguments and flags | Development, quick changes |
| Imperative Object Configuration | Uses a configuration file to create or update objects; requires specifying the file | Reusable templates, testing |
| Declarative Object Configuration | Applies configuration files to define desired state; kubectl determines necessary actions | Production, automation |
Imperative commands are easy to learn and use for direct operations. They do not provide an audit trail or support templates, making them less suitable for production. Example:
1kubectl run nginx --image=nginx
This approach uses configuration files (YAML or JSON) to define objects. It supports version control and templates, but requires specifying all operations. Example:
1kubectl create -f nginx.yaml
Declarative configuration defines the desired state in files. Kubectl automatically determines and performs the necessary operations to match the cluster state. This is ideal for production and automation. Example:
1kubectl apply -f ./configs/
| Command | Description |
|---|---|
| kubectl get | Lists resources (pods, services, deployments, etc.) |
| kubectl delete | Deletes resources |
| kubectl apply | Creates or updates resources from configuration files |
| kubectl autoscale | Applies autoscaling to resources |
| kubectl scale | Scales the number of replicas for a resource |
Examples:
1kubectl get pods --all-namespaces
2kubectl apply -f deployment.yaml
3kubectl scale --replicas=3 deployment/my-dep
To create a deployment with three replicas of the nginx image using declarative configuration:
1kubectl apply -f nginx-deployment.yaml
To check the deployment status:
1kubectl get deployment my-dep
The output confirms the creation of three replicas, all up-to-date and available.
| Command | Description |
|---|---|
| for …do | Runs a for command multiple times as specified. |
| kubectl apply | Applies a configuration to a resource. |
| kubectl config get-clusters | Displays clusters defined in the kubeconfig. |
| kubectl config get-contexts | Displays the current context. |
| kubectl create | Creates a resource. |
| kubectl delete | Deletes resources. |
| kubectl describe | Shows details of a resource or group of resources. |
| kubectl expose | Exposes a resource to the internet as a Kubernetes service. |
| kubectl get | Displays resources. |
| kubectl get pods | Lists all the Pods. |
| kubectl get pods -o wide | Lists all the Pods with details. |
| kubectl get deployments | Lists the deployments created. |
| kubectl get services | Lists the services created. |
| kubectl proxy | Creates a proxy server between a localhost and the Kubernetes API server. |
| kubectl run | Creates and runs a particular image in a pod. |
| kubectl version | Prints the client and server version information. |
Kubectl is the primary tool for managing Kubernetes clusters. Understanding its command structure and the differences between imperative, imperative object configuration, and declarative approaches is essential for effective cluster management and automation.
(3) Imperative commands act directly on live objects, while declarative commands use configuration files to define and achieve the desired state.
(3) Only declarative configuration automatically determines necessary operations; imperative object configuration requires explicit commands.
| Command Type | Characteristic |
|---|---|
| Imperative | Direct, no audit trail, quick changes |
| Imperative Object Configuration | Uses files, supports templates, version control |
| Declarative Object Configuration | Automation, audit trail, ideal for production |
Imperative-Direct, Imperative Object-Uses files, Declarative-Automation.
Declarative object configuration is ideal for production systems because it automates operations and maintains a single source of truth.
True. Declarative configuration enables automation and consistency, making it best for production.
(4) kubectl build is not a standard kubectl command.