Básico Kubernetes
Tipos de Recursos
Kubernetes trabaja con varios tipos de recursos distintos, los más utilizados son:
● Pod (pod): Contiene el contenedor de docker de la API, es la unidad de procesamiento.
● Service (svc): Representa el servicio propiamente dicho, se asegura de que los pods
están funcionando.
● Deployment (deploy): Especifica el servicio que se va a utilizar y cómo debe levantarse
(ej: número de réplicas, imagen de docker a utilizar, recursos del pod, etc).
● Ingress (ing): Contiene las rutas que deben direccionar a ese servicio.
● Configmap (configmap): Contiene variables del entorno que se le pasan al servicio.
● Secret (secret): Contiene variables del entorno que se le pasan al servicio.
Comandos
Obtener Listado de Recursos
Devuelve un listado de todos los recursos de un tipo.
kubectl -n <ambiente> get <recurso>
<ambiente> se debe reemplazar por el namespace al que se quiera acceder (dev o qa)
<recurso> se debe reemplazar por el tipo de recurso (svc, deploy, ing, configmap o secret)
Se puede combinar con el comando grep para filtrar por nombre de servicio.
Ejemplo
kubectl -n dev get pod | grep loanscalculator
Nos daría la lista de pods que contienen el “loanscalculator” en el nombre, por ejemplo:
api-fifpe-debt-reorganization-createloanscalculator-v1-dep8mkgn
Obtener Información de un Recurso
Devuelve información detallada del estado del recurso.
Es útil, por ejemplo, cuando un pod falla al inicializar.
kubectl -n <ambiente> describe <recurso> <nombre>
<ambiente> se debe reemplazar por el namespace al que se quiera acceder (dev o qa)
<recurso> se debe reemplazar por el tipo de recurso (svc, deploy, ing, configmap o secret)
<nombre> se debe reemplazar por el nombre entregado al pedir el listado de dicho recurso
Ejemplo
kubectl -n dev describe pod api-fifpe-debt-reorganization-createloanscalculator-v1-dep8mkgn
Obtener Logs de un Pod
Devuelve todos los mensajes que se loguearon o imprimieran por pantalla en ese pod.
Solo funciona si el pod está iniciado y funcionando correctamente.
kubectl -n <ambiente> logs <nombre-pod>
<ambiente> se debe reemplazar por el namespace al que se quiera acceder (dev o qa)
<nombre-pod> se debe reemplazar por el nombre del pod deseado, como aparece al pedir el
listado.
Ejemplo
kubectl -n dev logs api-fifpe-debt-reorganization-createloanscalculator-v1-dep8mkgn
Eliminar un Recurso
Elimina el recurso especificado del ambiente.
kubectl -n <ambiente> delete <recurso> <nombre>
<ambiente> se debe reemplazar por el namespace al que se quiera acceder (dev o qa)
<recurso> se debe reemplazar por el tipo de recurso (svc, deploy, ing, configmap o secret)
<nombre> se debe reemplazar por el nombre entregado al pedir el listado de dicho recurso
Ejemplo
kubectl -n dev delete svc api-fifpe-debt-reorganization-createloanscalculator-v1-svc
Para el caso de pods también se puede lograr escalando el número de réplicas a cero y de
vuelta al número deseado:
kubectl -n dev scale deploy <deploy-name> --replicas=0
kubectl -n dev scale deploy <deploy-name> --replicas=1
Editar un recurso en caliente
Editar el configmap:
kubectl -n dev edit configmap <nombrepod>
Validar Conectividad Desde el Pod de Linux
Ingresar al pod linux-toolkit:
kubectl -n dev get pod | grep linux-toolkit
kubectl -n dev exec -it <linux-toolkit-pod> sh
Desde la consola del pod usar el comando wget a la URI a validar:
wget <URI>
Otra opción es usar el comando telnet:
telnet <ip> <port>
<ip> no lleva protocolo (http/https).
<port> si no se especifica, debiera ser 80
Ejemplo
telnet 127.168.0.1 80
Port Forward
Permite acceder a un servicio o pod desde local.
kubectl -n <ambiente> port-forward svc/<nombre_servicio>
<puerto_local>:<puerto_destino>
<ambiente> se debe reemplazar por el namespace al que se quiera acceder (dev o qa)
<nombre_servicio> se debe reemplazar por el nombre del servicio al que se desea acceder
<puerto_local> indica a través de qué puerto de localhost se va a acceder al servicio
<puerto_destino> debe ser 8080
Ejemplo
kubectl -n dev port-forward svc/api-fifpe-debt-reorganization-createloanscalculator-v1-svc
8081:8080
Otra opción es hacer port forward directamente a un pod:
kubectl -n <ambiente> port-forward <nombre_pod> <puerto_local>:<puerto_destino>
Ejemplo
kubectl -n dev port-forward api-fifpe-debt-reorganization-createloanscalculator-v1-12345678
8081:8080
Notas
● El servicio reinicia los pods caídos, eso incluye los eliminados por el comando delete. Si
se desea que los pods no reinicien se debe eliminar el service.
● Para volver a crear los recursos es necesario correr el pipeline en el ambiente que
corresponda.
● El deploy es el único recurso que al ejecutar el pipeline no se genera nuevamente si ya
existe. Si se realizan cambios en el archivo deployment.yaml se debe eliminar el deploy
antes de ejecutar el pipeline para que hagan efecto.
● Puede ser conveniente eliminar todos los recursos antes de volver a ejecutar un
pipeline, para asegurarse que todos los recursos son inicializados nuevamente.
Errores Frecuentes a lo Criosho
● Errarle de nombre en los recursos en los yaml de iaas (falta de svc, ing, cfg, secret o
deploy) (el pod no inicia: revisar con describe. Que error da? Era algo como
ContainerCreationError?)
● Falta de recursos en el ambiente para levantar el pod (se ve con el describe del pod,
algo como 0/7 cpu disponibles)
● Path de ingress no coincide con path de http_handler (una de las rutas da “no route
matched with those values” (no esta en ingress) y la otra “404 not found” (no es
reconocida por la API))... Parece que también puede responder con un html en algunos
casos.
● Cuando no coincide el nombre del configmap o del service puede pasar el pipeline y dar
error de ImagePullBackoff
● Codear mal, que se yo…
Más comandos que pueden llegar a ser útiles:
- https://kubernetes.io/docs/reference/kubectl/cheatsheet/
Configuración
Setup
Para acceder al cluster es necesario cargar un archivo configuraciones y un certificado
Las configuraciones están definidas en la carpeta ~/.kube. El archivo por defecto es “config”,
pero se puede cambiar seteando la variable de entorno KUBECONFIG.
Ejemplo
export KUBECONFIG=~/.kube/newConfigFile
Manejo de Contextos
Dado el cambio del ambiente de dalaran se requieren contextos distintos para acceder a los
ambientes de DEV y QA.
Para cambiar de contexto:
kubectl config use-context <nombre_contexto>
Ejemplo
kubectl config use-context dalaran (#develop)
Nota: puede ser necesario usar sudo
Los contextos para los ambientes son los siguientes:
- DEV: dalaran
- QA: kube-preprod
Busqueda dentro de recursos:
kubectl -n dev get configmap -o yaml | grep
https://10.140.40.94/axis2/services/SAT_FLCLMNFWS
$ kubectl -n dev describe configmap | grep
http://10.140.40.94:7003/axis2/services/SAT_FLCLMNFWS
