Skip to main content

Working with Clusters

1. Creating Local Cluster

Example: Create local cluster with kind

apiVersion: kind.x-k8s.io/v1alpha4
kind: Cluster
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: "ingress-ready=true"
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
Option Values Description
kind Cluster Kind of the Kubernetes cluster configuration
nodes array List of nodes in the cluster
role control-plane, worker Role of the node in the cluster
kubeadmConfigPatches array Patches to apply to kubeadm config during init
extraPortMappings array Port mappings to expose from the container to host
Note: The kind tool requires Docker to be installed and running.
Warning: Ensure that the host machine has sufficient resources (CPU, RAM) to run a local cluster.

2. Connecting to Remote Cluster

Method Description Command Notes
kubectl config View and modify kubeconfig files kubectl config view Shows current configuration
kubectl config use-context Switch to a specific cluster context kubectl config use-context <context-name> Use context defined in kubeconfig
kubectl config set-cluster Define or update a cluster entry kubectl config set-cluster <cluster-name> --server=<api-server-url> Specify cluster endpoint and certificate
kubectl config set-credentials Define or update user credentials kubectl config set-credentials <user-name> --client-certificate=<cert-path> Set client certificate and key
kubectl config set-context Create or update a context kubectl config set-context <context-name> --cluster=<cluster-name> --user=<user-name> Combine cluster and user for a context

Example: Configure kubectl to connect to a remote cluster

kubectl config set-cluster my-remote-cluster \
  --server=https://192.168.1.100:6443 \
  --certificate-authority=/path/to/ca.crt

kubectl config set-credentials my-user \
  --client-certificate=/path/to/client.crt \
  --client-key=/path/to/client.key

kubectl config set-context my-context \
  --cluster=my-remote-cluster \
  --user=my-user

kubectl config use-context my-context
Note: Ensure that the kubeconfig file has proper permissions (e.g., chmod 600) to prevent unauthorized access.
Warning: Using --insecure-skip-tls-verify in kubectl config set-cluster disables TLS verification and should only be used for testing.

3. Viewing Cluster Nodes

Field Description Example Value
NAME Node name k8s-node-1
STATUS Node status (Ready, NotReady) Ready
ROLES Node roles (master, worker) <none>
VERSION Kubelet version running on node v1.28.0
INTERNAL-IP Internal IP address of node 10.0.1.10
EXTERNAL-IP External IP address of node (if applicable) <none>
OS-IMAGE Operating system image running on node Ubuntu 22.04.3 LTS
KERNEL-VERSION Kernel version running on node 5.15.0-1028-gcp
CONTAINER-RUNTIME Container runtime used on node Docker 24.0.5

Example: Get node details using kubectl

kubectl get nodes -o wide

Example: Describe a specific node

kubectl describe node k8s-node-1
Note: The STATUS field indicates whether the node is ready to accept workloads. A status of Ready means the node is healthy and available.
Warning: Nodes in NotReady status may not be able to schedule pods. Check logs or node conditions for more details.

4. Describing Node Details

Property Description Example Value
status.nodeInfo.machineID Unique identifier for the node's machine 12345678-1234-1234-1234-123456789012
status.nodeInfo.systemUUID Universally unique identifier for the node 12345678-1234-1234-1234-123456789012
status.nodeInfo.bootID Boot ID of the node's operating system 12345678-1234-1234-1234-123456789012
status.nodeInfo.kernelVersion Kernel version running on the node 5.4.0-1047-azure
status.nodeInfo.osImage Operating system image used on the node Ubuntu 20.04.6 LTS
status.nodeInfo.containerRuntimeVersion Version of the container runtime installed docker://20.10.24
status.nodeInfo.kubeletVersion Version of kubelet installed on the node v1.28.0
status.nodeInfo.kubeProxyVersion Version of kube-proxy installed on the node v1.28.0
status.nodeInfo.operatingSystem Operating system of the node linux
status.nodeInfo.architecture Architecture of the node amd64

Example: Describe Node Details

kubectl describe node <node-name>

Example: Get Node Info in JSON Format

kubectl get node <node-name> -o json | jq '.status.nodeInfo'

5. Labeling Nodes

Label Key Label Value Description
environment production Indicates the environment where the node is deployed
team backend Identifies the team responsible for managing the node
node-type worker Specifies the role of the node in the cluster

Example: Applying Labels to a Node

kubectl label node <node-name> environment=production team=backend

Example: Listing Nodes with Labels

kubectl get nodes --show-labels
Note: Labels are key-value pairs that can be attached to Kubernetes objects like nodes, pods, and services.

6. Tainting Nodes

Field Description Example
key The key part of the taint node-role.kubernetes.io/master
value The value part of the taint effect
effect The effect when the taint is applied NoSchedule, PreferNoSchedule, NoExecute

Example: Taint a Node

kubectl taint nodes <node-name> key=value:NoSchedule

Example: Remove a Taint

kubectl taint nodes <node-name> key-
Note: Taints are used to control how pods are scheduled on nodes.
Warning: Applying taints can prevent pods from being scheduled if they don't tolerate the taint.

7. Cordoning Nodes

Field Description Values
spec.unschedulable Controls whether new pods can be scheduled on the node true or false

Example: Cordon a Node

kubectl cordon &lt;node-name&gt;

Example: Uncordon a Node

kubectl uncordon &lt;node-name&gt;
Note: Cordoning a node prevents new pods from being scheduled on it, but does not terminate existing pods.

8. Draining Nodes

Option Values Notes
kubectl drain node-name Drains a node of pods
--ignore-daemonsets true Ignore daemonset pods during drain
--delete-local-data false Delete local data when draining
--grace-period -1 Grace period in seconds to wait for pod termination
--timeout 0s Timeout for drain operation

Example: Drain a Node

kubectl drain node-1 --ignore-daemonsets
Note: Draining a node will evict all pods from that node, and mark the node as unschedulable.

9. Uncordoning Nodes

Command Description Notes
kubectl uncordon NODE_NAME Removes the taint that prevents scheduling on a node Re-enables scheduling for workloads on the specified node

Example: Uncordon a Node

kubectl uncordon worker-node-01
Note: The node must have been cordoned using kubectl cordon before it can be uncordoned.
Warning: Uncordoning a node will allow new pods to be scheduled on it, which may affect existing workloads if resources are constrained.

10. Checking Cluster Health

Example: kubectl get nodes

kubectl get nodes
Field Description Status Values
NAME Node name minikube, gke-cluster-1
STATUS Node health status Ready, NotReady, SchedulingDisabled
ROLES Node roles <none>, master, control-plane
VERSION Kubelet version v1.29.0, v1.28.3

Example: kubectl get pods --all-namespaces

kubectl get pods --all-namespaces
Field Description Status Values
NAMESPACE Namespace of the pod default, kube-system
NAME Pod name nginx-deployment-7b5b9c6d8f
READY Pod readiness status 1/1, 0/1
STATUS Pod lifecycle status Running, Pending, Error
RESTARTS Number of pod restarts 0, 3
AGE Pod creation age 5m, 2d

Example: kubectl describe node minikube

kubectl describe node minikube
Note: Use kubectl describe node to get detailed information about a specific node's conditions, events, and resource usage.
Condition Status Explanation
Ready True, False Node is healthy and ready to accept pods
MemoryPressure True, False Node is under memory pressure
DiskPressure True, False Node is under disk pressure
PIDPressure True, False Node is under PID pressure

Workflow: Cluster Health Check Steps

  1. Run kubectl get nodes to check node status
  2. Run kubectl get pods --all-namespaces to check pod status
  3. Run kubectl describe node <node-name> for detailed node info
  4. Check logs of problematic pods or nodes if any status is not Ready

11. Viewing API Resources

Resource Type Description CLI Command Notes
Pod A group of one or more containers kubectl get pods Basic unit of deployment in Kubernetes
Service Abstracts network access to pods kubectl get services Enables communication between components
Deployment Manages pod replicas and updates kubectl get deployments Used for declarative application management
Namespace Logical partition of cluster resources kubectl get namespaces Used for organizing and isolating resources
ConfigMap Stores configuration data for pods kubectl get configmaps Allows decoupling of configuration from image
Secret Stores sensitive data like passwords kubectl get secrets Encrypted at rest in etcd

Example: Get all pods in a namespace

kubectl get pods -n production

Example: Get detailed pod information

kubectl describe pod my-pod -n development

12. Managing Cluster Certificates

Property Description Default Value Notes
certificates.kubeconfig Kubeconfig file path for cluster access /etc/kubernetes/admin.conf Used by kubectl and other tools to authenticate with the cluster
certificates.ca.crt CA certificate used to sign cluster certificates /etc/kubernetes/pki/ca.crt Must be distributed to all nodes and clients for trust
certificates.etcd.crt ETCD server certificate /etc/kubernetes/pki/etcd/server.crt Required for secure communication with etcd
certificates.api-server.crt API server certificate /etc/kubernetes/pki/apiserver.crt Used to secure communication between API server and clients

Example: Renewing a Cluster Certificate

openssl req -new -key /etc/kubernetes/pki/apiserver.key \
  -out /etc/kubernetes/pki/apiserver.csr \
  -subj "/CN=kube-apiserver" \
  -config /etc/kubernetes/pki/openssl.conf

openssl ca -in /etc/kubernetes/pki/apiserver.csr \
  -out /etc/kubernetes/pki/apiserver.crt \
  -config /etc/kubernetes/pki/openssl.conf \
  -extensions v3_req \
  -days 365
Note: After renewing certificates, restart the API server and other components to pick up new certificates.
Warning: Ensure that all cluster components and clients have updated CA certificates before rotating keys to prevent authentication failures.

Was this article helpful?