{"id":1340,"date":"2026-08-20T11:39:42","date_gmt":"2026-08-20T17:39:42","guid":{"rendered":"https:\/\/folken-it.com\/?p=1340"},"modified":"2026-08-20T11:50:52","modified_gmt":"2026-08-20T17:50:52","slug":"comandos-de-kubernetes-que-todo-administrador-deberia-conocer","status":"publish","type":"post","link":"https:\/\/folken-it.com\/?p=1340","title":{"rendered":"Comandos de Kubernetes que todo administrador deber\u00eda conocer"},"content":{"rendered":"\n

Kubernetes se ha convertido en una de las plataformas m\u00e1s importantes para administrar aplicaciones basadas en contenedores. Si trabajas en soporte, DevOps, infraestructura, SRE o administraci\u00f3n de sistemas<\/strong>, conocer los comandos b\u00e1sicos de kubectl<\/code> puede ayudarte a diagnosticar problemas mucho m\u00e1s r\u00e1pido.<\/p>\n\n\n\n

kubectl<\/code> es la herramienta de l\u00ednea de comandos utilizada para comunicarnos con un cluster de Kubernetes. A continuaci\u00f3n encontrar\u00e1s algunos de los comandos que considero m\u00e1s \u00fatiles en operaciones diarias.<\/p>\n\n\n\n

1. Conocer el estado del cluster<\/h2>\n\n\n\n

Comencemos por identificar los nodos:<\/p>\n\n\n\n

kubectl get nodes\n<\/code><\/pre>\n\n\n\n
Para obtener informaci\u00f3n adicional:<\/p>\n\n\n\n
kubectl get nodes -o wide\n<\/code><\/pre>\n\n\n\n
Y para conocer los detalles de un nodo:<\/p>\n\n\n\n
kubectl describe node <node-name>\n<\/code><\/pre>\n\n\n\n
Tambi\u00e9n podemos consultar informaci\u00f3n general del cluster:<\/p>\n\n\n\n
kubectl cluster-info\n<\/code><\/pre>\n\n\n\n
2. Consultar los Pods<\/h2>\n\n\n\n
Los Pods son una de las primeras cosas que normalmente revisamos cuando una aplicaci\u00f3n presenta problemas.<\/p>\n\n\n\n
Mostrar los Pods:<\/p>\n\n\n\n
kubectl get pods\n<\/code><\/pre>\n\n\n\n
Mostrar Pods de todos los namespaces:<\/p>\n\n\n\n
kubectl get pods -A\n<\/code><\/pre>\n\n\n\n
Mostrar informaci\u00f3n adicional:<\/p>\n\n\n\n
kubectl get pods -o wide\n<\/code><\/pre>\n\n\n\n
Consultar un namespace espec\u00edfico:<\/p>\n\n\n\n
kubectl get pods -n production\n<\/code><\/pre>\n\n\n\n
Obtener informaci\u00f3n detallada:<\/p>\n\n\n\n
kubectl describe pod <pod-name>\n<\/code><\/pre>\n\n\n\n
Al hacer troubleshooting presta atenci\u00f3n a estados como:<\/p>\n\n\n\n
CrashLoopBackOff\nImagePullBackOff\nErrImagePull\nPending\nOOMKilled\nError\n<\/code><\/pre>\n\n\n\n
3. Revisar los logs<\/h2>\n\n\n\n
Uno de los comandos m\u00e1s importantes para Production Support es:<\/p>\n\n\n\n
kubectl logs <pod-name>\n<\/code><\/pre>\n\n\n\n
Seguir el log en tiempo real:<\/p>\n\n\n\n
kubectl logs -f <pod-name>\n<\/code><\/pre>\n\n\n\n
Mostrar solamente las \u00faltimas 100 l\u00edneas:<\/p>\n\n\n\n
kubectl logs --tail=100 <pod-name>\n<\/code><\/pre>\n\n\n\n
Consultar los \u00faltimos 10 minutos:<\/p>\n\n\n\n
kubectl logs --since=10m <pod-name>\n<\/code><\/pre>\n\n\n\n
Si existen varios containers:<\/p>\n\n\n\n
kubectl logs <pod-name> -c <container-name>\n<\/code><\/pre>\n\n\n\n
Y un comando especialmente \u00fatil cuando un container se ha reiniciado:<\/p>\n\n\n\n
kubectl logs <pod-name> --previous\n<\/code><\/pre>\n\n\n\n
Esto permite consultar los logs de la instancia anterior del container.<\/p>\n\n\n\n
4. Ejecutar comandos dentro de un container<\/h2>\n\n\n\n
Para abrir una terminal Bash:<\/p>\n\n\n\n
kubectl exec -it <pod-name> -- \/bin\/bash\n<\/code><\/pre>\n\n\n\n
Si Bash no est\u00e1 disponible:<\/p>\n\n\n\n
kubectl exec -it <pod-name> -- \/bin\/sh\n<\/code><\/pre>\n\n\n\n
Tambi\u00e9n podemos ejecutar directamente comandos:<\/p>\n\n\n\n
kubectl exec <pod-name> -- env\n<\/code><\/pre>\n\n\n\n
o:<\/p>\n\n\n\n
kubectl exec <pod-name> -- df -h\n<\/code><\/pre>\n\n\n\n
5. Revisar CPU y memoria<\/h2>\n\n\n\n
Para conocer el consumo de recursos:<\/p>\n\n\n\n
kubectl top pods\n<\/code><\/pre>\n\n\n\n
Todos los namespaces:<\/p>\n\n\n\n
kubectl top pods -A\n<\/code><\/pre>\n\n\n\n
Consumo por nodo:<\/p>\n\n\n\n
kubectl top nodes\n<\/code><\/pre>\n\n\n\n
Y por container:<\/p>\n\n\n\n
kubectl top pod <pod-name> --containers\n<\/code><\/pre>\n\n\n\n
kubectl top<\/code> requiere que el cluster proporcione Metrics API, normalmente mediante Metrics Server u otra implementaci\u00f3n compatible.<\/p>\n\n\n\n
6. Revisar eventos<\/h2>\n\n\n\n
Los eventos pueden revelar r\u00e1pidamente problemas de scheduling, almacenamiento, im\u00e1genes o health checks.<\/p>\n\n\n\n
kubectl get events\n<\/code><\/pre>\n\n\n\n
Una variante especialmente \u00fatil:<\/p>\n\n\n\n
kubectl get events \\\n  --sort-by=.metadata.creationTimestamp\n<\/code><\/pre>\n\n\n\n
Podemos encontrar eventos como:<\/p>\n\n\n\n
FailedScheduling\nFailedMount\nFailedAttachVolume\nFailedPull\nBackOff\nUnhealthy\nEvicted\n<\/code><\/pre>\n\n\n\n
7. Deployments<\/h2>\n\n\n\n
Consultar deployments:<\/p>\n\n\n\n
kubectl get deployments\n<\/code><\/pre>\n\n\n\n
o simplemente:<\/p>\n\n\n\n
kubectl get deploy\n<\/code><\/pre>\n\n\n\n
Informaci\u00f3n detallada:<\/p>\n\n\n\n
kubectl describe deployment <deployment-name>\n<\/code><\/pre>\n\n\n\n
Reiniciar un deployment:<\/p>\n\n\n\n
kubectl rollout restart deployment <deployment-name>\n<\/code><\/pre>\n\n\n\n
Comprobar el rollout:<\/p>\n\n\n\n
kubectl rollout status deployment <deployment-name>\n<\/code><\/pre>\n\n\n\n
Consultar historial:<\/p>\n\n\n\n
kubectl rollout history deployment <deployment-name>\n<\/code><\/pre>\n\n\n\n
Realizar rollback:<\/p>\n\n\n\n
kubectl rollout undo deployment <deployment-name>\n<\/code><\/pre>\n\n\n\n
8. Services y conectividad<\/h2>\n\n\n\n
Consultar servicios:<\/p>\n\n\n\n
kubectl get services\n<\/code><\/pre>\n\n\n\n
Forma abreviada:<\/p>\n\n\n\n
kubectl get svc\n<\/code><\/pre>\n\n\n\n
Informaci\u00f3n detallada:<\/p>\n\n\n\n
kubectl describe svc <service-name>\n<\/code><\/pre>\n\n\n\n
Tambi\u00e9n podemos revisar los EndpointSlices:<\/p>\n\n\n\n
kubectl get endpointslices\n<\/code><\/pre>\n\n\n\n
Esto resulta especialmente \u00fatil cuando un Service existe pero la aplicaci\u00f3n no responde.<\/p>\n\n\n\n
9. Ingress<\/h2>\n\n\n\n
kubectl get ingress\n<\/code><\/pre>\n\n\n\n
Todos los namespaces:<\/p>\n\n\n\n
kubectl get ingress -A\n<\/code><\/pre>\n\n\n\n
Informaci\u00f3n detallada:<\/p>\n\n\n\n
kubectl describe ingress <ingress-name>\n<\/code><\/pre>\n\n\n\n
Para troubleshooting podemos pensar en el flujo:<\/p>\n\n\n\n
Usuario\n   \u2193\nDNS\n   \u2193\nLoad Balancer\n   \u2193\nIngress\n   \u2193\nService\n   \u2193\nEndpointSlice\n   \u2193\nPod\n   \u2193\nContainer\n<\/code><\/pre>\n\n\n\n
10. Persistent Volumes<\/h2>\n\n\n\n
Consultar Persistent Volumes:<\/p>\n\n\n\n
kubectl get pv\n<\/code><\/pre>\n\n\n\n
Persistent Volume Claims:<\/p>\n\n\n\n
kubectl get pvc\n<\/code><\/pre>\n\n\n\n
Informaci\u00f3n detallada:<\/p>\n\n\n\n
kubectl describe pvc <pvc-name>\n<\/code><\/pre>\n\n\n\n
Estos comandos son particularmente importantes cuando encontramos Pods en Pending<\/code> o ContainerCreating<\/code> relacionados con problemas como FailedMount<\/code>.<\/p>\n\n\n\n
11. ConfigMaps y Secrets<\/h2>\n\n\n\n
ConfigMaps:<\/p>\n\n\n\n
kubectl get configmaps\n<\/code><\/pre>\n\n\n\n
kubectl describe configmap <name>\n<\/code><\/pre>\n\n\n\n
Secrets:<\/p>\n\n\n\n
kubectl get secrets\n<\/code><\/pre>\n\n\n\n
kubectl describe secret <name>\n<\/code><\/pre>\n\n\n\n
En ambientes productivos debemos evitar imprimir innecesariamente informaci\u00f3n sensible almacenada en Secrets.<\/p>\n\n\n\n
12. Obtener la configuraci\u00f3n YAML<\/h2>\n\n\n\n
Una t\u00e9cnica muy \u00fatil para troubleshooting:<\/p>\n\n\n\n
kubectl get pod <pod-name> -o yaml\n<\/code><\/pre>\n\n\n\n
Tambi\u00e9n podemos hacerlo con otros recursos:<\/p>\n\n\n\n
kubectl get deployment <name> -o yaml\n<\/code><\/pre>\n\n\n\n
kubectl get service <name> -o yaml\n<\/code><\/pre>\n\n\n\n
Esto permite revisar configuraci\u00f3n, labels, annotations, requests, limits y estado del recurso.<\/p>\n\n\n\n
13. Contextos<\/h2>\n\n\n\n
Si administras m\u00faltiples clusters, este punto es fundamental.<\/p>\n\n\n\n
Mostrar contextos:<\/p>\n\n\n\n
kubectl config get-contexts\n<\/code><\/pre>\n\n\n\n
Conocer el contexto actual:<\/p>\n\n\n\n
kubectl config current-context\n<\/code><\/pre>\n\n\n\n
Cambiar de contexto:<\/p>\n\n\n\n
kubectl config use-context <context-name>\n<\/code><\/pre>\n\n\n\n
Antes de realizar una modificaci\u00f3n importante en producci\u00f3n, verifica siempre d\u00f3nde est\u00e1s trabajando:<\/p>\n\n\n\n
kubectl config current-context\n<\/code><\/pre>\n\n\n\n
Un comando correcto ejecutado sobre el cluster equivocado puede convertirse r\u00e1pidamente en un incidente.<\/p>\n\n\n\n
14. Port Forwarding<\/h2>\n\n\n\n
Podemos crear temporalmente una conexi\u00f3n hacia un Pod:<\/p>\n\n\n\n
kubectl port-forward pod\/<pod-name> 8080:8080\n<\/code><\/pre>\n\n\n\n
O hacia un Service:<\/p>\n\n\n\n
kubectl port-forward svc\/<service-name> 8080:80\n<\/code><\/pre>\n\n\n\n
Despu\u00e9s podemos probar localmente:<\/p>\n\n\n\n
curl localhost:8080\n<\/code><\/pre>\n\n\n\n
Esto puede ser muy \u00fatil para aislar problemas de conectividad durante troubleshooting.<\/p>\n\n\n\n
Los comandos que deber\u00edas memorizar<\/h2>\n\n\n\n
Si est\u00e1s comenzando con Kubernetes, empieza por estos:<\/p>\n\n\n\n
kubectl get nodes\nkubectl get pods -A\nkubectl get pods -o wide\nkubectl describe pod <pod>\nkubectl logs <pod>\nkubectl logs -f <pod>\nkubectl logs <pod> --previous\nkubectl exec -it <pod> -- \/bin\/bash\nkubectl get events\nkubectl top pods\nkubectl top nodes\nkubectl get deploy\nkubectl get svc\nkubectl get endpointslices\nkubectl get ingress\nkubectl get pv\nkubectl get pvc\nkubectl get pod <pod> -o yaml\nkubectl rollout status deployment\/<deployment>\nkubectl rollout history deployment\/<deployment>\nkubectl rollout undo deployment\/<deployment>\nkubectl config current-context\n<\/code><\/pre>\n\n\n\n
Una metodolog\u00eda sencilla para troubleshooting<\/h2>\n\n\n\n
Memorizar comandos es \u00fatil, pero saber cu\u00e1ndo utilizarlos es mucho m\u00e1s importante<\/strong>.<\/p>\n\n\n\n
Cuando una aplicaci\u00f3n Kubernetes presenta problemas, podemos comenzar con:<\/p>\n\n\n\n
get pods\n   \u2193\ndescribe pod\n   \u2193\nlogs \/ logs --previous\n   \u2193\nevents\n   \u2193\nCPU \/ Memory\n   \u2193\nRequests \/ Limits\n   \u2193\nService \/ EndpointSlice\n   \u2193\nIngress\n   \u2193\nNode \/ Storage \/ Network\n   \u2193\nCambios recientes\n   \u2193\nMitigaci\u00f3n\n   \u2193\nRoot Cause Analysis\n<\/code><\/pre>\n\n\n\n
Kubernetes puede parecer complejo al principio porque contiene muchos componentes. Sin embargo, una vez que comprendemos c\u00f3mo se relacionan Pods, Deployments, Services, Ingress, Nodes, almacenamiento y networking<\/strong>, los comandos de kubectl<\/code> comienzan a tener mucho m\u00e1s sentido.<\/p>\n\n\n\n
El objetivo no deber\u00eda ser memorizar cientos de comandos, sino desarrollar una metodolog\u00eda que nos permita identificar r\u00e1pidamente d\u00f3nde se encuentra el problema<\/strong>.<\/p>\n\n\n\n
\u00bfY t\u00fa qu\u00e9 comandos de Kubernetes utilizas con mayor frecuencia durante troubleshooting?<\/strong><\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Kubernetes se ha convertido en una de las plataformas m\u00e1s importantes para administrar aplicaciones basadas en contenedores. Si trabajas en soporte, DevOps, […]<\/p>\n","protected":false},"author":62,"featured_media":1341,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"jetpack_seo_schema_type":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[54],"tags":[],"class_list":["post-1340","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-kubernetes"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/08\/kuebernetes.png?fit=1536%2C1024&ssl=1","_links":{"self":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1340","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/users\/62"}],"replies":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1340"}],"version-history":[{"count":2,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1340\/revisions"}],"predecessor-version":[{"id":1347,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1340\/revisions\/1347"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/media\/1341"}],"wp:attachment":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1340"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1340"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1340"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}