GitHub link - https://github.com/SUBHAM-NANDI/40DaysKubernetes/tree/main/Day%207
1. Imperative vs. Declarative Kubernetes Management
In Kubernetes, you can manage resources using two primary methods: imperative and declarative.
-
Imperative Approach: You directly issue commands to Kubernetes to perform actions. This is similar to running commands like
kubectl run
orkubectl create
. You tell Kubernetes what to do, and it performs the action immediately. However, the changes made with this method are not easily repeatable since there's no persistent configuration.Example:
kubectl run nginx --image=nginx
-
Declarative Approach: In contrast, the declarative method uses YAML (or JSON) files to declare the desired state of the system. You define what resources should look like in configuration files, and Kubernetes takes care of creating or updating the resources to match the desired state. This approach is preferred for production environments because it's more scalable and maintainable.
Example YAML (Declarative):
apiVersion: v1 kind: Pod metadata: name: nginx-pod labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80
Then you would apply this YAML configuration with:
kubectl apply -f nginx-pod.yaml
2. Imperative Commands in Kubernetes
With the imperative method, you directly issue commands to Kubernetes. These are some key commands:
-
Run a Pod:
Thekubectl run
command allows you to create a pod on the fly.
kubectl run nginx --image=nginx
This creates a pod named
nginx
using thenginx
image from Docker Hub. -
Get Pods:
Check the state of pods by running:
kubectl get pods
This will return a list of all running pods in the cluster.
-
Delete a Pod:
To delete thenginx
pod:
kubectl delete pod nginx
-
Describe Pod:
If there’s an issue with the pod, you can describe it to get more information:
kubectl describe pod nginx
-
Exec into a Pod:
To interact with a pod, such as debugging an issue, you canexec
into the running container:
kubectl exec -it nginx -- /bin/bash
This opens a bash shell inside the container.
3. Declarative Management via YAML
YAML is the primary configuration format for defining Kubernetes resources. Here are the components of a typical YAML manifest:
apiVersion: Defines the version of the Kubernetes API used (e.g.,
v1
,apps/v1
).kind: Specifies the type of resource you're creating, such as
Pod
,Deployment
,Service
, etc.metadata: Provides metadata for the resource, like
name
,labels
, and annotations.spec: Describes the desired state of the resource. For a pod, this includes the list of containers, images, ports, volumes, and other configurations.
Example YAML for a deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
This YAML file creates a deployment with 3 replicas of an NGINX pod. Kubernetes ensures that 3 instances of the pod are always running.
Key elements to note:
- replicas: This specifies how many instances of the pod you want.
-
selector: It selects the pods that the deployment will manage based on the
app: nginx
label. -
template: This defines the pod's structure, including its
metadata
,spec
, and containers.
4. Debugging Pods and Troubleshooting
Debugging a pod involves checking its state and logs or even running commands inside the container. Here’s a detailed approach:
Checking Pod Status:
Usekubectl get pods
to see the current status of pods. You might see statuses likeRunning
,Pending
,CrashLoopBackOff
, etc.-
Pod Logs:
If a pod is inCrashLoopBackOff
orError
state, you can view its logs:
kubectl logs pod-name
-
Describing Pod:
Get a detailed description of the pod, including its events, errors, and lifecycle:
kubectl describe pod pod-name
-
Error Example - Image Pull:
If there’s an issue with pulling an image, the event will report:
Failed to pull image "nginx123": rpc error: code = Unknown desc = Error response from daemon: manifest for nginx123 not found
This indicates that the image name is incorrect.
5. Dry-run and Auto-generating YAMLs
When you’re using imperative commands, you can generate the corresponding YAML files with the --dry-run=client
and -o yaml
options:
kubectl run nginx --image=nginx --dry-run=client -o yaml
This outputs the YAML for the pod creation command, which you can save to a file:
kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
This method allows you to convert an imperative command into a reusable YAML file that can be version-controlled or used in CI/CD pipelines.
Top comments (0)