# kubectl Cheat Sheet — Networking & Config

> **Tool:** kubectl
> **Category:** Containers & Orchestration
> **Verified against:** kubectl v1.34.0 (client), flags verified via `kubectl <cmd> --help`, 2026-08-21
> **Official docs:** https://kubernetes.io/docs/reference/kubectl/

Services, ingress, configmaps, secrets, and switching between clusters/namespaces via kubeconfig contexts.

## Exposing a deployment as a service

```bash
kubectl expose deployment my-deployment --port=80 --target-port=8080
kubectl expose pod my-pod --port=443 --name=my-frontend
kubectl get services
kubectl get svc my-service -o wide
```

`--port` is what the Service listens on; `--target-port` is the container port traffic gets forwarded to — they're allowed to differ (e.g. exposing 443 externally while the container listens on 8443).

## Ingress

```bash
kubectl create ingress simple --rule="app.example.com/*=my-service:80"
kubectl create ingress simple --class=nginx --rule="app.example.com/*=my-service:80,tls=my-tls-secret"
kubectl get ingress
kubectl describe ingress simple
```

`--class` selects which ingress controller handles the resource (e.g. `nginx`, `alb`) — a cluster with no matching IngressClass installed will accept the resource but never actually route traffic for it.

## ConfigMaps

```bash
kubectl create configmap my-config --from-literal=LOG_LEVEL=info --from-literal=ENV=production
kubectl create configmap my-config --from-file=path/to/config.yaml
kubectl get configmap my-config -o yaml
```

## Secrets

```bash
kubectl create secret generic my-secret --from-literal=DB_PASSWORD=hunter2
kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa
kubectl get secret my-secret -o jsonpath='{.data.DB_PASSWORD}' | base64 -d   # decode a value for inspection
```

Secret values in `get -o yaml`/`json` are base64-encoded, not encrypted — base64 is an encoding, not security. Anyone with `get secrets` RBAC access can decode it in one command; rely on RBAC and (if needed) an external secrets manager, not the encoding, for actual protection.

## Kubeconfig contexts — switching clusters and namespaces

```bash
kubectl config get-contexts                     # list all contexts
kubectl config current-context                  # which one is active
kubectl config use-context my-cluster            # switch active context
kubectl config set-context --current --namespace=my-namespace   # default namespace for the current context
```

Switching context switches which *cluster and credentials* `kubectl` talks to — a common incident-response mistake is running a `delete` against the wrong cluster because the active context wasn't checked first. `kubectl config current-context` before anything destructive is cheap insurance.

## Port-forwarding to a pod or service

```bash
kubectl port-forward pod/my-pod 8080:80
kubectl port-forward deployment/my-deployment 8080:80
kubectl port-forward service/my-service 8443:https   # target a service's named port
```

## RBAC — roles, bindings, and service accounts

```bash
kubectl create serviceaccount my-app-sa
kubectl get serviceaccounts

kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
kubectl create rolebinding my-app-binding --role=pod-reader --serviceaccount=my-namespace:my-app-sa

kubectl create clusterrolebinding my-app-cluster-binding --clusterrole=view --user=jane@example.com

kubectl get roles,rolebindings                    # namespaced RBAC objects, current namespace
kubectl get clusterroles,clusterrolebindings        # cluster-scoped RBAC objects
```

A `Role`/`RoleBinding` pair grants permissions within one namespace; `ClusterRole`/`ClusterRoleBinding` grants cluster-wide (or, if bound via a namespaced `RoleBinding`, a `ClusterRole`'s rules scoped to just that namespace — useful for reusing a built-in role like `view`/`edit`/`admin` without redefining it per namespace).

```bash
kubectl auth can-i create pods --namespace=my-namespace                       # am I allowed to?
kubectl auth can-i list pods --as=system:serviceaccount:my-namespace:my-app-sa   # check as a specific service account
```

`auth can-i` is the fastest way to debug a `Forbidden` error — it evaluates the same RBAC rules the API server would, without you having to trace through Role/RoleBinding YAML by hand.