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 |
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 |
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
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 |
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 |
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 |
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 |
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
| 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 |
| 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 |
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
- Run
kubectl get nodesto check node status - Run
kubectl get pods --all-namespacesto check pod status - Run
kubectl describe node <node-name>for detailed node info - 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 |
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.