Networking & Config
.mdVerified against kubectl v1.34.0 (client), flags verified via `kubectl <cmd> --help`, 2026-08-21 · official docs
Services, ingress, configmaps, secrets, and switching between clusters/namespaces via kubeconfig contexts.
Exposing a deployment as a service#
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#
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#
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 yamlSecrets#
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 inspectionSecret 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#
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 contextSwitching 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#
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 portRBAC — roles, bindings, and service accounts#
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 objectsA 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).
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 accountauth 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.