Exploring Kubernetes Cluster

This guide walks you through inspecting a Google Kubernetes Engine (GKE) cluster. You’ll learn how to list nodes, view namespaces, deploy a sample NGINX app with Ingress, verify your kubeconfig, and prepare namespaces for GitLab CI/CD.

Inspecting Cluster Nodes on GKE

Note

Make sure you’ve authenticated with GKE and set up kubectl (or aliased as k) using:

gcloud container clusters get-credentials <CLUSTER_NAME> --zone <ZONE> --project <PROJECT_ID>

List your cluster’s worker nodes:

k get nodes

Example output:

NAME                                         STATUS   ROLES     AGE   VERSION
gke-cluster-1-default-pool-36b5f551-hzvn     Ready    <none>    20m   v1.29.0-gke.1381000
gke-cluster-1-default-pool-36b5f551-rsc0     Ready    <none>    20m   v1.29.0-gke.1381000

These nodes are running Kubernetes v1.29.0.

Viewing Namespaces and the NGINX Ingress Controller

Show all namespaces:

k get namespaces

Locate the ingress-nginx namespace and inspect its resources:

k -n ingress-nginx get all

You should see:

A Deployment managing the Ingress Controller pod
A LoadBalancer Service exposing a public IP

Deploying a Sample NGINX Application

In the default namespace, the following resources route traffic through the Ingress Controller:

k -n default get all
k -n default get ingress

Sample output:

# Pods, Services, Deployments
pod/nginx-deploy-d845cc945-hnj2v          1/1 Running   0        8m
service/nginx-deploy                     ClusterIP    10.96.14.252   80/TCP    8m
deployment.apps/nginx-deploy             1/1          1              8m

# Ingress
nginx-demo   <none>   nginx-default.34.82.207.123.nip.io   34.82.207.123   80,443   7m

Copy the Ingress host into your browser. You may encounter a security warning due to a self-signed certificate:

Warning

The default Ingress TLS certificate is self-signed. Browsers will warn before displaying the NGINX welcome page.

The image shows a browser displaying the default "Welcome to nginx!" page, indicating that the nginx web server is successfully installed and running.

This confirms external traffic is routed correctly.

Configuring kubectl and kubeconfig for CI/CD

To automate deployments in GitLab CI, ensure kubectl is installed and authenticated via kubeconfig.

Check client and server versions:

kubectl version --short

Client Version: v1.29.1
Server Version: v1.29.0-gke.1381000

View the active kubeconfig context:

kubectl config view --minify

apiVersion: v1
clusters:
- cluster:
    server: https://35.230.61.213
    certificate-authority-data: DATA+OMITTED
  name: gke_clgcporg8-090_us-west1-a_cluster-1
contexts:
- context:
    cluster: gke_clgcporg8-090_us-west1-a_cluster-1
    namespace: kube-system
    user: gitlab-cluster-admin
  name: gke_clgcporg8-090_us-west1-a_cluster-1
users:
- name: gitlab-cluster-admin
  user:
    token: REDACTED

A dedicated user or service account (e.g., gitlab-cluster-admin) should authenticate your GitLab CI jobs.

Creating Namespaces for Environments

Instead of separate clusters, use dedicated namespaces to isolate development and staging workloads:

k create namespace development
k create namespace staging

namespace/development created
namespace/staging created

Verify all namespaces:

k get namespaces

NAME                  STATUS   AGE
default               Active   30m
development           Active   1m
staging               Active   1m
ingress-nginx         Active   25m
kube-system           Active   30m

Your cluster is now prepared for GitLab CI pipelines targeting development and staging.

Kubernetes CLI Command Reference

Command	Description
`kubectl get nodes`	List all cluster nodes
`kubectl get namespaces`	Show active namespaces
`kubectl -n ingress-nginx get all`	Inspect Ingress Controller resources
`kubectl get ingress`	Display all Ingress resources
`kubectl config view --minify`	Show current kubeconfig context
`kubectl create namespace <name>`	Create a new namespace

Links and References

Watch Video

Watch video content