Para el dia de hoy la practica es sobre deployments.
Actividad 3: Create a new deployment named httpd-frontend with 3 replicas using image httpd:2.4-alpine
Bueno antes de realizar busquedas voy a intentar generar con los comandos que ya conozco, create y appy. (https://kubernetes.io/docs/reference/kubectl/generated/kubectl_create/kubectl_create_deployment/)
Particularmente se que create si funciona con deployments en a diferencia de los pods.
kubectl create deployments nombre –image=nginx
Funciono bastante bien, tuve unos problemas cuando escribi ‘busybox’ , pero revisando parece algo de la propia imagen que espera un comando entonces vamos con la actividad
kubectl create deployment httpd-frontend –replicas=3 –image=httpd:2.4-alpine
El apply no funciona con esta estrategia. Asi que usare un documento para el mismo.
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-front
spec:
selector:
matchLabels:
app: httpd-frontend
template:
metadata:
labels:
app: httpd-frontend
spec:
containers:
- name: deployment-front
image: httpd:2.4-alpine
replicas: 3
Datos interesantes.
- El API es diferente, es apps/v1 a diferencia de un pod que es simple v1.
- Hay dos tipos de spec, para la plantilla y para el objeto principal.
- El objeto principal tiene sus parametros como replicas dentro de spec
- El selector es importante para que K8 relacione en su operativa el los pods del template con el deployment.
Datos complementario
- Cuando hice el experimento con busybox, si necesitaba un parametro command. Diferentes imagenes necesitan diferentes parametros
- Se puede monitorear el deployment o cualquier componente con kubectl get pod –watch
- –watch deja ver que esta pasando en tiempo real para la consulta de lectura.
- Con el comando para exportar o el –dry-run=client logre ver muchos mas parametros como -strategy