Skip to main content
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

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:
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

CommandDescription
kubectl get nodesList all cluster nodes
kubectl get namespacesShow active namespaces
kubectl -n ingress-nginx get allInspect Ingress Controller resources
kubectl get ingressDisplay all Ingress resources
kubectl config view --minifyShow current kubeconfig context
kubectl create namespace <name>Create a new namespace

Watch Video