[kubernetes learnings notes] #k8s learnings notes https://kubernetes.io/docs/reference/kubectl/quick-reference/

deployment-apply-vs-rollout.md

A new Deployment will take effect when it's applied.

kubectl apply -f deployment.yaml
kubectl get deployment myapp-deployment # to verify the deployment

The kubectl apply command and the kubectl rollout command serve different purposes in managing deployments in Kubernetes.

kubectl apply

• Primary Use: The kubectl apply command is used to create or update resources in a Kubernetes cluster. It takes a configuration file (usually in YAML format) and applies it to the cluster. This is the command you use to initially create objects like Deployments, Services, ConfigMaps, etc., or to apply changes to them.
• Configuration Changes: When you have a new configuration for your Deployment (like updating the version of the container image), you use kubectl apply with the updated YAML file to make changes to the Deployment.
• Declarative Approach: kubectl apply is part of the declarative approach to managing Kubernetes resources, where you declare the desired state of the resource in a file and let Kubernetes make the necessary changes to achieve that state.

kubectl rollout

• Primary Use: The kubectl rollout command is used to manage the deployment process of a Deployment, DaemonSet, StatefulSet, or ReplicaSet after it has been created or updated. It allows you to see the status of the rollout, pause, resume, or undo changes (roll back to a previous version).
• Monitoring and Managing Rollouts: After you use kubectl apply to update a Deployment, you can use kubectl rollout status to watch the status of the update. This command shows you if the rollout is successful, stuck, or failed.
• Rollback: If you find issues with the latest version of your application after applying changes, you can use kubectl rollout undo to revert to a previous version of the Deployment. This is critical for quick recovery in production environments.
• Fine-Tuned Control: kubectl rollout provides more granular control over the deployment process, like pausing and resuming rollouts, which is not achievable with kubectl apply.

kubectl rollout cannot be used to initiate a new deployment. Its purpose is to manage and control the rollout process of an existing deployment, such as updating, pausing, resuming, or rolling back an in-flight deployment. A typical deployment flow will be like:

kubectl apply -f deployment.yaml

kubectl rollout status deployment/myapp-deployment # view status
kubectl rollout pause deployment/myapp-deployment # pause
kubectl rollout resume deployment/myapp-deployment # resume
kubectl rollout undo deployment/myapp-deployment # rollback

frequently-used-k8s-commands.sh

# Kubernetes Frequently Used Commands Reference

# --- Cluster Information ---
# Get cluster info
kubectl cluster-info

# View nodes
kubectl get nodes

# --- Working with Namespaces ---
# List namespaces
kubectl get namespaces

# Create a namespace
kubectl create namespace [namespace-name]

# Delete a namespace
kubectl delete namespace [namespace-name]

# --- Managing Pods ---
# List pods
kubectl get pods

# List pods in a namespace
kubectl get pods --namespace [namespace-name]

# Create a pod from a YAML file
kubectl apply -f [file.yaml]

# Delete a pod
kubectl delete pod [pod-name]

# --- Deployments ---
# List deployments
kubectl get deployments

# Create a deployment
kubectl create deployment [deployment-name] --image=[image-name]

# Delete a deployment
kubectl delete deployment [deployment-name]

# Scale a deployment
kubectl scale deployment [deployment-name] --replicas=[number]

# --- Services ---
# List services
kubectl get services

# Create a service
kubectl expose deployment [deployment-name] --type=[type] --port=[port]

# Delete a service
kubectl delete service [service-name]

# --- ConfigMaps and Secrets ---
# List ConfigMaps
kubectl get configmaps

# Create a ConfigMap from a file
kubectl create configmap [configmap-name] --from-file=[path-to-file]

# List Secrets
kubectl get secrets

# Create a secret
kubectl create secret generic [secret-name] --from-literal=key1=value1

# --- Viewing and Managing Resource Usage ---
# Check node resource usage
kubectl top node

# Check pod resource usage
kubectl top pod

# --- Logs and Debugging ---
# View logs of a pod
kubectl logs [pod-name]

# Execute a command in a container
kubectl exec -it [pod-name] -- [command]

# Attach to a running container
kubectl attach [pod-name] -i

# Port forwarding to a local machine
kubectl port-forward [pod-name] [local-port]:[pod-port]

# --- Advanced Commands ---
# Apply a configuration
kubectl apply -f [file.yaml]

# Get detailed info about a resource
kubectl describe [resource-type] [resource-name]

# Roll out a new update
kubectl rollout restart deployment/[deployment-name]

# Viewing rollout history
kubectl rollout history deployment/[deployment-name]

# --- Cleanup and Deletion ---
# Delete resources from a file
kubectl delete -f [file.yaml]

# Force delete a pod
kubectl delete pod [pod-name] --grace-period=0 --force

k8s-learnings.sh

kubectl get nodes
kubectl describe node control-plane | more
kubectl run nginx --image=nginx; watch kubectl get pods -o wide
kubectl delete pod/alpine

# -v is to revert the match, ie exclusion
nerdctl -n k8s.io ps -a | grep -v pause

kubectl run nginx --image=nginx --dry-run=client -o yaml # generate and display the YAML config for a k8s pod running in nginx image, without actually creating the pod
# first check if a resource exists. If it does, update the exsting resource; otherwise, create a new resource
# it can be used to apply pod-level, deployment-level and other k8s configuration update
kubectl apply -f nginx-deployment.yaml 
# kubectl create
kubectl delete -f <path_to_modified_yaml> --grace-period=0 # delete a reource based on configurations

kubectl exec -it <podname> -- sh -c "nsloopup example.com"

kubectl create deployment nginx --image=nginx --port 80
kubectl get deployment
kubectl get replicaset
kubectl get pods -o wide # `-o wide` provides additional details
kubectl scale deployment nginx --replicas=2; watch kubectl get pods -o wide
kubectl describe deployment nginx # to view the configs
kubectl edit deployment nginx # to change the configs

kubectl get deployment nginx -o yaml # output the deployment configuration in YAML format
kubectl apply -f nginx-deployment.yaml # update the resource specified in the YAML file

# (default) ClusterIP Service
# NodePort
# LoadBalancer
# ExternalName
# Headless Service
kubectl expose deployment/nginx --type=ClusterIP # expose nginx as ClusterIP service
kubectl expose deployment/nginx --name=my-app-service --type=ClusterIP # expose nginx as ClusterIP service
kubectl get service

# k8s DNS, created along with the cluster
<servicename>.<namespace>.svc.cluster.local # SERVICE nginx.default.svc.cluster.local
<podname>.<namespace>.svc.cluster.local # POD 10-10-0-50.default.pod.cluster.local, where iQp is used as pod name

# cluster level
# etcd, the distributed key-value store for clusters
# kube-apiserver, the main point of interaction with kubectl. It validates and configures data for API objects.
# kube-scheduler, control plane process that assigns pods to nodes(kubelet)
# kube-controller-manager, daemon that embeds the core control loops shipped with k8s. A control loop is a non-terminating loop that regulates the state of the system. Such as maintaining the deployment state
# coredns, cluster DNS for k8s
# kube-dns, to be deprecated (< v1.11)

# NODE level
# kubelet, the primary "node agent" or worker that runs on each node. It ensures that containers are running in a pod and it runs both pods and "static pods".
# kube-proxy, network proxy 

more-about-configMaps.md

ConfigMaps is used to store non-sensitive, configuration data. For instance, you might use a ConfigMap to store settings like a database URL, file configurations, or command-line arguments. It's a cluster-level resource. Any pod in the cluster can be configured to use data stored in a ConfigMap ny mounting the ConfigMap as a volume and setting the env variables using values from ConfigMap.

Storage of ConfigMaps:

1. API Server and etcd: ConfigMaps are stored in the Kubernetes etcd database, which is a key-value store used by Kubernetes to persist the cluster's state and configuration. This database is managed by the Kubernetes API Server, which typically runs on master nodes (or control plane nodes in the newer terminology).
2. Accessed via the API Server: When a pod in the cluster needs to access a ConfigMap, it does so through the Kubernetes API Server. The API Server retrieves the ConfigMap data from etcd and provides it to the pod. This means that the actual data retrieval does involve network communication between the node where the pod is running and the control plane nodes.
3. Caching: The kubelet on each node can cache the ConfigMap data locally once it's retrieved from the API server. When a pod on that node requires the ConfigMap, it can be served from this local cache if it's still valid.
4. Mounted as Volumes: When ConfigMaps are used as volumes in pods, the data is effectively transferred to the node where the pod is running and stored on the node's filesystem. The kubelet keeps this data in sync with the original ConfigMap stored in etcd.
5. As Environment Variables: If a ConfigMap is used to set environment variables in a pod, the values are set when the pod is created. The kubelet pulls the necessary data from the API server at pod creation time.

Implications:

• Availability: Since ConfigMaps are stored in etcd, they are as available as the etcd cluster. In a high-availability Kubernetes setup, etcd is typically distributed across multiple control plane nodes for fault tolerance.
• Performance: While there is network communication involved in retrieving ConfigMap data, Kubernetes is designed to handle this efficiently. For most use-cases, this does not create a significant performance bottleneck.
• Security: Since ConfigMaps can include sensitive data, though not as sensitive as Secrets, it's important to manage access to them using Kubernetes RBAC to ensure only authorized pods and users can read them.