{"id":39016,"date":"2019-10-31T22:27:21","date_gmt":"2019-10-31T19:27:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google\/"},"modified":"2019-10-31T22:27:21","modified_gmt":"2019-10-31T19:27:21","slug":"7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/7-luchshih-praktik-po-ekspluatatsii-kontejnerov-po-versii-google","title":{"rendered":"7 mejores pr\u00e1cticas para operar contenedores seg\u00fan Google","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota de traducci\u00f3n.<\/b>: Autor del art\u00edculo original \u2014 Th\u00e9o Chamley, arquitecto de soluciones en la nube de Google. En esta publicaci\u00f3n del blog de Google Cloud, present\u00f3 un breve resumen de una gu\u00eda m\u00e1s detallada de su empresa, llamada \u201cMejores Pr\u00e1cticas para Operar Contenedores<\/a><\/noindex>\u201d. En ella, los especialistas de Google recopilaron las mejores pr\u00e1cticas para la explotaci\u00f3n de contenedores en el contexto del uso de Google Kubernetes Engine y m\u00e1s, abarcando una amplia gama de temas: desde la seguridad hasta la monitorizaci\u00f3n y el registro. Entonces, \u00bfcu\u00e1les son las pr\u00e1cticas m\u00e1s importantes para el trabajo con contenedores seg\u00fan Google?<\/i><\/p>\n

\"7<\/a><\/noindex><\/p>\n

Kubernetes Engine<\/a><\/noindex> (servicio basado en Kubernetes para ejecutar aplicaciones containerizadas en Google Cloud \u2014 nota del traductor.<\/b>)<\/i> \u2014 es una de las mejores maneras de ejecutar cargas de trabajo que requieren escalabilidad. Kubernetes<\/a><\/noindex> Garantizar\u00e1 el funcionamiento sin problemas de la mayor\u00eda de las aplicaciones, siempre que est\u00e9n containerizadas. Pero si desea que la aplicaci\u00f3n sea f\u00e1cil de gestionar y aprovechar todas las ventajas de Kubernetes, es necesario seguir las mejores pr\u00e1cticas. Estas simplificar\u00e1n la explotaci\u00f3n de la aplicaci\u00f3n, su monitoreo y depuraci\u00f3n, as\u00ed como aumentar\u00e1n la seguridad.<\/p>\n

En este art\u00edculo, revisaremos una lista de lo que debe saber y hacer para el funcionamiento efectivo de los contenedores en Kubernetes. Quienes deseen profundizar en los detalles deber\u00edan leer el material Mejores Pr\u00e1cticas para Operar Contenedores<\/a><\/noindex>, as\u00ed como prestar atenci\u00f3n a nuestro post anterior<\/a><\/noindex> sobre la construcci\u00f3n de contenedores.<\/p>\n

1. Utilice los mecanismos nativos de los contenedores para el registro<\/h2>\n

\nSi la aplicaci\u00f3n se ejecuta en un cl\u00faster de Kubernetes, no se necesita mucho para los registros. Un sistema de registro centralizado probablemente ya est\u00e1 integrado en el cl\u00faster que se est\u00e1 utilizando. En el caso de usar Kubernetes Engine, esto es responsabilidad de Stackdriver Logging<\/a><\/noindex>. (Nota de traducci\u00f3n.<\/b>: Y si utiliza su propia instalaci\u00f3n de Kubernetes, le recomendamos que considere nuestra soluci\u00f3n de c\u00f3digo abierto \u2014 loghouse<\/a><\/noindex>.)<\/i> No se complica la vida y utilice los mecanismos nativos de registro de los contenedores. Escriba registros en stdout y stderr: ser\u00e1n capturados, almacenados e indexados autom\u00e1ticamente.<\/p>\n

Si lo desea, tambi\u00e9n puede escribir registros en formato JSON<\/a><\/noindex>. Este enfoque permitir\u00e1 agregar f\u00e1cilmente metadatos a ellos. Junto con estos, surgir\u00e1 la posibilidad de b\u00fasqueda en los registros en Stackdriver Logging utilizando esos metadatos.<\/p>\n

2. Aseg\u00farese de que los contenedores sean stateless e inmutables<\/h2>\n

\nPara que los contenedores funcionen correctamente en un cl\u00faster de Kubernetes, deben ser stateless e immutable. Cuando se cumplen estas condiciones, Kubernetes puede realizar su trabajo creando y destruyendo entidades de la aplicaci\u00f3n cuando y donde sea necesario.<\/p>\n

Stateless<\/i> significa que cualquier estado (datos permanentes de cualquier tipo) se almacena fuera del contenedor. Para ello, dependiendo de las necesidades, se pueden utilizar diferentes tipos de almacenamiento externo: Almacenamiento en la Nube<\/a><\/noindex>, Discos Persistentes<\/a><\/noindex>, Redis<\/a><\/noindex>, Cloud SQL<\/a><\/noindex> o otras bases de datos gestionadas. (Nota de traducci\u00f3n.<\/b>: Para m\u00e1s informaci\u00f3n, consulte tambi\u00e9n nuestro art\u00edculo \"Operadores para Kubernetes: c\u00f3mo ejecutar aplicaciones con estado<\/a><\/noindex>\u00bb.)<\/i><\/p>\n

Immutable<\/i> significa que el contenedor no se modificar\u00e1 durante su vida \u00fatil: no habr\u00e1 actualizaciones, parches ni cambios en la configuraci\u00f3n. Si necesita actualizar el c\u00f3digo de la aplicaci\u00f3n o aplicar un parche, cree una nueva imagen y despliegue esta. Se recomienda extraer la configuraci\u00f3n del contenedor (puerto de escucha, opciones del entorno de ejecuci\u00f3n, etc.) hacia Secrets<\/a><\/noindex> y ConfigMaps<\/a><\/noindex>. Se pueden actualizar sin necesidad de construir una nueva imagen de contenedor. Para crear pipelines de construcci\u00f3n de im\u00e1genes de manera sencilla, se puede utilizar Cloud Build<\/a><\/noindex>. (Nota de traducci\u00f3n.<\/b>: Para estos fines, utilizamos la herramienta de c\u00f3digo abierto dapp<\/a><\/noindex>.)<\/i><\/p>\n

\"7
\nEjemplo de actualizaci\u00f3n de la configuraci\u00f3n de Deployment en Kubernetes utilizando ConfigMap, montado en los pods como configuraci\u00f3n<\/i><\/p>\n

3. Evite contenedores privilegiados<\/h2>\n

\nNo est\u00e1is ejecutando aplicaciones como root en vuestros servidores, \u00bfverdad? Si un atacante logra infiltrarse en la aplicaci\u00f3n, tendr\u00e1 acceso con privilegios de root. Las mismas consideraciones se aplican a no ejecutar contenedores con privilegios. Si es necesario modificar la configuraci\u00f3n en el host, se le puede otorgar al contenedor permisos espec\u00edficos. capabilities<\/i> mediante la opci\u00f3n securityContext<\/code><\/a><\/noindex> en Kubernetes. Si es necesario modificar sysctls<\/i>, Kubernetes tiene una anotaci\u00f3n especial<\/a><\/noindex> para ello. En general, trate de utilizar al m\u00e1ximo init-<\/a><\/noindex> y contenedores sidecar para realizar estas operaciones privilegiadas. No necesitan estar disponibles para el tr\u00e1fico interno o externo.<\/p>\n

Si usted es el administrador del cl\u00faster, puede utilizar Pol\u00edtica de Seguridad de Pods<\/a><\/noindex> para restricciones en la aplicaci\u00f3n de contenedores privilegiados.<\/p>\n

4. Evite ejecutar como root<\/h2>\n

\nYa se ha hablado sobre los contenedores privilegiados, pero ser\u00eda a\u00fan mejor si, adem\u00e1s de eso, no ejecut\u00e1is aplicaciones como root dentro del contenedor. Si un atacante encuentra una vulnerabilidad remota con capacidad de ejecuci\u00f3n de c\u00f3digo en una aplicaci\u00f3n con privilegios de root, y luego puede salir fuera del contenedor a trav\u00e9s de una vulnerabilidad a\u00fan no descubierta, obtendr\u00e1 acceso root en el host.<\/p>\n

La mejor forma de evitar esto es, ante todo, no ejecutar nada como root. Para ello, se puede utilizar la directiva. USER<\/code> en Dockerfile<\/code> o runAsUser<\/code> en Kubernetes. El administrador del cl\u00faster tambi\u00e9n puede configurar un comportamiento forzado usando Pol\u00edtica de Seguridad de Pods<\/a><\/noindex>.<\/p>\n

5. Haga que la aplicaci\u00f3n sea f\u00e1cil de monitorear<\/h2>\n

\nAl igual que el registro, el monitoreo es una parte integral de la gesti\u00f3n de aplicaciones. Una soluci\u00f3n popular para el monitoreo en la comunidad de Kubernetes es Prometheus<\/a><\/noindex> \u2014 un sistema que detecta autom\u00e1ticamente los pods y servicios que requieren monitoreo. (Nota de traducci\u00f3n.<\/b>: Consulte tambi\u00e9n nuestro informe detallado<\/a><\/noindex> sobre monitoreo con Prometheus y Kubernetes.)<\/i> Stackdriver<\/a><\/noindex> puede monitorear cl\u00fasteres de Kubernetes e incluye su propia versi\u00f3n de Prometheus para el monitoreo de aplicaciones.<\/p>\n

\"7
\nEl panel de monitoreo de Kubernetes en Stackdriver<\/i><\/p>\n

Prometheus espera que la aplicaci\u00f3n exponga m\u00e9tricas en un endpoint HTTP. Para esto, est\u00e1n disponibles bibliotecas de cliente de Prometheus<\/a><\/noindex>. El mismo formato es utilizado por otras herramientas como OpenCensus<\/a><\/noindex> y Istio<\/a><\/noindex>.<\/p>\n

6. Haga accesible el estado de salud de la aplicaci\u00f3n<\/h2>\n

\nLa gesti\u00f3n de aplicaciones en producci\u00f3n se ve ayudada por su capacidad para informar sobre su estado a todo el sistema. \u00bfEst\u00e1 la aplicaci\u00f3n en ejecuci\u00f3n? \u00bfEst\u00e1 en buen estado? \u00bfEst\u00e1 lista para recibir tr\u00e1fico? \u00bfC\u00f3mo se comporta? La forma m\u00e1s com\u00fan de abordar este problema es implementar verificaciones de salud (health checks)<\/i>. Kubernetes tiene dos tipos de ellas: liveness y readiness probes<\/a><\/noindex>.<\/p>\n

Para liveness probe (verificaci\u00f3n de viabilidad)<\/i> la aplicaci\u00f3n debe tener un endpoint HTTP que devuelva una respuesta \u201c200 OK\u201d si est\u00e1 funcionando y sus principales dependencias est\u00e1n satisfechas. Para readiness probe (verificaci\u00f3n de preparaci\u00f3n para el servicio)<\/i> La aplicaci\u00f3n debe tener otro endpoint HTTP que devuelva una respuesta \"200 OK\" si la aplicaci\u00f3n est\u00e1 en buen estado, se han completado los pasos de inicializaci\u00f3n y cualquier solicitud correcta no conduce a un error. Kubernetes dirigir\u00e1 el tr\u00e1fico al contenedor solo si la aplicaci\u00f3n est\u00e1 lista seg\u00fan estas comprobaciones. Dos endpoints pueden combinarse si no existe diferencia entre los estados de viabilidad (liveness) y preparaci\u00f3n (readiness).<\/p>\n

Puedes leer m\u00e1s al respecto en el art\u00edculo correspondiente de Sandeep Dinesh, Defensor de Desarrolladores en Google: \u00abMejores pr\u00e1cticas de Kubernetes: Configuraci\u00f3n de comprobaciones de salud con sondas de preparaci\u00f3n y viabilidad<\/a><\/noindex>\u00bb.<\/p>\n

7. Elige cuidadosamente la versi\u00f3n de la imagen<\/h2>\n

\nLa mayor\u00eda de las im\u00e1genes p\u00fablicas y privadas utilizan un sistema de etiquetado similar al descrito en Mejores Pr\u00e1cticas para Construir Contenedores<\/a><\/noindex>. Si la imagen aplica un sistema cercano a versionado sem\u00e1ntico<\/a><\/noindex>, es necesario considerar las particularidades del etiquetado. Por ejemplo, la etiqueta latest<\/code> puede moverse con frecuencia de una imagen a otra \u2014 no se puede confiar en ella si necesitas construcciones e instalaciones predecibles y reproducibles.<\/p>\n

Puedes utilizar la etiqueta X.Y.Z<\/code> (casi siempre son invariables), sin embargo, en ese caso, debes rastrear todos los parches y actualizaciones de la imagen. Si la imagen que utilizas tiene la etiqueta X.Y<\/code>, es una buena opci\u00f3n intermedia. Al elegirla, obtienes autom\u00e1ticamente los parches y al mismo tiempo te basas en una versi\u00f3n estable de la aplicaci\u00f3n.<\/p>\n

P.D. del traductor<\/h2>\n

\nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n