Tengo mi Pod manifiesto de la siguiente manera:
apiVersion: v1 kind: Pod metadata: name: pod-nginx-container spec: containers: - name: nginx-alpine-container-1 image: nginx:alpine ports: - containerPort: 80 Y puedo obtener un shell para el contenedor que ejecuta mi Nginx usando kubectl exec --stdin --tty pod-nginx-container -- /bin/sh
Mi pregunta es: ¿Kubernetes siempre otorga un caparazón al contenedor en ejecución? Quiero decir, supongamos que he creado mi propia imagen del servidor web Tomcat, y cuando use esa imagen, ¿obtendré el shell para iniciar sesión en el contenedor que ejecuta Tomcat?
Kubernetes programa pods en nodos. Un pod consta de uno o más contenedores, que se instancian a partir de imágenes de contenedor.
Una imagen de contenedor contiene un comando que se ejecutará como el proceso principal, pero también puede contener otros archivos binarios y también un "ámbito de usuario" completo de Linux como, por ejemplo, Ubuntu con shell y muchas herramientas.
Las imágenes de contenedor se pueden construir desde cero sin ningún otro software que, por ejemplo, su aplicación, pero normalmente contienen más software para que su aplicación se pueda ejecutar, por ejemplo, glibc . Vea distroless para imágenes base mínimas que no contienen un shell .
Mi pregunta es: ¿Kubernetes siempre otorga un caparazón al contenedor en ejecución? Quiero decir, supongamos que he creado mi propia imagen del servidor web Tomcat, y cuando use esa imagen, ¿obtendré el shell para iniciar sesión en el contenedor que ejecuta Tomcat?
Su contenedor contiene un caparazón, solo si ha incorporado un caparazón, lo más probable es que use una imagen base que contenga un caparazón, por ejemplo, alpine o ubuntu.
Depende de lo que haga en su Dockerfile antes de construir una imagen de contenedor con docker build