En Google Cloud Español te hablamos de como los datos de los usuarios almacenados en disco duro siempre se pueden cifran de forma predeterminada utilizando varias capas de tecnología de cifrado . Te explicamos que opciones de administración de claves de encriptación tienes para ayudarte a cumplir con los requisitos de seguridad de tu organización. ¿Sabía que ahora hay una funcionalidad beta que puede usar para aumentar aún más la protección de tus discos, imágenes e instantáneas de Compute Engine utilizando sus propias claves de cifrado almacenadas y administradas con Cloud Key Management Service (KMS)? Estas claves de encriptación administradas por el cliente (CMEK) le ofrecen un control granular sobre qué discos, imágenes e instantáneas se cifrarán.
Puede ver a continuación que en un extremo del espectro, Compute Engine encripta automáticamente los discos y administra las claves en tu nombre. En el otro extremo, puede continuar usando las claves de encriptación proporcionadas por el cliente(CSEK) para sus cargas de trabajo más sensibles y/o reguladas.
Esta característica te ayuda a encontrar el equilibrio entre la facilidad de uso y el control: tus claves están en la nube, pero aún bajo tu administración. Esta opción es ideal para organizaciones en industrias reguladas que necesitan cumplir con requisitos estrictos para la protección de datos, pero que no desean ocuparse de los gastos generales de la creación de soluciones personalizadas para generar y almacenar claves, administrar y registrar el acceso clave, etc.
La configuración de CMEK en Compute Engine ayuda a brindarles tranquilidad rápidamente a estas organizaciones, ya que controlan el acceso al disco mediante el control de las claves.
Cómo crear un disco compatible con CMEK
Para comenzar con la función CMEK es fácil. Siga los pasos a continuación para crear y adjuntar un disco de Compute Engine cifrado con una clave que gestionas.
Deberá crear "Key ring" y una clave en KMS. Esto, y el resto de los pasos a continuación, se pueden realizar de varias maneras: a través de Developer Console , API y gcloud . En este tutorial, usaremos la consola de desarrollador. Comenzaremos en la página Claves criptográficas , donde seleccionaremos "Key ring".
Dale un nombre a tu llavero. Haga lo mismo con la tecla de la página siguiente. Para este tutorial, el resto de opciones pueden dejarse por defecto.
Cuando completes estos pasos tendras una KEY con una sola clave de cifrado AES-256. En la captura de pantalla siguiente, puede verlo como "tutorial-keyring-1". Y como KMS administra el llavero, ya está completamente integrado con Cloud Identity and Access Management (IAM) y Cloud Audit Logging, por lo que puede fácilmente Administrar permisos y monitorear cómo se usa.
Con la clave en su lugar, puede comenzar a encriptar discos con las teclas CMEK. Las instrucciones a continuación son para crear una nueva instancia y proteger su disco de arranque con una clave CMEK. Tenga en cuenta que también es posible crear nuevos discos encriptados a partir de instantáneas e imágenes y adjuntarlos a máquinas virtuales existentes, o incluso encriptar las instantáneas y las imágenes subyacentes.
En la página de creación de instancias, expanda la sección "Administración, discos, redes y claves SSH" y vaya a la pestaña "Discos". Allí, verá opciones para las tres opciones de encriptación diferentes descritas anteriormente. Seleccione "Clave administrada a medida" y seleccione la clave adecuada en el menú desplegable.
Tenga en cuenta que si es la primera vez que hace esto, puede ver el siguiente diálogo. Esto es lo que debe aparecer la primera vez para otorgar permisos a esta cuenta de servicio. A su vez, Compute Engine utiliza esta cuenta de servicio para realizar el cifrado y descifrado real de discos, imágenes e instantáneas.
Una vez que haya hecho esto, confirme la creación de la máquina virtual seleccionando "Crear".
¡Y ahí lo tienes! Con unos sencillos pasos, puede crear una clave en Cloud KMS, cifrar un disco con la clave y montarlo en una máquina virtual. Como administra la clave, puede elegir suspender o eliminar la clave en cualquier momento. Si eso sucede, los recursos protegidos por esa clave no se iniciarán hasta que se restablezca el acceso a la clave.
Usando HashiCorp Terraform para gestionar y modificar sus recursos en Google Cloud
Cuando empiezas un nuevo código o proyecto de software, es posible que desee activar un entorno de prueba para simular la aplicación. HashiCorp Terraform es una herramienta de administración e implementación de infraestructura que le permite configurar la infraestructura mediante una variedad de proveedores, incluidos los proveedores de la nube, como Google Cloud. Al usar Terraform en Google Cloud, puede administrar proyectos, políticas de IAM, recursos de Compute Engine, conjuntos de datos BigQuery y más. Para comenzar con Terraform para Google Cloud, consulte la documentación del proveedor Terraform Google Cloud , eche un vistazo al tutorial para administrar proyectos GCP con Terraform, que puede seguir en nuestra página , o vea la demostración de Terraform para Google Cloud.
Queremos contar con nuevos contribuyentes a los proyectos de open source que estamos gestionando. Si desea contribuir, apuntate en proyectos como Kubernetes , istio , así como en Vault y Terraform . La comunidad es lo que hace que estos proyectos tengan éxito. Para obtener más información acerca de los proyectos de código abierto que admitimos, consulte Open source en Google .
La decimosexta región de Google Cloud Platform (GCP), ubicada en Finlandia, está ya abierta para que pueda crear aplicaciones y almacenar sus datos.
La nueva región de Finlandia, europe-north1, se une a los Países Bajos, Bélgica, Londres y Frankfurt en Europa y facilita la creación de aplicaciones de alto rendimiento y disponibilidad utilizando recursos en esas geografías.
Las aplicaciones de alojamiento en la nueva región pueden mejorar las latencias hasta en un 65% para los usuarios finales en los países nórdicos y hasta en un 88% para los usuarios finales en Europa del Este, en comparación con su alojamiento en la región más cercana. Puede visitar www.gcping.com para ver qué tan rápido es la región de Finlandia desde su ubicación.
Servicios
La región nórdica tiene todo lo que necesita para construir la próxima gran aplicación y tres zonas que le permiten distribuir aplicaciones y almacenamiento en múltiples zonas para protegerse contra las interrupciones del servicio.
También puede acceder a nuestros servicios multiregionales en Europa (como BigQuery) y a todos los otros servicios de GCP a través de la red de Google, la mayor red de la nube, medida por el número de puntos de presencia. Visite nuestros Términos específicos del servicio para obtener información detallada sobre nuestras capacidades de almacenamiento de datos.
Construir de forma sostenible
La nueva región se encuentra en nuestro centro de datos existente en Hamina. Esta instalación es uno de los centros de datos más avanzados y eficientes de la flota de Google. Nuestro sistema de refrigeración de alta tecnología, que utiliza agua de mar del Golfo de Finlandia, reduce el consumo de energía y es el primero de este tipo en cualquier parte del mundo. Esto significa que cuando usa esta región para ejecutar sus cargas de trabajo de cómputo, almacenar sus datos y desarrollar sus aplicaciones, lo está haciendo de forma sostenible.
En Google Cloud Español estamos de estreno del nuevo canal de youtube
Y empezamos con toda un formación de:
Juan Guillermo Gómez
GDE Firebase
Lider del GDG Cali - Colombia
CEO DevHack
Linkedin: co.linkedin.com/in/jggomezt @jggomezt - GDG Cali - GDE Firebase
Y nos presenta:
Creando tu chatbot con Dialogflow
Los chatbots se han convertido en una herramienta importante para mejorar los servicios brindados en las empresas, agregando un mayor soporte y engagement de los usuarios. Con Dialogflow una plataforma de google podrás crear chatbots de una forma sencilla y robusta. En este webinar hablaremos y crearemos un chatbots que se conecte a APIs para obtener información e integrarlo con los los messenger mas comunes.
Registra el evento en tu calendario y pasate por el canal y activa las notificaciones para no perderte nada:
Dirección del evento: https://www.youtube.com/watch?v=oeX1PH1fGn0
Hoy en Google Cloud Español y de la mano del gran Romin Irani nos ha preparado una serie de tutoriales sobre Google Cloud Functions, una plataforma de cómputo sin servidor basada en eventos.
Esta oferta se basa en la oferta informática Funtions as a Service (Faas as a Service (FaaS)).
La serie cubrirá los siguientes temas:
Descripción general de las opciones de servicios disponibles, junto con detalles específicos sobre la oferta de Serverless y funciones como servicio (FaaS).
Configuración de un entorno de desarrollo local para Google Cloud Functions. Esta sección cubre la instalación y configuración de gcloud, código de Visual Studio y un emulador local que le permite probar sus funciones localmente.
Escritura de funciones de fondo. Esta sección cubre dos tipos de proveedores de eventos: Google Cloud Storage y Google Pub / Sub que actualmente son compatibles como proveedores de eventos que pueden activar sus funciones en la nube.
Desarrollo local. Esta sección cubre cómo utilizar la herramienta gcloud a través de los comandos de las funciones beta de gcloud. Emulación local y depuración: esta sección cubre cómo usar el emulador de funciones locales para probar sus funciones y también cómo depurar su código de función localmente.
Aplicaciones de Google Cloud Functions. Esta sección contiene una serie de aplicaciones que demuestran cómo podemos escribir funciones para crear aplicaciones interesantes y útiles.
- Estableciendo un canal de traducción de idiomas para inglés -> traducción al español
Todo el código complementario para la serie de tutoriales está disponible aquí. Continúa y clona el repositorio o mejor aún, ábrelo en Google Cloud Shell a través del botón en la página del proyecto Github a continuación. Mire el archivo README.md en la carpeta raíz, contiene instrucciones sobre cómo ejecutar tutoriales en Google Cloud Shell.
Google Cloud Functions se encuentra actualmente en Beta. Si bien actualmente la oferta no ofrece características en comparación con ofertas equivalentes de AWS y Azure, se espera que se publiquen más tiempos de ejecución de idioma, proveedores de eventos y características a medida que se acerca a la Disponibilidad general (GA). Esta serie de tutoriales se mantendrá actualizada para reflejar los cambios y las nuevas características.
Si tiene algún comentario específico sobre el contenido existente y / o desea que yo explore posiblemente sobre un tema relacionado con Google Cloud Functions, hágamelo saber en los comentarios o envíeme un correo electrónico.
En Google Cloud Español os hablamos de un nuevo anuncio en beta en Google Cloud y es la disponibilidad beta de los nodos sole-tenant en Google Compute Engine.
Los nodos sole-tenant son servidores físicos de Compute Engine diseñados para su uso exclusivo. Normalmente, las instancias de VM se ejecutan en hosts físicos que pueden ser compartidos por muchos clientes. Con los nodos de sole-tenant, nos aseguran que tendremos host sólo para nosotros.
Puede lanzar instancias utilizando las mismas opciones que usaría para las instancias normales, excepto en la capacidad del servidor dedicada para usted. Puedes lanzar instancias de cualquier forma (es decir, vCPU y memoria). Un algoritmo de ubicación encuentra automáticamente la ubicación óptima para iniciar su instancia en todos sus nodos. Si prefiere más control, puede seleccionar manualmente la ubicación para lanzar sus instancias.
Las instancias lanzadas en nodos de sole-tenant pueden aprovechar la migración en caliente para evitar el tiempo de inactividad durante el mantenimiento proactivo. Los precios siguen siendo simples: pague solo por los nodos que usa por segundo con un cargo mínimo de un minuto. Los descuentos por uso sostenido se aplican automáticamente, al igual que cualquier descuento de uso comprometido nuevo o existente.
Los nodos sole-tenant estan pensados para:
Cumplimiento de regulación: las organizaciones con requisitos estrictos de cumplimiento normativo pueden usar nodos con sole-tenant con ubicación de VM para facilitar la separación física de sus recursos informáticos en la nube.
Aislamiento y utilización: controle la ubicación de la instancia directamente a través de etiquetas definidas por el usuario, o permita que Compute Engine maneje automáticamente la ubicación de la instancia en los nodos. También puede crear e iniciar diferentes tipos de máquinas, o "formas" en sus nodos, con el fin de lograr el mayor nivel de utilización.
Para comenzar con nodos sole-tenant. Puede iniciar una VM en un nodo de sole-tenant desde Google Cloud SDK, así como desde las API de Compute Engine (En Google Cloud Console próximamente):
// CREATE A NODE TEMPLATE
gcloud beta compute sole-tenancy node-templates create mynodetemplate
--node-type n1-node-96-624 --region us-central1
// PROVISION A NODE GROUP OF SIZE TWO
gcloud beta compute sole-tenancy node-groups create mynodegroup
--node-template mynodetemplate --target-size 2 --zone us-central1-a
// CREATE INSTANCE WITH 4vCPUS AND 8GB OF MEMORY ON A NODE
gcloud beta compute instances create my-vm --node-group
mynodegroup --custom-cpu 4 --custom-memory 8 --zone us-central1-a
Los nodos sole-tenant con compatibles con las opciones de migración en caliente, reducción de precio por uso continuado, con las redes VCP y se pueden conectar con el resto de instancias, se pueden crear maquinas a medida y predefinidas a excepcion de las restricciones que luego se indican, y permiten la gestión en grupo para auto-escalado.
Restricciones
Las siguientes opciones no estan activadas en nodos sole-tenant
Host que tienes menos de dos vCPUs
Maquinas que comparten core de tipo:
f1-micro
g1-small
Los host de tipo n1-standar-1
Hos a medida "Custon" on un sola vCPU
Para obtener más informacion sobre ubicaciones manuales, consulte la documentación. Visite la página de precios para obtener más información sobre los precios, así como sobre la disponibilidad regional.
Desde Google Cloud Español saludamos a un nuevo grupo dentro de los GDG Cloud que también habla en Español, en poco tiempo tenemos dos nuevos Cloud Community en y esta vez es en Peru en su capital Lima
Para estar al día de sus eventos pasate por la web y registrate sin falta en su meetup. La Comunidad de Cloud esta creciendo y en una zona con mas proyección es en todo America, especialmente en Latino America.
Apuntate a su canal en twitter @GCDCLima
Nota del traductor: En Google cloud Español os indicamos que es la última entrega de una serie de videos y blogs en siete partes de Google Developer Advocate Sandeep Dinesh sobre cómo aprovechar al máximo su entorno de Kubernetes.
La máxima de -Si funciona no toques- no es aplicable a los servicios que están expuestos en internter y es una buena práctica mantener la aplicación actualizada para optimizar la seguridad y el rendimiento. Kubernetes y Docker pueden hacer que estas actualizaciones sean mucho más fáciles, ya que puede construir un nuevo contenedor con las actualizaciones y desplegar lo con relativa facilidad.
Al igual que sus aplicaciones, Kubernetes constantemente obtiene nuevas funciones y actualizaciones de seguridad, por lo que los nodos subyacentes y la infraestructura de Kubernetes deben mantenerse actualizados.
En este episodio de Best-Practices de Kubernetes, echemos un vistazo a cómo Google Kubernetes Engine puede hacer que la actualización de su clúster de Kubernetes sea transparente.
Las dos partes de un grupo
Cuando se trata de actualizar su clúster, hay dos partes y ambos necesitan actualizarse: los maestros y los nodos. Los maestros necesitan actualizarse primero, y luego los nodos pueden seguir. Veamos cómo actualizar ambos usando Kubernetes Engine.
Actualización del maestro sin tiempo de inactividad
Kubernetes Engine actualiza automáticamente el maestro a medida que se lanzan nuevas versiones , sin embargo, por lo general, no se actualizará automáticamente a una nueva versión (por ejemplo, de 1.7 a 1.8). Cuando esté listo para actualizar a una nueva versión, puede simplemente hacer clic en el botón maestro de actualización en la consola de Kubernetes Engine, por ejemplo:
Sin embargo, es posible que haya notado que el cuadro de diálogo dice lo siguiente:
"Cambiar la versión maestra puede provocar varios minutos de inactividad de la gestionde control. Durante ese período, no podrá editar este clúster ".
Cuando el maestro realiza una actualización, las implementaciones, los servicios, etc. continúan funcionando como se esperaba. Sin embargo, todo lo que requiere la API de Kubernetes deja de funcionar. Esto significa que kubectl deja de funcionar, las aplicaciones que usan la API de Kubernetes para obtener información sobre el funcionamiento del clúster y, básicamente, no puede realizar ningún cambio en el clúster mientras se está actualizando.
Entonces, ¿cómo actualizar el maestro sin incurrir en tiempo de inactividad?
Masters de alta disponibilidad con clusters regionales de Kubernetes Engine
Mientras que los clústeres Kubernetes Engine estándar "Zonal" solo tienen un nodo maestro que los respalda, puede crear clústeres "Regionales" que proporcionan maestros de zonas múltiples y altamente disponibles.
Al crear su clúster, asegúrese de seleccionar la opción "regional":
¡Y eso es! Kubernetes Engine crea automáticamente sus nodos y maestros en tres zonas, con los maestros detrás de una dirección IP con equilibrio de carga, por lo que la API de Kubernetes continuará funcionando durante una actualización.
Actualización de nodos con tiempo de inactividad cero
Al actualizar los nodos, hay algunas estrategias diferentes que puede usar. Hay dos en los que me quiero enfocar:
Actualización continua
Migración con grupos de nodos
1. Actualización continua
La forma más sencilla de actualizar los nodos de Kubernetes es utilizar una actualización continua. Es el mecanismo de actualización predeterminado que Kubernetes Engine usa para actualizar sus nodos.
Una actualización continua funciona de la siguiente manera. Uno a uno, un nodo se vacía y se condiciona para que no haya más módulos que se ejecutan en ese nodo. Luego se elimina el nodo y se crea un nuevo nodo con la versión actualizada de Kubernetes. Una vez que ese nodo está en funcionamiento, se actualiza el siguiente nodo. Esto continúa hasta que se actualicen todos los nodos.
Puede dejar que Kubernetes Engine administre este proceso por completo habilitando actualizaciones automáticas de nodos en el grupo de nodos.
Si no selecciona esto, el panel de control de Kubernetes Engine le avisará cuando haya disponible una actualización:
Simplemente haga clic en el enlace y siga el mensaje para comenzar la actualización continua.
Advertencia: asegúrese de que sus pods sean administrados por ReplicaSet, Deployment, StatefulSet o algo similar. ¡Los pods autónomos no serán gestionados!
Si es simple realizar una actualización continua en Kubernetes Engine, tiene algunos inconvenientes.
Una desventaja es que obtiene un nodo menos de capacidad en su clúster. Este problema se resuelve fácilmente escalando su grupo de nodos para agregar capacidad adicional, y luego des-escalando nuevamente una vez que la actualización ha finalizado.
La naturaleza completamente automatizada de la actualización progresiva lo hace fácil pero usted tiene menos control sobre el proceso. También lleva tiempo volver a la versión anterior si hay un problema, ya que debe detener la actualización continua y luego deshacerla.
2. Migración con grupos de nodos
En lugar de actualizar el grupo de nodos "activo" como lo haría con una actualización continua, puede crear un grupo de nodos nuevo, esperar a que se ejecuten todos los nodos y luego migrar las cargas de trabajo de un nodo a la vez.
Supongamos que nuestro clúster de Kubernetes tiene tres VM en este momento. Puede ver los nodos con el siguiente comando:
kubectl get nodes
NAME STATUS AGE
gke-cluster-1-default-pool-7d6b79ce-0s6z Ready 3h
gke-cluster-1-default-pool-7d6b79ce-9kkm Ready 3h
gke-cluster-1-default-pool-7d6b79ce-j6ch Ready 3h
Creando el nuevo grupo de nodos
Para crear el nuevo grupo de nodos con el nombre "pool-two", ejecute el siguiente comando:
gcloud container node-pools create pool-two
Nota: Recuerde personalizar este comando para que el nuevo grupo de nodos sea el mismo que el anterior. También puede usar la GUI para crear un nuevo grupo de nodos si lo desea.
Ahora bien, si comprueba los nodos, notará que hay tres nodos más con el nuevo nombre del grupo:
$ kubectl get nodes
NAME STATUS AGE
gke-cluster-1-pool-two-9ca78aa9–5gmk Ready 1m
gke-cluster-1-pool-two-9ca78aa9–5w6w Ready 1m
gke-cluster-1-pool-two-9ca78aa9-v88c Ready 1m
gke-cluster-1-default-pool-7d6b79ce-0s6z Ready 3h
gke-cluster-1-default-pool-7d6b79ce-9kkm Ready 3h
gke-cluster-1-default-pool-7d6b79ce-j6ch Ready 3h
¡Sin embargo, los pods todavía están en los nodos antiguos! Cambiemos los pods de lugar.
Elimine el antiguo grupo
Ahora necesitamos mover el trabajo al nuevo grupo de nodos. Avancemos sobre un nodo a la vez de manera continua.
Primero, ajuste cada uno de los nodos antiguos. Esto evitará que se programen nuevos pods en ellos. Es como meterlos en mantenimiento.
kubectl cordon nodo
Una vez que todos los nodos antiguos están acordonados, los pods solo se pueden programar en los nuevos nodos. Esto significa que puede comenzar a eliminar pods de los nodos antiguos, y Kubernetes los programa automáticamente los crea dentro de los nuevos nodos. Advertencia: asegúrese de que sus pods sean administrados por ReplicaSet, Deployment, StatefulSet o algo similar. ¡Los pods independientes no se reprogramarán!
Ejecute el siguiente comando para vaciar cada nodo. Esto elimina todos los pods en ese nodo.
kubectl drain --force
Después de vaciar un nodo, asegúrese de que los nuevos pods estén activos y en ejecución antes de continuar con el siguiente. Si tiene algún problema durante la migración, conecte el antiguo grupo y luego desactive y vacié el nuevo grupo. Los pods vuelven a programarse en el grupo anterior.
Borre el grupo anterior. Una vez que todos los pods se reprograman de manera segura, es hora de eliminar el grupo anterior. Reemplazar "grupo predeterminado" con el grupo que desea eliminar.
gcloud container node-pools delete default-pool
¡Aacabas de actualizar con éxito todos sus nodos!
Conclusión
Para utilizar Kubernetes Engine, puede mantener su clúster de Kubernetes actualizado con solo unos pocos clics.
Si no está utilizando un servicio gestionado como Kubernetes, puede seguir utilizando la actualización continua o método de grupos de nodos con su propio clúster para actualizar los nodos. La diferencia es que debe agregar manualmente los nuevos nodos a su clúster y realizar la actualización maestra a a mano, lo cual puede ser complicado.
Recomiendo utilizar los clústeres regionales de Kubernetes Engine para los maestros de alta disponibilidad y las actualizaciones automáticas de nodos para tener una solución rápida, tenga en cuenta que la actualización es gratuita.
Si necesita el controlar de forma adicional las actualizaciones de su nodo, el uso de conjuntos de nodos le otorga ese control sin renunciar a las ventajas de una plataforma administrada de Kubernetes que Kubernetes Engine le ofrece.
Y así concluye esta serie sobre las mejores prácticas de Kubernetes. Si tiene ideas para otros temas que le gustaría abordar en el futuro, puede encontrarme en Twitter.